26 ms·

Ask HN: What happened to vanilla HTML/CSS/JS development?

• rozenmd 4y ago
  JS development in particular is relatively verbose, so folks started writing little helper libraries to get things done faster. Folks open-sourced their libraries, others contributed, and we eventually wound up with frameworks.
  • LEDThereBeLight 4y ago
    I think there’s a core difference between helper libraries and frameworks like React. JQuery is a helper library, but the purpose of React etc are more to manage state, improve efficiency, and pave over security and browser inconsistency issues more than they are to reduce lines of code.
• adamredwoods 4y ago
  Security, scaling of development, and progression of language features. The larger a code base gets, the more complex it can be, and frameworks help abstract ideas (like design systems), rather than having to repeat component code, css, each time it is needed. Also, if more developers are being added to the code base, the scaling of a project can get quite large. We have over 50 developers working at my company coding on the website. Security is another. When updating a list of items (for example) from a fetch, vanilla js will require direct modification of the html, whereas a framework like React will handle that, with best security practices applied, as the code has been written and production tested. I'm not going to deep dive on language features, can be quite subjective, for example how great Typescript is (compiler errors > runtime errors), or how SASS fills in a lot of missing features for CSS, etc. I think some websites could be done in vanilla JS/HTML/CSS, but as the site scales, I feel at some point a developer would build their own framework to make things easier and streamlined. It's what developers do.
• gabrielsroka 4y ago
  > I don't understand what problem they're trying to solve I don't use React. I learned a little bit of Vue. I'm definitely not an expert, but I think there are (at least) two problems that they solve: consistency and reusability. Consistency: I think the hope is that if you're a React programmer and you see a brand new site written in React, you'll understand it, whereas if it used vanilla JS, it might be written in any number of ways. Reusability: if you start writing your own reusable functions in vanilla, you'll eventually build your own React -- it's the build vs. buy decision.
• LEDThereBeLight 4y ago
  The web was originally created to share documents, so interactivity and extra functionality was an afterthought. As the web became more popular, websites started to add more functionality similar to traditional software programs. Eventually, the original guideline of HTML for structure, CSS for styling, and JavaScript for interactivity started to not really make sense anymore for many websites, because as pages became more interactive, the lines became blurred. If you look at a site like GMail, where does the page structure end and interactivity begin? With large parts of a page being interactive, it becomes difficult to manage all the state involved, especially if it’s a “live” page that updates in real time and may have several people viewing it. Frameworks were introduced as a way to manage state and allow websites to re-render efficiently without hard page refreshes.
  • skadamat 4y ago
    IMO this is the best answer. A clear, history-contextualized summary of the reasons why vanilla is often not enough for some use cases.
    • krapp 4y ago
      For some use cases, sure. But most sites aren't GMail. Frameworks and typescript should still be the exception, and the rule should still be independent, modular libraries like JQuery.
      • kitsunesoba 4y ago
        As someone who’s become most comfortable with strictly typed languages (primarily Swift and Kotlin), I find that TypeScript makes my dabbling in web dev much more tolerable and even somewhat enjoyable, even for simple projects with zero dependencies. Plain JS becomes frustrating quickly as project complexity ramps.
      • joshmanders 4y ago
        > But most sites aren't GMail. Frameworks and typescript should still be the exception, and the rule should still be independent, modular libraries like JQuery. People always say this but it's so hollow. Most sites aren't Gmail, but we're not building most sites. We're building applications that work in similar fashion to Gmail, thus need similar stuff like all these frameworks provide. "Oh but everyone's using React to build their blogs instead of writing new posts for them and that's overkill" Let me stop you before we get to this point. People use their personal blogs as a way to test new concepts they want to learn, so of course it's gonna be over engineered to hell.
• altilunium 4y ago
  Most of my side projects are written in plain HTML/CSS/JS. Of course, it's deemed "not acceptable" by current industry standards. But i work for myself, so i dont care. https://github.com/altilunium/ https://github.com/altilunium/
  • silent_cal 4y ago
    Very cool, thank you for sharing
  • ozim 4y ago
    Not acceptable if you would have 4-8 people working on it - where any of these people stay with company around 2-4 years on average. Not acceptable if each person working for 2 years builds his own abstractions that new hires have to learn - but you make it easier by using framework and hiring devs for that framework. Not acceptable if you would have 20 of such teams and you would have to have UI/UX standardized.
• krapp 4y ago
  The problems that technologies like React, Typescript, NPM, etc. solve are mostly only relevant to startups and corporations needing to write business logic and correlate complex projects between teams. The point of front-end frameworks, for instance, is to reduce the roundtrip cost of requests and server-side code by compiling and rendering as much of the site as possible within the browser - an optimization that doesn't matter for most people, but matters when you're "web scale." Unfortunately, because the web is serious business, all of that complexity became the standard for the entire ecosystem. Just using HTML/CSS/JS is considered either regressive or niche. It's called "vanilla js" which only shows how utterly locked in to the enterprise paradigm javascript has become, when what should be the default needs its own genre identifier to differentiate it from "the norm."
  • an1sotropy 4y ago
    Interesting point that "vanilla js" is kind of judgemental, or at least framework-centric. Maybe we should start saying "pure js", or "sparkling, refreshing, clean js", or whatever companies that sell bottled water call it.
• bdcravens 4y ago
  Remember that once upon a time, there were options outside of Javascript for high interactivity, most prominently Flash. At the time there was no need for Javascript to be more complex. So harkening back to a "golden age" when Javascript was simple is only telling half of the story.
• nfw2 4y ago
  The thing I've found about working with React (and the web frameworks like Vue and Svelte), is that once you embrace a component-centered model, it makes virtually all web development easier, even relatively simple projects. There certainly is a decent subset of web development work where HTML/CSS/JS is still reasonable and viable, but it tends to be less complex, and low-code/no-code tools like Wix or Retool are quickly taking over that space.
  • edmcnulty101 4y ago
    Doesn't the browser now have native web components and this will replace React as time continues?
    • lelandfe 4y ago
      Ya, but you gotta roll your own process for the stuff React and co. provide easy methods to do. It's just a lot of boilerplate for small projects. I don't know if web components will really be a "library killer" in the same way browser APIs have done with jQuery. https://github.com/mdn/web-components-examples/blob/main/popup-info-box-web-component/main.js https://github.com/mdn/web-components-examples/blob/main/pop...
      • dbxkcichhdfufu 4y ago
    • Octoth0rpe 4y ago
      React is about a whole lot more than just web components. It's also a strategy for state management, life cycle, etc. I don't expect web components will ever replace react, but I think it's possible we'll see a new generation of react-like competitors that use web components under the hood.
      • collyw 4y ago
        > It's also a strategy for state management, life cycle, etc. As a backend dev who can do a bit of traditional style frontend, I fail to see the need for all this complexity. Most apps are running same database queries and displaying it on a webpage.
• treis 4y ago
  It's only relatively recent that you could write vanilla HTML/CSS/JS & have it work. There were inconsistencies across browsers and browser versions. Frameworks like Jquery came about to paper over those inconsistencies. It's similar for CSS with the added twist that it's a fair amount of work to get something non-hideous. Much better to start with something reasonably good looking and tweak from there.
• dageshi 4y ago
  They're the assembler of web dev, especially css. People move to the equivalent of higher level languages to escape the tedium of dealing with them.
  • lofaszvanitt 4y ago
    The tedium? The tedium is with React et al.
    • dageshi 4y ago
      I frankly think all front end is tedious to be honest. It doesn't matter what you use, it's fundamentally annoying to build in my opinion.
    • IceDane 4y ago
      Spoken like someone who has never built a non-trivial web application using vanilla JS or jQuery.
      • lofaszvanitt 4y ago
        lololololol... babyface, you are groping in the dark.
