Hacker News Reader

Comment by baybal2 | Hacker News Reader

Yet another ActiveX-like tech re-spin, we are going back to the dark age.

Having usable and capable _SCRIPTING_ language for web was the biggest achievement of the whole Web 2.0 push, now the browsermaker is about to reverse that

View on HN

I don't disagree that we're moving further and further away from the documents with links model, but that ship has long past sailed. It wasn't just ActiveX, it was Flash. And Java. And Silverlight. And EME. And JavaScript (which, despite the presence of "Script" in the name is not just a scripting language).

Web browsers are currently (to take a reductionist view) just VMs with the ability to also view traditional HTML pages. Java had the right idea with its run-anywhere code and the JVM; it was just a bit too early to the party, and didn't have an HTML viewer to get its foot in the door.

> Java [...] was just a bit too early to the party, and didn't have an HTML viewer to get its foot in the door.

Well, it kindof had one ([1], [2], [3]). Rhino JS (still used all over the place; for example by Google's closure compiler) originated from that time.

[1]: https://en.wikipedia.org/wiki/HotJava

[2]: http://jazilla.sourceforge.net/pmwiki.php

[3]: https://docs.oracle.com/javase/7/docs/api/javax/swing/JEdito...

Oh, swing.

Java is a bad language, bad design, and bad execution.

Having more of Java in JavaScript is bad. Turning browser into a VM is just a recipe to bring pretty much every problem inherent to VMs to web development

"Microsoft’s ActiveX[1] was a technology for code-signing x86 binaries to run on the Web. It relied entirely upon code signing and thus did not achieve safety through technical construction, but through a trust model."

https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

And no one used that trust model. Every place I was aware I was using activex, even deploying it in a few places, part of the process was showing the users how how to click the "Run Anyway" or "Ignore security warnings" type of buttons. It was such a night mare for support.

The web was never composed of x86 hardware

This is wrong on so many levels it's borderline trolling. As if minifying and uglifying and mangling ASCII Javascript is so readable and accessible.

It was fine for displaying a "Hello dear user please enter your name" dialog in the 90s.

Now we are just joking ourselves pushing ASCII program code for full-blown web applications down the wire to the user.

If WASM isn't making that any better, it's not making it any worse either.

>This is wrong on so many levels it's borderline trolling

>full-blown web applications

Well, for underhanded "premium plugin" devs, this opens opportunities. I understand your position.

It does not change anything substantial about the web today. It will just be a saner output format for compilers than javascript. Unless you write compilers, nothing changes.

It does not matter weather your language compiles to JS or WASM, and it does not matter what the browser executes.

I agree with most of what you say but it is a bit extreme to say "Unless you write compilers, nothing changes".

Some troubleshooting methods will change, the ability to view source will be reduced, performance will be increase, safety will increase...

And many more subtle things. I agree it is a huge win, but there are some (minor) negatives.

There is a major negative effect - you will be running obscure blobs of code - you can't think of anything worse for security.

Sandboxing as such will not help you to any degree with that. People promoting sanboxing as a universal solution have poor knowledge of computer security

I don't know a complex web app that doesn't minify and/or obfuscate its source code.

You do not see a difference in between two?

No, not at all (practically). Either way I need a source map and/or a decompiler to read the code.

The parsed VM bytecode and calls to native code by the interpreter are two quite different things

"Each successive version will incrementally incorporate improvements to support more...features such as: Multiple return values, Multiple memories + tables, Threads + shared memory, SIMD, DOM/HTML integration, Garbage-collected object support..."[1]

It does sound like we're headed for some fragmentation here. That list will allow for other scripting languages to run on browsers without having to download a huge runtime, and to interact with the DOM just as JavaScript does. Wasm starts to look more like a multipurpose VM versus looking like ASM.

[1] https://www.w3.org/2017/08/wasm-charter

Your comment makes no sense. Of course it will allow you to use multiple languages. That's the point! Like how you can implement any language using assembly.

Sorry, but your comment makes no sense. Those features are needed for some popular languages to work well in WASM. They aren't implemented yet.

Yes, you can hack around and push an entire runtime now. There's a reason nobody is doing that. It isn't practical, performant, or a good experience.

Here's Brendan Eich's quote on the matter:

"Certainly GCC or similar could generate wasm, but I think to get to the dynamic languages, like I mentioned Dart, or Ruby, or Python, even JavaScript — that’s gonna require some extensions that I mentioned earlier, like: garbage collection hooks, JIT support, things like that. Otherwise they just won’t be competitive."

No, in no way. WebAssembly is more a tool to create a library for JavaScript and it is standard unlike ActiveX. It is possible for example to put wasm functions in IndexedDB to use them with multiples apps.

Come on, don't downvote him just because you disagree with his opinion.

That is only discouraging people from expressing their opinions.

I would agree 95% of the time, but honestly this one is just absurd.

JS isn't going anywhere? And now you can write code in lots more languages that compile down to Wasm, so that's really the opposite of a reversal.

What is a "scripting" language? At this point JavaScript has effectively become a general purpose language. And one that usually gets transpiled and then minified for production anyways. Plus, since WASM is essentially for providing libraries to JS code, is there really much of a difference to either the developer or the end user between including a JS library via npm and a WASM library?

A scripting language, is a language whose main utility is to manipulate and run functions provided from outside of its execution environment

I'm siding with baybal2 on this one. No matter how much you're wishing to use your favourite language on the Web, WASM is at best unnecessary, as the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser? The only reason I can think of is because software/game publishers want to control your usage even more.

But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]. Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc. Not to mention content will only work on the bundled WebKit version.

