The front end community wants to wash its hands of the decade we lost(twitter.com)
twitter.com
The front end community wants to wash its hands of the decade we lost
https://twitter.com/slightlylate/status/1583157448885514240
86 comments
I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete
I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.
I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else.
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.
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.
> Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue.
True, but Twitter threads are the Burma Shave signs of the tech-gentsia.
https://en.wikipedia.org/wiki/Burma-Shave
https://www.legendsofamerica.com/66-burmashave/2/
True, but Twitter threads are the Burma Shave signs of the tech-gentsia.
https://en.wikipedia.org/wiki/Burma-Shave
https://www.legendsofamerica.com/66-burmashave/2/
At first I found it surprising to start finding all of these Twitter threads making it to the front of HN and thought "well, it must be a really compelling message..." Now I just ignore them altogether. It is a very distracting medium for the longer posts, and that distraction shows through from the writers side as well.
Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?
> hate Twitter threads
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.
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.
Sums up the majority of whinging about JS you see online. I’m confused what “the front end community” even is.
I’ve heard stuff like this before. The people that say it are generally advocating for plain HTML/CSS/JS.
I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?
OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor).
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...
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...
so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote:
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
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
Device performance has been growing in diversity as we approach smartphone saturation (the last couple of hundred million flipphones getting traded for < $100 low-end smartphones). I'm working on an update to this series, but here's a recap from last year:
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.
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.
another thought:
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?
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?
I think is because JS is one of the few languages that has practically always been used with a layer on top, before with Jquery or other libraries and now with frameworks, that is not so common in other languages, JS has an external layer for everything
> 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.
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.
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.
JavaScript and CSS both provide abstractions for complexity.
So, I am not sure exactly what your point is?
So, I am not sure exactly what your point is?
I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro.
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
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.
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.
I worked with React.js for more than 5 years in a big projects and I finally burnout of it, I agree with all you said, React added a extremely complexity for simple thing, added a lot of side affects that sometimes are hard to debug and fix, fix re-render will be your daily work more that create features and in the end you get a slow application in mobile devices due the size/re-render etc.
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
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
From engineering perspective react-dom is being 130kB (.min) while the other is 6-8kB AND faster in benchmark, yet the industry decided this is acceptable, I know that our engineering principle is rotten.
Indeed. This is something the the staunch React folks are missing: with vanilla, I can cut out a LOT of excessive payload.
> 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’s just a ternary conditional in React. How is it complex?
That’s just a ternary conditional in React. How is it complex?
I'd encourage you to write it once in vanilla and once in React in jsfiddle and compare the implementations.
Then consider the render model and how it would affect page time to interactive for a large content oriented page.
Then consider the render model and how it would affect page time to interactive for a large content oriented page.
I’ve written this sort of thing in both. Personally, I find the “make your view a function of your state” approach to be much easier to reason about and more maintainable. Obviously, not if the only thing your site does is this one feature. But as soon as your site becomes non-trivial, I prefer the functional / React approach.
Well, frameworks vs vanilla JS doesn’t cash out into whether it’s hard to write ‘element.style.display = “…”’ or not.
It's been while since I've heard frontend devs even speak about actual frontend. Layouts, fonts, accessibility, that sort of thing.
When I interview front-end devs, I still focus on core fundamentals and I want to see if they can build simple interactions and layouts in HTML, CSS, and simple JS via jsfiddle. My assumption is that if they can do vanilla well enough, having them do React is easy enough. The reverse is often not the case.
That's very wise.
Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade.
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.
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.
> 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.
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.
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.
No argument from me, there.
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.
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.
Well, a lot of the “modern” frontend frameworks/libs are having the same symptoms that you describe as the entire world has changed, because it’s actually IS… Good luck working on a two years old Android project where Android Studio won’t even open it.
That sounds like a problem with Android or Android Studio. Two years really isn't that long of a time, and I don't really see anything in the world that really fundamentally changed in that time.
Client side development isn’t trivial on any platform. Comparing a Go project with a client application just reveals that client apps rot faster because the devices that run them and the software on them are moving targets, esp mobile devices.
Nothing fundamentally changed in the last few years AFAIK. I see no reason why it should rot faster. I've written things over ten years ago that work just fine today.
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).
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).
Yeah, I think people who pretend that modern FE is possible without React or another similar framework haven't built a modern frontend and dealt with all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc.
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.
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've built quite a few highly interactive webapps over the years both with and without "modern FE" (although more without), and I found the more "classic" approaches tend to be quite a bit faster than SPAs, and never really had serious problems with complexity.
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.
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.
> all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc.
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.
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.
I cannot wait for the next.js rfc. React server components are going to be awesome. You could say they’ve been a decade in the making.
There are a couple of full-blown text editors written in vanilla js so it's very capable of doing highly interactive.
Of course it's _possible_. If you go deep enough, React is just vanilla JS after all. The question is how fast a team can build and maintain something with each method.
This is what I do. Make the core pattern solid (barely touch this), and extended functionalities in vanilla way; i.e. just write another function receive context and return expected things. You can use solid/uhtml/preact/lit "the view part" they all have it separated from component model. It's 6-8kB (.min). Everything else is just application logic. react-dom is 130kB now and even slower than the rest.
I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em.
OK, so what about Vue.js? Or is it dead to you already?
OK, so what about Vue.js? Or is it dead to you already?
I think you are missing the point.
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.
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.
So what other kind of thing do you suggest (and which currently has some traction)?
What about the tried and trusted "have some backend generate HTML and push that to the client"?
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!
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!
Okay, I'm with you - but I meant for, like, people who have some idea of what they're doing (and don't just impulsively reach for a massive framework to deal with routine content dispatch).
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)?
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)?
I'm not familiar enough with the current space.
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.
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.
I don't agree with the Twitter thread but the implied alternative is serverside HTML and unclear what is the solution for rapid UX on the client.
> React (and Preact and similar) are my favorite ways to build out UIs
Sadly, they're not what your users want.
Sadly, they're not what your users want.
mattgperry(1)
I thought it was a good thread.
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.
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.
I feel the author misjudges the people making these decisions because for them in their own situation, the choice of large frameworks isn't the right one.
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.
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.
This makes three shaky if not outright wrong presumptions:
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/
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/
React was created by Facebook/Instagram, for FB/IG. Startups with tiny teams (or a team of one!) should hesitate to reach for ANYTHING promoted by large corporations. Even Lit, a web component library I really, really like, should _not_ be a default solution. Vanilla web components—especially ones that are easily progressively-enhanced from server-driven HTML—can be a better solution sometimes.
What's the missing context for this thread? This person seems upset at something, but it's entirely unclear what they're actually talking about...
I dunno, he seems to say at first that not naming whatever he is talking about is a bad idea. And then never names what he's talking about.
He doesn’t care about making a point to the world at large. He’s subtweeting some group of people and is hoping they read his long thread.
To add my subjective opinion:
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.
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.
The problem is misaligned incentives.
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.
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.
As a PM, I’m used to being blamed for shit going wrong (it’s part of the JD). But c’mon… the state of modern FE development… that’s my fault too???
I think blame is a too strong word, but there's some merit in this.
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.
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.
You’re a pm. By default, everything is your fault :)
There was/is also a level of resisting against evidence too though. Like "I don't care performance I will use what I like". And find reasons to back subjective metrics claims, like hiring pool (catch-22 problem of demand & supply of type of workforce).
This seems to refer to some new consensus that everyone now agrees to, but I am not sure what they are referencing. Does anyone know?
The consensus is that "good frontends need to be all done in JS, whether React or Vue or Angular or ...".
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.
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.
Front end development won't change. We'll just keep switching out frameworks for the shiny new one with the hope the next one won't be an overly complex mess of npm packages and microservices that can topple over at any moment.
This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes?
Am I missing some fundamental new insight?
Am I missing some fundamental new insight?
The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better.
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.
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.
> 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.
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.
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.
Turbo's actually really great for static sites—you can speed up page transitions and even handle some "reactive" elements using Frames and HTML fragments. Pretty awesome stuff. No Rails required.
Red flags words in web tech/tools to me:
- 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)
- 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)
'toxic positivity'
that's a new one
that's a new one
Yeah, that's the part that really kills me about JavaScript. I can deal with the language, npm, some curious conventions in the community, every "npm install" telling me I have 100+ security vulnerabilities. It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me, which is really just my snarky way of saying that I found there's generally some serious lack of introspection in the community at large. Something like, say, the Python packaging situation is far from ideal, but people are generally pretty honest about the fact that the situation sucks, and that it has sucked for quite a few years. Python devs tend to get embarrassed when you ask about packaging, or the GIL, and most ecosystems have some pain point(s) like that.
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 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.
> It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me
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 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.
Toxic positivity goes a step further. It's not just the gung ho "everything is awesome". There's also pushback against critique. In some communities, you can't say, "this project has aspects that are not good" without getting met with "be quiet, the devs are trying really hard".
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.
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.
> It's not just the gung ho "everything is awesome". There's also pushback against critique.
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.
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.
maybe people enjoy working with it .. I love it, I went from a systems admin/customer support to being a senior react dev, I learned angular, than some javascript, than some programming and then some more and some more.
Perhaps your love of JS/TS/whatever is based more on the path you took and your starting point than the tech you use.
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.
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’ve written quite a few old-school web apps in Rails and ASP.Net. Unless you stuck to really basic stuff, they were much harder for me to reason about than the React codebases I’ve been on. jQuery consists of trying to reason about accidentally over aggressive global event handlers and effects, etc.
I prefer the modern mess.
It’s still a mess, though.
I prefer the modern mess.
It’s still a mess, though.
That's fine, but lots of people also enjoy working with Python. I happen to not particularly like Python all that much, and that's never really caused that much friction (responses tend to be "yeah, that part isn't very good" and/or "right, I see where you're coming from"). Frontend on the other hand...
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).
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).
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.