The Frontend Treadmill(polotek.net)
polotek.net
The Frontend Treadmill
https://polotek.net/posts/the-frontend-treadmill/
721 comments
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc.
I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains.
Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about.
This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic.
There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.
I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains.
Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about.
This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic.
There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.
That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions.
That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
> That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.
Me either, but I have a hunch about why.
Are you a fast reader?
I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere close, I have to crank the playback speed up so high that I start having trouble understanding what the presenter is saying. That's on top of other things like poor searchability and no way to copy-paste code snippets.
The decline of reading skills, at least in the US, is pretty well-documented. And my hunch is that for the increasingly large number of people coming into the industry who don't read quickly or well, the efficiency of learning from videos is closer to parity with text. What's more, I suspect there's high correlation between lower reading skills and dislike of the act of reading, so videos are a way to avoid having to do something unpleasant.
I have no solid evidence to back any of this up, but it seems at least as plausible to me as any other explanations I've run across.
Me either, but I have a hunch about why.
Are you a fast reader?
I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere close, I have to crank the playback speed up so high that I start having trouble understanding what the presenter is saying. That's on top of other things like poor searchability and no way to copy-paste code snippets.
The decline of reading skills, at least in the US, is pretty well-documented. And my hunch is that for the increasingly large number of people coming into the industry who don't read quickly or well, the efficiency of learning from videos is closer to parity with text. What's more, I suspect there's high correlation between lower reading skills and dislike of the act of reading, so videos are a way to avoid having to do something unpleasant.
I have no solid evidence to back any of this up, but it seems at least as plausible to me as any other explanations I've run across.
That’s a really interesting take. I say that as I’m the opposite — a slow reader — and I, too, cannot stand learning via video.
I’m by no means a weak reader, I love reading and do so often. I just find myself re-reading complex sections to ensure that I understand 100%.
I also like to be able to read something and then follow it on a train of thought. For example, if a post/article says that X causes Y because of Z I want to find out why Z causes it. What causes Z to be etc.
With a video I find this sort of learning to be inefficient and less effective while also making the whole experience a bit rigid. I also find that videos tend to leave out less glamorous details as they don’t video well if that makes sense
I’m by no means a weak reader, I love reading and do so often. I just find myself re-reading complex sections to ensure that I understand 100%.
I also like to be able to read something and then follow it on a train of thought. For example, if a post/article says that X causes Y because of Z I want to find out why Z causes it. What causes Z to be etc.
With a video I find this sort of learning to be inefficient and less effective while also making the whole experience a bit rigid. I also find that videos tend to leave out less glamorous details as they don’t video well if that makes sense
I'm also a slow-reader by your standards, re-reading to me is part of the learning process. Going over text with your eyes is not reading, let alone learning.
I think your dislike of video over text is because you're a quick learner. Like you said, going on a tangent and researching some word or sentence or statement makes you a thorough learner I think. Eventually you have a quicker and bigger grasp of the subject at hand, which is the whole point if you ask me.
I think your dislike of video over text is because you're a quick learner. Like you said, going on a tangent and researching some word or sentence or statement makes you a thorough learner I think. Eventually you have a quicker and bigger grasp of the subject at hand, which is the whole point if you ask me.
Thanks mate! I think I consider myself a slow reader as I’ve grown up with my mother and sister who both read at some ungodly pace. They’ll finish 5 books for every one which I finish.
I do agree with the thorough learner aspect. I think having come from physical engineering backgrounds helps a lot with that.
When studying aerospace, for example, there was a lot of ‘but why’ which usually ended up leading to ‘natural phenomenon’ after abstracting far enough.
I do agree with the thorough learner aspect. I think having come from physical engineering backgrounds helps a lot with that.
When studying aerospace, for example, there was a lot of ‘but why’ which usually ended up leading to ‘natural phenomenon’ after abstracting far enough.
Alternatively: you can listen to audio while commuting or driving or cleaning or working out. I love audio for higher level things and to get an overview of the topic. Then text to dive into the details.
Another big driver to move from text to video: It is easier to monetise video via YouTube compared to a blog. People with millions of subscriptions on YouTube aren't creating FE learning material out of the goodness of their hearts; it is a big business. Also, video is almost always lower information density compared to text, so it is easier for your net to capture more customers.
And you can't just search in it. It's truly trashy format for anything other that presentation or lecture. For simple information sharing it's horrible.
We millenials ruined the doorbell industry by texting “here”. (Always connected)
Gen Z just sends you a picture of your door. (Mobile broadband)
What we perceive as the best way is often just driven by the technology available when we learned how to operate in the world.
Gen Z just sends you a picture of your door. (Mobile broadband)
What we perceive as the best way is often just driven by the technology available when we learned how to operate in the world.
I think you nailed it.
Another example of advertising destroying the world.
Another example of advertising destroying the world.
It can be quite difficult to follow programming topics over audio only, so it's not interchangeable with video in this case.
I have a fairly fast reading speed, but I mostly consume my non fic (not technical) books in audio format.
Why? Attention span. If someone is reading to me, I tend to get 'pushed along' and it makes it easy to slog through a non fiction book that really could have been a pamphlet but the author needed it to be 400 pages. If I space out listening, it's usually not a problem because most non fic books are so repetitive. I suspect that's the secret behind video's popularity, people's attention is in short supply.
Why? Attention span. If someone is reading to me, I tend to get 'pushed along' and it makes it easy to slog through a non fiction book that really could have been a pamphlet but the author needed it to be 400 pages. If I space out listening, it's usually not a problem because most non fic books are so repetitive. I suspect that's the secret behind video's popularity, people's attention is in short supply.
I’m a pretty slow reader. I tend to reread sections, pause and play around with the ideas that come into my head, get lost while doing that and have to start over… I still prefer reading specifically because it allows me to do all that at my own pace. I don’t have to feel rushed along by a presenter or actively pause, rewind, try to scrub the timeline to find a point I want to rehash etc.
I really think you have got a point, I'd add however that reading is more cognitive effort than watching a video, at a basic level (that is, information in the text or video put aside).
Just see how hard it is to read more than a few paragraphs when tired before bed vs. how hard it is to watch something in the same state.
I think this gets added to the point you are making about reading skills declining.
Just see how hard it is to read more than a few paragraphs when tired before bed vs. how hard it is to watch something in the same state.
I think this gets added to the point you are making about reading skills declining.
People learn best in different ways. Some learn best by reading, some by tinkering, some by watching and listening. I heard this over and over in school and college.
I don’t think it has anything to do with reading speed. When taking in complex technical information, you spend more time thinking and trying to understand than actually reading.
If you’re finding that you can quickly race through content, it probably just means you find the content easy to understand because you’re already familiar with many concepts.
I don’t think it has anything to do with reading speed. When taking in complex technical information, you spend more time thinking and trying to understand than actually reading.
If you’re finding that you can quickly race through content, it probably just means you find the content easy to understand because you’re already familiar with many concepts.
> no solid evidence
IMO you don’t need any. The correctness of your conclusion is self-evident. Proof by common sense, QED.
IMO you don’t need any. The correctness of your conclusion is self-evident. Proof by common sense, QED.
I happen to agree with the conclusion also. And you don't need a rigorous proof to do what you want to do. But I often find that people appeal/resort to "common sense" when they don't have a coherent argument, and just can't conceive of any other point of view.
>, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions.
That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.
I like (some) programming videos and I'll give my perspective as someone who learned 100% from books and 3-ring binders for old languages like C/C++/C#/Javascript/Python/bash/etc. (The 1980s Microsoft C Compiler manuals were 3-ring binders.)
The newer languages I learned with a hybrid of videos + traditional books would be HTML CSS, Apple Swift, and PyTorch with the latest AI toolkits and libraries.
The extra dimension that videos offer besides plain text is the live usage of IDE, tools, troubleshooting, etc. For me, watching a dynamic screen with a moving mouse cursor and voiceover seems to activate extra neurons moreso than just reading static text in a book.
There's also a lot of "activities in-between the coding" that's helpful such as seeing the programmer looking up something in various pages of documentation, scrolling around, navigating etc.
Another useful aspect that's underappreciated is seeing the mistakes the programmer makes during the video recording. E.g. the code doesn't compile because of invalid syntax. Or a config setting is wrong and he troubleshoots what's preventing it from working. In contrast, virtually all text books or blogs of coding are "perfect happy path" outcomes. But real-world programming is messy with broken intermediate states. A lot of videos show the messy steps to get to a working state.
The videos that are not that helpful would be the videos of C++ CppCon conference sessions where there are a bunch of static slides with bullet points and the speaker just reads them aloud word-for-word.
Although I learned C++ from textbooks, I found videos of Matt Godbolt showing tips & tricks of how to use his Compiler Explorer (http://godbolt.org) very helpful.
In summary, the artifacts of coding may be the text, but the activity of coding involves a lot more than just the text and that's why some videos can enhance learning.
I like (some) programming videos and I'll give my perspective as someone who learned 100% from books and 3-ring binders for old languages like C/C++/C#/Javascript/Python/bash/etc. (The 1980s Microsoft C Compiler manuals were 3-ring binders.)
The newer languages I learned with a hybrid of videos + traditional books would be HTML CSS, Apple Swift, and PyTorch with the latest AI toolkits and libraries.
The extra dimension that videos offer besides plain text is the live usage of IDE, tools, troubleshooting, etc. For me, watching a dynamic screen with a moving mouse cursor and voiceover seems to activate extra neurons moreso than just reading static text in a book.
There's also a lot of "activities in-between the coding" that's helpful such as seeing the programmer looking up something in various pages of documentation, scrolling around, navigating etc.
Another useful aspect that's underappreciated is seeing the mistakes the programmer makes during the video recording. E.g. the code doesn't compile because of invalid syntax. Or a config setting is wrong and he troubleshoots what's preventing it from working. In contrast, virtually all text books or blogs of coding are "perfect happy path" outcomes. But real-world programming is messy with broken intermediate states. A lot of videos show the messy steps to get to a working state.
The videos that are not that helpful would be the videos of C++ CppCon conference sessions where there are a bunch of static slides with bullet points and the speaker just reads them aloud word-for-word.
Although I learned C++ from textbooks, I found videos of Matt Godbolt showing tips & tricks of how to use his Compiler Explorer (http://godbolt.org) very helpful.
In summary, the artifacts of coding may be the text, but the activity of coding involves a lot more than just the text and that's why some videos can enhance learning.
I'm not sure if this is what you intended, but I read this as a great argument in favor of pair programming.
Definitely. As long as the videos are uncut, they can be a confidence booster that I'll be able to replicate the result, because I can follow them knowing they won't skip over those little steps that often go without mention. Well, unless they're being sneaky with hotkeys.
These videos are edutainment at best, which is generally not a good way to learn something well enough to be able to actually work with it. A lot of them are pretty much straight up entertainment, where the entertainment value comes from drama and strong opinions. They're totally fine if you know that, but some of their audience does not know that.
I've been seeing more and more of a certain kind of person who are into these videos on some Discord servers, and it is clear that they are driven more by culture and style than by the goal of creating some thing, or having a strong understanding of how to make computers do certain things.
I've been seeing more and more of a certain kind of person who are into these videos on some Discord servers, and it is clear that they are driven more by culture and style than by the goal of creating some thing, or having a strong understanding of how to make computers do certain things.
> That people like video formats isn't really surprising to me since it's everywhere
That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.
That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.
Likely these videos did not exist when your reference / age group was acquiring these skills.
Videos are sort of easier to produce (via screen capture), and are much easier to show the effect of FE things: look, we write code like this, now we can click here, and the page reacts that way. No need to muck with JSFiddle or something.
I'm not a fan of videos as a reference medium, but they can be elucidating to those who needs more hand-holding, literally "click here, see the result". Back in the day, a few short videos about Blender helped me quite bit to grasp certain things that were not obvious from descriptions.
Videos are sort of easier to produce (via screen capture), and are much easier to show the effect of FE things: look, we write code like this, now we can click here, and the page reacts that way. No need to muck with JSFiddle or something.
I'm not a fan of videos as a reference medium, but they can be elucidating to those who needs more hand-holding, literally "click here, see the result". Back in the day, a few short videos about Blender helped me quite bit to grasp certain things that were not obvious from descriptions.
I've learned most of what I know about database internals from MCU lecture course on YouTube. It's great.
Famous YouTube influencer checks notes Carnegie Mellon university.
Marvel cinematic university?
I assume its CMU, Carnegie Mellon u
You wouldn't believe what else you can learn there.
I learned a new definition of boredom.
This correlates to my parent post - when my generation started with Flash around 2000 there was no literature on how to programm in Flash, it just happened.
So we went to the nearest bookstore and got a bunch of other books on programming. For many Flash developers the bible was Thinking in Java by Bruce Eckel. Most of the source materials for game programming (and that was a lion share of Flash programming) was in C++.
I'm not claiming that we were smarter, but by sheer coincidence, most people, even folks like me who skipped school, had very solid fundamentals. And partially due to the fact that it wasn't that lucrative back then.
Today most people don't care, IT is just easy money, kids have short attention span and trends are tailored by tiktok videos. All in all, it's just a fashion driven developement.
So we went to the nearest bookstore and got a bunch of other books on programming. For many Flash developers the bible was Thinking in Java by Bruce Eckel. Most of the source materials for game programming (and that was a lion share of Flash programming) was in C++.
I'm not claiming that we were smarter, but by sheer coincidence, most people, even folks like me who skipped school, had very solid fundamentals. And partially due to the fact that it wasn't that lucrative back then.
Today most people don't care, IT is just easy money, kids have short attention span and trends are tailored by tiktok videos. All in all, it's just a fashion driven developement.
>I'm not claiming that we were smarter, but by sheer coincidence, most people, even folks like me who skipped school, had very solid fundamentals.
Higher barrier of entry should statistically lead to less people making it past and that those who do make it past aren't a random sampling of the initial group making the attempt. While the selection isn't only for intelligence, specifically the subsets of intelligence related to programming, I would doubt any claims it wasn't a factor at all.
Higher barrier of entry should statistically lead to less people making it past and that those who do make it past aren't a random sampling of the initial group making the attempt. While the selection isn't only for intelligence, specifically the subsets of intelligence related to programming, I would doubt any claims it wasn't a factor at all.
It's not about learning (anymore). It's about consuming content. People spending (wasting) their time on X and YT are not there to learn something but to get their social media (dopamine) fix.
I hate YT, X, Insta. Don't even have an account. Some years ago there was really great content on YT, now it's mostly clickbait.
I hate YT, X, Insta. Don't even have an account. Some years ago there was really great content on YT, now it's mostly clickbait.
There's still lots of great YT content, much of it by the same producers you allude to, and they need your support more than ever with all the slop around them.
Here's one:
https://remix.run/
These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :(
And they just promote it and promote it:
https://kentcdodds.com/blog/a-review-of-my-time-at-remix
https://kentcdodds.com/blog/why-i-love-remix
https://kentcdodds.com/courses
Pure grift. But since most people are decent people they don't know and fall for it, and something like this influencer emerges. They have entire Discords of customers, the same as crypto scams.
Edit: I don't know why people would downvote calling out a notable grifter in a thread that extended out to a discussion about influencers. WHICH influencers? Are we scared of that topic? The climate of the JS ecosystem didn't happen accidently.
People fall victim to this shit right here on HN, and then write blog posts about what the fuck is wrong with frontend:
https://news.ycombinator.com/item?id=39453767
(This entire thread reads like deliberate testimonials.)
Stop buying this stuff.
https://remix.run/
These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :(
And they just promote it and promote it:
https://kentcdodds.com/blog/a-review-of-my-time-at-remix
https://kentcdodds.com/blog/why-i-love-remix
https://kentcdodds.com/courses
Pure grift. But since most people are decent people they don't know and fall for it, and something like this influencer emerges. They have entire Discords of customers, the same as crypto scams.
Edit: I don't know why people would downvote calling out a notable grifter in a thread that extended out to a discussion about influencers. WHICH influencers? Are we scared of that topic? The climate of the JS ecosystem didn't happen accidently.
People fall victim to this shit right here on HN, and then write blog posts about what the fuck is wrong with frontend:
https://news.ycombinator.com/item?id=39453767
(This entire thread reads like deliberate testimonials.)
Stop buying this stuff.
I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach people about a framework. But the idea that the entire thing was created just to sell courses about it is not true.
But I do agree that there’s just way too much fast moving, breaking changes on front end in general, frameworks released every other week, etc…
But I do agree that there’s just way too much fast moving, breaking changes on front end in general, frameworks released every other week, etc…
But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.
It does. It bridges a purely server-rendered architecture with a SPA really nicely, and does it mostly with web standards. You don't need to run any client-side JS with a Remix app. It's not perfect, but there are a lot of benefits to its approach.
I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI at work.
But this "The web was perfect in 1999--stop changing things!" take is tedious and intellectually lazy. (I'm not accusing you of it, but it's certainly a common sentiment.)
We should be working together to solve concrete problems, and avoid both chasing the latest fads and pretending there's no room for improvement.
I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI at work.
But this "The web was perfect in 1999--stop changing things!" take is tedious and intellectually lazy. (I'm not accusing you of it, but it's certainly a common sentiment.)
We should be working together to solve concrete problems, and avoid both chasing the latest fads and pretending there's no room for improvement.
It’s a nuanced topic. If we want to dive in, I can provide a glimpse into the first layer of the anus as we stick our head into it.
When we shepherded a lot of sheep into frontend via these courses and boot camps and quasi courses/bootcamps in the form of certain frameworks (hey, you only know this one framework?), we created a cohort of something.
Now what is that something? It’s not really the tinkerer that loves doing this stuff and would have found a way to express themselves (please pay attention to the word “express”, as in, can’t help it). That something was … a pragmatic identity. A pragmatic identity was formed where “I am now a software engineer because I and my cohort agree, we really know how to do our stuff”.
Such a cohort can only be fueled by identity, not passion. This cohort can’t innovate and must cling to the identity of their original accreditation, so they will always be defensive.
That’s the first layer of the asshole as we enter it, it goes deeper. The second layer involves large amounts of money and people’s livelihoods, to which they’d defend unto death.
When we shepherded a lot of sheep into frontend via these courses and boot camps and quasi courses/bootcamps in the form of certain frameworks (hey, you only know this one framework?), we created a cohort of something.
Now what is that something? It’s not really the tinkerer that loves doing this stuff and would have found a way to express themselves (please pay attention to the word “express”, as in, can’t help it). That something was … a pragmatic identity. A pragmatic identity was formed where “I am now a software engineer because I and my cohort agree, we really know how to do our stuff”.
Such a cohort can only be fueled by identity, not passion. This cohort can’t innovate and must cling to the identity of their original accreditation, so they will always be defensive.
That’s the first layer of the asshole as we enter it, it goes deeper. The second layer involves large amounts of money and people’s livelihoods, to which they’d defend unto death.
I don't believe you want to have a productive conversation about this. It sounds like you just want to be angry.
Okay? I'm having a lot of fun talking about some of the parts of our circus. I can't change anything. There will be new cult leaders (evangelists) for frameworks, and new cohorts, we can't change the past. Just pay attention to the rough framework (no pun intended, swear) as it happens again, and try our best to call it out, because it didn't always lead to great outcomes.
Money will be made on all sides regardless and we will all be fine financially. I'm talking about something else, inner. The infinite anus, asshole, is real - but now I'm just projecting.
Money will be made on all sides regardless and we will all be fine financially. I'm talking about something else, inner. The infinite anus, asshole, is real - but now I'm just projecting.
> mostly with web standards
IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great.
At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain.
Especially because we haven't finished any of these migrations:
* ExtJS -> JQuery
* JQuery -> React class components
* React class components -> MobX-observed components
* Observable MobX components -> functional React components with context
* Functional React Components with context -> React Router v6
* React Router v6 -> Remix w/ GraphQL federation
I understand my situation is unique - I'm just bitter from needing to know ~6 different frontend technologies at once. Let alone all the Not-Invented-Here-Syndrome abominations in our codebase.
IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great.
At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain.
Especially because we haven't finished any of these migrations:
* ExtJS -> JQuery
* JQuery -> React class components
* React class components -> MobX-observed components
* Observable MobX components -> functional React components with context
* Functional React Components with context -> React Router v6
* React Router v6 -> Remix w/ GraphQL federation
I understand my situation is unique - I'm just bitter from needing to know ~6 different frontend technologies at once. Let alone all the Not-Invented-Here-Syndrome abominations in our codebase.
[deleted]
It's not that unique. The one enterprise app I worked on (that was started with Rails 1) had all of: Prototype, jQuery, Backbone, Angular, React, Handlebars AND mustache, vanilla CSS, SASS, CSS in JS (or whatever it's called). I wouldn't be surprised if they've introduced Tailwind at this point.
This is also a project started w/ Rails 1, so I feel our experiences may be similar.
To be fair to both code bases - it's very impressive that they're still running, right?
To be fair to both code bases - it's very impressive that they're still running, right?
Definitely!
It actually wasn't even THAT bad considering how huge it is. People still complained (admittedly myself included), but it had been TDD'd from the start so had very good test coverage, at least. Also, some people who had worked on really massive Java applications called it "really good!" so it's all about perspective, I suppose :)
It actually wasn't even THAT bad considering how huge it is. People still complained (admittedly myself included), but it had been TDD'd from the start so had very good test coverage, at least. Also, some people who had worked on really massive Java applications called it "really good!" so it's all about perspective, I suppose :)
Remix already has data loading, why add GraphQL? It's a pain in the ass to work with from my brief experience.
That's my point exactly. I have the same questions from leadership.
your last note that adds not-invented-here abominations… if chasing endless frameworks of the month is bad, and building stuff in house is bad, then what do you propose to avoid making this mess?
I would propose that if you want to change frameworks, actually complete the migration from one technology to the other.
My problem is having all of them existing at once.
My problem is having all of them existing at once.
Skip a couple framework versions and indeed entire frameworks. Maybe go a couple years before you "upgrade" to something else. It is entirely possible you could go as much as 5 or 10 years on something. You'll still have to evaluate and potentially mitigate some CVE's. But that could actually be less work and less aggravating.
But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.
My point being, it's "based on" Web Standards, it is _not_ Web Standards.
What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before.
If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?
What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before.
If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?
My favorite example of this being JSON gets converted to FormData on the frontend, which then gets POST-ed to the server, which then converts it to JSON on the backend.
[deleted]
I think you're mistaken. I can't comment on the quality of Kent C. Dodds' educational content, but his formal affiliation with Remix was short-lived. The courses that he sells have no apparent affiliation with Remix (the open source project or the company).
Incidentally, Remix is an open source project started by the React Router devs to create more framework features around React Router. React Router is probably one of the most widely deployed JavaScript libraries ever and is the furthest thing imaginable from a project created by grifters to sell online courses.
Remix was also a company that raised a $3 million seed round and then was acquired by Shopify (for presumably much more than $3 million). Shopify appears to continue to invest heavily in Remix and React Router development, and appears to use Remix heavily.
Incidentally, Remix is an open source project started by the React Router devs to create more framework features around React Router. React Router is probably one of the most widely deployed JavaScript libraries ever and is the furthest thing imaginable from a project created by grifters to sell online courses.
Remix was also a company that raised a $3 million seed round and then was acquired by Shopify (for presumably much more than $3 million). Shopify appears to continue to invest heavily in Remix and React Router development, and appears to use Remix heavily.
While his formal affiliation may have been short-lived, do you think he got a cut of the sale to Shopify?
If so, not disclosing that when he promotes Remix is a bit shady.
Nice dude and all, but that is one thing I take issue with still.
If so, not disclosing that when he promotes Remix is a bit shady.
Nice dude and all, but that is one thing I take issue with still.
I don't think it's weird to like a piece of software and have that lead you to work at the company that builds the software and also to develop an educational course about that software.
[deleted]
Not weird to do all that. Just weird to not disclose it.
There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
Promoting it? No problem. But promoting something you profited from without disclosing it violates FCC rules for broadcasting. I would say influencers aren't technically broadcasting but they are in principle.
[deleted]
> React Router is probably one of the most widely deployed JavaScript libraries ever and is the furthest thing imaginable from a project created by grifters to sell online courses.
This is a funny example (to me) because in 2017, one of the two co-creators of React Router (Michael) came to my job and gave a two or three-day in-person training course on React. I think he also covered Redux and React Router. We had a great time getting to know him.
It turns out that Ryan and Michael spent a substantial amount of time and effort on a side business called React Training. It is fair to say that their speaking engagements were a solid revenue stream, but agreed - definitely not grifters.
This is a funny example (to me) because in 2017, one of the two co-creators of React Router (Michael) came to my job and gave a two or three-day in-person training course on React. I think he also covered Redux and React Router. We had a great time getting to know him.
It turns out that Ryan and Michael spent a substantial amount of time and effort on a side business called React Training. It is fair to say that their speaking engagements were a solid revenue stream, but agreed - definitely not grifters.
[deleted]
[deleted]
In case anyone isn't familiar with remix, bloomingkales seemingly has no familiarity with the framework. Obviously it's not been created as a conspiracy to sell training courses. The idea is ludicrous.
It's quite a nice framework. It's easy to learn, straightforward, the people in their discord are very helpful. It has the backing of a large company (shopify) who are using it extensively.
It is, I'll say again, obviously not a conspiracy to sell training courses.
It's quite a nice framework. It's easy to learn, straightforward, the people in their discord are very helpful. It has the backing of a large company (shopify) who are using it extensively.
It is, I'll say again, obviously not a conspiracy to sell training courses.
I get why you might feel that way. Ryan and Michael used to run a company based around React training. They created React Router which some people love to complain about. They've since moved over to working for Shopify. Shopify pays for their development on React Router/Remix. They do NOT sell training anymore.
Kent on the other hand, worked with them for a short time. He makes his living selling training. Filling in a gap (selling training) isn't really a grift is it? The dude's got a family and he's found something he can sell.
Kent on the other hand, worked with them for a short time. He makes his living selling training. Filling in a gap (selling training) isn't really a grift is it? The dude's got a family and he's found something he can sell.
Not sure it's fair to characterize a repo with 6k + commits and the last being 10 hours ago as "pure grift".
E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training.
Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.
Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.
Do you know anyone who bought courses on react-router? The documentation is right there for free.
Wasn't react-training.com owned by the react-router people? I wonder what the training consultants recommended to use for routing...
And what's wrong with that? It works good if you're building an SPA in React.
You asked if react-router team sold courses, they sold consulting services. Seems like a conflict of interest to sell consulting on a tool you built while introducing breaking changes (but hey if you need quick help throw us a few dozen grand).
I guess that's fine for you but it's very smarmy IMO.
I guess that's fine for you but it's very smarmy IMO.
They also post (free) documentation how to migrate from the previous major version
[deleted]
[deleted]
[deleted]
You know you can just read rfc's right? there is a reason they update the thing, because people use it. https://github.com/remix-run/react-router/discussions/catego...
I think that adds to my point. How does that have so many stars on github? The customers "star" it. Who uses this on a real app? It's alright to slowly accept the bitter truth that grifting scales.
Not really sure that's relevant. Grift implies an intentional value extraction without providing anything. Using your example: I'm confident that the time spent working on remix and courses related to it resulted in far less monetary gain than spinning out courses on React. If you think Remix is misguided or a bad framework etc... that is very different from grifting. A corollary: Is Deno a grift because it shares the same creator as Node and has a paid product attached to it? In my opinion no but you might disagree... I'm mostly opposed to the idea remix in particular exists purely as a grift - love it or hate it there are far easier ways for someone with the influence of Kent to make money.
Imagine someone made Deno with a corresponding course to go along with it. I would consider that a grift.
https://frontendmasters.com/courses/remix/
That was the end goal for this whole thing. I do look at the pricing page (what are you trying to sell constantly?) on anything people put up on the internet and judge from there. You can have the last word and put in a testimonial for Remix, since I won't be budging on this. It's a rabbit hole for both you and me to keep going at this, as I've seen enough of this pattern. Consider me a neural net on this front (end).
https://frontendmasters.com/courses/remix/
That was the end goal for this whole thing. I do look at the pricing page (what are you trying to sell constantly?) on anything people put up on the internet and judge from there. You can have the last word and put in a testimonial for Remix, since I won't be budging on this. It's a rabbit hole for both you and me to keep going at this, as I've seen enough of this pattern. Consider me a neural net on this front (end).
I'm not interested in writing a testimonial for Remix, merely commenting on the absurdity of calling a project of this scale as nothing more than a grift to sell educational content. There's no reference to these paid courses anywhere on the landing page, there's no callout for paid courses in the main navigation. The only mention of tutorials at all is buried in the community section which leads to: https://remix.guide/ which seems to be unaffiliated with the Remix team, and has no section advertising paid courses anywhere. You're talking about a framework that has been acquired and subsequently used in production by a global company in Shopify - clearly there is something to the framework beyond being a vehicle for tutorial sales.
Again, I want to be clear: This is NOT an endorsement of Remix. Your line of thinking seems to be conspiratorial and not grounded in reality. You mention repeatedly about pricing and the end goal of funneling noobs toward course purchases... One would assume that in conspiring to sell courses the team behind Remix might actually advertise that they have courses for sale on their website.
I have to be honest as a third party that a. doesn't work with remix, b. doesn't know anyone who works on remix, c. doesn't know you - it seems like you have a personal vendetta.
Again, I want to be clear: This is NOT an endorsement of Remix. Your line of thinking seems to be conspiratorial and not grounded in reality. You mention repeatedly about pricing and the end goal of funneling noobs toward course purchases... One would assume that in conspiring to sell courses the team behind Remix might actually advertise that they have courses for sale on their website.
I have to be honest as a third party that a. doesn't work with remix, b. doesn't know anyone who works on remix, c. doesn't know you - it seems like you have a personal vendetta.
No personal vendetta. We sit here and punch the mysterious air as to why things are the way they are. I thought maybe we'd punch up at something that is plausibly a culprit. I'll admit it may be punching down, since this is just one dude. But then again, it's one dude who influenced a lot of people ...
We can't just keep sitting here and blaming developers for being
1) New
2) Dumb
3) FOMO
4) Dumb
5) Unqualified
You understand? It's worth looking at what content they are consuming and where the mindshare is being promoted from. It's worth asking who is selling them the idea of these frameworks.
We can't just keep sitting here and blaming developers for being
1) New
2) Dumb
3) FOMO
4) Dumb
5) Unqualified
You understand? It's worth looking at what content they are consuming and where the mindshare is being promoted from. It's worth asking who is selling them the idea of these frameworks.
> We can't just keep sitting here and blaming developers for being New / Dumb …
Well, as a cohort, I think the ratio of inept programmers to skilled programmers stays mostly constant regardless of stuff like this. Like, if programming is hard to learn, fewer people will try and learn it. But also the skill bar goes up - so people spend more time as inept developers before they’re skilled. Likewise if programming gets easier to learn, we get a swell of fresh faces eager to become frontend developers. And the ratio stays more or less the same. It’s kinda like a sales funnel, or a hiring funnel. You always have more leads in your funnel than conversions. (And if you don’t, you’re in trouble!)
We live in an anti gatekeeper era. Content is free, but nobody protects you from wasting your time watching edutainment. The downside of that is real - lots of people waste countless hours larping as students. But the upside is real too. It’s easier than ever to learn anything.
Well, as a cohort, I think the ratio of inept programmers to skilled programmers stays mostly constant regardless of stuff like this. Like, if programming is hard to learn, fewer people will try and learn it. But also the skill bar goes up - so people spend more time as inept developers before they’re skilled. Likewise if programming gets easier to learn, we get a swell of fresh faces eager to become frontend developers. And the ratio stays more or less the same. It’s kinda like a sales funnel, or a hiring funnel. You always have more leads in your funnel than conversions. (And if you don’t, you’re in trouble!)
We live in an anti gatekeeper era. Content is free, but nobody protects you from wasting your time watching edutainment. The downside of that is real - lots of people waste countless hours larping as students. But the upside is real too. It’s easier than ever to learn anything.
[deleted]
>Grift implies an intentional value extraction without providing anything.
Is it without providing anything, or a value extraction greater than what one is providing?
If the former, it makes the definition very each to check, but it almost makes it very easy to avoid grifting by providing even the most minimal value, and leads use to needing a new word for providing some value but extracting more than provided (perhaps intention should be included). If that is the case, might I suggest "jrift"?
Is it without providing anything, or a value extraction greater than what one is providing?
If the former, it makes the definition very each to check, but it almost makes it very easy to avoid grifting by providing even the most minimal value, and leads use to needing a new word for providing some value but extracting more than provided (perhaps intention should be included). If that is the case, might I suggest "jrift"?
And what have you put out into the world?
I called out a grifter.
And what have you put out into the world?
I push back on stuff like this so developers who feel the feet on their throat from this culture can have some confidence to nudge the boot off.
There goes my hero: https://youtu.be/EqWRaAF6_WY
There goes my hero: https://youtu.be/EqWRaAF6_WY
I can tell you that your response is at least relevant for me because I happen to be working with Remix right now, not because of any influencers but just because I happen to be working on a Shopify project. I've seen lots of frameworks come and go and evolve, so I'm not surprised that this one changes a lot, but I always enjoy getting opinions from people with experience. Whether or not I'll end up resenting it in the future, I don't know, but at least I'll have been warned.
[deleted]
[deleted]
[deleted]
I get shorts in my feed and it’s all Front End developers. It’s all stupid JS behaviour and other inconsequential stuff.
> web dev influencers
The fact that there's influencers for everything nowadays made me realize I'm old.
It's super useful that everyone is sharing their opinions and expertise to get that sweet 5 minutes of fame - I just learned how to tile my bathroom after watching a slew of TikToks on the subject, some with millions of views.
The fact that there's influencers for everything nowadays made me realize I'm old.
It's super useful that everyone is sharing their opinions and expertise to get that sweet 5 minutes of fame - I just learned how to tile my bathroom after watching a slew of TikToks on the subject, some with millions of views.
I can read pretty fast, but prefer videos for introductions to any new tech.
Then if I decide I like it I read the manual.
Then if I decide I like it I read the manual.
I think it used to be much worse. While the youtube/Tiktok churn might be much more active than 5 years ago, back in the ancient era of 2018-2016, the churn was driven by the fact that tooling sucked, which was capitalized on by people who were very good at self promotion but a lot less good at engineering.
I'm not a 'frontend guy', but I do write frontend code. I use Typescript React with hooks and context most of the time, rollup with esbuild to bundle and to run my dev workflows and raw CSS/SCSS for styling or Bootstrap for cookie-cutter UIs. I've also dabbled with Svelte.
This stack has served me well, and nothing here is newer than 5 years old. There's a cadre of much newer technology that I would consider stable (Vite + SvelteKit), but since new projects come with a maturity curve from the framework side and a learning curve, learning to troubleshoot issues and solve problems.
Anyone who constantly hops frameworks is doomed to be a perpetual amateur, working with buggy frameworks they know nothing about, and they will leave a trail of projects using deprecated frameworks in their wake.
I'm not a 'frontend guy', but I do write frontend code. I use Typescript React with hooks and context most of the time, rollup with esbuild to bundle and to run my dev workflows and raw CSS/SCSS for styling or Bootstrap for cookie-cutter UIs. I've also dabbled with Svelte.
This stack has served me well, and nothing here is newer than 5 years old. There's a cadre of much newer technology that I would consider stable (Vite + SvelteKit), but since new projects come with a maturity curve from the framework side and a learning curve, learning to troubleshoot issues and solve problems.
Anyone who constantly hops frameworks is doomed to be a perpetual amateur, working with buggy frameworks they know nothing about, and they will leave a trail of projects using deprecated frameworks in their wake.
Yeah, back in my day being an "influencer" required being able to crack copy protection mechanisms and add an intro into the loading screen, or animations deemed impossible in the given hardware, while remaining anonymous behind a group handle.
With fame being slowly propagated via tapes and floppies sent by mail, or some BBS archives.
Now you comment on what others do, or commit single function packages.
With fame being slowly propagated via tapes and floppies sent by mail, or some BBS archives.
Now you comment on what others do, or commit single function packages.
True, the barrier to becoming a tech influencer are very low now and yet it's harder than ever. This suggests that dumb luck plays an increasing role.
Current tech influencers are generally smart and qualified but they aren't experts in anything specific and they aren't innovative in any way. They are chosen by algorithms out of a large pool of possible candidates.
Current tech influencers are generally smart and qualified but they aren't experts in anything specific and they aren't innovative in any way. They are chosen by algorithms out of a large pool of possible candidates.
> This suggests that dumb luck plays an increasing role.
Nah. It’s not luck. It’s charisma. And skill at performance & in many cases clowning. Some people just have that certain something that makes people enjoy listening to them. It can be learned, but like programming it takes a lifetime to master. And like programming, some people are naturals at it.
I know because I’ve been training in improv theatre and clowning for the last 6 years. That’s enough that I could tell you in detail what people like the Primagen or Joe Rogan are doing. But I can’t replicate it. I’m way better than I was, but I’m nowhere near their skill level as a performer.
Nah. It’s not luck. It’s charisma. And skill at performance & in many cases clowning. Some people just have that certain something that makes people enjoy listening to them. It can be learned, but like programming it takes a lifetime to master. And like programming, some people are naturals at it.
I know because I’ve been training in improv theatre and clowning for the last 6 years. That’s enough that I could tell you in detail what people like the Primagen or Joe Rogan are doing. But I can’t replicate it. I’m way better than I was, but I’m nowhere near their skill level as a performer.
I don't agree with this position. Primagen worked at Netflix. This is already a massively significant luck component. I watched a video of his where he describes how he got his job at Netflix and it sounds like he got very lucky, by his own account. The brand recognition and network effects of having worked at Netflix cannot be underestimated. I'm sure he also got lucky in other ways. When you really dig into stories like his, you can find so many cases where they got abnormally lucky... Many cases where you're reading and think "wow, that's just not plausible, this does happen in the real world." Like reading the Steve Jobs biography, there are so many things that don't make sense... Like when Steve Jobs was young and he called the CEO of some company asking for some electronic component and they sent it to him... I did a lot of this cold calling when I was younger and nobody ever did that for me, even for much smaller companies and asking for much smaller favors.
There's no doubt the Primeagen has a popular channel (459K subs at last count), but his videos are super annoying to me. Many of them are just him reading a blog post and adding some light clowning to it. To me it feels like a waste of time...I can just read the article myself a lot faster and the clowning doesn't add any value to me.
I feel the same way. I don’t think you and I are the target audience for him. My read is that his content is actually pitched to a very junior audience - or an audience who don’t really want to read or engage with the blog post themselves. They want to feel smart and entertained without doing any actual thinking.
That sounds like I’m a snob - but I really get it. I’ve been watching Inkmaster lately with my gf - which is a reality tv show about tattooing. It’s super fun sitting on the couch judging all the tattoos they do. It would be nowhere near as much fun if I had to actually think, or do work while watching the show.
I think primagen is like that. It’s kinda like a trashy reality tv show about programming. If you don’t know any programming, you’ll probably learn a thing or two along the way. But you aren’t going to become a great software engineer by watching his channel. Not any more than I’m going to become a great tattoo artist by sitting on my arse, eating chocolate and watching ink master. I still do it. But I wouldn’t call it educational.
That sounds like I’m a snob - but I really get it. I’ve been watching Inkmaster lately with my gf - which is a reality tv show about tattooing. It’s super fun sitting on the couch judging all the tattoos they do. It would be nowhere near as much fun if I had to actually think, or do work while watching the show.
I think primagen is like that. It’s kinda like a trashy reality tv show about programming. If you don’t know any programming, you’ll probably learn a thing or two along the way. But you aren’t going to become a great software engineer by watching his channel. Not any more than I’m going to become a great tattoo artist by sitting on my arse, eating chocolate and watching ink master. I still do it. But I wouldn’t call it educational.
> But I wouldn’t call it educational.
Edutainment perhaps?
Edutainment perhaps?
Yeah, I really do think "edutainment" is the correct classification for this type of content. A lot of tech influencers have figured out the formula for success on YouTube. In order to hit the sweet spot, the content has to be a mile wide and an inch deep to get the engagement metrics necessary to make the channel profitable.
It is incredibly pertinent. Even with the 20+ years of web dev I sometimes get swayed with clickbait like "If you are not using <frontend tech x> you are behind the curve, you are missing out, nobody works this way anymore, you are toast." This is an incredibly harmful take from those influencers. I do remember when it started - and it came from a good place, from a desire to "modernize from jQuery soup". But what it turned to now is noise that is sometimes hard to ignore.
It is only natural for a dev to ask themselves "am I still current? am I still relevant?". The induced FOMO triggers the worst bits of that anxiety, and sometimes I feel the influencers do not realise just how harmful this is.
It is only natural for a dev to ask themselves "am I still current? am I still relevant?". The induced FOMO triggers the worst bits of that anxiety, and sometimes I feel the influencers do not realise just how harmful this is.
I also don't think these front end influencers are even coding very much. Like if you hired them on a job on a serious team, they would probably come off like a junior engineer
I get that same vibe. It seems like their intent is to "wow" others into thinking how easy it is to become a developer and build an app with X framework. When in reality they just built a todo app that barely resembles how real software is built.
Yeah, it seems sort of obvious in its own way. People like “the primagen” on YouTube are really entertainers first and educators second. The pitch is something like “I’ll pretend to teach you something, and you’ll pretend to learn. But actually I’ll just entertain you by being a goofball for 20 minutes. You don’t have to do any work, and afterwards you can walk away pretending like you learned something”.
I suspect in his case he might actively dumb down his skill level for the stream, so he doesn’t scare away the junior devs.
I suspect in his case he might actively dumb down his skill level for the stream, so he doesn’t scare away the junior devs.
[deleted]
The #1 tell is that all their projects are solo.
Working on a team,
working with peers,
building software systems the live in production for years,
through change and expansion,
all seem beyond the typical influencer.
It doesn't help that JS projects are often thin wrappers around thin wrappers where the project owner puts more work into their Vitepress logo than a stable API.
It all seems like it is for CV glory. Then the projects don't see a commit for years.
It all seems like it is for CV glory. Then the projects don't see a commit for years.
Maybe now that’s a factor, but this has been a problem with FE development for many years, well before these influencers showed up.
I'm only recently getting into some of the dev influencer stuff (and enjoying watching some!), I've discovered Primeagen and Theo but that's about it. Are you willing to name some names? I am trying to still form my mental model about these people and what I should pay attention to and what I should ignore.
I agree with the other comment. Ignore them all, go with the fundamentals. Heck, ask chatgpt what do they think are the fundamental ideas in computer science and go from there. Look for classic books written on those subjects. There have been plenty of smart people around the sw field who took years of their lives to write succint and valuable technical books! Use them! Ignore the poison-mixers who probably didn't write a single line of code in their whole life!
Go for a decent text editor, learn how to type! It's incredible how we use ai tools to write code for us but some don't know how to actually write themselves! Again, look it up, there are plenty of resources out there. If in doubt, search for said resources here on hn. If still in doubt, ask chatgpt what does the hn community recommend for x or y.
Go for a decent text editor, learn how to type! It's incredible how we use ai tools to write code for us but some don't know how to actually write themselves! Again, look it up, there are plenty of resources out there. If in doubt, search for said resources here on hn. If still in doubt, ask chatgpt what does the hn community recommend for x or y.
You should ignore all of it. They mostly sell the idea of a developer to you, the same with any marketing. That's what an influencer does, they make you feel good about buying a cheap identity.
They're just entertainment. Like throwing on a movie or tv show.
I found value in a handful of Primeagen's videos (he inspired me to relearn C programming in a roundabout way) but the vast majority are fluff and I skip them based on the title or within the first 5 minutes.
A couple exceptions are Low Level Learning and Tsoding, who both generally stay technical, and any guest appearance by Casey Muratori will be worthwhile.
But even those, you're better off with a book or your own project to work on.
I found value in a handful of Primeagen's videos (he inspired me to relearn C programming in a roundabout way) but the vast majority are fluff and I skip them based on the title or within the first 5 minutes.
A couple exceptions are Low Level Learning and Tsoding, who both generally stay technical, and any guest appearance by Casey Muratori will be worthwhile.
But even those, you're better off with a book or your own project to work on.
Not an influencer but: Casey Muratori is great.
He's actually the opposite of the "trendsetter" kind that is being criticized here, and is more of an educator with lots of experience in both education and business.
He's actually the opposite of the "trendsetter" kind that is being criticized here, and is more of an educator with lots of experience in both education and business.
I agree. He's by far my favorite "very YouTube famous" programmer and it isn't even very close.
Yeah, I dig what Casey is doing. Subscribe to him instead of these other clowns. I like how his stuff isn't glossy or overproduced—he just gets down to the content.
Primeagen and Theo is pure brain rot.
Idk Theo reminds me so heavily of a "freelance frontend developer" I had to bear with on my team for a while. Eventually even my manager caught on to how pretentious and incompetent he was, so luckily it was a short intermezzo. An opinion on everything but not a clue of anything
The best programming videos I've seen are ones where someone just pointed a camera at a teacher in a classroom setting, like the Programming Paradigms series Jerry Cain did at Stanford some years ago. No attempt to add entertainment value, just a teacher, students, and chalkboards. I wish I could find more content like that, especially about newer stuff.
[deleted]
Have you checked out https://ocw.mit.edu/ ? They have a ton of MIT courses online for free in the format you just described.
I truly enjoy the Primeagen. I've watched him since he started on Twitch. I don't ever really see him pushing any particular agendas at all. Mostly he's either trying new things, or working on projects. That's pretty much been his jam since day one. He has opinions, sometimes they're counter to the typical dev takes. Theo is much more likely to have a commonly shared opinion. That's not necessarily a bad thing if you're into NextJS (I'm not). I just don't feel like either of those guys are trying to get me to buy stuff.
If you think they are fun to watch, watch them for entertainment, but don't fool yourself into believing that this is "learning".
Their content is the definition of "video on the most googled keywords of the day" and the quality is about what you would expect. just consider how much content they pump out and how much time it takes to actually get into any of the topics they "cover" on a daily switching basis.
If you're watching for entertainment and, importantly, they're not selling you courses or a project they have a vested interest in, I wouldn't worry much.
Remember to take them as another perspective, not a source of truth.
The most problematic influencers are the ones who have pivoted to selling courses. If you find yourself thinking about dropping hundreds of dollars on someone's video course, spend a couple days reading free learning materials first so you can realize that it's almost always not worth it, no matter how much the smiling cheerful influencer pretends they're only trying to help you.
Remember to take them as another perspective, not a source of truth.
The most problematic influencers are the ones who have pivoted to selling courses. If you find yourself thinking about dropping hundreds of dollars on someone's video course, spend a couple days reading free learning materials first so you can realize that it's almost always not worth it, no matter how much the smiling cheerful influencer pretends they're only trying to help you.
Prime is almost an anti-influencer. He promotes not adding dependencies more often than not. He's the guy making fun of the Ai craze, while also genuinely reviewing the recent releases and saying people should just learn to code instead. I really wouldn't put him in this general category of fe influencers discussed here.
His style is very much brain rot-like though. It's way more "entertainment" (though it isn't very entertaining to me) than informational content.
Meanwhile Primagen: " I Am Using Cursor - CURSOR FOUNDER TEACHES ME CURSOR!!!!!!! #ad "
Relevant YouTube video:
Dear Developer, the Web Isn't About You
https://www.youtube.com/watch?v=WYXSck7TyVM
Dear Developer, the Web Isn't About You
https://www.youtube.com/watch?v=WYXSck7TyVM
> Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about
I feel sad to hear that. I thought that the decrease in the VC-money flow would also slow down the number of new FE-related frameworks entering the mainstream, but it seems I was wrong then
I feel sad to hear that. I thought that the decrease in the VC-money flow would also slow down the number of new FE-related frameworks entering the mainstream, but it seems I was wrong then
And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart.
15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications!
Almost all of the front end churn is simply a political/organizational failure.
15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications!
Almost all of the front end churn is simply a political/organizational failure.
I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm.
It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this.
I was doing it today to create a gantt chart from mermaid.
I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
I was doing it today to create a gantt chart from mermaid.
I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM.
At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
I did that a few years ago and it was fascinating: not only did it remove near-weekly React dependency churn, it produced significant performance improvements (multiple orders of magnitude better update speed - and yes, I did the usual incantations), and the total lines of code in our repo actually went down and it was easier code because it just did what was necessary without having to deal with layers of abstractions designed to work around earlier problems created by the framework.
One of the things I realized while working on it was that it was easy because I’ve learned the web platform over the years and was able to use builtin features rather than reaching for more libraries, but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around. That allows them to be productive, of course, but it often means that people take on layers of dependencies because once they’ve invested a lot in that path the cost of switching is really high.
One of the things I realized while working on it was that it was easy because I’ve learned the web platform over the years and was able to use builtin features rather than reaching for more libraries, but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around. That allows them to be productive, of course, but it often means that people take on layers of dependencies because once they’ve invested a lot in that path the cost of switching is really high.
> but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around
Last release of IE6: 2008
Concerted campaign to make everybody stop using IE6: 2009
Microsoft joins that campaign: 2011
First release of React: 2013
Last release of IE6: 2008
Concerted campaign to make everybody stop using IE6: 2009
Microsoft joins that campaign: 2011
First release of React: 2013
It may be hard to remember now that we’ve had frequently-updated browsers for so long but not everyone updated promptly. That lead to a lot of now-vestigial frontend culture where developers would build around the oldest browser they couldn’t afford not to support.
That colored a lot of low-level decisions about how events were implemented, false claims about virtual DOMs being fast or efficient, and especially the culture of adding dependencies because you need a feature which wasn’t in Internet Explorer. Once that trend is established, it’s hard to change without breaking compatibility and so you end up with people in 2025 using slower code based on the support matrix set over a decade earlier.
(And to be clear, I’m not saying that React has no redeeming values - only just it’s healthy to reconsider decisions made in previous decades to see whether the cost/benefit ratio has changed. I think we’re going to see some really interesting shifts as funding for open source shifts in a non-boom economy, but also as LLMs adjust the working style & relationship many people have to maintenance.)
That colored a lot of low-level decisions about how events were implemented, false claims about virtual DOMs being fast or efficient, and especially the culture of adding dependencies because you need a feature which wasn’t in Internet Explorer. Once that trend is established, it’s hard to change without breaking compatibility and so you end up with people in 2025 using slower code based on the support matrix set over a decade earlier.
(And to be clear, I’m not saying that React has no redeeming values - only just it’s healthy to reconsider decisions made in previous decades to see whether the cost/benefit ratio has changed. I think we’re going to see some really interesting shifts as funding for open source shifts in a non-boom economy, but also as LLMs adjust the working style & relationship many people have to maintenance.)
The major turn for the average user was actually 2009/2010. IE6 usage seems to have dropped below 1% by 2012, still before React's public release: https://www.theverge.com/2019/5/4/18529381/google-youtube-in...
That said, I was on a team that was still supporting IE6 around 2014. We had clients, mostly in China from what I heard, that were required to use it because internal tooling had developed around it and their IT teams wouldn't let them upgrade.
That said, I was on a team that was still supporting IE6 around 2014. We had clients, mostly in China from what I heard, that were required to use it because internal tooling had developed around it and their IT teams wouldn't let them upgrade.
Yeah, I worked on things geared towards the general public so we had to support, say, a senior citizen who was using old computers at the underfunded library or senior center. They weren’t a high percentage of total traffic but it was still millions of people.
It was definitely frustrating knowing that a better world was possible but not quite there.
It was definitely frustrating knowing that a better world was possible but not quite there.
If you are in the US, it's more likely than not that your local/state court system is managed by software that runs almost entirely on VBScript within an IE7 wrapper.
[deleted]
This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Homebrew dependencies were expected on the last git commit date.
The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Homebrew dependencies were expected on the last git commit date.
> This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
I know, I've had to revive and make small changes to an old Angular project myself. Which is my point.
If the underlying technology hasn't really changed, why constantly break the tooling and compatibility in general?
This collective lack of discipline is exactly why I don't work in FE. It's just tiresome for no actual reason.
If the underlying technology hasn't really changed, why constantly break the tooling and compatibility in general?
This collective lack of discipline is exactly why I don't work in FE. It's just tiresome for no actual reason.
I also haven’t seen it in any other place. Game dev and backend which I’ve worked in uses the same technologies for decades. It’s like someone trying to write a book but instead of writing a new chapter each month they mess about with their ink choice and their font choice and their paper roughness and get very little actual progress
> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas.
The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project.
Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bower, which FE used before using npm), and suddenly the advice became to just not program those things yourself, download the module.
But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
Even today, it's possible to care about your project enough to not bloat the invisible parts too much, if you want to be able to continue to work on the project. Again, requires restraint, and going back to the "I only need a function from this library so instead of depending on the entire library, lets just copy-paste this function into our codebase and add some tests" way of dealing with minor things.
So I guess what I'm ranting about, is that this is a people and process problem, not a JavaScript problem, because there are a lot of us JS developers who don't suffer from this problem, while large parts of the ecosystem does.
The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project.
Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bower, which FE used before using npm), and suddenly the advice became to just not program those things yourself, download the module.
But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
Even today, it's possible to care about your project enough to not bloat the invisible parts too much, if you want to be able to continue to work on the project. Again, requires restraint, and going back to the "I only need a function from this library so instead of depending on the entire library, lets just copy-paste this function into our codebase and add some tests" way of dealing with minor things.
So I guess what I'm ranting about, is that this is a people and process problem, not a JavaScript problem, because there are a lot of us JS developers who don't suffer from this problem, while large parts of the ecosystem does.
I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.
Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI.
Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language.
React is far more stable to build with and far less experimental.
People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere.
You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.
Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language.
React is far more stable to build with and far less experimental.
People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere.
You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.
"Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI."
"People who have never touched any UI tech until HTML/JS have no clue how good they have it"
Tech like:
- Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments?
- Qt, developed and maintained for over 30 years, currently at 6th major release?
- Win32, and frameworks built on top of it like MFC, WinForms, WPF?
Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.
"People who have never touched any UI tech until HTML/JS have no clue how good they have it"
Tech like:
- Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments?
- Qt, developed and maintained for over 30 years, currently at 6th major release?
- Win32, and frameworks built on top of it like MFC, WinForms, WPF?
Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.
Just to reinforce how stable the desktop environment can be:
- Qt has had a mostly stable interface since Qt 4.0 and that was twenty years ago.
- Win32 has had barely any breaking changes since it was introduced with NT 3.1 in 1993 or so.
Most of the UI/UX churn in that space comes from fashion changes in UI design.
- Qt has had a mostly stable interface since Qt 4.0 and that was twenty years ago.
- Win32 has had barely any breaking changes since it was introduced with NT 3.1 in 1993 or so.
Most of the UI/UX churn in that space comes from fashion changes in UI design.
On the other hand, I can write a very complicated graphics-related app in React+tons_of_libs within _days_. It took me months to do that in Win32 API in 2005.
The developer velocity enabled by React is insane.
The developer velocity enabled by React is insane.
Yes, saying that calling Win32 APIs is not the most ergonomic approach to writing UIs would be an understatement, but if any software can be called stable, this is it.
I would compare win32 API to vanilla JS. Whatever framework you might want to use on top of win32 is what's comparable to the criticized web tech in the article.
Calling Win32 directly was already old fashion when Windows 95 came out in 1994, let alone 2005 when .NET was four years old.
The only folks already doing Win16 development with pure C code, instead of a C++ framework (OWL, MFC, VCL), VB or Delphi, were stuck in jurassic park.
The only valid reason for raw Win32 applications are games.
The only folks already doing Win16 development with pure C code, instead of a C++ framework (OWL, MFC, VCL), VB or Delphi, were stuck in jurassic park.
The only valid reason for raw Win32 applications are games.
I liked it in the Jurrasic park
> Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments
Not always. I attempted to upgrade some open source 32bit Delphi frontend code to 64bit/ARM, but the specific GUI toolkit was never ported.
It's similar for Java frontends, JavaFX in particular seems to be a moving target.
QT is a bit of an outlier in terms of frontend stability, but at the cost of the UI looking pretty dated.
Not always. I attempted to upgrade some open source 32bit Delphi frontend code to 64bit/ARM, but the specific GUI toolkit was never ported.
It's similar for Java frontends, JavaFX in particular seems to be a moving target.
QT is a bit of an outlier in terms of frontend stability, but at the cost of the UI looking pretty dated.
Qt apps UI can look very good if QML is used with some effort. I wrote about it here: https://rubymamistvalove.com/block-editor
This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.
And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.
I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another).
I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.
I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.
Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right.
The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.
The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.
I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React.
My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer.
As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer.
As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a post graduate students custom niche language. And I want to say the redux kid's background was literally microsoft powerpoint scripting. Very surreal time in development.
FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created.
Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS.
See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation:
- https://redux.js.org/understanding/history-and-design/histor...
- https://redux.js.org/understanding/history-and-design/prior-...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS.
See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation:
- https://redux.js.org/understanding/history-and-design/histor...
- https://redux.js.org/understanding/history-and-design/prior-...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
We need a Behind the Javascript VH1 show.
Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.
People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap.
Well gosh darnit, then everyone and their mother is going to come to America
It's an age old envy.
Well gosh darnit, then everyone and their mother is going to come to America
It's an age old envy.
I'm a back-end dev, I've avoided being paid to do any front-end work (and/or my bosses have avoided paying me to do any front-end work? hahaha) for getting on a decade now. So no doubt front-end devs will cringe at what I'm about to say (not that I care!). But for the occasional personal front-end stuff that I still do, my "dependency management" is just "copy-paste versioned CDN script tags / CSS link-rel tags into my index.html file". Which is equivalent to (but better than) old-skool copy-pasting into a "vendor" directory" (which of course I also did, back in the day). And my "front-end build system" is just "write vanilla javascript in .js files and include it un-minified un-typescripted un-anything via script tags". I've got better things to do in my spare time, than deal with npm / gulp / yarn / whatever they've invented this week.
> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).
It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.
This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).
It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.
> backed by a SasS service and VC money
While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.
A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.
By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.
The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).
If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.
While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.
A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.
By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.
The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).
If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.
Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too.
But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.
I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.
I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.
For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:
1) Can't update react without updating react-router because react deprecated some API
2) Can't update react-router without updating react because the new version of react-router is using some new API from react
And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.
I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...
For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:
1) Can't update react without updating react-router because react deprecated some API
2) Can't update react-router without updating react because the new version of react-router is using some new API from react
And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.
I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...
At this point in time this is absolutely a "people and process" problem. But also the process that is there has been excercised and is known to folks you may hire. Trying to come up with less of it (or with a different version of it) dramatically shrinks the number of people who can be productive on your product from day 1, and is not a choice to be made lightly. There is also a number of people who will then be spending time convincing you that the "none" or "less" process you have imposed is wrong and you should "just get on with the program".
The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes.
There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.
One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.
One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
It depends on what you want to build. If you want to build impressive B2C software, this sounds like a recipe for disaster. I've worked with many backend engineers masquerading as full stack engineers who couldn't carbon copy a simple mockup design into a working UI if their life depended on it. Yet they never seem to notice how bad their implementation is, sometimes not even if you point it out to them even if the end users would notice; I think these engs are so enamored with their work they're in some kind of denial about the shortcomings. And that's just the visual parts. There's also skill required to take accessibility and conformance with web standards into account (HTML/CSS/JS stack is devious in that it lets you do things in ways that are "wrong"), which you can't easily fix later on by tweaking a bit here and there. So without this understanding, you end up with a crappy UI that's overengineered for what it is. Of course that all won't be an issue if you're building software you can sell even if the UI makes its users depressed.
Not saying your typical frontend engineer is flawless either. It's probably true that they're, on average, not as skilled sw architects as backend engineers, simply because a lot of their work focuses on details instead of architecting, and, again, the HTML/CSS/JS stack is incredibly flexible, in good and bad.
Not saying your typical frontend engineer is flawless either. It's probably true that they're, on average, not as skilled sw architects as backend engineers, simply because a lot of their work focuses on details instead of architecting, and, again, the HTML/CSS/JS stack is incredibly flexible, in good and bad.
It's fair to point out that there is real skill involved in that kind of work. However, I don't trust the average "frontend developer" to do pixel perfect implementations either. Many of them don't even seem to know CSS anymore. And not to discount your experience, but being able to implement a design is something that is easily testable when evaluating candidates. Because I come from the multimedia agency world, most of the candidates I've hired were actually for that kind of role. Accidentally hiring people who can't do the work points to a competency issue with management. As I've pointed out elsewhere, I have the awards to speak authoritatively on this. But perhaps me focusing on average skill is just an unfair way to look it, since I'm never really looking for average anyways.
The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior.
For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.
I totally get your point. I'll just give you a little color about where I'm coming from. Most products don't need a team of over five frontend/backend devs (so imagine a team of 10 people). Most teams have been over staffed. When you are overstaffed, that's when everyone needs to be cookie cutter
with cookie cutter expectations (e.g backend should do ui, frontend should backend). On non-overstaffed teams, the core group compliments each other very well and brings extreme expertise. No one on such a team ever goes "I can do what that guy does", because it's not a run of the mill mass market team.
I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.
I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.
That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.
Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.
Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.
I've also experienced the other end. As a pithy saying goes, "it takes a lot of skill to write Java in every language."
> Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.
I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.
I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.
I think that culture will happen somewhere anyway, and FE being the battle ground is probably because it's the most visible part of the experience.
I mean: some people will want to reinvent the wheel, and preferably carve their name in some monument while doing so. And there will also always be an impulse to create busywork as it's the tide that rises all the boats, inflating the workforce in the field.
The staggering costs of breaking APIs is to some a feature, not a bug, and the field will attract more and more like-minded people who then accelerate that trend.
To note, BtoB focused startups usually go for a completely different FE stacks, including long deprecated ones, or even plain staticly generated sites wherever they can get away with it.
I mean: some people will want to reinvent the wheel, and preferably carve their name in some monument while doing so. And there will also always be an impulse to create busywork as it's the tide that rises all the boats, inflating the workforce in the field.
The staggering costs of breaking APIs is to some a feature, not a bug, and the field will attract more and more like-minded people who then accelerate that trend.
To note, BtoB focused startups usually go for a completely different FE stacks, including long deprecated ones, or even plain staticly generated sites wherever they can get away with it.
> But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.
It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.
As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type.
All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something!
The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.
All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something!
The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.
I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented.
What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about.
A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not.
Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about.
A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not.
Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list.
If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend. There are lots of great languages you can use for a backend. Java, C#, Go, lots of stuff. Js and python are the kind of languages you choose when you either don't know any other language or you don't know that they're ass.
The only good excuse to use JS is that your code needs to run in a browser. The only good excuse to use python is that you're just making a tiny little toy thing. Or you're doing data science stuff/ML, in any case you're not creating a large complex application. And you certainly don't care much about performance.
People invest so much time and money into creating more JS libraries and frameworks and stuff when what we should really be investing time and money into is creating an actually good language for the web. JS is the epitome of sunk cost fallacy.
"But TS" no. TS is just JS with a bunch of overly complicated type bullshit you have to deal with. It is a better dev experience than JS so I do use it, but it's less a cure and more a band aid over the huge, gaping and pus-dripping wound that is JS.
If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend. There are lots of great languages you can use for a backend. Java, C#, Go, lots of stuff. Js and python are the kind of languages you choose when you either don't know any other language or you don't know that they're ass.
The only good excuse to use JS is that your code needs to run in a browser. The only good excuse to use python is that you're just making a tiny little toy thing. Or you're doing data science stuff/ML, in any case you're not creating a large complex application. And you certainly don't care much about performance.
People invest so much time and money into creating more JS libraries and frameworks and stuff when what we should really be investing time and money into is creating an actually good language for the web. JS is the epitome of sunk cost fallacy.
"But TS" no. TS is just JS with a bunch of overly complicated type bullshit you have to deal with. It is a better dev experience than JS so I do use it, but it's less a cure and more a band aid over the huge, gaping and pus-dripping wound that is JS.
JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.
Yeah I'm aware that it works. I'm just saying it's a bad choice. It's slower than most other languages, the language itself is just plain bad, the standard library is poor, npm isn't great, there's really just no good reason to use it other than "our devs don't know anything else".
> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something.
And by "in JS", you really mean, "in NPM land".
So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue.
NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)
And by "in JS", you really mean, "in NPM land".
So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue.
NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)
the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you.
Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
I understand why they had to EOL Vue 2 and make Vue 3 - I'm still facing migrating a couple of projects at some point, and I will keep putting it away x)
But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
[deleted]
Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”.
NPM sucks. It's not the way to do JS
${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.
NPM sucks. It's not the way to do JS
${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.
Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works.
A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
This is exactly why I am a huge fan of ember.js
Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
Ember is one of those frameworks that isn't as "flashy" as the latest and greatest javascript frameworks, but it just keeps quietly working and adopting new techniques from the more popular frameworks on a consistent and easy to follow schedule. They even make upgrading to the latest way of doing things relatively painless by providing scripts to automate many upgrades for you.
> 1. Before removing a feature in a major version, it lands as a deprecation in the previous major. A deprecation is only enabled by default once we have a clearly documented migration strategy that covers the use-cases of the old feature.
> 2. When we ship a new major, the only thing it does it flip deprecations targeting that new major into errors.
https://bsky.app/profile/wycats.bsky.social/post/3lg2p5dwuzk...
> 1. Before removing a feature in a major version, it lands as a deprecation in the previous major. A deprecation is only enabled by default once we have a clearly documented migration strategy that covers the use-cases of the old feature.
> 2. When we ship a new major, the only thing it does it flip deprecations targeting that new major into errors.
https://bsky.app/profile/wycats.bsky.social/post/3lg2p5dwuzk...
I'm thinking of building a long term living app (say an app that I will use the next 30 years).
It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript.
The fewer things you have in your stack, the fewer things can change under your feet.
The fewer things you have in your stack, the fewer things can change under your feet.
Go for web components. It's guaranteed to last 30 years
If you MUST use a framework, then yes i would go with ember because they have a prooved commitment to following the web standards rather than creating their own custom standards that they throw away the next year.
Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.
Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.
If you are designing for that kind of long term I suggest looking into SmallTalk. A lot changes in 30 years.
The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it.
No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.
It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.
No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.
It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.
> No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.
To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.
To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.
I agree, it seems like popular packages really need an LTS release channel or something. Enterprises do not have budget or time to continuously invest in their front end tools.
Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.
Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.
> it seems like literally everything is deprecated
I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen.
I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?
I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen.
I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?
but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvious reason.
Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
I mean the browser and security does change somewhat often so there's that.
> Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes.
That so many libs take advantage of semver is both good and bad.
> Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes.
That so many libs take advantage of semver is both good and bad.
Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.
Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?
Well, what's wrong is your mindset, if anything. You're not supposed to do anything. npm still works, it isn't deprecated, and it does more or less the same thing as the others, only that others can be slightly faster.
But if npm/yarn/whatever works for you, just use that thing. The mindset of having to move to whatever "mainstream developers" are using today is what is causing you problem, not that alternative solutions exists in the first place.
But if npm/yarn/whatever works for you, just use that thing. The mindset of having to move to whatever "mainstream developers" are using today is what is causing you problem, not that alternative solutions exists in the first place.
Main difference between all of them is speed. There’s some differences in how npm, yarn, pnpm or bun handle workspaces and hoisting (and stuff like dependency overrides) but if one of them works for you, you rarely have to switch between them.
Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
With respect, you almost certainly stopped paying attention for much longer than six months. yarn v2 was a significant rewrite that was released five years ago and a lot of Yarn projects either never upgraded or just switched back to npm (because npm eventually addressed most of the major reasons that yarn was better than npm).
`pnpm` was released back in 2016. It's 9 years old at this point.
I think part of the problem is this thinking that
- you must change things all the time (yarn is still good why switch?)
- the things you change to are somehow really new (pnpm is 9 years old)
I think part of the problem is this thinking that
- you must change things all the time (yarn is still good why switch?)
- the things you change to are somehow really new (pnpm is 9 years old)
Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988.
I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.
Hardly a deal-breaker; presumably I can just pipe the output to less.
npm is not deprecated and is a pretty good choice. pnpm is a bit nicer in some details, but it's a nonstandard tool - use it if you're familiar with frontend development enough that you understand the tradeoffs you're making, but otherwise sick with npm.
npx is a tool bundled with node/npm for running commands in isolated environments. It's mostly useful in two situations:
* You want to run a particular NPM-distributed tool as a one-off, and have the tool installed outside of your current project and then uninstalled afterwards. This can be useful for scaffolding or trying out tools released using NPM.
* You have a local project and one of the dev dependencies provides a utility to e.g. lint the code or run a migration. npx allows you to directly call commands installed locally without having to set up `npm run` beforehand.
If you don't know why you need it, you don't need it.
npx is a tool bundled with node/npm for running commands in isolated environments. It's mostly useful in two situations:
* You want to run a particular NPM-distributed tool as a one-off, and have the tool installed outside of your current project and then uninstalled afterwards. This can be useful for scaffolding or trying out tools released using NPM.
* You have a local project and one of the dev dependencies provides a utility to e.g. lint the code or run a migration. npx allows you to directly call commands installed locally without having to set up `npm run` beforehand.
If you don't know why you need it, you don't need it.
No, we're past pnpm and on to bun now
Bun may be fine for people using it to replace the javascript runtime
As a dependency management toolchain I recommend reading: https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothi...
I had some issues with it using it briefly (though it was way faster than other installers I've used)
As a dependency management toolchain I recommend reading: https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothi...
I had some issues with it using it briefly (though it was way faster than other installers I've used)
Sorry, everyone’s on pyarn now and next month we’re deprecating that for pbun and then starting from scratch with taquito when that doesn’t solve all our perceived problems
But first you need corepack because globally installing yarn is BAD
Corepack is marked experimental but trust us bro
oh if you don't have corepack just install it globally (this is fine)
If you do have it, you have to opt into the experiment by running "corepack enable"
So simple
Corepack is marked experimental but trust us bro
oh if you don't have corepack just install it globally (this is fine)
If you do have it, you have to opt into the experiment by running "corepack enable"
So simple
Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist.
FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)
FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)
I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json.
I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up.
I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up.
I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.
Okay thanks for your patience. I put together this gist based on an interaction we had with a user last year, I hope it's helpful: https://gist.github.com/bignimbus/457f9ac42f29d0bb6c4eb742ad...
That matches my experience as well.
Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search.
X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced.
A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search.
X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced.
A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.
Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.
>>The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated.
I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc.
Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features.
I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend.
Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc.
Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features.
I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend.
Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
I’m getting back into development after being a photographer for the last 10 years and after reading your comment I thought “maybe I should apply at a bank…”
This.
I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends.
And every time it leads to a complete rewrite.
And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season.
The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers.
I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise.
I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming.
And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.
I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends.
And every time it leads to a complete rewrite.
And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season.
The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers.
I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise.
I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming.
And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.
Many bring the same mindset to backend as well. In my small team of less than 10 developers we use C#, Java, Kotlin, Rust, Elixir, Go, Javascript, Typescript, and Python to worry about and maintain because developers have been allowed to pick what they want.
I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume
I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume
> because developers have been allowed to pick what they want.
That's a technical leadership failure first and foremost
That's a technical leadership failure first and foremost
You could make exactly the same complaint about python packaging. We've gone from setuptools, to pip, to poetry and now uv.
GraphQL is such an exciting addition to the front end stack. Imagine, an entire new system you need to learn that cargo cult proponents love and also sucks ass to use.
decides to swap out a working package manager for another for no apparent reason
"Why do JS people keep doing something new for no apparent reason?"
"Why do JS people keep doing something new for no apparent reason?"
The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.
I'd gladly swap out any piece of tooling if it's written in JavaScript.
There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This leads to a loop of unrealistic optimism.
1. Library X promises to abstract everything away in an easy-to-use way
2. Devs adopt X and it makes work fast and fun.
3. The human element forces in tons of edge cases.
4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.
5. Devs start looking for an abstraction that works and goes back to the first stage.
I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.
Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.
If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.
The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.
I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.
DRY is a means to an end rather than an end in itself.
This leads to a loop of unrealistic optimism.
1. Library X promises to abstract everything away in an easy-to-use way
2. Devs adopt X and it makes work fast and fun.
3. The human element forces in tons of edge cases.
4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.
5. Devs start looking for an abstraction that works and goes back to the first stage.
I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.
Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.
If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.
The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.
I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.
DRY is a means to an end rather than an end in itself.
> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.
This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.
Like a challenge to write better code that is still bad enough to throw away as soon as possible, I think there's something to scripting that feels enticingly ephemeral.
Fully agreed that the amount of "that was last year's answer" is obscenely frustrating.
Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
I fully agree, _but_ it's not just frontend, it's the entire NPM ecosystem. Meaning it's not much better in NodeJS (or Deno/Bun/whathaveyou)
It's more or less always been like this.
It's why I moved to mainly backend (where feasible).
Because someone has to maintain that crap at some point.
It's why I moved to mainly backend (where feasible).
Because someone has to maintain that crap at some point.
Part of the problem is that React monopolized the entire space and most other frameworks became legacy; not able to maintain even a tiny community.
The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit.
This is why frontend development is so bad these days.
The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit.
This is why frontend development is so bad these days.
I've been working on a small side project on-and-off for the last year and some. The state-of-the-art decisions I made last year are already dead. There's a new version of everything, and everything was a breaking change, nothing is backwards compatible.
How do people live like this?
How do people live like this?
They don't. They say fuck it and learn a trade.
This is why I stopped doing front end.
This has been the most amazing thing about ClojureScript - finding libraries that are 10+ years old without an update still work perfectly. Using reagent and over time learning more and more of the internals (instead of the runaway treadmill in js land).
I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.
I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.
Meanwhile, I can go dig up some open source Objective-C/AppKit Mac app project that hasn’t seen any activity in 20 years and probably get it compiling and running in an evening. Cleaning out warnings might take a weekend.
I wonder what it’d take to achieve that kind of stability over time in the web front end world…
I wonder what it’d take to achieve that kind of stability over time in the web front end world…
[deleted]
I'm still using npm and wasn't sure if I should use yarn or pnmp, is there a clear winner here on this one?
Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.
Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.
pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you.
Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies.
Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks).
tldr: I'd recommend pnpm.
Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies.
Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks).
tldr: I'd recommend pnpm.
Cool, thanks!
I've not anything this succinct between them before.
I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.
This is why I have been so pumped for LiveView. It just removes so much javascript from the equation
And when you need to use JS, you can do so in a clean and controllable way.
Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input
Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview
https://surface-ui.org/
Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input
Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview
https://surface-ui.org/
[deleted]
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc
My theory is that they do it because they don't have enough to do.
My theory is that they do it because they don't have enough to do.
one wonder how this liability of a tech stack became so popular. i have a theory it was VC dollars pumping up a ton of saas tools and they all came out with one-click integrations.
this is one house of cards that may never really be fixed.
this is one house of cards that may never really be fixed.
I work mostly on the JVM world, with Java/Kotlin. Two comments:
In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good).
In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).
In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good).
In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).
My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"
One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.
laughs in C99
This experience is one of the reasons people love Phoenix LiveView so much.
> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies
Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here:
I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options.
Maybe that is what the author meant and I am just misreading.
Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here:
I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options.
Maybe that is what the author meant and I am just misreading.
Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself.
However, that said I agree with you. Especially so when it comes to things like consulting work, contracting, etc. Having worked alongside the people who do the hiring or make the decision as to whether to bring somebody in for an interview at all in big consulting firms, they basically automatically disqualify anybody who doesn't already know the stack they prefer to use or that the client they are currently hiring somebody for uses. And this is including technical architects, so this isn't even just an issue of non-tech aligned hiring people. They simply don't want anybody to have to ramp up on the tech itself regardless of skill.
For these types of roles it is very important to be up to date if you want to stay hirable, or the hiring manager will just throw your resume in the trash before it even gets in front of an engineer who can evaluate your skills without the buzzwords.
However, that said I agree with you. Especially so when it comes to things like consulting work, contracting, etc. Having worked alongside the people who do the hiring or make the decision as to whether to bring somebody in for an interview at all in big consulting firms, they basically automatically disqualify anybody who doesn't already know the stack they prefer to use or that the client they are currently hiring somebody for uses. And this is including technical architects, so this isn't even just an issue of non-tech aligned hiring people. They simply don't want anybody to have to ramp up on the tech itself regardless of skill.
For these types of roles it is very important to be up to date if you want to stay hirable, or the hiring manager will just throw your resume in the trash before it even gets in front of an engineer who can evaluate your skills without the buzzwords.
Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"
I always interpret “core” as “no libraries”. What can you do with just your browser and an HTML file?
Poke through MDN and see what you find.
Do you know about dialog? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
MutationObserver? https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
URL? https://developer.mozilla.org/en-US/docs/Web/API/URL_API
Poke through MDN and see what you find.
Do you know about dialog? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
MutationObserver? https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
URL? https://developer.mozilla.org/en-US/docs/Web/API/URL_API
Thanks! I looked at MutationObserver and wondered about the example:
Anyway, not to get too mired in details... I've done no front-end dev, but I'm building a mobile app that'll need administrative pages for me (or, hopefully, other staff) to use. Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?
I like to hand-roll stuff from the basics, by all means, but I already have my hands full with a back end and a client application.
if (mutation.type === "childList") {
console.log("A child node has been added or removed.");
Anyway, not to get too mired in details... I've done no front-end dev, but I'm building a mobile app that'll need administrative pages for me (or, hopefully, other staff) to use. Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?
I like to hand-roll stuff from the basics, by all means, but I already have my hands full with a back end and a client application.
Consider an HTML fragment being inserted into the DOM as a result of a user interaction. If the fragment contains elements which need event listeners attached, or any other js-enabled behavior (like a progressively enhanced select component) the mutation observer can see it arrive (or leave) the DOM, and attach or remove the listeners. You write your initialization code for the enhanced select once somewhere, and then use mutation observer to handle its lifecycle management. (Edit: this isn't a theoretical pattern, it's what I'm using in our frontend at work.)
How can such changes occur to the DOM that aren't brought about by other code on the page? And if other code on the page brought them about, why didn't it also perform whatever the MutationObserver is doing?
You're right, that approach would also work. But MutationObserver can be useful for decoupling, to reduce complexity -- you don't need to think about all the possible ways some part of the page could change, you just want to be able to say "if the contents of this div change, do this".
I used it in a recent project for layout animations. I needed to measure the size of a particular div that slides in and out, to position it correctly, so I added a MutationObserver to re-runs the calculation any time there are changes.
Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?
Well, pretty much all frameworks will claim to be that...!
I think some things you might find useful are:
- Polyfills. Just use standard browser APIs (which are getting really good these days) but use polyfills to ensure they work correctly/consistently across different browsers.
- Web components. I haven't used these myself, but as I understand it, it's a way of packaging JS modules so they can be used exactly like new HTML tags. So somebody could make a nice <calendar> component for example. I've heard that Lit is a good library for developing web components, but it's not a framework in the sense that it will take control of your whole architecture.
- Vite. This bundles your HTML, scripts and assets -- you can develop your code in vanilla HTML and JS, and Vite will package it up neatly for publishing. It's really fast and reliable. Tons of frameworks are built on top of Vite, but you can go quite a long way just with Vite on its own (and there isn't any lock-in as its input is just HTML).
You're right, that approach would also work. But MutationObserver can be useful for decoupling, to reduce complexity -- you don't need to think about all the possible ways some part of the page could change, you just want to be able to say "if the contents of this div change, do this".
I used it in a recent project for layout animations. I needed to measure the size of a particular div that slides in and out, to position it correctly, so I added a MutationObserver to re-runs the calculation any time there are changes.
Is there a "next-level up" front-end layer that provides convenience functions but still isn't a bloated framework liable to be obsolete?
Well, pretty much all frameworks will claim to be that...!
I think some things you might find useful are:
- Polyfills. Just use standard browser APIs (which are getting really good these days) but use polyfills to ensure they work correctly/consistently across different browsers.
- Web components. I haven't used these myself, but as I understand it, it's a way of packaging JS modules so they can be used exactly like new HTML tags. So somebody could make a nice <calendar> component for example. I've heard that Lit is a good library for developing web components, but it's not a framework in the sense that it will take control of your whole architecture.
- Vite. This bundles your HTML, scripts and assets -- you can develop your code in vanilla HTML and JS, and Vite will package it up neatly for publishing. It's really fast and reliable. Tons of frameworks are built on top of Vite, but you can go quite a long way just with Vite on its own (and there isn't any lock-in as its input is just HTML).
"How can such changes occur to the DOM that aren't brought about by other code on the page?"
- The other code that made the change may have been written by another team or a third-party organization
- The code setting the MutationObserver may not originate from the page e.g. a browser extension or bookmarklet
- The other code that made the change may have been written by another team or a third-party organization
- The code setting the MutationObserver may not originate from the page e.g. a browser extension or bookmarklet
Let‘s say you have an UI pattern that styles some element and defines possible interactions with it. You do not want business code to do that job, so it’s easier to have a decorator that detects certain elements on the page.
(This is a purely theoretical example coming from someone with lots of architectural experience, I didn’t use it before).
(This is a purely theoretical example coming from someone with lots of architectural experience, I didn’t use it before).
The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.
I never mentioned build tools. You can write your own quickly.
I never mentioned build tools. You can write your own quickly.
The DOM, events, CSS, WCAG. If you want to get into TypeScript then just type and interface keywords. If you want to get into Node then it’s the library system in Nodes documentation. That is it.
Here is a practical example: https://github.com/prettydiff/wisdom/blob/master/performance...
I never mentioned build tools. You can write your own quickly, and you don’t need all the framework bullshit. That stuff is for insecure people and otherwise just slows you down.
Here is a practical example: https://github.com/prettydiff/wisdom/blob/master/performance...
I never mentioned build tools. You can write your own quickly, and you don’t need all the framework bullshit. That stuff is for insecure people and otherwise just slows you down.
I've been in the market for 30 years, had some of the best jobs on earth doing FE, and only did my first React project last year. Maybe I'm an anomaly but I never felt that not knowing React has been a problem. "table stakes" is too strong a phrase.
To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.
Everywhere I've worked would have judged heavy emphasis on framework expertise rather than fundamental CS concepts and web standards as a red flag. I don't think it's that rare.
Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.
Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.
Counterargument: my colleague with 15y exp (10 C++ & 5 Angular/Vue) has been unemployed for 2yrs already because he has no React on the CV and no local company wants to hire him (secondary size tech hub in the country, EU). He's probably have to force-relocate soon.
I’d rather have my FE friends learn about API design, Unix tooling, networking, testing, hundred other things than keep re-learning a framework doing the same thing over and over
> The fact is that if you want to maximize your "market value", you still need to be _very_ good at React.
In some sense yes, but full-stack engineers are nowhere near the top of "market value". Frontend has a pretty hard ceiling on compensation. Past a certain level of advancement you'll never need to build a UI again.
In some sense yes, but full-stack engineers are nowhere near the top of "market value". Frontend has a pretty hard ceiling on compensation. Past a certain level of advancement you'll never need to build a UI again.
I was speaking specifically about FE devs.
Also working in FE for the past 10+ years with 20+ years total dev experience, and I agree with you.
The vast majority of companies out there - even large ones - don't really care, screen for, or hire for core fundamentals. They hire for "good at React" or "lots of experience with Next.js", etc. Fundamentals are great if you are building things from scratch, but the truth is companies very rarely do that. They just pull off the shelf things with large ecosystems and good documentation and use them. Just get good at those things and it's much easier to get hired. You can learn the fundamentals along the way.
The vast majority of companies out there - even large ones - don't really care, screen for, or hire for core fundamentals. They hire for "good at React" or "lots of experience with Next.js", etc. Fundamentals are great if you are building things from scratch, but the truth is companies very rarely do that. They just pull off the shelf things with large ecosystems and good documentation and use them. Just get good at those things and it's much easier to get hired. You can learn the fundamentals along the way.
I have heard of first-hand stories where people interviewed and been asked to have experience in THIS particular framework. Despite the fact that the person had years of FE experience, worked with a similar framework, they were, eventually, rejected most likely due to the fact that they did not have experience with THIS particular framework.
So yeah, while I'm with you on the fundamentals, I'm also with you on the fact that it might not be the best approach if you want to stay employable.
So yeah, while I'm with you on the fundamentals, I'm also with you on the fact that it might not be the best approach if you want to stay employable.
Yeah, the issue is that those frameworks add their own paradigms and abstractions, almost to the point where you don't need to worry / know about the underlying core web standards.
However, this is also a missed opportunity, in that those standards haven't stood still. That is, a lot of web developers are stuck in 2015 and still use Angular / React, Bootstrap or some other framework, LESS/SCSS. Meanwhile in CSS there's things like oklch colours, advanced variables and selectors, layers, etc - I only learned about them recently while working with another developer who has in fact kept up with them.
That is, I'd argue that companies, designers, etc are being kept behind by sticking to these frameworks, because they can only design for and build in what those frameworks support, instead of what is now possible.
Likewise, React Native or other crossplatform app building toolkits, instead of truly understanding the underlying operating system and tools. For a lot of these same companies, things like widgets, live activities, watch apps etc are infeasible because their frameworks don't support them (or in the case of widgets, the frameworks take up all the memory budget). But I believe that if you want a great app experience for your end users, you gotta have dedicated app developers and -designers.
However, this is also a missed opportunity, in that those standards haven't stood still. That is, a lot of web developers are stuck in 2015 and still use Angular / React, Bootstrap or some other framework, LESS/SCSS. Meanwhile in CSS there's things like oklch colours, advanced variables and selectors, layers, etc - I only learned about them recently while working with another developer who has in fact kept up with them.
That is, I'd argue that companies, designers, etc are being kept behind by sticking to these frameworks, because they can only design for and build in what those frameworks support, instead of what is now possible.
Likewise, React Native or other crossplatform app building toolkits, instead of truly understanding the underlying operating system and tools. For a lot of these same companies, things like widgets, live activities, watch apps etc are infeasible because their frameworks don't support them (or in the case of widgets, the frameworks take up all the memory budget). But I believe that if you want a great app experience for your end users, you gotta have dedicated app developers and -designers.
Or..or..or.. don't use a framework!
You can do so much with HTML5 + CSS + Vanilla JS nowadays. I think the default "let's start by picking a framework" is often wrong, unless you know from the start this is going to be a large SPA. Yes, you'll write a little bit more boilerplate for stuff you get for free from a framework, but it will pay itself back in the long run because there is no upgrade treadmill.
You can do so much with HTML5 + CSS + Vanilla JS nowadays. I think the default "let's start by picking a framework" is often wrong, unless you know from the start this is going to be a large SPA. Yes, you'll write a little bit more boilerplate for stuff you get for free from a framework, but it will pay itself back in the long run because there is no upgrade treadmill.
Can you help me understand how this relates to my comment? We’re talking about what skills make you more marketable.
I replied to the wrong comment! Sorry, I can no longer change it.
Ha! All good. Been there myself.
React and / or Angular, I was out of things for a few years but didn't realise that under water, at least in the Dutch market, Angular is still very popular.
Sorry, but people been maximizing value with ASCII-rendered tables of numbers at least since DB2 and Oracle came out. The UI has always been regarded as a key to success, but there are plenty of examples of ugly-as-fuck UI, which otherwise does okay for whatever means was created.
Add to that the fact that Perplexity-like search-RAG-services would very soon start munching not only search, but a plethora of APIs exposed by various services. And perhaps incur costs on the user for it, but the point is nobody cares about nobody else's UI that much. In fact people would love to have dashboards of data shown for their own needs in some open manner, and this is what we should expect to come, not a fancier version of SVG/canvas/React/WEBGL whatever.
last time UI was disruptively innovated was when reactive-functional-spreadsheets were introduced at the end of 90s and it stayed as an engineering concept more than actual implementation.
later on perhaps html/browsers could've disrupted something, and it did for a while, but very soon (only 15 years later) the soc.net.bros were already abusing all the good things in it and now we mostly have closed apps running on top of the open web infrastructure, which is basically the same as running closed apps on top of the open linux ecosystem.
Add to that the fact that Perplexity-like search-RAG-services would very soon start munching not only search, but a plethora of APIs exposed by various services. And perhaps incur costs on the user for it, but the point is nobody cares about nobody else's UI that much. In fact people would love to have dashboards of data shown for their own needs in some open manner, and this is what we should expect to come, not a fancier version of SVG/canvas/React/WEBGL whatever.
last time UI was disruptively innovated was when reactive-functional-spreadsheets were introduced at the end of 90s and it stayed as an engineering concept more than actual implementation.
later on perhaps html/browsers could've disrupted something, and it did for a while, but very soon (only 15 years later) the soc.net.bros were already abusing all the good things in it and now we mostly have closed apps running on top of the open web infrastructure, which is basically the same as running closed apps on top of the open linux ecosystem.
> Whatever framework you choose will be obsolete in 5 years.
I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. So honestly I think this is out-of-date logic. While frontend dev moves fast, it really isn't that bad. Pick boring choices and you get boring results.
I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. So honestly I think this is out-of-date logic. While frontend dev moves fast, it really isn't that bad. Pick boring choices and you get boring results.
> And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together.
I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not as severe as with the shift from v1 to Angular2, but still severely enough that it would require some major re-adjusting. Everything is moving to standalone components, new template syntax, signals, etc.
Similar things can be said about React. React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.
And the same thing kind of applies for less specific paradigms. First everything was SSR, then we went full steam into Single Page Apps only to return back to SSR but only partial SSR with Hydration, etc.
I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not as severe as with the shift from v1 to Angular2, but still severely enough that it would require some major re-adjusting. Everything is moving to standalone components, new template syntax, signals, etc.
Similar things can be said about React. React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.
And the same thing kind of applies for less specific paradigms. First everything was SSR, then we went full steam into Single Page Apps only to return back to SSR but only partial SSR with Hydration, etc.
I agree with Angular 2 not really being the same as Angular 1. Angular in general was a lot less stable, pushing API breaks inside of release candidates and generally just playing fast and loose with things. That said, there was a migration path to go from Angular 1 to 2 incrementally. It wasn't fantastic, but if you had a large Angular 1 app, it was absolutely better than rewriting the whole damn thing.
Angular took a while longer to become more stable. React considered all of its early releases to be 0.x releases, until (I believe) 0.14 -> 15.0, at which point I'd certainly consider React fairly stable. Angular, meanwhile, was kinda unstable until I'd say around v4. Which to be honest, was still a while ago (Google says 2017) but it does bear mentioning.
> React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.
The thing is, functional components are not new. They were a part of React 10 years ago, before React was formally considered stable. I do think hooks came a bit later, but it wasn't that much later. I know that many early React clones supported stateless functional components pretty early on.
And yes, compatibility is key. You can continue to use class components indefinitely. I don't think they have any plans to deprecate them any time soon.
Angular took a while longer to become more stable. React considered all of its early releases to be 0.x releases, until (I believe) 0.14 -> 15.0, at which point I'd certainly consider React fairly stable. Angular, meanwhile, was kinda unstable until I'd say around v4. Which to be honest, was still a while ago (Google says 2017) but it does bear mentioning.
> React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.
The thing is, functional components are not new. They were a part of React 10 years ago, before React was formally considered stable. I do think hooks came a bit later, but it wasn't that much later. I know that many early React clones supported stateless functional components pretty early on.
And yes, compatibility is key. You can continue to use class components indefinitely. I don't think they have any plans to deprecate them any time soon.
React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.
Idiomatic React is different (it now uses hooks and functional components), but the old style of class based components with methods still works, and can be mixed and matched with the newer style so gradual migration is possible. There have been some deprecations over 10 years, but there are automated code migration tools for those.
As a daily React user for 10 years, and having used Ember, Angular, and several backend frameworks, I really don't agree. Hooks were the only meaningful change I can think of, and they took me about a day of real effort to grok, and a week to begin using well - in my existing React codebases no less. The primary way React works is unchanged since the very first day I learned it. It and SQL are probably the oldest tools I have at this point, and the ones that keep paying off year after year.
By a similar argument, most frameworks are the same, most JS package upgrades are the same, etc, etc.
It's still small incompatibilities adding up. It's still work.
It's still small incompatibilities adding up. It's still work.
I think it's fair enough that libraries and frameworks change in ways that require your project to do some maintenance. I do not get mad when this happens with e.g. Qt. You may argue it happens a lot less frequently with Qt. Fair point, but Qt is very old compared to React. React 10 years ago wasn't even considered stable.
If you keep your dependency list short and make boring choices, your app may not still build with modern dependencies after 10 years of neglect. However, it will almost certainly not need to be entirely rewritten, either.
I think learning the fundamentals is good and people should learn to acquire less dependencies, but going as far as to say you may as well not use a framework because it will be gone in five years... I think that is hyperbolic.
If you keep your dependency list short and make boring choices, your app may not still build with modern dependencies after 10 years of neglect. However, it will almost certainly not need to be entirely rewritten, either.
I think learning the fundamentals is good and people should learn to acquire less dependencies, but going as far as to say you may as well not use a framework because it will be gone in five years... I think that is hyperbolic.
React Hooks have been out for 8 years. Idiomatic React code haven't changed much in the last 8 years, mostly it has just been a slow move away from using Redux.
This may be true if you consider React in isolation but nobody uses it that way.
8 years ago create-react-app was new and Next.js v2 was on webpack 3. The former is now obsolete and Next is radically different. And hooks released in 2019
8 years ago create-react-app was new and Next.js v2 was on webpack 3. The former is now obsolete and Next is radically different. And hooks released in 2019
I'd argue that the bigger things in React world are happening under water; new compiler, new architecture for RN, things like that. Loads of things most users won't be aware of, but it's huge projects that clever engineers worked on for years.
I've been doing React for about 10 years. Just started playing with Svelte 5 a few days ago.
It's so simple to work with. Built a simple stock allocation app and what surprised me most was the bundle size... 9kb (gzip). That's better than any other framework I am aware of. That's even smaller than htmx which is somewhat "anti-js"
It's so simple to work with. Built a simple stock allocation app and what surprised me most was the bundle size... 9kb (gzip). That's better than any other framework I am aware of. That's even smaller than htmx which is somewhat "anti-js"
I think svelte 5 is an actual innovation, it does not behave or feel like a “framework” to me. It feels like a natural extension of building an front end with raw html, css, js, solving the headaches you eventually hit when you do so.
Agreed, and I'd add that "obsolete" is a strong word. You can run an older framework for a long, long time. So long as people exist who know your stack and can be hired to work on it when needed, your stack is not "obsolete". "Dated", maybe. "Legacy" is also sometimes an accurate term. But until the day comes when nobody is left who will work on it, it is not "obsolete".
You can, but at some point things start breaking down. Your dependencies are all outdated and pile up CVEs (which you probably are contractually obligated to do something against.) The dev-tool extension is no longer maintained, and Sentry stops support too.
You want to improve things by migrating to the new version or competing framework, but that requires lots of toil, since a lot of things changed in subtle ways or are done differently now, and that has ripple effects. Before you know it, you’ve spent four months playing the zero-sum game of rewriting your frontend. Finally you’ve made it, and then they release Tailwind 4.
Coincidentally, I just migrated something from Tailwind v3 to v4, even though Tailwind isn't really much my cup of tea. The migration tool that they ship was able to do everything. e.g. I ran it, then my project built and worked with v4 instead of v3.
Likewise, there haven't really been any major API changes in React lately either, but if you want it to be automated, they ship react-codemods which will handle a surprising amount of edge cases for you when upgrading.
Likewise, there haven't really been any major API changes in React lately either, but if you want it to be automated, they ship react-codemods which will handle a surprising amount of edge cases for you when upgrading.
It's not just React, but all the other rando packages that your co-workers installed.
Yes, exactly. Please stop doing that! It's not only bad for maintenance to install random packages that get maintained for a couple years (or sometimes barely any time at all,) it's also bad for your bundle sizes. It is annoying having to do a lot more stuff by hand, but it's really not that bad.
If you're going to choose third party packages for something, at least vet that they have good support, are backed by a developer or entity that has been around for a while, and that the library itself is sufficiently mature.
If you're going to choose third party packages for something, at least vet that they have good support, are backed by a developer or entity that has been around for a while, and that the library itself is sufficiently mature.
Are you using the same version of React that you started 10 years ago? More importantly can you use the React version that was 10 years ago ? Can you even build a 10 year project ?
At a previous job, the frontend was a ClojureScript codebase dating back to around 2013, with a React-based UI. The codebase survived a decade of major upgrades to ClojureScript and React, and many chunks of code in git blame dated back to 2013 - 2014. For reference, ClojureScript's first public release was in 2011, and the React wrapper the codebase used dates back to December 2013.
I think the strong focus on backwards compatibility is what helped ClojureScript (and CLJS libraries we used) stay largely unchanged, but we had plenty of "React code" that wasn't changed at all between 2013 and 2022 since it met business requirements and "just worked".
Unfortunately, I don't work there anymore, but I don't see why it'd be impossible to build the early version of that frontend today. Recently, I've been using TypeScript for frontend, and the codebase is still surviving major upgrades to React, TypeScript, and the various libraries we use.
However, I will admit that the pace at which libraries release is extremely fast compared to other ecosystems I'm familiar with (Clojure, Java, Rust, etc.).
I think the strong focus on backwards compatibility is what helped ClojureScript (and CLJS libraries we used) stay largely unchanged, but we had plenty of "React code" that wasn't changed at all between 2013 and 2022 since it met business requirements and "just worked".
Unfortunately, I don't work there anymore, but I don't see why it'd be impossible to build the early version of that frontend today. Recently, I've been using TypeScript for frontend, and the codebase is still surviving major upgrades to React, TypeScript, and the various libraries we use.
However, I will admit that the pace at which libraries release is extremely fast compared to other ecosystems I'm familiar with (Clojure, Java, Rust, etc.).
Well, that's just moving the goal posts. I never said you wouldn't have to do any maintenance at all, just that the floor doesn't just fall from under everyone every 5 years. Even outside of frontend, most ecosystems move fast enough that projects from 10 years ago would be in pretty bad shape. That's long enough that even many C/C++ projects will not compile, if nothing else, as a result of improvements to compilers.
As far as a React program from 2015, the maintenance required to get it working in modern React probably wouldn't be all that bad. The biggest transition in React's existence was the move from createClass to ECMAScript 2015 classes. React predates the existence of ECMAScript 2015 classes, having been released in 2013, but once they were available React 13 (2015) they were pretty quickly adopted for reasons obvious. So I'd expect a project from 10 years ago to probably still be using ECMAScript 2015 classes. If not, that transition is mostly mechanical. Definitely a few other potential compatibility breaks over the years, but they're all documented. None of them are going to require a full application rewrite.
Can you build a project from 10 years ago, using 10 year old React? Well, yeah, if you want to. You'll need to use an old version of Node.js most likely, but npm still has all of the old packages.
As far as a React program from 2015, the maintenance required to get it working in modern React probably wouldn't be all that bad. The biggest transition in React's existence was the move from createClass to ECMAScript 2015 classes. React predates the existence of ECMAScript 2015 classes, having been released in 2013, but once they were available React 13 (2015) they were pretty quickly adopted for reasons obvious. So I'd expect a project from 10 years ago to probably still be using ECMAScript 2015 classes. If not, that transition is mostly mechanical. Definitely a few other potential compatibility breaks over the years, but they're all documented. None of them are going to require a full application rewrite.
Can you build a project from 10 years ago, using 10 year old React? Well, yeah, if you want to. You'll need to use an old version of Node.js most likely, but npm still has all of the old packages.
I don't think it's moving the goal posts. It's a very reasonable thing to ask. I have Go projects that are now 10 years old that require zero maintenance on my part.
I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react.
Sure if you were using just react that is okay, but how many frontend projects are JUST using react? The issue with react has always been the community surrounding it. Library recommendations that use to be "best practices" get churned into the next thing marketers want to push.
It's very wasteful in our community because we are just tilting at windmills rather than focusing on the harder problems we have to collectively sell. We should start shunning tools that enable this churn, not all frontend communities are like this either but the popular ones seem to be.
I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react.
Sure if you were using just react that is okay, but how many frontend projects are JUST using react? The issue with react has always been the community surrounding it. Library recommendations that use to be "best practices" get churned into the next thing marketers want to push.
It's very wasteful in our community because we are just tilting at windmills rather than focusing on the harder problems we have to collectively sell. We should start shunning tools that enable this churn, not all frontend communities are like this either but the popular ones seem to be.
I don't really disagree that there is a lot of churn in frontend, but a lot of that comes down to simply picking up too many dependencies, a problem that isn't really that hard to avoid by simply not doing that. I have indeed had large projects where the list of direct dependencies was about a dozen, because if you are more judicious about dependencies, it's not so bad.
Go is a great example. Once Go hit 1.0, it gained very strong compatibility guarantees. Go has two properties that make it much better in terms of ecosystem stability than JS was:
- The Go standard library. For a long time JS lacked very basic functionality in its standard library. Go has a very nice standard library that not only covers essential algorithms and data structures, but also standard I/O interfaces, implementations of popular protocols and file formats, and a full cryptography suite. 10 years ago, JavaScript lacked much of this, so you often had to "roll your own". Today JS has standard modules, WebCrypto, the File System API, IndexedDB, bigint, ES Maps and Sets, and more. The problem is much alleviated.
- Go has an ethos of minimal dependencies, a la the famous Go proverb, "A little copying is better than a little dependency." JavaScript had virtually the opposite attitude; they were pushing for making every small thing a module. This was a terrible idea, and it has led to the unfortunate reality that your dependency trees in Node.JS grow uncontrollably. This has been somewhat alleviated, though there are still many projects with out-of-control module trees.
Mind you also, that React prior to v15 was also considered pre-1.0; the last relatively big transition (to ES classes) happened in v13, which was actually v0.13 at the time.
But come on. The quote I took issue with was:
> Whatever framework you choose will be obsolete in 5 years.
This is an exaggeration. Undoutedly the JS ecosystem is not as stable as the Go one, but I don't think dropping all frameworks because the ecosystem moves kind of fast is the right answer. There's a measure in the middle.
Go is a great example. Once Go hit 1.0, it gained very strong compatibility guarantees. Go has two properties that make it much better in terms of ecosystem stability than JS was:
- The Go standard library. For a long time JS lacked very basic functionality in its standard library. Go has a very nice standard library that not only covers essential algorithms and data structures, but also standard I/O interfaces, implementations of popular protocols and file formats, and a full cryptography suite. 10 years ago, JavaScript lacked much of this, so you often had to "roll your own". Today JS has standard modules, WebCrypto, the File System API, IndexedDB, bigint, ES Maps and Sets, and more. The problem is much alleviated.
- Go has an ethos of minimal dependencies, a la the famous Go proverb, "A little copying is better than a little dependency." JavaScript had virtually the opposite attitude; they were pushing for making every small thing a module. This was a terrible idea, and it has led to the unfortunate reality that your dependency trees in Node.JS grow uncontrollably. This has been somewhat alleviated, though there are still many projects with out-of-control module trees.
Mind you also, that React prior to v15 was also considered pre-1.0; the last relatively big transition (to ES classes) happened in v13, which was actually v0.13 at the time.
But come on. The quote I took issue with was:
> Whatever framework you choose will be obsolete in 5 years.
This is an exaggeration. Undoutedly the JS ecosystem is not as stable as the Go one, but I don't think dropping all frameworks because the ecosystem moves kind of fast is the right answer. There's a measure in the middle.
In React 10 years ago, you included a <script> tag in your HTML page and added interactivity via "React.createClass()" function calls.
To be fair...
Webpack existed 10 years ago, and that was after Browserify had already existed for a bit, too. The era of bundling was already in full swing in 2015, and React gained support for ES Classes, too.
React wasn't really terribly usable without bundling. Prior to bundling, there were multiple competing adhoc module systems, but obviously this wasn't fantastic for a variety of reasons. AngularJS 1.0 was great in part because the dependency injection system kind of took care of a lot of trouble; you could have a workflow in Gulp/Grunt concatting your JS together, and the order didn't really matter a ton since dependency injection would largely handle it.
React moved relatively quickly in the first few years, but 10 years ago was already not the very beginning of React. It was starting to mature by that point.
Webpack existed 10 years ago, and that was after Browserify had already existed for a bit, too. The era of bundling was already in full swing in 2015, and React gained support for ES Classes, too.
React wasn't really terribly usable without bundling. Prior to bundling, there were multiple competing adhoc module systems, but obviously this wasn't fantastic for a variety of reasons. AngularJS 1.0 was great in part because the dependency injection system kind of took care of a lot of trouble; you could have a workflow in Gulp/Grunt concatting your JS together, and the order didn't really matter a ton since dependency injection would largely handle it.
React moved relatively quickly in the first few years, but 10 years ago was already not the very beginning of React. It was starting to mature by that point.
Svelte will never overtake react. It won’t even overtake Vue.
Especially true with the runes update. imo, it traded away the thing that made it unique and truly great in the market: the feeling that you’re just writing vanilla HTML, JS, and CSS.
It was a false feeling. 1) Vue already had runes, under a different name. 2) Svelte's old behavior was only possible with their dependency-tracking compilation step. i.e. not vanilla. 3) runes use proxies, which are vanilla JS, and don't require a build step at all, although svelte may still have them.
Honestly, I don't even really care that much which frontend library wins, and I've been mostly happy with React as a foundation to build off of. If the future is some Rust-based framework compiled to WASM, that's ultimately fine with me. Just as long as whatever it is is relatively performant and stable and doesn't add 1 megabyte of code to every pageload.
Yeah but we also got lucky there - like picking the right altcoin. React was just one of many then, and the rest all crumbled. And like OPs said, modern react is quite different than it was 10 years ago
> React was just one of many then, and the rest all crumbled.
Luck played a role, but if you were well versed in the ecosystem at the time (read: worked professionally in more than one framework), the others all had well known trajectories, limitations, or issues. Angular was just fine; Knockout was eaten by Angular. Ember was way too rigid and magical. jQuery was great but not a framework, more like a lodash. Backbone was really cool but incomplete and didn't help enough. In a way its the best one to compare too, because React was also minimal, but not incomplete - instead the part it did, it did better than you would on your own, then let you do whatever you want with everything else - I think they marked as "The V in MVC" at the time. It was both really powerful, simple, and easy to pick up especially if you were using a lot of jQuery or vanilla js at the time. Its the only one since jQuery that felt like it was simply adding useful stuff, and not taking anything away; I wasn't at all surprised to see it stick as well as jQuery, and for the others to fade. You'd be lucky to outright choose it out of ignorance.
Luck played a role, but if you were well versed in the ecosystem at the time (read: worked professionally in more than one framework), the others all had well known trajectories, limitations, or issues. Angular was just fine; Knockout was eaten by Angular. Ember was way too rigid and magical. jQuery was great but not a framework, more like a lodash. Backbone was really cool but incomplete and didn't help enough. In a way its the best one to compare too, because React was also minimal, but not incomplete - instead the part it did, it did better than you would on your own, then let you do whatever you want with everything else - I think they marked as "The V in MVC" at the time. It was both really powerful, simple, and easy to pick up especially if you were using a lot of jQuery or vanilla js at the time. Its the only one since jQuery that felt like it was simply adding useful stuff, and not taking anything away; I wasn't at all surprised to see it stick as well as jQuery, and for the others to fade. You'd be lucky to outright choose it out of ignorance.
I believe there's an art in choosing the right tools and frameworks. A big one i think is whether it solves a problem that no other tools have solved - rather than just an improvement.
React had that which I believe is the reason why they won. There are other "better" iteration after that but they don't inherently solve a big problem.
React had that which I believe is the reason why they won. There are other "better" iteration after that but they don't inherently solve a big problem.
I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem.
I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3
For backend instead of "let's use this new framework", I get the "let's use this new LANGUAGE" - the newest hottness is to rewrite something in Rust. It was Go before that, haskell, scala, F# (yes I got that too).
You think migrating your frontend code from react to svelte or whatever is troublesome, trying rewriting that VB 6 app :) (Or god forbid something like RPC where your data is in the code)
Not saying that the unstableness of engineering practices aren't a problem. It's a huge problem. Just that it's not a frontend problem.
I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3
For backend instead of "let's use this new framework", I get the "let's use this new LANGUAGE" - the newest hottness is to rewrite something in Rust. It was Go before that, haskell, scala, F# (yes I got that too).
You think migrating your frontend code from react to svelte or whatever is troublesome, trying rewriting that VB 6 app :) (Or god forbid something like RPC where your data is in the code)
Not saying that the unstableness of engineering practices aren't a problem. It's a huge problem. Just that it's not a frontend problem.
React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years.
Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically.
If Apache configs moved as much as these systems did, no one would use Apache.
Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically.
If Apache configs moved as much as these systems did, no one would use Apache.
imo, the Webpack situation is worse. React's evolution has been more incremental/cumulative. Best practices evolve, but not too much truly needs to be forgotten.
Anecdotal: I agree because everywhere I have worked were backend-senior heavy -- they think frontend is easy and not worth touching, and they are the ones who makes decisions on "the next shiny things" for backend things. In my last job, databse migrations happened twice in just two years and we spent a total of one year of engineering time on it -- every single table, not just some non-critical ones. When things broke or when upper management was asking why thigns were so slow, they just blamed the front-end learning engineers for not being experienced enough.
>> It's not a frontend problem
From my perspective as a Java developer, it's a frontend problem.
I've been employed as a Java developer for over a quarter of a century. For a little over the first ten years of that, I did full stack development, and that was the norm at the companies I worked for.
That has changed where it is now typical for there to be a separate team for frontend, and often three teams for frontend (web, iOS and Android). For me that change was around the time of AngularJS -> Angular.
Yes, Java was changing rapidly in the first ten years or so, very rapidly in the first 3 years. But that is over. Java 5 was a huge change, and there were some major features in Java 8, but Java 8 was in 2014. My team only switched to Java 11 recently. Java 24 is out now. I haven't used any Java 11 features. I don't even know what they are. I haven't learned a single new language feature for a decade.
Build tools are the same for the last 15 years. IDE is the same for the last 20 years. The main frameworks I use have been the same for 10 years. When I switched to my last job, the code base was structured exactly the way my previous team's was.
Building web services in Java is a solved problem. It's completely boring, in a good way. It's COBOL.
Frontend was changing rapidly in the late 90's/early 00's also, but it has kept changing rapidly the entire time since then. The pet UI project I build a few years ago is completely outdated.
Any of the Java projects that I worked on in the post-EJB era, you could easily find a Java developer today who could step in and immediately be productive working on them, even if the developer wasn't born yet when they were created. There would be a few outdated libraries to learn, maybe.
From my perspective as a Java developer, it's a frontend problem.
I've been employed as a Java developer for over a quarter of a century. For a little over the first ten years of that, I did full stack development, and that was the norm at the companies I worked for.
That has changed where it is now typical for there to be a separate team for frontend, and often three teams for frontend (web, iOS and Android). For me that change was around the time of AngularJS -> Angular.
Yes, Java was changing rapidly in the first ten years or so, very rapidly in the first 3 years. But that is over. Java 5 was a huge change, and there were some major features in Java 8, but Java 8 was in 2014. My team only switched to Java 11 recently. Java 24 is out now. I haven't used any Java 11 features. I don't even know what they are. I haven't learned a single new language feature for a decade.
Build tools are the same for the last 15 years. IDE is the same for the last 20 years. The main frameworks I use have been the same for 10 years. When I switched to my last job, the code base was structured exactly the way my previous team's was.
Building web services in Java is a solved problem. It's completely boring, in a good way. It's COBOL.
Frontend was changing rapidly in the late 90's/early 00's also, but it has kept changing rapidly the entire time since then. The pet UI project I build a few years ago is completely outdated.
Any of the Java projects that I worked on in the post-EJB era, you could easily find a Java developer today who could step in and immediately be productive working on them, even if the developer wasn't born yet when they were created. There would be a few outdated libraries to learn, maybe.
Scala, in and of itself, would have entire revolutions every year.
To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.
> no separation between backend and frontend folks in the company.
This is the biggest gain available anywhere.
When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML).
I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.
This is the biggest gain available anywhere.
When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML).
I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.
> When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS.
A million times yes!
> I think the end game is doing SSR of web content inside the RDBMS
That feels like one step too far for me. I think things like authorization and HTML rendering belong in a separate layer.
But I do believe that more than 90% of today's "server side code" actually belongs in the RDBMS, and I blame the weakness of SQL as the reason no one wants to do this.
A million times yes!
> I think the end game is doing SSR of web content inside the RDBMS
That feels like one step too far for me. I think things like authorization and HTML rendering belong in a separate layer.
But I do believe that more than 90% of today's "server side code" actually belongs in the RDBMS, and I blame the weakness of SQL as the reason no one wants to do this.
Does writing HTML into database entries count? Because certain large entertainment companies are ahead of the curve if so.
This is just compiling and caching right?
No, this is hand-writing HTML into SQL database rows for conditional rendering. I think it stems from a culture of remarkable IP protectiveness. Take your guesses at which company I am referencing.
I am struggling with why the practice of storing HTML partials in SQL is necessarily bad.
If anything, this is arguably one of the more structured ways you could go about attacking the problem of a complex web product.
If anything, this is arguably one of the more structured ways you could go about attacking the problem of a complex web product.
Because you shouldn't repeat yourself. If you're going to store your content that way, it should be as agnostic as possible, so that when the inevitable redesign comes around, you're not stuck rewriting every single line of that database, like I was.
Plain HTML and plain CSS (well, maybe with SASS) are pretty great.
Plain JS loses much to plain Typescript though, to my mind.
Plain JS loses much to plain Typescript though, to my mind.
Is there a way to use typescript without pulling in all of npm? That’s the deal breaker for me, maybe others as well.
Yes. E.g. bun [1] consumes typescript directly.
The current canonical TS compiler and language server are both written in JS/TS and run on Node (even though there's an ongoing effort for rewriting things in Go). They are relatively compact though; IIRC installing the Rust compiler or the Haskell compiler takes more space.
[1]: https://bun.sh/
The current canonical TS compiler and language server are both written in JS/TS and run on Node (even though there's an ongoing effort for rewriting things in Go). They are relatively compact though; IIRC installing the Rust compiler or the Haskell compiler takes more space.
[1]: https://bun.sh/
It's not too difficult to use the TypeScript type checker on JS files, so it's possible to reap most of those benefits without having to introduce a compilation step.
In my experience, most of the benefits of Typescript come from type-checking across call boundaries, the point where type-related bugs are most likely to be introduced due to each side of the call often being in different locations and contexts. And you can't get those benefits without explicitly typing function parameters.
If you really don't want the compilation step; you can use JSDoc and get almost the best of both worlds (not everything in TS is supported by JSDoc but most essentials are)
Ah yes. That is brilliant until it isn't. For any reasonably complex business problem you will run into:
* Performance issues: table scans, high memory usage for joins, crazy sql execution plans, lock contention
* Security problems: especially around authorisation. Who can see what data. You'll start to need rules engines written as stored procedure or some shit.
* Business logic: can a SQL work out the country city, state and federal tax for the address? Maybe it can. Maybe that query will grind the system to a halt. Maybe you'll slap redis and 1000 sql replications. Maybe you are no longer just doing SQL!
Yeah fortunately for all of us shit is complicated and needs bespoke thinking to solve each problem.
There are problems where your ideas work well (typically consumer facing startup types who can rewrite when they raise a bit more money).
If that is how you do things I know the conversations you'll be having next year already. And that is from just ORM abuse not even front end SQL.
I tried to use Firebase in earnest which is the ultimate in that approach and it is awful. You hit a bunch of new and worse problems because you don't want anything to do with an EC2.
* Performance issues: table scans, high memory usage for joins, crazy sql execution plans, lock contention
* Security problems: especially around authorisation. Who can see what data. You'll start to need rules engines written as stored procedure or some shit.
* Business logic: can a SQL work out the country city, state and federal tax for the address? Maybe it can. Maybe that query will grind the system to a halt. Maybe you'll slap redis and 1000 sql replications. Maybe you are no longer just doing SQL!
Yeah fortunately for all of us shit is complicated and needs bespoke thinking to solve each problem.
There are problems where your ideas work well (typically consumer facing startup types who can rewrite when they raise a bit more money).
If that is how you do things I know the conversations you'll be having next year already. And that is from just ORM abuse not even front end SQL.
I tried to use Firebase in earnest which is the ultimate in that approach and it is awful. You hit a bunch of new and worse problems because you don't want anything to do with an EC2.
> I think the end game is doing SSR of web content inside the RDBMS
OR just embed the RDBMS into your application!
OR just embed the RDBMS into your application!
SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack.
https://www.sqlite.org/appfunc.html
https://www.sqlite.org/appfunc.html
It's also very easy to do in Rust.
https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
> I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX)
At my workplace our IT department uses APEX a lot for all kind of internal LOB apps. It works great as long as it supports what you need.
At my workplace our IT department uses APEX a lot for all kind of internal LOB apps. It works great as long as it supports what you need.
The odds that that person will also understand or care about normalization, let alone the performance characteristics of their RDBMS and how their schema decisions affect it, are close to zero.
I’ve spent enough time watching devs have access to the DB that I know it’s a dead end. For a group that loves to talk about DSA, you’d think a B+tree would be second nature, and yet…
Full Stack is a lie, as is DevOps. We need to return to highly specialized roles. You want a new view? Submit your proposal to the DB team. They shot you down with a list of reasons why? Go learn everything they complained about; next time, the list won’t be so long.
I’ve spent enough time watching devs have access to the DB that I know it’s a dead end. For a group that loves to talk about DSA, you’d think a B+tree would be second nature, and yet…
Full Stack is a lie, as is DevOps. We need to return to highly specialized roles. You want a new view? Submit your proposal to the DB team. They shot you down with a list of reasons why? Go learn everything they complained about; next time, the list won’t be so long.
Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.
As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea.
When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.
I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.
Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.
Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.
When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.
I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.
Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.
Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.
I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.
Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all.
In a way, it is exactly the example opposite of what you mention.
In a way, it is exactly the example opposite of what you mention.
It's not an experiment though. The divide is clear, you have a client application, and then server applications that the client talks to. This is even more true if you want a lot of interactivity. This line isn't going away anytime soon. There will always be an application that runs on the edge device or machine, and it needs to talk to some other application to store and retrieve data.
The secret is to make the thing that runs on the backend the application, and the thing that runs on the edge device the user interface.
It just depends on the use case. The "interface" could be complicated enough that it needs a full blown application with state. I would say that's the typical expectation today from users.
This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity
Delete the API, render your html on the server, problem solved.
If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.
> The BE / FE split has been a really bad experiment.
What do you mean - "full stack" is very popular and frankly produces some of this weird unmaintainable code. Hiring backend-y type people and making them develop UI (with state especially) is where half these companies realize "crap we need a front end developer"..
What do you mean - "full stack" is very popular and frankly produces some of this weird unmaintainable code. Hiring backend-y type people and making them develop UI (with state especially) is where half these companies realize "crap we need a front end developer"..
I’m sure you can find horrible code bases in any arrangement. I will say that a good team will tend to be better for more projects than two good teams (fe/be). There certainly are cases where a split will make sense and be much better, but I have seen it become the default when one team should be.
It's amazing what CSS can do these days.
I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.
I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.
I agree 100%, but "JavaScript only when needed" is a loaded phrase. Especially when you don't have an engineering-centric culture.
Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.
Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.
No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.
Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.
Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.
You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.
I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!
Yea people should just learn Elixir/Phoenix and forget about all their npm js issues...
Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).
This was true in the lodash and jquery as essential days, but hasn't been the case for years.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> hasn't been the case for years
For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago.
- https://en.wikipedia.org/wiki/ECMAScript_version_history#6th...
It truly did improve the JS landscape by an order of magnitude.
For those unfamiliar with the extensive features this brought to JS, here is a good list:
- https://rse.github.io/es6-features/
For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago.
- https://en.wikipedia.org/wiki/ECMAScript_version_history#6th...
It truly did improve the JS landscape by an order of magnitude.
For those unfamiliar with the extensive features this brought to JS, here is a good list:
- https://rse.github.io/es6-features/
ES6 modules make it straightforward to reform great piles of unstructured JS hackery into hierarchical dependency-controlled units for which you can actually reliably draw a block diagram. Hmm, or maybe get Claude to draw it for you ...
Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.
Yeah, those were two big sticking points.
There's also Object.groupBy() now which was another thing I always missed from the standard library.
Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals
There's also Object.groupBy() now which was another thing I always missed from the standard library.
Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals
Worth noting that those features were indeed added after the creation of e.g. React, but both have been widely available for ~10 years now.
No regular frontend needs any of that. Serde support, that's a ridiculous requirement for painting some web boxes on a display.
Plus, as the other comment noted, the basic JS types go a long way now.
Plus, as the other comment noted, the basic JS types go a long way now.
You don't need javascript at all to render.
Oh for a version of the WWW that never allowed javascript at all.... money destroys absolutely everything it touches.
Oh for a version of the WWW that never allowed javascript at all.... money destroys absolutely everything it touches.
Alright, I've been in the industry a very long time but moved to backend when it got complex. I am wondering why you need a decent hash map or set implementation. This is supposed to be done on the backend. The frontend is for presentation. Your backend should not give you elements with duplicates (why you don't need set). "Decent hash map" sounds like you just don't like the hash map implementation because you are trying to do something complex with the Map implementation, in which case it belongs on the backend.
[deleted]
So you're just jumping on the backend treadmill.
Yeah, agreed - but I do think using vue, react, whatever on certain pages really has its benefits. Sometimes a UI really is improved by using features that Vue makes really easy to implement.
Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?
Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?
When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.
> Newbies should read MDN and ignore everything else.
I think people forget how inaccessible it is for a newbie to start writing pure javascript directly from the API reference.
People need tutorials and walkthroughs, and need to build a an internal understanding of how these all work.
Frameworks help them abstract all that
I think people forget how inaccessible it is for a newbie to start writing pure javascript directly from the API reference.
People need tutorials and walkthroughs, and need to build a an internal understanding of how these all work.
Frameworks help them abstract all that
> I think people forget how inaccessible it is for a newbie to start writing pure javascript directly from the API reference.
That's when you buy a book and try to do practice projects, and learn how everything works.
That's when you buy a book and try to do practice projects, and learn how everything works.
MDN has exactly those kinds of tutorials and walk throughs! It’s not all API documentation
Which ones? Could you link to them?
HTML: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
CSS: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
JS: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
They even have courses for frameworks.
React: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Svelte: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Vue: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
CSS: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
JS: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
They even have courses for frameworks.
React: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Svelte: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Vue: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
I've been using MDN for a decade, and this is a TIL!
React's been around long enough and is dug in deep enough to have decent ROI on knowing fairly well, but the recent obsession with Next.js and SSR...maybe not. Privately I think this might be their undoing.
I agree with learning React, it pops up in all sorts of places, vscode extensions, the windows start menu apparently.
But yes, mixed-rendering, server functions, meta-frameworks, etc. You are in real danger of spending years learning all this stuff and still not being any closer to knowing how computers work.
But yes, mixed-rendering, server functions, meta-frameworks, etc. You are in real danger of spending years learning all this stuff and still not being any closer to knowing how computers work.
Which version of react?
Hooks or classes?
Or whatever comes next.
Hooks or classes?
Or whatever comes next.
You can still write class-based components in React, no problem. It might not be in vogue, but for the most part, you can still write React 18.x roughly the same way you wrote React 0.x.
You can but are people going to when the first thing you see upon opening the docs is a giant warning telling you not to?
https://react.dev/reference/react/Component
https://react.dev/reference/react/Component
Considering all the advancements that Vanilla JS and CSS have made in recent years (plus exciting features like animating "display: none" that are almost fully adopted), I think templated HTML on the server + JS where it's needed, makes more sense than ever. And, that's coming from someone who largely makes their living from React.
Like the author, I've been doing frontend in one way or another for 20 years. The ecosystem, churn, and the absolute juggling act of sync'ing state between the frontend and backend is batshit crazy.
I recently started a proof of concept project using Go templates and HTMX. I'm trying to approximate building a UI with "components" like I would with React. There's still a lot of rough edges, but it's promising. I'm still not sure I need HTMX tbh. I've started managing event listeners myself, and I think I prefer it.
Interestingly enough, managing complex UI state that's based on user roles and permissions is so much easier on the server. Just send the HTML that the user is allowed to see. Done.
That said, React, Vue, et. al has sooo much steam. I don't know how a collective shift in thinking would even begin. Especially considering all the developers who have never known anything but frontend frameworks as a way to build a UI.
Like the author, I've been doing frontend in one way or another for 20 years. The ecosystem, churn, and the absolute juggling act of sync'ing state between the frontend and backend is batshit crazy.
I recently started a proof of concept project using Go templates and HTMX. I'm trying to approximate building a UI with "components" like I would with React. There's still a lot of rough edges, but it's promising. I'm still not sure I need HTMX tbh. I've started managing event listeners myself, and I think I prefer it.
Interestingly enough, managing complex UI state that's based on user roles and permissions is so much easier on the server. Just send the HTML that the user is allowed to see. Done.
That said, React, Vue, et. al has sooo much steam. I don't know how a collective shift in thinking would even begin. Especially considering all the developers who have never known anything but frontend frameworks as a way to build a UI.
> Whatever framework you choose will be obsolete in 5 years.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
How many dependencies does your package.json file declare? Which versions of node/npm does your team use?
If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.
If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.
Dependencies issue is not exclusive to frameworks. If you don't want to reinvent the wheel, there's no way around using packages, even if you go with vanilla JS.
None? I use it from ClojureScript. I've been maintaining a React-based app with Semantic UI for 10 years now.
Then you aren't doing what the author is talking about.
The new insight then is if you do things then bad things will happen?
Do you mean your package.json literally has no dependencies declared (or you don't even have package.json)? If so, you're not using frontend tooling like 98% of development teams.
I don't have a package.json. I don't use npm. But I do use React. Yes, I am not like [insert scientifically determined very very high percentage] of teams out there — but that's exactly my point. There are ways to do frontend development without the treadmill.
Thing is, we are the reason for the treadmill being there: we love the new shiny, we call software that is stable "dead", we actively mock software that doesn't have a lot of churn as "not being developed". So I guess we deserve what we get.
Thing is, we are the reason for the treadmill being there: we love the new shiny, we call software that is stable "dead", we actively mock software that doesn't have a lot of churn as "not being developed". So I guess we deserve what we get.
Java and .net developers also uses dependencies, and they too need to upgrade their dependencies (and sometimes switch out deprecated stuff). Definitely not a Frontend issue.
I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods...
Even a well-maintained project like React can't escape the squalor of its ecosystem.
I don't always have this option, but usually these days I choose vanilla JS, imported with no build system, do as much as I can with Python/Django on the backend, and opt out of the JavaScript ecosystem entirely. I haven't regretted it.
Even a well-maintained project like React can't escape the squalor of its ecosystem.
I don't always have this option, but usually these days I choose vanilla JS, imported with no build system, do as much as I can with Python/Django on the backend, and opt out of the JavaScript ecosystem entirely. I haven't regretted it.
Some of the problem with React and npm is that they are a victim of their own success.
React lets you suck in 80 components from 15 different vendors and it works. NPM lets you suck in more dependencies than many other systems because it deals with diamond dependencies better than other systems [1]
Because you can mix and match so many widget sets no wonder you will have trouble when those widget sets change.
[1] package A can import version B of package C, package D can import version E of package C -- so long as A and D don't exchange objects from package C there is never a problem, even if they do it might work.
React lets you suck in 80 components from 15 different vendors and it works. NPM lets you suck in more dependencies than many other systems because it deals with diamond dependencies better than other systems [1]
Because you can mix and match so many widget sets no wonder you will have trouble when those widget sets change.
[1] package A can import version B of package C, package D can import version E of package C -- so long as A and D don't exchange objects from package C there is never a problem, even if they do it might work.
The problem is more cultural than technical. JavaScript folks see the ready availability of dependencies as a feature rather than a risk, including the creation of a plethora of micro-dependencies (such as the left pad fiasco).
React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.
You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.
Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.
React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.
You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.
Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.
> To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility.
That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system - which is still possible with React, but not with Svelte, Vue or Angular.
My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system - which is still possible with React, but not with Svelte, Vue or Angular.
My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
I just had a thought and decided to look it up.
This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years."
The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production?
So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.
This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years."
The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production?
So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.
You are extrapolating from the past into the future, but a lot has consolidated in the last five years. You used to need babel to use crucial language features that are now supported across the board, at the same time the avalanche of new language features has subsided.
Conditional types (not statements) are not a basic feature.
Conditional types (not statements) are not a basic feature.
> You are extrapolating from the past into the future, but a lot has consolidated in the last five years.
I've been writing JavaScript that entire time, and the complete disregard for maintenance has gotten worse, not better.
You seem to be under the impression that because I also write other languages, I haven't been keeping track of what's happening in the JS ecosystem, but you're wrong--I still write JS, because I often don't have any other option.
The fact that I work in other languages means I get to see what I like about better-managed ecosystems. If you're writing JS on both frontend and backend and not using anything else, it's likely that you don't know how bad things are for you because the JS churn has been normalized for you.
I've been writing JavaScript that entire time, and the complete disregard for maintenance has gotten worse, not better.
You seem to be under the impression that because I also write other languages, I haven't been keeping track of what's happening in the JS ecosystem, but you're wrong--I still write JS, because I often don't have any other option.
The fact that I work in other languages means I get to see what I like about better-managed ecosystems. If you're writing JS on both frontend and backend and not using anything else, it's likely that you don't know how bad things are for you because the JS churn has been normalized for you.
> That's a problem with your build system then, not React.
Did you read the sentence that you're "correcting"?
> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
Your optimism is admirable.
Did you read the sentence that you're "correcting"?
> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
Your optimism is admirable.
If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.
> If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools.
Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.
How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?
Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.
How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?
wait, what package does no longer exist? is it something that has been unpublished from NPM?
https://en.wikipedia.org/wiki/Npm_left-pad_incident
People arguing with me here don't seem to remember this breaking like 1/2 the JS builds in existence for a few days.
People arguing with me here don't seem to remember this breaking like 1/2 the JS builds in existence for a few days.
Component lifecycle methods to hooks and HOCs, does that ring a bell?
Yeah, and I'm not anywhere near as distressed about it as this article implies I should be.
As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
Front-end dev here.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
Most likely because you work on apps in active development.
Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new.
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
The transition to hooks was worth it.
I'm not convinced.
- they're much harder to learn and understand than the callback hooks from class components
- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them
- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)
- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm
- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)
- the mental model for how to put them together when you're writing custom ones is a little bit funky too.
- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
- they're much harder to learn and understand than the callback hooks from class components
- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them
- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)
- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm
- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)
- the mental model for how to put them together when you're writing custom ones is a little bit funky too.
- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
Class components and HOCs aren’t deprecated though.
They're very much not "best practices", and will be deprecated soon (if they're not already).
You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove.
HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
But they're not deprecated. Where's the forced churn?
Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
That's not true (the deprecation part, anyway) and I know of at least one React team member who has spoken publicly to that fact.
Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
I have no idea why you are getting downvoted for this comment when there is literally a massive warning on the docs page for class components.
https://react.dev/reference/react/Component
https://react.dev/reference/react/Component
[deleted]
How's your Create React App support in 2025?
Are you still keeping your app on React 15?
It takes ten minutes to switch from CRA to Vite.
I think that's only if you've rehearsed it several times. Although now that I think about it, you will probably have to do it multiple times, so once you get good at it, that may be a reasonable estimate.
My current firm is still on 16 and just trying to make it to 18 because of the deprecations.
All of the WYSIWYG editors that work on 16 are no longer supported. it's a "cross your fingers" in case someone found a security issue (or don't use them)
React 16 is still supported, but it's definitely obsolete.
All of the WYSIWYG editors that work on 16 are no longer supported. it's a "cross your fingers" in case someone found a security issue (or don't use them)
React 16 is still supported, but it's definitely obsolete.
Idiomatic Reacts historical changes pretty often. In large codebases major version upgrades can take teams multiple quarters to complete.
Same I’ve been writing React for 11 years now.
Before that I used Backbone on top of jQuery.
Before that I used jQuery.
Before that I used the document, but I still use the document.
I have barely had to learn anything each decade.
Before that I used Backbone on top of jQuery.
Before that I used jQuery.
Before that I used the document, but I still use the document.
I have barely had to learn anything each decade.
I have too and the react of today is vastly different from the react of 5 years ago. Which itself was vastly different from the original react.
It’s different paradigm, best practice, file organization, etc.
So it’s close to learning a new language.
And I won’t even go into the fact that Next is replacing React as the standard.
It’s different paradigm, best practice, file organization, etc.
So it’s close to learning a new language.
And I won’t even go into the fact that Next is replacing React as the standard.
[deleted]
Didn't React deprecate itself entirely circa 2018?
They just keep stirring his slop and he keeps eating it, that's all I'm reading here
"That was some good slop, sir. Can I come back here for lunch every day for the next 10 years?"
Hilarious, and accurate.
Hilarious, and accurate.
[deleted]
The counterpoint is that if you don’t adopt a framework you end up with a “framework” you built yourselves that people outside your team don’t understand, is generally poorly documented and needs constant work to add features existing frameworks already have. There are common features needed on the FE and common problems to solve, why not at least start with something instead of nothing?
Yes this is a problem I've seen. It's impossible to find people who can be immediately productive because they've never seen your internal framework before. Even if it's extensively documented, it still takes time to learn and internalize. For long-term hires, it's not the worst, but if you ever temporarily need extra devs, you're SOL.
I am not sure this is true . As I wrote elsewhere, almost everyone wants a web app or thinks that they have a web app, but usually it is just a dynamic website. You do not need to build up a framework to have a dynamic website.
"everyone" and "usually" are doing a lot of work here
I would bet real money that what I am saying is also true at your workplace.
It's not a frontend problem but a JS-ecosystem problem. Happens in the backend too.
The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify):
https://npmgraph.js.org/?q=platformatic#zoom=h
Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point.
And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.
The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify):
https://npmgraph.js.org/?q=platformatic#zoom=h
Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point.
And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.
368 dependencies, 179 dependencies with only one maintainer. 8 different licenses used. No thanks.
Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too.
Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms... The Web needs true change.
Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms... The Web needs true change.
Basically we are in this scenario: https://xkcd.com/927/ Honestly though I think WASM might be the final state of the web.
WASM makes things worse because now "rewrite it in hip new frontend framework X" has more options. Tired of React? Try Blazor WASM (C#) or any of the exciting new Rust-based front ends or any of the up-and-comers in Swift, Go, Perl, Befunge, Intercal, and other favorite languages or flavors of the month. Dart's not just a thing for people installing Chrome Extensions, now you can use it in WASM almost like Father Google intended when Dart was originally envisioned.
Most of these languages can at least use Web Components for some sort of interoperability. At least the ones doing FFI to JS for DOM manipulation. Of course the "new WASM hotness" for "performance" is "do everything in a canvas and avoid the DOM altogether".
Every WASM "app" is an opaque VM to itself. Many WASM languages bundle a lot of things the browser already provides (beyond the ones also building their own DOM engines for canvas-based UIs) including things like GC. Maybe future proposals like WASM GC will start to break down the barriers between WASM languages/runtimes, and open up more instances of memory sharing and data structure reuse. Maybe. The flipside is every GC is special and not every language wants a weak version of JS' GC underpinning their memory management. Hopes for real convergence of WASM language runtimes seem very optimistic to me. (Especially in a world where even the JS DOM is being skipped for canvas apps because some languages want that control.)
WASM may be the final state of the web in terms of being the diaspora of too many languages running on the web and the true death of the View Source web.
Most of these languages can at least use Web Components for some sort of interoperability. At least the ones doing FFI to JS for DOM manipulation. Of course the "new WASM hotness" for "performance" is "do everything in a canvas and avoid the DOM altogether".
Every WASM "app" is an opaque VM to itself. Many WASM languages bundle a lot of things the browser already provides (beyond the ones also building their own DOM engines for canvas-based UIs) including things like GC. Maybe future proposals like WASM GC will start to break down the barriers between WASM languages/runtimes, and open up more instances of memory sharing and data structure reuse. Maybe. The flipside is every GC is special and not every language wants a weak version of JS' GC underpinning their memory management. Hopes for real convergence of WASM language runtimes seem very optimistic to me. (Especially in a world where even the JS DOM is being skipped for canvas apps because some languages want that control.)
WASM may be the final state of the web in terms of being the diaspora of too many languages running on the web and the true death of the View Source web.
FFI is new for me. Foreign function interface? https://en.wikipedia.org/wiki/Foreign_function_interface
> A foreign function interface (FFI) is a mechanism by which a program written in one programming language can call routines or make use of services written or compiled in another one
Nifty, will remember that.
> A foreign function interface (FFI) is a mechanism by which a program written in one programming language can call routines or make use of services written or compiled in another one
Nifty, will remember that.
I'd be fine with pure HTML Websites, just give me a way to make auth extremely secure.
Been ditching js based things outside of work and I'm really enjoying BEAM. It is puzzling to me why companies prefer having 200 microservices orchestrated with Kubernetes if they could have it so much easier by ditching js...
Been ditching js based things outside of work and I'm really enjoying BEAM. It is puzzling to me why companies prefer having 200 microservices orchestrated with Kubernetes if they could have it so much easier by ditching js...
> I think WASM might be the final state of the web
Oh sweet summer child, we've been close to the "final state of the web" for as long as I've done web development.
Oh sweet summer child, we've been close to the "final state of the web" for as long as I've done web development.
> The Web needs true change.
Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be.
I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.
Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be.
I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.
How will you scale your take on this? We are currently facing incredible scaling issues and complexity in web dev because of js based systems.
Meanwhile companies that ditch js have great success (whatsapp, discord, ...)
Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.
Meanwhile companies that ditch js have great success (whatsapp, discord, ...)
Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.
The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you.
The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).
The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).
Good read and I agree fully.
Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack.
CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP.
I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already knew from around 2004, but I feel for all kinds of younger developers who got dragged into the trap.
Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack.
CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP.
I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already knew from around 2004, but I feel for all kinds of younger developers who got dragged into the trap.
If you want to include some dynamic elements without getting into the whole frontend framework thing, HTMx is pretty great for that.
Oh, I do include some JS, just a little bit. A little sprinkle on top, that's enough for my use cases. But CHAMPj just doesn't sound that nice. ;)
After developing applications using native windowing toolkits for over fifteen years, I looked at React briefly in 2015 and have avoided it since. Currently working on several HTML+CSS proofs of concept to support interactive UIs.
Giving up on that treadmill after investing 3 insanely intense years consuming everything about it was the best thing I ever did. Now I write elixir (phoenix liveview), sometimes I write javascript (phoenix hooks), sometimes that javascript uses Alpine. Zero pain.
I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.
I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.
I've only used Elixir/Phoenix as the backend with Elm as the frontend. If you're familiar with that, can you TL;DR what Phoenix Liveview does differently than a Phoenix/Elm/GraphQL stack?
Yes. You get to drop the javascript compile and the graphql and you speak purely in three languages:
1. elixir: def handle_event("save_customer", params, socket)...
2. html: <form :for={@form} phx-submit="save_customer">
3. And sometimes rarely javascript: this.pushEvent("reorder_customer_priorities")
Liveview nearly eliminates the boundary between backend and frontend. Your forms, inputs, outputs, whatever, just become another GenServer with a few special callbacks. You no longer have to worry about an API and syncing data from client to server. The transport layer becomes invisible
It's not even worth it to talk about GenServer or special callbacks. Any idiot can just think of it as "phx-{binding}" html attribute and "handle_event".
That's why I haven't even bothered getting into the atrocity that is modern frontend. I still build stuff mostly like it's 2007. In my projects I don't even have much of a frontend — most of the functionality works without any JavaScript whatsoever — but the JS that I do have has to contain exactly zero third-party runtime dependencies. I'm okay with self-contained third-party scripts like Leaflet for when I need to display a map, and I'm okay with build tools like TypeScript and PostCSS. But that's it really. I'm not having any of that abstraction-over-single-platform nonsense.
This approach is ideal until you try to grow your design team. People will poke at your code for money but it takes a while for them to orient to doing things without their heavy environments.
The biggest problem by far with the frontend ecosystem is that it assumes everyone's been writing perfect frontend code which makes deprecation/migration a breeze. Frontend is much more forgiving then backend, which means you can write absolute dogsh*t and have it not be discovered for years. This compounds, unfortunately, and when it comes time for breaking changes in a new library or framework versions, I think the authors of these versions don't understand how bad it is in the average frontend trenches. So more bad code is written to patch over existing bad code, and the cycle continues. Gets worse, in fact.
I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there.
And other than that? Pure HTML.
It’s downright lovely. And it’ll still work fine 20 years from now.
And other than that? Pure HTML.
It’s downright lovely. And it’ll still work fine 20 years from now.
I maintain an app that was originally written in 2011 in Rails, and a lot of old code looks very similar to what we have in Rails 2025.
It's very easy to dig into existing code. Feels really good.
> And it’ll still work fine 20 years from now.
bold claim. A Rails project of 20 years would not work fine today without a lot of work.
bold claim. A Rails project of 20 years would not work fine today without a lot of work.
Well not if you didn’t do occasion, very light maintenance lol.
It’s like a car. If you’re going to run it, you’ll need to do periodic maintenance.
I didn’t claim you could run it for 20 years without touching it.
It’s like a car. If you’re going to run it, you’ll need to do periodic maintenance.
I didn’t claim you could run it for 20 years without touching it.
Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?
Step 1: Resist the urge to overcomplicate.
Step 2: Don't build multiple applications that need shared components.
Step 3: Profit
I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions.
Having 2 apps that operate slightly differently is okay—even under the same brand.
I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions.
Having 2 apps that operate slightly differently is okay—even under the same brand.
> Having 2 apps that operate slightly differently is okay—even under the same brand.
Perhaps if you those two apps are in completely different domains, but if you have a suite of apps that are all related, maintaining consistent styling and behaviour provides a much better user experience.
Essentially what you're saying is rails isn't capable of solving that problem, and if you're talking about efficiencies/profit, implementing a component _once_ is a better strategy, and actually less complicated than two similar implementations of the same component.
Perhaps if you those two apps are in completely different domains, but if you have a suite of apps that are all related, maintaining consistent styling and behaviour provides a much better user experience.
Essentially what you're saying is rails isn't capable of solving that problem, and if you're talking about efficiencies/profit, implementing a component _once_ is a better strategy, and actually less complicated than two similar implementations of the same component.
Rails can certainly handle those issues. I’m commenting on your example which isn’t a problem anyone _needs_ to solve.
I’ll also point out, sure, better UX, but again—not profitable. Look at Microsoft, one of the largest software companies in the world and people still use their awful products despite no consistent UX.
This isn’t a Rails problem, it’s a leadership problem.
I’ll also point out, sure, better UX, but again—not profitable. Look at Microsoft, one of the largest software companies in the world and people still use their awful products despite no consistent UX.
This isn’t a Rails problem, it’s a leadership problem.
your 3 steps can be summarized in just one?
Step 1 - don't grow
Step 1 - don't grow
Yep. That’s basically Basecamp’s philosophy and it’s worked pretty damn well for them.
Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe, “Don’t grow” is a great philosophy. If you do happen to hit that 0.1%, congratulations you’ve got money to tear everything down and rewrite it in the JavaScript framework du jour.
Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe, “Don’t grow” is a great philosophy. If you do happen to hit that 0.1%, congratulations you’ve got money to tear everything down and rewrite it in the JavaScript framework du jour.
> Considering there’s a near-zero chance you won’t be starting the next Facebook or Stripe
This is like gym beginners worrying they'll get too bulky overnight. You don't want to start with a don't grow philosophy. That's a thing to think when you are big enough.
This is like gym beginners worrying they'll get too bulky overnight. You don't want to start with a don't grow philosophy. That's a thing to think when you are big enough.
I’d say it’s the opposite. Choosing Rails is understanding what is important. To follow on your metaphor, beginners worrying about becoming too bulky should be worrying about getting adequate nutrition and rest; the basics. That’s Rails.
You can start with a Don’t Grow mentality. I have, and it’s working out great. My company makes choices based on that principle, and we’re profitable. But we understand that we don’t want to be a huge corporate conglomeration and never will be.
You can start with a Don’t Grow mentality. I have, and it’s working out great. My company makes choices based on that principle, and we’re profitable. But we understand that we don’t want to be a huge corporate conglomeration and never will be.
Never had those issues. It is just frontend job protection blah. No one should listen to it really.
I once read an article that promoted putting all of your business logic in the database, in the form of stored procedures, functions, etc. I thought the author was completely insane, until I kept reading. "You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database." Have I done it? No... but that opened my mind to a new way of thinking.
My experience with this at one company is the DB became a wild west of cowboyed sprocs that were in source control but a lot of times the sproc in the db didnt match the stored code. It became a way to skirt code reviews and push changes fast. Now, the environment was toxic to begin with, and maybe that wouldnt happen on a project with better technical leadership, but there is a lot of wiggle room for hanky panky at the db level
> You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database.
Or you can properly architecture your application and move the logic layer to a language with better tooling.
Or you can properly architecture your application and move the logic layer to a language with better tooling.
I think this issue will slow down as LLMs become more prominent. I find myself being naturally dissuaded from the "shiny, new thing" because it means my LLM won't have a deep set of materials to draw from.
Writing in Bevy was really hard because it was a niche language that has breaking changes every three months.
Writing in Svelte has been decent/good, but LLMs constantly prefer using v4's syntax rather than v5's runes -- even with Cursor rules and reminders.
At some point I think the tools will become so overwhelmingly part of my workflow that I'll prefer sticking with the old rather than moving to the new and losing access to well-written LLM code code.
Writing in Bevy was really hard because it was a niche language that has breaking changes every three months.
Writing in Svelte has been decent/good, but LLMs constantly prefer using v4's syntax rather than v5's runes -- even with Cursor rules and reminders.
At some point I think the tools will become so overwhelmingly part of my workflow that I'll prefer sticking with the old rather than moving to the new and losing access to well-written LLM code code.
This sounds like it could also be a terrible thing: LLMs freezing progress in languages.
It’s kind of analogous to how the entire web became a slave to SEO.
It’s kind of analogous to how the entire web became a slave to SEO.
I agree. I'm concerned with the implications, too.
I wonder how much of this has been driven by ZIRP, making companies a little bit more lax on what they were spending energy on. Teams are large and devs are decoupled from the end user and end result (PMs, designers, leads, managers have more say on the product being created). That, coupled with devs traditionally, IMO, being enamored by system design and wanting to create even more efficient systems for building things, and given that is the one thing they have direct control over (not the end user experience and product), they would naturally want to focus their efforts on improving their systems for building things, at the sake of missing out on the bigger picture, which is that rebuilding systems has a cost that does not directly translate into net user benefit.
When you're closer to improving the bottom line in terms of sales and user joy, I think there's a greater likelihood that you focus less on spending time rebuilding your platform to whatever is currently hot on the scene. (Not to mention internal promotions may be skewed towards clear engineering efforts vs. more qualitative user-perceived improvements.)
When you're closer to improving the bottom line in terms of sales and user joy, I think there's a greater likelihood that you focus less on spending time rebuilding your platform to whatever is currently hot on the scene. (Not to mention internal promotions may be skewed towards clear engineering efforts vs. more qualitative user-perceived improvements.)
I had this same mindset when React started gaining popularity. "Vanilla JS all the way". Then I saw the power of React, and fell in love with it. Then I landed a position that uses jQuery and Vanilla JS for everything a few years later... and oh my. It's absolutely awful.
I know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, but damn. Wretched.
I know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, but damn. Wretched.
> but damn. Wretched
I am curious.
I know no React. I am neck deep in vanilla TS (not JS, small mercies)
What is "Wretched"?
My needs are simple (nobody at my org gives a single care about beautiful pages, it is an interface to an industrial process - big, feature-full interface, but not public nor a selling point)
I am curious.
I know no React. I am neck deep in vanilla TS (not JS, small mercies)
What is "Wretched"?
My needs are simple (nobody at my org gives a single care about beautiful pages, it is an interface to an industrial process - big, feature-full interface, but not public nor a selling point)
For simple interfaces, vanilla is preferable, of course. But when you're working with mostly dynamic content and huge datasets, it really is a nightmare compared to using something like React.
With vanilla, it just takes more effort to build things. A file could easily become 2,000+ LOC.
With vanilla, it just takes more effort to build things. A file could easily become 2,000+ LOC.
Front-end engineering is incredibly driven by the “fashion” of the moment. The only framework that seems to have maybe overcome fashion is React.
Though React is plagued with its own churn around trends. Perhaps this is aging me a bit but I still can’t get my head around why we threw away class-based components with clear lifecycle methods.
I use hooks regularly now but it just feels so much less elegant than the perfectly fine solution that came before it.
Though React is plagued with its own churn around trends. Perhaps this is aging me a bit but I still can’t get my head around why we threw away class-based components with clear lifecycle methods.
I use hooks regularly now but it just feels so much less elegant than the perfectly fine solution that came before it.
Vanilla JS and the default browser capabilities are quite incredible these days. Server-side templating (jinja2, twig etc.) + vanilla js and some library sprinkle (htmx, graphs) will cover 99% of all web use cases and continue working 10 years later faster than most new stuff.
I recently adapted 3 open source dashboards made in react, alpine and vue to just vanilla JS for my use case and saw at least 100x speed increase. Data rows that took 2~ seconds to render were visually instant. Granted, the original dashbboard code lacked some optimizations but the vanilla code I replaced it with didn't really do any magic to begin with — just got rid of the incredible overhead these frameworks introduce by default.
I recently adapted 3 open source dashboards made in react, alpine and vue to just vanilla JS for my use case and saw at least 100x speed increase. Data rows that took 2~ seconds to render were visually instant. Granted, the original dashbboard code lacked some optimizations but the vanilla code I replaced it with didn't really do any magic to begin with — just got rid of the incredible overhead these frameworks introduce by default.
Probably a little more than 10 years ago I made a project with Django and Angular 1.x. I had a look at it again recently and managed to update Django to v5 with very little effort. The front-end however would obviously need to be completely rewritten.
AngularJS hasn't just disappeared. There are security issues that are now unpatched, but what's the risk here? Users attack software running on their own computer?
> Whatever framework you choose will be obsolete in 5 years.
The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete.
Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
It uses two 500-line libraries, hardly a "framework". One for MVC/History and one for TSX.
The notion that you need React/Svelte/Vue/Angular is what is obsolete. All you need is VanillaJS.
The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete.
Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
It uses two 500-line libraries, hardly a "framework". One for MVC/History and one for TSX.
The notion that you need React/Svelte/Vue/Angular is what is obsolete. All you need is VanillaJS.
VanillaJS is a worse solution. When the JS framework benchmark first came out, VanillaJS was the fastest. After some of the vdom frameworks came out (especially InfernoJS), VanillaJS was slower.
How did they make VanillaJS faster? They studied the output code paths of InfernoJS and copied them. Each time InfernoJS would release new, faster versions, they'd backport those optimizations into the VanillaJS. Then SolidJS and Svelte came out and it copied them.
By the time it was done, the VanillaJS code was fast, but not very readable and definitely NOT the type of code a human would write. Additionally, each new piece being hand-written means each is a brand new chance to miss little implementation details that lead to subtle bugs and memory leaks. As your site grows, you'll also develop bugs from accidentally stomping on someone else's piece of the DOM unless you add all the overhead/complexity of shadow DOM.
pReact (or something similar if it exists) is a much better type of solution IMO. Here's a link to the whole source code minified.
https://esm.sh/[email protected]/es2022/preact.mjs
It's not even a whole page on my laptop screen, but it will be faster than an average dev's VanillaJS code 95% of the time. It won't have those potential implementation bugs. It will scale to many components and devs effortlessly. It also provides clean, tested ways to add other features your project may need in safe ways.
How did they make VanillaJS faster? They studied the output code paths of InfernoJS and copied them. Each time InfernoJS would release new, faster versions, they'd backport those optimizations into the VanillaJS. Then SolidJS and Svelte came out and it copied them.
By the time it was done, the VanillaJS code was fast, but not very readable and definitely NOT the type of code a human would write. Additionally, each new piece being hand-written means each is a brand new chance to miss little implementation details that lead to subtle bugs and memory leaks. As your site grows, you'll also develop bugs from accidentally stomping on someone else's piece of the DOM unless you add all the overhead/complexity of shadow DOM.
pReact (or something similar if it exists) is a much better type of solution IMO. Here's a link to the whole source code minified.
https://esm.sh/[email protected]/es2022/preact.mjs
It's not even a whole page on my laptop screen, but it will be faster than an average dev's VanillaJS code 95% of the time. It won't have those potential implementation bugs. It will scale to many components and devs effortlessly. It also provides clean, tested ways to add other features your project may need in safe ways.
You have to define "worse". What is actually "worse" is paying developer time to sit there in a never-ending upgrade and deprecation cycle when your core product is elsewhere.
React is not a framework.
The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.
I think a lot of people are yearning for the "good old days", where you'd install Apache, drop some .php files into /var/www and start hacking around with only static HTML and maybe a sprinkle of progressive-enhancement JS here and there. I think it's totally okay way to build a dynamic webpage. But web application? Not so sure.
Everyone thinks they have a web application but a lot of the React I get asked to build could have easily just been a dynamic webpage (it is usually a dashboard). I think there is an over-emphasis on what constitutes a "web app".
I think "web fundamentals" here might mean DOM manipulation, browser-native APIs, default form inputs. Stuff like <input type=date> and document.querySelector() and appendChild(), which are often abstracted over or replaced with frameworks.
He's missing the bigger picture, IMHO. Nobody goes back to fundamentals because the industry is not allowing the role to do that. FE engineers don't have control over the codebase to this degree, and the expectation from the company is more about business profit, more usage, etc., instead of building something that will not need to be rewritten.
In other words, the article misses the huge factor that companies don't care enough to allow FE engineering to be about building things properly, and instead make it something akin to a product owner with technical skills.
In other words, the article misses the huge factor that companies don't care enough to allow FE engineering to be about building things properly, and instead make it something akin to a product owner with technical skills.
Besides knowing JavaScript well, there are so many stable web APIs that are not used often. IndexedDB, WebRTC, PWAs, WebComponents, service workers, web/shared workers, Broadcast Channel API, File System APIs, Cache API...
I also miss the web. When HTTP form posts were a thing. React and friends are desktop apps, delivered over HTTP, where the browser is the runtime. You know why we got so obsessed with JavaScript? Cause screen refreshes look janky. "Just use XMLHttpRequest to send the data ONLY over the wire! And get data ONLY as a response!" That's how we got into this mess. I'm not saying you don't need JavaScript, or there aren't reasons to use React. I'm saying there are easier solutions to jank. If good engineering is the ability to design the least complicated solution to a problem, we are far from good engineering.
It's weird to see React frequently treated in these kinds of discussions as the opposite of the good-old ways of doing things because React has great support for server-side rendering and form posts. Its server support was one of its major features that initially distinguished it from other front-end frameworks of the time and helped lead to its popularity.
I wonder whether AI being the new and shiny thing will lead to a reduction in ‘innovation’ in front-end frameworks. Front-end dev seems to me to have been a solved problem for years now, yet there are still new ways of doing things for marginal gains. I personally just use vanilla JS (having never built anything Facebook-scale which would necessitate using a tool like React) and would be happy if instead of working on yet more front-end stuff, folk will otherwise build something AI-related, both because that is where the hype is but also because it’s genuinely exciting.
Much of the tech churn in frontend is likely attributable to it being an entry door for beginner coders over other pathways. Most of us got started in web dev and made big messes using frameworks we didn't understand. So e of us got better and changed the framework to make it more x, y, or z. Some decided, I'll build my own that doesn't have those x, y, z problems. And so here we are. TBD if HTML standards can ever replace this cycle.
I think this THE main reason why many people are getting fed up with javascript heavy frontends and switching to technologies like htmx.
Personally I stick to json to feed data to my frontends, but I gave up on "frameworks" a while back and just implemented my own abstractions on top of vanilla js and the dom and have been happily using them for years. If you work in large teams with people that don't care so much tough, that would also have drawbacks.
Personally I stick to json to feed data to my frontends, but I gave up on "frameworks" a while back and just implemented my own abstractions on top of vanilla js and the dom and have been happily using them for years. If you work in large teams with people that don't care so much tough, that would also have drawbacks.
Yup. The Frontend ecosystem juice isn't worth the squeeze unless you've got a full time team of software devs on your project. Better to ditch NPM etc. and go with HTMX.
I think there's a big part of the picture being missed here. Frontend is bad because of how the industry treats frontend engineering, and web engineering overall. Companies will make engineers do way more than just focus on the code and build things properly and correctly. This is why they all gravitate towards the new, shiny library and over time the ecosystem is a huge mess of dozens upon dozens of libraries just to build something simple. They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly.
> On a more personal note, this is frustrating to me because I think it’s a big part of why we’re seeing the web stagnate so much. I still run into lots of devs who are creative and enthusiastic about building cool things. They just can’t.
Yes, because they're not allowed to just code. It's no longer enough for the role, and the expectations include everything from talking to stakeholders, to crafting the requirements, to testing, releasing, and doing the telemetry and analyticis. Obviously nobody will have the focus or time to build anything properly this way, and they will always choose to use external libraries instead of making something from scratch that will fit the domain space and will allow full control to build something with no bugs.
It's amazing how the industry has accepted that bugs are normal, and part of building frontends, when good engineering should mean that you are able to build and ship something with almost zero bugs. The industry has changed the role and steered it away from what engineering is supposed to be, which is building things properly, and now people are scratching their heads as to why we have such bad software and everything is so complicated on the frontend.
> On a more personal note, this is frustrating to me because I think it’s a big part of why we’re seeing the web stagnate so much. I still run into lots of devs who are creative and enthusiastic about building cool things. They just can’t.
Yes, because they're not allowed to just code. It's no longer enough for the role, and the expectations include everything from talking to stakeholders, to crafting the requirements, to testing, releasing, and doing the telemetry and analyticis. Obviously nobody will have the focus or time to build anything properly this way, and they will always choose to use external libraries instead of making something from scratch that will fit the domain space and will allow full control to build something with no bugs.
It's amazing how the industry has accepted that bugs are normal, and part of building frontends, when good engineering should mean that you are able to build and ship something with almost zero bugs. The industry has changed the role and steered it away from what engineering is supposed to be, which is building things properly, and now people are scratching their heads as to why we have such bad software and everything is so complicated on the frontend.
> They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly.
The reason is that most business are marketing driven, where the focus is let's try this to see if it sticks. Everything from the product to the technical implementation is a prototype where no ones can articulate a specification for anything. The same has infected Windows and macOS where no focus is given to the whole, but it's just adding beta features on top of other beta features.
The reason is that most business are marketing driven, where the focus is let's try this to see if it sticks. Everything from the product to the technical implementation is a prototype where no ones can articulate a specification for anything. The same has infected Windows and macOS where no focus is given to the whole, but it's just adding beta features on top of other beta features.
We're trying to hire an Angular design engineer, so now the recruiter is the person trying to get management to switch to React to make his search easier. The tech doesn't matter too much, but the market forces do.
Management should not be listening to technology advice from recruiters.
Feels like an article from 2015, where churn was still enormous. Today we have more stability: mostly React, Angular is also still around, some novel approaches like Svelte or HTMX, but mostly its the reactive paradigm packaged in different ways (eg Vue.js). No XHTML, no IE6, heck not even IE. CSS converges on Tailwind.
What is unsolved is the dependency hell: builds break over time, just by NPM rot.
What is unsolved is the dependency hell: builds break over time, just by NPM rot.
Meanwhile, my team has been trying to upgrade a large app from vue2/nuxt2 to vue3/nuxt3, which has no real upgrade path at all.
Oh, and the time between nuxt3's prod release and vue2's EOL was like 9 months.
Vue 3 IS better than 2, but at what cost?
Oh, and the time between nuxt3's prod release and vue2's EOL was like 9 months.
Vue 3 IS better than 2, but at what cost?
At least when Vue 4 rolls around, you can pay Claude Code to do it for you (for a modest fee).
Btw what made you choose Vue over React?
Btw what made you choose Vue over React?
Not GP but if I were to start a project today that needs an SPA I would go Vue rather than React 100%. Or if you want to be trendy, something like Solid or Svelte are also ok.
React is okay-ish when done in moderation but it becomes spaghetti too quickly when the team is not made of 10x ninja rockstars from space. It is particularly bad for startups, you either slow down with code reviews or pay the price. The main reason IMO is the reactivity mode. Too many footguns to watch out for.
Plus, the quality of third-party React packages is abysmal. What a terrible ecosystem. Using as few dependencies as possible makes it better, but it's hard to push back on larger teams.
In the end it's all about opinion of course but after 10 years going back and forth between both (hey I'm trying to stay employable) that's my experience.
EDIT: But if I had to do SSR I would avoid Javascript period. Lots of backend languages are better for SSR.
React is okay-ish when done in moderation but it becomes spaghetti too quickly when the team is not made of 10x ninja rockstars from space. It is particularly bad for startups, you either slow down with code reviews or pay the price. The main reason IMO is the reactivity mode. Too many footguns to watch out for.
Plus, the quality of third-party React packages is abysmal. What a terrible ecosystem. Using as few dependencies as possible makes it better, but it's hard to push back on larger teams.
In the end it's all about opinion of course but after 10 years going back and forth between both (hey I'm trying to stay employable) that's my experience.
EDIT: But if I had to do SSR I would avoid Javascript period. Lots of backend languages are better for SSR.
> The main reason IMO is the reactivity mode. Too many footguns to watch out for.
But Vue is reactive as well? Eg communication between components is not straightforward.
But Vue is reactive as well? Eg communication between components is not straightforward.
Vue is quite different, as it uses proxies for reactivity and automates a lot for you… no need for dependency arrays or worrying about re-renders, for example.
I like React but it does put some burden on the developer to get it right. I find that even backend devs doing frontend super casually adapt quick and barely makes mistakes in Vue, but in React even experienced mid-level frontend devs can make a mess pretty quickly.
All IMO and IME of course.
I like React but it does put some burden on the developer to get it right. I find that even backend devs doing frontend super casually adapt quick and barely makes mistakes in Vue, but in React even experienced mid-level frontend devs can make a mess pretty quickly.
All IMO and IME of course.
Front-end dev of 20+ years. Plenty of back-end and full stack work in there too. While I definitely agree with the sentiments in this article, I feel it is a bit more nuanced a conversation than this.
While you can truly swap out the UI and ultimately the front-end doesn't matter if the back-end isn't solid long-term - you can equally swap out/automate/just install a rock solid back-end framework, just like you can a front-end.
Furthermore, the front-end is the single thing that customers/users typically interact with - which makes it drastically more important than is let on in the article. We were recently doing a book study on measuring UX and I am pretty convinced that the way people feel about a thing is more important than how well it functions.
I don't really even call myself front-end or back-end anymore.. to be honest I'm not sure it's as useful of a distinction as it has been in the past. Both aspects of an app need to be solid and also bespoke to a degree imo.
While you can truly swap out the UI and ultimately the front-end doesn't matter if the back-end isn't solid long-term - you can equally swap out/automate/just install a rock solid back-end framework, just like you can a front-end.
Furthermore, the front-end is the single thing that customers/users typically interact with - which makes it drastically more important than is let on in the article. We were recently doing a book study on measuring UX and I am pretty convinced that the way people feel about a thing is more important than how well it functions.
I don't really even call myself front-end or back-end anymore.. to be honest I'm not sure it's as useful of a distinction as it has been in the past. Both aspects of an app need to be solid and also bespoke to a degree imo.
I am quite some time in the biz but I see it as a feature not a bug.
I was waiting until we get rid of IE6.
Nowadays no one will support anything for dozens of year so you would have to take care of some bug ridden monstrosity because it will get decommissioned because it will just stop working and cost of supporting it will be higher.
Your CRUD web app is not a nuclear powered plant to run 50 years.
I was waiting until we get rid of IE6.
Nowadays no one will support anything for dozens of year so you would have to take care of some bug ridden monstrosity because it will get decommissioned because it will just stop working and cost of supporting it will be higher.
Your CRUD web app is not a nuclear powered plant to run 50 years.
If someone new to FE development were to start today, what would the process be?
A) If they are on their own (one-person team), they will do a web search and pick the most popular framework/library etc. Or do some POCs in a few of these frameworks/libraries and pick one.
B) If they are part of a team, they will go with whatever the team has decided
If someone has been doing FE, they either will stick to whatever they are doing or search for what else is out there. Yes. This sounds like a treadmill - but that is part of software development and continuous improvement, right?
Building a website in plain/vanilla JS or no JS is possible.
It all boils down to what is moving the product development forward. And this isn’t always simple or possible with FEs.
There are many choices for BEs and cloud providers as well - and sometimes a combination of those.
In short, there are no right or wrong answers. It is always - “it depends” - on what scenarios you are targeting and what features you want to build
A) If they are on their own (one-person team), they will do a web search and pick the most popular framework/library etc. Or do some POCs in a few of these frameworks/libraries and pick one.
B) If they are part of a team, they will go with whatever the team has decided
If someone has been doing FE, they either will stick to whatever they are doing or search for what else is out there. Yes. This sounds like a treadmill - but that is part of software development and continuous improvement, right?
Building a website in plain/vanilla JS or no JS is possible.
It all boils down to what is moving the product development forward. And this isn’t always simple or possible with FEs.
There are many choices for BEs and cloud providers as well - and sometimes a combination of those.
In short, there are no right or wrong answers. It is always - “it depends” - on what scenarios you are targeting and what features you want to build
Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?
I think it’s because, on a fundamental level, we have been trying to wedge an app platform into a document reader.
Zoom out and think about how mad this is. Like if we tried to build “Web 2.0” inside Adobe Acrobat Reader.
Apple has prescribed front-end frameworks like AppKit and UiKit and now SwiftUI, Linux had Gnome and GTK and whatever (I’m not an expert and my knowledge here is out of date)… there’s never been a Correct Way to build a web app because the browser doesn’t have an Apple Microsoft or Linux Foundation, so we’ve been winging it all along.
I’m similarly tired of framework churn, NextJS server components might be the breaking point for me. But there’s no way I’m going back from component driven architecture, and I’m not sure what a vanilla js answer to a static site builder like Next (back when it was good) or Gatsby would be like.
Zoom out and think about how mad this is. Like if we tried to build “Web 2.0” inside Adobe Acrobat Reader.
Apple has prescribed front-end frameworks like AppKit and UiKit and now SwiftUI, Linux had Gnome and GTK and whatever (I’m not an expert and my knowledge here is out of date)… there’s never been a Correct Way to build a web app because the browser doesn’t have an Apple Microsoft or Linux Foundation, so we’ve been winging it all along.
I’m similarly tired of framework churn, NextJS server components might be the breaking point for me. But there’s no way I’m going back from component driven architecture, and I’m not sure what a vanilla js answer to a static site builder like Next (back when it was good) or Gatsby would be like.
Absolutely. It took me a while to realize that I hated web development and why: because of all the layers of stuff you have to deal with on top of that document fetching platform. Something as simple as maintaining a login session is a complicated problem, even before you get into validating users, single sign-on, etc. You can put a lot of that out-of-sight/out-of-mind by letting a framework deal with it, but it's still there, lurking, waiting to bite you. And that's just one small aspect of building a web app.
It's too bad Java sucked so much. Maybe we could have had applets that worked like desktop apps, keeping the app-type stuff within applets and leaving the document reader alone. Probably not.
It's too bad Java sucked so much. Maybe we could have had applets that worked like desktop apps, keeping the app-type stuff within applets and leaving the document reader alone. Probably not.
But most web apps are actually web sites and they do fit the document model. If we consider the web as a UI layer, it's capabilities are more than just sufficient. The issue is when you want to bring business logic into it, or fighting the document model to bring in your own abstractions.
[deleted]
I'm going to go out on a limb and also suggest that there's a lower barrier to entry with HTML. You get a lot "for free" and this means there's more to choose from.
(But yes, I think this is a good assessment, and it matches my experience.)
(But yes, I think this is a good assessment, and it matches my experience.)
It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)
Churn complaints are older than Angular 2. We'd gone through an entire cycle of churn around templating engines (mustache, handlebars, ejs, jade/pug, nunchucks, underscore, lodash).
Gen 1 wars (up through 2010-ish), we had: jQuery-UI, Prototype, SproutCore, YUI, MooTools, Google Web Toolkit, Dojo, ExtJS, BackboneJS, etc. There were no survivors.
Gen 2 wars (up through 2015-ish): Angular, KnockoutJS, Ember, Enyo, React, Vue, Meteor, Polymer, Aurelia, Elm, Mithril, etc.
Gen 3 wars (up through today): React, pReact, Vue, Angular 2, Svelte, SolidJS, AlpineJS, InfernoJS, Lit, etc.
We're actually more stable than we have been in a long time. The difference in performance changing frameworks could often get 10x or sometimes even closer to 100x performance increase. Today, even the slowest framework is generally within 20-30% of hyper-optimized VanillaJS. You really can't go wrong with any of them anymore.
Gen 1 wars (up through 2010-ish), we had: jQuery-UI, Prototype, SproutCore, YUI, MooTools, Google Web Toolkit, Dojo, ExtJS, BackboneJS, etc. There were no survivors.
Gen 2 wars (up through 2015-ish): Angular, KnockoutJS, Ember, Enyo, React, Vue, Meteor, Polymer, Aurelia, Elm, Mithril, etc.
Gen 3 wars (up through today): React, pReact, Vue, Angular 2, Svelte, SolidJS, AlpineJS, InfernoJS, Lit, etc.
We're actually more stable than we have been in a long time. The difference in performance changing frameworks could often get 10x or sometimes even closer to 100x performance increase. Today, even the slowest framework is generally within 20-30% of hyper-optimized VanillaJS. You really can't go wrong with any of them anymore.
Gen 1 wasn't Gen1. Gen1 for dynamic websites was a lamp stack with yolo javascript in the php header. Then people really started using jQuery because targeting a bunch of browsers at the time was a huge incompatible mess, along with other tools like modernize.js . Then your gen 1 started in earnest, if I remember correctly.
I remember the divisions slightly differently . There seemed to be a core movement from Ember.js and backbone onto Angular. Then from angular to react. Now I am seeing some movement off of react onto alternatives like Vue and Svelte, but almost everyone still is using react. Most shops have issues with the React part of their stack. It's still hard to get buy in for the alternatives in production. No one is using web assembly or even knows what a web component is.
I disagree about the comment about not going wrong with either. This assumes you or your team have the time to maintain the stack with the large amount of dependencies, as there are security patches often and deprecations often. It's a waste when it seems like a large portion of the actual market is just creating dashboard products. You can handle this with a much lighter frontend if you can get buy in (you can't).
I remember the divisions slightly differently . There seemed to be a core movement from Ember.js and backbone onto Angular. Then from angular to react. Now I am seeing some movement off of react onto alternatives like Vue and Svelte, but almost everyone still is using react. Most shops have issues with the React part of their stack. It's still hard to get buy in for the alternatives in production. No one is using web assembly or even knows what a web component is.
I disagree about the comment about not going wrong with either. This assumes you or your team have the time to maintain the stack with the large amount of dependencies, as there are security patches often and deprecations often. It's a waste when it seems like a large portion of the actual market is just creating dashboard products. You can handle this with a much lighter frontend if you can get buy in (you can't).
There was also a huge bunch of completely forgotten ActionScript Flash stuff.
Hmm...
React, Backbone, jQuery.
SwiftUI, AppKit, Cocoa, Carbon, Toolbox.
WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI.
---
Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.
React, Backbone, jQuery.
SwiftUI, AppKit, Cocoa, Carbon, Toolbox.
WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI.
---
Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.
Yes, of course. In good faith, I'm not trying to accuse specific WWW frameworks of being less-backwards-compatible—react has actually done a pretty damn good job of guiding people along upgrades. But culture-wise there's a massive difference in discourse, and native apps still have the best quality. Spotify's app is horrifically bad; slack and notion could be worse, but these are hardly examples of excellence. Apps that do perform well seemingly need to hook directly into native widgets to compete (see: tiktok).
(And sure you could view AppKit/Cocoa/SwiftUI as distinct frameworks, but ultimately they're all just different interfaces to the same event loop and there's typically a clear indication which one you should be using in which context. The transition from Carbon to Cocoa took more than a decade to complete!!! Most of my Cocoa code from the era can be gotten to compile with modern macosx in under an hour, and most of the performance lessons from then apply directly to AppKit. SwiftUI can and should be used as a wrapper around these views if possible.)
(And sure you could view AppKit/Cocoa/SwiftUI as distinct frameworks, but ultimately they're all just different interfaces to the same event loop and there's typically a clear indication which one you should be using in which context. The transition from Carbon to Cocoa took more than a decade to complete!!! Most of my Cocoa code from the era can be gotten to compile with modern macosx in under an hour, and most of the performance lessons from then apply directly to AppKit. SwiftUI can and should be used as a wrapper around these views if possible.)
You left out other 150 major web frameworks.
I also left out Qt, Swing, etc. on the desktop. I'm comparing a direct lineage of replacements, not showing diversity of choice.
Hi, I've been a web front-end dev for 25+ years. I have no idea what Backbone is/was. There's no direct lineage there, I think that's a sort of forced reading. Also the whole notion of a "front-end vs back-end" division only covers part of the web's history.
imo a real "lineage" would be something like…
- pre-AJAX, server-rendered sites (PHP, JSP, ASP, ColdFusion; no division of front/back-end)
- the monolithic framework era (Drupal, Ruby on Rails, Laravel) with some AJAX Javascript and jQuery sprinkled in
- the modern era of reactive frameworks (front-end fully decoupled)
Even within the most popular modern framework, NextJS, the first question a developer has to ask is “how do I manage state?” Actually that's the second question; the first is “how do I manage styling? should I use Tailwind, or something that doesn't suck?"
Immediately you're looking at dozens of conceptually different choices, which makes one wonder if it even makes sense to call NextJS a framework at all. A real framework would have prescribed methods.
This is why there's front-end churn, there's never been a right way to do any of this, because the web wasn't designed to be an app platform. It's all hacks, from top to bottom.
imo a real "lineage" would be something like…
- pre-AJAX, server-rendered sites (PHP, JSP, ASP, ColdFusion; no division of front/back-end)
- the monolithic framework era (Drupal, Ruby on Rails, Laravel) with some AJAX Javascript and jQuery sprinkled in
- the modern era of reactive frameworks (front-end fully decoupled)
Even within the most popular modern framework, NextJS, the first question a developer has to ask is “how do I manage state?” Actually that's the second question; the first is “how do I manage styling? should I use Tailwind, or something that doesn't suck?"
Immediately you're looking at dozens of conceptually different choices, which makes one wonder if it even makes sense to call NextJS a framework at all. A real framework would have prescribed methods.
This is why there's front-end churn, there's never been a right way to do any of this, because the web wasn't designed to be an app platform. It's all hacks, from top to bottom.
Backbone sat right between the jQuery sprinkle and reactive frameworks era. It popularized a bunch of important concepts that quickly led to the next era:
- storing data in JavaScript, not in DOM elements
- separate models and views before JavaScript even had the class keyword
- decoupling from your back-end through a RESTful API
- templates that would be filled with data in the browser
- client-side routing
However, it was not in the same league as reactive frameworks like Angular.js or Ember. It was missing two big things, which destined it to be a bridge from the jQuery era to the present.
- Reactivity that stretches to the DOM. Backbone's views had a `render` hook you had to implement that expected you to either replace the HTML wholesale or go fiddle with the DOM yourself.
- Partials or Components. Backbone didn't support subviews at all.
- storing data in JavaScript, not in DOM elements
- separate models and views before JavaScript even had the class keyword
- decoupling from your back-end through a RESTful API
- templates that would be filled with data in the browser
- client-side routing
However, it was not in the same league as reactive frameworks like Angular.js or Ember. It was missing two big things, which destined it to be a bridge from the jQuery era to the present.
- Reactivity that stretches to the DOM. Backbone's views had a `render` hook you had to implement that expected you to either replace the HTML wholesale or go fiddle with the DOM yourself.
- Partials or Components. Backbone didn't support subviews at all.
As someone who developed web apps since the DHTML days when DOM was not yet standardized,... :)
I'd add another major category and that's ExtJS and friends (large integrated MVC GUI component frameworks), which successfully replicated the [developer] feel of desktop GUI toolkits in the browser, somewhere between your last two categories.
I'd add another major category and that's ExtJS and friends (large integrated MVC GUI component frameworks), which successfully replicated the [developer] feel of desktop GUI toolkits in the browser, somewhere between your last two categories.
There's no direct lineage.
Could you name any of these "150 major web frameworks"?
Are you using QT 1.0? I don't think any (updated) desktop GUI from 30 years ago has stayed backwards compatible. So yes frameworks like QT are from 30 years ago but they are entirely different from what they used to be back then. Except for maybe some winforms stuff?
Because web apps you see today were not feasible even 10 years ago
(and I'm not talking about simple static websites)
(and I'm not talking about simple static websites)
Like what? I think the web looked more or less the same in 2015 as it does today.
Wasm, WebGPU, a bunch of PWA features etc...
I mean, we had asm.js in 2013, which ran Unreal Engine 4 in the browser.
WebGPU is new, but WebGL came out in 2011.
WebGPU is new, but WebGL came out in 2011.
Noobs. Almost all typescript devs and React devs and especially NextJs devs are terrible programmers and absolute beginners. So that creates churn.
Speaking of front end frameworks, whatever happened to Angular(JS)? It seemed to be required on every other job posting, but now things seem to only ask for React or React Native.
If anonymous posters on HN are to be believed, the guy spearheading Angular as a major frontend framework got his mansion on a hill and he left. And before that the Angular developers burned down their community by breaking compatibility in the transition between 1.X and 2.0.
Develop on Google -- when you really really really want to refactor your web app every 6 months. Love me some Android version bumps -- who needs compatible API interfaces?? Never did Microsoft or Intel/AMD any favors.
I still see many job postings for Angular, mainly from government institutions and non-tech companies. In my region, Angular for the frontend and Java with Spring Boot for the backend still account for a healthy number of job postings.
I began doing AngularJS and have been doing Angular 2 for a while, as another commenter said: there are jobs still out there.
In my experience I get more Angular & Vue offers than C# and React. For what is worth I'm convinced that across the industry React jobs wages are lower. Who knows, I could be closed in my own bubble but am pretty sure the pool of react devs is bigger and this might be the reason.
In my experience I get more Angular & Vue offers than C# and React. For what is worth I'm convinced that across the industry React jobs wages are lower. Who knows, I could be closed in my own bubble but am pretty sure the pool of react devs is bigger and this might be the reason.
Angular's fine, new versions come out regularly, often improving DX. Although I must admit that deprecation and breaking changes mentioned in the article sometimes make keeping up with updates kinda annoying. On the other hand, I'd never return to a home grown framework. Most of my problems nowadays come from business requirements and lackluster IT.
I see angular postings still. I can't claim I've touched frontend in a half decade, though.
The difference in speed between Angular 1 and React was like the difference between Python and Rust. Not only was React simpler than Angular and had fewer footguns, but it was so ridiculously fast out of the box compared to Angular.
Then Google google'd and left devs high and dry with the need to rewrite their apps from Angular 1 to Angular 2+, whereas React has been relatively stable, despite some incompatibilities -- yes there are new features and new methods, but you can still do React classes.
Then Google google'd and left devs high and dry with the need to rewrite their apps from Angular 1 to Angular 2+, whereas React has been relatively stable, despite some incompatibilities -- yes there are new features and new methods, but you can still do React classes.
The frontend world gave you many fancy toys; but they all come with hidden cost. It is your choice: do you want to stay on or get off this treadmill? My need is modest, so I got off. I rewrote my simple SPA from Svelte to SolidJS to no framework at all. Now I have ~1000 LOC javascript, ~500 LOC CSS, all written by myself. No framework, no package, no build step. If you want to see it in action:
https://airss.roastidio.us
It is a fully functional RSS reader. You are welcome to poke under the hood. The key insight is that I don't need reactivity, if re-rendering everything at every event is fast enough.
I believe this style of barebone SPA programming can scale up to at least 10,000 LOC javascript.
https://airss.roastidio.us
It is a fully functional RSS reader. You are welcome to poke under the hood. The key insight is that I don't need reactivity, if re-rendering everything at every event is fast enough.
I believe this style of barebone SPA programming can scale up to at least 10,000 LOC javascript.
Just use Ruby on Rails. Problem solved.
I can't imagine having to build a frontend in React... I'm doing everything from mobile app to extensive frontend using Rails... no React anywhere. Just plain vanilla Rails and it's been a godsend!
Any chance Addison-Wesley will publish more Professional Ruby Series books? Those were great books, yours especially.
Just use Angular and stop worrying. Batteries included, it works and works well.
Yes there was a big change from v1 to v2, but we are at v19 now I think and upgrades are pretty painless IME (I generally don't even really notice them happening, and there is even a tool to help know what changed: https://angular.dev/update-guide) I've been using it at BigCos now for years and it's really just totally fine, and importantly zero drama.
They key thing is you only need angular so you don't need a whole fleet of dependencies that you also need to migrate at the same time.
Yes there was a big change from v1 to v2, but we are at v19 now I think and upgrades are pretty painless IME (I generally don't even really notice them happening, and there is even a tool to help know what changed: https://angular.dev/update-guide) I've been using it at BigCos now for years and it's really just totally fine, and importantly zero drama.
They key thing is you only need angular so you don't need a whole fleet of dependencies that you also need to migrate at the same time.
Upgrading to standalone components and the new signal API right now, not sure I’d say this avoids the frontend treadmill
standalone for us was piecemeal - just do it one by one line of code here or there when you are already in the component making other changes.
Likewise signals it was trivial to just change @Input() to input (ok slight simplification but not by much - I think there are automated scripts to do it anyway if you want to do it in one fell swoop?) when already in a component making changes.
But you didn't have to, which is nice. You could take your time doing it but by bit if you wanted, no rush etc. I don't think the old ways are even fully gone yet anyway?
Likewise signals it was trivial to just change @Input() to input (ok slight simplification but not by much - I think there are automated scripts to do it anyway if you want to do it in one fell swoop?) when already in a component making changes.
But you didn't have to, which is nice. You could take your time doing it but by bit if you wanted, no rush etc. I don't think the old ways are even fully gone yet anyway?
You may not have to today, but you will one day. They will remove zone.js and there will be a whole host of deprecated libraries and outdated blog posts about how to do things the “angular” way. If the vite dev server didnt feel so much snappier, I would lament it, however, I think overall its a nice change.
And sure, just change components while you are in there, but this is for my blog libraries I work on in my spare time. A lot of the standalone stuff just feels like change for change sake and the scripts did not run against a library project. I tried to dig into the @angular/cli repo to try and figure out what was going on, but after reading a few classes noped out and just converted by hand. Only takes a couple of hours or a day to test, but thats 0 productivity time. Change detection is different now and leveraging ngOnChanges is def broken now, zone js removal is experimental, and all of it so Angular becomes more like React as far as I can tell.
My new projects are Django with templates and post backs. Its a breath of fresh air.
+1 for Angular, upgrading has always been very easy and somewhere since V15 or so the build times have gotten insanely fast. Hot reloading a largeish cross-platform app with WASM takes less than 3 seconds. Deploys are also very simple.
As a frontend engineer, I see the proclivity frontend engineers have for fully rewriting their codebase in a new framework for literally no reason all the time. It drives me absolutely bananas. This would never happen in game dev.
> People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away
This hit hard.
This hit hard.
> Whatever framework you choose will be obsolete in 5 years.
IDK our product is older than 5 years and React is still not obsolete.
IDK our product is older than 5 years and React is still not obsolete.
Doesn't seem to be a popular opinion here, but I think FE can be ok. A typical React application feels easier to reason about than HTMX-based code that I looked at. I never had a hard time picking up an app that used React/Preact + Tailwind + some simple state management library like Preact Signals.
Maybe never having had to deal with GraphQL or Server Components helped.
Tooling, OTOH, does feel like it gets insane from time to time. I don't know why we needed such a painful migration to go from CommonJS to ES Modules in Node.js. They always just 'worked' in Bun, and even Node.js has a flag these days to allow you to use both of them together. ESLint changed their configuration format and instantly made every existent tutorial/configuration available out of date. I fail to see how anyone benefited from that.
It's not as popular these days, but I appreciate how Meteor always made an effort to be backwards compatible to the extend it was possible. The only __major__ migration was going from Fibers to Promises - and I don't blame them for picking the wrong 'horse' 13 years ago.
But yeah I feel very comfortable doing FE these days. Meteor for bigger fullstack apps, or just Vite for a simple FE, and things just work. TypeScript tooling is better than ever. AI helps automating lots of the simpler but tiring tasks like generating Zod schemas.
Maybe never having had to deal with GraphQL or Server Components helped.
Tooling, OTOH, does feel like it gets insane from time to time. I don't know why we needed such a painful migration to go from CommonJS to ES Modules in Node.js. They always just 'worked' in Bun, and even Node.js has a flag these days to allow you to use both of them together. ESLint changed their configuration format and instantly made every existent tutorial/configuration available out of date. I fail to see how anyone benefited from that.
It's not as popular these days, but I appreciate how Meteor always made an effort to be backwards compatible to the extend it was possible. The only __major__ migration was going from Fibers to Promises - and I don't blame them for picking the wrong 'horse' 13 years ago.
But yeah I feel very comfortable doing FE these days. Meteor for bigger fullstack apps, or just Vite for a simple FE, and things just work. TypeScript tooling is better than ever. AI helps automating lots of the simpler but tiring tasks like generating Zod schemas.
I also want to add: the new hooks introduced by React 19 seem like a complexity creep. But I haven't found any need to use them yet.
Just write vanilla JS, CSS and HTML. Web standards have improved so much over the past 10 years. You don’t need any of the junk people talk about—not even Tailwind. Not even Svelte. Just KISS.
I've proposed an idea several times that I think might resolve this situation, but it's never received any real uptake and I can see some serious issues with the approach.
Instead of building a "inner system" (https://en.wikipedia.org/wiki/Inner-platform_effect) where the browser uses HTML, CSS, and Javascript to create interactive applications, or attempting to make a sandboxed and highly limited execution environment (WebAssembly), browser tabs should be Virtual Machines- in the sense that VMWare, KVM, and HyperV are VMs, not in the sense that some language runtimes are VMs.
Think about it: every tab on your machine could be its own little machine running a full stack and rendering the output to a framebuffer (the tab window content). It provides precisely the sandboxing and virtual IO that existing VMs have already implemented and optimized.
But of course, if you do this, you don't actually need a browser window with tabs: you just render the application to a standalone window. But then really what value does the browser provide, other than giving you some convenient runtime for accessible web resources? So just put the browser runtime in the operating system and host applications within virtual machines. Nothing stops you from building applications using web frameworks- you can still use javascript, HTML, and CSS if you want, within or seperate from existing high quality graphics application frameworks (like Qt, GTK, etc).
Those reading carefully will note this is exactly what (some) operating systems have been capable of doing for longer than the WWW has existed, and all major operating systems now support this natively (KVM, HyperV, Apple Hypervisor) and they also all embed full browser capability in native libraries. The main issue I see is that there are now 2 or 3 hardware architetures (x86, arm, risc-v) and a VM does not directly resolve performance issues of cross-arch translation, so devs would still need to produce binary packages for 2-3 archectures to reach the level of cross-OS compatibility that browsers currently support.
I work frequently with Qt and it's amazing how much better it is for building powerful, complex applications that have long term support.
Instead of building a "inner system" (https://en.wikipedia.org/wiki/Inner-platform_effect) where the browser uses HTML, CSS, and Javascript to create interactive applications, or attempting to make a sandboxed and highly limited execution environment (WebAssembly), browser tabs should be Virtual Machines- in the sense that VMWare, KVM, and HyperV are VMs, not in the sense that some language runtimes are VMs.
Think about it: every tab on your machine could be its own little machine running a full stack and rendering the output to a framebuffer (the tab window content). It provides precisely the sandboxing and virtual IO that existing VMs have already implemented and optimized.
But of course, if you do this, you don't actually need a browser window with tabs: you just render the application to a standalone window. But then really what value does the browser provide, other than giving you some convenient runtime for accessible web resources? So just put the browser runtime in the operating system and host applications within virtual machines. Nothing stops you from building applications using web frameworks- you can still use javascript, HTML, and CSS if you want, within or seperate from existing high quality graphics application frameworks (like Qt, GTK, etc).
Those reading carefully will note this is exactly what (some) operating systems have been capable of doing for longer than the WWW has existed, and all major operating systems now support this natively (KVM, HyperV, Apple Hypervisor) and they also all embed full browser capability in native libraries. The main issue I see is that there are now 2 or 3 hardware architetures (x86, arm, risc-v) and a VM does not directly resolve performance issues of cross-arch translation, so devs would still need to produce binary packages for 2-3 archectures to reach the level of cross-OS compatibility that browsers currently support.
I work frequently with Qt and it's amazing how much better it is for building powerful, complex applications that have long term support.
Browsers like Chrome already allow you to install websites that support it to your computer as a desktop app, and a page can already fill itself with a canvas element to allow itself to be programmatically in charge of all the pixels in it. What you describe sounds like a more limited version of what we already have today, other than the suggestion that this should be a responsibility of the OS.
Reminds me of: https://xkcd.com/1367/
Webpages being rendered framebuffers would be terrible for consistency and accessibility. All the logic for layout computation, responsive design, font rendering, and literally thousands of other things browser have developed over the decades would go out the window.
But on the topic of multi-architecture, that’s really what web assembly is. I’d be surprised if it didn’t continue too become more important, it looks like it’s escaping the browser and into backend apps and server code too.
Webpages being rendered framebuffers would be terrible for consistency and accessibility. All the logic for layout computation, responsive design, font rendering, and literally thousands of other things browser have developed over the decades would go out the window.
But on the topic of multi-architecture, that’s really what web assembly is. I’d be surprised if it didn’t continue too become more important, it looks like it’s escaping the browser and into backend apps and server code too.
GUI frameworks have done accessibility and consistency better than browsers (which includes layouts, font rendering, etc) for decades. The browsers are literally just inner platforms that take the capabilities available in the GUI framework, and make it available through a set of API (javascript), content (HTML) and styling (CSS). Moving applications from browser tech to GUI framework tech doesn't throw anything away because GUI frameworks embed widgets that are browser windows (https://doc.qt.io/qt-6/qtwebengine-overview.html)
I wanted to love webassembly, but each time I've looked into it, it places significant constraints on the application developer in terms of networking, file systems, and many other things that I consider to be table stakes for modern application development. Similar to Web GPU support, it's just another inner platform with a bunch of restrictions that prevent me, as an experienced developer, from using high quality GUI frameworks and all the nice things that OSes have developed over the decades.
I wanted to love webassembly, but each time I've looked into it, it places significant constraints on the application developer in terms of networking, file systems, and many other things that I consider to be table stakes for modern application development. Similar to Web GPU support, it's just another inner platform with a bunch of restrictions that prevent me, as an experienced developer, from using high quality GUI frameworks and all the nice things that OSes have developed over the decades.
But now every app in those VMs needs to ship a TON of custom stuff: text rendering, accessibility, layout, etc.
Frontend has always been a pain for me.
Just switched from React to Vue since it's getting harder to stay with React.
then I was thinking maybe just the old bootstrap(alpine.js,htmx) with SSR approach? it's simpler and more importantly, can be maintained a few years down the road without a revamp(due to frontend breaking changes).
In the end, I still stick to Vue.js, as the SSR approach has its own problems, nothing is ideal.
Also for the money you save by not having a dozen software engineers to maintain the frontend and its dependencies, you can hire a very talented front end designer and give everyone on the engineering team a 100% raise.
you mean no SPA just the old fashion frontend? vue.js still needs developers but simpler than react for sure, less money needed with vuejs down the road
I think he have a good point, you shouldn't be switching frontend tech all the time. Focus on making a good product.
> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.
However I feel like this point isn't entirely correct. According to StateOfJs [1] React have been the most used frontend library for the last 8 years (which I think is how long the survey have been done). React Hooks which is the modern way of writing React components have been around for 7 years (since 2018).
React is definitely going to be around in 5 years, and most likely still going to be the most used frontend library. I also don't think Vue is going away in the next 5 years (Angular might however, they are loosing usage numbers year after year).
So really I think there is an argument to be made that you should just use React and move on.
[1] https://2024.stateofjs.com/en-US/libraries/front-end-framewo...
> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.
However I feel like this point isn't entirely correct. According to StateOfJs [1] React have been the most used frontend library for the last 8 years (which I think is how long the survey have been done). React Hooks which is the modern way of writing React components have been around for 7 years (since 2018).
React is definitely going to be around in 5 years, and most likely still going to be the most used frontend library. I also don't think Vue is going away in the next 5 years (Angular might however, they are loosing usage numbers year after year).
So really I think there is an argument to be made that you should just use React and move on.
[1] https://2024.stateofjs.com/en-US/libraries/front-end-framewo...
Funny story.
I started a new job in 2017 rewriting a rather large website with tons of functionality. The old one had to be replaced because it wasn't maintained and started to become a security issue.
I started doing JS and React/Redux for that job, and just as I was getting the hang of it React broke all my knowledge by coming up with "the modern way of writing React components", hooks. In my opinion there was absolutely nothing wrong with the old way of writing components. I never rewrote my now more than year old project, kept using the normal way of writing React components, which was still allowed. Two years later the depreciation messages started flashing by in the build process, and I was looking at a moutain of work having to refactor the complete front end.
Luckily I was able to move on to other things. But React always left the taste in my mouth of "don't, it auto-breaks after time".
I recently visited this old employer, and they have now hired a new coder to rebuild the old website, which is becoming a security issue.
I started a new job in 2017 rewriting a rather large website with tons of functionality. The old one had to be replaced because it wasn't maintained and started to become a security issue.
I started doing JS and React/Redux for that job, and just as I was getting the hang of it React broke all my knowledge by coming up with "the modern way of writing React components", hooks. In my opinion there was absolutely nothing wrong with the old way of writing components. I never rewrote my now more than year old project, kept using the normal way of writing React components, which was still allowed. Two years later the depreciation messages started flashing by in the build process, and I was looking at a moutain of work having to refactor the complete front end.
Luckily I was able to move on to other things. But React always left the taste in my mouth of "don't, it auto-breaks after time".
I recently visited this old employer, and they have now hired a new coder to rebuild the old website, which is becoming a security issue.
> New developers are having an extremely hard time learning enough skills to be gainfully employed. They are drowning in this complex garbage and feeling really disheartened.
> We need to relearn what the web is capable of and go back to that.
> And it [the web] has only gotten better over time while retaining an incredible level of backwards compatibility.
I would suggest that "retaining an incredible level of backwards compatibility" might be one of the sources of this "complex garbage" the web world is drowning in.
The fact that so many people feel the need to reach for a framework makes me wonder if the web doesn't do nearly as much as it needs to do. Maybe the web will always just be too big, too slow to change, and too bad at pruning out all of the bad ideas that accumulated over the years.
"But what about backwards compatibility? Don't we want all the old web apps to continue to work forever?" Yes, so ship the renderer with the app.
Sure, the current web is probably beyond being able to this, but I'm sure we'll eventually find a far better way to distribute software than the web, a way that makes fewer assumptions about the environment our code will run in.
> We need to relearn what the web is capable of and go back to that.
> And it [the web] has only gotten better over time while retaining an incredible level of backwards compatibility.
I would suggest that "retaining an incredible level of backwards compatibility" might be one of the sources of this "complex garbage" the web world is drowning in.
The fact that so many people feel the need to reach for a framework makes me wonder if the web doesn't do nearly as much as it needs to do. Maybe the web will always just be too big, too slow to change, and too bad at pruning out all of the bad ideas that accumulated over the years.
"But what about backwards compatibility? Don't we want all the old web apps to continue to work forever?" Yes, so ship the renderer with the app.
Sure, the current web is probably beyond being able to this, but I'm sure we'll eventually find a far better way to distribute software than the web, a way that makes fewer assumptions about the environment our code will run in.
Make no mistake, the engineers who come in and want to immediately change to another framework, that is purely by design and an organizational play. The goal is to have the team switch to an unfamiliar framework, but one you know well, so you can divide and conquer the team's productivity. It's a great promotion strategy when you're a newcomer with high productivity while the rest of the team is struggling.
If you're in the java world, I feel that Vaadin the "java-only" frontend framework is heavily underused. Yes, http sessions, but no it's not a big deal unless you're scaling beyond 10k+ users and even then so. It's been around for 20+ years, with paying commercial features if needed and they seem to have survived from JSF all the way through the latest version of sveractular.
I think it’s reasonable for the author to feel like Frontend is a treadmill. It can at times without a doubt be tiring. It certainly was moving much, much faster in the 2010s (although, I think it started to cool down in the 2020s)
I don’t think this specific problem targeted at Frontend or Frontend frameworks is necessarily useful other than to vent. It seems this can be attributed as an effect of swelling technology communities. Frontend has been a community with explosions of ideas, high levels of participation and enthusiasm coupled with opportunities for notoriety and wealth.
One could argue that AI is currently experiencing a similar phenomenon as Frontend did in the 2010s. If it follows a similar trajectory, we’ll be seeing articles about AI treadmills.
I don’t think this specific problem targeted at Frontend or Frontend frameworks is necessarily useful other than to vent. It seems this can be attributed as an effect of swelling technology communities. Frontend has been a community with explosions of ideas, high levels of participation and enthusiasm coupled with opportunities for notoriety and wealth.
One could argue that AI is currently experiencing a similar phenomenon as Frontend did in the 2010s. If it follows a similar trajectory, we’ll be seeing articles about AI treadmills.
I've seen this so many times already, going from server-rendered web apps to client-side rendered web apps in React, then through multiple generations of state management and component management strategies in React, then back to server-side rendered stuff with Next.js, it is so tiring.
I wrote https://blog.julik.nl/2024/03/those-people-who-say-no in response to that Mastodon thread back when it was posted. I fully agree with the article. The problem, I believe, is that "getting off the treadmill" is incredibly hard if you have no authority to push for "getting off the treadmill", and when you get labeled as a problem when you suggest the "getting off the treadmill".
I do believe that with the end of ZIRP delivering more with smaller teams and being forced to make more pragmatic choices will be a net positive with this.
I do believe that with the end of ZIRP delivering more with smaller teams and being forced to make more pragmatic choices will be a net positive with this.
For any backend engineers that don’t build products because dealing with frontend is demoralizing… give the replit ai agent a test. I’m making better ui now than I ever could with bootstrap and jquery. Typescript + react + the right amount of prompting about code quality and maintainability and it produced workable interfaces plus some.
I have given this a lot of thought, and I haven't been able to come up with any reasonable long-term solution that avoids major refactors or swapping out libraries and tools. I am leaning toward pairing React with React Router for creating server-side rendered web apps. My thinking is that React has "won" the JavaScript wars, maintaining its popularity consistently over the past decade, and React Router is one of the most downloaded libraries for React. (At this point, I’ve come to terms with the fact that React Router will likely introduce breaking changes in its next major update, as it has done many times in the past.)
So I mostly agree with you, but I think there's some real dissatisfaction with React and Remix/React-Router's emphasis on SSR. If you don't care about SEO, there's really not that much SSR gives you that CSR doesn't. React and Remix seem to have gone all-in on SSR, and I just don't quite understand why.
Yeah, I like have an express or python backend that just is the api. I know I can test and validate what comes out easily, and control auth from there.
The backend is the real app, and the frontend is the ui peice.
With a solid backend, you can yank out the FE and replace it, or have it power some other apps easily. You can identify issues, and not have to traverse much code to get to them.
Your browser network tools will quickly help you identify if your problem is on the backend or the frontend regarding data.
SSR, well it is like going back to PHP days. The problem could be anywhere in the codebase.
If SEO is important, then yeah, it becomes an issue, but in that case I think periodic caching of client side rendered code to make it so that it shows that to the crawlers works best.
The backend is the real app, and the frontend is the ui peice.
With a solid backend, you can yank out the FE and replace it, or have it power some other apps easily. You can identify issues, and not have to traverse much code to get to them.
Your browser network tools will quickly help you identify if your problem is on the backend or the frontend regarding data.
SSR, well it is like going back to PHP days. The problem could be anywhere in the codebase.
If SEO is important, then yeah, it becomes an issue, but in that case I think periodic caching of client side rendered code to make it so that it shows that to the crawlers works best.
It’s kind of wild that local storage is still the go-to in most places. Just a single big string, and the only way to handle complex data is by endlessly serializing and parsing one massive JSON object.
That's a technical problem, most frontend developers (or backend monkeypatching FE code) are not capable of using IndexedDB.
I love using ai tooling to make frontend engineering trivial. Needs only a minor patch or two but that's enough for me as a dumbass backend/data/distributed systems/site reliability engineer
A big part of the treadmill is that frontends are seen as interchangeable low level investments steered by sales. Short term superficial requirement drive development often by an external team. Funding for sustaining them is scarce. So after a few years - the original team disbanded except maybe a small fraction and when the list of must have changes become too painful a new team is assembled and with it comes a need to differentiate itself from the legacy and assert control of architecture and purse.
Is the frontend treadmill responsible for making browsers so expensive to maintain?
Sorry for the incredibly naive question. I've only ever worked on "backend" projects. A few times I've made simple read-only pages in raw html (and maybe some CSS) to share information with colleagues. So while I get that the web is more awesome now than it was 10 years ago, I don't have any concrete understanding as to why this is a multi-billion dollar industry.
Sorry for the incredibly naive question. I've only ever worked on "backend" projects. A few times I've made simple read-only pages in raw html (and maybe some CSS) to share information with colleagues. So while I get that the web is more awesome now than it was 10 years ago, I don't have any concrete understanding as to why this is a multi-billion dollar industry.
It is kind of gaslighting to say that frontend frameworks don't last more than 5 years when React has been around and popular for more than 10 years and the vast majority of FE jobs today are React.
When I read comments suggesting that frameworks keep changing, it sounds like the kinds of articles which were written 7 to 10 years ago. It made sense to say that back then, the top frameworks DID keep changing. Nowadays it just sounds very strange... It's like complaining about something which is no longer a reality... But which actually turned out to have been a good thing all along.
I actually liked that different companies used different frameworks. It mirrored the reality that no framework is inherently superior to every other framework for every use case. I hate the pretense that React is the silver bullet while simultaneously pretending that it's an underdog struggling for relevance in a world of relentless framework-churn...
When I read comments suggesting that frameworks keep changing, it sounds like the kinds of articles which were written 7 to 10 years ago. It made sense to say that back then, the top frameworks DID keep changing. Nowadays it just sounds very strange... It's like complaining about something which is no longer a reality... But which actually turned out to have been a good thing all along.
I actually liked that different companies used different frameworks. It mirrored the reality that no framework is inherently superior to every other framework for every use case. I hate the pretense that React is the silver bullet while simultaneously pretending that it's an underdog struggling for relevance in a world of relentless framework-churn...
> If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by trying to convince them to switch from framework X to your framework of choice. It’s really annoying and tremendously costly.
We try to screen for this mentality pretty thoroughly in interviews.
Few things are more tiresome than having a product that has been around for years, and that has lots of users, tech debt, edge cases, and business considerations baked into it and having to explain to someone who's been with the company for 2 months that no we probably shouldn't throw out the entire React app and rewrite it in Svelte. An few things are more aggravating than someone who has that idea shot down multiple times and keeps. bringing. it. up.
Any indication in our interview process that you are a language or framework zealot will make it a lot harder for you to move to the next round.
We try to screen for this mentality pretty thoroughly in interviews.
Few things are more tiresome than having a product that has been around for years, and that has lots of users, tech debt, edge cases, and business considerations baked into it and having to explain to someone who's been with the company for 2 months that no we probably shouldn't throw out the entire React app and rewrite it in Svelte. An few things are more aggravating than someone who has that idea shot down multiple times and keeps. bringing. it. up.
Any indication in our interview process that you are a language or framework zealot will make it a lot harder for you to move to the next round.
We have a jquery/Razor front-end that has a ton of global JS state manipulation and a file called 'common.js' which is a dumping ground for almost any function used in two places regardless of what it does. Many things are reinvented wheels (badly) and the previous team left a ton of XSS vulnerabilities in on top of that. Language differences from the previous offshore team mean things are named strangely to me, but even then, there's sometimes bad names for variables and functions.
Does it still function? Sort of. But most of our bugs are front-end issues because it's difficult to reason about any of the control flow. It isn't just obsolete or an unpopular framework, it's bad code.
There's no way I'm going to stay quiet about rewriting something like that if I want to stay at the company (spoiler: I'm quiet about it) and I don't think anyone else should be quiet about it either. This shit causes stress.
Does it still function? Sort of. But most of our bugs are front-end issues because it's difficult to reason about any of the control flow. It isn't just obsolete or an unpopular framework, it's bad code.
There's no way I'm going to stay quiet about rewriting something like that if I want to stay at the company (spoiler: I'm quiet about it) and I don't think anyone else should be quiet about it either. This shit causes stress.
Use “survivor” frameworks, things that last a decade will likely last another. Tailwind, React, Vue, PHP/Laravel, Rails etc. are all very much alive and kicking.
Plus there is nothing wrong with using outdated front end framework other than being unfashionable.
The web is the most backwards compatible platform ever invented,
Plus there is nothing wrong with using outdated front end framework other than being unfashionable.
The web is the most backwards compatible platform ever invented,
LLMs are a huge win in that regard.
I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc.
Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can
I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc.
Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can
My experience is very very different. LLM code is often useless for Frontend stuff for me while it's okay for things like Java and Rust etc.
For frontend stuff the churn seems to be so big that I almost never get valid code because the LLM only know about some old versions or combinations of versions. The "statistical average" they learned is seldom correct for me.
I wonder what we do differently.
For frontend stuff the churn seems to be so big that I almost never get valid code because the LLM only know about some old versions or combinations of versions. The "statistical average" they learned is seldom correct for me.
I wonder what we do differently.
I have a semi-technical friend who's built a whole SaaS with paying customers (currently $x,xxx/mo) using nothing but AI and an occasional bit of hand tuning.
He has some knowledge of the space and technical terminology from managing devs and projects, but was never a developer or engineer himself.
I watched his approach once and it's totally different from mine when I tried AI. He tells the AI what to do and if there's an error, he copy+pastes the error from the dev tools and says "fix this". And he'll keep cycling.
When this happens to me, I think too much about the error and perhaps I'm too specific to the AI on how to fix it. He just lets the AI do it over and over until it gets it right.
He doesn't care how the code looks, what libraries are used, etc.; the only thing that he cares about is "when I click this, does the right thing happen". It's actually kind of insane what he's built solo over a period of 4 months or so.
He has some knowledge of the space and technical terminology from managing devs and projects, but was never a developer or engineer himself.
I watched his approach once and it's totally different from mine when I tried AI. He tells the AI what to do and if there's an error, he copy+pastes the error from the dev tools and says "fix this". And he'll keep cycling.
When this happens to me, I think too much about the error and perhaps I'm too specific to the AI on how to fix it. He just lets the AI do it over and over until it gets it right.
He doesn't care how the code looks, what libraries are used, etc.; the only thing that he cares about is "when I click this, does the right thing happen". It's actually kind of insane what he's built solo over a period of 4 months or so.
“I just fuck around til it works”
> People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away.
This might be the solution in many cases. For small projects vanilla js is quite pleasant to use.
For bigger projects React helps structure things for sure. I am for "vanilla react", or prop drilling, hooks and context. No state libraries or fancy shit.
This might be the solution in many cases. For small projects vanilla js is quite pleasant to use.
For bigger projects React helps structure things for sure. I am for "vanilla react", or prop drilling, hooks and context. No state libraries or fancy shit.
I sometime hire web developers to do frontend for my clients. 90% of the time when I talk to them all I can hear is - can we use / rewrite with X/Y/Z/etc framework. Needless to say that I tell them to take a hike right away. I usually ask how would you implement this and that workflow using plain JS (using some specific libs is ok).
Someone knows some good framework or anything which I could embedd Haskell code in HTML to use in Canvas to see results immediately. I am just started learning Haskell. Someones have some exp.how to use LLMs for speed-up learning of coding in new language with new paradigm?:) Thx!
React 16.8 (the one with hooks) has been stable for almost 6 years and newer React versions are mostly backwards compatible. The real problem are bundler / build tools. Using something like esbuild + tsc goes a really long way and will never get deprecated. If you know the craft enough, you can ignore everything else (save eslint, probably).
I was once hopeful that WASM would bring some sanity to browser but...I don't know any more. That was also when I thought (assumed) WASM would get the ability to manipulate the DOM directly but it seems like that's not what the browser overlords want to happen. Having a dependency on javascript doesn't change much IMO.
Out of curiosity I've just fired up an old dynamic Perl website of mine. Works! 20 years later. On my modern machine!
Hi, are there any good frameworks which I could use embedding Haskell code in HTML to see results during code changing in Canvas. Someone use LLMs to speed-up programming language? Especially FP. Arebthere some good structured methods for this? Thx.!
[deleted]
>> The frontend ecosystem is kind of broken right now.
Everyone claims it's broken, then builds a new framework.
Everyone claims it's broken, then builds a new framework.
This really strikes cord with me.
I chose early on in my carrier not to use frontend frameworks, precisely because of the added abstraction and inherent complexity they tend to bring to your codebase. Its been tough and limited my prospects significantly as a junior dev. But these days, I'm happy that I chose to steer clear of frameworks. As it really does give you a much more broad understanding of how the web platform works.
Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.
Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.
Love a pro-Web Platform post
Really every single point made is well taken, even the if-you-gotta-use-a-JS-framework one(s)
Really every single point made is well taken, even the if-you-gotta-use-a-JS-framework one(s)
> Whatever framework you choose will be obsolete in 5 years.
Reagent was born in 2013 and still works just the same in 2025. And it adapted to React changes quite nicely. You won't have to refactor Reagent code from 10 years ago.
Technology and programming language choice matters.
Reagent was born in 2013 and still works just the same in 2025. And it adapted to React changes quite nicely. You won't have to refactor Reagent code from 10 years ago.
Technology and programming language choice matters.
The frontend space will surely change to accomodate AI.
We may go back to pre-framework days if we don't need that much complexity anymore. If we start to rely on AI Summaries we won't need complex interactions. Just beautiful charts to explain data.
We may go back to pre-framework days if we don't need that much complexity anymore. If we start to rely on AI Summaries we won't need complex interactions. Just beautiful charts to explain data.
IMHO, the root cause is HTML was/is not designed for building user interfaces. It's amazing what people have accomplished with HTML but, damn, so much work compared to using an actual UI toolkit.
A wise man once wrote, "There is nothing new under the sun" (King Solomon, ~2500 years ago), but the frontend cult refuses to accept that. They reinvent the wheel multiple times a year, failing to realize they are going in circles. Every so-called "new" thing falls victim to the Pareto principle — it solves only 80% of the problems introduced by the last shiny thing, meaning progress is merely asymptotic.
They also seem oblivious to the short history of programming. In general, there are three main branches: imperative, functional, and logic programming — with the latter two being built on imperative foundations. Yet the frontend cult acts as if they're groundbreaking by introducing pattern matching via discriminated unions in TypeScript, a concept that has existed in functional and logic programming for over 50 years.
In other words, they behave like brats.
They also seem oblivious to the short history of programming. In general, there are three main branches: imperative, functional, and logic programming — with the latter two being built on imperative foundations. Yet the frontend cult acts as if they're groundbreaking by introducing pattern matching via discriminated unions in TypeScript, a concept that has existed in functional and logic programming for over 50 years.
In other words, they behave like brats.
When I started coding, 20 years ago, the frontend was HTML+CSS+JS.
Now, it is still HTML+CSS+JS.
The most used backend was perl/Java/C/C++, which is not the case anymore.
So which one changed more, frontend or backend?
So which one changed more, frontend or backend?
[deleted]
[deleted]
As a developer just starting to get into frontend, I'm wondering how learning core-web technologies has helped frontend developers vs just going all-in on on something like React.
As someone with 15+ years of experience, a lot of that FE specific, that is the advice I always give newer devs if asked. Learn the fundamentals of Javascript, HTML, CSS (it's like a 3 legged stool, even if the JS leg is oversized in the days of web apps). If you know how to program, and you know the fundamentals, you can work in whatever framework is thrown your way.
Now, practically speaking, that's actually probably better advice for someone with a job and 1-2 years in. To get an initial foothold in the industry, people often need to specialize in one specific thing (React at the moment most likely), in order to be able to demonstrate enough competence to get that initial job and so I understand how fundamentals can be backburnered initially. But I recommend devs don't let that initial success lock them into that framework - that's the time to get back and learn all the fundamentals, go wide, learn a couple other frameworks even so it's easy to compare and contrast the strengths/weaknesses of each.
And you will want to be well-versed in the framework you currently use day to day, knowing best practices, architecture patterns that work and those to avoid, etc. Knowing the fundamentals will help, but there will be framework specific things that will change from framework to framework, even code-base to code-base sometimes. So it's always going to be a bit of a balance. But long-term, IMO, being well-versed in the fundamentals affords you the most flexibility and employ-ability long-term.
Now, practically speaking, that's actually probably better advice for someone with a job and 1-2 years in. To get an initial foothold in the industry, people often need to specialize in one specific thing (React at the moment most likely), in order to be able to demonstrate enough competence to get that initial job and so I understand how fundamentals can be backburnered initially. But I recommend devs don't let that initial success lock them into that framework - that's the time to get back and learn all the fundamentals, go wide, learn a couple other frameworks even so it's easy to compare and contrast the strengths/weaknesses of each.
And you will want to be well-versed in the framework you currently use day to day, knowing best practices, architecture patterns that work and those to avoid, etc. Knowing the fundamentals will help, but there will be framework specific things that will change from framework to framework, even code-base to code-base sometimes. So it's always going to be a bit of a balance. But long-term, IMO, being well-versed in the fundamentals affords you the most flexibility and employ-ability long-term.
I don't disagree with the point being made but it should also be noted that React and Vue are both 11 years old.
Hell, even Meteor.js (anyone remember this one?) is still around and being updated.
Hell, even Meteor.js (anyone remember this one?) is still around and being updated.
Even Svelte is going to be 10 years old in about a year.
This is covered in the article. They change so much they may as well be new. There are tons of apps out there that have a mix of React class and functional components, for example. And didn't Svelte just make a huge fundamental change to its api?
Good luck with a Vue 2 + vuex + Vue Router project scaffolded with Vue CLI in 2016 which NPM is screaming at you is full of vulnerabilities. Or that React + React Router + Redux + Webpack 3 project from 2015.
In both cases you'd need to spend serious time moving to newer deps, rearchitecturing, probably moving to Vite, etc.
In both cases you'd need to spend serious time moving to newer deps, rearchitecturing, probably moving to Vite, etc.
Sounds absolutely brutal for sure. I didn't mean to sound like everything was fine in JavaScript land, they have been chasing the shiny new thing and focusing too much on the wrong abstractions for a while. Even backend frameworks aren't free from this same problem, when you look at the support and migration woes in big players like rails/laravel/django. I suppose thats less frequent though.
I'm not sure how you avoid it in any framework without rawdogging pure HATEOAS and vanilla concepts. Recently I've gravitated towards Django and HTMX and its felt quite refreshing.
Keeping your tech stack up to date inevitably brings some pain and suffering along. I do wish more frontend frameworks cared about backwards compatibility.
The web dev influencers really push the latest and greatest memes. One day they are putting out a video of how Firefox is the worst browser in the world because it doesn't support some niche variety of CSS gradient and the next they are gushing over something like Zen (a Firefox fork).
I'm not sure how you avoid it in any framework without rawdogging pure HATEOAS and vanilla concepts. Recently I've gravitated towards Django and HTMX and its felt quite refreshing.
Keeping your tech stack up to date inevitably brings some pain and suffering along. I do wish more frontend frameworks cared about backwards compatibility.
The web dev influencers really push the latest and greatest memes. One day they are putting out a video of how Firefox is the worst browser in the world because it doesn't support some niche variety of CSS gradient and the next they are gushing over something like Zen (a Firefox fork).
I agree. I don't know what the solution is either. I've been asking myself this question for some years now.
Last year, after 10 or so years using Node, I concluded that JS in the backend was a mistake and I had mostly wasted those years. I'm currently migrating towards another stack.
It's more difficult for the frontend. Inevitably you end up needing JS unless the project works as static HTML with close to no interactivity. I still haven't properly tested HTML over wire solutions though.
Last year, after 10 or so years using Node, I concluded that JS in the backend was a mistake and I had mostly wasted those years. I'm currently migrating towards another stack.
It's more difficult for the frontend. Inevitably you end up needing JS unless the project works as static HTML with close to no interactivity. I still haven't properly tested HTML over wire solutions though.
> Whatever framework you choose will be obsolete in 5 years.
I must be living in a different reality, because most of the frameworks 5 years ago are still being (actively) used.
I must be living in a different reality, because most of the frameworks 5 years ago are still being (actively) used.
> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.
Frontend guys crack me up. The browser is an extremely advanced environment and ES6 is an extremely powerful language. You don't need a framework. You haven't for 10 years now, which is probably why they're so easy to replace, they're wrappers of very thin technology and very thick opinions.
The only reason to use one is if you want to share code between the web and a native app, otherwise, it's a complete and total waste of your engineering efforts.
Frontend guys crack me up. The browser is an extremely advanced environment and ES6 is an extremely powerful language. You don't need a framework. You haven't for 10 years now, which is probably why they're so easy to replace, they're wrappers of very thin technology and very thick opinions.
The only reason to use one is if you want to share code between the web and a native app, otherwise, it's a complete and total waste of your engineering efforts.
I've been writing UX code professionally since the late 90's and for many years, I have led teams that build relatively complex UX software products at companies you've surely heard of.
It took me about about 5 years before I began to realize no one I had met, had any idea how to do this work in a way that wasn't horrible.
I held out hope, and thought maybe those other super-smarty-pants folks over there had it all figured out.
It took another 10 years to figure out that they most definitely did not have anything figured out at all. Functional weanies, OO nerds, Imperative Prima donnas. No one. Has GUI figured out. Not Apple, Not MS, Not Linux. No One.
I've worked professionally in every language, every framework, every paradigm. I've tried it all.
Writing Graphical User Interfaces is HARD.
The problem is that the problem is HARD.
Graphical User Interfaces (for anything reasonably sophisticated) represent broad and deep, hierarchical, tree-like (or graph-like) projections of large amounts of domain information PLUS some amount of administrative debris.
Changing any state of any node in these large and complex data structures can and often should cause some other node in some faraway sub-branch to instantaneously be updated.
Sometimes, that node is on someone else's computer. Almost always, there's a replicated, similar, but different version of that information on a server somewhere that really must be kept in sync.
The problem is made exponentially more complex when we just drop in some little multi-user, real-time update stories.
This thread is a great example of people shitting on the whole field, and yet... Not one person has figured out how to make front-end development not suck.
The problem appears to be deceptively simple on the surface, and like those sirens, it calls out to weary sailors, only to leave them shipwrecked on the shore.
Funny enough, it turns out that Text-based User Interfaces (TUI's) are far more expressive and exponentially easier to author and maintain.
They just have the little, teeny problem of being a sheer cliff face that users must ascend in order to get anything useful at all.
It's my bet, that the world will be saved by some mixture of Text and Graphical UX that is primarily rooted in Text, but enhanced by graphics, rather than the other way around.
This whole LLM thing looks kind of interesting on that front.
I suspect we'll all look back on the last 30 years with contempt and remorse at all the wasted time and energy we've put into this mess that we've created that is called, "Graphical Applications."
Feel free to rant on about how shitty everything is, but just remember that at least one person out here in the ether knows that your solution either doesn't exist (most likely) or is even worse.
It took me about about 5 years before I began to realize no one I had met, had any idea how to do this work in a way that wasn't horrible.
I held out hope, and thought maybe those other super-smarty-pants folks over there had it all figured out.
It took another 10 years to figure out that they most definitely did not have anything figured out at all. Functional weanies, OO nerds, Imperative Prima donnas. No one. Has GUI figured out. Not Apple, Not MS, Not Linux. No One.
I've worked professionally in every language, every framework, every paradigm. I've tried it all.
Writing Graphical User Interfaces is HARD.
The problem is that the problem is HARD.
Graphical User Interfaces (for anything reasonably sophisticated) represent broad and deep, hierarchical, tree-like (or graph-like) projections of large amounts of domain information PLUS some amount of administrative debris.
Changing any state of any node in these large and complex data structures can and often should cause some other node in some faraway sub-branch to instantaneously be updated.
Sometimes, that node is on someone else's computer. Almost always, there's a replicated, similar, but different version of that information on a server somewhere that really must be kept in sync.
The problem is made exponentially more complex when we just drop in some little multi-user, real-time update stories.
This thread is a great example of people shitting on the whole field, and yet... Not one person has figured out how to make front-end development not suck.
The problem appears to be deceptively simple on the surface, and like those sirens, it calls out to weary sailors, only to leave them shipwrecked on the shore.
Funny enough, it turns out that Text-based User Interfaces (TUI's) are far more expressive and exponentially easier to author and maintain.
They just have the little, teeny problem of being a sheer cliff face that users must ascend in order to get anything useful at all.
It's my bet, that the world will be saved by some mixture of Text and Graphical UX that is primarily rooted in Text, but enhanced by graphics, rather than the other way around.
This whole LLM thing looks kind of interesting on that front.
I suspect we'll all look back on the last 30 years with contempt and remorse at all the wasted time and energy we've put into this mess that we've created that is called, "Graphical Applications."
Feel free to rant on about how shitty everything is, but just remember that at least one person out here in the ether knows that your solution either doesn't exist (most likely) or is even worse.
I agree with your sentiment.
I'm a designer but 80% of the time I implement user interfaces. I have to say that the worst user interface code comes from traditionally educated computer science people... it's almost always a huge pile of shit with layer upon layer of useless abstraction.
I think you're right... no one has it figured out, it's all a mess.
I'm a designer but 80% of the time I implement user interfaces. I have to say that the worst user interface code comes from traditionally educated computer science people... it's almost always a huge pile of shit with layer upon layer of useless abstraction.
I think you're right... no one has it figured out, it's all a mess.
> But our current framework layer is working against the grain instead of embracing the platform.
Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run:
Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run:
<style>body{visibility:hidden;opacity:0}</style>
That comes from the theme they’re using, and there’s a noscript directive immediately after it.
https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...
https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...
Which is now deprecated and no longer receiving updates! Haha, that’s hilarious in context of the post.
It’s also maddeningly frustrating as someone who regularly has to update things on awful frontend projects no one else is willing to touch. Frontend work is cursed.
It’s also maddeningly frustrating as someone who regularly has to update things on awful frontend projects no one else is willing to touch. Frontend work is cursed.
If they weren't in that morass they'd be writing about how happy they are with Common Lisp or Pony or something.
Doesn't make it any less stupid or hypocritical. Dependencies you made a choice to use don't absolve you from responsibility.
Actually, it doesn't matter at all.
I think of the strange case of react-router which has been through 7 versions, many of which were complete breaking rewrites. It's hard not to come to the conclusion that since they kept rewriting it, they didn't believe in any of them. Lately they made big changes because they want to support SSR but I couldn't give a flying F because we're not using SSR any more than I care about React Native support because we're not using React Native! [1]
I've worked on a lot of code where people tried to use react-router and eventually gave up and have some code where they parse the URL directly and it works just fine. The trouble with react-router is that if you understand it enough to use it, you don't need it that is, you can either write some stupid URL parsing code or you can write some hooks that do 100% of what you want (as opposed to 90% of what you want with their code) with about 25% of the code.
For them it's a tiny amount of code that they understand completely and they have no problem tearing it up and rewriting it all because there is very little to it and it doesn't really do very much. [2] For you you either don't understand it in which case you feel like a hostage to their whims or you do understand it in which case you don't need it.
I am looking at a React 16 app which uses a huge number of third-party components that I badly want to take up to React 17 because of testing. With React 16 the tests can't ever really know that React is done running callbacks which makes them brittle and slow which is a bad enough situation that I don't want to write any more tests. React could have done something about it before because React knows if it has callbacks left to run but they didn't until React 17.
My understanding is that, most likely, all the components I have will work just fine with React 17 or 18 for that matter because the 16 -> 17 and 17 -> 18 transitions caused very little breakage. Their package.json files disagree so I can't just bump to React 17, but rather I have to update all the dependencies to newer version and many of them, like react-router, have a cavalier attitude about compatibility so I'd expect to spend a month at least dealing with all the breaking changes in the dependencies. It's times like this when I wish I could stick an axiom into my package.json that says "Version A of package B is really compatible with React 18" or just fork version A of package B to version A' which has a patched package.json. After all that it is certain that there will be invisible changes in the HTML which will cause us to fail an accessibility audit six months later requiring another month of work to track down.
[1] Sure, somebody else is, but I have enough problems to worry about with the modern web and patching up applications written by interns that I don't need the burden of navigating through the docs over and over and over again having to ignore 80% of the content which is completely irrelevant to me. Never mind that older versions of RR, at the very least, support obsolete methods of navigation which is another thing you don't need filling your headspace.
[2] So little code that it probably takes up more of their headspace to go to a conference and boast about what they did than it did to actually do it!
I've worked on a lot of code where people tried to use react-router and eventually gave up and have some code where they parse the URL directly and it works just fine. The trouble with react-router is that if you understand it enough to use it, you don't need it that is, you can either write some stupid URL parsing code or you can write some hooks that do 100% of what you want (as opposed to 90% of what you want with their code) with about 25% of the code.
For them it's a tiny amount of code that they understand completely and they have no problem tearing it up and rewriting it all because there is very little to it and it doesn't really do very much. [2] For you you either don't understand it in which case you feel like a hostage to their whims or you do understand it in which case you don't need it.
I am looking at a React 16 app which uses a huge number of third-party components that I badly want to take up to React 17 because of testing. With React 16 the tests can't ever really know that React is done running callbacks which makes them brittle and slow which is a bad enough situation that I don't want to write any more tests. React could have done something about it before because React knows if it has callbacks left to run but they didn't until React 17.
My understanding is that, most likely, all the components I have will work just fine with React 17 or 18 for that matter because the 16 -> 17 and 17 -> 18 transitions caused very little breakage. Their package.json files disagree so I can't just bump to React 17, but rather I have to update all the dependencies to newer version and many of them, like react-router, have a cavalier attitude about compatibility so I'd expect to spend a month at least dealing with all the breaking changes in the dependencies. It's times like this when I wish I could stick an axiom into my package.json that says "Version A of package B is really compatible with React 18" or just fork version A of package B to version A' which has a patched package.json. After all that it is certain that there will be invisible changes in the HTML which will cause us to fail an accessibility audit six months later requiring another month of work to track down.
[1] Sure, somebody else is, but I have enough problems to worry about with the modern web and patching up applications written by interns that I don't need the burden of navigating through the docs over and over and over again having to ignore 80% of the content which is completely irrelevant to me. Never mind that older versions of RR, at the very least, support obsolete methods of navigation which is another thing you don't need filling your headspace.
[2] So little code that it probably takes up more of their headspace to go to a conference and boast about what they did than it did to actually do it!
The only explanation I have for the React Router team's behavior is that it's a funnel for their consultancy gig. I've never seen another project so developer-hostile in my life.
I'm afraid you've thought more about react-router than the maintainers about the people using it.
I feel like the tradeoff has historically been between smaller, more composable libraries with more breaking changes and larger, more feature-filled libraries that move more slowly and care about their users.
react-router is the epitome of choosing the worst of both worlds with a healthy dose of disdain for their users.
I feel like the tradeoff has historically been between smaller, more composable libraries with more breaking changes and larger, more feature-filled libraries that move more slowly and care about their users.
react-router is the epitome of choosing the worst of both worlds with a healthy dose of disdain for their users.
> Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply.
I've been working on a SaaS product for a couple of years and when I first started I picked up MUI as my FE framework. Since then on at least 5 different occasions I looked into replacing it and have always landed back on "no lets keep it".
MUI is far from a perfect FE framework but for me I realized it worked really well because it helped me create pretty professional looking UI's without any designer assistance. And over the years I've learned many of the quirks around the framework and have implemented various tooling to mitigate any shortcomings.
I'm still looking for an eventual replacement though, for a while I thought I was going to jump on Google's official material design spec but then they stopped working on the web version. At this point I'm probably going to gradually adopt TailwindCSS (probably over the course of a year or more) and eventually move my FE to an entirely custom build solution.
But even thinking about this change I still come back to "what's the point?". Customers like my product and use it ever day, MUI has it's shortcomings but it's not something terrible I need to jump ship from. I'm sure I will eventually replace MUI but so far it's been chugging along just fine.
I've been working on a SaaS product for a couple of years and when I first started I picked up MUI as my FE framework. Since then on at least 5 different occasions I looked into replacing it and have always landed back on "no lets keep it".
MUI is far from a perfect FE framework but for me I realized it worked really well because it helped me create pretty professional looking UI's without any designer assistance. And over the years I've learned many of the quirks around the framework and have implemented various tooling to mitigate any shortcomings.
I'm still looking for an eventual replacement though, for a while I thought I was going to jump on Google's official material design spec but then they stopped working on the web version. At this point I'm probably going to gradually adopt TailwindCSS (probably over the course of a year or more) and eventually move my FE to an entirely custom build solution.
But even thinking about this change I still come back to "what's the point?". Customers like my product and use it ever day, MUI has it's shortcomings but it's not something terrible I need to jump ship from. I'm sure I will eventually replace MUI but so far it's been chugging along just fine.
It’s really not that hard. Software needs maintenance, big deal. This is why we have a job.
Everyone complaining in this thread about trivial things like upgrading a build tool once every 5 years is hilarious
Everyone complaining in this thread about trivial things like upgrading a build tool once every 5 years is hilarious
I wonder why nobody seems to have designed a front end framework by sitting down and asking themselves how to express things clearly. Every single front end framework seems to have been designed by people just riffing on all the nonsense complexity already in the world. Odd syntax rules, lots of implicit behaviors and side effects, logic spread across at least 5 different domains etc.
Why hasn’t anyone talented designed a front end framework?
And before getting angry and downvoting me for this heresy: prove me wrong first.
Why hasn’t anyone talented designed a front end framework?
And before getting angry and downvoting me for this heresy: prove me wrong first.
[deleted]
express.js and vue.js with axios/bulma css, has not changed that much in 10 years
Amen!
fwiw i've added a structured summary of the discussion here: https://extraakt.com/extraakts/frontend-development-churn
Author misses the point.
There are now basically 2 answers:
- go with vanilla html js + some css stuff à la tailwind
- go with react for anything with more dynamic interaction
I am not a huge fan of either, but anything else will be costly either in hiring opportunity or in terms of “shit I can’t use that dependency in my xxx framework”
- go with vanilla html js + some css stuff à la tailwind
- go with react for anything with more dynamic interaction
I am not a huge fan of either, but anything else will be costly either in hiring opportunity or in terms of “shit I can’t use that dependency in my xxx framework”
all i know is that nextjs is the absolute worst
This is exactly why I'm building Joystick [1]. I got tired of the constant indecision and churn in JS frameworks, so I've built (and am actively building) a full-stack solution that features a simple component API that doesn't change, backed up by a batteries-included Node.js backend. All wired together so it's easy to use and fast to build your idea (for real, not just marketing fluff). Purposefully designed for people who are trying to build real businesses, not tinkering around to pad their resume.
The best part? I'm a tyrant about backwards compatibility, stability, and longevity (meaning, even if nobody else uses it, I'll be maintaining this for the long-haul).
For the cynics: for the love of all that's holy, do not send me the XKCD cartoon about standards. I deeply care about solving this problem and this isn't "just another JS framework." It's a replacement for all of the "just do everything on the client" buffoonery and it works incredibly well.
[1] https://github.com/cheatcode/joystick
The best part? I'm a tyrant about backwards compatibility, stability, and longevity (meaning, even if nobody else uses it, I'll be maintaining this for the long-haul).
For the cynics: for the love of all that's holy, do not send me the XKCD cartoon about standards. I deeply care about solving this problem and this isn't "just another JS framework." It's a replacement for all of the "just do everything on the client" buffoonery and it works incredibly well.
[1] https://github.com/cheatcode/joystick
(2024)
Great advice, but my case is different because our framework is REALLY hurting us.
/s
It's wild how easy it is to fall into this trap. IMO, if you're considering switching frameworks (especially for perf reasons), your time would be better served by getting parts of your app off framework completely (assuming there's truly no way to get the results you want in your current framework.)
/s
It's wild how easy it is to fall into this trap. IMO, if you're considering switching frameworks (especially for perf reasons), your time would be better served by getting parts of your app off framework completely (assuming there's truly no way to get the results you want in your current framework.)
As an embedded developer I've long felt the web folks were crazy changing their frameworks all the time. They are not doing anything on the web we haven't done before. Most of the concepts are right out of the mainframe era, and we switched to dumb terminals and PCs for a reason (not always good reasons - there are pros and cons to both approaches)
Which web folks have been changing their frameworks all the time?
If anything, I think a valid criticism of modern/current web development is that it's entirely a React monoculture. I'm happy writing react, and have been at countless companies for the past 10 years.
If anything, I think a valid criticism of modern/current web development is that it's entirely a React monoculture. I'm happy writing react, and have been at countless companies for the past 10 years.
The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally different configuration and doesn’t support all the same options. Okay, so we just keep the old one and disable the node engine check in pnpm that makes it complain. Want to do a patch upgrade to some dependency? Hope you weren’t relying on any of its type signatures! Pin that as well, with a todo in the codebase hoping someone will update the signatures.
Finally get things running, watch the stream of hundreds of deprecation warnings fly by during the install. Eventually it builds, and I get the hell out of there.
It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’ve been working on a large rust project for nearly four years and in that time there have been a few minor breaking changes in or of third party libraries, but only one major breaking change that required significant changes to our application. Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas.
Okay, rant over.