Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

231–240 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#231

Earlier quoted context omitted.

> I guess you missed all those sites using Flash, Silverlight, Applets, WebStart, ClickOnce and many other plugins. I did actually, because most aren't around any more. Even so, I was talking about sites that purely use the html canvas to draw. There is nothing preventing websites from being built like that right now, so I don't see how webasm will make much of a difference.

You're missing it... Web Assembly would allow devs to build apps without any html or javascript or css. The UI construct could be WPF/XAML or even WinForms like tech or something new. Scripting and CSS would be entirely unnecessary. A lot of businesses would love nothing better than to dump the Jedi-like skills of the scripting developers and trade that for mundane forms skills.

you appear to be missing the fact that there is no widespread desire by web developers or businesses to convert their webdev stack to an application development stack.

HTML, javascript and CSS are easier than C, C++ or Rust. Writing a website in HTML/CSS/JS and updating a website in HTML/CSS/JS are vastly simpler than writing a graphical application then rewriting and recompiling it.

As with Flash, WebAssembly will be implemented as fully integrated apps where it makes business sense, which will probably be a limited number of cases, such as graphics or media delivery. Everywhere else, it will either not be implemented at all, or be used alongside JS in the existing web.

Re: Introduction to WebAssembly: why should we care?

#232
post #89
post #59

Earlier quoted context omitted.

Admittedly, I'm looking at this situation from within my comfortable bubble of a GNU system in which I only use software for which I have a source-to-binary mapping through GNU Guix. JavaScript applications are the exception in my environment and they threaten to burst that shiny bubble. Aside: I really think that the terms "open" and "closed" are imprecise and confusing, which is why I avoid them. With deterministic…

I guess I mostly agree. I just think that theoretically it should be able for web applications to be open source just as much as our GNU systems are, and that it's a shame that in practice, this is often not the case.

The javascript part of web applications are pretty fairly open source. Most libraries are OS licensed (probably MIT) and include plain source along with the minified versions that can be verified, forked, modified or redistributed as desired. Any browser allows the source of any page to be viewed or saved locally - and I would bet dollars to donuts that even with minifiers, most javascript running on the web is still plaintext. Browsers allow turning off javascript entirely, or overriding it with custom scripts using plugins like Greasemonkey, which is a lot more freedom than most native apps provide.

The only problem from a free software perspective is that not every line of javascript in the universe is explicitly linkable to a GPL license in a static file, as one would find in, say, a C library. But in every other way (I would argue, in every way that really matters) javascript in the browser is either as free or more free than other languages in their respective environments.

Re: Introduction to WebAssembly: why should we care?

#233
post #32
post #5

I know a lot of people long for the days when the web was just text and a few JPGs. I personally am waiting for the web to become a rich, ubiquitous, standardised application delivery platform that works on any device. I think web assembly adds to the richness while being fairly standardised, so I welcome it!

> richness That includes the problematic features like tracking. Running software from random sources is dangerous in ways we are only beginning to understand.

Let’s keep in mind that software running in a browser is sandboxed, using standardized APIs, and isn’t nearly as privileged as software running directly on your desktop.

Re: Introduction to WebAssembly: why should we care?

#234
post #27

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don'…

I think the idea that "access to source code == freedom" is out of date. Imagine someone gave you a thumbdrive with the complete source code for all of Facebook's products, build system, infrastructure, everything that's checked into their repositories. They also gave you legal carte blanche to do as you feel with it. Would you be free of Facebook? Would you be able to do anything useful with at all? No. The problem…

> Would you be free of Facebook?

Are you kidding?

