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

101–110 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#101

Post by tskaiser »

_red wrote: post #45
osrec wrote: 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!

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. side effects of the true problems being solved.

Re: Introduction to WebAssembly: why should we care?

#102

Post by kilburn »

Normal_gaussian wrote: post #74
tzahola wrote: post #55

Earlier quoted context omitted.

Websites will be obfuscated blobs downloaded from a single server.

That's possible now. You can serve the ad so its indistinguishable from any other image. Redirect it and clicks through your server. Give it an obfuscated DOM path. Its just a hassle and can't be done with pasting a line of code

Pretty off-topic, but the reason why it isn't done is tracking, not ease of use.

Ad-networks want the ads pulled from their servers so they can track views. If web-owners serve the ads themselves, then the ad-network must trust whatever the web owner says about the numbers of visits/clicks/etc.

For now the ad-networks just don't care about ad blockers, because they are making money hand over fist anyway. If things ever get hairy for them, I suspect they'll switch to a reverse-proxy model. You point your domain to their servers as you do with cloudflare, and they they serve your content with ads injected in the right places, served under the same domain. This would be pretty easy for web-owners and completely nullify ad-blockers in their current incarnation.

Re: Introduction to WebAssembly: why should we care?

#103

Post by TremendousJudge »

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/

If it had been a deterrent, people wouldn't have done it, and we wouldn't have slow loading pages in the first place, and Google wouldn't have an AMP initiative. However, We have slow loading pages, and Google has AMP, which means that load speeds hasn't deterred stopped anyone from adding a ton of JS bloat

Re: Introduction to WebAssembly: why should we care?

#104

Post by charlysl »

"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 goes ahead, can be confined to just UI again.

They are planning to add support for gc, threads, bigger mem, tail recursion, etc [1], so will it be running everything efficiently? Even on mobile, given its backers?

Wow

[1] https://github.com/WebAssembly/design/blob/master/FutureFeat...

Re: Introduction to WebAssembly: why should we care?

#105

Post by woogley »

hood_syntax wrote: post #47
_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…

Yeah, if we want latency added to literally every action... I understand that what you're saying is a possibility, but I sure hope it doesn't come to pass.

The catalyst of such a shift could be a very good thing, e.g. exceptional internet speeds everywhere

Re: Introduction to WebAssembly: why should we care?

#106

Post by baybal2 »

hood_syntax wrote: post #47
_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…

Yeah, if we want latency added to literally every action... I understand that what you're saying is a possibility, but I sure hope it doesn't come to pass.

Now I expect that there will come usability experts from google/facebook/amazon and tell you that an average user does not event know what latency is.

Native apps have won over web app ecosystem, plainly and simple. WASM will not change things even a bit to root causes of people deciding to use native apps over web apps.

Re: Introduction to WebAssembly: why should we care?

#107

Post by scanr »

dingo_bat wrote: post #52
Figs wrote: post #36

Earlier quoted context omitted.

> when the entire contents of the page - including the ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of obfuscated code. Your site would also be unreadable by Google, meaning that you'll be heavily penalized in search ranking and no one will find your abomination of a website designed this way.

If it becomes the norm Google crawler will start running the pages and looking at the content.

It already does

Re: Introduction to WebAssembly: why should we care?

#108

Post by baybal2 »

tzahola wrote: post #54
Figs wrote: post #36

Earlier quoted context omitted.

> when the entire contents of the page - including the ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of obfuscated code. Your site would also be unreadable by Google, meaning that you'll be heavily penalized in search ranking and no one will find your abomination of a website designed this way.

Yeah, no. Google is an ad company. They will simply open an API for content providers to push content into their search engine. They don't have to maintain their crawlers, users can't block their ads, and both Google and the content providers get more revenue. It's a win-win situation. Oh, I forgot the users: they obviously lose! But hey, at least you can write rich applications :^)

>They will simply open an API for content providers to push content into their search engine

Ah, clickfarmers and adfraudsters will welcome that with open hands.

Re: Introduction to WebAssembly: why should we care?

#109

Post by 2sk21 »

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.

I was going to say there same thing - this just seems like java Applets have been reinvented

Re: Introduction to WebAssembly: why should we care?

#110

Post by baybal2 »

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.

WASM is a three miles step back for the web, along with native DRM implementations.

HTML5 was there to obsolete quirky flash/silverlight/java applets and tell people to not to confuse code and the content, now main "web ecosystem pushers" are doing everything to reincarnate Flash in a new embodiment as WASM

Post reply on HN