Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

251–259 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#251
post #249

Earlier quoted context omitted.

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.

Most of the time when you put JS on your page, what you're doing is breaking the thing that would - without JS - still correctly do what it's actually supposed to do.

Re: Introduction to WebAssembly: why should we care?

#252
post #247
post #240

Earlier quoted context omitted.

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…

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

This looks like a strawman.

For a user of a service there is no difference between a service provider that uses free software and a service provider that uses proprietary software. Proprietary software primarily harms the user of that software --- and in this case it is the service provider, not the user with a browser.

There are different concerns to outsouring computing and/or communication to services, but these are not the same concerns that apply with the use of proprietary software.

JavaScript applications, however, do run on the user's machine and thus the usual concerns about running non-free software apply.

> [Stallman] does seem to believe that only running free javascript somehow makes it safe to run... which isn't true.

I haven't heard him argue that position. Free software obviously can be faulty and it can be unsafe to use.

Re: Introduction to WebAssembly: why should we care?

#253

Earlier quoted context omitted.

> 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

6.5 is pretty respectable. Not quite like Windows or general purpose Linux which can be upgraded almost indefinitely. I have Vista laptops released mid-2009 (>8yrs old) that run Windows 10 rather well considering their age. Of course, no one would have guaranteed 8yrs on those devices. I'd wonder what experiences people with EOL Chrome devices out there are having with upgrades.

Re: Introduction to WebAssembly: why should we care?

#254
post #250
post #241

Earlier quoted context omitted.

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…

No one is suggesting wasm would replace all of the web.

We're just saying the developer and deployment optimization story would be vastly simplified without the JS/HTML/CSS stack.

Those of us who remember what development was like before "front-end" development as it is today know that story very well. The amount of undocumented, untested, and wonky code in the current web stack has always seemed ridiculous to us.

The problem with ActiveX, Flash, Silverlight, and OneClick was never about the developer story. It was about security and openness. WebAssembly solves both of those problems.

Open tools, pixel-perfect GUI design, compilers and debuggers, and strongly-typed languages would absolutely reduce the amount of HTML/JS/CSS in the world. It may not kill all of it, but it would put a sizable dent in it.

Re: Introduction to WebAssembly: why should we care?

#255
post #249

Earlier quoted context omitted.

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

Most of the time when you put JS on your page, what you're doing is breaking the thing that would - without JS - still correctly do what it's actually supposed to do.

"Most of the time"? Citation needed.

While I generally agree with the sentiment of "do more by coding less", and minimalist user interfaces, there are plenty of cases where you throw a whole lot of functionality out the window by outright banning JS.

Re: Introduction to WebAssembly: why should we care?

#256

Earlier quoted context omitted.

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

6.5 is pretty respectable. Not quite like Windows or general purpose Linux which can be upgraded almost indefinitely. I have Vista laptops released mid-2009 (>8yrs old) that run Windows 10 rather well considering their age. Of course, no one would have guaranteed 8yrs on those devices. I'd wonder what experiences people with EOL Chrome devices out there are having with upgrades.

I imagine you could still update with some wench-work. An EOL date of 6.5 sounds to me like a way to say that "beyond this point we will stop testing and ensuring compliance, and to avoid fucking over your relic (in PC terms), with an update that is untested on your specific hardware, we simply disable the automatic updates. Good luck."

Re: Introduction to WebAssembly: why should we care?

#257

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…

So, potentially, an OS could just be the browser and it would suffice for running apps like Android, iOS etc. already do?

Re: Introduction to WebAssembly: why should we care?

#258

Earlier quoted context omitted.

That's all true. But the domain serving the ads might be the same one serving the rest of the content. And if that server is motivated enough to show you that ad, they will do all of the things you mentioned. I've been worried for sometime that this will be the end-game of the ad-blocker wars.

Right, but all that could happen now. Webasm doesn't change anything in that regard.

It makes it easier though.

Re: Introduction to WebAssembly: why should we care?

#259
post #154

Earlier quoted context omitted.

I'd prefer a C++ compiler that directly compiles to wasm. Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake. I have read tutoria…

I really don’t understand the industry fixation with C++. It has to be one of the WORST (as in “error prone death trap”) computer languages ever devised. God how I wish it would fade away into obscurity. If half the effort wasted on C++ compilers and usage learning had been spent on something worthwhile...

"There are languages people complain about, and languages nobody use." - Bjarne Stroutup.

I don't think C++ will fade away as it's already a well installed language, and it is getting several upgrades, which are supported by big companies.

There is really nothing comparable to C++ in terms of language, to be really honest. There really are no language which are as readable and flexible as C, AND extensible and high level.

I tried to get interested to statically compiled language like rust, go, D, and honestly I can't get used to them. Safety is not really a good idea because putting barriers between the compiler and the programmer will always result in pain. C++ is the ease of C with some syntactic sugar for more convenient use. I see nothing that can be as good as C in term of down-to-earth syntax.

A good language is not a language that is well designed, a good language is a language everyone can use. C++ to me seems to be the least worse, except of course the toolchain.

Post reply on HN