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

WebAssembly support now shipping in all major browsers

blog.mozilla.org

Post reply on HN
Print view View original

331–340 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#331

Post by rhabarba »

krapp wrote: post #326
rhabarba wrote: post #184

WebAssembly is not worth the effort unless it finally is supported by the LINK tag. Seriously, using JS to load a JS alternative is ridiculous.

Before HTML5 deprecated it, it was assumed that browsers would just supply plugins to support various scripting languages or whatever, which is why the tag had a type attribute. Unfortunately, integrating a new runtime like will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a differenc…

I consider it to be broken web design if a website requires JS to display text. I could live with a hard cut.

Re: WebAssembly support now shipping in all major browsers

#332

Post by tedunangst »

tptacek wrote: post #283
austincheney wrote: post #255

Earlier quoted context omitted.

> It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access I am not going to say never . It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority. Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security…

Which of the security concerns browser Javascript deals with do you think are intrinsic to the language, as opposed to the bindings the browser provides the language? If the security issues are in the bindings (ie: when and how I'll allow you to originate a request with credentials in it), those concerns are "portable" between languages.

Not sure if this is directly relevant, but there have been all sorts of type confusion bugs when resizing arrays, etc. Stuff in the base language. They exist independent of API, but merely because the language is exposed.

Re: WebAssembly support now shipping in all major browsers

#333

Post by api »

felipellrocha wrote: post #181
api wrote: post #162

Earlier quoted context omitted.

I dunno... React and React Native are nice. I would prefer to use those for UI but do everything else in C++14 or some other real language. The web stuff could just be the view.

Sure. But it would be nice to be able to cheese between go and python for the UI, as well.

I always cheese my UI. Mobile is the foot rub.

Re: WebAssembly support now shipping in all major browsers

#334

Post by boomlinde »

rl3 wrote: post #320
boomlinde wrote: post #163

Earlier quoted context omitted.

> 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…

> Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example).

That is essentially the same problem people implementing garbage collectors on real machines are facing. You have some memory and you have to implement the algorithms and data structures necessary to allocate and free it as necessary.

> Lua is very lightweight. Many GCs are non-trivial.

Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, while the latter only supposes an architecture where you can arbitrarily manage memory "manually". From what I understand, you just hand WASM an array of memory and it can do whatever it wants with it, since it's a linear bounded automaton.

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

The link seems to be addressing the use of VM-managed GC objects within WASM programs. That would certainly a nice feature, especially when it comes to interoperability with JS, but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.

Re: WebAssembly support now shipping in all major browsers

#335

Post by austincheney »

tptacek wrote: post #288
austincheney wrote: post #286

Earlier quoted context omitted.

It isn't due to the language but to context of known APIs provided to the language that can only be executed a certain way by the language. How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.

I really don't understand your example. Are you proposing a web server running inside the browser as a WebAssembly program, and the browser attempting to enforce same origin policy against that server? That doesn't make much sense.

Yep, it doesn't make sense and that is the problem. There is no reason why you couldn't write a web server in WASM that runs in an island inside the browser to bypass the browser's security model.

Re: WebAssembly support now shipping in all major browsers

#336

Post by scott_karana »

greenhouse_gas wrote: post #174
KeitIG wrote: post #34

A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and…

There's another reason why I want JavaScript in the browser to die: We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there. Why? It's simply too expensive to create a fast (and compatible) JS engine. If Web…

Chrome's V8 engine was actually written from scratch, unlike Webkit's JavaScriptCore (which descended from Konqueror/KJS, as you say). Google made a big deal about marketing this fact at the time. (1)

And while yes, Mozilla's Spidermonkey comes from the Netscape days, and Chakra in Edge descends from JScript in IE, plus aforementioned JavaScriptCore, each of those engines still evolved massively: most went from interpreted to LLVM-backed JITs over the years. I suspect that no more than interface bindings remain unchanged from their origins, if even. ;-)

(1) I can't currently find the primary sources from when Chrome released on my phone, but here's a contemporary secondary one: https://www.ft.com/content/03775904-177c-11de-8c9d-0000779fd...)

Re: WebAssembly support now shipping in all major browsers

#337

Post by untog »

holydude wrote: post #10

Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)

I beg to differ. The DOM is the problem, not JavaScript. Once other languages can interface with the DOM everyone will finally realise this.

Re: WebAssembly support now shipping in all major browsers

#338

Post by eighthnate »

holydude wrote: post #10

Can't wait for DOM interop and get away from JS on frontend. Seriously JS should not be the lingua franca of the web :)

People have been saying that forever. But it's so entrenched now that it'll take a gargantuan effort to get rid of it.

Re: WebAssembly support now shipping in all major browsers

#339

Post by rl3 »

boomlinde wrote: post #334
rl3 wrote: post #320

Earlier quoted context omitted.

> 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…

> Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). That is essentially the same problem people implementing garbage collectors on real machines are facing. You have some memory and you have to implement the algorithms and data structures necessary to allocate and free it as necessary. > Lua is very lightweight. Many GCs are non-trivial. Yes, but don't confuse the problem…

>Yes, but don't confuse the problem of implementing a garbage collector with the problem of implementing a system that can support a garbage collector. The former may be non-trivial, ...

In most cases it isn't non-trivial, and that's further compounded by the fact that the GC currently has to be part of the module payload at the moment.

If we're talking strictly implementation difficulty, then interop with VM-managed GC objects may in fact be more difficult; I'm certainly not an expert so I couldn't tell you.

>... but the lack of it is not a showstopper for implementing your own garbage collector as it has always been done.

Per the very first sentence of mine you quoted, I never said it was. It certainly is likely to be far from practical, however.

Also I suggest reading the sibling comment that Steve Klabnik replied with prior. The wasm host bindings proposal is now separate from the GC proposal.

Re: WebAssembly support now shipping in all major browsers

#340

Post by rrhd »

isaiahg wrote: post #134

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…

> In most user applications JavaScript is good enough or better

If you are willing to toss performance out the window.

Electron is just turning dev work into user headaches.

Post reply on HN