> Multi-page applications are slow to load and navigate. A bit tired to see this... No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.
HTTP was designed for multi-page applications/websites but I think it makes sense that Facebook migrated from basic PHP/MySQL to something more complex including React and making less full-page navigation events, for performance reasons (server costs and mobile loading time). There's also UX because a PHP website can feel a bit static, with less animations.
But yes the web has evolved since then and the HTTP protocol has newer versions and most apps don't serve as many users as Facebook.
> The idea of reactivity came from or was popularized by Angular.js No, spreadsheets popularized reactivity. And the general point is incredibly weak. Don't use frameworks and make your own? Sure, have your fun. But then try teaching your framework to your company of 1000 and see how quickly you realize your view of the "problems" are only a slice of the pie.
How many companies have 1000 frontend developers? Do they need 1000 frontend developers? Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-co…
My point was your needs and problems are not everyone's needs and problems.
I don't want to think of memory management in most projects, I want to focus on business logic, so I use Node.js instead of Rust, even if the latter gives me more control.
Similarly, I don't want to think of DOM management in most projects, I want to focus on data dependencies, so I use React instead of Web Components, even if the latter gives me more control.
It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept wo…
Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.
But it's harder to have component composition. Consider also lists and adding/removing items and so on, juggling all of it gets insanely complex and requires MVC or MVVM patterns like with backbone.js
Nobody says that React is great (also) because it's industry standard. If you pick up a React codebase you instantly understand how a component renders, where its state is, what its effects are, which components render that component etc. If it's React with a decent linter configuration, it's even easier. With a custom framework, on the other hand, you're at the mercy of who invented it. You have to find where state is, you have to trace where the state is "teleported" via broadcast, you have to understand where side effects are invoked etc. If the custom framework is as good as React, I'd still choose React just because it's a de factor standard.
It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept wo…
Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.
it can be faster, but is it correct?
React was invented because jQuery style state management collapsed into unmanageable code past a certain size
I appreciate the sentiment, but can't agree fully. I used vanilla JS for many years before AngularJS even existed (and I also tried AngulasJS when it was the new thing). Vue is just a huge convenience over raw JavaScript for large, complex view. Sure, I don't get to do direct DOM manipulation, but when I write C code I also don't get to pick which variable goes in which CPU register. I accept giving up control that A…
Writing programs in C has simplified developer experience over Assembly. Issue with JS frameworks is that many find them complex, i.e. complexity has not been abstracted away (which should be goal of abstractions). Maybe DOM manipulation has, but many new complex ideas had to be introduced to achieve it.
But isn't that the right thing to do? Recognize the problems and introduce concepts to tackle them. C introduced pointers as a concept, one more thing to learn and reason about but frees you from using addresses directly. Relational models was discovered as a formal way of understanding and reasoning about data structures. Frontend components introduce a composable architecture with lifecycle hooks, reactivity etc. Those concepts were already there (e.g. with ad-hoc html templates, event listeners, clean up code) but now they are actually formalized and made explicit and developers actively think about them when doing frontend. So the abstraction is there, but I feel for some reason non-UI people assume UI is easy to code, but they never thought about the actual concepts involved. Even without frameworks, you need to consider composability, modularity, events, life cycle, state management, async behavior, etc. I'd rather have those built in and considered as part of the programming model, than to avoid it.
Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome. The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI. Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" ev…
Or not. For simple to moderate requirements, plain HTML with a small templating helper is genuinely simpler than React. React’s complexity isn’t just components — it’s effects, state‑management conventions, data‑loading patterns, and the surrounding build ecosystem. If your UI doesn’t need those abstractions, adopting them early is pure overhead. For these kinds of projects, React usually carries a much larger total…
To write good React you have to follow conventions, too. You can't get away from conventions. People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
People keep touting react etc but I swear every mobile ordering app I use lags like hell.. I don't doubt it. People make terrible websites with React. However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good…
I've had someone tell me to not bother with list virtualization under React, since the 'computer's fast, it won't matter'.
We shipped it like that. Turns out the computer's not fast and it does matter.