Hacker News Reader

Comment by black_puppydog | Hacker News Reader

> The original, native code is extremely fast. Way faster than most applications need.

Faster than any one application needs. But virtually anything I do nowadays uses crypto on some level, and wasm isn't only proposed to be used for crypto either. Suddenly, my CPU has to do 2x to 7x the work for the same code, because we collectively decided that using electron and web stuff if the way to go for nearly every mainstream application? I don't think so, really.

WASM seems to me like some people are simply longing for the old days of flash. I don't see why I'd want it.

View on HN

WASM makes some sense in the browser, but what horrifies me about it is that it is going the way of Electron.

The usual pattern:

1. Instead of figuring out how to do things well in the native space, developers hack something together from web technologies, because it's "simpler".

2. They realize it doesn't work all that well and reinvent some aspect of native environment to fill the gaps.

3. They backport all the complexity back to the web, because they want to run one codebase everywhere.

This is incredibly backwards. We get bloated faux-native apps that use abstractions that make zero sense outside of the web context. We get web technologies that are bad approximations of what has been done reasonably well in the native space. Finally, we get more and more complexity with each iteration.

---

BTW, does anyone remember how Alan Kay said[1] browsers should be designed to be like mini operating systems? Does anyone remember how many people said he is wrong and doesn't understand the web? Well, browsers increasingly are used as an operating system, except it's a system formed by accretion, not by deliberate design. So maybe, just maybe, people should pause, listen to Kay and read up on how similar problems were solved by very smart people before us, instead of just adding more and more web-ducktape to everything.

https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1405s

OK, but wasm is a pretty "boring" VM; it's a reasonable design you could easily arrive at by only considering native code. People are acting like this result indicates that wasm is fundamentally misdesigned, rather than that it simply doesn't yet support SIMD and has a relatively immature compiler compared to GCC and Clang.

I don't think it's fair to quote "2x to 7x slower". What's exciting about WASM is that is has a lot of potential to get close to native performance, a lot of the tricks just haven't been applied yet.

EDIT: just to support my claim, here is an example of a WASM runtime implementations that run 4x-6x faster than others: https://github.com/perlin-network/life#benchmarks

It definitely has a lot of potential for gaming, look at the unreal engine port. Even if that's all it really ends up being, that is still a pretty big deal.

I've been wanting to use it for some b2b applications, or maybe for some reports/charts. Just in places where it makes sense to need that power, but you'd want it in a browser.

Actually I'm really excited about wasm and WebGL inside of the browser. One build target to rule them all. But we're still far, far away from utopia.

Unreal and Unity web builds are not production-ready yet. The cross compilation can be brittle, compile time is huge, the resulting assemblies are large and memory consumption is just too high.

This leads to many, many problems, which are hard to diagnose. Getting games to work on mobile browsers consistently is nearly impossible. For example, last time I checked, Chrome on Android disables WebGL by default and limits memory to 64mb.

Unity is working on "Unity Tiny", but it's in alpha state. Frameworks like Three.js are better suited, but more barebones. Still a long way to go...

I think your Android info must be out of date or specific to certain hardware.

Yep, I have seen it.

"Stage3D - The Demo of Porting Epics Unreal Engine to Flash"

https://www.youtube.com/watch?v=_EBxd2tFEvU

> I don't see why I'd want it.

It lets web devs use languages other than JS on the frontend. That's primarily why I'm excited about it.

As for why electron, the only real explanation I've heard from people that makes sense is the ease with which you can put together custom UI controls and style them. All of the desktop UI systems are great at the simple things, like putting default OS controls in an app, but complex things like creating custom controls, animations and complex styling appear extremely difficult to accomplish. At least, that's the way it seems to me.

And here I am just wishing for table cells and list views on the web that have functional mouse selection.

Not sure if this is what you meant, but try holding the Ctrl key while selecting.

I’m launching this as part of an app platform soon-ish. If you’d like to beta test get in touch. Virtual tables and lists, with keyboard and shift/command selection modifiers, click and drag to select, edge scrolling, sorting, etc. All with a couple lines of code!

Did you had a look at Qt? It can do best of both worlds

