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

241–250 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#241

Post by pjmlp »

krapp wrote: post #231
ChicagoDave wrote: post #201

Earlier quoted context omitted.

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

Says the web developer.

Qt, Delphi, WPF are miles ahead in terms of tooling in what a pile of HTML, CSS and JavaScript are capable of.

Anvil and tools like OutSystems are probably the one thing that comes close to what Blend is capable of.

Having a pixel perfect WYSIWYG GUI designer, with a components market, painless DB integration and deploying to the web at the press of a button will get lots of enterprise love.

Re: Introduction to WebAssembly: why should we care?

#242

Post by adrianN »

sp332 wrote: post #183
TeMPOraL wrote: post #176

Earlier quoted context omitted.

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

You can't download the entire internet. And loading a new web page every time you push a button is slow.

For some reason the web feels a lot faster when I disable JS...

Re: Introduction to WebAssembly: why should we care?

#243

Post by adrianN »

TheRealPomax wrote: post #93
hood_syntax wrote: post #47

Earlier quoted context omitted.

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.

New technology starts with the above-well-off, using tech you currency consider "absurdly unattaible to the masses" (like cars in the 20s, or telephone in the 40s, or computers in the 60s, or 24/7 internet in the 90s): for instance, when you just get a basically free gigabit connection straight into the backbone (like in a new upscale Japanese apartment building) the very idea that latency could even be a problem jus…

Latency and bandwidth are different though. Your GBit connection won't help you access servers on the other side of the Atlantic.

Re: Introduction to WebAssembly: why should we care?

#244

Post by adrianN »

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?

The web was a pretty exiting place before the suits arrived trying to make money. Hobbyists writing about their passions doesn't require ads. People who can afford a computer to write their blog can also afford the pennies it costs to host a static web site.

Re: Introduction to WebAssembly: why should we care?

#245

Post by tskaiser »

pecg wrote: post #152
tskaiser wrote: post #101

Earlier quoted context omitted.

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…

> 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 think either of these statements is correct. There wasn't a problem of 'responsiveness' and 'interaction' on http to begin with, in fact what Sun and Netscape did with javascript was to overengineer the web because they saw it as a business opportuni…

While I accept that my description of JS et. al. might be contentious, I don't see that you have argued against my piece on the WWW in general.

Regarding latency and responsiveness I agree that they are issues that depend largely on your use cases and your skill at implementing solutions. In this regard I can agree that some pages simply don't need JS. It is also being misused for ads and tracking to a degree that is problematic and can in itself cause issues.

Re: Introduction to WebAssembly: why should we care?

#246

Post by tskaiser »

discreditable wrote: post #185
opportune wrote: post #96

Earlier quoted context omitted.

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…

> it moves away from the "upgrade your device every X years" paradigm Don't Chromebooks have ~4yr end-of-support lifecycles where they stop receiving upgrades?

6.5 years for most devices, 5 years for some legacy cases, and it is a soft limit ie. they don't automatically enter EOL, they just stop guaranteeing the updates.

Source: https://support.google.com/chrome/a/answer/6220366

Re: Introduction to WebAssembly: why should we care?

#247

Post by krapp »

Vinnl wrote: post #240
krapp wrote: post #232

Earlier quoted context omitted.

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 :)

The web throws a monkey wrench into a lot of assumptions the free software model seems to make about what software is - obviously you can't download the source of an entire server stack and compile it, much less rewrite and redistribute it, but that would seem to be what would be required for the web to be 'free.'

Ok, technically you could but that would be insane. Even if you consider how much FOSS exists on servers, it's impossible to ever be certain what is running the logic of a site unless you can run it locally, which defeats the whole point of the web.

But arguments that javascript in particular is hostile to user freedom seem a bit overstated... and even Stallman doesn't suggest the answer is getting rid of it altogether. Although he does seem to believe that only running free javascript somehow makes it safe to run... which isn't true.

Re: Introduction to WebAssembly: why should we care?

#248

Post by TheRealPomax »

adrianN wrote: post #243
TheRealPomax wrote: post #93

Earlier quoted context omitted.

New technology starts with the above-well-off, using tech you currency consider "absurdly unattaible to the masses" (like cars in the 20s, or telephone in the 40s, or computers in the 60s, or 24/7 internet in the 90s): for instance, when you just get a basically free gigabit connection straight into the backbone (like in a new upscale Japanese apartment building) the very idea that latency could even be a problem jus…

Latency and bandwidth are different though. Your GBit connection won't help you access servers on the other side of the Atlantic.

I have no idea why you would need to leave your country in a world where we're back to thin clients and remote processing. Pretty sure the most obvious place for that processing to take place is at what used to be ISPs and have in this hypothetical future become Interactive Service Providers rather than "internet" service providers, with low latency, high bandwidth hubs in or near your city (and more likely, multiple hubs per city).

Re: Introduction to WebAssembly: why should we care?

#249

Post by sp332 »

adrianN wrote: post #242
sp332 wrote: post #183

Earlier quoted context omitted.

You can't download the entire internet. And loading a new web page every time you push a button is slow.

For some reason the web feels a lot faster when I disable JS...

I can make an application as fast as you want if it doesn't have to run correctly.

Re: Introduction to WebAssembly: why should we care?

#250

Post by krapp »

pjmlp wrote: post #241
krapp wrote: post #231

Earlier quoted context omitted.

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

Says the web developer. Qt, Delphi, WPF are miles ahead in terms of tooling in what a pile of HTML, CSS and JavaScript are capable of. Anvil and tools like OutSystems are probably the one thing that comes close to what Blend is capable of. Having a pixel perfect WYSIWYG GUI designer, with a components market, painless DB integration and deploying to the web at the press of a button will get lots of enterprise love.

I don't disagree with that. I disagree with your original premise that all websites will eventually be compiled WASM blobs. There's simply no reason for that to ever be the case, no matter how nice the tooling gets.

Not every site is a business site and not every business with a website has the budget or impetus to chase the bleeding edge of web development. HTML and javascript will continue to exist and be supported by browsers for the forseeable future (meaning the option to choose not to use WASM will also always be there.) Billions and billions of sites already on the web which would have to be completely taken down and rebuilt for no practical reason.

I look forward to the age of embedded binary apps on the web . I think the web is the only real option we have to preserve software long-term, and the likelihood of software being preserved is enhanced by that software remaining executable. But even in my wildest fantasies where every program ever written maps to a URL, I doubt that use case will take up more than a fraction of online content. The web is just too big and too complex and too general to reduce to any single heuristic or use case.

People are still using COBOL and Perl and pushing code to production with Notepad++ and Filezilla. The real world doesn't optimize the way you're suggesting it would. The business world certainly doesn't.

Post reply on HN