Live data from Hacker News

W3C recommends WebAssembly

w3.org

161–170 of 350 posts

Re: W3C recommends WebAssembly

#161

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…

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.

95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX.

Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users.

HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.

This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.

Re: W3C recommends WebAssembly

#162
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…

The reason behind 'the Web' resembling the mess unfortunately best exemplified by 'the Net' has a much simpler and trivial reason:

We have globally networked local Networks of locally networkable Networks and most of us naively think that this Global Network of Local Networks networking Local Networks actually functions as a universally internetworking Internetwork of universally internetworkable Internetworks internetworking internetworkable Internetworks internetworking internetworkable Networks[([¹]1)], because we trust the people who've labeled both IPv4 and IPv6 as the "Internet Protocol" despite it not in any way, shape or form having the ability to perform what the people who came up with the concept of internetworking (no, NOT the ARPA people.) actually meant by the term.[2]

As the simplest proof of this fact: We've almost reached 2020 and all of our 'solutions' for multi homing don't ACTUALLY work in a not-pants-on-head-dysfunctional despite the fact that we've faced that issue since, to quote Wikipedia, "In 1972, Tinker Air Force Base wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony)."

Our 'Inter'net at the moment still resembles just a global network, aka just plain old phone calls, with extra steps. Which explains both the mess we call the WWW, and the global dominance of large telcos.Can't give an AS number and BGP access to just anyone[([²]4)] , as we know ever since L0pht Heavy Industries testified before the US Senate, over 2 decades ago, back in 1998.[3] NOTHING has fundamentally changed about this since. We've just written bigger and bigger macros ignorant of why we keep having to fight windmills & having to reinvent the wheel over and over again.

[1 (¹ yes, I did intentionally phrase that in & as a reference to a certain Cisco exam question.)]

[2 see https://news.ycombinator.com/item?id=21108796, but also see http://ict-arcfire.eu/index.php/rina/ & http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-ind... ]

[3 https://youtu.be/VVJldn_MmMY]

[4 (² Of course, I don't advocate that we should. No. I do however argue that each of these situations shouldn't exist in the first place.)]

Re: W3C recommends WebAssembly

#163
post #122

Earlier quoted context omitted.

Indeed, HTML = World Wide Web If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!

> Indeed, HTML = World Wide Web The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of…

Why do you find this stance ridiculous ?

Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...)

I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though I'm pretty sure that the capability has been here for more than a decade.)

With the ability to run arbitrary code comes the loss of a common standard, and therefore the inability to communicate, especially for machines - you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?

Re: W3C recommends WebAssembly

#164
post #160

Earlier quoted context omitted.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS. ex: end $label121 get_local $var7 get_local $var9 call $func3444 get_local $var7 call $func1500

Yes this is what I am talking about. Once you know the instruction, I fail to see how it is more difficult to understand than javascript.

That certainly is a take.

Re: W3C recommends WebAssembly

#165
post #118

Earlier quoted context omitted.

WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob. So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.

Unless I'm completely missing something the "text version" you're talking about is just WASM and there's quite a difference between that and minified JS. ex: end $label121 get_local $var7 get_local $var9 call $func3444 get_local $var7 call $func1500

How is that any more readable than deobfuscated js?

    func1500(func3444(var7, var9), var7)
or more likely:

    gw(kl(s,i),s)

Re: W3C recommends WebAssembly

#166
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 No, not any more than C#'s giant standard library blows my mind. Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that wil…

> These people are missing the point

Maybe not.

If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.

Re: W3C recommends WebAssembly

#167
post #2

Write once, run everywhere. I bet in few years we will run wasm natively on processor.

WASM machines--the next (hopefully) better version of Lisp machines ( https://en.wikipedia.org/wiki/Lisp_machine )! It looks like Gary Bernhardt was pretty spot on in his talk "The Birth and Death of JavaScript": ( https://www.destroyallsoftware.com/talks/the-birth-and-death... )

Lisp machines didn't go away because of some conspiracy, they just stopped making sense. The vast majority of the benefit was that since they ran on (and were compared to other) 1980s minicomputer hardware without instruction caches, pulling the interpreter into microcode meant that the interpreter's overhead wasn't competing with data fetches on the von Neumann memory bus.

Instruction caches (and JITs to a degree) solve the same problem in much more general ways. That's why Azul went out of their way to create an appliance to run Java code with custom CPUs, and ended up with a pretty standard RISC for the most part.

All of that applies to WASM machines too.

Re: W3C recommends WebAssembly

#168
Good. Javascript needs to die. It was far simpler to build performant multi-device UIs 15 years ago than it is today. Building UIs natively on iOS and Android is so much simpler than building for the web.

Technical question: 1.) What is the speed of WebAssembly on iOS WebKit and Android WebView? 2.) Is it feasible to write an entire app UI in something like Qt and target WebAssembly? 3.) Android, iOS, Windows versions of the app are Qt apps natively or possibly through the device's WebKit.

Is this possible today? Is there a better UI library than Qt for this?

Re: W3C recommends WebAssembly

#170
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 No, not any more than C#'s giant standard library blows my mind. Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that wil…

Complicated lists on the web are really bad. If you have a lazily populated table, it breaks the browser's Find, it typically breaks the scroll bar positioning, there's visible holes while it populates, scrolling is janky slow, the scroll bar will jump unexpectedly.

This is one place where HTML does not give enough primitives for a quality library-based solution.

Post reply on HN