• pie_flavor 4y ago
  They make everything faster to develop and maintain. Same reason you'd use a framework for anything in any other language. When was the last time you saw a web server implemented with a HTTP-parsing library, instead of a framework for defining endpoints?
  • voidfunc 4y ago
    Go's vanilla HTTP server lib gets pretty close to being not much more than an HTTP parsing library. Some people pull in a routing library, but a lot of times its all done manually by processing off the incoming http.Request struct.
  • giaour 4y ago
    > When was the last time you saw a web server implemented with a HTTP-parsing library, instead of a framework for defining endpoints? This is not unheard of in languages that have an HTTP server and router built into the standard library (Go is the most prominent example here, but I've seen many node.js web services written w/o 3P frameworks). You could argue that the stdlib functionality is a framework, just not one that you need to install, but the same could be said of vanilla HTML/CSS/JS.
• wruza 4y ago
  Regular non-ui programming is different from ui one. In a regular straightforward program you apply a change and read it back only when it is needed. Even if that change is cached/computed/transformed/etc, there is only need to observe it when your program execution comes to that part. In a ui program after doing a change you have to somehow update all the relevant elements/controls that are currently visible on a screen, i.e. replicate the whole state of a program into a graphical context at once (regardless if html or not). This process has associated costs and is pretty error-prone if not addressed systemically. All these frameworks spin around some idea of optimization of it. Since it can't be done without tradeoffs, they invent new ways of thinking about a problem, offloading parts of it via methodological contracts to a developer, who pays their half of the price. Different developers have different opinions on how high the price should be and which trade-offs they should take. Is it worth it? Sometimes yes, sometimes not really. In my opinion, ideas behind some frameworks are useful by themselves, but in general all this tends to become more religious rather than technical. E.g. if you weigh what "cost" is or how error-prone the straightforward approach is, you may find that for some cases it doesn't really matter.
• avgDev 4y ago
  I am a solo dev. I wrote a complete warehouse management system. I wouldn't be able to accomplish this in a relatively short time frame without help of frameworks and libraries. Instead of using vanilla SQL queries I used LINQ. For UI, I used bootstrap, because it made it easy to handle desktop/mobile. For async calls I used old jquery because it worked well enough with .NET and was well documented. Additionally .NET allowed to scaffold models and identity. I can write a site in JS/HTML/CSS, however, why? I would rather do things quickly with proven frameworks. Size of websites is less of an issues these days. There may be use cases for going pure vanilla but often not the case from a business perspective.
• temp_account_32 4y ago
  Using pure HTML/JS/CSS is so unopinionated that it's very easy to create spaghetti, and hard to onboard new developers because you have to teach them a lot of 'this is how we do stuff here'. Don't get me wrong, it's perfectly possible to create spaghetti in React, but it just makes large codebases so much more manageable, and the tooling and ecosystem around it is massive. Typescript with React and a bundler, linter etc. is just an amazing developer experience, compared to the mess those of us who did front end development in the past remember.
  • tstrimple 4y ago
    I agree with this. It's especially important to use opinionated frameworks (Angular being more opinionated than React) when working with a lot of contract developers who rarely care about internal development culture or standards. With Angular, there are a lot of prescribed ways to accomplish common functionality which you could solve any number of ways in React or even more ways in vanilla JS. A cohesive and experienced development team can do amazing things with whatever tools and frameworks they decide to use, but less cohesive teams benefit from opinionated frameworks.
• cetinsert 4y ago
  People love getting themselves tangled in convoluted frameworks. --- We are building SyncHTML.io to counter that. Try at https://sy.ht https://sy.ht (press up/down arrows) See how we set ourselves apart https://efn.kr/b/sync#new-playground https://efn.kr/b/sync#new-playground --- Web standards are unbeatable when used right. They are not used right most of the time. --- See 2 custom elements done right™: (The /?s at the end is significant!) 1. zero-md: https://md.sy.ht/?s https://md.sy.ht/?s (just press up/down arrow keys) 2. WebPDF.pro: https://pdf.sy.ht https://pdf.sy.ht (view); https://pdf.sy.ht/?s https://pdf.sy.ht/?s (edit) (The WebPDF.pro elements are served from an unoptimized server. Takes a few seconds to load.)
  • foobarbecue 4y ago
    I tried these links and couldn't figure out what's going on. When I go to https://sy.ht https://sy.ht, I see a clock animation on the right and a blank editor on the left. I tried arrow keys and nothing happened. Got ERR_CONNECTION_RESET from https://efn.kr/b/sync#new-playground https://efn.kr/b/sync#new-playground What are you sharing? Is this a codepen-like thing?
    • cetinsert 4y ago
      Oh, thank you for reporting! Might have temporarily hit a limit (https://deno.com/deploy/docs/pricing-and-limits https://deno.com/deploy/docs/pricing-and-limits) with the link shorteners. This is what I am sharing: https://sy.ht/yt https://sy.ht/yt (YouTube video showing what this is about.)
• jamal-kumar 4y ago
  I like to build things in ways where I try and avoid the use of JavaScript if I can, using vanilla typescript for most things that do need that. I really like seeing what is possible in pure CSS for stuff like animations if I can completely avoid doing it in JS/TS while still looking fresh. The component based frameworks make a ton of sense for when your project gets large and worked on by a ton of people though. Personally for most small things I don't think you need them, and a lot of more novice developers really rely on ridiculously fat npm packages which impact site performance - often what I end up doing is finding alternatives in that ecosystem which are smaller and more well written, it's not all hot garbage but a ton of it is unnecessary bloat. Most of these frameworks are very similar and easy to adapt to once you have learned one or two of them but they definitely can lead to a website that weighs like 5 megabytes for no reason. I once inherited a project where the front end was split between like +20 different react projects across that many git repos which we really had to twist the arm of the original developer to get access to. That's definitely an example of doing it wrong.
• ranuzz 4y ago
  To build an application a framework was always a requirement. Developers either used an existing one or created their own. And I believe it is true for any application development, the code you see in tutorial or courses are not the same in a professional environment. Same goes for HTML/CSS/JS, in fact, CSS and JS are the answer to the limitation of HTML and static page serving which was the vanilla www. As for your question, I don’t see HTML/CSS/JS going anywhere, they are the building blocks of web development and are written as such.
• davidn20 4y ago
  If you don't understand the problem they are solving, you're still very green in the field. Try to implement a basic data bind input field and display the value in the DOM with react vs with just "vanilla js". You'll see the difference right away.
  • silent_cal 4y ago
    I already said I'm not even in the field - I just dabble in it. But thanks for your input.
    • davidn20 4y ago
      Sorry, I missed that part
  • julianlam 4y ago
    https://jsfiddle.net/craqvoxz/ https://jsfiddle.net/craqvoxz/ 3 mins... or were you looking for a server-side component as well?
• lofaszvanitt 4y ago
  You have to somehow employ more people and slow down corporate growth, so React was introduced, plus google idiocies like WEB VITALS... oh my friggin god, web development went full retard mode in the last 5 years.
  • cyral 4y ago
    Web vitals were created specifically to address the user experience issues often caused by slow JS websites: things jumping around as they are loading, things being unresponsive until some script initializes, etc. Using these metrics for search placement now incentivizes website owners to take them seriously and fix them.
    • lofaszvanitt 4y ago
      No, it's a layer to obfuscate things even further. It's a pseudo kinda job, bullshit job for future gen ppl. Even the simple pagespeed value was not respected by any Goog product, so why pushing it as a metric?
• giaour 4y ago
  The HTML/CSS/JS platform offered by modern browsers is very powerful and approachable, but the web's security model prevents most platform customizations. Browser-managed navigation, form submission, control appearance, etc, is largely a take-it-or-leave-it proposition. JS frameworks allow front-end developers to get around this limitation by rebuilding parts of the platform as a JavaScript application. For example, if you want to customize how navigation works on your page, you can either use the few, limited hooks offered by the browser (e.g., registering window.onunload callbacks), or you can make navigation an application concern by writing your site as a single-page app. There are plenty of things you just can't do with a framework-less multipage site (like animate transitions between pages) that are possible once you make navigation an application rather than platform concern. I can understand why many enterprise teams choose to use front-end frameworks like React even when it would arguably be faster and easier to just use vanilla JS, as there's a risk someone may need to add functionality that is not supported by the native web platform. For personal projects, though, I use vanilla JS and HTML.
• oneplane 4y ago
  It's because you can't scale up without modularisation and component re-use. This applies to pretty much anything. You can find this 'problem' in other languages, markup methods etc. all the same, for the same reasons.
  • silent_cal 4y ago
    Okay, but can't you do that with HTML/CSS/JS? You can save collections of JavaScript functions, CSS class definitions, and HTML templates pretty easily. Re-using them is just a matter of copying them over to a new directory.
    • joshstrange 4y ago
      > Re-using them is just a matter of copying them over to a new directory. And you lost me. Is it possible to write reusable JS/CSS/HTML? Yes but the overhead is very frustrating and you will quickly find yourself building a custom framework to manage everything. Best to start with a framework from the start if you plan on having rich interactions. The speed at which I can move in VueJS is nothing short of amazing and the amount of reuse I get is extremely high, all without me having to manually manage a bunch of files/includes. With 1 TS import I can get all the HTML/CSS/JS for a component and safely use it in another component. At a minimum that would take 3 http calls in "vanillaJS" to fetch the html/css/js that I would need to maintain and update myself. SFC's are a game changer. Sure the browser might eventually support what I need but by that point I have no doubt that VueJS (or similar) will have lept further ahead. It's the same reason I jumped on the 6to5/babel train early, it let me write my code in ES6 but still deploy to older browsers without waiting on everyone to upgrade.
      • silent_cal 4y ago
        Okay, so if I understand the main benefit is that you get to use a package manager and import statements? Also, don't you still need to manage tons of files, directories and config files in a React project? The React websites I've seen have way more complex directory structures than your average HTML/CSS/JS site.
• azeemh 4y ago
  I agree with your perspective on separation of concerns as that was the intent of the html5 standard. The reason react was invented was to enable real time update of items on the page -- to update when someone liked your item, or send you a notification update instantly instead of polling the server. It was the idea of pushing code to the webpage. So they made a component in javascript that updates in realtime -- the state or prop determining the content or how many likes the post had. However this ended up requiring a huge Redis instance which is also very expensive, so now they need to sell more ads. In order to figure this out they realize emojis on the like button allow people to choose a sentiment of their reaction to the content. Their ML uses the sentiment to group and sandwich ads between content the ML knows or thinks you will react favorably. So for example, a comedy central ad will be shown after a meme or story that is similar or something you reacted Haha to because the advertiser's desired reaction is a Haha as well. Thus the name React. Plus it makes that div/element/part of the page defined as a "component" in js that will update or "react" in realtime -- anytime they push an update to the server everyone viewing that page sees it change in realtime. Essentially a combination of a push notification or pubsub and ajax request. Honestly, when jsx goes out of style like it should because its idiotic, and gross, and a violation of those separations of concerns, it could just be an html page where you write a js function to add a realtime update to an id or class... Svelte uses that style of approach to the DOM. If you don't have a realtime data store like Redis or any type of realtime data streaming going on, React or any other component based framework is a waste of time. The ability to update the page without reloading or building as a single page app is not SEO friendly unless you use SSR which you already would have created in your normal seo friendly html files. also name your files consistently and clearly. unless you need to change the page in realtime without reloading, react and these other component frameworks have no use case. If you want a clean css3 framework to help build a web front end that works neatly in html5 check out Bulma. Bulma.io You are exactly right, the js developer scene is like a herd and people wanted to work at facebook or look smart so they learned it. It's useful for making single page applications, however all framework interactivity can be written in normal js, so if you take your time you'll have much cleaner, unbloated code, yielding pages that run better and faster...
• tzm 4y ago
  It's still there: http://vanilla-js.com/ http://vanilla-js.com/
• mamcx 4y ago
  > I don't understand what problem they're trying to solve Certainly, not building a website. MAYBE building certain kinds of apps, like a game or a paint app (see: most action is truly on the client-side). --- I found a simple stack that is super-productive & efficient: https://tailwindcss.com https://tailwindcss.com + https://htmx.org https://htmx.org. This is, IMHO, the best way to do "normal" websites, even the ones some are tempted to get nuts with stuff like React (eCommerce, blogs, chat app,...). The best is that it actually embrace the web as-is and not requiere anything to degrade correctly.
• ckz 4y ago
  These frameworks have emerged for historical reasons. There was a time when HTML/CSS/JS was much less capable and much more fiddly to use. Libraries and frameworks gradually evolved to both smooth the wrinkles and provide dev-workflow-oriented abstractions (components, etc.). They do, of course, add their own wrinkles, but at the time of adoption ostensibly the juice is worth the squeeze--at least for whatever real-world challenge a given team (or the broader dev culture) is facing at the time. --- I'll still use pure HTML/CSS/JS for client projects, depending on the context. Usually for static sites or interactive UI/UX prototypes, both in freelance and day-job (agency, bigcorp) contexts. So far, folks are very happy with the outcomes, but I do vet the fit first. :) In other contexts like enterprise/SaaS apps, Shopify builds, etc. I won't insist on no-JS or avoiding React/SPAs, as much as I'd secretly like to, but I will advocate for self-hosting and minimizing 3P JS dependencies where we're not necessarily gaining a huge increase in capability in exchange for dev convenience, etc. It's a balance.
• mejutoco 4y ago
  IIRC the email client https://www.hey.com/ https://www.hey.com/ and other 37signals projects use vanilla js. I did use Typescript without a framework to implement this ios calculator clone (https://getcalculator.app/ https://getcalculator.app/) and it was not a bad experience at all. I wrote about it here (https://mejuto.co/the-ipad-did-not-have-a-calculator-so-i-ported-the-ios-calculator/ https://mejuto.co/the-ipad-did-not-have-a-calculator-so-i-po...)
• spaghettiToy 4y ago
  I make little JavaScript stuff on my WordPress site, does that count? No react needed.
• deleted 4y ago
  [deleted]
• bcrosby95 4y ago
  Where these basic technologies really start to fall down is when your pages become increasingly dynamic. You start running into an issue where you have to define your structure multiple times: once in HTML, and at least once in JS since that's where you're dynamically updating things.
• yakkomajuri 4y ago
  The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. That's it - that's the problem they solve. People started writing vanilla HTML/CSS/JS and struggling to make "reactivity" (hence React) work well when web applications got complex with a lot of state to manage. So we started building frameworks on frameworks and abstractions on abstractions and ended up where we are today. It's gone a bit far but the overall purpose is a valid one. (From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website)
  • dbxkcichhdfufu 4y ago
    Browsers already managed state just fine. We just didn't like the way it looked.
    • have_faith 4y ago
      Browsers do nothing to help us manage state outside of individual elements.
      • hellcow 4y ago
        That’s actually all I use for state management. Elements pass data to children through attributes and bubble data up through events. It’s worked well for us on a complex front-end using native web components.
        • bornfreddy 4y ago
          That's basically a home-made React (& co.) duplicate (which is great). This simplifies development considerably, because you break the original problem into a) updating the state and b) translating the state into UI elements, and the framework (hopefully) automatically updates UI as needed.
        • have_faith 4y ago
          This is called prop drilling. It technically works for any size or complexity of app if you're willing to make every intermediate component have knowledge about every possible piece of state that might be wanted by a component lower in the tree. It's extremely cumbersome though.
• petilon 4y ago
  > What makes the trade-off of all that extra complexity and abstraction worth it? For most applications the extra complexity is not worth it. React started off as a simple library but now it has bloated with Redux and ReactRouter and Hooks and all that nonsense. You can do plain HTML/CSS/JS development for most projects. Here's an example: https://github.com/wisercoder/eureka https://github.com/wisercoder/eureka It uses a couple of 500-line libs, that's it. No complicated framework, and yet you will be more productive.
• romellem 4y ago
  For small sites, I always reach for vanilla rather than a framework. For example, [a super simple QR Code website][1] I made uses less than 100 lines of JS (minus the QR code library of course :)), plus regular HTML and CSS. Anything larger, however, and using a library just makes things easier: HTML partials and helpers, nesting in Sass, and data flow and component composition in JS frameworks are just easier when a project is large enough. [1]: https://github.com/romellem/easyqr-codes https://github.com/romellem/easyqr-codes
• TekMol 4y ago
  I build the frontend of all my projects with plain HTML/CSS/JS. Every time I talk to developers who use frontend frameworks, I challenge them and say: Let's sit down and build the same application. You build it with React or whatever, I build it with plain JS. Let's see which one is leaner and more logical. Every time the answer is the same: The benefit of a frontend framework will not become visible in a small app. Only in a big app. Then I ask: Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer. When I see React examples like this calculator ... https://github.com/ahfarmer/calculator https://github.com/ahfarmer/calculator ... which use 70 files (without dependencies!) to build something one could do in a single HTML file, I am afraid that those "big" apps the React proponents talk about will be very big when implemented with React.
  • confidantlake 4y ago
    Can you build Microsoft word or google maps or any of the 100s of other moderately complex web apps without a framework?
    • PaulDavisThe1st 4y ago
      parent has already essentially admitted that the answer is no. they asked "where is the cut-off?"
    • busymom0 4y ago
      Obviously not Microsoft word but I built my resume builder using vanilla JS, html and css: https://resumetopdf.com/ https://resumetopdf.com/
      • frumper 4y ago
        That's a nice looking project
    • wiredearp 4y ago
      The top complex component in Word is the text editor while the tricky component in Maps is the map. Neither of those can be made with the frameworks we're dealing with here, so that is a go. We can make the traditional UI with a simple view library like lit-html [1] and we'll want to keep some state around, but most state managers can be rigged to Vanilla. I'd totally prefer Web Components to any popular framework for the particular apps you suggest. [1] https://lit.dev/docs/libraries/standalone-templates/ https://lit.dev/docs/libraries/standalone-templates/
• jraph 4y ago
  Two things: - adding interactivity to a web page vs building an application. Those are not the same thing, and what you read applies to the first - there's a widely accepted belief that vanilla js is not suitable for building apps. I don't buy into this belief. I have a built networked Scrabble game with vanilla js. Both the backend and the frontend. This simplicity allowed external contributors not well-versed in the modern web stack to contribute. I also was able to enter the code of Pianojacq (from jacquesm) [1] and contribute quite easily because he also chose vanilla js. This simplicity is very valuable, and lost with modern framework, and nobody is really concerned about this. I've done some React development, so I know my way in a modern app. I've also contributed to a frontend written in Vue. I think they solve problems but bring complexity to the table, in particular the tooling (bundlers, minifiers, etc), the dependencies and the debugging being much harder. It seems DOM manipulation through native browser API scares many people, but when it's what you are familiar with, your usual "framework", it's manageable. You need to be disciplined to avoid things getting messy (a discipline frameworks partially enforce), but I really believe you can go far with vanilla js. I believe React & Co are often picked to ease beginners' contributions, but they actually do require expertise. I'd rather touch vanilla js code from a beginner or an experienced developer than a React code from a beginner. It's a matter of taste. Vanilla JS has the taste of fresh air to me. It's zen. You write the code and it runs. No tools, no slow compilation, no minification that complicates the debugging. Minification which is only useful because with those frameworks you bundle an awful quantity of code in the first place. Yes, source maps exists but they don't do everything. But today you won't have access to the whole ecosystem of existing React components with vanilla JS. It might be a curse or a benediction. [1] https://gitlab.com/jmattheij/pianojacq https://gitlab.com/jmattheij/pianojacq
• fullstackchris 4y ago
  How are you going to manage interantionalization, testing, sessions, etc. with just these tools? (In before people say, "but that's all I need for my blog!" Fine. go ahead and do that then. I'm talking about international huge scale applications) What you'll do if you stay the purist and need to implement aformentioned services is that you'll eventually end up with some sort of quasi-framework, but bad in the sense that only you (or perhaps your team) know how it 'works'. With most frameworks there are at least opinionated ways to go about implementing all these things, and you can find other teams and consultants who speak this 'language' so to speak. Being a purist is fine, but it really grinds my gears when people assume vanilla is ALWAYS the solution, and it can 'easily' be applied to things like e commerce shops, huge shared tools, or big social apps. Hint: it can't, unless you like a lot of pain.
• awb 4y ago
  The same reason frameworks are popular in any language: convention over configuration. In a native lang there is are near infinite choices to make in implementing a solution and no two developer’s native code typically looks the same. Jumping into a vanilla JS codebase can sometimes take more time because you have to discover and understand the choices the developer made. The code is highly configurable but lacks a common convention. With a framework, some of those choices have been made for you. So, jumping into a framework codebase is sometimes easier and simpler for those that understand the framework. The code adheres to a public convention at the expense of being less configurable.
• tkpremier 4y ago
  This isn't a one-or-the-other situation. A web developer should and would choose the right path depending on the scope of the website. Mainly, is it a web page or a web app? If it's a landing page or even a blog, i'd say vanilla HTML/CSS/JS is just fine. It's when you get to data manipulation, state manipulation, and user interaction that React is very helpful... Same with BackboneJS and Angulars of the past, and if society has taught us anything, it's that there always be a NEW and IMPROVED one-framework-to-rule-all the other frameworks. Also, the state of JS in browsers are way more "consistent" than the IE wild west of the 90's and 00's, which was why jQuery was so popular. And that began our dependency on plugins to provide consistent dev codebase in between browsers. So if you REALLY think about it, it's the browser vendors' fault for why "vanilla" HTML/CSS/JS seems to have so much tooling. In the end...figure out what you're trying to build, and know that if it gets too complicated in straight up HTML/CSS/JS, there's plenty of frameworks to help you organized.
• vagrantJin 4y ago
  They are being used. Its just that frontend is a moshpit. Everyone wants more overhead and complexity, mostly to justify the high salaries.
  • nfRfqX5n 4y ago
    Nobody wants more overhead or complexity. Users expect complicated features as a baseline experience.
    • vagrantJin 4y ago
      Ofcourse. It's the users fault.
• jtolmar 4y ago
  There's a few parts to it. javascript used to be awful. Using JQuery was more or less required to have a decent API and not have your entire app full of polyfills. Those days are behind us, but the precedent remains. Some javascript APIs are still pretty bad. Fetch and XMLHttpRequest are both really warty in their own ways, to the point where you're probably writing a wrapper function. Common-enough collection operations are missing, you'll need to write some sort of utils file. So you're definitely going to want at least some sort of small library for the missing stuff. The DOM forms a parallel, persistent tree to your application state, and you need to manage the relationship between that and your app. Parallel state trees just always suck (I've also dealt with them in Box2D, some game engines, SVG renderers...), it's probably an antipattern. It's not that big of a deal for a small app, but for larger ones it starts getting hairy. And it certainly feels like you should be able to write a better API easily enough, but because the problem is that the entire DOM is based on a parallel state tree model, your wrapper library ends up getting large before you know it. There are good technical reasons to use some sort of build system for your web content. Concatenating and minifying all your javascript helps a ton. But to do a really good job of minifying you basically need a whole compiler, and at that point you might start pulling in all sorts of clever transformations that seem like a good idea.
  • PaulDavisThe1st 4y ago
    > Parallel state trees just always suck (I've also dealt with them in Box2D, some game engines, SVG renderers...), it's probably an antipattern. Just to reinforce this ... this is the case even with native desktop GUI toolkits. Take the example of GTK. You build a model for a tree/list view using the "nice" data types GTK provides. In Gtkmm (the C++ bindings) it's even easier and actually feels very idiomatic. However, if you already have a model data structure somewhere in your code for other reasons (for example, your "backend" code isn't allowed to use GUI toolkit objects or APIs), you now have parallel state trees, and they suck just as much here as anywhere else.
• AngeloAnolin 4y ago
  I think the reality that there's little (to none at all) job posting which would only require application development in vanilla CSS/JS/HTML is the main reason why frameworks dominate the land. While I see the value of using vanilla stuff, the complexity of software requirements, ever evolving browser APIs and features and increasing ease of using libraries (i.e. date-fns, lodash, etc.) has definitely increased the appeal of frameworks.
• jjcm 4y ago
  FWIW, I chose to make my side project I've been working on for the last couple years an entirely vanilla js SPA. The biggest downside I've noticed vs using something like React is my speed of development is much slower. The upside though is the code itself is extremely efficient / packages sizes are small. For my own project this is great - I have no deadlines, and half of the process is me just enjoying writing the code. For an existing company the demands are different. Not only are there time pressures, but aligning on something like React means you're introducing convention into the code. Hiring people who already know this convention is easy. Vanilla js, even with webcomponents, just isn't quite there as far as convention and speed go, and there isn't a rich community around it. Is it perfectly able to do the task at hand? Absolutely, but at a price most companies aren't willing to pay. React is the easier of the two.
• solumos 4y ago
  Vanilla html/css/js are great for static sites, but once you start building an application it gets more difficult to manage state: both on the page, and with the backend that stores user data. What you're saying is similar to saying "I don't understand why someone would use Django, can't I just use the python http.server for an API and psycopg to connect to postgres?" The answer is yes, you can do that, but over time you'll find that there are pitfalls with a bare-bones approach that are easily avoided by using higher-level frameworks. Mostly the spaghetti that someone else mentioned, but also getting caught up in technical details that the frameworks have mostly already abstracted away.
  • neon_electro 4y ago
    The trouble is that even with good definitions for "web site" and "web app" (the distinction clearly matters, right?), non-developers always want their web sites to be more interactive, to the point that using React somewhere you shouldn't feels like the "easiest" choice. I hate this.
• deleted 4y ago
  [deleted]
• sysadm1n 4y ago
  Honestly, I'm turned off by these frameworks. Javascript is an easy language, and these frameworks raise the bar to entry. Many will say they make things 'easier' but that's not my personal experience. Some context: I wrote a lot of JS in the early/late 2000s (Anyone remember WebFX by Erik Arvidsson?). His follow-up gig became WebOS[0] Back then it was called DHTML or Dynamic HTML and then evolved into the HTML5 standard later on. The syntax of React & Vue is just too weird for me. Frankly I've reached a framework fatigue after learning jQuery inside out which was a hard-won battle, and then having to learn React/Vue/Svelte just to stay 'in the game' is too much for me. Excuse me if I'm biased here. [0] https://newmedia.fandom.com/wiki/Web_Operating_System https://newmedia.fandom.com/wiki/Web_Operating_System
  • tkpremier 4y ago
    I hear you...another level is that building javascript files has gotten so obfuscated with build processes such as webpack, babel, and typescript, that it adds a layer of confusion just to output code that you know is valid code, but all these darn build processes may give you problems under the hood....then you gotta research all that nonsense and find that some packages weren't updated. THAT is the fatigue part to me. I don't really mind learning new frameworks, cuz let's be honest, most of them are all doing CRUD operations and repainting the browser with new html. However, under the hood stuff that potentially arises with misaligned, packages, or configs...ughhhhh
    • wruza 4y ago
      Webpack specialist became a position recently. I miss these good times when you could simply %.o: %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< and feel great for the rest of the day.
      • tkpremier 4y ago
        Hahah, I'm not surprised. Them config files have created a niche FE DevOps Specialist role. To be fair, while the hours of painful medium articles and gists research, the knowledge gained has given me a better understanding of Webpack, and I do feel more confident when taking on various tutorials which all have different approaches to fit the config to my needs. But still, as a newcomer to JS or someone in OP's position, the build game is certainly a lot more complicated than your command! ....btw, I have no idea what your command does/says :D. Linux (Ubuntu) CLI syntax has been something I've tried to improve on over the years.
• typingcyclist 4y ago
  Depending on what you want to build and how many people will contribute, the answer might vary. HTML/CSS/JS can be enough, but mostly you will need to handle streamlining browser differences etc. explicitly. Frameworks are popular because they can help to streamline these issues. Also there is mostly an eco-system built around these frameworks, so you don't have to build every component from scratch for example. From a business perspective it's easier to say we're hiring for this specific framework (React, Vue etc). vs. we have our own rules and styles. Finally these frameworks also have a social function. It's like a style or taste preference, where a group shares the same preferences.
• chrisweekly 4y ago
  Great question. I'm short on time (and using my phone to comment) but TLDR, there's a spectrum from (A) "SPA by default" and piling on layers of abstractions to (B) properly leveraging the web as a platform, and mentoring the browser instead of micromanaging it ...and the trend is finally starting to move (back) towards (B). There's also a significant role played by the "document-based web" vs "web applications" paradigms' semi-dichotomy. You'll see plenty of (frankly sophomoric) takes like "webdevs are rediscovering that server-rendering HTML is a good idea, LOL, sounds like PHP or my cgi-bin Perl scripts from 1999" -- which ignore the need for client-side interactivity and responsiveness and the profound changes in the capabilities of clients, networks, servers, languages, and tooling over the intervening years. I highly recommend a close look at https://Remix.run https://Remix.run and https://every-layout.dev https://every-layout.dev (and probably https://Astro.build https://Astro.build) for examples of frameworks and techniques that thoughtfully leverage the best of what's new as it continues to evolve, while being firmly grounded in from-first-principles foundations that enable creation of magic comprised of sane primitives. I've been building and improving web-related sites and apps for a living since 1998, and without reservation urge anyone involved in webdev to read up on both Remix and EL's "axiomatic CSS". They provide a profoundly well-informed and -reasoned perspective that answer your question and help show the way forward amid all the froth and churn and nonsense. It's the signal in the noise.
• superkuh 4y ago
  It still exists and it is the best form of website. The UK National Health System (NHS) use it extensively for their health infrastructure and it supports all devices intrinsically. This was a huge boon during the earlier pandemic where many other government websites were having to roll back their advanced features and re-enable older protocols to cover all citizens. Corporations generally can ignore the majority of people and only concentrate on their target market. If their target market can be coerced into using SPA and other application based weapon design then that's easier and cheaper for teams of paid developers to do. If only because most modern web devs are trained to make such JS applications. But everyone else, individual humans, institutions, governments, they should try to make their websites accessible to all. It's a shame that few are.
  • frosted-flakes 4y ago
    Why do you think JS frameworks can't be used to create accessible websites?
    • superkuh 4y ago
      There's this assumption by for profit business that all people will have modern software with modern JS support. They're wrong and the tools they use to measure such things are implemented in a way they won't ever know they're wrong. What JS is in terms of what features are used to write those frontends changes far faster than the software that resides on a great many people's computers.
• kgwxd 4y ago
  Every time I've started a new vanilla project, it's not long before I figure out I need a lot of stuff that's already been done better in a framework. It's usually about the time I start writing a helper function to build up dynamic DOM elements.
  • jeanmayer 4y ago
    This. Also, these frameworks increase our productivity significantly
• deleted 4y ago
  [deleted]
• bullen 4y ago
  I built my multiplayer web client with vanilla: http://fuse.rupy.se http://fuse.rupy.se There is nothing like being on the lowest common denominator, but you can understand why browsers are not evolving past this point.
• JimmieMcnulty 4y ago
  I find myself missing React when building a plain HTML/CSS/JS site. I just like the modularity and my fingers have muscle memory for solving certain issues.
  • julianlam 4y ago
    From somebody who's been in the industry for a little bit (only 10+ years, which depending on your perspective could be no time at all, or a lifetime!), I'd be wary of becoming too familiar with the "react way" (substitute your framework of choice.) Aeons ago I learned js with Mootools, so much so I thought in Mootools vernacular. Imagine my surprise when Mootools went away seemingly overnight and I couldn't code vanilla js to save my life.
    • JimmieMcnulty 4y ago
      Fair! I'm pretty confident in my ability to pick up new tools and tech (I'm probably too far into the "bleeding edge" side of the "how comfortable are you supporting new tech in prod?" scale), so I'm not overly worried about getting left behind. I just recently had to explicitly build a "raw" JS/HTML/CSS app for work, and found myself missing the organization React overlayed on top of JS, is all. Besides, my bread and butter is backend, so I can always throw my hands up and shove the work onto some web dev's plate if I ever do get left behind! :D
• towaway15463 4y ago
  The web is now a virtual machine combined with a content delivery service and “web dev” companies are actually just building software that runs on it. If this were 1994 all of these companies would be shipping disks in boxes instead.
• spapas82 4y ago
  Still going strong, I do it exclusively every day, maybe with a little splash of jQuery when needed!
• asadkn 4y ago
  I'd say that most of the websites still use HTML/CSS/JS and are server-side rendered - well, at least 40%+ of the web does (WordPress). The distinction mainly is in the apps. Yes, web apps almost always use a framework like React now. Others have already explained the whys. However, it's still possible to do webapps the traditional way, with the server-side approach, adding only a little interactivity via JS - techs like LiveView and HotWire: https://hotwired.dev/ https://hotwired.dev/
• seydor 4y ago
  A bunch of people started overcomplicating things in order to impress their peers so they will hire them to BigShinyCorp Inc. Things went on for 15 years and ended up with an abomination in which everything has 53 levels of virtual machines behind it. Because i guess virtual machiens are fun. Yes they are perfectly fine, dont waste your time
• manv1 4y ago
  The fundamental problem is that HTML is technically stateless but a web app is not. So to do anything that needs state (think google maps, or a responsive website) you need to either build or buy a way to manage that state, while working inside the confines of HTML/HTTP. In many ways you can look at react, vue, etc as javascript applications that use HTML/DOM to render. The problem is that they don't really see themselves like that, so the way they present stuff is sort of fucked up. And even after all these years the DOM handling stuff hasn't adjusted to the reality of web 2.0...because presumably the devs want to keep backward compatibility with hand-written css/html/js. The DOM is another one of those hacky things that survived and thrived. If browser makers, the standards people, framework makers, and web devs got together, they could theoretically simplify a lot of this shit going forwards, but they don't because it's too hard. Instead, we have these sort of layers of bullshit that live forever.
• bob1029 4y ago
  We do 100% vanilla web development for our B2B product now. Our roadmap went something like: (Client Authoritative State) Angular 2.x/??? => RiotJS/Bootstrap => (Server Authoritative State) Blazor/Bootstrap => Custom/Vanilla The Angular and Riot apps were a nightmare to maintain long-term. We sign contracts with our customers that are 5+ years long, so having autonomy over this sort of stuff is critical. The rate of change with these frameworks was too much to deal with, especially at our scale of <10 employees.The big solve moving to Blazor from RiotJS was keeping the state on the server and being able to reuse existing C# codebase to manage UI. This continues to be very productive for us. Server-authoritative state is the answer for keeping complex UIs on rails. We still have quite a few interfaces on top of Blazor, but those aren't really a pain point for us (at least until Microsoft does what they usually do in a few major versions...). The biggest catalyst for moving from Blazor/Bootstrap to Vanilla was 2-fold: On one hand, the power of modern web APIs, such as CSS Grid, eliminates a large reason why you need a 3rd party layout system in the first place. On the other, we realized that dynamically updating the DOM using a 2-way web socket setup is actually not that complicated or scary, assuming you have well-scoped requirements and aren't afraid of javascript. For hand-rolled vanilla, the way we sync the DOM is with a simple 2-way web socket protocol where the server has a dictionary of elements per active client, and hashes of state are used to detect required updates after client events are processed. No shadow DOM or any of that crap. We just blow it all out and redraw on update. None of our UIs has enough elements to justify all that extra complexity right now. We could easily iterate into several directions if we needed to over time. The key point is that we understand 100% of our stack. Every line of code makes sense to us. At no point do we have to worry about someone pulling support or shifting their framework in an adverse direction. Finally, we also have major security concerns with vendoring out anything, since our product is used - in part - for in-branch banking. The hottest PII you can imagine flows through our web app every day. Being able to tell various CTOs that there is no supply chain risk with our web UI is a very fun hat trick for me.
  • P5fRxh5kUvp2th 4y ago
    I have a mini-rant about that. When a company decides to use Angular (for example), they're also deciding to jump on the rat-wheel that is constant upgrades to the next version. Meanwhile, that vanilla app will just keep working in perpetuity.
• deleted 4y ago
  [deleted]
• Ambolia 4y ago
  Pure HTML/CSS/Js either devolves into spaguetti code very fast, or requires you to put very hard conventions to avoid it. Component Frameworks give you more structure that organize the projects in more sane ways.
• jppope 4y ago
  I actually have to disagree a little bit... The rise of static site generators have filled a void there of where you can have reuse but you don't need to head off into framework land. I do a lot of projects now (using SSGs) where most of the work is plain jane html/css/js
• fabfabfab 4y ago
  Grug develop doctor's appointment website, grug use jQuery + Flask/Django. Grug try develop Notion or Google Sheets competitor, grug use React/Vue framework.
• ilaksh 4y ago
  For my own startups that I work on as a solo developer over the last few years, everything is currently in vanilla JS and CSS. I have been programming for decades and used many different component systems on the web and desktop, such as React, Angular, Vue, WPF, wxWidgets, some more that I dont remember. For projects involving several designers and developers, some kind of component model might be necessary to be able to easily reuse and integrate code. Also designers or backend programmers may not factor in the complexity of certain design or architectural decisions such as state changes that are supposed to cascade to other items on the page. Since I am controlling all of those decisions, I can for example simplify so that either only state relevant to one small element is updated, or an entire tab panel is re-rendered. And then can ensure there is time to optimize the panel rendering. With that amount of control, usually the extra cognitive load for the component system etc. seems to not be worthwhile. But for example many years ago I had a complex web front end given to me on a shoestring budget, with subpanels etc. supposedly automatically reflecting every other type of state change that occurred. He insisted that I use a plain version of something called Knockout.js which did not have facilities for tracking and updating based on so many dependent state changes. Then he kept adding more and more panels and components, with more cascading or interacting state changes that caused bugs when I tried to manually keep them up to date. So that was kind of a "setup" in terms of the architecture required of me by the contract and the design decisions and there were lots of bugs and was especially rough to do in a small time frame. At the time things like React and related state management did not exist or were not known to the client, who thought he knew better about architectural decisions anyway and so that wasn't something I had room to negotiate or in the budget to research. You either need a good concept for handling all of these potentially interacting state changes such as what happens with component and state flow systems, or you do what I do. The whole design avoids it where possible, and when necessary I set it up so I can just re-render that whole section, making design decisions to avoid something causing annoying latency or other problems. It's a lot easier for me to do this stuff as a solo developer where I have end to end control. Also one thing that has changed in the last several years I think is that Firefox and Chrome have gotten significantly faster at re-rendering HTML through various optimizations. So actually some teams may want to reevaluate complex state or component frameworks to see if they might be overkill.
• replwoacause 4y ago
  What is the easiest way for someone with HTML, CSS, and Ruby programming skills to add JS interactivity to a site? Would that be something like HTMX?
• umvi 4y ago
  IMO for things like static sites, or sites that only have some landing pages and a bit limited interactivity behind a login portal, vanilla HTML/CSS/JS is perfectly fine. The complexity of vanilla gets out of hand when developing web applications (websites that feature menus and tools and widgets and state that the user interacts with - think JIRA or Gmail or Google Docs, etc)
• gwbas1c 4y ago
  One thing to point out: "web," as a UI platform, is very weird compared to Windows/Mac/iOS/Android. These frameworks bring in concepts that we take for granted in most other platforms. More specifically: When I "do web," I prefer generating HTML on the server. Working with text that way is very simple, but the paradigm breaks down when the page needs to update itself from Javascript. Javascript+html+css alone isn't nearly as powerful as the kind of UI tooling that I'm used to for Windows/Mac/iOS/Android. That's where the frameworks come in. The reason why they change so much is that so far, no one's really come up with a good one. I personally think we'll get there if we can replace HTML, because that's the real obstacle. For representing a document; it's really cool, but for doing true UI, HTML just makes everything over complicated.
• deleted 4y ago
  [deleted]
• IYasha 4y ago
  Yeah, things got messy, laggy and sad. Because there are no longer "sites" - there are "apps". Because why spend money on expensive servers while we can run JS garbage on client side? Because why our corp has this boring page? We need something more splashy-flashy than our rivals have! Because why keep old bugged codebase? Let's write a framework! Because can I haz animated website with no skillz? I heard I only need a few clicks with some "frameworks"...
• sebringj 4y ago
  Some of the better ones do most of the thinking for you in a clever and minimal way and seem to reset the status quo of giant dependency trees that take a long time to install and update and deploy (relatively to your scenario). deno fresh for example is a reset coupled with deno deploy. Its better to not have to worry about manually updating the dom and think of updating state instead just like updating a variable ideally. As long as it gets out of your way and speeds up results, it is a win IMO. It gets even better when its a super fast deployment baked in. Not fun to FTP as I remember long time back. FYI coming from simple user-land and I do think things are getting better when those resets happen, not worse.
• shadowgovt 4y ago
  It's easy, I think, to forget how bad the basic HTML / CSS / JS behavior is from a modern aesthetics standpoint. So I'm currently maintaining a totally static blog I build in Hugo. It's almost nothing but plaintext, one static CSS file, and some images. One time in a hundred, when I select a new story, the lightly-shaded background of the page blanks through white because loading a couple resources takes too long. For my personal blog, for fun? That's fine. For most corporate sites? Unacceptable. Looks unprofessional. This is 2022; we're not using teletypes and command-lines anymore where the user can feel the individual bytes coming over the wire. So to prevent just that one visual hiccup, I'd need to do dynamic fetching of page content and a hollow-and-replace of the content div instead of reloading the entire page when the user navigates around, but I also need to support direct navigation to the page loading the full page content, and I need to do this all correctly from Google et. al's point of view so search crawling doesn't break. And at that point? I'm definitely using a framework (probably with both client and server-side components). All because the aesthetic of the end-user has evolved and your page looks unprofessional if it navigates like a traditional '90s-era page.
  • umvi 4y ago
    > It's almost nothing but plaintext, one static CSS file, and some images. One time in a hundred, when I select a new story, the lightly-shaded background of the page blanks through white because loading a couple resources takes too long. That doesn't sound right to me. Why isn't the "one static CSS file" cached? It should load instantly because it's already in your browser and doesn't need to fetch anything. I've created/maintained static sites as well and I've never run into this visual hiccup you are describing.
    • shadowgovt 4y ago
      Excellent point. Upon further investigation, I suspect what I was seeing was that Chrome with the Inspector open was evicting cache aggressively. Closed it up and no longer saw this issue. Definitely worth remembering for the future that the render loop is more complicated than I assumed!
  • redeeman 4y ago
• lhorie 4y ago
  Disclaimer: I'm the author of one of the frameworks mentioned in this thread. Yes, HTML/CSS/JS are perfectly fine tools for web development. But just like it's not as efficient to use a hammer as a nail gun, using HTML/CSS/JS alone might not be the best choice if you're trying to build something highly interactive or if you have other concerns (e.g. a very large team that consistently steps on each others' toes on accident). I'd encourage that you try to actually take HTML/CSS/JS as far as you can take them, if nothing else to experience the pain points of using them at high levels of complexity yourself. This can give you an appreciation for why frameworks do things the way they do. For example, routers are patterns that every framework dealing w/ parameterized pages eventually lands on because it's a pattern that makes it easier to manage page parameterization. It can be argued that some frameworks land on seemingly strange or overly complicated APIs sometimes, but that's just the realities of engineering. We try to make the best decisions with the known information at the time, and then we have to consider maintenance costs after the fact. Nobody is perfect and sometimes we only see flaws in an approach through hindsight. There's also such a thing as using the wrong tool for the job. Frameworks usually have scope and an idiomatic way of being used. These indicates which use cases the frameworks are strong for, and which aren't. Most self-respecting frameworks will have some sort of tutorial that you can follow to get a feel for what type of tasks they are trying to optimize for. Try them out to see if that's what you need. If it's not, that's ok, there are plenty of other tools that could fit the bill better. My recommendation would be to try different "categories" of frameworks. For example, React/Vue/Svelte are very similar in scope, so trying one should give you an idea of what all three are more or less all about. You could try htmx, or GWT or even jQuery to experience completely different flavors of "framework-ness", maybe one of those will "click" better. Maybe you'll find that vanilla HTML/CSS/JS is all you need after all, and that's ok too.
• IYasha 4y ago
  You also forgot to mention Flash :) It was starting to solve all the problems: from design to inveractivity. But then Adobe.
