4 ms·

The basic problem can be described quite simply. HTML was designed for the World Wide Web - a matrix of hyperlinked documents. For that purpose it more or les

The basic problem can be described quite simply. HTML was designed for the World Wide Web - a matrix of hyperlinked documents. For that purpose it more or less has succeeded (some people were more ambitious about what authoring hypertext should have achieved but I'll ignore that wrinkle). However, these days people want to do things with the web other than write hypertext - they're wanting applications on the web in just the same way we want applications on our computers or apps on our phones. And for THAT purpose, HTML / CSS / DOM is utter gobshite. If I want to write an application, the bottom of layer of that shouldn't be "now convert that into something that perverts document layout of the browser to look like something that hasn't been laid out like an HTML document". We need a technology that is suitable as a compilation target: a virtual machine. It can be optimised to hell (better than JS which necessarily is always compromised by having to be JavaScript and not byte code) and we need a suite of basic machine systems - sound, graphics, storage. We're not really all that far off from these things with what is supplied with HTML 5 it just sucks that the core of the affair - HTML/CSS/JS - is rotten through and through.

sktrdie 11y ago
I think UI really shines using the Web stack because it was built using async tools from the very beginning. UI development should be async from the get go. In other non-webby systems you do UI using async but you're still using blocking tools (for example by using Java's mixture of async for UI but blocking for other stuff). JavaScript on the other hand, and all of its libraries, are entirely async which makes it a pleasure to work with - it's a much more natural environment to be doing UI in (single thread and everything is there to be used without multi-threading complicated stuff). This is a big insight that JS and other webby-tools have given to the UI world, and I strongly believe something entirely async needs to exist for the desktop/mobile world as well - fortunately there is in the form of node.js/electron/nw.js. Now in terms of how that's handled behind the scenes, I don't really care (use a nice VM, use a whatever mixture of whatever you want). Just give me a fully-async toolset to build my app in a single thread and I'm happy.
- peterashford 11y ago
  I can't agree that UI via JS async is a pleasure to work with. I can't think of a UI technology I've found less pleasurable to work with. No - there was an ancient C GUI that used all C Macros to compose - that was worse... but only just.

sktrdie 11y ago

I think UI really shines using the Web stack because it was built using async tools from the very beginning. UI development should be async from the get go. In other non-webby systems you do UI using async but you're still using blocking tools (for example by using Java's mixture of async for UI but blocking for other stuff). JavaScript on the other hand, and all of its libraries, are entirely async which makes it a pleasure to work with - it's a much more natural environment to be doing UI in (single thread and everything is there to be used without multi-threading complicated stuff). This is a big insight that JS and other webby-tools have given to the UI world, and I strongly believe something entirely async needs to exist for the desktop/mobile world as well - fortunately there is in the form of node.js/electron/nw.js. Now in terms of how that's handled behind the scenes, I don't really care (use a nice VM, use a whatever mixture of whatever you want). Just give me a fully-async toolset to build my app in a single thread and I'm happy.

peterashford 11y ago
I can't agree that UI via JS async is a pleasure to work with. I can't think of a UI technology I've found less pleasurable to work with. No - there was an ancient C GUI that used all C Macros to compose - that was worse... but only just.