The primary reason to use React is that it's an easy API for working within the stateful component paradigm, and goes the extra mile in protecting you from state-related bugs. It still has value even if you drop the stateful part, it's not unheard of to build completely static or server-rendered websites with React without any client-side JavaScript.
There are performance penalties when it comes to the initial page load, you tend to win it back when it comes to subsequent user activities. Whether it's worth the trade-off is dependent on your use case. There are also downsides to progressive enhancement, an obvious one is that if your enhanced JS version changes appearance/layout in a noticeable way, you could end up making the website feel slower even though it's technically usable sooner. In addition, what happens to any existing interactions with the non-enhanced UI after the enhanced version suddenly appears?
The fact is, you just have to decide what's important. I do agree that not enough developers are giving real-world accessibility and performance enough consideration. But I'm less convinced that there's a way to approach these needs that is superior in all circumstances.
Granted, for some UI, this is hard to avoid. Those are much fewer and far between than given credit. Most state for a browser should be easily holdable in the address. If you find you can't do that, are you sure it is relevant state that your user cares about?
The idea that there’s a mythical user out there who absolutely demands serverside rendering is a bizarre figment of HNs collective imagination.
Then implement that. There are much more lightweight ways to achieve this than going full react. Especially with modern JS this can even be implemented from scratch.
Take HN as an example. Inline replying, voting etc. is undeniably convenient, but there is no way there shouldn't be a full page load when going through paginated results, or opening the comment thread to a post. That requires a couple lines javascript, no bloated js-framework-of-the-month. And the page stays completely usable without JS. A lot of stateful webapps out there aren't any more complex than this, structurally. Bonus: You get a fully working, predictable back button in your browser for free.
I recently used the best webapp I've ever used - LucidCharts. That was an app, and, as such, I didn't have the expectation that everything I did generated a new link, or that I could even link to certain things. BUT, they also struck the balance of providing web behaviors for things where I expected them.
And for the users on weak machines or connections, the reload version at least works, unlike the JS one.
The "users love AJAX" argument is both silly and honestly also a bait&switch. It's not really because of AJAX that people build their sites in JS frameworks.
Server side rendering HTML and serving it up works perfectly fast for pretty much every site which is read only content or forms. The of 3rd party scripts running on every page are the issue.
Also as a major negative against SPAs, once a script is loaded - it's going to be ever present on every page afterwards - enjoy explaining why payment details page needs 20 3rd part scripts running on it. Not possible to unload scripts.
If using that framework means that the developer can churn out something much faster, and therefore has time for more features, even if they aren't perfect or fast, is the user really worse off for it?
Continuing the carpenter analogy, it's the difference between using a nailgun and a dovetail joint.
Sure, the nailgun'd version probaly won't last as long, but if that means that the one carpenter was able to make 5 different shelving units that all looked exactly how the customer wanted them to look and was able to do it for cheap enough that they all happily bought it, is that really worse than only being able to get one expensive "better" version out and not being able to customize it per-customer because of time constraints?
And I know first-hand that those kinds of trade offs happen all the time. There are tons of times where "can we afford to add feature X" is a "yes" because we are using React in the app and spinning up a new component becomes extremely easy, but in applications which aren't using a framework that is often a "no" because we need to do so much more work to get it fully integrated and working.
I can only speak for one user, myself, but my answer is -- yes, the user really is worse off for it.
I get that there may be network effects that trap you, and you could be worse off because that means that by prioritising another feature they made one of your personal favorite features worse, but that really doesn't have to do with the technology used and more with what the developer is prioritising.
I can and I do, for as long as it's possible.
The problem is that JS-first fashion infects web shops, and one by one, websites are being rebuilt in "modern ways", rendering them less usable than they were before. Such sites would be easy to avoid if they were the exception, but you can't do that if everyone follows this trend.
It’s both amusing and sad to see modern web developers criticize Java for being “bloated” because they don’t understand the Abstract Factory-pattern (fairly light-weight, 2 levels), while themselves are using infinitely more complex and heavy frameworks to render what is more often than not is just static HTML.
Proof of that is that in languages where there are alternative patterns (like Python), people rarely create a factory, they use functions that return classes; they don't use singletons, they just use module static variables; they don't create observers, just just gather callbacks on a list; and so on.
There are many less formal patterns that do add a lot of value. And there are syntactic and type level patterns that are great, but typically OOP programs use those less than code in other paradigms. OOP has one common less formal pattern that is very useful and less used elsewhere - it's the abstract API, but this one people on the internet mostly recommend not using, because it requires inheritance.
Don't get too hung up on the implementation details in any particular language. A Python function that returns a class is just a factory by another name. The essential point is deferring the decision of which implementation class to instantiate until run time.
Inheritance is one way of handling abstract APIs, but not the only way (depending on language). And don't believe everything you read on the Internet. In some limited circumstances inheritance can be a great way to simply code and eliminate duplication, far outweighing any additional complexity it introduces.
Or just use interfaces. As in "design by contract".
And that's just common sense programming wise, not some OOP specific solution.
You can successfully apply OOP and OOP design-patterns to a lot of problems and come up with equally functional solutions as you would with FP.
And for certain domains, better.
1. It is designed to be testable. It makes testing the components much easier than testing jQuery soup. 2. It has an opinionated way for developing javascript applications 3. Will validate input types passed to controllers 4. Has nicer syntax than jQuery soup
I'm not sure if you're blaming the tool or not, but at least for 3rd parties, I want to clarify: jQuery doesn't mandate "soup" - In fact, devs learned over time that the best approach development with jQuery was the same as without - have application state tracked as variable(s), have routines to translate the current state into the the DOM. That's the unidirectional flow that React likes, and both vanilla JS and jQuery can run with it.
But jQuery makes it EASY to use your DOM as state storage, which works well at first and quickly grows nastily complex. Meanwhile, React makes it EASY to update the DOM from state without performing unnecessary re-renderings.
So jQuery doesn't mandate, or even encourage "soup", but there's nothing guiding you away from it. React, OTOH, makes the path of least resistance be towards this particular best practice.
To your points as to why people use React, I don't think those are bad points, but those aren't my primary points. React best practices mimic the best practices of coding in general: Small, single-purpose components with minimal coupling. This allows me to bring in experience from outside React, and allows me to apply React experience outside of React.
Model.
> have routines to translate the current state into the the DOM
Views. Triggered by #changed notifications.
> That's the unidirectional flow that React likes,
Aka MVC.
I really don't know what world that statement would be true in.
It is a full tool-chain, language, architecture, API spec, and testing framework. They are all closely tied to each other.
> React, Flux, JSX, GraphQL, Jest.
Opinionated implies there is "1 true way" to do things a la angular or ember.
react is most definitely not the embodiment of opinionated.
ref the multitude of libraries which were flavour of the month before something else came along.
> It is a full tool-chain, language, architecture, API spec, and testing framework.
Ok, now I know you're either trolling or have never used any technology but React to solve problems.
React is amusing, as it makes it look like you have to have a complex JavaScript framework to have hot loading. But you don't. Never have. Will you need a fancy tool that knows JavaScript well? Yes. Do you need to be writing to that tool, or with it?
So, nobody would mock a carpenter for using power tools. They would question one that only worked with a 3d printer. Even though that would certainly let them iterate faster.