With JavaScript it seems the simpler the programming model gets, the more complex the build system and tooling becomes
No! We’re actually pretty close to not needing any build process!
The only thing browsers can’t do is resolve package-based import paths. (And I have a small on-the-fly rewriter for that.) Other than that, the only reason you “need” to have a bundler that calls babel which calls plugins and so on is backwards compatibility.
(Oh, also another reason is JSX. Consider lit-html/LitElement instead of JSX based… stuff!)
If you don’t have to support ancient browsers, you SHOULD ship raw ES6 with async/await directly to browsers without any compilation steps.
No matter how optimized Blazor gets, it will always have some overhead compared to JavaScript, because it will need to ship a .NET/Mono runtime. So we’ll always be able to do more with our 130KB compressed first-load budget if we stick with JavaScript, or something that compiles to JS with little or no overhead. It’s better still, of course, if we can do what we need in much less than 130KB compressed. This is why I think something like Sapper should be the future of web application frameworks.
As developers, we need to prioritize the user experience, not our convenience. So in my opinion, something like Blazor should be a non-starter. But if someone can compile a meaningful subset of .NET to JavaScript with a hello-world no bigger than Sapper’s, then that will be worth looking at.
This makes me realize that webasm is actually a really really bad idea.
All the worst practices of bloat and overcomplexity in frameworks and stacks is going to be amplified even further.
I truly understand your concerns.
But I think that the issue is much worse than spreading bad practices.
No! We’re actually pretty close to not needing any build process!
The only thing browsers can’t do is resolve package-based import paths. (And I have a small on-the-fly rewriter for that.) Other than that, the only reason you “need” to have a bundler that calls babel which calls plugins and so on is backwards compatibility.
(Oh, also another reason is JSX. Consider lit-html/LitElement instead of JSX based… stuff!)
If you don’t have to support ancient browsers, you SHOULD ship raw ES6 with async/await directly to browsers without any compilation steps.
No matter how optimized Blazor gets, it will always have some overhead compared to JavaScript, because it will need to ship a .NET/Mono runtime. So we’ll always be able to do more with our 130KB compressed first-load budget if we stick with JavaScript, or something that compiles to JS with little or no overhead. It’s better still, of course, if we can do what we need in much less than 130KB compressed. This is why I think something like Sapper should be the future of web application frameworks.
As developers, we need to prioritize the user experience, not our convenience. So in my opinion, something like Blazor should be a non-starter. But if someone can compile a meaningful subset of .NET to JavaScript with a hello-world no bigger than Sapper’s, then that will be worth looking at.