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

Introduction to WebAssembly: why should we care?

tomassetti.me

Post reply on HN
Print view View original

131–140 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#131

Post by brunoc »

sidlls wrote: post #128
brunoc wrote: post #127

> JavaScript has a bad reputation, but in reality is a good language for what is was designed for: quickly write small scripts. That's a little condescending, considering the amount of non-trivial, critical applications written in JavaScript. And it ignores the progress made on the language and tooling of the last oh i don't know, 20 years.

Non-trivial, sure. Critical? In what sense?

Critical for the survival of many businesses? Dealing with important data and processes? In that sense. Not in a system-critical kind of sense (kernels, etc).

I mean I'm glad that when I call 911 the dispatching system probably isn't written in JavaScript, but it's likely that there's a web ui somewhere in there. Police cars too, run web applications on those touchscreens.

I'm definitely aware of JS shortcomings, having had to deal with them for many years. I just found that particular quote to be a little snarky, and outdated.

Re: Introduction to WebAssembly: why should we care?

#132

Post by AboutTheWhisles »

pjmlp wrote: post #2

I am betting when WebAssembly gets mature all Web sites will look like Flash, just coded on the framework of choice, thus finally making the browser just yet another VM.

What does webasm enable that would cause such a massive difference in how people create web pages? Everything it does could be done now with javascript or asm.js, all webasm does is enable the same things to run faster.

I can't think of a single site that works like you are saying, yet webasm would only be a 2x-8x speedup over existing techniques.

Re: Introduction to WebAssembly: why should we care?

#133

Post by cm2187 »

olavk wrote: post #95
loup-vaillant wrote: post #72

Earlier quoted context omitted.

Problem is, adding to the bl… sorry, richness , doesn't remove the old cruft. How about having an application platform that would be just an application platform? No HTML, no CSS, no built in multimedia. Just a VM, a viewport, audio, and inputs (and local storage if the user allows it).

We already tried that - Java Applets. Silverligt was the same idea. And Flash I guess? All attempts failed in the marketplace. It turns out using higher level standards like HTML, CSS, URL's etc actually provide a a lot of value.

They didn't fail in the market, they were actually quite popular (maybe not java, but flash definitely). It is just that Apple killed them by not making them run on mobile. That's more of a case of a major player strong forcing the market.

Re: Introduction to WebAssembly: why should we care?

#134

Post by steveklabnik »

charlysl wrote: post #104

"Its development is backed by people at Mozilla, Microsoft, Google and Apple." It seems this is for real then? JS has had a surprisingly long life actually given its original use cases, and I understand the objections to wasm, but I guess that something like this was inevitable given how big the browser is as a platform and how web apps have been steadily fattening on the back of a suboptimal language, which, if this…

It's probable you can already use it on mobile today. I have. https://caniuse.com/#feat=wasm

Re: Introduction to WebAssembly: why should we care?

#135

Post by AboutTheWhisles »

pdkl95 wrote: post #68
moron4hire wrote: post #61

Earlier quoted context omitted.

Needing to download a large amount of JavaScript hasn't been a deterrent to anyone for anything yet. These arguments against WebAssembly are just FUD.

> hasn't been a deterrent to anyone for anything yet This is patently incorrect. Javascript's impact on page load time is so widespread that Google introduced AMP to "enables the creation of websites and ads that are consistently fast ... and high-performing"[1]. [1] https://www.ampproject.org/

You are saying the same thing as he is. Javascript's impact on load time hasn't been a deterrent to people using mountains of bloat in their page.

Thus, webasm being a few times faster to download and parse won't change a whole lot, since few web developers seem to care much about the speed of their pages.

If webasm won't change much, then it isn't reasonable to predict a future of web pages that simply render to the canvas.

Re: Introduction to WebAssembly: why should we care?

#136

Post by cm2187 »

alex_duf wrote: post #28
MistahKoala wrote: post #17

For non-dev idiots like me, what is it and why is it special? I got the impression that it allows compiled scripts to run in the browser and is faster than JavaScript.

It potentially allows any language (C, C++, Rust, .NET, heck in the future maybe Java, Scala or anything you want) to be run inside a webbrowser, at near native speed. Because any language would be compiled to this intermediate form (wasm) it would drastically simplify the distribution of complex applications. Because any language can be compiled to that form, you can potentially reuse your existing company's code to…

And it will pretty much allow to have a full app that bypasses the Apple/google app stores and their pay tolls/random policies.

Re: Introduction to WebAssembly: why should we care?

#137

Post by kbenson »

pjmlp wrote: post #37
rekado wrote: 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'…

Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.

So, viral GPL FTW?

Seriously, there's no shared libraries in compiled monolithic WebAssembly, is there? I think[1] that means included GPL code will require exposure of the source.

Maybe if we're lucky some best practice will emerge that the source is often available as a sourcemap so companies don't have to worry about being sued for infringing the GPL. It sure would be nice to finally see an outcome of companies erring on the side of (legal) caution that's better for consumers.

1: Think because everybody seems to like to argue the specifics of this point.

Re: Introduction to WebAssembly: why should we care?

#138

Post by pecg »

rekado wrote: post #98
austincheney wrote: post #91

Earlier quoted context omitted.

Use a code beautifier. JavaScript code isn't encrypted or compiled to binary. It is just text.

> It is just text This misses the point. Looking at a binary through a hex editor is also just text --- and the binary is also "just code", albeit at a level at which only few people are comfortable to work. Obfuscated code (and generated code in general) is clearly not the preferred form, so it hardly even counts as source code. But let's pretend your point were valid: would it remain valid with WebASM?

Also, with the ever increasing level of software complexity many websites rely on, reading such text isn't as simple as it may seem, to give clear example, Google's default page in only one reference javascript file from apis.google.com has ~8000 lines of code, which is deliberately difficult to understand by itself: variables have weird names, lots of anonymous functions, and so on.

Re: Introduction to WebAssembly: why should we care?

#139

Post by vanadium »

pjmlp wrote: post #11
Longhanks wrote: post #7

Earlier quoted context omitted.

With all major browser JIT compiling JavaScript, aren't they already?

No, because it still is the pile of HTML, CSS and JavaScript hacks. With WebAssembly you can bypass all of it, and do your UI framework in GL, and everything else with native libraries compiled into WebAssembly.

Accessibility?

Re: Introduction to WebAssembly: why should we care?

#140

Post by mikestew »

dbbk wrote: post #111
Endy wrote: 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?

That’s not my problem to fix, no proposal is required of me.
Post reply on HN