I'm having a hard time finding a good, comprehensive comparison between Qt and Electron. My current understanding (which is probably wrong) is that Qt isn't much smaller than Electron itself and I would need to use C++. The animations do not look simple or easy to understand at all, but that's just a first glance.

QtQuick, at first glance, is weird. It uses JS and the animation transitions look pretty close to css transitions.

I guess what I'm looking for here is: how is it a clear win over electron other than just raw speed?

Maybe I'll make a non-simple app in both electron and QtQuick and see how they compare in terms of ease of development, development speed, app size, ram usage and "speed".

You don't need C++ with QML.

https://github.com/qmlnet/qmlnet

I used it at work on my embedded devices.

https://medxchange.com/4klear-all-in-one-camera-recorder/

I highly recommend it. PS: I'm the author.

> WASM seems to me like some people are simply longing for the old days of flash

In what way is WASM like Flash? One is a proprietary IDE with a VM to run it and the other is an open bytecode standard.

gee let me think:

1) increases the attack-surface[0] of the browser (arbitrary code execution in victims browser)

2) wasm shares some of the same vulnerability classes from native applications (thanks to code generation frameworks that allows you to spit out wasm in addition to say C - see Nim & others offering generation via llvm backend)

3) cryptographic verification of payloads is still not possible (afaik)

4) binary blobs from untrusted sources which isn't auditable in the way javascript is (raises the bar for security researchers to identify malicious payload, or really just anyone who want's to audit / poke around)

5) thanks to 1+2 wasm shares the same pitfalls as JavaScript when doing crypto in the browser.

6) all of the above works over plain HTTP links (hurray)

7) assumes that security/integrity can be derived from language subsets and a few rules to prevent specific type of behavior[1]

[0] https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-...

[1] https://webassembly.org/docs/security/

[2] https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...

edit: link to current CVE's

Oh sorry, I thought you were comparing it to other alternatives, I didn't realize you meant WASM is worse than not running code at all. Yes, I agree.

Yeah. Like... Markup languages meant to describe things, then leave rendering to the client. It's gonna be fun once our adblockers become useless because the "Web" apps are essentially blobs that do all the presentation for us. Oh and good luck making that barrier free

most adblockers work by blocking network requests to ad domains, there is nothing wasm can do here. Regarding a canvas site the difference is purely in performance.

Note that integrity checking is supported and used in many sites. Given that, using HTTP does not matter. (Of course not for the main page.)

that 4) holds is not so clear to me, being auditable was one of the design goals.

I think perhaps you and the GP are defining auditable slightly differently. There's being able to look into and figure out what the code you wrote is doing because you have source maps or pre-compilation source, and then there's being able to see what third party code that your browser is downloading and running is doing. Given how hard that can be with JavaScript and obfuscation, I imagine an obfuscating compiler for WASM can do quite a bit if you're willing to take a performance hit on the running code. And something tells me that the entities most interested in obfuscating what their code is doing are more often than not likely to not care too much about the CPU and battery life ramifications of making their code less performant.

1. Perhaps, but we already have JavaScript, and WASM has much less access than JavaScript at the moment. It's definitely something to watch as WASM gets more integrated. 2. Sure, it is intended for native-type development in the browser. In fact, the easiest languages to get started with are C, Rust, and Go IMO. 3. If it's being sent over TLS, you know that it hasn't been tampered with in flight, no? So it is functionally equivalent in this regard to JavaScript. 4. Have you tried to audit obfuscated JavaScript? If that's acceptable, you can do the same with the tools provided for WASM. 5. Yup. However, as I mentioned earlier, TLS removes the ability for things to be tampered with in flight, which means you'll need to trust the server (and the browser). Since that's always the case, I'm not sure what you want to see different here. 6. So don't use HTTP and only use HTTPS? Browsers are moving toward making that look more scary to the user, so it's a browser problem, not a WASM one. 7. No, it assumes the sandbox can prevent security issues. The language subset stuff is to help developers write more reliable code. It won't eliminate crashes from faulty code, it'll just make those easier to spot.

Those CVEs mostly look like problems in the sandbox, which will mature as WASM gets used more. Those types of things point to immaturity in implementation, not design AFAICT.

Just like Flash.

http://adobe-flash.github.io/crossbridge/

Reply on news.ycombinator.com