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

111–120 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#111

Post by dbbk »

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?

Re: Introduction to WebAssembly: why should we care?

#112

Post by dbbk »

adriancooney wrote: post #34

I feel like a really big point people gloss over when it comes to WebAssembly is browser support. It’ll be years before we can drop JavaScript (not that I want to) because we’ll be waiting for IE and friends to drop of the face of the planet. WebAssembly could act like a catalyst to propel the web forward or segment it even more. I’m leaning more towards the latter, at least for the next 7-10 years or so.

Many sites can already afford to drop IE entirely. Frameworks such as Ember have dropped support for every version except 11. It is not going to take 7-10 years for you to be targeting evergreen browsers.

Re: Introduction to WebAssembly: why should we care?

#113

Post by AngeloAnolin »

The more I read about WebAssembly, the more I think it is the rebirth of Flash, or Silverlight, or JavaFX without being tied to a proprietary entity (Adobe, MS, Oracle).

Will it be really good for the web in general? I guess it will depend on the motivation of those who would peruse the technology.

Re: Introduction to WebAssembly: why should we care?

#114

Post by chongli »

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.

Those of us who get frustrated by latency in our tools were left behind long ago. Shiny user interfaces, cloud to-do lists, adblockers, bloated fad frameworks of the week, electron apps, blue apron for dogs... This is our reality now.

I miss the internet I grew up with. The one before all the money arrived to ruin absolutely everything.

Re: Introduction to WebAssembly: why should we care?

#115

Post by TomMarius »

pjmlp wrote: post #82
mrec wrote: post #64

Earlier quoted context omitted.

It reuses the existing Javascript security model, which has been tested pretty extensively in the wild.

Should I list all of the CVEs related to exploits on JavaScript VMs? Just today there were a few on another HN thread.

It happens, yes. But we're not building WAsm on a greenfield.

Re: Introduction to WebAssembly: why should we care?

#116

Post by niftich »

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.

Obligatory point that Flash didn't fail in the marketplace. Rather, it was wildly popular, so much so that Microsoft eventually felt the need to develop a comparable tech -- Silverlight.

Flash on the web faltered rapidly after many years of efforts by Mozilla, Apple, Opera, and associated individuals. They were looking to move the web 'forward' had a high-profile disagreement with W3C, so they started their own standard-setting collaboration to specify HTML5 and associated JS APIs. The blogosphere eagerly awaited the results, which promised to formally bring multimedia and rich interactivity to HTML, without having to use a vendor plugin.

When Apple announced that Flash won't be supported on the upcoming first iPhone, it was over. After a few years, when apps came to the iPhone, Adobe failed at marketing the fact that their Flash assets can be compiled into iPhone apps using Adobe AIR.

With existing Flash assets effectively relegated to desktop-only, it was only a matter of time before it was pushed out of the standard browser stack. Although later, both Microsoft and Google shipped Adobe's plugin (with better process isolation) together with the browser or the OS, and hooked into their respective auto-updaters, Flash was on its way out.

Re: Introduction to WebAssembly: why should we care?

#117

Post by simion314 »

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!

I think web needs some more standardized functionality (like popups/modals, better dropdowns styling, datagrids ) so you do not have to implement things yourself or research and find a solution made by a third party.

Re: Introduction to WebAssembly: why should we care?

#118

Post by forgotpassagan »

rekado wrote: post #59
Vinnl wrote: post #49

Earlier quoted context omitted.

This is hardly inherent to Javascript/WebAssembly. Installed applications are binary code, i.e. closed by default unless you explicitly provide source code. The same holds true for web applications, however, for some reason we don't care about it being open source that much anymore...

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…

A lot of sites are transpired these days, so you have the 'source' but it's generated code

Re: Introduction to WebAssembly: why should we care?

#119

Post by [deleted] »

forgotpassagan wrote: post #118
rekado wrote: 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…

A lot of sites are transpired these days, so you have the 'source' but it's generated code

[deleted]

Re: Introduction to WebAssembly: why should we care?

#120

Post by tzahola »

baybal2 wrote: post #108
tzahola wrote: post #54

Earlier quoted context omitted.

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.

Obviously, it will be protected via client certificates.
Post reply on HN