> HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility.
Verifiable security? You can't statically verify a program is secure.
Flexibility? The complexity has given it greater flexibility.
> For instance, a developer has no choice of programming language, but has to resort to javascript
Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!
Unless you use a compiler. Which you can do, and it works very well.
I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.
> also, the developer has no choice of render engine
I thought complexity was an issue?
But this is also not true. You can use your own if you really want to.
Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.
> the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet)
Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.
> And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.
> We need simpler primitives
We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.
Verifiable security? You can't statically verify a program is secure.
Flexibility? The complexity has given it greater flexibility.
> For instance, a developer has no choice of programming language, but has to resort to javascript
Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!
Unless you use a compiler. Which you can do, and it works very well.
I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.
> also, the developer has no choice of render engine
I thought complexity was an issue?
But this is also not true. You can use your own if you really want to.
Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.
> the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet)
Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.
> And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.
> We need simpler primitives
We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.