The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.
More pithily, maybe PHP was good, actually?
Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.
Some of that is captured in this post; hope it helps:
https://infrequently.org/2022/05/performance-management-matu...
Consider that Chrome Dev Tools are built with vanilla js (plus web components). I would call it a medium-to-large-sized project, wouldn't you?
Although Chrome Dev Tools isn't the kind of use case that Alex has in mind when he rants on Twitter. His concern is the mobile web; his reference is a weak Android device (used to be a Moto G4) on a 4g mobile network. Which kinda ignores that there are valid use cases for sites that are built as apps primarily for stationary desktop users.
So, I am not sure exactly what your point is?
We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla.
Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just
element.style.display = condition ? 'none' : 'block'
From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters.
I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS.
Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model).
We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.
It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.
I hate the poor UX often produced by React— fat, slow, clunky pages with loading spinners and jank. So, I sympathize with the author. I hope something like Quik gets it’s footing.
But until there’s a better way to build UIs from this subjective developer’s perspective, I’m sticking with React.
For those unaware of the missing context, what he's talking about is how in the 2010s, progressive enhancement — long seen as a webdev best practice — was largely replaced by a JS-first approach by JS frameworks in practice.
It does seem like the JS-first bubble is deflating a bit, but I'm not sure it's on its way to fully popping like the Flash bubble did. I do agree it was a lost decade though. More than a decade. I miss when everyone agreed progressive enhancement was the way to go.
It's entirely possible to build a SPA without abandoning progressive enhancement, but the frameworks do not encourage those best practices. As such, it's rare to see a web app built with a framework that doesn't create a hard dependency on JavaScript or isn't an accessibility disaster.
When I reflect on the last decade of frontend development, the lesson I draw from it is everyone is susceptible to ill-conceived fads, including people who think of themselves as evidence-driven. We're good at convincing ourselves we're objective, especially at times when we're not.
What's really depressing is this tendency applies to all the applied sciences. Tons of people who think of themselves as motivated solely by evidence fall for terrible fads in their field all the time, including, terrifyingly, in areas like medical practices.
I think we'd all do better to spend less time emotionally attaching to our tools and more time looking at evidence and metrics in a dispassionate way. As Paul Graham once said, keep your identities small.
A great book that's vital to grokking this stuff is The Scout Mindset by Julia Galef. She argues we should always just go where the evidence leads. But our monkey brains are bad at this, so it takes a lot of conscious effort or we'll do it poorly. I think JS framework mania is yet more evidence of her thesis.
But many smart people are in different situations in which the best decision is to use a framework.
If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework and going very very basic is the right thing to do.
If I'm a startup with 3 engineers who need to iterate quickly and don't care about page load time (yet) then I'm going to reach for React.
I came back to frontend development after a break of 10 years. Back then there was jQuery, CSS and HTML.
I found that the complexity of the tooling had increased 20-fold. All these build and task runners that were cool for a year and then a new one came along.
Those were the costs, but what was the upside? It seems that you can do maybe 10%-20% "more" than back then. It seems to me that this is a very very steep price to pay.
Sure, for my personal projects I am all about KISS but at work, if someone insists we try out this new framework and build a super complicated SPA, why not?
People make fun of resume-driven development but besides the money which obviously is the main benefit of having a job, experience is the other big thing that a job can offer. It is in my best interest that we use the most complex solution. I like the challenge.
Lets be honest, most fronted jobs could be rationalized away and the products would actually be better. It depends on your exact business but in many areas there is not point in keeping your UI "fresh". I have seen lots of redesigns actually HURT sales. Once you have found a design that works for you target customers, just keep riding the good thing.
So yeah, things are insane but as a developer it is neither in my power nor in my interest to change anything.
PMs should be aware of what they bring in when they allow some dev to (re)write the next project to in [this weeks' framework or tech]. PMs can push towards boring, proven and simple tech. Sure, much less fun for devs, might even push away the "magpie-devs" (the ones always chasing the next shiny thing), but in many projects this is probably the best for the business. Not always, but PMs more than devs, should know that any tech has trade-offs and downsides, what they are and how they will affect the business over years and decades.
It's like the blockchain craze that thankfully has passed. A few years ago, any company worth anything had some kind of blockchain project, because "everyone knew" that blockchain was some magic thing that would make your business (and your product) better. Certainly some levels of upper management believed this, and they saw their peers embracing it.
It's the same, but older, for JS-heavy frontends.
The point is that we should carefully re-evaluate how we got here and if we indeed have reaped rewards great enough to compensate for the immense additional complexity.
Am I missing some fundamental new insight?
Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence?
My instinct is that 80% of websites can be HTML and comfortably meet user needs. Another 15% can sprinkle in a little JS to make some targeted improvements. And finally, maybe 5% really do need full JS frontends.
Our problem in general is that we like shiny new things, clever things, and things which we think will make our developer lives better. But it seems we end up overdoing it, approaching each new thing as if it were a silver bullet.
The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. I have a strong opinion on which of the two does this better and more simply, but that's a separate discussion.
As an aside, for those unaware it may be of interest that Hotwire can be used to incrementally enhance any ecosystem's server-rendered HTML experience and not just Rails. From the simplest option of just including the source but changing absolutely no code, which has an instant impact, to making proper use of it.
One of the projects I use it on is a C# MVC (server-rendered) app and with virtually no effort you get some of the benefits of ye olde update panels from webforms. It's really quite neat.
- modern
- revolutionary
- love ("really really like" is ok)
- can't go back to / can't live without
- is the future
- just (describe which is not)
that's a new one
In the end I decided to re-evaluate was I was doing, I want make the web better but with React.js I was doing worst the web
That’s just a ternary conditional in React. How is it complex?
Then consider the render model and how it would affect page time to interactive for a large content oriented page.
People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'm all for that.
But ... 2 weeks ago I took over a half-finished Go project that's been left to "bitrot" for almost 3 years after the previous developer took a different job. Updating the Go dependencies was pretty easy; updating from 1.4.3 to 1.8.9 and such; maybe 1 or 2 with major version bumps, which were minor incompatibilities. Even the usage of the now-deprecated github.com/golang/protobuf wasn't a big deal, and updating to use the new conventions was boring and unexciting, but fairly painless.
The frontend part ... yikes... Things need to be updated from 3.0.2 to 6.8.4 and nothing works if I update it. There are what seem like to be 500 releases in the meanwhile and a lot of changes to go through. It seems in those 3 years the entire world changed. I spent a day on this, and eventually resigned to just accepting the 100+ security vulnerabilities that npm install throws at me. Most, if not all, probably aren't a huge deal in a browser context, but still...
Certainly from my perspective, there seem to be some problems here. I just want to solve real-world problems and write code, not babysit my 1000+ dependencies for what is actually not a very complex project at all. Of course, you don't deal with any of this for new projects, but a 3 year jump really isn't that long of a period. Some churn is expected, but "yeah, maybe just throw a lot of it away and start from scratch"-kind of churn? Meh.
I’m not going to defend the instability of the rest of the JS ecosystem. It’s totally insane. I try to minimize my deps as much as possible, but even so, they’re in the double digits.
My side project at the moment is a zero-dependency stack.
That said, React itself is pretty stable. My guess is that an upgrade from a 3 year old version would be painless. And I still think React / Preact are the best approach that I’ve found for building UIs. It’s quite painful to go back to templating (ERB or Go templates) by comparison.
There's still a time and place for sending HTML and maybe a few tiny JS files down the wire, but for anything "application-like" it's just not feasible, unless your business is so big and performance matters so much that hundreds/thousands of engineering hours are a valid tradeoff to achieve it.
Regarding data loading and performance, there is a lot of exciting stuff in the near future - Remix loaders, Next.js RFC, React 'use' RFC, Quik, Astro, better bundling/build tools, etc.
I never understood this whole "it is literally impossible to do it without React" (or React alternatives) thing. I've seen it a few times now and it reminds me of 2005 when people were saying it's literally impossible to build any serious program without OOP. I don't really want to have a fight about which approach is "better"; I don't really care, maybe SPAs are better. And if you want to build SPAs then by all means do. If my boss wants me to build an SPA I'll go do it without complaining; maybe not my favourite approach but that's okay. But clearly they're not the only approach that can work well. The insistence that it is, is something I find rather off-putting.
I absolutely think you can do SPAs well; my favourite example is FastMail's web UI, it's pretty good and quite a bit of attention has gone in to various details such as the way the scrollbar/pagination works for large mailboxes. It's just hard to build a good SPA.
I borrowed quite a bit from FastMail's design when we built our own email solution a few years back with a more "classic" server-side templated approach, and I felt the UX was on par, and it was a very manageable project technically.
Are you sure users are really the ones demanding this?
It's more likely that "modern FE" is imposing this additional complexity on itself for other reasons, because most sites are still boring old crud apps that don't need anything "modern". The canonical example is the Todo app, which is...crud.
I don't think it's the users fault.
OK, so what about Vue.js? Or is it dead to you already?
React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.
Sadly, they're not what your users want.
1. The only reason to cutting out the framework is speed.
There are many reasons to forego a framework. Coupling, maintenance[1], dependencies or simply "keeping it simple" are some of the parameters to take into consideration when choosing for or against a (certain) framework.
More practically: I'm writing a simple job search engine[2]. Plain, vanilla JS, some \<template\> tags, and a library to communicate with the search backend. I dont' yet need anything react-redux-saga-event-based yet. This approach is reaching its limit, but I now have the proper information to make a better choice. I did not have that when I started, so I would've certainly picked the wrong framework and painted myself in a corner there.
2. Without a framework we cannot iterate quickly
As I point out in my blog[1] article, this is has often (but not always) be proven to be exactly opposite. Obviously depending on context and use-case. But there are many situations in which a framework is holding you back. In which it is actually slowing the project down, rather than speeding it up. Frameworks, famously, allow a rapid start, and therefore are great for PoCs, Demos, prototypes, MVPs or even "run-off-the-mill-agency-produce". But over time (think years, decades) often get in the way, hold the project back. Just think of the wasted eons of all engineers "rewriting project P from scratch"; often because it turns out that the current version/market/tech/use requires things that no longer fit the boundaries the framework imposed. Bouddaries welcomed or disregarded when the framework was chosen a decade (or just years) ago.
3. Smaller teams need a framework
See above. But also: what a small team needs is reusable code. Libraries. Not Frameworks per-sé, but libraries. Preferably implemented behind decoupled, isolated layers; away from business-logic. Or, more modern, SAAS, PAAS, IAAS. reusable stuff, preferably implemented behind isolated layers.
[1] https://news.ycombinator.com/item?id=33185010 [2] https://search.flockingbird.social/
I understand that some problems are just hard, that there are obstacles, or that things you build don't always turn out to work as well as you intended when you started out (sometimes what seemed like a good idea at the start turn out not to be so good ideas later on), and that many things are also trade-offs where there is no perfect solution. That's all okay. It's the whole attitude I find hard to deal with.
I joined a project using node, npm and angular. Everybody said things like that; "this is so awesome", "JS is great", "never had so much fun".
I tried installing it and needed help at every step, "Oh right! We need to do this in our env because X and Y", "Oh, you missed a step, trust me, it's easier to nuke everything and start again now." I ended up with a 30+ step guide that nobody had documented before. We had a little less than 100 security vulnerabilities.
Almost every standup was an exercise in figuring out some strange problem with node or angular, sometimes several.
This team was definitely doing things poorly, but the unrelenting toxic positivity mixed with the "Rails and Django and Symfony all suck so bad" was hard to take, especially as we struggled to ship a really basic MVP.
I'm sorry, but certain things shouldn't involve participation trophies. Building bird houses with your kids in the backyard, yes. Building anything at least as complex as a toolshed for other people, no. At a certain point (i.e. when our work can have consequences for others), we have to take responsibility for our work, and expect responsibility from others.
Client-side JavaScript is actually very compatible; see for example .at() to fix the [] subscripting behaviour (the reason [] wasn't changed was due to compatibility concerns; arr[-1] gets treated as arr["-1"], and changing it may break a script or two).
JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process
that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff.
what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency.
my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast.
to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s
https://infrequently.org/2021/03/the-performance-inequality-...
As this relates to latency, JS-mediated UI is slower to materialize for a host of reasons, not least of all the problems with getting it across the wire (as you note). Naive SPA designs tend to serialize what should be parallel (data fetching and shell setup). Getting better at this requires more sophistication, whereas teams that stick to basic HTML + light progressive enhancement tend to end up with simpler systems that are faster for light-to-medium session depths and are easier to diagnose/fix when things go sideways.
The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.
i agree that some (or maybe all) frameworks go needlessly complex with their dependencies. little libraries that contain one function that should really be folded into the other libraries that are using that function.
but isn't part of the problem the the inherent higher complexity of modern interfaces? the days where a site as simple as hackernews are appealing to the average person browsing the web are gone. i am afraid that in order to compete for visitors or customers, we have pushed ourselves into a corner. doesn't any new website need to function and look as modern as every other if it wants to have a chance?
a large engineering team with a sufficient budget and time may accomplish that without a framework, and so you are exactly right, the strings to accomplish it need to be pulled at the very top. but what hope do we have when the primary directive that comes from the top is to keep the cost down?
especially new projects suffer from this. i can only afford to spend engineering resources after a project has become profitable. but in order to get there, i need to cut corners where i can. that usually means using frameworks to get up and running fast. and once we make a profit we can spend money to improve things. but by then it's to late to switch to a non-framework approach unless the resources are enough to start over.
the complexity caused by frameworks is costing us money. but it's money that is now available because the project is making a profit.
wouldn't your approach require higher expenses upfront, at a time when i don't even know if it is worth the effort?
Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
True, but Twitter threads are the Burma Shave signs of the tech-gentsia.
Me too. They are absurd, hard to read and a waste of resource (load time, requests, steaming pile of JS).
They sould be penalized/barred.
And the required "buy in", not only can't you critique, you must ALSO actively assert everything is great or you're not "part of the team".
Any team without a few, "I disagree but support the group" engineers on it, is probably in a bad way.
It still works for me, has many benefits, and many downsides. But so do the "react-alike" frontend frameworks. There's no silver bullet.
It cracks me up (and makes me sad) to see all the effort going into "hydrating, SSR and whatnots" in JS frameworks, where we move our ball of react-js-spagetti onto some deno-based-edge-function-container thing, in order to serve clients plain HTML... I mean, this problem was solved in 1998 already!
What do you suggest for manageable SPA-like development -- for those of us who have actually thought the matter through and have decided that's what we need (at least in certain corners of this otherwise lean and mean, mostly static / old-school website we're building)?
Having been through half a dozen programming languages and most phases of the evolution of web development, I have a very different perspective. The complexity and fragility of modern JS-centric web development would have been unimaginable to us 15 years ago.
What started (as far as most people experienced) as Jquery, where you could sprinkle a little JS and make some big UX improvements ballooned into this monster where you need thousands of libraries, package management, bundling/minifying/babeling/etc., and fallback plans (you do have graceful degredation built into your JS frontend, yes?).
As the phrase goes, we can't see the forest for the trees. If we did carefully review the path we took from then to now, the promises or beliefs we bought which led us down certain trails, and then considered the outcome... I expect we wouldn't be even close to this situation we find ourselves in now.
I prefer the modern mess.
It’s still a mess, though.
I don't want to paint with too broad of a brush. Some of my best friends are frontend developers! But a community can have a certain "atmosphere" or "vibe" to it. I do a lot of Go programming these days, and I find the "vibe" in Go is one of self-righteous arrogant twattery. Does that mean every Go developer is like that? Of course not. But I found that's the overall "vibe" in the community nonetheless (it's a bit better than it used to be though).
But my preference would be something like: plain old server side rendered HTML with JS that enhances the site, adds some dynamicity etc. But in which a link or button-click usually is just fetching a new page over the wire.
This JS can (also) fetch data over the wire, websockets or such. And I wouldn't even expect it to be some fancy "progressive enhancement" - fine if the web-app doens't work without JS for me.