Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What makes WebAssembly fast?

hacks.mozilla.org

Post reply on HN
Print view View original

201–210 of 238 posts

Re: What makes WebAssembly fast?

#201

Post by mkawia »

zurn wrote: post #199
aphextron wrote: post #139

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript. Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iO…

JS provided that already without WebAssembly, no?

I don't understand why the downvotes , JS is one of the most target languages. Elm,GHJS(Haskell),Purescript,Clojurescript and supersets like Typescript which come with their own toolchains.

Re: What makes WebAssembly fast?

#202

Post by mort96 »

bluejekyll wrote: post #109
jfoutz wrote: post #76

Earlier quoted context omitted.

Wild guess? Oracle with Java.

Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS. It could have been JS, but it was strangled to death by Sun (on the client).

Java also has the problem of long startup times while the JIT is doing its thing. Javascript has always just started executing right away. Waiting a minute or two for a Java loading bar wasn't fun.

Re: What makes WebAssembly fast?

#203

Post by Klathmon »

petre wrote: post #184
ZenPsycho wrote: post #143

Earlier quoted context omitted.

browsers that support WASM will support ES6 natively. compiling ES6 to WASM would not be a good idea, since you would have to send a garbage collector and full dynamic language runtime down the pipe instead of just using the one in the browser. wouldn't you rather just run ES6 right in the browser instead of compiling it first at all?

If all major browsers support 100% of the spec and every implementation is bug to bug compatible with the others, yes, I would rather run ES6 directly in the browser. The problem is fragmentation and not supporting the whole spec -- some functions working in Firefox and Chrome and not implemented in IE/Edge or Safari.

Has any runtime anywhere had 100% compatibility with anything ever?

Re: What makes WebAssembly fast?

#204

Post by marcosdumay »

rkangel wrote: post #188
yumaikas wrote: post #180

Earlier quoted context omitted.

Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.

Lack of GC in WASM would make that difficult right now. But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.

GC is just something you implement on the language runtime.

Re: What makes WebAssembly fast?

#205

Post by marcosdumay »

bostik wrote: post #161
ncantelmo wrote: post #66

Earlier quoted context omitted.

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib. One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib…

What was the last time you wrote something that was 10MB after compiled to native code when optimizing for space?

Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).

Re: What makes WebAssembly fast?

#206

Post by thomasrognon »

Clubber wrote: post #200
kayoone wrote: post #137

Earlier quoted context omitted.

Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ? I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.

The only concerns I would have is I believe you have to debug the javascript rather than the typescript.

You can make the sourcemaps refer to the TypeScript code. I set breakpoints in TypeScript files and step through it all the time.

Re: What makes WebAssembly fast?

#207

Post by bluejekyll »

mort96 wrote: post #202
bluejekyll wrote: post #109

Earlier quoted context omitted.

Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS. It could have been JS, but it was strangled to death by Sun (on the client).

Java also has the problem of long startup times while the JIT is doing its thing. Javascript has always just started executing right away. Waiting a minute or two for a Java loading bar wasn't fun.

JavaScript hasn't always worked that way. My guess is that if Java had become the tool for this, then it's startup times would have been fixed. Pure speculation of course.

Re: What makes WebAssembly fast?

#208

Post by bluejekyll »

scriptproof wrote: post #164
bluejekyll wrote: post #106

Earlier quoted context omitted.

Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.

These people are probably over represented here else things like Node.js, Electron would have never existed - and be successful.

Electron is awesome. And with webassembly, I think electron will be even better. Electrons success is because it offers a single Dev experience across all major platforms, windows, macOS, Linux and the web.

It's a great container for reducing the work to deliver code across platforms.

JavaScript is a necessary evil right now; it's the least common denominator for delivery. I would probably choose typescript if I were starting a new app right now to target it, though I want to play with Rust and webassembly soon.

It's success is not bc of JavaScript; it's because it merges the cross platform Dev experience.

Re: What makes WebAssembly fast?

#209

Post by bluejekyll »

zurn wrote: post #199
aphextron wrote: post #139

My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript. Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iO…

JS provided that already without WebAssembly, no?

Asm.js was exactly what your talking about.

You can think of webassembly more like a common standard akin to the JVM specification. Anyone can implement the spec.

It's a formal definition of what people are doing with JS.

Re: What makes WebAssembly fast?

#210

Post by attractivechaos »

marcosdumay wrote: post #205
bostik wrote: post #161

Earlier quoted context omitted.

> If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib. One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib…

What was the last time you wrote something that was 10MB after compiled to native code when optimizing for space? Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).

Yes, I still remember the days when we could have core Linux experience on one 1.44MB floppy disk. This keeps reminding me how bloated most modern software are.
Post reply on HN