>All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.

This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.

Yeh Babel and webpack blow out compile times to epic proportions.

Any app that grows to a certain size will slow down to a crawl on incremental builds.

Try esbuild. I thought the following benchmarks must be fake until I tried it myself.

https://raw.githubusercontent.com/evanw/esbuild/master/image...

I really can’t believe that.

But I will try!

There has been some interesting tooling being written in Rust, swc[1] compiles very fast. Not quite production ready but getting there.

[1]https://swc.rs/

I'm not familiar with TS compile times, most of the engineers I know working on FE code use JS.

Thankfully on my projects FE and BE are separate builds, so I only do FE builds when needed, I save so much minutes.

Genuine question: in what sort of setup do you have a single build for your frontend and backend?

JEE and .NET, where the build takes care of handling JavaScript, CSS and HTML files, provided they are on the expected project layout structure.

Naturally I am not doing SPAs in this case, just vanilla JS and web components.

The FE/BE split builds are only in SPA projects, with BE being mostly about WebAPIs.

> All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.

This is a shocking argument coming from any front end dev. Since when is static type checking, working on serious big repositories that take time to compile, have proper architecture with hundreds if not thousands of programmers working on it comparable to 3 frontend folks working on a web application? There is so much wrong with this argument and haven't scratched the surface.

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.