WASM is user-hostile and anti-Web. What does it even mean that W3C "approved" a working group? I thought WASM was a WHATWG thing. W3C shouldn't lend what's left of its credibility to it.

[1]: https://trevorlinton.github.io/

> Say goodbye to content linking, sharing, saving, translation, accessibility, ad blocking, etc.

That is already posible without WASM. But it's not done because it hurts search engine scores.

> the kind of application it enables (near-native speed) can be had with ordinary native apps as well. Why does something like that have to run in the browser?

For the same reasons all the other kinds of web applications are not developed as native apps as well. Hint: it's not only about speed. Some of the main reasons web apps are winning over native apps is easy of distribution, updates and being multiplataform. And it's being increasingly harder to force javascript to behave as a general application programming environment.

> But it doesn't stop there: the worst possible outcome of WASM is that entire custom browser runtimes are being pushed to you [1]

If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become? At the moment it is one of the most complex pieces of software out there. It is so hard to build a modern web browser from scratch nowadays that doing so as a hobby would take a lifetime. This takes the power away from individual developers, since it's not very realistic to build a new browser unless you are a big corporation with money to spare.

This situation also poses a big problem for the development of new operating systems. If your shiny, awesome, new research open source OS does not have a modern web browser, it will never reach wide adoption and thus never atract enough developers to build critical mass. The alternative is to make your OS compatible with POSIX and thus reuse the work of others so that you can build existing web browsers. But then you are most likely bound to become just another unix/linux alike, thus hindering innovation.

> This situation also poses a big problem for the development of new operating systems.

I am currently developing a new kind of operating system using nothing but web technologies (ie, it is technically a single-page web app). It might not be the same kind of legacy hardware-centric operating system that most techies fret over, as I am just interested in "userland" ideas (ie, what new kinds of applications can we build, using what new kinds of higher-order abstractions). IMO, the kinds of research programs you are thinking of are really, practically speaking, solved problems.

Also, my OS is compatible with POSIX, as it is the first (that I know of) Javascript implementation of IEEE Std. 1003.1 (Shell Command Language).

The project is called "Linux on the Web" :

- https://linuxontheweb.org

~or~

- https://linuxontheweb.appspot.com

