Comment by _qbjt | Hacker News Reader

Comment by _qbjt | Hacker News Reader

Parent Full thread

I hate to break it to you, but we're already there. People have been using the web to deliver desktop-like applications for the past decade. Over that period of time, the number of people connected to the Internet has more than doubled [1] and will continue to increase. Whether or not an application is delivered through a browser or natively is inconsequential to most of these users. If we look at the list of the most popular websites [2] we see mostly content-delivery platforms (Google, Bing, Wikipedia etc.) with some popular web apps which resemble desktop software in complexity (Facebook, YouTube, Windows Live etc.)

So we have two paths forward. One, we could try to influence the habits of billions of Internet users who use desktop-like web applications in an attempt to restore the document-based nature of the web; or two, we could provide an alternative to the artifice of modern JavaScript development which allows for better applications to be written and distributed to users that use and rely on them. The latter initiative is the more realistic and productive one, in my opinion.

WebAssembly will not lead to the end-of-times of the Internet as a content delivery vehicle. It is a net positive for the parts of the web that do not fulfill that purpose. If you're worried about the free and open web as a publishing platform, look more to governments and corporations around the world that collude to limit our freedom of expression (Facebook, we're all looking at you [3]).

[1] http://www.internetlivestats.com/internet-users/

[2] https://en.wikipedia.org/wiki/List_of_most_popular_websites

[3] http://www.theatlantic.com/technology/archive/2016/02/facebo...

> Whether or not an application is delivered through a browser or natively is inconsequential to most of these users.

This is probably the most true statement in your entire comment.

Running with the assumption that of course we should ignore the users who aren't "most" users (not a safe one).... I'd go farther, though. Whether or not these users are getting access to the utility they're looking for through:

(1) a web page with some layer of interactivity on top of more-or-less legible document semantics or

(2) whether they get it through a giant-blob-of-code SPA

is also irrelevant, right? Except to some minority of power users who can actually get more utility when someone uses a more basic semantic-document resource-oriented approach.

So it isn't the users who are driving the "let's use the web as a VM for desktop apps!" trend. It's the developers. And it isn't the billions of Internet users whose habits would need to change.

I'd guess the most ready response to this would be something like "How would you have the current Facebook/YouTube/WebMail Experience without this Desktop-Experience-Focus?" But as far as I can tell, the essentially utility involved here -- and to a large extent, the best things about the experience -- haven't really changed since a FB page was actually a legible document (a milestone we left down the road a looooong time ago).

The document-centered approach does have its limits. There are some applications it will not support. First-person shooters.... sure, deploy a black-box binary to a runtime.

Facebook, YouTube, and web mail are not really in that category at this point, and developer choices are the primary thing driving the march away from documents here.

It's only a small minority of users who are affected, but historically how much innovation happened due to the web's openness and that small minority's tinkering.

The majority of web "innovation" already existed at Xerox PARC hypermedia applications.

The web is just a worse experience of what Xerox already had.

It may be worse, but it's a lot more democratic. Now we are moving away from that two way street into something much more monopolistic.

Democracy for content, tyranny for developers (one legacy language or transpilation).

Webassembly will likely open even more doors because it'll free us from the shackles of the web's document publishing origin.

And I for one, can't wait to piss on Javascript's grave.

Bill Gates' quote fits perfectly: "Develop for it? I’ll piss on it."

http://www.quoteswise.com/bill-gates-quotes-5.html

So it isn't the users who are driving the "let's use the web as a VM for desktop apps!" trend. It's the developers.

Really? I was in a public middle school this afternoon that, just a few years ago, was having to buy expensive computers and licenses for MS-Word. Only a few could be bought, and each was its own little separately licensed, separately maintained world that easily became unusable. If a server had problems, your work required access to a specific machine. Access required lots of waiting.

And now? Chromebooks for a tenth the price (don't have to support full, expensive Widows/OSX), which they bought in order to "use the Web as a VM for desktop apps" (the horror!) such as Google's free equivalents of Word, Excel, and PowerPoint. Now everyone gets access, and they can even continue working on their own documents after school from the public library, a home tablet, or any number of other options made possible by the Web (and ever-improving hardware options).

And do you imagine that our science teacher and her students are more interested in A) "pages" about physics with "more-or-less legible document semantics", or B) live physics simulations to experiment with on their Chromebooks and phones? Are uncaring developers the only ones driving these poor users to the latter?

