However, after working for software companies for a few years, it seems like almost nobody uses these technologies in the way they're presented on websites like w3schools to make web applications. Instead, they use component-based frameworks like React. To me, these frameworks seem way more complicated than HTML/CSS/JS, and I don't understand what problem they're trying to solve. What makes the trade-off of all that extra complexity and abstraction worth it? Aren't HTML/CSS/JS perfectly fine and time-tested tools for web development on their own?
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)
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.
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.
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.
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
... 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.
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.
(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.
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.
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.
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.
- 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.
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.
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.
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.
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)
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.
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://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.
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.
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.
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.
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.
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.
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.
(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.
---
We are building SyncHTML.io to counter that.
Try at https://sy.ht (press up/down arrows)
See how we set ourselves apart 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 (just press up/down arrow keys)
2. WebPDF.pro: https://pdf.sy.ht (view); https://pdf.sy.ht/?s (edit)
(The WebPDF.pro elements are served from an unoptimized server. Takes a few seconds to load.)
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.
Folks open-sourced their libraries, others contributed, and we eventually wound up with frameworks.
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/
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.
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.
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.
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/
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.
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.
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."
Yes they are perfectly fine, dont waste your time
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.
I did use Typescript without a framework to implement this ios calculator clone (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-po...)
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 It uses a couple of 500-line libs, that's it. No complicated framework, and yet you will be more productive.
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.
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.
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.
(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 and https://every-layout.dev (and probably 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.
"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"
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.
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
Grug try develop Notion or Google Sheets competitor, grug use React/Vue framework.
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.
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
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)
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.
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.
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.
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.
It still works fairly well on the relatively small scale if you just want to write a frontend app (i.e. simulations):
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?
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.
There is nothing like being on the lowest common denominator, but you can understand why browsers are not evolving past this point.
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.
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.
Component Frameworks give you more structure that organize the projects in more sane ways.
Maybe it just "seems" like they don't because so many people post about using web frameworks, and nobody posts about not using frameworks?
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).
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.
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...
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.
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.
No react needed.