The reality is, Javascript has problems, and smart people disagree about how to solve those problems. The proliferation of frameworks is a symptom, but the frameworks are not themselves the problem. Javascript has some quirks, that is for sure, and then, independent of Javascript, HTML/XHTML has its quirks. Most ambitious sites today are trying to deliver software as a service, but HTML was conceived as a publishing mechanism for documents. The emphasis on publishing brings in some baggage that complicates any conversation about doing HTML right. Consider the holy wars that have raged regarding the word "semantic". There are many GUIs in the world that focus strictly on visual representation and programming mechanics. Think about Java/Swing, or GTK, or Flash. Swing does not aspire to be semantic, it only aspires to give us a GUI for those who would create a GUI app with Java. GTK is the same, it is for programming environments. But Javascript/HTML is given the task of being both a programming environment and also a publishing platform, with semantics and a hierarchical document object model. This is a confusing burden to put on something that most people nowadays only want to use as a programming environment.
In the short run, I do not know what the solution is. I suspect developers will continue to invent new Javascript frameworks in an effort to create sufficient levels of abstraction to ease the pain of development for the Web. In the long run, the solution for the industry will be polyglot browsers, and polyglot protocols, that can work as a runtime and thus give developers the kind of freedom on the frontend that they already have on the backend. Despite the many brilliant minds working on the issue, Javascript is never going to work as the byte-code of the Web. Something more general is needed. On the server, the JVM gives developers a runtime that allows them to use many languages, and many different paradigms: Scala, Clojure, jRuby, Jthyon, etc. We need that kind of flexibility on the frontend. And we need protocols to support that runtime.
That sounds nice on paper. But would it not be a security nightmare and result in browser fragmentation?
I rather tell my customers to embrace HTML and a concept where a URI has a main concern and if I want to see that concern, I have to load the page. I like to build web applications that work without Javascript, but enhance the page for better user experience, when activated. (Like the old (sane) times.)
It would be so nice, if I can just mail a link or make a bookmark and when I follow that link, I don't get a firework from a client-side application that tries to magically restore state.
BTW. I have JS deactivated by default and I am not the only one (security measures, privacy, insane amounts of JS loaded by e.g. news pages). I tend to be annoyed, if the page does not work without JS.
The possibility of browser fragmentation ceases to exist in a world of polyglot browsers. You would instead have fragmentation in the sense of many languages running on the runtime, and there the individual languages would presumably have their own system of managing dependencies, just like on the JVM now.
> a security nightmare
Sandboxing becomes an issue of the runtime. Assuming there is a standard runtime, then security could be managed as it is now.
> where a URI has a main concern
Those days started to end in 2004, with Ajax, and those days have suffered further retreat with WebSockets, and will likely cease to exist as people combine more data in one place. Have you seen how many Ajax calls your typical Angular app makes to construct one page? The original concept of the URI is undermined -- instead of a scalar value, most pages are now a vector of URIs.
>I tend to be annoyed, if the page does not work without JS.
My comments are only directed to those who are trying to offer software as a service. Those are services where the Javascript must be on. My remarks have no relevance for those traditional pages that you can view without JS. However, clearly, the industry is investing a great deal in sites that work as pure software -- it is for those sites that the old ideal of HTTP/HTML as a publishing platform is a handicap rather than a benefit.
As I said, your polyglot browser idea looks nice on paper. Look at the current state of browser development and how hard it is to push standards like HTML5 or Ecmascript 6 and take a look at the differences on how and when browser vendors implement those standards. And what languages should be supported? Who provides the runtime environments? What about the different devices and their capabilities?
Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well...
Ajax made URIs more important than ever. Everyone started to speak about APIs (first Widgets) and a dissertation of a guy named Fielding became really important, because people had to (re)learn the basics of the web (and are still learning). WebSockets are for data streams and you cannot compare that to your typical browsing session.
For me, Single Page Applications are nice for Dashboards or simply pages which federate data and are open for longer sessions. I do not condemn them. What I don't like are Single Page Applications which exist for the sake of a Fatclient-like experience. It creates so much more complexity when I have to work around the limitations of HTML. Angular, Ember or ExtJS are complex and it becomes a huge dependency/constraint. You have to duplicate so much business logic, because you cannot trust the client. You have to validate everything server-side. That's why there are approaches like Dart, GWT/Vaadin or even NodeJS.
I like it the other way around - old school. Javascript to enhance, not to enforce. Take Gmail: I like to bookmark important mails. When I open that bookmark, I like to see the message. But Gmail has to boot first. And this is really optimized compared to your usual Angular application. Why can't I just see my mail - rendered with plain HTML + CSS. And when I click one (mock) button (e.g. reply), the page becomes enhanced immediately (because it loaded the necessary script in the background). We could even be better at UIs, which do not try to put as much information on the screen as possible. Another good example is Atlassian. I really like their applications. Nearly everything can be opened in a new tab. On each page, I get the main information (the concern) first and when I need more, I can get that - even with heavy Javascript support. Everything that's important uses Javascript unobstrusively. I like that. I can link/bookmark that.
If you want people or entire businesses to share links and information effectively, Single Page Apps are not the answer.
Sandboxing is hard, very hard. You would be afraid to even open a browser window if you know enough. If you like to have a strong sandbox, you cannot use plugins. You cannot even use fonts or render images - not to speak of video. Using fancy HTML5 APIs like to access file system or device sensors? Gone. WebGL, well...
But this is the case right now with "javascript as the assembly of the web". So, nothing changes in the polyglot browser VM except that non-javascript languages can target it directly rather than go through javascript.
You're obviously not the only one who deactivates javascript by default, but a quick google brought up numbers of around 1% for users with javascript deactivated. I can see why a lot of developers wouldn't be too concerned about that 1%.
It used to be that a significant portion of that 1% (and those that also turned off CSS) were from those leveraging screenreaders some years back; with the uptake of ARIA and better screenreaders, not so much the case anymore.
So there was once a definite use case for supporting them in a B2C context, at least. You still see it in .edu/.gov/.mil quite a bit as a requirement (Sec 508, et al).
I strongly disagree the solution is polyglot browsers. This necessitates not only inventing a new web language(s), but then getting widespread adoption of them.
And IF you could do all that, what would be the end result? Fragmentation. Now anyone whose browser doesn't support your new language(s) can't visit your site. Unless you create a fallback site in HTML5/JS. So you've saved yourself no trouble and only created work for yourself.
It's ridiculous. The obvious way the web has been going for 20 years and will continue to go is refinement and improvement of HTML/JS.
I want to be able to deliver a packaged application built using a proper GUI toolkit to users with the simplicity of just linking to a URL. But we've had this ability almost forever in the form of "applets"; built with Java, Flash, or even Silverlight. Obviously no one one wants to use these plugin-based platforms anymore for very good reasons (security, performance, and usability).
The problem with starting from scratch with something new is that, today, you can deliver a "pretty good" user experience using nothing but HTML and JavaScript. And it already works on pretty much every single computing device available, without needing additional software.
Along with you I've been preaching about the disconnect between a "semantic" web document and a stateful GUI app. HTML, CSS, and JavaScript combine to make probaby _the worst_ GUI toolkit in wide use today. You can even blame Microsoft for inventing AJAX[2], laying the foundation for SPAs.
But it is getting better. I look ahead to things like Flexbox[0], CSS Grid Layout[1], ECMAScript 6, etc. The platform is maturing, enabling developers to create GUIs that feel even more native. But the packaging and delivery are still "broken".
I would love to see something like Chrome Apps[3] become a standard.
I think a lot of people would agree that being able to target a vm in the browser would be really nice. The problem comes down to getting a consensus. You run into the catch-22 of people only wanting plugin-less browser support but browser developers will only integrate it if the demand is already there.
I guess the DartVM is sort of in that direction, though I seem to remember reading that it is not a ByteCode VM.
The server doesn't need to use a JVM. You can use whatever language you want and expose it via a REST API with some JSON. Typically folks go to JVM when scalability is a problem.
In the short run, I do not know what the solution is. I suspect developers will continue to invent new Javascript frameworks in an effort to create sufficient levels of abstraction to ease the pain of development for the Web. In the long run, the solution for the industry will be polyglot browsers, and polyglot protocols, that can work as a runtime and thus give developers the kind of freedom on the frontend that they already have on the backend. Despite the many brilliant minds working on the issue, Javascript is never going to work as the byte-code of the Web. Something more general is needed. On the server, the JVM gives developers a runtime that allows them to use many languages, and many different paradigms: Scala, Clojure, jRuby, Jthyon, etc. We need that kind of flexibility on the frontend. And we need protocols to support that runtime.