| There's a lot of space between rendering text and doing a slow remote database query. HTML is great but it just wasn't designed for building efficient UIs: • No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank. • JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher. • DOM/CSS are extremely generic because they have to satisfy both document and app use cases. They're both low and high level simultaneously. On one hand that's great for making interactive documents - an important class of thing that non-web tech mostly ignores - on the other hand it means a lot of branches in hot paths, stringly-typed everything, big code footprint in the renderer, heavy objects, high level libraries can't use shared memory and more. The header file for Blink's DOM Element class is ~2000 lines by itself. • No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it. • The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them. • JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach. It all adds up! |
> No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank.
This is completely untrue today. I have a variety of ways to move work out of the UI thread as just a simple website. The easiest is to just use a modern networking API like fetch. If you're using response.json() on the result of a fetch call, you're done. The parsing is already off the UI thread by default.
If you don't want to do that (or you have a use case that's doing heavy lifting that's not a network request), you can easily add a serviceWorker and hand off the parsing to that JS context.
If you're on a browser that doesn't support serviceWorkers, you can simulate a similar handoff through framing your page (each page is getting a new JS context) and passing data around with postMessage.
If you're targeting Electron specifically - they start with the concept of a background worker (main) that is independant of the UI thread in the first place. It's easy to move work there.
----
> JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher.
This is true but not really relevant. If you really need to be doing something with high overhead - electron allows you to easily call into native libraries, but you risk losing compatibility.
---
> DOM/CSS are extremely generic because they have to satisfy both document and app use cases.
I see this as a plus. DOM/HTML/CSS have literally been put through the ultimate trial by fire of use cases, and they are still standing.
---
>No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it.
This is exactly what <meta> tags are for. They absolutely allow you control over the rendering process. Everything from specifying how to handle viewports to choosing the exact version of legacy IE you might want to target.
---
> The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them.
I would argue that when the sandboxing is cheap, there's no reason not to use it. There's a reason that most enterprises allow their users to browse the web at large, but heavily restrict installed applications. Just from a bureaucracy and politics point of view, the sandbox is a plus.
---
> JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach.
Yes, yes it does. It's called Typescript. Overkill for a single person project, but really freaking powerful for teams. Does exactly what you're describing - makes refactoring easy and safe, and allows teams to coordinate effectively.
------
It does add up, but it sounds like it's been a long time since you've done real work in this space. It's definitely not the same as it was 15 years ago, and while some of that change is probably churn, a lot of it is valuable additions that address nearly every complaint you've come up with.