Live data from Hacker News

WebAssembly support now shipping in all major browsers

blog.mozilla.org

311–320 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#311
post #199

I'm not as excited for this as I used to be. In most user applications JavaScript is good enough or better. If it wasn't then we wouldn't be taking the browser to make desktop applications. Recently I decided to make a desktop app and asked around about the different UI libraries. The answer I keep getting is "just use electron and JavaScript". Why? Because love it or hate it the Dom is fantastic and simple for makin…

> will it even by worth it beyond a few specific applications? I'm sure if you sampled all developers the number that would say Javascript is their favorite programming language would be in a substantial minority. So if it makes it easier for developers to write client side code in their preferred language its worth it. That being said, I'm worried a bit. Javascript being awful has traditionally kept developers doing…

You should check some of the SO developer surveys. I think you'd be surprised...

https://insights.stackoverflow.com/survey/2017#technology-mo...

Re: WebAssembly support now shipping in all major browsers

#312

Earlier quoted context omitted.

And semicolons are optional in JavaScript, makes it whitespace sensitive I suppose.

Yes and no. The language specification requires the use of semicolons. If a semicolon is not supplied the interpreter will insert it for you. That magical insertion step is referred to as ASI. I don't remember if ASI is mentioned in the spec (as I don't think it is), but at the very least it is a de facto standard as missing ASI breaks the web. As stupid as all that sounds... semicolons are actually required to termi…

And yet somehow the web doesn't break when one programmer uses \r\n while another uses \n. What was your original point about line terminators in this context?

Re: WebAssembly support now shipping in all major browsers

#313

Earlier quoted context omitted.

Yeah, but WASM was supposed to democratise the web development not to do just server-side stuff. Without DOM and Web APIs you can't do much Web related.

> not to do just server-side stuff He didn't say anything about 'only server side stuff'. There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.

>> There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.

Even for that it doesn't work without some js. The promise was that you can use your favorite language for web development and that's not the case. WASM is now more about the integration with JS.

Re: WebAssembly support now shipping in all major browsers

#314

Earlier quoted context omitted.

> Edge is closed source, but I'm almost sure there's some old IE code in there EdgeHTML is a fork of Trident, so yes. That said, I'm led to believe there's about as much commonality there as there is between KHTML and Blink: they've moved quite a long way away from where they were. > It's simply too expensive to create a fast (and compatible) JS engine. I don't think that's so clear cut: Carakan, albeit now years out…

> Notably, though, nobody's tried to rewrite their DOM implementation wholesale Depending on your definition of "wholesale", the Edge team claims it took them 3 years to do exactly that: https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d...

Oh, yeah, that definitely counts. I was forgetting they'd done that. (But man, they had so much more technical debt around their DOM implementation than others!)

Re: WebAssembly support now shipping in all major browsers

#315

Earlier quoted context omitted.

Yeah, but WASM was supposed to democratise the web development not to do just server-side stuff. Without DOM and Web APIs you can't do much Web related.

There's tons of tooling written in JS for JS that doesn't need DOM access to work, for example.

If you talk about Node I would say that only proves my point that people go to great lengths to use their preferred language whenever possible. Tell them to use JS only for DOM stuff and wasm for things that don't need DOM. Nobody would prefers a FFI between wasm and js instead of plain wasm if given the option to choose.

Re: WebAssembly support now shipping in all major browsers

#316
post #91

Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on. Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer…

I'd like to interject for a moment here, and pitch my idea about what I call the "Web 4.0". It's basically a binary equivalent of HTML, without the many inconveniences of HTML for content providers. Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents via WebGL. This way, adblocking becomes impossible, as the actual content and ads are within the same opaque WebGL framebuffer. Stealing copyrigh…

Just like the good old days with sites built in Flash :)

Re: WebAssembly support now shipping in all major browsers

#317
post #258

Earlier quoted context omitted.

When DOM access comes, all my js will hit the round file.

As much as I dislike JS, my experiences with React Native (JS but largely native UI elements) and Electron (JS with some native elements, but largely HTML+CSS) has convinced me that that HTML+CSS is my real (performance and battery life) enemy, with JS a significant but distant second. I look forward to better UI kits that just draw to a Canvas-like surface or something, ideally without needing an HTML+CSS engine at…

What do you consider a better alternative? A lot of people love to hate on HTM+CSS, but it's actually fairly powerful. I've been trying out a lot of native UI toolkits, and they're all as quirky and confusing as web tech. I'd agree that there's tons of room for improvement, but any UI tookit will need to make certain tradeoffs and deal with complex layouts and compositions.

Flexbox and grid help a lot with app-style layout.

Re: WebAssembly support now shipping in all major browsers

#318
post #102

Earlier quoted context omitted.

We're still a long ways off from garbage-collected languages inside wasm. That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.

> That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I felt like I should respond to this, too. It's not, but it is not unreasonable to object to implementing new ways for browsers to hog resources pretty much at the hosts' discretion. In this case it can be argued that it's poor use of technology to implement it in the browser. On a similar basis, one might argue that it's…

I understand your point, and admittedly I have many of the same concerns.

That said, some of us have legitimate uses for said dynamite, pyromaniac infants be damned.

Re: WebAssembly support now shipping in all major browsers

#319

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not havi…

> Unfortunately SIMD is still not supported on any browsers Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?

Not really portable. Even x86 has lots of variation between supported operations and vector length. ARM similarly has variations between ARM versions. At least for the abandoned JS SIMD effort, they stuck to the least-common-denominator SIMD (SSE1/NEON-armv7), but it was still good for a noticeable speedup in many applications.

Re: WebAssembly support now shipping in all major browsers

#320
post #102

Earlier quoted context omitted.

We're still a long ways off from garbage-collected languages inside wasm. That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.

> We're still a long ways off from garbage-collected languages inside wasm. I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua

>I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?

Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial.

Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.

See: https://github.com/WebAssembly/design/issues/1079

Post reply on HN