In reality, JavaScript in 2019 on V8 - thanks to innovations like JIT compiling - is in almost the same ballpark as Java itself when it comes to performance. JavaScript itself is not what slows down JavaScript UIs.
What does slow down Web UIs is the DOM (whose rendering engine in Chromium is written in C++). The DOM is the most advanced layout engine ever created. It does an unbelievable amount of work to make interfaces resizable-by-default and adaptable-by-default, and yet is enormously flexible, allowing one to build virtually any box-based interface imaginable. This isn't simply so newcomers have an easier time. It frees application code to focus on the control logic and the structural side of the view, instead of messing with things like pixels and manual sizing, which makes application code more maintainable and reusable. I can place a piece of DOM in wildly different contexts, with wildly different amounts and types of content, and for the most part it will just respond as expected. This significantly reduces code complexity, which improves long-term maintainability and avoids bugs.
This of course comes with a cost. All of those implicit layout adjustments have overhead. The ability for your code to handle content you never thought it would encounter requires CPU time. That cost isn't worth it for certain applications. But it isn't a waste, or a sign of the moral decline of "kids these days". It's a conscious tradeoff that any good developer can weigh and consider for what it is.
What does slow down Web UIs is the DOM (whose rendering engine in Chromium is written in C++). The DOM is the most advanced layout engine ever created. It does an unbelievable amount of work to make interfaces resizable-by-default and adaptable-by-default, and yet is enormously flexible, allowing one to build virtually any box-based interface imaginable. This isn't simply so newcomers have an easier time. It frees application code to focus on the control logic and the structural side of the view, instead of messing with things like pixels and manual sizing, which makes application code more maintainable and reusable. I can place a piece of DOM in wildly different contexts, with wildly different amounts and types of content, and for the most part it will just respond as expected. This significantly reduces code complexity, which improves long-term maintainability and avoids bugs.
This of course comes with a cost. All of those implicit layout adjustments have overhead. The ability for your code to handle content you never thought it would encounter requires CPU time. That cost isn't worth it for certain applications. But it isn't a waste, or a sign of the moral decline of "kids these days". It's a conscious tradeoff that any good developer can weigh and consider for what it is.