The problem with this "apps are oppression, simple docs for the masses!" meme is that the narrative excludes a vast number of those "underserved" who want good apps more than simple docs and need the Web-as-VM to finally make it possible.

> was having to buy expensive computers and licenses for MS-Word

how did the developers force that one upon you ?

The developers (and commercial environment) hadn't come up with anything better yet, so the local OS with local MS Word application was the best choice.

Now things are different.

> The problem with this "apps are oppression, simple docs for the masses!"

I kindof knew someone was going to confuse my argument and think I was arguing against web applications. Or against the browser as a platform.

It's a sign of how deep a certain kind of thinking goes in the industry. If we're talking orienting around semantic documents and resources.... we can't be talking about real applications! There's just no way to create interactive applications around those!

(And conversely, unless we're talking about application frameworks, lots of code --preferably not written in JavaScript, of course, which everyone knows isn't a serious language compared to Python -- unless we're working with GUI toolkit metaphors, unless the finished product simply isn't meant to ever be read by a human, we can't be talking about an actual application, right?)

> And do you imagine that our science teacher and her students are more interested in A) "pages" about physics with "more-or-less legible document semantics", or B) live physics simulations to experiment with on their Chromebooks and phones? Are uncaring developers the only ones driving these poor users to the latter?

Like the astute reader would note I said in my earlier post, some applications really don't fit inside a document/resource-oriented paradigm. Some simulations for sure, including first-person shooters and other games.

Other simulations, of course, fit rather nicely as a document with a layer of interactivity, and in that case, yes, the problem would indeed be uncaring developers. Perhaps particularly those who think interactive and semantic are exclusive.

What a wonderful story. Do those children know that everything they do on their Chromebooks is tracked and analysed by Google? Probably not, and they don't even know what tracking is or why it's bad.

They've been sold the idea that web apps and the cloud are beautiful and "free".

Same thing happens if they use Windows (esp Win 10). Did you know that when you search Google or Yahoo (using IE), your query is sent to Microsoft and stored?

http://www.youtube.com/watch?v=iGze_gjJTos&t=9m50s

We have been doing this for -decades- with Shockwave, Java applets, and Active X controls.

But they always end up abused. Everyone hates all of those, and that's good, because it causes people to steer away from them. Instead of throwing our hands up, and giving up, we should continue to try to keep those out.

The main thing I didn't like about those was that they were proprietary single vendor blobs that stagnated and ran poorly.

I guess I fail to see how the end result of this will end up any different

Considering WebAssembly is a feature that going to be standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's I'd say you have no reason to think this will end up like them.

so, IMO, I don't think any of them failed because they were > standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's

I think they failed because they were closed off, and nobody could read the shitty code, so people wrote shitty code. If we have things open, it gives people an incentive to make it look/work nice. Sure, not everyone will, but it makes it easier to shame those that dont.

You can't read the code of most C++ programs yet if operating systems dropped support for C++ there would be a reckoning.

Well, it's no different. Say, ActiveX were just x86 binary blobs. Java applets were JVM binary blobs. (Flash applets were somewhat worser kind of binary blobs with proprietary and undocumented bytecode.) WebAssembly is... again, binary blobs.

The runtime (which I was taking about) isn't a blob.

Plus minified and obsfucated JavaScript is already quite common. See closure and asm.js.

Well, my point is OpenJDK/IcedTea-Web isn't a blob either, but it doesn't make Java applets any better. Neither is Wine (which can host ActiveX controls), but I'm not going to try it at home.

And I agree that modern minified, packed and obfuscated JavaScript is also more like a binary blob than source code. WebAssembly is just a logical conclusion of this.

How long before the first WebAssembly exploit?

(And what advantage does WebAssembly have over Java applets? We've been down this road.)

The advantage? Instead of having access to a large, stable ecosystem with 20+ years of engineering behind it (Java/JVM), you'll get to use fun, new half-baked tools that barely work to build your webassembly apps.

In another 20 years time, we might be at the level of productivity we had 20 years ago with VisualBasic.

The advantage is that in time people agree about web standards.

Good luck getting Visual Basic adopted as an standard ;)

We've gotten worse.

