Instead of yet another .js to run * in the browser, maybe we should return the web and browser back to it's pure days of marked up text documents with images and move "web apps" to a generalized, native runtime designed explicitly to run dynamically fetched untrusted code. Might be better than the current mess.
Edit:
And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.
Yeah, except not completely broken with shit like "let's run python in the browser with javascript!" and "let's animate UI components originally designed to be static with an overloaded scripting language!" and a million other things. The browser and web were originally designed to view webpages (read documents) and not run arbitrary untrusted code...
tl;dr you are making the point I refuted in my original post.
Browsers have evolved into exactly what people wanted Java for all along. Except it evolved from the wrong base. Kind of like if an elephant evolved to have intelligence and communication like ours instead of monkeys. That's pretty much the DOM & JS.
I think taking this sentiment to its conclusion is a bit more of a drastic change than that.
It would mean the end of the web, not a return to its beginnings. You wouldn't be dealing with marked-up text, you'd be dealing with binary files (text markup, of course, being a subset thereof). The internet (and whatever emerged on top of it to replace the web) would then be concerned with content, sharing, and identity management only, and applications would be built on top of that.[1]
The trick, as you said, is how to securely run untrusted code. That's what the web (well, I suppose more technically, browsers) are trying to solve; the problem is that the same origin policy, which is at the core of web security, just doesn't work very well. There are a lot of examples where this breaks; here are three off the top of my head:
1. Tracking using javascript to look for unique browser identifiers
2. XSS, CSRF, etc
3. Legitimate cross-site communication
So clearly our existing solution to the "how do you securely execute dynamic, untrusted code" problem isn't cutting it. There's a lot of research (and production code, for the record) going into potentially better approaches though, so I think it's likely we'll see change, if we can get past the inertia behind today's hairball.
[1] Incidentally this is exactly the approach we're taking with implementations of the Muse protocol (https://github.com/Muterra/doc-muse), which uses encryption to provide private content/sharing/identity management on untrusted servers.
While I completely agree, since it will never happen, why not strip javascript out of a browser (FF?), come up with a new catchy name, and market it as a safe browser. Just need a catchy name..., hmm, maybe Lynx? ;
No, he means a properly done sandbox but native and 2D accelerated platform without the DOM cruft.
Not sure why it's so hard, probably because it's in nobody's interests but the users (as every major just wants to promote their own platform and have the web play second fiddle to it).
Then again, a top tier BMW doesn't sound so different than an Edsel either. They both have internal combustion engines, 4 wheels, a steering wheel, and they take you from place A to place B in similar speeds (in orders of magnitude).
That's because you're focusing on the similarities which don't say anything -- what's important in all cases are the differences.
Which in this case are mostly about the implementation.
- the UI wouldn't be a part of a page, it would be THE page.
- it shouldn't be an over-engineered mess of a GUI toolkit like Swing.
- it should offer modern and capable widgets, instead of the bizarro, limited and uncanny value one's that Swing offers (if you don't get into intricate customization of your own).
- it should be faster than the web app it replaces -- applets were often slow to load AND slow to run.
- it shouldn't be controller by a single company.
- it shouldn't be proprietary.
- it should, if possible, cater to many programming languages.
- it should play natively with the HTTP model, AJAX etc.
In the sense that Cocoa or Windows top level window hierarchy is also like a "canvas element".
In other words, like a canvas element which has a full, comprehensive, standard UI library with tons of standard, pre-built widgets (not just the meagre web form controls), including a full featured text widget with all the trimmings, plus a free drawing component of its own (for totally custom UIs and controls).
I think java apps failed to achieve more mainly because they didn't have decent access to the DOM, and the HTML rendering engine that goes with it.
IMHO that's the killer app of the browser... for all it's faults, the HTML+CSS rendering engine is a superior UI description api than anything previously devised.
I remember the brief period I wrote some java apps. The main pain was choosing between rendering a native java gui, or establishing hooks to have it instrument an html interface from behind the scenes. The native gui had better connection to the code... whereas using the DOM was insanely flexible, but talking to the DOM was like trying to drive a car by reaching through the tailpipe.
That I think is why java apps never prospered (outside of the whole "loading" issue... which could have been optimized away if the motivation was there).
---
JS currently has the best of both worlds, and not because of anything native to the language (though it does have many positive points).
I feel like WebAssembly, and things like PyPy.js, are a step in the right direction. Making the DOM and HTML+CSS just another ui library available to the language of the moment. Having PyPy.js is great, because (I assume) where PyPy's python goes, all the other pypy interpreters (Hippy, etc) can follow.
> IMHO that's the killer app of the browser... for all it's faults, the HTML+CSS rendering engine is a superior UI description api than anything previously devised.
Except it's horrifically slow. It was never designed for widespread dynamic update, and to work around it we have to go to great lengths like having a virtual DOM. Combine that with the widespread incompatibility of different implementations, and I have trouble seeing it as a good UI framework at all, let alone a superior one.
As a communications platform, sure. As an application platform, I'm not sure I agree. I have used many actual applications packaged as .jar files. They're generally more featureful and performant than we have come to expect from web apps[1]. As a platform-independent, single-file distribution format, Java actually works very well.
Java wasn't ever intended to compete with the Web; it was the Web that got ideas.
Honestly, the things people did with applets probably haven't been replicated by JS in the browser, especially when native got involved (if I'm remembering correctly).
Nobody is stoping you from making a browser that doesn't run JS at all.. nobody will use it, but nobody is stopping you from doing it... there's several decent rendering codebases you could strip JS out of and disable by default. Of course you won't be able to get to most content, but hell, it will be PURE.
I agree that there is a mess, but what kind of mess is it? What about it makes it a mess? Is perhaps because the JS interpreter is embedded (the DOM calls it)? Is it that the DOM is poorly suited for what we used to call "rich" internet applications? Or is it Javascript itself that is the problem?
The main problem with the DOM API is that when used from JS it's a pain, because it was designed largely by people wanting to do DOM in XML documents in Java on the server side; the use on the web was considered less important at the time. Many of the resulting issues (e.g. lack of use of options objects when it would be appropriate, numeric "enums" etc), flow from this historical accident.
Very easy to have all kinds of memory leaks right now for one. It is really a combination of Javascript and the DOM. Unpleasant to use is definitely a big thing too. If it was easy and pleasant, nobody would complain.
Is it really easier to have memory leaks here than in any other garbage-collected language with first-class functions and closures? If you stick references to objects somewhere permanent, you will leak them. If you don't, you won't....
The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.
Back in 2005 Gecko (Firefox) had issues like this too, but a cycle collector was added in 2006 that handles this sort of problem.
For DOM nodes issues like this basically don't happen in modern browsers.
There _are_ still some existing bugs of this sort in browsers for objects other than DOM nodes (especially WebKit and Blink; modern IE and Gecko are way ahead here, though Blink is actively working on fixing this in their implementation). But you typically have to work quite a bit to hit these cases; all the common cases are handled correctly because otherwise pretty much any web site you left open for an hour or two would use up all the RAM on your machine.
I do agree that if you have to worry about compat with old/unpatched browser versions then you run into some serious problems with this sort of thing. If you have to deal with that, you have other serious problems too, of course.
And, again, the source of all the "leak while the website is live" behaviors I have seen recently is websites doing things like sticking more and more stuff in global arrays. That's just a basic no-no in a garbage collected language, obviously.
IIRC it was particularly hard for MS to improve on (got much better starting with IE8)... I worked on an extjs app around 09 that would just eat itself in IE6 (the corporate browser at the time) if the app was open more than 3-4 hours. It was pretty bad.. FF didn't have any issues at the time, and could run open all day. Even then, still much better than the late 90's, when the NN/IE4 browsers were still hanging on, and needed to be supported... that was anti-fun.
Edit:
And to all those thinking "but that's the browser", that's my point. We have the browser and while it works, it's incredibly broken in a lot of ways. I'm proposing a system designed from the ground up to do the job that the browser has currently been hacked and add-on'd into doing.