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

181–190 of 238 posts

Re: What makes WebAssembly fast?

#181

Post by coldtea »

robotresearcher wrote: post #105
coldtea wrote: post #69

Earlier quoted context omitted.

> Nothing to install Modern app stores like the Mac App Store make installing an one click affair. It will take me more clicks to login to their Word website... Also, "nothing to install" means "nothing to own". > no updates There will still be updates, only I won't be controlling them, and I wont be able to stick with an older version. Besides, it has been ages since updates for apps have been totally painless (e.g.…

None of these things are true about MS Office (native - not online 365) right now, which was the specific subject this sub-thread.

You seem to have totally missed what the "specific subject of this sub-thread is".

A quick reminder from just the parent comment above to which we're answering: "Imagine MS Word is running in your browser without them having to rewrite it in JS!".

That is, we're not talking about the native MS Office "right now".

Re: What makes WebAssembly fast?

#182

Post by stupidcar »

cm2187 wrote: post #166
ZenPsycho wrote: post #140

Earlier quoted context omitted.

no, WASM will not replace JS unless somehow, overnight, the idea of downloading 30mb of compiled runtime libraries to read an inaccessible-to-screenreaders news article becomes appealing. but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript. what wasm competes with is flash games, ins…

In all fairness, javascript should have never even been required to display a news article. Javascript makes up for a lot of the shortcomings of HTML.

JS isn't required to display a news article, and never has been. You can make a fast, beautiful and modern news site using only HTML and CSS, without a byte of JS.

Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS.

99.9% of the JS will be advertising, analytics, and tracking. People understand that these sites are tracking them, but I think most people have not idea just how much tracking is going on. Major news sites have hundreds of tracking libraries loaded per-page. That is the only reason they are slow.

Re: What makes WebAssembly fast?

#183

Post by tannhaeuser »

I realize this is about discussing technical merit, but I'd like to share a less naive view of what WebAss does to the web (eg. DRM, making ad-blockers impossible, etc.) over in the [other thread] (https://news.ycombinator.com/item?id=13755370).

Right now, the discussion evolves around finding fecalia-/coprophilia-inspired names for the WebAss ecosystem. Can't wait until America Awakens to contribute :)

Re: What makes WebAssembly fast?

#184

Post by petre »

ZenPsycho wrote: post #143
petre wrote: post #135

Earlier quoted context omitted.

I don't hate JS but would rather write my web codebase in something else, something that has a standard lib for instance. ES6 is also a transpile to JS language on the browser. The main problem is that we are stuck with ancient JS on the browser and WASM could fix that. Wouldn't you rather conpile ES6 to WASM instead of JS?

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.

Re: What makes WebAssembly fast?

#185

Post by unwind »

scriptproof wrote: post #163
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…

You can write wasm. It is the official shortcut (not an acronym). Source: http://webassembly.org/

*Abbreviation (https://github.com/WebAssembly/design/issues/980).

Re: What makes WebAssembly fast?

#186

Post by oneweekwonder »

v413 wrote: post #175
tonyedgecombe wrote: post #171

Earlier quoted context omitted.

It could be another target for TypeScript though.

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#).

Re: What makes WebAssembly fast?

#187

Post by lomnakkus »

pdkl95 wrote: post #113
daurnimator wrote: post #70

Earlier quoted context omitted.

> For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?

> who wants these to be in the browser Anybody that resents the user having ultimate control over the User Agent . A game in e.g. the Unity engine isn't important. Instead, there are a lot of people that would love to replace their (easily adblockable) web page with a small opaque binary that contains freetype, custom layout/UI library, and maybe "drm"-like obfuscation. You don't need the DOM if you intent to render…

That's an interesting idea, but I'm not sure if it's got any legs for "mostly-content" sites given the inherent unsearchability of that approach.

Re: What makes WebAssembly fast?

#188

Post by rkangel »

yumaikas wrote: post #180
v413 wrote: post #173

Earlier quoted context omitted.

JS will not compile to WASM.

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.

Re: What makes WebAssembly fast?

#189

Post by lomnakkus »

randomdata wrote: post #124
int_19h wrote: post #58

Earlier quoted context omitted.

They decided to use it because it let you add things like drop-down menus (and falling snowflakes!) to your website, which made it look better than your competitor's website. Syntax was just the hoop to jump through to achieve that, and a very minor one at that. I doubt it would have made any difference.

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.

Re: What makes WebAssembly fast?

#190

Post by brlewis »

fiddlerwoaroof wrote: post #133
brlewis wrote: post #39

Earlier quoted context omitted.

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.

Because of macros lisps are more resistant to bad APIs than other languages, in my experience.

That is a very good point.
Post reply on HN