• francisofascii 4y ago
  I recently started two small web projects (one personal, one work) using ViteJs, Html, Vanilla Typescript, CSS, and a .Net Core Web API. It has been a great dev experience compared to React and Angular, IMHO. Of course I have this sense of guilt that I should be using a framework. And if these web apps were to suddenly explode with unexpected screens and features, then it would get complex. But right now, it is a fast and pleasurable development experience.
• txdm 4y ago
  In my experience, just having the ability to "modularize" the common elements on pages of a site (navbar and footer, for example) is the biggest task for most simple websites. There are lots of frameworks out there that do this, at the expense of making everything else on the website "html with extra steps". React comes close to solving this, but there's not a "react lite" that does it more elegantly that I know of.
• deleted 4y ago
  [deleted]
• novoreorx 4y ago
  I always love vanilla HTML/CSS/JavaScript, here's a site I made recently, using Vite as the development tool, and SCSS as the preprocessor, no JavaScript involved. https://cht-colors.pages.dev/ https://cht-colors.pages.dev/
• reducesuffering 4y ago
  I notice that the distribution is heavily skewed where the HTML/CSS/JS camp is using it for their blog or 1-person project and has been doing it like this for a decade, where the React/framework camp are the people who have done both and are working on large projects. The basics of React are learned by 1-month novice programmers in 2022. You don't even need a build system (which is even setup for you with Next or create-react-app). At it's core, it's just a file which contains "super"-html that you can update state more easily.
