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

271–280 of 350 posts

Re: W3C recommends WebAssembly

#271

Post by marcosdumay »

EvanAnderson wrote: post #129
6gvONxR4sf7o wrote: post #69

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…

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…

Yes, and for games it will be great. And a mixed bless for web applications.

What won't be great are sites that do this to enforce ad viewing. But if it becomes common enough, you can expect ad-blockers to act on the frame-buffer of that virtual browser.

Anyway, the most annoying will be the stupid people that do that just because "Even Google does it!" "It's webscale!", or whatever people will be saying 5 years from now.

Re: W3C recommends WebAssembly

#272

Post by skunkworker »

nojvek wrote: post #236

The design goals of WebAssembly are the following: Fast, safe, and portable semantics: * Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware. * Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches. * Well-defined: fully and precisely defines valid programs and their behavior i…

Two of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers.

About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing for in-browser MP3 encoding.

And secondly cloudflare allows for their workers to be written in WASM, allowing for more processor intensive apps (like resizing an image) to be completely on the edge.

I see it as eventually fulfilling the portability goals that java applets in the browsers use to have, but instead of one you have many companies agreeing on the implementation.

[1] https://github.com/Kagami/vmsg

[2] https://blog.cloudflare.com/webassembly-on-cloudflare-worker...

Re: W3C recommends WebAssembly

#273

Post by MikeHolman »

pumanoir wrote: post #158
jandrese wrote: post #80

Earlier quoted context omitted.

I guess he's saying that an unminifier tool is effectively no different than a decompiler, and both are basically unreadable without it. That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the…

That is correct, a minified JS will preserve most of the semantics of the original program. And since the original source can come from any language, how would one know which decompiler to use.

You could already compile programs from other languages to javascript.

https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

Wasm was effectively an extension of asm.js. It makes the experience of compile-to-web better, but it isn't much more opaque than other projects.

Re: W3C recommends WebAssembly

#274

Post by Someone »

thosakwe wrote: post #212
EvanAnderson wrote: post #129

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?

Consider some company running some web application for their employees that “works best in” IE 6 or, for example, Chrome, but the 2018 version.

A third party that offers a way to run that on their iPad at the cost of a one-time 100MB download will find customers.

archive.org also might find something like it useful. How else are you going to show old sites in 20 year’s time?

Re: W3C recommends WebAssembly

#275

Post by int_19h »

goto11 wrote: post #41
dm33tri wrote: post #2

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

This was also attempted for Java bytecode but didn't really pan out. I think the benefit just wasn't there compared to JIT compiling for a regular processor. The processes would have to translate the wasm into some form of register-based operations anyway, and a JIT compiler might be able to do this more efficiently since it can see a bigger picture than the processor.

JVM bytecode is very high-level though (it deals with objects, and has opcodes for method calls etc).

Wasm is in this interesting spot where it's relatively low-level, but high-level enough to allow proper sandboxing. It strikes me that the arrangements to accommodate that, like call indirection via tables, could be optimized on CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but rather a CPU architecture which is optimized to be a target for JIT or AOT compilers from wasm.

Re: W3C recommends WebAssembly

#276

Post by golemotron »

Quarrelsome wrote: post #184
IvanK_net wrote: post #178

Earlier quoted context omitted.

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…

> 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? Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just…

Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: W3C recommends WebAssembly

#277

Post by amw-zero »

simias wrote: post #107
6gvONxR4sf7o wrote: post #69

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…

You hit the nail on the head. At this point I’ve done about equal amounts of time building native apps and web apps. I’m very fortunate in that I don’t have to “pick a side” because I understand the strengths of both platforms and I try and learn from the strengths of both and apply that to whatever I’m working on.

For example I’m a huge fan of the declarative UI trend going on in the web community. Now, granted, Microsoft came out with MVVM and XAML way before React or Angular existed, but native UI libraries are so historically imperative that declarative UI wasn’t making much of a dent in the native sphere.

But even though these older native frameworks are imperative, they are much more powerful than anything like React out of the box. They’re much more comparable to component frameworks like Bootstrap, SemanticUI, AntD, etc. But even still, those libraries don’t come anywhere close to the power of Qt or UIKit in iOS. If you’ve used both, I can’t imagine you saying that it’s even close.

But it’s precisely because of the tension between the web as a document platform vs. the web as an application platform. The web has never doubled down on being an application platform, it always keeps its document roots in the background in some way. Personally, I’m torn. I love the transparency and inspectability of the web. Literally yesterday I opened up the dev tools inn twitter and I learned about its timeline architecture just from inspecting the requests. This is the biggest thing I miss when I’m working on a native app.

But WebAssembly may be the web finally doubling down on being an application platform. Whether that’s good or bad is irrelevant at this point. It’s the direction it’s headed in.

Re: W3C recommends WebAssembly

#278

Post by MuffinFlavored »

smattiso wrote: post #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 version…

> Building UIs natively on iOS and Android is so much simpler than building for the web.

I can get lit-element with no build process going to prototype something in a single .html file in probably 30 seconds. I don't think XCode/iOS developers can compete with the simplicity. Define initial state, alter it through events, pull data through fetch(), write HTML. I know for a fact iOS development isn't that simple.

Re: W3C recommends WebAssembly

#279

Post by robocat »

skunkworker wrote: post #272
nojvek wrote: post #236

The design goals of WebAssembly are the following: Fast, safe, and portable semantics: * Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware. * Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches. * Well-defined: fully and precisely defines valid programs and their behavior i…

Two of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers. About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing…

> like resizing an image

For image uploading, resizing is best done in the browser, so you are not sending large files over a limited mobile connection. The code is ugly (it also needs to fix image rotation by reading EXIF information because browsers are broken, and if supporting IE11 then there is some other voodoo).

Re: W3C recommends WebAssembly

#280

Post by zzo38computer »

robocat wrote: post #279
skunkworker wrote: post #272

Earlier quoted context omitted.

Two of the most exciting applications I've come across so far are allowing for in-browser audio encoding with a provided encoder and distributing WASM binaries to run on edge servers. About 5 years ago I tried to use an optimized javascript file to encode some audio in browser before uploading, it was painfully slow and very hardware intensive. But using wasm in the vmsg [1], it distributes the LAME encoder allowing…

> like resizing an image For image uploading, resizing is best done in the browser, so you are not sending large files over a limited mobile connection. The code is ugly (it also needs to fix image rotation by reading EXIF information because browsers are broken, and if supporting IE11 then there is some other voodoo).

The problem is that the browser does not let me enter a shell command where a filename is expected (Heirloom-mailx does allow it, and is something I often use when dealing with attachments).
Post reply on HN