I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized.

These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.

I believe you might have a slightly biased view of what front-end development largely looks like. What you're describing is the type of front-end development that goes on at the organizations that actually develop these frameworks.

The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped mess of bad practices everywhere.

Now if you take a look at development outside of front-end and go to some large non-tech, mid-sized, or small business you'll probably also find poor practices (from my experience), but nothing like the mess I see in these same organizations trying front-end development now.

If someone is making a static business informational page, it’s significantly more likely that they’re using WordPress and jQuery than e.g. React [1]. Like, significantly significantly — 20x more likely to be using jQuery (which is on a full 83% of all webpages) than React, and 30x more likely to be using WordPress than Gatsby or whatever.

People on HN talk about React and friends because they’re building client-side apps that deserve full frameworks. But it’s absolutely not representative of most web development.

[1] https://css-tricks.com/how-the-web-is-really-built/

Perhaps, I've only seen front end projects at FAANG and personal projects. That said, my front projects have at least an eslint config and usually a CI/CD deployment strategy if not full on tests.

Do you ever wonder whether we cause the complexity ourselves. Did we need React? Flux? Graphql? Since we introduced these concepts we needed to rethink a huge amount of other stuff to keep it performant.

Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple.

You have to stay on the bandwagon because it’s where the community is now. There’s certainly a lot more fun to be had remaking everything in React though.

The main advantage of react in my opinion is the reusability of components. Most developers are not artists and can't design aesthetic and ergonomic interfaces from basic web elements, whereas with react you can install a component library (like material UI) and effectively just focus on business logic.

I'm mainly a backend developer so can't comment on how this tradeoff works out when you have the resources for artistic UI/UX folks and reduced development pace.

We had component libraries and reusability before React. I think a lot of FE best practices evolved at the same time as React.

A good example is React Native which is less about React but more about a js interop layer with Cocoa that happens to use React for the rendering.

If all you’re doing is submitting a form with Ajax, sure, jQuery would be fine. But I’ll venture that most frontend apps are at least somewhat more complicated than that.

My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.

It’s pretty clear you haven’t worked on any modern front end site. Go and try and build any front end site demanded by most business owners in jquery. It’s not just bandwagon, it’s solving problems in the environment in which they are required with the tools that are present. It’s so incredibly naive to think the efforts of tens of thousands is all pointless if they just used this one tool.

The reality is that most front-ends at most companies don't require that level of engineering. Sure if you work at Netflix or Facebook, there may be a lot of "real engineering" going on but most people don't work at those companies. But the guys at these small companies want to feel special, so they reach for whatever the big guys are doing and try to implement it, regardless of need. The same thing happens with (insert your domain here). Like, we have a single webstore with 10k customers, we need a Kubernetes cluster etc etc because Google does it.

> I think you have a fairly dated understanding of what front end is

Certainly, as I am finding out. Can you suggest some solid, robust frontend framework that doesn't break in 3 months when I update the dependencies?

Svelte and React would meet the criteria you described. So would Mithril.

Give Svelte a try online, their tutorial page is pretty slick: https://svelte.dev/tutorial/basics

I've gone through those. It looks clean. My biggest worry is the npm package manager and all the crud it brings into the repo.

It brings a package.json and a lockfile into your repo. There's arguments to be made against NPM but it doesn't bring any diffent "crud" into your repo than Composer, Maven, Pip/Pipenv/Poetry, or any other package manager.

That's an odd comment to make, you just inadvertently proved their point. Most large web products are serious (?), have 'proper architecture' and hundreds of frontend developers working on them. Google products, Spotify, AirBnB, JIRA/Atlassian, Booking.com, Trello, GitHub.. you name it. You may also notice TypeScript in the first paragraph of the report, which is a type checker and has been enjoying massive adoption.

Not 'his', 'their', but yes, I agree that the projects being done on the web are hugely complex these days and have a rich set of building, linting, releasing, testing, etc. tools.

corrected, thanks.