• deleted 4y ago
  [deleted]
• oxff 4y ago
  I'd say 80% marketing and "monkey see, monkey do" effect.
• unity1001 4y ago
  I blame Facebook/Twitter/Social for this. With their rise in mid 2000s, having a framework with which you could manipulate the entire dom real-time to reflect the state in the backend have been accepted as obligatory. Whereas in reality, aside from the neat templating that frameworks like React bring to the frontend, there is absolutely no need for the majority of web applications to be able to send micro updates to the client like how it is obligatory for social networks or other apps that are heavy in user interaction. The least thing that you would want to do when a user is going through an ecommerce checkout process is to manipulate the dom and change stuff that could distract the user from the checkout process, for example. If you need to update some info with the changing quantities in the cart or address, that could as well be done with simpler stuff like jQuery - considering that your site does not have such features that will cause your jQuery to bloat. There is even less need in the majority of the web where only content is consumed - how much interactivity do you need for a news article at the guardian or even your local-news blog? The user will just want to read the article. He or she may not even bother to comment (and likely wont), and when they comment, you definitely don't need a full fledged framework manipulating the dom to post and refresh the comments section. HTML and the browser already sort that out. ... The overall idea is sound, yes. A better form of presenting and manipulating the dom is a good thing. But, the bloated frameworks and the dependency hell that we created for ourselves do not look like the way to do it.
