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

211–220 of 238 posts

Re: What makes WebAssembly fast?

#211

Post by themihai »

vonklaus wrote: post #165
themihai wrote: post #144

Earlier quoted context omitted.

That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e…

They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.

The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.

Re: What makes WebAssembly fast?

#212

Post by KurtMueller »

charlieflowers wrote: post #154
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…

True. I agree with it all. However, by then, TypeScript might be so darn good that people choose to keep going with it! It really does have a better type system than C# in a lot of ways.

F# has an even better type system :)

Re: What makes WebAssembly fast?

#213

Post by zeveb »

brlewis wrote: post #39
zeveb wrote: post #29

Earlier quoted context omitted.

They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)

Pure Scheme would not be sufficient. You need at least DOM-handling libraries. And if those libraries were poorly designed, then people wouldn't cotton onto the advantage quickly. Look at DSSSL.

> You need at least DOM-handling libraries.

Did you see the '(set! (inner-html (get-element-by-id document "demo")) "Hello JavaScript!")' bit? That's DOM-handling in Scheme. Not a really great API, but it's not terrible either.

Re: What makes WebAssembly fast?

#214

Post by aphextron »

themihai wrote: post #211
vonklaus wrote: post #165

Earlier quoted context omitted.

They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.

The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.

>JS works just fine in browser.

Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#.

I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.

Re: What makes WebAssembly fast?

#215

Post by charlieflowers »

throwaway010317 wrote: post #174
charlieflowers wrote: post #154

Earlier quoted context omitted.

True. I agree with it all. However, by then, TypeScript might be so darn good that people choose to keep going with it! It really does have a better type system than C# in a lot of ways.

Could you please elaborate on how TypeScript's type system is better than C#?

Mostly, for me, it comes down to union types, intersection types, the ability to disallow implicit nulls (meaning null must be declared as a valid value at the type level, and therefore cannot creep in unexpectedly), string literal types, discriminated unions (most of the good stuff from algebraic data types), and index types.

All demonstrated here: https://www.typescriptlang.org/docs/handbook/advanced-types....

The result is a very nice, expressive way to state your types and get maximal benefit from the type checker.

Re: What makes WebAssembly fast?

#216

Post by aphextron »

nothrabannosir wrote: post #178
throwaway010317 wrote: post #174

Earlier quoted context omitted.

Could you please elaborate on how TypeScript's type system is better than C#?

I disagree with OP, but two interesting corollaries of TS type semantics are its strong type inference and structural typing: Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}]; Automatically gets you x: "Array of {x : number, y: string }". And if you declare the same type somewhere else, as long as they're "structurally equivalent" (i.e. same x and y types) you can actually use them interchangeably. You can't do that e.g…

> You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

Agreed. Duck typing is a killer feature. I can't say how many time's I've rolled a new class for no reason other than data structuring, which would have been far preferable as something just defined inline.

Re: What makes WebAssembly fast?

#217

Post by randomdata »

lomnakkus wrote: post #189
randomdata wrote: post #124

Earlier quoted context omitted.

You honestly believe that Javascript would have been equally successful if it had shared similar syntax to, say, Brainfuck? Especially given the alternatives that were available at the time? If syntax doesn't matter, I guess so, but I'm not sure I'm convinced.

There's a pretty big difference between Brainfuck and Scheme. Of course syntax matters , but parent wasn't asserting that it doesn't matter at all .

There is a big difference, but since we're talking about any language "deemed not good enough", a language similar to Brainfuck definitely applies, and perhaps is the shining example.

The original suggestion was that people would use Javascript, or any other language in its place, simply by virtue of it being the only option. I argue that the wrong language would hamper adoption, and eventually some other language – like, say, VBScript which came only 6 months later – would have taken over.

Javascript persisted, and eventually completely dominated, because it was good enough. A language not good enough would have not had the same success, even given the otherwise same environment to grow up in.

Re: What makes WebAssembly fast?

#218

Post by dcherman »

marcosdumay wrote: post #204
rkangel wrote: post #188

Earlier quoted context omitted.

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.

Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.

Re: What makes WebAssembly fast?

#219

Post by readittwice »

oneweekwonder wrote: post #186
v413 wrote: post #175

Earlier quoted context omitted.

Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.

Really? Anders Hejlsberg is in charge of TypeScript and a apt compiler architect with a proven track record(turbo pascal, delphi, .net/C#).

Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines. In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily. In addition the JIT can also make use of hand-written assembly if it is needed for best performance.

I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.

Re: What makes WebAssembly fast?

#220

Post by joshuahutt »

aphextron wrote: post #214
themihai wrote: post #211

Earlier quoted context omitted.

The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.

>JS works just fine in browser. Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#. I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.

> a real language like C#

While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice.

https://blog.codinghorror.com/the-principle-of-least-power/

Post reply on HN