The frameworks and tools aren't all that stable, reliable, or intentionally designed compared with what Java programmers might be used to. I don't fault anyone for trying to get off the bus.
Is JS tooling less of a Rube Goldberg machine nowadays? I remember that the people I knew who got into it but not fully used to use these humongous auto-generated boilerplates that glued together webpack, gulp, babel, had build processes involving native dependencies that would fail with weird errors vaguely related to Node JS versions, and this all to develop in the frontend.
Compare: Clojure. You have the project.clj file and put your dependencies there. The you do lein run or build a fat jar and run it like java -cp your.jar your_app.core. The end.
Not really (any less). A couple of years ago we migrated a project from Spring + GWT to Spring + Vue. The Vue part is nicer, but everything around it feels messy. The team is primarily backend / java developers (we had a frontend expert at the time too), but we felt that the JS frontend part shouldn't be that hard to master. Maybe Vaadin would have been a better option after all?
No it’s even more so with the rise of framework frameworks like Next.JS and Cypress. These frameworks are just wrappers around other frameworks. JS will never escape this as its primary reason for existence was a glue layer between Browser and HTML/CSS.
I've yet to see a single professional software company use these eztra layers. Though there are no doubt some most people are still using React, Vue or Angular directly.
Thw humungous auto-geberated boilerplates are rude goldberg machines. But you don't need those at all. A simple webpack config (including setting up babel, typescript, etc) is less than 100 lines (not nothing, but comparable to build scripts in other langauges).
It's worth noting that there is some inherent complexity in the web platform due to the fact that you are generally targetting multiple platforms. Server side code has it easy here (and indeed Node.js generally needs little in the way of build process)
Regarding error with native NPM dependencies (usually when switching node versionw, or switching between macOS node and linux node in docker): this can almost always be solved witha simple `npm rebuild` once when you change node version.
<eye roll> For tables, tables are fine. The only thing worse than jumping on a new thing because it's new is completely abandoning something because it's not.
I don't see how using TeaVM, which is not stable at all, has very little activity (a handful of commits since summer) and is going to be extremely niche since most people don't have that weird aversion to modern JS tooling, is a solution.