• have_faith 4y ago
  > I don't understand what problem they're trying to solve Building highly stateful / interactive web apps. If your web app is sufficiently complex enough then your vanilla js solution will just become an undocumented framework in disguise. When you build a homegrown system that manages components and their lifecycles (reacting to state changes) then you've written a framework that no one else has experience or knowledge of. > What makes the trade-off of all that extra complexity and abstraction worth it? Interactive UI's that react to state changes are hard to manually manage as complexity increases. Your UI and state are connected by an undocumented large state machine. These frameworks essentially allow you to define how your state, in any shape it may take, should be reflected in the UI (DOM). > Aren't HTML/CSS/JS perfectly fine and time-tested tools for web development on their own? Sure, but all of the frameworks are written in JS and you write plain JS to use them. You might use something like JSX or TypeScript for convenience, but these are turned into plain JS. They're also not required, they've just become standard because of how convenient they are.
• telman17 4y ago
  When you went through the Odin Project, did you do all the modules? Asking because there's a huge chapter on React that the vanilla JS course helps prepare you for. (To answer your question though - HTML, CSS, and JS are absolutely valid ways to go on a simple website that doesn't require a lot of interactivity. You use the tools you have in situations that benefit from them)
• paxys 4y ago
  Every non-trivial web application that starts of writing "vanilla" code will eventually evolve into something resembling React, Angular, Vue or whatever else, just with a lot less thought and resourcing put into it. So unless you truly want to build a mostly static web page with HTML content and minor styling it makes sense to just start off with one of them and prevent a painful migration down the line when your dev velocity has slowed down to a crawl because of the complexities of the codebase.