Fun fact: Netscape promised to include vbscript in Navigator but it never happened.

Imagine you can run (efficiently) Eclipse or Lucene in any browser.

Someone try to do that with WebKit:

http://trevorlinton.github.io/

Eclipse (Che) is already coming to the browser!

https://eclipse.org/che/

Joke?

Eww. One of the most beautiful parts of eclipse is the extensive level of plugins. A browser-based IDE means more painful maintenance, more painful extensibility, and a generally worse user experience. How am I going to tie into native binaries for C/C++ compilation like I can do with eclipse as is? Or the many plugins that give static checking, etc? A web-based IDE is a step backwards.

The toolchain is C/C++/LLVM, which is pretty well baked.

The toolchain, yes. I'm not sure about the libraries - especially the ones that provide the glue to the JS world (or DOM, directly). I heard there is something, say, SDL support for asm.js or emscripten, but I don't think there's a large and stable ecosystem. More like "some stuff patched to some extent".

Oh, and I think in webdev, there is a lot of... err... modern creative and innovative guys and gals out there who are always happy to rewrite the world again, because the last week's tech isn't cool anymore.

> I'm not sure about the libraries - especially the ones that provide the glue to the JS world (or DOM, directly)

Has the Java world come up with anything better than Swing or SWT? Because those are the libraries that are in the "stable ecosystem with 20+ years of engineering behind it", and they are terrible. Give me the 'innovative' webdev guys and gals any day.

We do actually have JavaFX now, which has some has some weird historical baggage from back when it was supposed to be its own platform, but is actually pretty nice to work with from a UI standpoint.

It has a XML/CSS based way to describe the UI/layout and then lets you link that to your code with annotations. It's not perfect, but it's a lot more pleasant to work with than the likes of SWT.

"Oh, and I think in webdev, there is a lot of... err... modern creative and innovative guys and gals out there who are always happy to rewrite the world again, because the last week's tech isn't cool anymore."

well said

You really think closed source Oracle is going to make applets better? People don't like applets cause the experience sucks, the tooling generally lacks, and the libraries are old.

You say that webdev is Applet 2.0? ok sure, at least it's open and moving instead of EOL'd [1] and the experience is better else wouldn't we all still be using Applets...

[1] http://www.v3.co.uk/v3-uk/news/2443810/oracle-signals-the-en...

Oracle isn't. Sun dropped the ball.

My point is we could've embedded JVM in the browser "correctly" instead of reinventing the wheel with another byte code format.

webasm is not a bytecode format

Yes, it's an IR. It still has all of the issues a bytecode format has, and none of the size advantages.

Do you have a source that Webasm's IR won't be as compact as Java bytecode?

Cannot find PDF for Slim Binaries paper by Franz, so I cite it from memory.

They used syntax trees of program as a distribution format, compressed these trees with LZW variant and executed using simple JIT compiler (basically, tree automata over program trees). The size of Slim Binaries was smaller than JAR files for comparable Java programs. I don't remember exact percentage reduction, it was about 20-40, I believe.

It is a binary AST and is explicitly made to be both compact and fast to parse.

Not all intermediate representations are bytecode.

No it is Applet 5.0.

Applet 2.0 was Flash, followed by Applet 3.0 aka Silverlight, followed by Applet 4.0 aka ecmspriten/asm.js.

Worse than that, in 2016 it still hasn't matched what VB and Delphi were capable of in the 90's.

I am really happy that our current customer projects that I am involved with, are all native mobile and desktop applications.

Never used Delphi but after reading about it I would love an equivalent for web dev. I wrote small abstractions over Rails and or React but it's still too low level for my work.

It's amazing, really. A few years ago I was brought in to feature-enhance (80%) / bug-fix (20%) some mil-spec hardware that interfaced with some custom Delphi front-end which was acting as a controller. I was amazed at the functionality:LOC ratio along with the correctness[0] with purely pre&post Asserts[1]. The hotel industry still largely runs on one popular Delphi app that's still chugging away. Other than MS Lightswitch which is dead[2], nothing even came close re: great RAD.

