The Frontend Treadmill
polotek.net
polotek.net
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.
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.
I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
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.
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)
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.
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)
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
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.
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?
The fewer things you have in your stack, the fewer things can change under your feet.
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.
> 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...
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
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 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.
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.
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...
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...
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.
"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.
- 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.
The developer velocity enabled by React is insane.
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.
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.
Well gosh darnit, then everyone and their mother is going to come to America
It's an age old envy.
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.
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.
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...
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.
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 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.
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?
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.
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.
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.
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.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
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.
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.
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.
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.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
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.
Last release of IE6: 2008
Concerted campaign to make everybody stop using IE6: 2009
Microsoft joins that campaign: 2011
First release of React: 2013
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 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.
It was definitely frustrating knowing that a better world was possible but not quite there.
"Why do JS people keep doing something new for no apparent reason?"
Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
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 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’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”.
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.
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://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).
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.
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.
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.
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"?
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.
I guess that's fine for you but it's very smarmy IMO.
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.
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.
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.
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…
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.
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.
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.
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.
My problem is having all of them existing at once.
To be fair to both code bases - it's very impressive that they're still running, right?
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 :)
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?
There goes my hero: https://youtu.be/EqWRaAF6_WY
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.
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.
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 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.
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.
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.
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.
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.
Another example of advertising destroying the world.
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.
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 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 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.
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 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.
IMO you don’t need any. The correctness of your conclusion is self-evident. Proof by common sense, QED.
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.
Then if I decide I like it I read the manual.
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 suspect in his case he might actively dumb down his skill level for the stream, so he doesn’t scare away the junior devs.
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.
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.
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.
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.
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.
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.
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.
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.
Edutainment perhaps?
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.
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 all seems like it is for CV glory. Then the projects don't see a commit for years.
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
Dear Developer, the Web Isn't About You
It's why I moved to mainly backend (where feasible).
Because someone has to maintain that crap at some point.
this is one house of cards that may never really be fixed.
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.
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.
For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
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.
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.
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.
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'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.
A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
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.
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.
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.
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.
How do people live like this?
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...>.)
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.
But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
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.
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 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.
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.
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.
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 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 stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume
That's a technical leadership failure first and foremost
I wonder what it’d take to achieve that kind of stability over time in the web front end world…
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.
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.
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.
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.
My theory is that they do it because they don't have enough to do.
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).
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.
Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.
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.
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
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.
(This is a purely theoretical example coming from someone with lots of architectural experience, I didn’t use it before).
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).
- 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
I never mentioned build tools. You can write your own quickly.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.).
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 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.
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.
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.
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.
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 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.
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.
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.
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
It's still small incompatibilities adding up. It's still work.
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.
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'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.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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
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:
Plus, as the other comment noted, the basic JS types go a long way now.
Oh for a version of the WWW that never allowed javascript at all.... money destroys absolutely everything it touches.
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.
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.
In a way, it is exactly the example opposite of what you mention.
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 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.
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.
OR just embed the RDBMS into your application!
https://github.com/rusqlite/rusqlite/blob/master/examples/lo...
If anything, this is arguably one of the more structured ways you could go about attacking the problem of a complex web product.
Plain JS loses much to plain Typescript though, to my mind.
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/
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.
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.
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.
* 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.
Of course it's possible without Vue - but you have to do a lot more work in many cases... so, what's the point?
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.
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.
Hooks or classes?
Or whatever comes next.
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
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...
That's when you buy a book and try to do practice projects, and learn how everything works.
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.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
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.
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
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.
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.
- 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
Hilarious, and accurate.
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.
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.
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.
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.
Conditional types (not statements) are not a basic feature.
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.
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 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.
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?
People arguing with me here don't seem to remember this breaking like 1/2 the JS builds in existence for a few days.
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.
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.
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.
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.
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.
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.
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.
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.
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 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).
Oh sweet summer child, we've been close to the "final state of the web" for as long as I've done web development.
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...
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.
> 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.
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.
I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.
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")
And other than that? Pure HTML.
It’s downright lovely. And it’ll still work fine 20 years from now.
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.
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.
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.
Step 1 - don't grow
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.
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.
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.
bold claim. A Rails project of 20 years would not work fine today without a lot of work.
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.
Or you can properly architecture your application and move the logic layer to a language with better tooling.
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.
It’s kind of analogous to how the entire web became a slave to SEO.
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 know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, 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)
With vanilla, it just takes more effort to build things. A file could easily become 2,000+ LOC.
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.
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.
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.
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/preact@10.26.4/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.
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.
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.
> 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.
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.
What is unsolved is the dependency hell: builds break over time, just by NPM rot.
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?
Btw what made you choose Vue over React?
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.
But Vue is reactive as well? Eg communication between components is not straightforward.
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.
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 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.
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
(and I'm not talking about simple static websites)
WebGPU is new, but WebGL came out in 2011.
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.
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 yes, I think this is a good assessment, and it matches my experience.)
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.
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.
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.
- 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.
(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.)
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.
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).
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.
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.
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.
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.
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?
This hit hard.
I'm not a frontend developer, but I'm always looking forward to writing frontend these days!
IDK our product is older than 5 years and React is still not obsolete.
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.
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.
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.
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.
> 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...
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.
> 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.
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 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.
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.
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.
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...
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.
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.
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,
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
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.
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.
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.
Everyone claims it's broken, then builds a new framework.
Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.
Really every single point made is well taken, even the if-you-gotta-use-a-JS-framework one(s)
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.
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.
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.
So which one changed more, frontend or backend?
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.
Hell, even Meteor.js (anyone remember this one?) is still around and being updated.
In both cases you'd need to spend serious time moving to newer deps, rearchitecturing, probably moving to Vite, etc.
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).
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.
I must be living in a different reality, because most of the frameworks 5 years ago are still being (actively) used.
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.
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'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.
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>
https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...
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.
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 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'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.
Everyone complaining in this thread about trivial things like upgrading a build tool once every 5 years is hilarious
Why hasn’t anyone talented designed a front end framework?
And before getting angry and downvoting me for this heresy: prove me wrong first.
- 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”
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.
/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.)
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.