• r3trohack3r 4y ago
  There are two forms of "the web" There is the document web - in which HTML/CSS/JS is more than sufficient. Somewhere between Web 1.0 and Web 2.0 we started experimenting with delivering application experiences to a web browser - arguably an abuse of the document web. This is the application web and it is a distinct use case. HTML, CSS, and JS on their own provide a pretty poor application development experience. At the very least, building a full application in HTML/CSS/JS is non-trivial. Rewind 10 years and many of the tools we take for granted on the backend were missing from web development, notably composability and dependency management. Scaling UI work up to teams of dozens of engineers is difficult. Companies with multiple UIs have a hard time re-using code between those UIs. Tools like React, Storybook, npm, and Webpack are addressing that gap. If you don't use them, given sufficient time and growth, you'll end up with your own patterns trying to address similar gaps in your code base. Arguably the industry took a pretty windy and awkward path to "on-demand sandboxed applications delivered over the wire," but that's just what happens with incremental development I guess. We started with a web browser and the document web, abused it to deliver some interactive applications, found it was "good enough," and then pushed it as far as it could go. We ended up at a local optimum. There are likely other optimums out there.
• Sujeto 4y ago
  I use vanilla html/css/js exclusively. I made some helper functions to manipulate DOM. I do everything manually, including saving state. And it works just fine. I find React and others confusing.
