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

171–180 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#171

Post by AboutTheWhisles »

pjmlp wrote: post #159
AboutTheWhisles wrote: post #132

Earlier quoted context omitted.

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.

I guess you missed all those sites using Flash, Silverlight, Applets, WebStart, ClickOnce and many other plugins. WebAssembly on the long run will enable to bypass JavaScript and target the browser as if it is yet another OS.

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

Re: Introduction to WebAssembly: why should we care?

#172

Post by dymk »

AboutTheWhisles wrote: post #167
v_lisivka wrote: post #157

Earlier quoted context omitted.

Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly. Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS.…

> 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

Re: Introduction to WebAssembly: why should we care?

#173

Post by borplk »

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'…

I don't particularly disagree but this theme of ehrmagerd-they-took-err-open-software comments under WASM posts is beginning to look like a meme.

> Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services.

The vast majority of people do not understand or want that. It's mostly a nerd fetish (and I count myself in).

> Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services.

This openness is also a double edged sword. People focus on the warm fuzzy side of it and forget the mess that it tends to create for a platform because no one can ever rely on some features being available for everyone.

You will need a never ending amount of feature detection, polyfills, polyfills for your polyfills, transpiling, blah blah blah because oh look someone wanted to exercise their freedom to disable textboxes on their browser. And now they are demanding that you make your application gracefully fallback to handle the case where a textbox is not available. IT'S THEIR RIGHT!

Eventually someone will show up with a baked sweet potato and demand that your application must work on their potato because they have disabled all features but still want the functionality.

You can't realistically cherry pick underlying software pieces like that.

Rather than delivering a buggy software that works under a million different combinations of features and settings I will deliver a package of software that run predictably well on one or more predictable platforms. That is "the atom". You either take it all, or not at all.

From my experience the average users tend to be perfectly happy and satisfied with that. They are almost always running with default options everywhere anyway. It's the GNU-enthusiast hacker-types (and I count myself in) that tend to throw a tantrum about their custom preferences and philosophical and technical objections.

Re: Introduction to WebAssembly: why should we care?

#174

Post by moron4hire »

kbenson wrote: post #137
pjmlp wrote: post #37

Earlier quoted context omitted.

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 er…

What? There's absolutely no need for such companies to view this as anything more dangerous than the past. Nothing in the GPL says you have to be provided with a copy of the source along with the program. It also doesn't say the program has to come with a link to an online repository for the code. The GPL says that the code has to be provided when requested. So go ahead, contact the company and request the code.

Always cracks me up how many people think the GPL means "I get everything I want, exactly how I want it".

Re: Introduction to WebAssembly: why should we care?

#175

Post by dymk »

mikestew wrote: post #140
dbbk wrote: post #111

Earlier quoted context omitted.

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.

Okay, then don't expect anybody to build one. Web browsers are incredibly complex, and nobody is going to build one for free nowadays.

Re: Introduction to WebAssembly: why should we care?

#176

Post by TeMPOraL »

tskaiser wrote: post #101
_red wrote: post #45

Earlier quoted context omitted.

These things are cyclical: * Early computers (1960-1980s): Dumb Terminal - Remote Server * Early PCs (1980s-1995): Local Processing - Remote Storage * WWW (1995-2010s): Dumb Terminal - Remote Server * JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will…

Yet each of those steps solved a different problem. Early computers did not have the local processing power needed to run heavy jobs. Early PCs did not have the storage. WWW solved an entirely different problem, namely distribution and communication. JS et. al. solved the problem of responsiveness and interaction ie. latency. I don't really see those as exhibiting cyclical traits, at best I see it as a correlation ie…

> JS et. al. solved the problem of responsiveness and interaction ie. latency.

You mean "introduced", right? Back before the modern web, when we all expected software to run on our machines, there was no responsiveness and latency problems, because data didn't travel over the wire unless it absolutely had to.

Re: Introduction to WebAssembly: why should we care?

#177

Post by TeMPOraL »

opportune wrote: post #96
_red wrote: post #45

Earlier quoted context omitted.

These things are cyclical: * Early computers (1960-1980s): Dumb Terminal - Remote Server * Early PCs (1980s-1995): Local Processing - Remote Storage * WWW (1995-2010s): Dumb Terminal - Remote Server * JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will…

That's basically what Chromebooks already are. I think it's the future too. The only problem is that it moves away from the "upgrade your device every X years" paradigm that makes consumer electronics manufacturers money. They'll have to switch to a subscription model and people may not like that (and personally I'm terrified of the alternative situation where a company would rather I give them my personal informatio…

> One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming.

That would be great, if only we could make it not belong to Amazon or Google. Consider the same idea phrased like this: apartment complex have servers in their basement offering compute, and services you use work on those servers. The model of today is that companies own services, control where the compute happens, and ship your data to them, taking ownership over it in the process. The alternative model I dream of is your data under your control, your choice where the compute happens, and third-party code being shipped to that place.

Re: Introduction to WebAssembly: why should we care?

#178

Post by dymk »

Skinney wrote: post #148
pjmlp wrote: post #11

Earlier quoted context omitted.

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.

But why on earth would you do that? That would be like bypassing the native UI framework on iOS or Android. It gives a worse experience for users, and is likely more work for you, the developer.

Because this is a HN circlejerk about WASM, since when does an argument ever have to be well thought out or reasonable?

Re: Introduction to WebAssembly: why should we care?

#179

Post by TeMPOraL »

dymk wrote: post #175
mikestew wrote: post #140

Earlier quoted context omitted.

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

Okay, then don't expect anybody to build one. Web browsers are incredibly complex, and nobody is going to build one for free nowadays.

That's only yet another reason to try and spin off a more user-friendly web, and burn the current thing to the ground.

Re: Introduction to WebAssembly: why should we care?

#180

Post by TeMPOraL »

Figs wrote: post #31
pjmlp wrote: post #11

Earlier quoted context omitted.

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.

Which is a terrible usability nightmare waiting to happen... Seriously, DON'T do this. This breaks ctrl-f. This is unlikely to work well for people who need to enlarge text or enhance contrast due to vision impairment. This breaks screen readers. This will probably break most site archive navigators, so your content is lost to history (e.g. wayback machine). This will probably prevent Google from indexing your site,…

Welcome to the Modern Web. Not sure if you noticed, but most web developers don't give a flying fuck about usability (despite what their company blogs say). A broken navigation is something you encounter daily on the Internet. CTRL+F still kinda works - it can scroll you to the more-less right area of the screen, but quite often the text you search for isn't highlighted anymore. Right-click is routinely broken (most recently with stupid-ass "social sharing" context menus). Copy-paste is routinely broken with stupid inventions that alter the contents of your clipboard in hope you don't notice the extra URL in there. Modern websites turn your computer into a frying pan with the shit ton of JS they execute, most of which is not only unnecessary, but also actively hostile. And/or mine cryptocoins, because it's almost 2018, so we need more dumb inventions.

It's a long topic, but basically boils down to companies being greedy and not giving a fuck about their users, and web developers being too busy chasing shiny to stop and care about actually providing value to users.

> you'll find that your users have things set up in ways you'd never considered...

Web companies don't care. They aim for the majority, which is users with popular browsers on default settings, without ad blockers and any plugins.

Post reply on HN