I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines.
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.
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc.
I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains.
Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about.
This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic.
There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.
That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions.
That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
> That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.
Me either, but I have a hunch about why.
Are you a fast reader?
I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere close, I have to crank the playback speed up so high that I start having trouble understanding what the presenter is saying. That's on top of other things like poor searchability and no way to copy-paste code snippets.
The decline of reading skills, at least in the US, is pretty well-documented. And my hunch is that for the increasingly large number of people coming into the industry who don't read quickly or well, the efficiency of learning from videos is closer to parity with text. What's more, I suspect there's high correlation between lower reading skills and dislike of the act of reading, so videos are a way to avoid having to do something unpleasant.
I have no solid evidence to back any of this up, but it seems at least as plausible to me as any other explanations I've run across.
That’s a really interesting take. I say that as I’m the opposite — a slow reader — and I, too, cannot stand learning via video.
I’m by no means a weak reader, I love reading and do so often. I just find myself re-reading complex sections to ensure that I understand 100%.
I also like to be able to read something and then follow it on a train of thought. For example, if a post/article says that X causes Y because of Z I want to find out why Z causes it. What causes Z to be etc.
With a video I find this sort of learning to be inefficient and less effective while also making the whole experience a bit rigid. I also find that videos tend to leave out less glamorous details as they don’t video well if that makes sense
I'm also a slow-reader by your standards, re-reading to me is part of the learning process. Going over text with your eyes is not reading, let alone learning.
I think your dislike of video over text is because you're a quick learner. Like you said, going on a tangent and researching some word or sentence or statement makes you a thorough learner I think. Eventually you have a quicker and bigger grasp of the subject at hand, which is the whole point if you ask me.
Thanks mate! I think I consider myself a slow reader as I’ve grown up with my mother and sister who both read at some ungodly pace. They’ll finish 5 books for every one which I finish.
I do agree with the thorough learner aspect. I think having come from physical engineering backgrounds helps a lot with that.
When studying aerospace, for example, there was a lot of ‘but why’ which usually ended up leading to ‘natural phenomenon’ after abstracting far enough.
Alternatively: you can listen to audio while commuting or driving or cleaning or working out. I love audio for higher level things and to get an overview of the topic. Then text to dive into the details.
Another big driver to move from text to video: It is easier to monetise video via YouTube compared to a blog. People with millions of subscriptions on YouTube aren't creating FE learning material out of the goodness of their hearts; it is a big business. Also, video is almost always lower information density compared to text, so it is easier for your net to capture more customers.
And you can't just search in it. It's truly trashy format for anything other that presentation or lecture. For simple information sharing it's horrible.
We millenials ruined the doorbell industry by texting “here”. (Always connected)
Gen Z just sends you a picture of your door. (Mobile broadband)
What we perceive as the best way is often just driven by the technology available when we learned how to operate in the world.
I think you nailed it.
Another example of advertising destroying the world.
It can be quite difficult to follow programming topics over audio only, so it's not interchangeable with video in this case.
I have a fairly fast reading speed, but I mostly consume my non fic (not technical) books in audio format.
Why? Attention span. If someone is reading to me, I tend to get 'pushed along' and it makes it easy to slog through a non fiction book that really could have been a pamphlet but the author needed it to be 400 pages. If I space out listening, it's usually not a problem because most non fic books are so repetitive. I suspect that's the secret behind video's popularity, people's attention is in short supply.
I’m a pretty slow reader. I tend to reread sections, pause and play around with the ideas that come into my head, get lost while doing that and have to start over… I still prefer reading specifically because it allows me to do all that at my own pace. I don’t have to feel rushed along by a presenter or actively pause, rewind, try to scrub the timeline to find a point I want to rehash etc.
I really think you have got a point, I'd add however that reading is more cognitive effort than watching a video, at a basic level (that is, information in the text or video put aside).
Just see how hard it is to read more than a few paragraphs when tired before bed vs. how hard it is to watch something in the same state.
I think this gets added to the point you are making about reading skills declining.
People learn best in different ways. Some learn best by reading, some by tinkering, some by watching and listening. I heard this over and over in school and college.
I don’t think it has anything to do with reading speed. When taking in complex technical information, you spend more time thinking and trying to understand than actually reading.
If you’re finding that you can quickly race through content, it probably just means you find the content easy to understand because you’re already familiar with many concepts.
> no solid evidence
IMO you don’t need any. The correctness of your conclusion is self-evident. Proof by common sense, QED.
I happen to agree with the conclusion also. And you don't need a rigorous proof to do what you want to do. But I often find that people appeal/resort to "common sense" when they don't have a coherent argument, and just can't conceive of any other point of view.
>, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal.
I like (some) programming videos and I'll give my perspective as someone who learned 100% from books and 3-ring binders for old languages like C/C++/C#/Javascript/Python/bash/etc. (The 1980s Microsoft C Compiler manuals were 3-ring binders.)
The newer languages I learned with a hybrid of videos + traditional books would be HTML CSS, Apple Swift, and PyTorch with the latest AI toolkits and libraries.
The extra dimension that videos offer besides plain text is the live usage of IDE, tools, troubleshooting, etc. For me, watching a dynamic screen with a moving mouse cursor and voiceover seems to activate extra neurons moreso than just reading static text in a book.
There's also a lot of "activities in-between the coding" that's helpful such as seeing the programmer looking up something in various pages of documentation, scrolling around, navigating etc.
Another useful aspect that's underappreciated is seeing the mistakes the programmer makes during the video recording. E.g. the code doesn't compile because of invalid syntax. Or a config setting is wrong and he troubleshoots what's preventing it from working. In contrast, virtually all text books or blogs of coding are "perfect happy path" outcomes. But real-world programming is messy with broken intermediate states. A lot of videos show the messy steps to get to a working state.
The videos that are not that helpful would be the videos of C++ CppCon conference sessions where there are a bunch of static slides with bullet points and the speaker just reads them aloud word-for-word.
Although I learned C++ from textbooks, I found videos of Matt Godbolt showing tips & tricks of how to use his Compiler Explorer (http://godbolt.org) very helpful.
In summary, the artifacts of coding may be the text, but the activity of coding involves a lot more than just the text and that's why some videos can enhance learning.
I'm not sure if this is what you intended, but I read this as a great argument in favor of pair programming.
Definitely. As long as the videos are uncut, they can be a confidence booster that I'll be able to replicate the result, because I can follow them knowing they won't skip over those little steps that often go without mention. Well, unless they're being sneaky with hotkeys.
These videos are edutainment at best, which is generally not a good way to learn something well enough to be able to actually work with it. A lot of them are pretty much straight up entertainment, where the entertainment value comes from drama and strong opinions. They're totally fine if you know that, but some of their audience does not know that.
I've been seeing more and more of a certain kind of person who are into these videos on some Discord servers, and it is clear that they are driven more by culture and style than by the goal of creating some thing, or having a strong understanding of how to make computers do certain things.
> That people like video formats isn't really surprising to me since it's everywhere
That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.
Likely these videos did not exist when your reference / age group was acquiring these skills.
Videos are sort of easier to produce (via screen capture), and are much easier to show the effect of FE things: look, we write code like this, now we can click here, and the page reacts that way. No need to muck with JSFiddle or something.
I'm not a fan of videos as a reference medium, but they can be elucidating to those who needs more hand-holding, literally "click here, see the result". Back in the day, a few short videos about Blender helped me quite bit to grasp certain things that were not obvious from descriptions.
Blender is a gui first program, it makes sense that videos will work for it.
HTML and CSS are sort of GUI-first, too.
I've learned most of what I know about database internals from MCU lecture course on YouTube. It's great.
Famous YouTube influencer checks notes Carnegie Mellon university.
Marvel cinematic university?
I assume its CMU, Carnegie Mellon u
You wouldn't believe what else you can learn there.
I learned a new definition of boredom.
This correlates to my parent post - when my generation started with Flash around 2000 there was no literature on how to programm in Flash, it just happened.
So we went to the nearest bookstore and got a bunch of other books on programming. For many Flash developers the bible was Thinking in Java by Bruce Eckel. Most of the source materials for game programming (and that was a lion share of Flash programming) was in C++.
I'm not claiming that we were smarter, but by sheer coincidence, most people, even folks like me who skipped school, had very solid fundamentals. And partially due to the fact that it wasn't that lucrative back then.
Today most people don't care, IT is just easy money, kids have short attention span and trends are tailored by tiktok videos. All in all, it's just a fashion driven developement.
>I'm not claiming that we were smarter, but by sheer coincidence, most people, even folks like me who skipped school, had very solid fundamentals.
Higher barrier of entry should statistically lead to less people making it past and that those who do make it past aren't a random sampling of the initial group making the attempt. While the selection isn't only for intelligence, specifically the subsets of intelligence related to programming, I would doubt any claims it wasn't a factor at all.
It's not about learning (anymore). It's about consuming content. People spending (wasting) their time on X and YT are not there to learn something but to get their social media (dopamine) fix.
I hate YT, X, Insta. Don't even have an account. Some years ago there was really great content on YT, now it's mostly clickbait.
There's still lots of great YT content, much of it by the same producers you allude to, and they need your support more than ever with all the slop around them.
Here's one:
https://remix.run/
These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :(
And they just promote it and promote it:
https://kentcdodds.com/blog/a-review-of-my-time-at-remix
https://kentcdodds.com/blog/why-i-love-remix
https://kentcdodds.com/courses
Pure grift. But since most people are decent people they don't know and fall for it, and something like this influencer emerges. They have entire Discords of customers, the same as crypto scams.
Edit: I don't know why people would downvote calling out a notable grifter in a thread that extended out to a discussion about influencers. WHICH influencers? Are we scared of that topic? The climate of the JS ecosystem didn't happen accidently.
People fall victim to this shit right here on HN, and then write blog posts about what the fuck is wrong with frontend:
https://news.ycombinator.com/item?id=39453767
(This entire thread reads like deliberate testimonials.)
Stop buying this stuff.
I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach people about a framework. But the idea that the entire thing was created just to sell courses about it is not true.
But I do agree that there’s just way too much fast moving, breaking changes on front end in general, frameworks released every other week, etc…
But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.
It does. It bridges a purely server-rendered architecture with a SPA really nicely, and does it mostly with web standards. You don't need to run any client-side JS with a Remix app. It's not perfect, but there are a lot of benefits to its approach.
I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI at work.
But this "The web was perfect in 1999--stop changing things!" take is tedious and intellectually lazy. (I'm not accusing you of it, but it's certainly a common sentiment.)
We should be working together to solve concrete problems, and avoid both chasing the latest fads and pretending there's no room for improvement.
It’s a nuanced topic. If we want to dive in, I can provide a glimpse into the first layer of the anus as we stick our head into it.
When we shepherded a lot of sheep into frontend via these courses and boot camps and quasi courses/bootcamps in the form of certain frameworks (hey, you only know this one framework?), we created a cohort of something.
Now what is that something? It’s not really the tinkerer that loves doing this stuff and would have found a way to express themselves (please pay attention to the word “express”, as in, can’t help it). That something was … a pragmatic identity. A pragmatic identity was formed where “I am now a software engineer because I and my cohort agree, we really know how to do our stuff”.
Such a cohort can only be fueled by identity, not passion. This cohort can’t innovate and must cling to the identity of their original accreditation, so they will always be defensive.
That’s the first layer of the asshole as we enter it, it goes deeper. The second layer involves large amounts of money and people’s livelihoods, to which they’d defend unto death.
I don't believe you want to have a productive conversation about this. It sounds like you just want to be angry.
Okay? I'm having a lot of fun talking about some of the parts of our circus. I can't change anything. There will be new cult leaders (evangelists) for frameworks, and new cohorts, we can't change the past. Just pay attention to the rough framework (no pun intended, swear) as it happens again, and try our best to call it out, because it didn't always lead to great outcomes.
Money will be made on all sides regardless and we will all be fine financially. I'm talking about something else, inner. The infinite anus, asshole, is real - but now I'm just projecting.
> mostly with web standards
IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great.
At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain.
Especially because we haven't finished any of these migrations:
* ExtJS -> JQuery
* JQuery -> React class components
* React class components -> MobX-observed components
* Observable MobX components -> functional React components with context
* Functional React Components with context -> React Router v6
* React Router v6 -> Remix w/ GraphQL federation
I understand my situation is unique - I'm just bitter from needing to know ~6 different frontend technologies at once. Let alone all the Not-Invented-Here-Syndrome abominations in our codebase.
It's not that unique. The one enterprise app I worked on (that was started with Rails 1) had all of: Prototype, jQuery, Backbone, Angular, React, Handlebars AND mustache, vanilla CSS, SASS, CSS in JS (or whatever it's called). I wouldn't be surprised if they've introduced Tailwind at this point.
This is also a project started w/ Rails 1, so I feel our experiences may be similar.
To be fair to both code bases - it's very impressive that they're still running, right?
Definitely!
It actually wasn't even THAT bad considering how huge it is. People still complained (admittedly myself included), but it had been TDD'd from the start so had very good test coverage, at least. Also, some people who had worked on really massive Java applications called it "really good!" so it's all about perspective, I suppose :)
Remix already has data loading, why add GraphQL? It's a pain in the ass to work with from my brief experience.
That's my point exactly. I have the same questions from leadership.
your last note that adds not-invented-here abominations… if chasing endless frameworks of the month is bad, and building stuff in house is bad, then what do you propose to avoid making this mess?
I would propose that if you want to change frameworks, actually complete the migration from one technology to the other.
My problem is having all of them existing at once.
Skip a couple framework versions and indeed entire frameworks. Maybe go a couple years before you "upgrade" to something else. It is entirely possible you could go as much as 5 or 10 years on something. You'll still have to evaluate and potentially mitigate some CVE's. But that could actually be less work and less aggravating.
But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.
My point being, it's "based on" Web Standards, it is _not_ Web Standards.
What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before.
If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?
My favorite example of this being JSON gets converted to FormData on the frontend, which then gets POST-ed to the server, which then converts it to JSON on the backend.
I think you're mistaken. I can't comment on the quality of Kent C. Dodds' educational content, but his formal affiliation with Remix was short-lived. The courses that he sells have no apparent affiliation with Remix (the open source project or the company).
Incidentally, Remix is an open source project started by the React Router devs to create more framework features around React Router. React Router is probably one of the most widely deployed JavaScript libraries ever and is the furthest thing imaginable from a project created by grifters to sell online courses.
Remix was also a company that raised a $3 million seed round and then was acquired by Shopify (for presumably much more than $3 million). Shopify appears to continue to invest heavily in Remix and React Router development, and appears to use Remix heavily.
While his formal affiliation may have been short-lived, do you think he got a cut of the sale to Shopify?
If so, not disclosing that when he promotes Remix is a bit shady.
Nice dude and all, but that is one thing I take issue with still.
I don't think it's weird to like a piece of software and have that lead you to work at the company that builds the software and also to develop an educational course about that software.
Not weird to do all that. Just weird to not disclose it.
There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
Promoting it? No problem. But promoting something you profited from without disclosing it violates FCC rules for broadcasting. I would say influencers aren't technically broadcasting but they are in principle.
> React Router is probably one of the most widely deployed JavaScript libraries ever and is the furthest thing imaginable from a project created by grifters to sell online courses.
This is a funny example (to me) because in 2017, one of the two co-creators of React Router (Michael) came to my job and gave a two or three-day in-person training course on React. I think he also covered Redux and React Router. We had a great time getting to know him.
It turns out that Ryan and Michael spent a substantial amount of time and effort on a side business called React Training. It is fair to say that their speaking engagements were a solid revenue stream, but agreed - definitely not grifters.
[flagged]
In case anyone isn't familiar with remix, bloomingkales seemingly has no familiarity with the framework. Obviously it's not been created as a conspiracy to sell training courses. The idea is ludicrous.
It's quite a nice framework. It's easy to learn, straightforward, the people in their discord are very helpful. It has the backing of a large company (shopify) who are using it extensively.
It is, I'll say again, obviously not a conspiracy to sell training courses.
I get why you might feel that way. Ryan and Michael used to run a company based around React training. They created React Router which some people love to complain about. They've since moved over to working for Shopify. Shopify pays for their development on React Router/Remix. They do NOT sell training anymore.
Kent on the other hand, worked with them for a short time. He makes his living selling training. Filling in a gap (selling training) isn't really a grift is it? The dude's got a family and he's found something he can sell.
Not sure it's fair to characterize a repo with 6k + commits and the last being 10 hours ago as "pure grift".
E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training.
Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.
Do you know anyone who bought courses on react-router? The documentation is right there for free.
Wasn't react-training.com owned by the react-router people? I wonder what the training consultants recommended to use for routing...
And what's wrong with that? It works good if you're building an SPA in React.
You asked if react-router team sold courses, they sold consulting services. Seems like a conflict of interest to sell consulting on a tool you built while introducing breaking changes (but hey if you need quick help throw us a few dozen grand).
I guess that's fine for you but it's very smarmy IMO.
They also post (free) documentation how to migrate from the previous major version
[flagged]
You know you can just read rfc's right? there is a reason they update the thing, because people use it. https://github.com/remix-run/react-router/discussions/catego...
I think that adds to my point. How does that have so many stars on github? The customers "star" it. Who uses this on a real app? It's alright to slowly accept the bitter truth that grifting scales.
Not really sure that's relevant. Grift implies an intentional value extraction without providing anything. Using your example: I'm confident that the time spent working on remix and courses related to it resulted in far less monetary gain than spinning out courses on React. If you think Remix is misguided or a bad framework etc... that is very different from grifting. A corollary: Is Deno a grift because it shares the same creator as Node and has a paid product attached to it? In my opinion no but you might disagree... I'm mostly opposed to the idea remix in particular exists purely as a grift - love it or hate it there are far easier ways for someone with the influence of Kent to make money.
Imagine someone made Deno with a corresponding course to go along with it. I would consider that a grift.
https://frontendmasters.com/courses/remix/
That was the end goal for this whole thing. I do look at the pricing page (what are you trying to sell constantly?) on anything people put up on the internet and judge from there. You can have the last word and put in a testimonial for Remix, since I won't be budging on this. It's a rabbit hole for both you and me to keep going at this, as I've seen enough of this pattern. Consider me a neural net on this front (end).
I'm not interested in writing a testimonial for Remix, merely commenting on the absurdity of calling a project of this scale as nothing more than a grift to sell educational content. There's no reference to these paid courses anywhere on the landing page, there's no callout for paid courses in the main navigation. The only mention of tutorials at all is buried in the community section which leads to: https://remix.guide/ which seems to be unaffiliated with the Remix team, and has no section advertising paid courses anywhere. You're talking about a framework that has been acquired and subsequently used in production by a global company in Shopify - clearly there is something to the framework beyond being a vehicle for tutorial sales.
Again, I want to be clear: This is NOT an endorsement of Remix. Your line of thinking seems to be conspiratorial and not grounded in reality. You mention repeatedly about pricing and the end goal of funneling noobs toward course purchases... One would assume that in conspiring to sell courses the team behind Remix might actually advertise that they have courses for sale on their website.
I have to be honest as a third party that a. doesn't work with remix, b. doesn't know anyone who works on remix, c. doesn't know you - it seems like you have a personal vendetta.
No personal vendetta. We sit here and punch the mysterious air as to why things are the way they are. I thought maybe we'd punch up at something that is plausibly a culprit. I'll admit it may be punching down, since this is just one dude. But then again, it's one dude who influenced a lot of people ...
We can't just keep sitting here and blaming developers for being
1) New
2) Dumb
3) FOMO
4) Dumb
5) Unqualified
You understand? It's worth looking at what content they are consuming and where the mindshare is being promoted from. It's worth asking who is selling them the idea of these frameworks.
> We can't just keep sitting here and blaming developers for being New / Dumb …
Well, as a cohort, I think the ratio of inept programmers to skilled programmers stays mostly constant regardless of stuff like this. Like, if programming is hard to learn, fewer people will try and learn it. But also the skill bar goes up - so people spend more time as inept developers before they’re skilled. Likewise if programming gets easier to learn, we get a swell of fresh faces eager to become frontend developers. And the ratio stays more or less the same. It’s kinda like a sales funnel, or a hiring funnel. You always have more leads in your funnel than conversions. (And if you don’t, you’re in trouble!)
We live in an anti gatekeeper era. Content is free, but nobody protects you from wasting your time watching edutainment. The downside of that is real - lots of people waste countless hours larping as students. But the upside is real too. It’s easier than ever to learn anything.
>Grift implies an intentional value extraction without providing anything.
Is it without providing anything, or a value extraction greater than what one is providing?
If the former, it makes the definition very each to check, but it almost makes it very easy to avoid grifting by providing even the most minimal value, and leads use to needing a new word for providing some value but extracting more than provided (perhaps intention should be included). If that is the case, might I suggest "jrift"?
And what have you put out into the world?
I called out a grifter.
And what have you put out into the world?
I push back on stuff like this so developers who feel the feet on their throat from this culture can have some confidence to nudge the boot off.
There goes my hero: https://youtu.be/EqWRaAF6_WY
I can tell you that your response is at least relevant for me because I happen to be working with Remix right now, not because of any influencers but just because I happen to be working on a Shopify project. I've seen lots of frameworks come and go and evolve, so I'm not surprised that this one changes a lot, but I always enjoy getting opinions from people with experience. Whether or not I'll end up resenting it in the future, I don't know, but at least I'll have been warned.
I get shorts in my feed and it’s all Front End developers. It’s all stupid JS behaviour and other inconsequential stuff.
> web dev influencers
The fact that there's influencers for everything nowadays made me realize I'm old.
It's super useful that everyone is sharing their opinions and expertise to get that sweet 5 minutes of fame - I just learned how to tile my bathroom after watching a slew of TikToks on the subject, some with millions of views.
I can read pretty fast, but prefer videos for introductions to any new tech.
Then if I decide I like it I read the manual.
I think it used to be much worse. While the youtube/Tiktok churn might be much more active than 5 years ago, back in the ancient era of 2018-2016, the churn was driven by the fact that tooling sucked, which was capitalized on by people who were very good at self promotion but a lot less good at engineering.
I'm not a 'frontend guy', but I do write frontend code. I use Typescript React with hooks and context most of the time, rollup with esbuild to bundle and to run my dev workflows and raw CSS/SCSS for styling or Bootstrap for cookie-cutter UIs. I've also dabbled with Svelte.
This stack has served me well, and nothing here is newer than 5 years old. There's a cadre of much newer technology that I would consider stable (Vite + SvelteKit), but since new projects come with a maturity curve from the framework side and a learning curve, learning to troubleshoot issues and solve problems.
Anyone who constantly hops frameworks is doomed to be a perpetual amateur, working with buggy frameworks they know nothing about, and they will leave a trail of projects using deprecated frameworks in their wake.
Yeah, back in my day being an "influencer" required being able to crack copy protection mechanisms and add an intro into the loading screen, or animations deemed impossible in the given hardware, while remaining anonymous behind a group handle.
With fame being slowly propagated via tapes and floppies sent by mail, or some BBS archives.
Now you comment on what others do, or commit single function packages.
True, the barrier to becoming a tech influencer are very low now and yet it's harder than ever. This suggests that dumb luck plays an increasing role.
Current tech influencers are generally smart and qualified but they aren't experts in anything specific and they aren't innovative in any way. They are chosen by algorithms out of a large pool of possible candidates.
> This suggests that dumb luck plays an increasing role.
Nah. It’s not luck. It’s charisma. And skill at performance & in many cases clowning. Some people just have that certain something that makes people enjoy listening to them. It can be learned, but like programming it takes a lifetime to master. And like programming, some people are naturals at it.
I know because I’ve been training in improv theatre and clowning for the last 6 years. That’s enough that I could tell you in detail what people like the Primagen or Joe Rogan are doing. But I can’t replicate it. I’m way better than I was, but I’m nowhere near their skill level as a performer.
I don't agree with this position. Primagen worked at Netflix. This is already a massively significant luck component. I watched a video of his where he describes how he got his job at Netflix and it sounds like he got very lucky, by his own account. The brand recognition and network effects of having worked at Netflix cannot be underestimated. I'm sure he also got lucky in other ways. When you really dig into stories like his, you can find so many cases where they got abnormally lucky... Many cases where you're reading and think "wow, that's just not plausible, this does happen in the real world." Like reading the Steve Jobs biography, there are so many things that don't make sense... Like when Steve Jobs was young and he called the CEO of some company asking for some electronic component and they sent it to him... I did a lot of this cold calling when I was younger and nobody ever did that for me, even for much smaller companies and asking for much smaller favors.
There's no doubt the Primeagen has a popular channel (459K subs at last count), but his videos are super annoying to me. Many of them are just him reading a blog post and adding some light clowning to it. To me it feels like a waste of time...I can just read the article myself a lot faster and the clowning doesn't add any value to me.
I feel the same way. I don’t think you and I are the target audience for him. My read is that his content is actually pitched to a very junior audience - or an audience who don’t really want to read or engage with the blog post themselves. They want to feel smart and entertained without doing any actual thinking.
That sounds like I’m a snob - but I really get it. I’ve been watching Inkmaster lately with my gf - which is a reality tv show about tattooing. It’s super fun sitting on the couch judging all the tattoos they do. It would be nowhere near as much fun if I had to actually think, or do work while watching the show.
I think primagen is like that. It’s kinda like a trashy reality tv show about programming. If you don’t know any programming, you’ll probably learn a thing or two along the way. But you aren’t going to become a great software engineer by watching his channel. Not any more than I’m going to become a great tattoo artist by sitting on my arse, eating chocolate and watching ink master. I still do it. But I wouldn’t call it educational.
> But I wouldn’t call it educational.
Edutainment perhaps?
Yeah, I really do think "edutainment" is the correct classification for this type of content. A lot of tech influencers have figured out the formula for success on YouTube. In order to hit the sweet spot, the content has to be a mile wide and an inch deep to get the engagement metrics necessary to make the channel profitable.
It is incredibly pertinent. Even with the 20+ years of web dev I sometimes get swayed with clickbait like "If you are not using <frontend tech x> you are behind the curve, you are missing out, nobody works this way anymore, you are toast." This is an incredibly harmful take from those influencers. I do remember when it started - and it came from a good place, from a desire to "modernize from jQuery soup". But what it turned to now is noise that is sometimes hard to ignore.
It is only natural for a dev to ask themselves "am I still current? am I still relevant?". The induced FOMO triggers the worst bits of that anxiety, and sometimes I feel the influencers do not realise just how harmful this is.
I also don't think these front end influencers are even coding very much. Like if you hired them on a job on a serious team, they would probably come off like a junior engineer
I get that same vibe. It seems like their intent is to "wow" others into thinking how easy it is to become a developer and build an app with X framework. When in reality they just built a todo app that barely resembles how real software is built.
Yeah, it seems sort of obvious in its own way. People like “the primagen” on YouTube are really entertainers first and educators second. The pitch is something like “I’ll pretend to teach you something, and you’ll pretend to learn. But actually I’ll just entertain you by being a goofball for 20 minutes. You don’t have to do any work, and afterwards you can walk away pretending like you learned something”.
I suspect in his case he might actively dumb down his skill level for the stream, so he doesn’t scare away the junior devs.
The #1 tell is that all their projects are solo. Working on a team, working with peers, building software systems the live in production for years, through change and expansion, all seem beyond the typical influencer.
It doesn't help that JS projects are often thin wrappers around thin wrappers where the project owner puts more work into their Vitepress logo than a stable API.
It all seems like it is for CV glory. Then the projects don't see a commit for years.
Maybe now that’s a factor, but this has been a problem with FE development for many years, well before these influencers showed up.
I'm only recently getting into some of the dev influencer stuff (and enjoying watching some!), I've discovered Primeagen and Theo but that's about it. Are you willing to name some names? I am trying to still form my mental model about these people and what I should pay attention to and what I should ignore.
I agree with the other comment. Ignore them all, go with the fundamentals. Heck, ask chatgpt what do they think are the fundamental ideas in computer science and go from there. Look for classic books written on those subjects. There have been plenty of smart people around the sw field who took years of their lives to write succint and valuable technical books! Use them! Ignore the poison-mixers who probably didn't write a single line of code in their whole life!
Go for a decent text editor, learn how to type! It's incredible how we use ai tools to write code for us but some don't know how to actually write themselves! Again, look it up, there are plenty of resources out there. If in doubt, search for said resources here on hn. If still in doubt, ask chatgpt what does the hn community recommend for x or y.
You should ignore all of it. They mostly sell the idea of a developer to you, the same with any marketing. That's what an influencer does, they make you feel good about buying a cheap identity.
They're just entertainment. Like throwing on a movie or tv show.
I found value in a handful of Primeagen's videos (he inspired me to relearn C programming in a roundabout way) but the vast majority are fluff and I skip them based on the title or within the first 5 minutes.
A couple exceptions are Low Level Learning and Tsoding, who both generally stay technical, and any guest appearance by Casey Muratori will be worthwhile.
But even those, you're better off with a book or your own project to work on.
Not an influencer but: Casey Muratori is great.
He's actually the opposite of the "trendsetter" kind that is being criticized here, and is more of an educator with lots of experience in both education and business.
I agree. He's by far my favorite "very YouTube famous" programmer and it isn't even very close.
Yeah, I dig what Casey is doing. Subscribe to him instead of these other clowns. I like how his stuff isn't glossy or overproduced—he just gets down to the content.
Primeagen and Theo is pure brain rot.
Idk Theo reminds me so heavily of a "freelance frontend developer" I had to bear with on my team for a while. Eventually even my manager caught on to how pretentious and incompetent he was, so luckily it was a short intermezzo. An opinion on everything but not a clue of anything
The best programming videos I've seen are ones where someone just pointed a camera at a teacher in a classroom setting, like the Programming Paradigms series Jerry Cain did at Stanford some years ago. No attempt to add entertainment value, just a teacher, students, and chalkboards. I wish I could find more content like that, especially about newer stuff.
Have you checked out https://ocw.mit.edu/ ? They have a ton of MIT courses online for free in the format you just described.
I truly enjoy the Primeagen. I've watched him since he started on Twitch. I don't ever really see him pushing any particular agendas at all. Mostly he's either trying new things, or working on projects. That's pretty much been his jam since day one. He has opinions, sometimes they're counter to the typical dev takes. Theo is much more likely to have a commonly shared opinion. That's not necessarily a bad thing if you're into NextJS (I'm not). I just don't feel like either of those guys are trying to get me to buy stuff.
If you think they are fun to watch, watch them for entertainment, but don't fool yourself into believing that this is "learning". Their content is the definition of "video on the most googled keywords of the day" and the quality is about what you would expect. just consider how much content they pump out and how much time it takes to actually get into any of the topics they "cover" on a daily switching basis.
If you're watching for entertainment and, importantly, they're not selling you courses or a project they have a vested interest in, I wouldn't worry much.
Remember to take them as another perspective, not a source of truth.
The most problematic influencers are the ones who have pivoted to selling courses. If you find yourself thinking about dropping hundreds of dollars on someone's video course, spend a couple days reading free learning materials first so you can realize that it's almost always not worth it, no matter how much the smiling cheerful influencer pretends they're only trying to help you.
Prime is almost an anti-influencer. He promotes not adding dependencies more often than not. He's the guy making fun of the Ai craze, while also genuinely reviewing the recent releases and saying people should just learn to code instead. I really wouldn't put him in this general category of fe influencers discussed here.
His style is very much brain rot-like though. It's way more "entertainment" (though it isn't very entertaining to me) than informational content.
Meanwhile Primagen: " I Am Using Cursor - CURSOR FOUNDER TEACHES ME CURSOR!!!!!!! #ad "
Go on, link a video where he actually recommends Cursor.
The point is, you can replace "Cursor" with "hot new dev toy" and it's exactly how his channel functions.
Relevant YouTube video:
Dear Developer, the Web Isn't About You
https://www.youtube.com/watch?v=WYXSck7TyVM
> Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about
I feel sad to hear that. I thought that the decrease in the VC-money flow would also slow down the number of new FE-related frameworks entering the mainstream, but it seems I was wrong then
And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart.
15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications!
Almost all of the front end churn is simply a political/organizational failure.
I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm.
It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this.
I was doing it today to create a gantt chart from mermaid.
I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM.
At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
I did that a few years ago and it was fascinating: not only did it remove near-weekly React dependency churn, it produced significant performance improvements (multiple orders of magnitude better update speed - and yes, I did the usual incantations), and the total lines of code in our repo actually went down and it was easier code because it just did what was necessary without having to deal with layers of abstractions designed to work around earlier problems created by the framework.
One of the things I realized while working on it was that it was easy because I’ve learned the web platform over the years and was able to use builtin features rather than reaching for more libraries, but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around. That allows them to be productive, of course, but it often means that people take on layers of dependencies because once they’ve invested a lot in that path the cost of switching is really high.
> but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around
Last release of IE6: 2008
Concerted campaign to make everybody stop using IE6: 2009
Microsoft joins that campaign: 2011
First release of React: 2013
It may be hard to remember now that we’ve had frequently-updated browsers for so long but not everyone updated promptly. That lead to a lot of now-vestigial frontend culture where developers would build around the oldest browser they couldn’t afford not to support.
That colored a lot of low-level decisions about how events were implemented, false claims about virtual DOMs being fast or efficient, and especially the culture of adding dependencies because you need a feature which wasn’t in Internet Explorer. Once that trend is established, it’s hard to change without breaking compatibility and so you end up with people in 2025 using slower code based on the support matrix set over a decade earlier.
(And to be clear, I’m not saying that React has no redeeming values - only just it’s healthy to reconsider decisions made in previous decades to see whether the cost/benefit ratio has changed. I think we’re going to see some really interesting shifts as funding for open source shifts in a non-boom economy, but also as LLMs adjust the working style & relationship many people have to maintenance.)
The major turn for the average user was actually 2009/2010. IE6 usage seems to have dropped below 1% by 2012, still before React's public release: https://www.theverge.com/2019/5/4/18529381/google-youtube-in...
That said, I was on a team that was still supporting IE6 around 2014. We had clients, mostly in China from what I heard, that were required to use it because internal tooling had developed around it and their IT teams wouldn't let them upgrade.
Yeah, I worked on things geared towards the general public so we had to support, say, a senior citizen who was using old computers at the underfunded library or senior center. They weren’t a high percentage of total traffic but it was still millions of people.
It was definitely frustrating knowing that a better world was possible but not quite there.
If you are in the US, it's more likely than not that your local/state court system is managed by software that runs almost entirely on VBScript within an IE7 wrapper.
This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Homebrew dependencies were expected on the last git commit date.
> This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
It still works fine for end users, just not for the compliance department.
Depends on your SecOps. Ours shuts down apps with critical vulnerabilities if they're not patched within 48 hours.
The power of unreported vulns: uninterrupted use
I know, I've had to revive and make small changes to an old Angular project myself. Which is my point.
If the underlying technology hasn't really changed, why constantly break the tooling and compatibility in general?
This collective lack of discipline is exactly why I don't work in FE. It's just tiresome for no actual reason.
I also haven’t seen it in any other place. Game dev and backend which I’ve worked in uses the same technologies for decades. It’s like someone trying to write a book but instead of writing a new chapter each month they mess about with their ink choice and their font choice and their paper roughness and get very little actual progress
I will note that Bower’s last non-hotfix release was 8 years ago :)
I’ve got big hands!
> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas.
The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project.
Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bower, which FE used before using npm), and suddenly the advice became to just not program those things yourself, download the module.
But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
Even today, it's possible to care about your project enough to not bloat the invisible parts too much, if you want to be able to continue to work on the project. Again, requires restraint, and going back to the "I only need a function from this library so instead of depending on the entire library, lets just copy-paste this function into our codebase and add some tests" way of dealing with minor things.
So I guess what I'm ranting about, is that this is a people and process problem, not a JavaScript problem, because there are a lot of us JS developers who don't suffer from this problem, while large parts of the ecosystem does.
I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.
Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI.
Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language.
React is far more stable to build with and far less experimental.
People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere.
You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.
"Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI."
"People who have never touched any UI tech until HTML/JS have no clue how good they have it"
Tech like:
- Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments?
- Qt, developed and maintained for over 30 years, currently at 6th major release?
- Win32, and frameworks built on top of it like MFC, WinForms, WPF?
Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.
Just to reinforce how stable the desktop environment can be:
- Qt has had a mostly stable interface since Qt 4.0 and that was twenty years ago.
- Win32 has had barely any breaking changes since it was introduced with NT 3.1 in 1993 or so.
Most of the UI/UX churn in that space comes from fashion changes in UI design.
On the other hand, I can write a very complicated graphics-related app in React+tons_of_libs within _days_. It took me months to do that in Win32 API in 2005.
The developer velocity enabled by React is insane.
Yes, saying that calling Win32 APIs is not the most ergonomic approach to writing UIs would be an understatement, but if any software can be called stable, this is it.
I would compare win32 API to vanilla JS. Whatever framework you might want to use on top of win32 is what's comparable to the criticized web tech in the article.
Your win32 app would have been much faster with much less memory hogging though. I would prefer to run that compared to your React app.
The choice really is between React and nothing. React (and Electron) enabled a lot of apps to be written that would not have existed otherwise.
Calling Win32 directly was already old fashion when Windows 95 came out in 1994, let alone 2005 when .NET was four years old.
The only folks already doing Win16 development with pure C code, instead of a C++ framework (OWL, MFC, VCL), VB or Delphi, were stuck in jurassic park.
The only valid reason for raw Win32 applications are games.
I liked it in the Jurrasic park
> Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments
Not always. I attempted to upgrade some open source 32bit Delphi frontend code to 64bit/ARM, but the specific GUI toolkit was never ported.
It's similar for Java frontends, JavaFX in particular seems to be a moving target.
QT is a bit of an outlier in terms of frontend stability, but at the cost of the UI looking pretty dated.
Qt apps UI can look very good if QML is used with some effort. I wrote about it here: https://rubymamistvalove.com/block-editor
This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.
And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.
I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another).
I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.
Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right.
The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.
I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React.
My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer.
As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a post graduate students custom niche language. And I want to say the redux kid's background was literally microsoft powerpoint scripting. Very surreal time in development.
FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created.
Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS.
See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation:
- https://redux.js.org/understanding/history-and-design/histor...
- https://redux.js.org/understanding/history-and-design/prior-...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
We need a Behind the Javascript VH1 show.
Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.
People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap.
Well gosh darnit, then everyone and their mother is going to come to America
It's an age old envy.
I'm a back-end dev, I've avoided being paid to do any front-end work (and/or my bosses have avoided paying me to do any front-end work? hahaha) for getting on a decade now. So no doubt front-end devs will cringe at what I'm about to say (not that I care!). But for the occasional personal front-end stuff that I still do, my "dependency management" is just "copy-paste versioned CDN script tags / CSS link-rel tags into my index.html file". Which is equivalent to (but better than) old-skool copy-pasting into a "vendor" directory" (which of course I also did, back in the day). And my "front-end build system" is just "write vanilla javascript in .js files and include it un-minified un-typescripted un-anything via script tags". I've got better things to do in my spare time, than deal with npm / gulp / yarn / whatever they've invented this week.
> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).
It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.
> backed by a SasS service and VC money
While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.
A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.
By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.
The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).
If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.
Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too.
But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.
I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.
For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:
1) Can't update react without updating react-router because react deprecated some API
2) Can't update react-router without updating react because the new version of react-router is using some new API from react
And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.
I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...
At this point in time this is absolutely a "people and process" problem. But also the process that is there has been excercised and is known to folks you may hire. Trying to come up with less of it (or with a different version of it) dramatically shrinks the number of people who can be productive on your product from day 1, and is not a choice to be made lightly. There is also a number of people who will then be spending time convincing you that the "none" or "less" process you have imposed is wrong and you should "just get on with the program".
The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes.
There is simply no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.
One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
It depends on what you want to build. If you want to build impressive B2C software, this sounds like a recipe for disaster. I've worked with many backend engineers masquerading as full stack engineers who couldn't carbon copy a simple mockup design into a working UI if their life depended on it. Yet they never seem to notice how bad their implementation is, sometimes not even if you point it out to them even if the end users would notice; I think these engs are so enamored with their work they're in some kind of denial about the shortcomings. And that's just the visual parts. There's also skill required to take accessibility and conformance with web standards into account (HTML/CSS/JS stack is devious in that it lets you do things in ways that are "wrong"), which you can't easily fix later on by tweaking a bit here and there. So without this understanding, you end up with a crappy UI that's overengineered for what it is. Of course that all won't be an issue if you're building software you can sell even if the UI makes its users depressed.
Not saying your typical frontend engineer is flawless either. It's probably true that they're, on average, not as skilled sw architects as backend engineers, simply because a lot of their work focuses on details instead of architecting, and, again, the HTML/CSS/JS stack is incredibly flexible, in good and bad.
It's fair to point out that there is real skill involved in that kind of work. However, I don't trust the average "frontend developer" to do pixel perfect implementations either. Many of them don't even seem to know CSS anymore. And not to discount your experience, but being able to implement a design is something that is easily testable when evaluating candidates. Because I come from the multimedia agency world, most of the candidates I've hired were actually for that kind of role. Accidentally hiring people who can't do the work points to a competency issue with management. As I've pointed out elsewhere, I have the awards to speak authoritatively on this. But perhaps me focusing on average skill is just an unfair way to look it, since I'm never really looking for average anyways.
The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior.
For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the industry as a whole though, and specifically that I wouldn't trust the average "frontend developer" to be making wise engineering decisions. Saying this coming from a background of working with designers on webby award winning projects and having a high degree of respect for the platform.
I totally get your point. I'll just give you a little color about where I'm coming from. Most products don't need a team of over five frontend/backend devs (so imagine a team of 10 people). Most teams have been over staffed. When you are overstaffed, that's when everyone needs to be cookie cutter with cookie cutter expectations (e.g backend should do ui, frontend should backend). On non-overstaffed teams, the core group compliments each other very well and brings extreme expertise. No one on such a team ever goes "I can do what that guy does", because it's not a run of the mill mass market team.
I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.
That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.
Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.
I've also experienced the other end. As a pithy saying goes, "it takes a lot of skill to write Java in every language."
Maybe hire BE devs and use htmx.
Doesn't help. I just cannot center that div or make it look pretty.
> Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.
I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.
I think that culture will happen somewhere anyway, and FE being the battle ground is probably because it's the most visible part of the experience.
I mean: some people will want to reinvent the wheel, and preferably carve their name in some monument while doing so. And there will also always be an impulse to create busywork as it's the tide that rises all the boats, inflating the workforce in the field.
The staggering costs of breaking APIs is to some a feature, not a bug, and the field will attract more and more like-minded people who then accelerate that trend.
To note, BtoB focused startups usually go for a completely different FE stacks, including long deprecated ones, or even plain staticly generated sites wherever they can get away with it.
> 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.
What are you talking about? Websites from ten or twenty years ago are still working. If there's one technology with good backwards compatibility, then it's JavaScript.
Definitely not talking about vanilla js.
As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type.
All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something!
The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.
I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented.
What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about.
A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not.
Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list.
If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend. There are lots of great languages you can use for a backend. Java, C#, Go, lots of stuff. Js and python are the kind of languages you choose when you either don't know any other language or you don't know that they're ass.
The only good excuse to use JS is that your code needs to run in a browser. The only good excuse to use python is that you're just making a tiny little toy thing. Or you're doing data science stuff/ML, in any case you're not creating a large complex application. And you certainly don't care much about performance.
People invest so much time and money into creating more JS libraries and frameworks and stuff when what we should really be investing time and money into is creating an actually good language for the web. JS is the epitome of sunk cost fallacy.
"But TS" no. TS is just JS with a bunch of overly complicated type bullshit you have to deal with. It is a better dev experience than JS so I do use it, but it's less a cure and more a band aid over the huge, gaping and pus-dripping wound that is JS.
JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.
Yeah I'm aware that it works. I'm just saying it's a bad choice. It's slower than most other languages, the language itself is just plain bad, the standard library is poor, npm isn't great, there's really just no good reason to use it other than "our devs don't know anything else".
> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something.
And by "in JS", you really mean, "in NPM land".
So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue.
NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)
the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you.
Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
I understand why they had to EOL Vue 2 and make Vue 3 - I'm still facing migrating a couple of projects at some point, and I will keep putting it away x)
But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”.
NPM sucks. It's not the way to do JS
${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.
Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works.
A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
This is exactly why I am a huge fan of ember.js
Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
Ember is one of those frameworks that isn't as "flashy" as the latest and greatest javascript frameworks, but it just keeps quietly working and adopting new techniques from the more popular frameworks on a consistent and easy to follow schedule. They even make upgrading to the latest way of doing things relatively painless by providing scripts to automate many upgrades for you.
> 1. Before removing a feature in a major version, it lands as a deprecation in the previous major. A deprecation is only enabled by default once we have a clearly documented migration strategy that covers the use-cases of the old feature.
> 2. When we ship a new major, the only thing it does it flip deprecations targeting that new major into errors.
https://bsky.app/profile/wycats.bsky.social/post/3lg2p5dwuzk...
I'm thinking of building a long term living app (say an app that I will use the next 30 years).
It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript.
The fewer things you have in your stack, the fewer things can change under your feet.
Go for web components. It's guaranteed to last 30 years
If you MUST use a framework, then yes i would go with ember because they have a prooved commitment to following the web standards rather than creating their own custom standards that they throw away the next year.
Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.
If you are designing for that kind of long term I suggest looking into SmallTalk. A lot changes in 30 years.
The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it.
No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.
It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.
> No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.
To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.
I agree, it seems like popular packages really need an LTS release channel or something. Enterprises do not have budget or time to continuously invest in their front end tools.
Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.
> it seems like literally everything is deprecated
I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen.
I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so why would I bother?
but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvious reason.
Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
I mean the browser and security does change somewhat often so there's that.
> Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes.
That so many libs take advantage of semver is both good and bad.
Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.
Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?
Well, what's wrong is your mindset, if anything. You're not supposed to do anything. npm still works, it isn't deprecated, and it does more or less the same thing as the others, only that others can be slightly faster.
But if npm/yarn/whatever works for you, just use that thing. The mindset of having to move to whatever "mainstream developers" are using today is what is causing you problem, not that alternative solutions exists in the first place.
Main difference between all of them is speed. There’s some differences in how npm, yarn, pnpm or bun handle workspaces and hoisting (and stuff like dependency overrides) but if one of them works for you, you rarely have to switch between them.
Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
With respect, you almost certainly stopped paying attention for much longer than six months. yarn v2 was a significant rewrite that was released five years ago and a lot of Yarn projects either never upgraded or just switched back to npm (because npm eventually addressed most of the major reasons that yarn was better than npm).
`pnpm` was released back in 2016. It's 9 years old at this point.
I think part of the problem is this thinking that
- you must change things all the time (yarn is still good why switch?)
- the things you change to are somehow really new (pnpm is 9 years old)
Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988.
I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.
Hardly a deal-breaker; presumably I can just pipe the output to less.
npm is not deprecated and is a pretty good choice. pnpm is a bit nicer in some details, but it's a nonstandard tool - use it if you're familiar with frontend development enough that you understand the tradeoffs you're making, but otherwise sick with npm.
npx is a tool bundled with node/npm for running commands in isolated environments. It's mostly useful in two situations:
* You want to run a particular NPM-distributed tool as a one-off, and have the tool installed outside of your current project and then uninstalled afterwards. This can be useful for scaffolding or trying out tools released using NPM.
* You have a local project and one of the dev dependencies provides a utility to e.g. lint the code or run a migration. npx allows you to directly call commands installed locally without having to set up `npm run` beforehand.
If you don't know why you need it, you don't need it.
No, we're past pnpm and on to bun now
Bun may be fine for people using it to replace the javascript runtime
As a dependency management toolchain I recommend reading: https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothi...
I had some issues with it using it briefly (though it was way faster than other installers I've used)
Sorry, everyone’s on pyarn now and next month we’re deprecating that for pbun and then starting from scratch with taquito when that doesn’t solve all our perceived problems
Still using gnu make.
I'll concede that I've moved to bazelisk over make
But first you need corepack because globally installing yarn is BAD
Corepack is marked experimental but trust us bro
oh if you don't have corepack just install it globally (this is fine)
If you do have it, you have to opt into the experiment by running "corepack enable"
So simple
Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist.
FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)
I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json.
I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up.
I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.
Okay thanks for your patience. I put together this gist based on an interaction we had with a user last year, I hope it's helpful: https://gist.github.com/bignimbus/457f9ac42f29d0bb6c4eb742ad...
That matches my experience as well.
Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search.
X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced.
A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.
Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.
>>The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated.
I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc.
Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features.
I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend.
Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
I’m getting back into development after being a photographer for the last 10 years and after reading your comment I thought “maybe I should apply at a bank…”
This.
I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends.
And every time it leads to a complete rewrite.
And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season.
The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers.
I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise.
I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming.
And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.
Many bring the same mindset to backend as well. In my small team of less than 10 developers we use C#, Java, Kotlin, Rust, Elixir, Go, Javascript, Typescript, and Python to worry about and maintain because developers have been allowed to pick what they want.
I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume
> because developers have been allowed to pick what they want.
That's a technical leadership failure first and foremost
You could make exactly the same complaint about python packaging. We've gone from setuptools, to pip, to poetry and now uv.
GraphQL is such an exciting addition to the front end stack. Imagine, an entire new system you need to learn that cargo cult proponents love and also sucks ass to use.
decides to swap out a working package manager for another for no apparent reason
"Why do JS people keep doing something new for no apparent reason?"
The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.
I'd gladly swap out any piece of tooling if it's written in JavaScript.
There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This leads to a loop of unrealistic optimism.
1. Library X promises to abstract everything away in an easy-to-use way
2. Devs adopt X and it makes work fast and fun.
3. The human element forces in tons of edge cases.
4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.
5. Devs start looking for an abstraction that works and goes back to the first stage.
I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.
Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.
If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.
The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.
I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.
DRY is a means to an end rather than an end in itself.
> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.
Like a challenge to write better code that is still bad enough to throw away as soon as possible, I think there's something to scripting that feels enticingly ephemeral.
Fully agreed that the amount of "that was last year's answer" is obscenely frustrating.
Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
I fully agree, _but_ it's not just frontend, it's the entire NPM ecosystem. Meaning it's not much better in NodeJS (or Deno/Bun/whathaveyou)
It's more or less always been like this.
It's why I moved to mainly backend (where feasible).
Because someone has to maintain that crap at some point.
Part of the problem is that React monopolized the entire space and most other frameworks became legacy; not able to maintain even a tiny community.
The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit.
This is why frontend development is so bad these days.
I've been working on a small side project on-and-off for the last year and some. The state-of-the-art decisions I made last year are already dead. There's a new version of everything, and everything was a breaking change, nothing is backwards compatible.
How do people live like this?
They don't. They say fuck it and learn a trade.
This is why I stopped doing front end.
This has been the most amazing thing about ClojureScript - finding libraries that are 10+ years old without an update still work perfectly. Using reagent and over time learning more and more of the internals (instead of the runaway treadmill in js land).
I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.
Meanwhile, I can go dig up some open source Objective-C/AppKit Mac app project that hasn’t seen any activity in 20 years and probably get it compiling and running in an evening. Cleaning out warnings might take a weekend.
I wonder what it’d take to achieve that kind of stability over time in the web front end world…
I'm still using npm and wasn't sure if I should use yarn or pnmp, is there a clear winner here on this one?
Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.
pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you.
Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies.
Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks).
tldr: I'd recommend pnpm.
Cool, thanks! I've not anything this succinct between them before.
I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.
This is why I have been so pumped for LiveView. It just removes so much javascript from the equation
And when you need to use JS, you can do so in a clean and controllable way.
Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input
Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview
https://surface-ui.org/
> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc
My theory is that they do it because they don't have enough to do.
one wonder how this liability of a tech stack became so popular. i have a theory it was VC dollars pumping up a ton of saas tools and they all came out with one-click integrations.
this is one house of cards that may never really be fixed.
I work mostly on the JVM world, with Java/Kotlin. Two comments:
In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good).
In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).
My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"
One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.
laughs in C99
This experience is one of the reasons people love Phoenix LiveView so much.