And it pulls hundreds of megabytes of shit behind the scenes with god knows what vulnerabilities & backdoors, the resulting browser bundle is hundreds of kilobytes of crap the browser has to download & parse (instant on a fast machine & internet, less so on a cheap Android device on crappy underground subway Wi-Fi), etc.
This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place.
This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity).
War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
Just because a new solution is trending doesn't mean you have to figure out how to use it in your tech stack. Evaluate your needs and where it may or may not fit and decide accordingly.
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
SSR was just an example. It's a valid solution, my point is that it's now yet an extra workaround to a problem we created in the first place.
Websites were SSR'd by default back in the day, the backend (with PHP or whatever you had on there) generates some HTML that the browser displayed. Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
But SSR isn't a core requirement for many applications. Nor is it necessary to build out a purely javascript based stack on the server side to get SSR with a shared React client codebase.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.
I never said the authors of big JS projects weren't smart. In fact, anyone that manages to keep their sanity in that environment is by definition smarter than me.
I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
Most projects do not have any requirements like real-time UIs that would justify a front-end app and will be just fine with a "boring" backend-rendered UI with some HTML, CSS & forms and will automatically avoid a horde of problems like syncing authentication between your backend & frontend, having to manage a separate build pipeline, server for SSR, etc.
> I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
I strongly disagree; most of the projects that I worked on a decade ago that lasted more than a few months ended up with ad-hoc frameworks or conventions implemented in vanilla JS or jQuery that varied wildly in quality and changed frequently through the lifespan of the project. In my experience React/Vue/Angular with their generally well engineered and thought-out principles have resulted in a huge boon for productivity for long term projects in a team environment.
> Most projects do not have any requirements like real-time UIs
Whose "most projects" are we talking about here? Yours?
> Whose "most projects" are we talking about here?
Go on a job board, search for React/Vue/Your-Favorite-SPA-framework, go to their website and then see if there are any features that would actually justify an SPA.
Some examples: the Airbnb website, the New Reddit, etc.
I would use reddit as a counter example.
Sure some the new features could be built without an SPA, but it would be much harder to do so.
They have a full wysgi for theming built in, a real time chat app, a video sharing app, multiple messaging platforms, and methods of bundling multiple subreddits together.
They added all this really fast, due to the nature of the platform being an SPA.
I have the same issue at work. Any given feature in isolation could be done simply as a jQuery plugin, but together the only way to make it seamless is an SPA.
It used to be true. Their first few months of the SPA was really rough on the UX front, but it really improved since then.
They have a good design staff, but there was so many minor decisions made over the years that no knew exactly what was a necessary feature of the UI and what was just fluff.
They needed some real world testing to get a better design.
SSR just seems like tail chasing, but this time around there is no mature server-side framework (like Django, Laravel, Rails). Maturity, ecosystem cohesion, and higher level abstractions are all casualties along the trail of abandoned work in the name of "scalability" and "modernity".
There is no world where a tool or language for which you need hundreds of megabytes of unknown untrusted dependencies of dubious quality is considered a good tool.
...what? He was bemoaning React making things far more difficult than they need to be. And I think that’s a fair assessment of the situation. There’s a minimum overhead to maintaining a modern js app that is far higher than maintaining say, a Rails frontend. And it’s more costly for every change.
You do realise that 5KB is bigger than most text content you'd ever display on a webpage? You know how many things can go wrong when trying to download 5KB on flaky public Wi-Fi or overloaded cellular connection? And you're telling me it is no big deal to be loading that with no actual benefit to the user?
Sorry but 5kb is absolutely nothing for today's Internet connections, public WiFi or overloaded cellular connection or something else, especially if it's provided by a cdn. Yes, it is absolutely no big deal to be loading 5kb. Come on, be serious.
The problem is not the CDN, it's the last mile. You seriously overestimate public Wi-Fi and shit cellular networks; there are times where a simple HTTP request returning dozens of bytes of text will fail. In these moments every byte matters and personally if I'm going to make my user download 5kb of data I will make sure it's content they care about, not a JS framework.
Let's take the example of London Underground's Wi-Fi. It's only available at platforms, not while the train is travelling between stations. When the train arrives into the station it will stay there around 10 seconds. 5 seconds of those are wasted by the phone finding the network and authenticating to it, which means you've already got only 5 seconds before the train goes away and the connection drops off. During those 5 seconds you have lots of apps in the background (push, e-mail sync, background app refresh, etc) that are all fighting for around 1Mbps of bandwidth.
There's also the issue of failing gracefully. If CSS or image loading fails the browser will still display the bare HTML and the user will still have their content in a consumable format. If JS fails to load in an SPA the page is unusable and often shows just a blank screen. If SPA-initiated requests fail it's up to the developer to handle the exception and offer the user a way to retry instead of just giving up and waiting for a page reload.
As someone who used to commute through London on the tube and knows the underground wifi very well, you take on board the limitations of the connection. And you know the connection is going to fluctuate so you're not going to be doing anything serious.
Broken images and incorrectly loaded CSS can also break pages and make them unusuable so where do we draw the line?
I do get your point but on the other hand many sites are using JS frameworks for good reason and 5kb is absolutely nothing to improve the user experience. You really can't complain about the size of a 5kb javascript file in this day and age otherwise let's just revert back to HTML 2 or 3 to cater for all edge cases.
Now you're just arguing for the sake of arguing. I get the general rant against huge bulky libraries, but you're picking the wrong hill to die on for 5kb.
Google's logo, one word, 4 colors, is 14kb.
To have a library that gives you a better foundation to build a website on be 5 (actually 3) kb? In what universe is that a bad thing?
That is less data than the logo will take up, and is also less data than, e.g., the raw text in this comments section (compressed with brotli). With proper caching policy, the code bundle also only needs to be downloaded once.
Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc).
Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