The source code for the full toolset would reveal how they analyze their data, what they find relevant (even merely based on which types of tools exist and which don't), how access is defined for various categories of employees to access that data, differences between what they claim about those capabilities and the actual infrastructure, problems they've had which they've attempted to fix in changes to the code, how they set prices to sell access to advertisers, how their frameworks to respond to lawful requests for user data from government agencies work (hell, even inferences about which government agencies they respond to), whether or not they've made serious attempts to curb the fake news problem, a full understanding of the ways in which they track people who don't have a facebook account across the web, and probably a whole host of other enlightening details about their entire operation.

I'm sure there are people who can make quite accurate guesses about how all of that probably works without looking directly at the code. But if the Snowden leaks tell us anything it's that a handful of security specialists being able to deduce something is completely different that a critical mass of programmers being unable to deny that a problem exists. Access to that code would certainly give developers of FLOSS privacy/security software a better idea of how to protect their users' privacy.

Re: Introduction to WebAssembly: why should we care?

#236
post #202
post #16

Earlier quoted context omitted.

We already had them, WebAssembly adds little to Flash, Java applets, Oberon Juice, ActiveX, Silverlight, other than a format that makes all browser vendors happy. I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash.

>other than a format that makes all browser vendors happy No small feat!

Sure it is. Find a way to lock down all user access and demand that Google and Microsoft get paid or your data gets it. Mozilla will do whatever Google says. Apple doesn't care as much, a new core tech means a new generation of iPhone/iPad/iPod/iHateThisNamingConvention, which means more money for them.

Re: Introduction to WebAssembly: why should we care?

#237
post #111
post #3

We shouldn't. All the nonsense we're trying to cram into the Web is making it harder to justify connecting to it. I long for the days when simple images and text were the norm. Nowadays, I need to have and devote constant system resources to a tracking-blocker, cookie-blocker, an ad-blocker, a script-blocker, a separate javascript-blocker, and a who-knows-what-else-blocker, just to do the things I want to do; let alo…

Okay, say every browser had a built-in tracking, cookie, ad, script blocker etc. How would you propose websites then make any money?

I don't. I literally don't care about them making money, so I can't propose any method. My problem is that they demand the monetization of the Web and crud up my PC. My solution is 'block everything but text and images.'

Re: Introduction to WebAssembly: why should we care?

#238
post #172

Earlier quoted context omitted.

> Anyone can run their C trough minifiers I don't know of any programs that are distributed as C to be run directly like javascript. > Machine code donesn't move needle of obfuscation much at all There are two very fundamental mistakes you are making when equating webasm to raw processor instructions. The first is that webasm even its binary format is still organized in a abstract syntax tree, so its instruction are…

> I don't know of any programs that are distributed as C to be run directly like javascript. https://github.com/kripken/emscripten

That's not what emscripten does. It compiles C to javascript and the program is distributed as javascript, not C.

Re: Introduction to WebAssembly: why should we care?

#239
Quoting from the article: "It will make developing for the web easier and more efficient."

Um .. no. It will make code execute faster but it will be more work to write and maintain.

For most of the daily bread-and-butter code that we produce, speed is not awfully important but clarity is. In this equation, you gain a great advantage from stuff like garbage collection, functional programming, and a well equipped package manager, i.e. Javascript is a pretty good choice (and Typescript an even better choice).

On the other hand, if you're writing very specialized algorithmic code which will be executed a very large amount of times, then WASM and fine tuning is in place. As cool a technology as WASM may be, a very small fraction of our code is like that.

My prediction is that WASM will find its place, mainly within some of the more popular libraries available on npm. If there is anything to gain from rewriting, say, parts of ReactJS in WASM then it will eventually be done. But it will be totally transparent to the user of said library.

Taking a view at the server side landscape is also instructive. There is a plethora of languages which execute faster than JS, yet nodeJS thrives. So it doesn't seem like people are eager to ditch JS. Hater's gonna hate, of course.

Re: Introduction to WebAssembly: why should we care?

#240
post #232
post #89

Earlier quoted context omitted.

I guess I mostly agree. I just think that theoretically it should be able for web applications to be open source just as much as our GNU systems are, and that it's a shame that in practice, this is often not the case.

The javascript part of web applications are pretty fairly open source. Most libraries are OS licensed (probably MIT) and include plain source along with the minified versions that can be verified, forked, modified or redistributed as desired. Any browser allows the source of any page to be viewed or saved locally - and I would bet dollars to donuts that even with minifiers, most javascript running on the web is still…

Don't forget that there's also a large server component that's usually closed source :)
Post reply on HN