• mkl95 4y ago
  Abstraction. If you use HTML/CSS/JS to solve some problem there is a high chance you are reinventing some package that's freely available via npm or Yarn. Even a leaky abstraction can be better than reinventing the wheel.
• miragecraft 4y ago
  It's still here, just no longer profitable. Frameworks are needed for web apps, especially single page applications (SPAs), if you just want to build traditional page/document based sites the traditional methods work just fine. However SPAs is where the money's at for developers, so developers tend to abuse it due to resume-driven development (RDD) in order to get themselves into better paying positions/companies. That's why tutorials and articles are all about frameworks now, just follow the money.
  • theihor 4y ago
    > resume-driven development (RDD) I love this phrase. Going to steal it. Thank you.
• mrzimmerman 4y ago
  I don’t see anyone specifically talking about CSS, but that is something I still generally just write without any libraries or tools. I do use SASS at times because I like the nesting, but I don’t always bother. In my 20 years working on the web I’ve found that a lot of styling libraries and tools like Bootstrap and Tailwind are great for getting off the ground quickly with a passable UI, and there are benefits for large teams to have a shared syntax and coding style that is well documented which these provide out of the box. But when it comes to overrides and general customization they can lead to people writing exotic selectors and using !important. People often get frustrated with CSS, especially when the page loads and things start to interact. I’ve always found that less is more with styling and I’ve fixed more problems in my career by removing and simplifying style declarations. CSS with variables, (and soon native nesting of selectors), animations, pseudo classes, and pseudo elements is quite powerful on its own. As long as there’s internal documentation for code styles and encapsulation of classes to components (even outside of a JS framework/library) its very scalable.
  • tkpremier 4y ago
    Interesting. I love using SCSS, and personally won't write CSS without it. It's also not just for nesting but also for variables, mixins, and extend functions. SCSS, to me, has made css become more of programming rather than just markup rules, allowing OOP prototypal concept via mixins. Absolutely agree re: depending on Bootstrap. Unless you're heavily leveraged in BS (no pun intended) either cuz 1) you're at an "early" phase in your product or 2) you've bought into yet another framework and are stuck with it :), you should start creating your own scss mixins to encapsulate these components. My personal fave is to use scss w/ bem. The naming conventions coupled with nesting selectors also help real well to create long class names without having to type it all at one time
• Aperocky 4y ago
  Self promoting plug: It still works fairly well on the relatively small scale if you just want to write a frontend app (i.e. simulations): https://aperocky.com/cellular-automata https://aperocky.com/cellular-automata https://prehistoric.tech https://prehistoric.tech
  • softcactus 4y ago
    Wow that cellular automata sandbox is almost identical to something I wrote a while back! You might find this article interesting for running arbitrary code in a browser sandbox: https://blog.risingstack.com/writing-a-javascript-framework-sandboxed-code-evaluation/ https://blog.risingstack.com/writing-a-javascript-framework-...
• softcactus 4y ago
  I kind of sought to answer this for myself in a roundabout way. My first experience with web dev was React. I never learned "why" so on a recent personal project I figured I'd start from the ground-up. First I wrote a little 'RTS' game in Javascript where the player writes code for the units in game and runs the code in the browser. But the player/programmer needs more info about the game's state. Which means I need dynamic html components to display the changing state of the game. Easy enough, I used a lightweight library called slim-js to give me the functionality I needed minus the ugly boilerplate of the Shadow Dom. But now my dynamic components were re-rendering every single frame, since they were tied to a callback that was triggered when the game re-rendered. Ok, I'll just save the state of the game into a map and only update when there's a missing value or a new value. But all of this state management and custom component logic is overhead that makes the page harder to maintain. I also wanted to use typescript to make sure I was passing the right values back and forth, which means transpiling every time I make a change. I also need to serve the index.html with a webserver, so I can import ES modules. Http-server works well enough for this, but what if I want to add another page to my site for watching tournaments run on the backend? It was a nice exercise to learn /why/ frameworks like React exist. Moving forward I'm definitely going to move to a React-based page since I'm already starting to outgrow my vanilla-ish stack. Here's the game if you'd like to check it out: https://ai-arena.com/ https://ai-arena.com/
