You're relegated to the backend not because you know Java instead of Typecript, but because you don't understand the problems of frontend development.
Thinking about how a user interacts with a page, how asynchronous data loads, different screen sizes, how to handle intermittent connections are very different problems than most backend developers deal with. They are all very complex topics that have been evolving over the last 15 years. Modern frontend frameworks focus on addressing these complexities. Because JS/TS are the language of the frontend, the best frontend frameworks are written in these.
Async data loading and intermittent connections are something backend developers should actually be prepared for, even though some of them like to pretend everything is always available quickly and reliably because of "cloud".
In my experience as a "full stack developer" frontend likes to reinvent itself rather than find new solutions to problems. We've had responsive design policies for years now and touch screens have been the norm, I don't think you need a "modern" library for anything, really. Just one that works well enough and a big chunk of well thought-out CSS.
I think technologies like Blazor are more useful to practical application development than a new version of React/Svelte/Vue where the widgets are now Fogo-based rather than Bar-based because the library developers considered it a better API.
In a perfect world, you don't need two languages for frontend and backend. You can torture yourself by adding the Node stack to the backend, or try something like that new Kotlin project, but it's clear we're still quite a ways away from well integrated web application development.
I dont think you have checked Blazor runtime libraries size. Last time I tried, it downloaded 5MB wasm files to the client in a simple hello-world screen.
Personally, I don't think Blazor is really finished, I wouldn't use it in production. It's more of an example of what can be.
Ultimately, I don't think 5MB blobs are all that bad for web applications that need the enormous complexity these libraries provide. Classic Django/Symphony/Spring Boot with some CSS animations and Javascript glue can work perfectly for the smaller apps. For things that aren't applications, you shouldn't need any framework at all, websites can/should just be static files to make everyone's lives easier.
> Ultimately, I don't think 5MB blobs are all that bad for web applications that need the enormous complexity these libraries provide.
The cases where this makes sense are probably internal enterprise applications or advanced tools.
For everyone else, there is this: https://whatdoesmysitecost.com/#gniCost (or at least it was a curious reference, before the pricing figures seemed to kind of break in other tabs; though this might as well be considered, not just site load times, or battery life implications)
"You're relegated to the backend not because you know Java instead of Typecript, but because you don't understand the problems of frontend development."
I've designed a number of front-ends in various languages on various platforms and am very comfortable with vanilla web programming and design.
The reason I'm relegated to the back-end because 99% of front-end developers don't know how to program and choose garbage like JavaScript or based on it and are often intently amused by the mention of yet another tool out of hundreds that churn all that crap into something almost useful but hopelessly unmaintainable.
Thinking about how a user interacts with a page, how asynchronous data loads, different screen sizes, how to handle intermittent connections are very different problems than most backend developers deal with. They are all very complex topics that have been evolving over the last 15 years. Modern frontend frameworks focus on addressing these complexities. Because JS/TS are the language of the frontend, the best frontend frameworks are written in these.