3 ms·
Agreed. Javascript is increasingly something that is optional. You can use it but you no longer have to use it. And even if you are using it, you are more than
by jillesvangurp 5y ago
Agreed. Javascript is increasingly something that is optional. You can use it but you no longer have to use it. And even if you are using it, you are more than likely transpiling it. Browser side Javascript is just a compiler target at this point. There are a minority of people not doing any transpilation of course. But at this point that really is a minority (and by no small margin I'm guessing). Nothing against that, but "native" javascript just stopped being a mainstream thing quite a few years ago.
That doesn't mean Javascript will go away but it does mean it now has to compete on merit rather than relying on it's status as the only thing that you can actually use in a browser. Many projects have already shifted to using Typescript for example. And from there to other transpiled languages is not that big of a leap. We use Kotlin-js for example. It's great. Other people use clojure, vue, elm or other languages that basically aren't javascript but that just happen to transpile to it.
Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. The only remaining reasons to target browser js with your compiler, is that it still has better bindings to the browser APIs. This is something that is being worked on and of course that is more than offset by being able to compile existing libraries to WASM.
WASM has a few other things as well that are still being worked on (threading, memory management/garbage collections, etc.). But long term, anything that javascript can do in a browser would be something you could do from a WASM compiled program as well. Once that works well enough, a lot more languages will start targeting browser applications just because they can. And a lot of developers that don't necessarily care about downgrading to Javascript might have a go at doing some applications that run in a browser. I predict a little renaissance in frameworks and tooling for this.
And of course with WebGL and Canvas, using the DOM and CSS is entirely optional. For example Figma has a nice UI that looks like it would be hard to match with anything DOM based. They have a bit of react on the side for the bits that don't really matter but most of the app is C++. People also run games, virtual machines, etc. in browsers. There might still be valid reasons to use DOM + CSS like we have been for the last two decades. But it won't be the only choice for doing UIs. And being limited by it like we have been is increasingly no longer necessary either.
- udbhavs 5y agoCould you share some more about your experience with Kotlin js and the libraries/frameworks you use?
- jillesvangurp 5y agoMostly good. We use the Fritz2 framework. It's a reactive UI framework that has a nice component library and supports styled components using a Kotlin DSL for CSS. It heavily leans on things like Flows (from Kotlin's co-routines library). We have a multiplatform client library that uses kotlinx-serialization, ktor, kotlinx-date, and a few other things. Interoperability with javascript is possible but a bit cumbersome due to the need to map types. A typescript mapping conversion exist but it does not really work that well. We use e.g. the maplibre framework to display maps and it has issues converting the type mappings for those. We ended up doing this manually for the bits of API we needed. Main downsides are the relatively immature tooling (though that has rapidly improved over the last year) and slowish build speeds. The Kotlin compiler has some performance issues.
- cies 5y ago> Long term WASM is a more efficient compiler target. Smaller, faster, easier to deal with for compiler builders, etc. And more obfuscatable.
- monocasa 5y agoI'd say obfuscated JavaScript is more obfuscated than stripped Wasm. In cases where you don't have meaningful symbol names either way, wasm's code flow is required to be significantly more structured than what you can get a JavaScript VM to accept and run. Those invariants that help the VM make sure the code is safe to run at close to native speed also halos automated tooling deobfuscate it.
- deckard1 5y ago> 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.