• balls187 4y ago
  It’s hard not to read many of these comments as “Old man yells at cloud.” I’ve been lucky enough to experience development across many different types of systems over my 20-year career, and web development has come a long long way to the point that Vanilla development is viable. Generally speaking, I prefer to spend my time solving problems, not reinventing the wheel with boilerplate. Using a framework like react aids me in that goal.
• lewdev 4y ago
  I have enjoyed writing HTML/CSS/JS (vanilla) apps on my personal projects and use React for large apps at work. When my apps get large, it gets harder to manage, whereas when using React, each component is contained, so I don't have to worry so much about what's going on around it. That's not a good description, but it's easier to built on top of a large React project, than it is on a large vanilla project. Frameworks also establish a common way of doing things like tracking state. For example, in vanilla projects, one developer might implement it in a unique way that no one else understands. You want to work with code that works well with multiple developers on larger projects. It's still fun and interesting using vanilla for personal projects. I built a bunch of apps with just a CSS framework and JS was vanilla. (my apps: https://lewdev.github.io https://lewdev.github.io)
• deleted 4y ago
  [deleted]
• asiachick 4y ago
  I want to add, I like typescript, I think React is okay. What I hate is the build steps. I tried create-react-app and it's basically on mimimal support, updates broke stuff, outdated deps, devs unresponsive, ... What is the simplest, least likely to break, minimal dependency, live update tool chain for typescript, and or typescript + react?
• throwaway0asd 4y ago
  Frameworks solve for architecture. When a choice is made to use a framework the choice declares the stakeholder(s) trust the framework to provide a better architecture than the assigned developers. How prolific a given group of frameworks become understates how little faith the decision makers have in developers to write an acceptable solution.
• Existenceblinks 4y ago
  I have a half-serious way to fix symptom here: everyone gets into javascript is required to implement their own `ui=f(state)` framework, maximum size is 10kB minified. 80% of them will be amazed how easy it is. I bet 20% of those implementation each would cover 80% of application use case today.
• vbezhenar 4y ago
  I think that most JS developers don't have experience writing code without React, so they just use tools they know.
• robertakarobin 4y ago
  I've always really preferred keeping it simple with HTML/CSS/JS and find most front-end frameworks to be a huge turn-off. You might like Astro (https://astro.build https://astro.build). I love that my sites are still 100% HTML/CSS/JS that I wrote myself. But Astro comes with Sass and Typescript support out-of-the-box (no Webpack necessary), and also makes it easy to do reusable components, scoped styles, supports FE frameworks if you want them, etc. It's the happiest medium I've found yet. :)
  • silent_cal 4y ago
    Cool, thanks for sharing!
• rglover 4y ago
  Yes, they are. This is why I built Joystick [1] to take a lot of the valuable concepts of modern web development frameworks and make them work with pure HTML, CSS, and JavaScript without any hacks, syntax tricks, etc. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
• vdnkh 4y ago
  ITT: non-web developers whining about JavaScript (a favorite pasttime of HN)
  • hbn 4y ago
    Or bragging about a pet project they made with vanilla HTML/CSS/JS that's any or multiple of: * not particularly impressive in terms of UI requirements * likely took them 10x the amount of time it would have taken if they just used a framework * doesn't make any API calls * doesn't manage any/much state * is composed of code that no one else would be able to easily hop into and refactor if working in a team scenario
• pengo 4y ago
  I still write static sites which are hand-coded in HTML and CSS augmented by a (very little) javascript. They're quick to build and easy to deploy and, for some clients, they're all that's needed. I've used frameworks for twelve years, and covered most of them across various projects. I particularly like the direction of recent frameworks like Svelte and Vue3.
• ggregoire 4y ago
  I worked on a "web app" in the early 2010s, 10k lines of vanilla JS and jQuery, and it was a nightmare. Adding basic features or fixing the many bugs we discovered every day took hours or days. Any refactoring took weeks. We had to invent new abstractions on top of existing abstractions to keep everything more or less understandable and maintainable. Just splitting the code into different files (like to achieve some sort of frontend MVC and avoiding to have 5k lines of code in a single file...) and loading everything in the correct order was a puzzle. Making or changing any kind of edit forms was a real challenge too and prone to just adding new bugs to the list. Between loading all the data in AJAX, adding an id to each input and filling every input one by one with jQuery by copy/pasting their ids from the HTML, generating the selects and selecting the correct option(s) and adding them to the DOM, dealing with all the buggy jQuery modules like date and time pickers and their own ways to initialize and return data, showing or hiding parts of the form depending of the selected options, extracting the new values one by one from the DOM with jQuery once the user submits the form, validating the data and toggling the classes of the inputs to "error" with jQuery and adding error messages at the correct spots inside the DOM, revalidating the data and formatting it and sending it to the backend, refetching the values just to be sure everything is in sync and updating the values inside the DOM again with jQuery by copy/pasting ids and classes from the HTML... We take all this stuff for granted nowadays because the frameworks do it for us but it was so artisanal back then. Eventually I pushed to rewrite the app when Backbone.js came up, and we started using tools like grunt, and it was already a huge step forward. Then some years later we migrated to Angular 1, it was another big win in productivity. Eventually React came out and I started experimenting with it and I thought it was revolutionary. Its component paradigm allows to break the app into small manageable and reusable pieces and this makes everything simpler. And then Microsoft released TypeScript and now we have code safety and autocompletion on everything, including external packages. And we also have JS export/imports, fetch, async/await and so on... And tools to test all the logic and interactivity in our apps. Nowadays frontend development is just so much easier than before. I can't believe that people who think the opposite have actually worked on any sort of real life big frontend projects in an enterprise environment (1 or several teams working on the same codebase, new non-trivial features to implement every day).
• weard_beard 4y ago
  TL;DR - People started using their mobile devices not just for apps, and not just to view static pages, but to spend money. They started expecting websites to behave like apps started spending money on websites that behaved like apps. We have frameworks instead of static HTML because it is really complicated to make a website behave like an app and it takes a LOT of javascript. We started out with jQuery ajax calls and media queries. We moved on to AngularJS to start swapping content in the page in larger chunks and maintain state and code better. We've now moved most/all of the site functionality into Javascript via React to better manage caching and state of the application for the best performance and more manageable code.
  • silent_cal 4y ago
    This actually makes a lot of sense, thank you
• weard_beard 4y ago
  TL;DR - People started using their mobile devices not just for apps, and not just to view static pages, but to spend money. They started expecting websites to behave like apps started spending money on websites that behaved like apps. We have frameworks instead of static HTML because it is really complicated to make a website behave like an app and it takes a LOT of javascript. We started out with jQuery ajax calls and media queries. We moved on to AngularJS to start swapping content in the page in larger chunks and maintain state and code better. We've now moved most/all of the site functionality into Javascript via React to better manage caching and state of the application for the best performance and more manageable code that leverages APIs for most of its data and content.
• caeril 4y ago
  The real meta-question here is why does everyone want to write SPAs in the first place? This is an era of ubiquitous 100mbps+ connections, CDNs, and edge-computing-two-hops-from-the-customer hosting. The whole reason we invented SPAs (bandwidth savings and latency) predicated on AJAX has been obviated. We can return to serverside HTML/CSS and forms with no loss of UI quality.
• nightski 4y ago
  Nothing happened there’s just no need to talk about it every day.
• aristofun 4y ago
  I’ve seen some complex vanilla js uis back in the days. They all ended up building some framework similar to react or angular. There is no other way to manage the growing complexity than to invent some “engine” and a set of rules. So your question has the answer in itself. There is no “or”. React _is_ HTML/CSS/JS, but organized for complex projects. And definitely not for any project. I bet most of “js justice” warrior have never got their hands deep in really big uis
• ericmcer 4y ago
  If you develop any decent sized application with vanillaJS you will end up at some point building your own framework. The chances of it being as good as React are almost 0.
• joeyguerra 4y ago
  People still write vanilla HTML/CSS/JS. Maybe it just "seems" like they don't because so many people post about using web frameworks, and nobody posts about not using frameworks?
  • noonhe 4y ago
• phendrenad2 4y ago
  GUIs lend themselves well to component-based (a.k.a. Object-Oriented Programming-based) approaches. The earliest GUIs used OO techniques. And JavaScript has VERY weak OO functionality. Or rather, the browser has very weak OO functionality. Everything is global. Any piece of code can just modify elements in the DOM as they wish. There's no modularity or namespacing. When building a big, complex, interactive GUI, it's a lot of work trying to use a homegrown approach. Better to just use what has risen to the top - React,etc.
• raffraffraff 4y ago
  "Papa, which web framework should I learn?" "Child, you know your mad uncle Joe who lives up at the big asylum?" "Yes Papa" "Well stay the fuck away from frontend web development"
• rk06 4y ago
  They are not fine. Your css styles are tightly coupled with html elements. Your js is tightly coupled with html elements. So why keep all html elements, css and js together and separate from each other? Components provide a better primitive by combining related css, html and js together as one unit. This is not supported by native browsers, hence custom frameworks are necessary and better