A couple of interesting articles making the rounds:
- Tom MacWrite: Second-guessing the modern web
- Rich Harris: In defense of the modern web
I like Tom’s assertion that React (which he’s using as a stand-in for JavaScript frameworks in general) has an ideal usage:
There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly. That’s where it excels.
If there is anything I hope for the world of web design and development, it’s that we get better at picking the right tools for the job.
I heard several people hone in on this:
I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.
One reaction was hell yes. React is a bunch of JavaScript and it does lots of stuff, but does not grant superpowers that make the web faster than it was without it. Another reaction was: well it actually does. That’s kind of the whole point of SPAs: not needing to reload the page. Instead, we’re able to make a trimmed network request for the new data needed for a new page and re-rendering only what is necessary.
Rich digs into that even more:
When I tap on a link on Tom’s JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we’ve loaded some stuff that will be useful later if they do tap on it. We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don’t need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page. This stuff gets fiendishly difficult to do by hand.
That’s what makes this stuff so easy to argue about. Everyone has good points. When we try to speak on behalf of the entire web, it’s tough for us all to agree. But the web is too big for broad, sweeping assertions.
Do people reach for React-powered SPAs too much? Probably, but that’s not without reason. There is innovation there that draws people in. The question is, how can we improve it?
From a front-of-the-front-end perspective, the fact that front-end frameworks like React encourage demand us write a front-end in components is compelling all by itself.
There is optimism and pessimism in both posts. The ending sentences of both are starkly different.
Using the right tool for the job is all well and good but web developers don’t want to learn a new language, framework or database every few months.
Yes, sometimes we might use react with a CMS to make a website which might be faster using a static site generator. Sometimes we might build something using jQuery when there are better/ newer alternatives and sometimes we might choose to build a REST API when GraphQL would be more suitable or install SASS to do some very simple CSS.
The point is that we want to use the same technology stack on more than one project because we want the chance to get good at it.
We don’t want to start every new project with a pile of books or wading through GitHub and stackoverflow just to get the basics in place before we can do any actual work.
My current stack is React with NextJS for websites and create-react-app for SPAs. Node/Express on the backend, MSSQL and Storyblok if I need a CMS.
Are they the right tools for the job on every project? Of course not, but I’m getting good at all of them and I’m being paid by the hour so I don’t have time to learn a new stack for every project.
For the same reason I know a lot of people who use WordPress on every project, even though it’s rarely, if ever, the right tool for the job.
What’s the answer? Do we all have to learn every tool so that we can always use the best one for the job or do the tools and frameworks need to be more flexible so that they cover the widest possible use cases?
Imagine if web developers only needed to learn one stack which was flexible enough for any project they were asked to work on, from small never-changing static websites to massive dynamic progressive web apps….
Not so fast. Concluding with “everybody is right” is a cheap win. The application on which I work at my job was rewritten several times, starting with jquery, then full server side cshtml and then full static pages with react and an API. At first look, static with react seems to be fastest – the page loads fast (but we also have a lot of CDN caching), runs smoothly, animations are great – all great.
But guess what? The moment I load the app in my browser, my laptop fans start spinning like crazy. Also, the code started very clean and it was a pleasure to work with – but now it’s as crappy as the server side cshtml. I think it’s crappier to work with than jquery at this point but that was long ago and I might be wrong. And of course it looks/works that way because the code is not done by university professors that are always able to organize code to perfection. The code is writeen by several teams, some of them in other countries, some contractors and so on.
And you see this exactly is the problem: in ideal conditions react would be fast and clean, but in everyday workplaces react makes the CPU go to 100% and the code looks like shit. It’s not a react problem per se. It’s not a react-router problem per se. It’s not a react-async-actions problem per se, nor redux, nor webpack, nor the whole million dependencies node_modules folder for which we have to use snyk audit every day. No no, the problem is all these tools crap on the dev environment so hard, a simple server side html (or cshtml) runs circles around all that stack all the time.
Webpack takes minutes to build? At least for our app. And it sometimes cannot delete node_modules folder because it’s used by the same build system somewhere else? You see all these problems were unheard of in cshtml land. Or in jquery land. Or hell, in plain javascript land now that we made it to year 2020. So yes I have plenty against react. It’s a fraud. It’s supposed to be good but turns your whole dev environment in a joke.
Sorry for the rant by the way…
Rather than thinking solely in terms of performance ideals, one should also consider the cost of development and maintenance, the speed at which you can adapt to changes in the market and new requirements, and so on.
The HTML (and CSS) is the visible UI. In my opinion, there is probably only one good argument for doing the visible UI on the server side, and that’s SEO. If you can implement your user interface on the user side, why wouldn’t you do that? It’s inherently simpler, faster, easier to build and change, more bandwidth efficient, and just common sense – trying to solve UI problems removed from the user/client adds a layer of complexity, performance constraints, and usually just a lot of “mess” from trying to tie up loose ends (mainly interaction UI) on the client side.
A static front-end and some APIs, in my experience, is always simpler and more maintainable than the alternative. I don’t personally reach for server side rendering of any sort unless there’s content on a page that can be indexed. Other than that, I don’t really find compelling reasons to emit HTML from the server side.
From my perspective, client-side UI frameworks and APIs have made web development overall simpler, more productive and more enjoyable than it was in the past. I honestly can’t really fathom why anyone would consider it not to be?
Nice summary. I agree they both had good points. It is healthy to reflect and evaluate like this on a regular basis. I sense the essence of Tom’s post is doing just that. I also like what Rich and team are doing with Svelte. Then, combine the news in Deno, I feel JS is beginning to show signs of the third wave (as Rich mentions in one of his talks)
I think it all trickles down to how the developer implements the tools that react has to offer as well as the web app itself. Reactive Js (Vue or React etc) in short gives you power to do more. It is up to you and how you use that ‘power’
It’s worth noting that on a static site, pages can be preloaded on hover without any manual work by integrating instant.page. WIth a bit of manual work, you can turn it into a SPA with much less JavaScript code compared to React using Barba.js. (I’d love to see a more minimal version of Barba.js that focuses just on the SPA aspect without animations, but I haven’t found one yet.)
I’ve come to intensely dislike react, along with the ecosystem around it – build/deployment practices and widespread UI design patterns.
These frameworks introduce subtle problems and hitches in websites that can be dreadfully annoying, but performance is always just good enough that no attention will ever be devoted to them.
The framework and build process generate page structures that are superfluous, obfuscated and very unfriendly for web power-users to customize.
And “responsive design” has turned into “mobile design”. Most sites look like utter crap on desktop. There is nothing “responsive” about it anymore, it’s become just a buzzword. It’s a consequence of both laziness or “good enough”-ness. Developers rely on tools and ready-made components to do a job that can’t be automated. It is not trivial to design a site that is truly responsive, that works well in 2 very divergent aspect ratios.
**Twitter.com* is a prime example:
More than half of my screen is empty. “Responsive” my bum.
The browser’s find function doesn’t work on the page, because as you scroll, the framework is removing elements from the page. Bad UX.
The page structure is a hellish tree of hundreds of nested divs and nonsensical CSS classes. If I want to change something I have to spend an hour just dissecting wtf is happening.
Another site I frequently visit – deviantArt – recently introduced a new redesign, based on react. It now performs worse, is a worse user experience and is missing a load of features from the old version.
And this has been a trend all around this new “modern web” and I absolutely hate it.
From my point of view both as web developer and web power user, these frameworks are just a novel way to compromise more. An illusion of productivity.