6 ms·
I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that l
by hn_throwaway_99 2y ago
I'd argue that other languages did this (or something similar) to great success, most notably Java.
That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes.
With an interpreted language like JavaScript, the dividing line is a little grayer, because the shippable code isn't bytecode, it's still just text. But it still seems to make sense to me to target a a "core", directly interpretable language, and then let all the syntactic sugar be precompiled down to that (especially since most JS devs have a compilation step now anyway). Heck, we basically already did this with asm.js, the precursor to WebAssembly.
- supriyo-biswas 2y agoIt seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.
- hn_throwaway_99 2y agoWhat's old is new again :) asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do. This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.
- no_wizard 2y agoI think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns. Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example. Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard
- pjmlp 2y agoActually in regards to Dart it is a more subtle. Dartium was cancelled and AdWords team, having just migrated from GWT to AngularDart, saved the Dart team. Eventually many left the team. Somewhere at Google, Flutter started and when they decided to replace JavaScript on their original design, they decided to reach out to the Dart team. So Dart got a new purpose in life, being Flutter's language. In this process it was rebooted from dynamic language, into a static type one, having JIT and AOT toolchains. How long Flutter, and by association Dart, remain relevant remains to be seen.
- petre 2y agoDart is a better designed language in many regards.
- mdhb 2y agoIt’s not just better than JavaScript, I would argue it’s probably the best general purpose modern OOP based language out there right now. It was actually really fortunate in that for a long time it didn’t have a big community behind it and they just put a lot of very smart language designers on the team where they had ten years to try various approaches and learn from the mistakes of not only themselves but others without a lot of outside noise. But there’s no other language I would prefer to write applications in. It’s just a really nice mix of ergonomic, expressive and powerful.
- pjmlp 2y agoasm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.
- adjav 2y agoPNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
- pjmlp 2y agoGiven Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference. Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.
- DonHopkins 2y ago>"let's shove the JVM into every browser and make it a mandatory part of web" Javagator / Jazilla! https://www.cnet.com/tech/tech-industry/javagator-down-not-out/ https://www.cnet.com/tech/tech-industry/javagator-down-not-o...
- no_wizard 2y agoThey’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to. I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs
- singularity2001 2y ago>> WASM isn’t the silver bullet everyone seems to cling to. And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.
- xscott 2y agoYou're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.
- singularity2001 2y agoFrom the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md https://github.com/WebAssembly/stringref/blob/main/proposals... I don't really mind, as it keeps the wasm bytecode cleaner.
- xscott 2y ago"trampoline business"? It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort. Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?
- dmart 2y agoI’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?
- xscott 2y agoBecause it's already solved from day one and people keep repeating that it's a problem anyways. Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.
- hu3 2y agoCould you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too. This is what StackOverflow tells me (2020): > Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React. > JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead. This feels like "we can have DOM access at home" meme.
- xscott 2y ago> This is what StackOverflow tells me (2020) Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too. I don't even know what he's on about with Preact/React... Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM. <!doctype html><title>Not that hard</title> <script type="module"> document.addEventListener('DOMContentLoaded', () => { /* Compile this module with wat2wasm to make the binary below: (module (import "env" "easy" (func $easy (param i32))) (func $run (param) (result) (call $easy (i32.const 123)) (call $easy (i32.const 456)) ) (memory $mem 1) (export "run" (func $run)) (export "mem" (memory $mem)) ) */ const binary = new Uint8Array([ 0, 97, 115, 109, 1, 0, 0, 0, 1, 8, 2, 96, 1, 127, 0, 96, 0, 0, 2, 12, 1, 3, 101, 110, 118, 4, 101, 97, 115, 121, 0, 0, 3, 2, 1, 1, 5, 3, 1, 0, 1, 7, 13, 2, 3, 114, 117, 110, 0, 1, 3, 109, 101, 109, 2, 0, 10, 14, 1, 12, 0, 65, 251, 0, 16, 0, 65, 200, 3, 16, 0, 11, ]); const imports = { easy(arg) { const div = document.createElement("div"); div.textContent = "DOM this: " + String(arg); document.body.appendChild(div); } }; const module = new WebAssembly.Module(binary); const instance = new WebAssembly.Instance(module, { env: imports }); instance.exports.run(); }); </script> That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export. I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas. > This feels like "we can have DOM access at home" meme. And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.
- binary132 2y agono, people need to be able to program the browser without needing “tooling”
- halostatue 2y agoThe BEAM VM (Erlang, Elixir) does this with what’s called "Core Erlang", used as lower-level targets before compiling to the BEAM primitives. https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_erlang https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_e...
- thayne 2y ago> because the shippable code isn't bytecode, But what if it was? What I would like to see is: - a bytecode "language" that roughly corresponds to Javascript semantics, and that is what the engines interpret (and JIT compile) - browsers still include a compiler to compile JS sourcecode to the bytecode. Possibly wasm could work, although it would need a lot more functionality, like native support for GC, and DOM access, etc. - browsers include a disassmbler/decompiler to improve debugging the bytecode Then simple sites, and development can use plain JS source, but for higher performance you can just deploy the pre-compiled bytecode.
- alpaca128 2y agoI am certain this would mainly add problems while not improving performance as websites would just add more stuff on top until it's again on a barely tolerable level, for both the user and the developer who know probably has to manage yet another super simple, blazingly fast tool to keep everything running.
- javajosh 2y agoThe problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules from within the same page without either a) hacking the global object or b) generating unnecessary resources).
- petre 2y agoThe vanilla js APIs are so atrocious that we got jquery.
- javajosh 2y agoI think you missed a tense. Was atrocious, we got jquery, which got folded back into javascript. If the last time you worked with vanilla js was when jquery was hot, you're views are outdated.
- petre 2y agoSibling and parent/child traversal is still a disaster and querySelector, querySelectorAll doesn't solve it.
- RandomThoughts3 2y agoYou are getting your history reversed. Java is a product of the JVM, which was the innovation, not the reverse. A successful language moving post-success to a new byte code format would be as far as I know unprecedented. The idea that JavaScript is an interpreted language is also fairly shaky. It’s JIT compiled as soon as it arrives to your browser. Honestly, a modern JS engine is not different from any other VM. The question as you rightfully pointed really is what do you send to the browser and under it lies the fundamental question of what is a browser actually. Is it a way to browse hypertext content or a standardised execution environment?
- pier25 2y agoJava doesn't run in browsers so the comparison doesn't make sense. Splitting the language might make sense from an engineering perspective but what about all the extra energy and bandwidth that will be needed?