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

W3C recommends WebAssembly

w3.org

Post reply on HN
Print view View original

211–220 of 350 posts

Re: W3C recommends WebAssembly

#211

Post by shadowgovt »

EvanAnderson wrote: post #129
6gvONxR4sf7o wrote: post #69

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

Well, someone attempting that will have a long row to hoe to get the thing working with the needs of networks with different performance standards, useragents with different screen structures, and users with different accessibility requirements.

Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.

Re: W3C recommends WebAssembly

#212

Post by thosakwe »

EvanAnderson wrote: post #129
6gvONxR4sf7o wrote: post #69

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

> Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser

Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?

Re: W3C recommends WebAssembly

#213

Post by sproketboy »

simias wrote: post #107
6gvONxR4sf7o wrote: post #69

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features…

> proper UI toolkit like JavaFX

FTFA

Re: W3C recommends WebAssembly

#214

Post by sitkack »

tmountain wrote: post #3

What's the horizon for WebAssembly capable browsers gaining enough marketshare that it becomes a viable compilation target?

WebAssembly is very widely supported, for systems that don't or won't have support one can use wasm2js from the binaryen project to convert .wasm to JavaScript.

https://github.com/WebAssembly/binaryen/blob/master/src/tool...

Re: W3C recommends WebAssembly

#215

Post by azakai »

maeln wrote: post #118
strictnein wrote: post #61

Earlier quoted context omitted.

A binary format is no more obfuscated than minified JS? What now? Going to need some clarification on how that's the case.

WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob. So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.

There is a difference in degree, though. Unminified JS is usually easier to read than wasm text, in general.

One practical factor: I often debug wasm files by compiling them to JS first.

At least wasm has structured control flow, which helps a lot. I wish wasm had even more readability features, personally.

Re: W3C recommends WebAssembly

#216

Post by [deleted] »

neckardt wrote: post #28
mbrock wrote: post #18

Earlier quoted context omitted.

Doesn’t that reasoning also imply that GNU and Linux are awfully opaque and not free nor open, since they are typically distributed as binaries?

No, because GNU and Linux are bound by license restrictions which require the unobfuscated source code to be made available. If all websites made their source available as well as distributing the binary, there wouldn't be a problem.

[deleted]

Re: W3C recommends WebAssembly

#217

Post by BlueTemplar »

jt2190 wrote: post #192
6gvONxR4sf7o wrote: post #69

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

> I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. What, exactly, is "content"? Are binary formats content? (Audio, Video, etc?) Are textual comments and notes on other text content, or is only the work being commented on content? Are languages that rely on unicode encodings content? Must content be static or can it change frequently, even second by second? (Stock quo…

No, the browser should not be used for all content. It's not designed for it, and we already have the OS itself for that, why do you want to add needless levels of abstraction??

Re: W3C recommends WebAssembly

#218

Post by EvanAnderson »

shadowgovt wrote: post #211
EvanAnderson wrote: post #129

Earlier quoted context omitted.

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

Well, someone attempting that will have a long row to hoe to get the thing working with the needs of networks with different performance standards, useragents with different screen structures, and users with different accessibility requirements. Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.

The inner browser doesn't need to be a general purpose browser. It just needs to render the site-owner's content, run their scripts, etc. Once there's an API for WASM to manipulate the DOM accessibility becomes easier.

Re: W3C recommends WebAssembly

#219

Post by camgunz »

lsalvatore wrote: post #173
danShumway wrote: post #116

Earlier quoted context omitted.

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS cla…

Hey, I'm a full stack eng and while I think React is net good, I don't think that's the same thing as "DOM/CSS is bad".

Writing a web application is different than writing a web document (or set of documents). I think what people are anxious about here is that many, if not most, sites are documents or sets of documents, but FE trends are "everything is an app", which leads to difficult situations like "in order to talk to my mom on the Internet, I essentially have to buy into the surveillance state".

We haven't done a good job at letting people do only what they want on the web, because so much of the web has been built by companies with ulterior motives. What people are worried about here--and this is true whether we're talking about WASM, Flash, Java Applets, Silverlight, etc.--is this is a giant leap down the road to a co-opted web, devoid of user choice and controlled entirely by moneyed or state interests.

Personally I feel like this happened a long time ago, so WASM doesn't worry me any more than I already am. But I think it's important to keep in mind more is at stake here than CSS-in-JS, or any one FE's career.

Re: W3C recommends WebAssembly

#220

Post by cjbprime »

jandrese wrote: post #80
strictnein wrote: post #61

Earlier quoted context omitted.

A binary format is no more obfuscated than minified JS? What now? Going to need some clarification on how that's the case.

I guess he's saying that an unminifier tool is effectively no different than a decompiler, and both are basically unreadable without it. That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the…

There are certainly wasm decompilers -- wasm2c, wasm2js, etc. You also have access to the browser's JS debugger for breakpoints, line by line execution control, dumping wasm's linear memory.

I haven't written any productive WebAssembly but I play Capture The Flag competitions, and it's become frequent for a wasm reverse engineering challenge to be thrown in. The tools are good enough to make that tractable, even for non-experts in wasm like me.

It helps a little that it's a stack-based rather than register-based VM. Usually more of the intent of code is preserved that way. It's like reversing a JVM class, rather than like reversing a native binary.

Post reply on HN