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

281–290 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#281

Post by askvictor »

austincheney wrote: post #263
askvictor wrote: post #260

Earlier quoted context omitted.

JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code. A good programmer can write in anything, but it's the not-so-good programmers that you have to worry about.

Agreed. To be a strong candidate for a web scripting language you need three things: * native lexical scope. This is how all web technologies work. * Minimal reliance on white space as syntax. The language needs to be portable. Overloading white space as syntax makes a language more brittle, particularly in distribution. * Immediate interpretation without a prior static compile step. This keeps the code open to exami…

While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory.

How about Lua?

Re: WebAssembly support now shipping in all major browsers

#282

Post by tptacek »

pavlov wrote: post #241
gsnedders wrote: post #217

Earlier quoted context omitted.

I think Blink's LayoutNG project and Servo both show that you can rewrite your layout implementation (and Servo also having a new style implementation, now in Firefox as Stylo). I think both of those serve as an existence proof that it's doable.

It's doable if you already have a large team of experienced web engine development experts, a multi-million budget and years to spend on just planning. Implementing an open standard shouldn't be like this. Even proprietary formats like PDF are much simpler to implement than CSS.

A minimal, 80% PDF, maybe. A complete PDF? No.

Re: WebAssembly support now shipping in all major browsers

#283

Post by tptacek »

austincheney wrote: post #255
sli wrote: post #244

Earlier quoted context omitted.

I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense. It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folk…

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

Re: WebAssembly support now shipping in all major browsers

#284

Post by lern_too_spel »

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…

If the issue is JavaScript, what explains the explosion of JavaScript engines? I agree that JavaScript is a cancer whose growth should be addressed, but implementation complexity isn't a reason.

Re: WebAssembly support now shipping in all major browsers

#285

Post by WorldMaker »

gsnedders wrote: post #214
greenhouse_gas wrote: post #174

Earlier quoted context omitted.

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…

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

Re: WebAssembly support now shipping in all major browsers

#286

Post by austincheney »

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.

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.

Re: WebAssembly support now shipping in all major browsers

#287

Post by ninkendo »

__s wrote: post #267
md224 wrote: post #185

Earlier quoted context omitted.

My CS background is a bit weak... is the hypothetical Metal architecture he describes supposed to be satire or actually a good idea?

Implement a WASM JIT in kernelspace & you don't have to have a userspace while still having hot code hopefully optimized to remove bounds checking. Now all your programs are WASM modules & we can replace your CPU with some random architecture that doesn't have to care about supporting more than ring0. Oh why not implement a nearly-WASM CPU? Probably just change branches to GOTO. Now the only program people care about…

There’s prior art for this too, Microsoft started a research project called Singularity that was essentially a kernel that only executed .NET bytecode, and had similar advantages (everything in ring0, no syscall overhead, etc.)

It died pretty unceremoniously though.

Re: WebAssembly support now shipping in all major browsers

#288

Post by tptacek »

austincheney wrote: post #286
tptacek wrote: post #283

Earlier quoted context omitted.

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.

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.

Re: WebAssembly support now shipping in all major browsers

#289

Post by Houshalter »

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…

There are a lot of better image compression formats than jpeg and png. With wasm you could have a very fast client side decompression and save a ton of bandwidth.

Re: WebAssembly support now shipping in all major browsers

#290

Post by austincheney »

askvictor wrote: post #281
austincheney wrote: post #263

Earlier quoted context omitted.

Agreed. To be a strong candidate for a web scripting language you need three things: * native lexical scope. This is how all web technologies work. * Minimal reliance on white space as syntax. The language needs to be portable. Overloading white space as syntax makes a language more brittle, particularly in distribution. * Immediate interpretation without a prior static compile step. This keeps the code open to exami…

While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory. How about Lua?

A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
Post reply on HN