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.
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.