3 ms·

> Browser side Javascript is just a compiler target at this point you're a decade late to this observation. CoffeeScript came out around 2009. The world has la

> Browser side Javascript is just a compiler target at this point you're a decade late to this observation. CoffeeScript came out around 2009. The world has largely been transpiling to ES5 for at least eight years now. The fact of the matter is, JavaScript post-ES6 is a solid language. Many of those people that were using ClojureScript/CoffeeScript/etc. have moved back to JS. 2007 JavaScript has almost nothing in common with 2022 JavaScript. I think this needs shouting from the moon, based on the comments I keep seeing on HN. We used to have to use Firebug. On IE we were totally blind. JavaScript was designed to crash silently while still allowing a web page to function. Today, JS is a critical part of most pages and has sophisticated tooling. > There might still be valid reasons to use DOM + CSS like we have been for the last two decades. If you care at all about accessibility and general browser standards, then you're stuck with the DOM. You have to reinvent the world each time you decide to make the canvas your entire UI. It's hard enough getting browser history and URLs working and creating the illusion of "pages" in a SPA. I can't imagine the pain in the ass this would be in a WASM blob. > But it won't be the only choice for doing UIs. It was never the only choice. Not even in 1996. Macromedia Flash, Java applets, etc. For niche applications, the canvas is great. But the majority of the world will continue using the DOM.

jillesvangurp 5y ago
Accessibile UIs are possible outside the browser as well. Lots of native applications exist that are accessible by e.g. blind people. Actually a lot of that stuff existed before the web was even a thing. All that stuff can now be compiled to run in a browser. The majority will continue to follow the easiest path. Which is not necessarily JS+DOM+CSS anymore. And contrary to your point, there always was a lot of friction with flash and Java or other plugins like silverlight. You had to install them, you had to keep them updated, they had security and performance issues, etc. General design by committee browser standards are kind of very limiting however. It doesn't even come close to what was possible 15 years ago with flash and shockwave. That's why games don't have browser based UIs for example. They suck. It's just not good enough if you are trying to immerse the user in a futuristic and playful game world. That's also why mobile phones have native UIs. We can do better than dom+css. Way better. And now that we no longer have to stick to just ccs+dom in a browser, inevitably people are going to make use of that.

jillesvangurp 5y ago

Accessibile UIs are possible outside the browser as well. Lots of native applications exist that are accessible by e.g. blind people. Actually a lot of that stuff existed before the web was even a thing. All that stuff can now be compiled to run in a browser. The majority will continue to follow the easiest path. Which is not necessarily JS+DOM+CSS anymore. And contrary to your point, there always was a lot of friction with flash and Java or other plugins like silverlight. You had to install them, you had to keep them updated, they had security and performance issues, etc. General design by committee browser standards are kind of very limiting however. It doesn't even come close to what was possible 15 years ago with flash and shockwave. That's why games don't have browser based UIs for example. They suck. It's just not good enough if you are trying to immerse the user in a futuristic and playful game world. That's also why mobile phones have native UIs. We can do better than dom+css. Way better. And now that we no longer have to stick to just ccs+dom in a browser, inevitably people are going to make use of that.