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

101–110 of 350 posts

Re: W3C recommends WebAssembly

#101

Post by Already__Taken »

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 worry more about the war against the URL than js progression. a simple way to send state to people is incredible.

Re: W3C recommends WebAssembly

#102

Post by krapp »

bogwog wrote: post #88
krapp wrote: post #67

Earlier quoted context omitted.

Those aren't technically binaries, as much as people want to cling to the metaphor of javascript as "bytecode" and pretend no distinction exists between the two.

> and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?

Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.

Re: W3C recommends WebAssembly

#103

Post by lukebitts »

remcob wrote: post #74
lukebitts wrote: post #59

Earlier quoted context omitted.

Maybe I’m misunderstanding something but WASM is meant to be compiled from other languages and that source is lost, unlike minified javascript, isn’t it?

Would you consider the source lost if the (minified) javascript was compiled from TypeScript?

I would. And fair enough, I think the web closed around me and I didn't even realize it. But we are all doing ok so far, so I supose wasm won't be that bad either.

Re: W3C recommends WebAssembly

#104

Post by danShumway »

hombre_fatal wrote: post #57
dkersten wrote: post #20

Earlier quoted context omitted.

In my opinion it’s been a long time since direct access to Javascript has been useful. Yes you can unminify javascript but it’s still more work than most people will go through (especially if the code was generated by a compile to javascript language)so for most people things aren’t really changing that much

I don't even think source code access is the most important part of the browser's dev console. Consider the network tab instead, being able to see exactly where your bandwidth is being spent and why. This to me makes the browser vastly preferable to native apps. I didn't realize that the desktop app I use to easily translate languages[0] sends every keystroke to Google Analytics until I had to bother installing a pro…

Totally agreed -- and I don't think WASM will change any of that.

The good parts of the web in terms of debugging is the separation of concerns -- having separate interfaces for CSS, HTML, network requests, and the DOM, and having each of those interfaces be relatively inspectable.

I am a little worried about frameworks that target WASM spitting everything onto a Canvas, bypassing HTML and CSS (coughQt*cought). That would be a substantial loss for the Open web. But I don't lose any sleep over the idea of replacing Javascript.

Re: W3C recommends WebAssembly

#105

Post by BlueTemplar »

harrygallagher4 wrote: post #97
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 think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a sit…

And this is why if blocking the "web"site JavaScript breaks the "web"site itself, then it never was a website to start with!

(Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)

Re: W3C recommends WebAssembly

#106

Post by krapp »

ajross wrote: post #91
duxup wrote: post #81

Earlier quoted context omitted.

That sounds like the use case would be to insert some WASM component (that is a big heavy application / operation) into traditional web application framework as needed. Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;) Of course th…

Really the only available use case is inserting a wasm component into a traditional web application framework. Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM. This is all still traditional web development. It's just a way to target other runtimes to a sandbox i…

>Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

Incorrect. WASM was designed from the beginning to be run both on and off the web[0], and native clients already exist[1].

[0]https://webassembly.org/docs/non-web/

[1]https://github.com/mbasso/awesome-wasm#non-web-embeddings

Re: W3C recommends WebAssembly

#107

Post by simias »

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.

Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know.

If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble.

To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.

Re: W3C recommends WebAssembly

#108

Post by voxic11 »

bogwog wrote: post #84
dmvinson wrote: post #60

Earlier quoted context omitted.

I respect your point and semi-agree, but as someone who ran a small business in high school that usually involved reverse engineering obfuscated Javascript, I think you're overstating how hard it is to follow the logic of Javascript blobs. Yes, whole program flows can be insanely difficult to follow, but narrowing in on the logic of key functions is often what one needs when trying to learn from other's code.

So are you saying that reverse engineering javascript is easy? Or that it's easier than reverse engineering wasm? I don't know much about web assembly, but x86, which is much more complicated with thousands of instructions, has been successfully reverse engineered basically since forever. There are decompilers that can automatically reconstruct source code in C or C++ from a binary blob. Compared to javascript, the b…

But if the WASM was compiled from javascript or some other language that isn't very C-like then the de-compiled C or C++ code is going to be very difficult to follow.

At the very least with obfuscated javascript you are going from js => js => js. Rather then from js => WASM => C++.

Re: W3C recommends WebAssembly

#109

Post by jsjolen »

eeZah7Ux wrote: post #50
markstos wrote: post #8

This is bad for frontend JavaScript being "open" for review, right? Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work. Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

The advertisement industry is huge and it's the driving force behind Google and many other companies. webassembly is encouraging websites to dump megabytes of binary code in browsers. Obfuscated, analysis-resistant code to ensure that people cannot disable ads and tracking. It's appalling that we are accepting this.

I'm not sure that WASM actually is that analysis-resistant. It's more high-level in some aspects than the JVM bytecode for example.

For example, it doesn't support arbitrary computed goto:s. Instead it supports block-based control flow, where the semantics can either create blocks or jump out of them to lower down blocks. This makes it possible to construct a CFG statically, which isn't possible if it did support arbitrary computed goto:s.

Re: W3C recommends WebAssembly

#110

Post by reificator »

mdszy wrote: post #52
duxup wrote: post #19

Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on…

When was the last time you were able to unminify a javascript file that you wanted to investigate and were able to make sense out of it?

Within the last month or two, certainly.

You have to be willing to edit it, start renaming variables to describe what they hold, rename them again if they get something unexpected assigned, rename functions once you have a good idea of what they're trying to do, and repeat until everything has a name.

Post reply on HN