Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C recommends WebAssembly

w3.org

Post reply on HN
Print view View original

311–320 of 350 posts

Re: W3C recommends WebAssembly

#311

Post by BlueTemplar »

krapp wrote: post #255
BlueTemplar wrote: post #227

Earlier quoted context omitted.

Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ? Browsers can do a lot of things these days that are not part of the Web : display pdfs, ftp folders, rtsp streams... The browser becoming an OS inside the OS is at the crux at the issue. (And the main reason is likely Google trying to wrest control of personal computing from Microsoft…

> Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ? What does a "separate field" have to do with anything? Now a site is or isn't part of the web based on how Google formats them in their search listings? These sites serve media meta-tags specifically so that Google will index them, they depend on SEO. Find someone famous with a Twit…

Right, thanks for the discussion, it has allowed me to pinpoint/remember the actual issue that I have :

It's about trying to push too many things on the Internet through HTTP, about trying to transform the browser into an OS inside an OS (which is a lot about the Microsoft vs Google battle over personal computing).

Protocols, not platforms ! https://news.ycombinator.com/item?id=20841059

Re: W3C recommends WebAssembly

#312

Post by shadowgovt »

BlueTemplar wrote: post #310
shadowgovt wrote: post #290

Earlier quoted context omitted.

At this point, HTTP has enough tooling around it to do enough significant application-layer things that the opportunity cost of rolling new protocols is extremely high. It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which is a technology few people want to build an alternative for (and fewer people should be trusted to do correctly).

Trying to force everything over HTTP is a bad practice that is slowly killing the Internet.

[citation needed]. Traffic, usage, diversity of usage, investment, all of these are higher than they've ever been and still trending upwards. What definitions are we using by which we can look at these numbers and claim the internet is being "killed?"

Re: W3C recommends WebAssembly

#313

Post by shadowgovt »

BlueTemplar wrote: post #309
Pete_D wrote: post #246

Earlier quoted context omitted.

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.

Indeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.) And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols. I believe that the Internet is fundamentally abo…

Novel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established.

To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate.

... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.

Re: W3C recommends WebAssembly

#314

Post by BlueTemplar »

shadowgovt wrote: post #313
BlueTemplar wrote: post #309

Earlier quoted context omitted.

Indeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.) And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols. I believe that the Internet is fundamentally abo…

Novel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established. To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use t…

Well, yes, lower level protocols are harder to implement and deploy because they require new hardware - but I'm not sure how are they relevant in a discussion about higher level protocols that are in software and build on the Internet Protocol?

Re: W3C recommends WebAssembly

#315

Post by BlueTemplar »

shadowgovt wrote: post #312
BlueTemplar wrote: post #310

Earlier quoted context omitted.

Trying to force everything over HTTP is a bad practice that is slowly killing the Internet.

[citation needed]. Traffic, usage, diversity of usage, investment, all of these are higher than they've ever been and still trending upwards. What definitions are we using by which we can look at these numbers and claim the internet is being "killed?"

https://news.ycombinator.com/item?id=20841059

Re: W3C recommends WebAssembly

#316

Post by bhaak »

krapp wrote: post #261
bhaak wrote: post #127

Earlier quoted context omitted.

Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine. Rather use that skills to make WASM faster.

> Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM. The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it a…

I thought you meant adding other scripting languages to the browser. Not a WASM runtime.

That's likely still not a good idea. A specific runtime is likely to be outdated fast. That's like asking why the JQuery library wasn't shipped with the browsers themselves.

For runtime with a significant size, it's probably going the same way as JQuery. Have a CDN host it so different websites can use it and leverage the browser's cache.

Re: W3C recommends WebAssembly

#317

Post by gavinray »

magsnus wrote: post #39

I really hope this can become a viable alternative to the JS-frameworks we have today for webapps and that more apps can be served via the web.

There are already several libraries that allow you to write React-like SPAs in the browser via WASM.

The two largest are Yew (Rust), Vugu (Vue-esque but with Go instead of JS), and Blazor (C#)

https://github.com/yewstack/yew

https://github.com/vugu/vugu

https://github.com/aspnet/Blazor

All are perfectly viable for production apps as of today and not much more difficult than writing React, given you have some familiarity with their implementation language.

Re: W3C recommends WebAssembly

#318

Post by numtel »

com2kid wrote: post #294
simias wrote: post #107

Earlier quoted context omitted.

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…

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy QT is a third party library that wraps the underlying OS primitives. A really fancy tree view in JS is 10KB, maybe 15KB, given desktop+mobile support, proper accessibility, and good support for theming. And that is if you are getting really fancy. A s…

For your #1 example, there is now the details and summary element that accomplish this too.

Re: W3C recommends WebAssembly

#319

Post by MaxBarraclough »

krapp wrote: post #64
bogwog wrote: post #23

Hopefully this also means that Javascript is going away for good

It doesn't. Browsers will have to continue to support javascript indefinitely, simply because doing otherwise would break most of the web. Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WA…

Also, WebAssembly doesn't have everything JavaScript has. Garbage collection and support for older browsers, for instance.

> WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode.

I'm not sure that requiring a build step is a real problem, for web 'applications' at least. Plenty of JavaScript frameworks use a build step anyway.

Re: W3C recommends WebAssembly

#320

Post by shadowgovt »

BlueTemplar wrote: post #314
shadowgovt wrote: post #313

Earlier quoted context omitted.

Novel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established. To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use t…

Well, yes, lower level protocols are harder to implement and deploy because they require new hardware - but I'm not sure how are they relevant in a discussion about higher level protocols that are in software and build on the Internet Protocol?

The details of the complexities change, but the complexities are still there. You still need adoption by multiple parties, you still need to solve the application level challenges that HTTP solves (including, most importantly, secure communication over an open network), and you still need tooling to understand the protocol in flight, including its failure modes, to debug an application built atop the protocol. And you lose the utility of libraries and infrastructure built around using the other protocol.

The opportunity cost to do that with a brand new protocol instead of taking advantage of HTTP's flexibility to build new protocol atop HTTP is high.

Post reply on HN