The historical context is web development became popular and developers from other disciplines moved over and brought their practices from those other areas of programming with them. We compile apps for the desktop, we should compile apps for the web too. They brought their complexity with them and forced it onto web development instead of stopping to consider if that was a good idea. Now we have developers who never knew how things were before transpilers were created and now think that this is how it has to be and that this is the best way.
Have you worked with old, medium to large sites filled with jQuery and custom ad-hoc scripts? In the past year I helped maintain a site exactly like this - it's a huge pain. So many problems that should've been caught sooner are noticed far later, leading to long feedback loops that cost time and money.
Sure, I would agree that the current JS ecosystem has its issues, but work can happen at either compile/design time, or at run time. Shifting work from one step to another has trade-offs that may or may not matter for a given team or product.
For small hobby projects? The scale makes these problems pretty insignificant, so handling more at runtime ain't so bad. But the number of possible problems multiplies as your codebase increases in size, and by solving these problems sooner, you spend less time overall dealing with them.
Typescript was still 0.x "public preview" and I was knee deep in a codebase that was a massive amount of jQuery scattered across mostly inline script blocks in a huge number of ASP.NET templates many of which were "components" subcluded by other templates (meaning who knows how many final inline DOM-blocking script blocks per final output page). I had helped invest a ton of effort into an AMD infrastructure to start to modularize all those inline script blocks, but the conversion was pretty slow going (AMD modules were a pain to write by hand) even though the clear performance win of it helped keep it a clear priority project. Typescript even in 0.x made all of that so much better and easier if for no other reason that it made writing and managing AMDs so much simpler (and type checking helped code quality so much as bonus).
A lot of compile time tooling didn't fall out of the sky because they were solutions looking for problems. They solved real problems at the time. It's amazing to think how few developers today remember "the bad jQuery days" and "server-side template inline script block hell" and AMDs (good riddance, though they too solved important problems in their time). I don't think they can understand how much "our compile times are slow" is a better problem to have. I'm not sure if I envy some of them having missed some of the worst of those past problems.
> We compile apps for the desktop, we should compile apps for the web too.
I don't think this is true at all. The key reason you see build steps are to solve problems that you don't even have to worry about in desktop apps. If you have an app on the web, its bundle size needs to be small so that it downloads over the internet in a few hundred ms or so. So you get a minification step. You want a good type system, you end up with a build step. You want broad compatibility with older browsers? You end up with polyfills. Need to do some asset processing? You end up with some scripts that have to run at build time.
Build steps aren't some arbitrary complexity people make them out to be. They solve performance and compatibility issues, which impact real users in the real world. Running full-blown desktop apps over HTTP comes with a different set of problems compared to any local native app.
Of course most of this isn't important for small side projects. But for many, side projects are a way to learn about different technologies they might end up using for larger projects or in a professional context.