As individual developers, we really need to start thinking of web browsers as the hardware layer, virtualized as it may be. Just as the scripting languages of the early 90's allowed us all to start thinking at higher levels at the language layer, modern web browsers allow us to start thinking at higher levels at the OS layer.

If we ever come to the point where all you need to develop a web browser is a wasm vm, don't you find exciting how much simpler a web browser would become?.

But you're not removing complexity, just moving it into the wasm-based runtime, and in the process it removes the power that comes with building the browser, which is shaping how the user sees and interacts with websites.

If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.

Because not all websites need all the complexity built into a browser. And wasm does necessarily imply that we need to leave html and css behind. But we get the freedom to choose and build better options.

>If every website is a blob of code that you have to execute as a black box, what's the point of writing your own browser? It'll just be a slower copy of every other, since all the potential for making it different has been taken away.

A very insightful comment

If that's the case then OTOH an argument can be made not to cram any more functionality into web browsers, such as entire language runtimes.

Browsers are becoming out of control behemoths.

You are basically saying we shouldn't bring good scripting environments into the web, because if we do, people will use them.

As much as I hate all the "javascript required to render text" sites out there, I can't agree. Scripting has its uses, and a proper environment will not only make it easier to deal with those accessibility and compatibility problems, it will also make it easier for browsers to sandbox those scripts so they won't mess with your computer.

> can be had with ordinary native apps as well.

Ordinary native apps are not safe.

Was going to reply something something about sandboxing but then I realized: If we're going to sandbox native apps, I'd rather it be done by a cross-platform standard like wasm instead of done differently by each vendor.

The fact is, this web assembly stuff could be seen in some ways as a response to the walled gardens being built by each vendor right now. I prefer native apps too, but if we're going to have walled gardens, why not one big one we can share.

Ah ok, I didn't see it from that PoV, I'm not into third-party apps on my phone. Speaking of which, do you believe Apple will allow running WASM apps on iOS?

Haha no idea, I wasn't even thinking of phones at all, but I guess it's a consideration too.

I'm a fan of anything that will help ease the pain induced by the ever-growing Electron cancer on the desktop. Hopefully this will catch on before I need 64GB of RAM...

Native apps are not compatible across platform. But more importantly they can't be safely installed by the user. I don't want to install your websites app because I have no way of knowing it won't give me a virus or drain my battery. How does that let "software publishers control my usage even more"? It takes a significant amount of their control away by putting them in a limited sandbox.

Wasm is the first time we will get cross platform and fully sandboxed native speed code.

None of what you speak of has anything to do with wasm. You can do all that just fine with JavaScript. We've had that world ever since browsers allowed disabling right clicking. Even before js, you could always distribute your webpage as an image if you wanted that. Wasm just let's you run code faster. It doesn't change anything.

You are unaware of issues with sandbox.

Here they are:

1. A sandbox can have bugs, and they do have them

2. Sandboxed environments have to give huge reach of system api's anyways, and you can do a lot with them

3. There are classes of vulnurabilities that sandboxes can't do anything about: instruction level exploits, hardware bugs, "gpu frying webgl shaders"

4. Human factor (see comments about "run anyways" above)

All of that applies to JavaScript again. Wasm is just lower level and simpler. If anything it should be significantly easier to sandbox because of its simplicity. It doesn't provide any more access to Apis or anything than JavaScript does.

Some sandbox is better than no sandbox. When's the last time somebody delivered ransomware through the browser without a user explicitly opening a downloaded file?

I agree its antiweb. But as these clowns at Google and Microsoft try to figure out ways to guarantee their long term employment, whether its through the appstore or this kind of bullshit - one thing they don't realize is most ppl have enough disk space on hand to store most of the useful internet and enough processing power to index it themselves. People really don't need the crap that is called the internet today. Just check out what kiwix can do and ask yourself what browser makers are trying to do.

Reply on news.ycombinator.com