The Frontend Treadmill

> 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.

>, 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.

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”.

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 get shorts in my feed and it’s all Front End developers. It’s all stupid JS behaviour and other inconsequential stuff.

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.

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.

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.

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.

Primeagen and Theo is pure brain rot.

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.

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.

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.

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.

> 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

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.

> 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.

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 will note that Bower’s last non-hotfix release was 8 years ago :)

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.

I've also experienced the other end. As a pithy saying goes, "it takes a lot of skill to write Java in every language."

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.

Maybe hire BE devs and use htmx.

Definitely not talking about vanilla js.

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.

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.

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...

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.

> 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.

Everywhere I've worked would have judged heavy emphasis on framework expertise rather than fundamental CS concepts and web standards as a red flag. I don't think it's that rare.

Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.

Coincidentally, I just migrated something from Tailwind v3 to v4, even though Tailwind isn't really much my cup of tea. The migration tool that they ship was able to do everything. e.g. I ran it, then my project built and worked with v4 instead of v3.

Likewise, there haven't really been any major API changes in React lately either, but if you want it to be automated, they ship react-codemods which will handle a surprising amount of edge cases for you when upgrading.

I don't think it's moving the goal posts. It's a very reasonable thing to ask. I have Go projects that are now 10 years old that require zero maintenance on my part.

I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react.

Sure if you were using just react that is okay, but how many frontend projects are JUST using react? The issue with react has always been the community surrounding it. Library recommendations that use to be "best practices" get churned into the next thing marketers want to push.

It's very wasteful in our community because we are just tilting at windmills rather than focusing on the harder problems we have to collectively sell. We should start shunning tools that enable this churn, not all frontend communities are like this either but the popular ones seem to be.

To be fair...

Webpack existed 10 years ago, and that was after Browserify had already existed for a bit, too. The era of bundling was already in full swing in 2015, and React gained support for ES Classes, too.

React wasn't really terribly usable without bundling. Prior to bundling, there were multiple competing adhoc module systems, but obviously this wasn't fantastic for a variety of reasons. AngularJS 1.0 was great in part because the dependency injection system kind of took care of a lot of trouble; you could have a workflow in Gulp/Grunt concatting your JS together, and the order didn't really matter a ton since dependency injection would largely handle it.

React moved relatively quickly in the first few years, but 10 years ago was already not the very beginning of React. It was starting to mature by that point.

It's not too difficult to use the TypeScript type checker on JS files, so it's possible to reap most of those benefits without having to introduce a compilation step.

SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack.

https://www.sqlite.org/appfunc.html

The secret is to make the thing that runs on the backend the application, and the thing that runs on the edge device the user interface.

I wonder what you think of components. Back in the day it was heresy to mix css html and js. Everything was separated. Nowadays a component mixes them all.

In a way, it is exactly the example opposite of what you mention.

I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.

Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.

Delete the API, render your html on the server, problem solved.

I get really exacerbated when people make this mistake.

Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.

I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!

I was never able to understand what useCallback does.

I've been using MDN for a decade, and this is a TIL!

You can still write class-based components in React, no problem. It might not be in vogue, but for the most part, you can still write React 18.x roughly the same way you wrote React 0.x.

Then you aren't doing what the author is talking about.

Do you mean your package.json literally has no dependencies declared (or you don't even have package.json)? If so, you're not using frontend tooling like 98% of development teams.

As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.

Most likely because you work on apps in active development. Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new.

Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?

They're very much not "best practices", and will be deprecated soon (if they're not already).

I'm not convinced.

- they're much harder to learn and understand than the callback hooks from class components

- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them

- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)

- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm

- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)

- the mental model for how to put them together when you're writing custom ones is a little bit funky too.

- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier

I think that's only if you've rehearsed it several times. Although now that I think about it, you will probably have to do it multiple times, so once you get good at it, that may be a reasonable estimate.

The problem is more cultural than technical. JavaScript folks see the ready availability of dependencies as a feature rather than a risk, including the creation of a plethora of micro-dependencies (such as the left pad fiasco).

React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.

You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.

Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.

> If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools.

Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.

How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?

I just had a thought and decided to look it up.

This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years."

The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production?

So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.

> That's a problem with your build system then, not React.

Did you read the sentence that you're "correcting"?

> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.

Your optimism is admirable.

"That was some good slop, sir. Can I come back here for lunch every day for the next 10 years?"

Hilarious, and accurate.

FFI is new for me. Foreign function interface? https://en.wikipedia.org/wiki/Foreign_function_interface

> A foreign function interface (FFI) is a mechanism by which a program written in one programming language can call routines or make use of services written or compiled in another one

Nifty, will remember that.

The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you.

The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).