Live data from Hacker News

W3C recommends WebAssembly

w3.org

241–250 of 350 posts

Re: W3C recommends WebAssembly

#241

Earlier quoted context omitted.

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS cla…

The last decade? In 2009 JQuery ruled the world, the last 6 years definitely.

they have a problem with it in that unless you are rendering server side your pages won't work for someone who does not want to enable JS.

In the same way it goes against lots of ways the web has worked for 2 decades in regards to user customization, the ability to scrape content etc. so these things are irritating to anyone familiar with how "things used to be" in the same way that new freeway development destroying an ecosystem can be irritating to people familiar with the beauties of that ecosystem.

For what it's worth I also make my living doing the same thing, but I can certainly see the benefits to the other way.

Re: W3C recommends WebAssembly

#242

Earlier quoted context omitted.

My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamental…

One of the reasons of the downfall of Flash were those tiny Flash sites in the middle of a full screen page when we suddenly moved from small screens to 1366x768 or better. Many sites didn't have the resources to upgrade and started looking like something 100 years old.

I always thought the primary driver of the demise of Flash was that Apple simply decided not to support it in iOS Safari. Is that not right?

Re: W3C recommends WebAssembly

#243

What's the horizon for WebAssembly capable browsers gaining enough marketshare that it becomes a viable compilation target?

WebAssembly support isn't sufficient on its own. You also have to deal with various WebAssembly features, such as thread support and growable heaps, that are relevant to your app.

There are more features coming to WebAssembly in the browser, including hopefully a way to feature detect in the WebAssembly binary instead of the way it's done now, which is to compile as many binaries as you need for combinations of features, feature test in JS, and then pick which wasm module to load.

Re: W3C recommends WebAssembly

#244

Earlier quoted context omitted.

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage? Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun. I would be very g…

I wouldn’t be surprised if 50 MB was a more common webpage size than 5 KB these days.

Re: W3C recommends WebAssembly

#245
post #226

Earlier quoted context omitted.

My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamental…

> Modern JavaScript addressed these issues, hence its popularity over Flash I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.

I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.

Re: W3C recommends WebAssembly

#246

Earlier quoted context omitted.

But with the strong advantages of access to the Internet that a website brings (which is itself a whole bag of hard problems to solve), the appeal of building things accessible via browser user-agent (regardless of what the thing is) is huge. It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rende…

What prevents access to the Internet from a non-website ? Why use the HyperTEXT Transfer Protocol for things completely unrelated to text - it's not like other, more appropriate protocols are not available, or cannot be designed ! (Or that URLs are limited to HTTP...)

Partly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt ("On the use of HTTP as a Substrate"). I wish we still built protocols too.

Re: W3C recommends WebAssembly

#247

Earlier quoted context omitted.

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…

> Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?

Users seem pretty satisfied with single-page apps. They are slow to load and have frustrating-to-use (inconsistent) interfaces, at least compared to my memory of 1990s desktop software. If users actually cared about performance then software would get faster over time.

Re: W3C recommends WebAssembly

#248
post #225

Earlier quoted context omitted.

> Could we ever lose the HTML centered model? This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separat…

Well QT can easily render on any device context (like Canvas) or Xamarin could also easily ship their own controls to render on a Canvas (Microsoft owns more that enough code to do that). It is a matter of time till we see desktop application hosted in a wasm enabled browser.

QT is already experimenting with rendering to Canvas using WASM in the browser, I've tried to call them out on it as bad practice a couple of times in the past.

Rust on the other hand is doing some genuinely exciting, powerful stuff with allowing WASM to talk to the DOM and allowing native developers to target HTML directly within their apps. Rust's approach is to treat the language like a minimal, drop-in replacement for Javascript that doesn't require you to ship an entire rendering engine alongside it.

It is yet to be seen which approach to web portability is going to win. Obviously I'm rooting for Rust, and I personally think apps that are written using Rust's strategy will nearly always be higher quality than apps written using QT's strategy. But that doesn't necessarily mean that Rust will win, there are a lot of factors at play here. It'll be interesting to see.

But agreed, native apps are definitely coming to the web in some form or another. Funnily, the opposite is also true, since there's been a lot of buzz about using WASM for native sandboxing. I like to think that Gary Bernhardt[0] is pleased about that.

[0]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: W3C recommends WebAssembly

#249
post #226

Earlier quoted context omitted.

> Modern JavaScript addressed these issues, hence its popularity over Flash I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.

I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.

Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.

Re: W3C recommends WebAssembly

#250
post #107

Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…

If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance. HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features…

> This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance.

I thought HTML was developed with HATEOAS in mind. So I don't see the seperation as a technical limitation but a powerful abstraction. Flash was what people wanted but HTML was what a good web needed (imagine the internet with only Flash/WebAsm from the beginning).

Post reply on HN