[skohan]

This is something I really deplore about the state of modern software development. Taken collectively, it's mind-boggling the amount of waste there is in terms of memory and CPU (i.e. energy) usage by running a huge portion of consumer software in the browser. We could achieve the same result so much cheaper, with better performance and UX, by putting a serious effort into a set of standards for handling code from an arbitrary source securely.

[Epskampie]

> a set of standards for handling code from an arbitrary source securely

That is what html+js is. Why do you presume a different standard would be more efficient in the end?

[skohan]

HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist.

The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very limited support for web workers. I'm also limited to basically one language, which is garbage collected, so performance and memory usage are significantly worse than they could be. And as far as graphics, you're limited to WebGL which is ages behind the state of the art in terms of graphics APIs.

Basically there is a whole universe of tools out there for software development, but if you want to target web you're limited to a handful of poorly performing, hacky options.

For my work, we use several web applications to collaborate. As someone who works on highly optimized user-facing software, it's frustrating to understand how poor these web applications perform given the potential of modern hardware.

The reason we use them is because you can send anyone a link, and they're into the software in one click. There's no reason we couldn't have the same experience for native software, where when you click the link your computer downloads a native binary and runs it in a sandboxed environment against a standardized system API. It would take a lot of careful work and planning, but there's no technical reason it couldn't exist, and it would be so much better for developers and users.

[Epskampie]

But if it were to run on every platform and processor the binary would have to be written to some VM, which would slow it down a bit. That’s webassembly, which is coming up.

Also, there would have to be some GUI framework that works well across all devices, phone to desktop. That alone would be massive undertaking.

I agree there is no technical reason, but once you consider all limitations and let some time pass in the end you might up with something similar to what we have now. For example you might standardize on a current graphics API, but in a few years: guess what, you have an outdated API like webGL now.

[skohan]

> But if it were to run on every platform and processor the binary would have to be written to some VM

Not necessarily. You could have different binaries for different architectures. All you need is a consistent system interface with a well-specified ABI, and the client would just have to request the binary for their architecture.

> That’s webassembly, which is coming up.

Web assembly still has the limitations of running inside the browser. It's still single-threaded, and also the file size is pretty large compared to a binary.

> Also, there would have to be some GUI framework that works well across all devices, phone to desktop.

If you had a consistent system interface, you'd only have to do it once.

> For example you might standardize on a current graphics API

I mean Vulkan is basically this. And graphics API's are converging not diverging: modern graphics API's are all structured in a very similar way, since they're all just wrappers around the low level functionality of the GPU at this point.

I'm not saying it would be easy, but the reasons we don't have it have more to do with the fact that it would be difficult to get buy-in from OS vendors than it has to do with the technical problems involved. From a technical perspective, we could easily do way better than modern web.

[random32840]

JS is generally very fast because these monolithic VMs have had so much money poured into them that their optimisation process is unparalleled. V8 can sometimes get performance on par with C. "Overhead" is arguable, JS may be garbage in a lot of ways but modern JS is quite efficient.

[skohan]

sometimes is the key word there. It's amazing what kind of performance can be reached with JS given the monumental amount of effort which has gone into optimizing it, but there are structural reasons JS hsa a performance ceiling. JIT compilation can't change the fact that it's a highly dynamic, weakly typed language which is garbage collected. You might be able to find examples where a JIT compiled block of JS code performs comparably to a similar block of C code, but there are design patterns available in languages like C/C++ and Rust which aren't even expressible in JS which allow an extremely high level of optimization using careful memory management techniques.

Also web is basically a single-threaded runtime environment. For the foreseeable future, increased parallelism is the main way we can expect to get increased computing performance, and it's basically not available on the web.

[why_only_15]

The biggest thing you would probably be sacrificing is development time for every engineer involved. The html/css/js stacks have had unimaginable amounts of manpower invested, more so than any UI stack in history. This has made them much easier to learn and manipulate. Throwing away all of that would be a very hard sell.

[skohan]

I agree there would be an adoption problem for something new. But if there were a viable alternative, and people managed to build killer apps on it might be possible to draw adoption over time as people got to experience the superior performance.