(Hey, MS employees reading this - now VS Community is free-for-commercial-use, if you want to capture the 5<=revenue<=50 MM market, replicate the Delphi + VCL ecosystem for RAD apps with Azure as the backing technology. Lightswitch already let me target WPF and HTML5, with Xamarin you now have native mobile. You pushed for an "integrated" desktop + surface/tablet + cell-phone a few years too early, but Xamarin as the presentation layer and Azure as your data-store and you've got the feature set that most businesses need. You'd put me out of business, but absolutely take over that mid-market share.)

[0] Pedants, I'm one of you. No Coq was not used in this project ;) [1] http://blog.matthewskelton.net/2012/01/29/assert-based-error... Similar to this [2] http://janvanderhaegen.com/2015/01/14/its-2015-and-lightswit...

> How long before the first WebAssembly exploit?

It will happen...

> And what advantage does WebAssembly have over Java applets ?

Microsoft supports asm.js.

Well unlike third party plugins (such as java, flash, ect) wasm will be executed by the browser (like JS) and likely won't have the same privileges that java/flash have while running.

Why would WebAssembly be any more prone to exploits than JavaScript?

Because there will probably be bugs that make it possible to break out of the sandbox and run arbitrary code on the target machine. Just like Java applets.

There's no reason to suspect that browser implementors would sandbox wasm any less strictly than JS. Heck, there's no reason to suspect that they wouldn't just re-use the existing JS sandbox.

Thanks, kibwen. I'll make a stronger statement. By definition, wasm and JS are two syntaxes (initially co-expressive, wasm and asm.js) for one VM.

Do people actually read docs any longer? https://github.com/WebAssembly/ has some, my blog covered the 1VM requirement. There won't be a new "sandbox". JS and wasm interoperate over shared objects.

> Do people actually read docs any longer

No, not really. People read headlines and make pithy middlebrow comments. Though I also don't think that's a new phenomenon...

> Do people actually read docs any longer? No. People only read headlines that WebAssembly is replacement for JS ;)

> (And what advantage does WebAssembly have over Java applets? We've been down this road.)

The same advantage as Javascript, I'd assume: easy access to the DOM and the concomitant natural integration into a webpage. Java applets were like a portal into a weird world that started with a security warning and all of the widgets looked wrong.

What advantage does WebAssembly have over Java applets?

Not java.

Do people outside of "The Web is for documents only!" camp really hate Flash? I've had many good web experiences thanks to Flash (granted, mostly movies and games, but still...)

People on HN seem to discount how absolutely amazing it is to have a VM that can almost seamlessly connect to a network and pull down awesome programs!

I'm a big fan of Web Assembly but I've hated Flash for a long time. Flash apps tended to peg the CPU and shorten battery life on my laptop, even though most were inconsequential to the web pages that used them (ads). Constant security holes left me paranoid. Crashes left me frustrated. I can't count how many times that Flash crashed on me. The UI of most Flash apps left many things to be desired. From a technical perspective, it was also a deeply flawed design with a mediocre implementation from one vendor. Most video sites which use Flash seem to be far inferior to their HTML+JavaScript counterparts, only the biggest sites ever had decent flash players (Vimeo, YouTube), and I've noticed that some Flash video players can't really handle full screen video with the performance that they should. Ugh. I was glad so many years ago when Flash stopped being bundled with the OS, so I didn't need to take any extra steps to avoid it.

I find myself kind of pragmatic but I hated Flash because once it was available people used it for everything, even stuff that never needed it in the first place.

Flash is great -- I love being forced to update flash every 20 minutes.

Flash does provide a lot of nice/cool things. The problem is it was abused because it was "cool". If we could get people to use it only when necessary, then I probably would have been OK with it. Too many people end up using this in inappropriate places.

No, we hated them because their performance and UX was bad. Running programs off the Internet, safely, has long been the goal.

I guess I fail to see how this will be any safer?

But this time we do it fully open source, working everywhere unlike ActiveX, and much faster than Java applets.

I wonder if we will see ios/android apk app running in browser soon.

We already got DOS, Linux kernel, Window 95 running in the browser as very cool demo projects.

Maybe Angry bird Apk running unmodified inside browser at close to device speed would be next?

They (APKs) already do in Chrome.

Except for, security constraints, currently require that APKs are packaged as Chrome extensions, and can't be served from web directly.

> I wonder if we will see ios/android apk app running in browser soon.

or apt-get, yum or pacman...

You can already do this with App Runtime for Chrome.

Reply on news.ycombinator.com