There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps. I'm curious: what is that difficult work that you're doing? Because if it's legitimately difficult, it probably shouldn't be done every single time you're building and deploying your webapp, should it? Because if you have a large webapp, "difficult" is slow, and you should be avoiding "difficult." "Busy work" is for "smart" projects. "No work" is for exceptional projects.
Tree-shaking is treating a symptom of not paying attention to what is in your front-end. It's purely daft to me. This sort of thinking alone is how you get karma.conf.js files with configurations built by 5 teams over 3 years who have no idea what the configuration is doing or why particular versions of Webpack are supposed to be used, or why you have to hire some senior software engineer to do nothing but comb over some gulpfiles across various projects for months at a time that haphazardly move critical shared client/server webapp files for a product moving 80% of your company's revenue, or why a simple front-end change actually requires two weeks of development time, oh and don't forget paying your QA engineer for testing this, for something requires a simple tag change but the build process is out of date, so now you have to fix that first.
You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns, whereas I have no idea what you're talking about. You know what's a lot more work? A build step. Oh and I've never seen a build process in npm take milliseconds across a large project. But one that has none to begin with doesn't have a creeping perf issue. Because if I do have a build process, it better finish immediately, without cache.
Because if builds don't finish immediately, it's just more overhead in my CI/CD that I don't want outside of testing, and now I have to watch it, because those times only ever grow unless someone cares enough to optimize them.
This isn't a tool for people who like to make their lives easier, because anyone who was in a position to hire wouldn't use tools like this. No one knows what Astro is.
You can't hire for it. If you did, it's a waste of engineering hours to get someone to screw around using this unproven tech versus a typical React stack.
I want tech that lasts for years and years and years that isn't PHP, so I can retain engineers who actually know what they're doing and aren't screwing around relearning something for the 10th time while I pay them 6 figure salaries.
I don't have to change anyone's mind. There are some people that work faster and produce more than others, while others ask themselves how they do it while they toil away relearning.
You're conflating two separate arguments that you made.
1) That a build step is a bad idea.
2) That this tool, Astro, is a bad idea.
I wasn't arguing against #2 and don't care to. I don't personally use new or niche build tools myself. Some people might have different tradeoffs, but I generally agree that 100% of niche build tools (and 90% of popular ones) end up being unmaintainable technical debt.
> There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps.
That's fine. People are free to waste enormous amounts of dev time doing things that build tools can do for them.
> You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns
I believe you believe this, but it's not black-and-white.
The majority of the dev world (including the people making 7 and 8 figures at Facebook, Google, and Microsoft) has realized that JavaScript, HTML, and CSS are not good languages for writing web apps.
Building from other languages or DSLs (TypeScript, JSX, Svelte, Vue, etc.) allows people to have better developer ergonomics and still get code that can run in a browser. It's not really any different from using a compiler to get assembly.
If you don't build anything, you end up doing tedious optimizations in your code. Tree-shaking was an example I brought up, but there are many more possibilities: minifying, combining assets, etc. Worse, you might just be writing vanilla JS without the benefits of TypeScript or a completely separate language.
Using a poorly-maintained build tool (or an unpopular one) is definitely a problem, but throwing them all out because some of them require devs to spend some time learning them is ridiculous.
Tree-shaking is treating a symptom of not paying attention to what is in your front-end. It's purely daft to me. This sort of thinking alone is how you get karma.conf.js files with configurations built by 5 teams over 3 years who have no idea what the configuration is doing or why particular versions of Webpack are supposed to be used, or why you have to hire some senior software engineer to do nothing but comb over some gulpfiles across various projects for months at a time that haphazardly move critical shared client/server webapp files for a product moving 80% of your company's revenue, or why a simple front-end change actually requires two weeks of development time, oh and don't forget paying your QA engineer for testing this, for something requires a simple tag change but the build process is out of date, so now you have to fix that first.
You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns, whereas I have no idea what you're talking about. You know what's a lot more work? A build step. Oh and I've never seen a build process in npm take milliseconds across a large project. But one that has none to begin with doesn't have a creeping perf issue. Because if I do have a build process, it better finish immediately, without cache.
Because if builds don't finish immediately, it's just more overhead in my CI/CD that I don't want outside of testing, and now I have to watch it, because those times only ever grow unless someone cares enough to optimize them.
This isn't a tool for people who like to make their lives easier, because anyone who was in a position to hire wouldn't use tools like this. No one knows what Astro is.
You can't hire for it. If you did, it's a waste of engineering hours to get someone to screw around using this unproven tech versus a typical React stack.
I want tech that lasts for years and years and years that isn't PHP, so I can retain engineers who actually know what they're doing and aren't screwing around relearning something for the 10th time while I pay them 6 figure salaries.
I don't have to change anyone's mind. There are some people that work faster and produce more than others, while others ask themselves how they do it while they toil away relearning.