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.
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.
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.
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 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 like (some) programming videos and I'll give my perspective as someone who learned 100% from books and 3-ring binders for old languages like C/C++/C#/Javascript/Python/bash/etc. (The 1980s Microsoft C Compiler manuals were 3-ring binders.)
The newer languages I learned with a hybrid of videos + traditional books would be HTML CSS, Apple Swift, and PyTorch with the latest AI toolkits and libraries.
The extra dimension that videos offer besides plain text is the live usage of IDE, tools, troubleshooting, etc. For me, watching a dynamic screen with a moving mouse cursor and voiceover seems to activate extra neurons moreso than just reading static text in a book.
There's also a lot of "activities in-between the coding" that's helpful such as seeing the programmer looking up something in various pages of documentation, scrolling around, navigating etc.
Another useful aspect that's underappreciated is seeing the mistakes the programmer makes during the video recording. E.g. the code doesn't compile because of invalid syntax. Or a config setting is wrong and he troubleshoots what's preventing it from working. In contrast, virtually all text books or blogs of coding are "perfect happy path" outcomes. But real-world programming is messy with broken intermediate states. A lot of videos show the messy steps to get to a working state.
The videos that are not that helpful would be the videos of C++ CppCon conference sessions where there are a bunch of static slides with bullet points and the speaker just reads them aloud word-for-word.
Although I learned C++ from textbooks, I found videos of Matt Godbolt showing tips & tricks of how to use his Compiler Explorer (http://godbolt.org) very helpful.
In summary, the artifacts of coding may be the text, but the activity of coding involves a lot more than just the text and that's why some videos can enhance learning.
I've been seeing more and more of a certain kind of person who are into these videos on some Discord servers, and it is clear that they are driven more by culture and style than by the goal of creating some thing, or having a strong understanding of how to make computers do certain things.
That’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.
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.
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.
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://www.hackerneue.com/item?id=39453767
(This entire thread reads like deliberate testimonials.)
Stop buying this stuff.
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…
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.
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.
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.
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.
Then if I decide I like it I read the manual.
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.
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.
It is only natural for a dev to ask themselves "am I still current? am I still relevant?". The induced FOMO triggers the worst bits of that anxiety, and sometimes I feel the influencers do not realise just how harmful this is.
I suspect in his case he might actively dumb down his skill level for the stream, so he doesn’t scare away the junior devs.
It all seems like it is for CV glory. Then the projects don't see a commit for years.
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.
Dear Developer, the Web Isn't About You
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
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.
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.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
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.
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.
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.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
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.
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.
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.
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.
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...
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.
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.
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...
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.
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.
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.
I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.
I 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.
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.
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.
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.
A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
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.
> 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...
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.
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.
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 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.
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.
Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
I think part of the problem is this thinking that
- you must change things all the time (yarn is still good why switch?)
- the things you change to are somehow really new (pnpm is 9 years old)
I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
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
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.
Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search.
X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced.
A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc.
Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features.
I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend.
Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
I 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
"Why do JS people keep doing something new for no apparent reason?"
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.
Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
It's why I moved to mainly backend (where feasible).
Because someone has to maintain that crap at some point.
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.
How do people live like this?
I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.
I wonder what it’d take to achieve that kind of stability over time in the web front end world…
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.
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
My theory is that they do it because they don't have enough to do.
this is one house of cards that may never really be fixed.
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).
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.