8 ms·

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 fram

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.

cdnsteve 12y ago
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.
- jbergens 12y ago
  Nowdays they actually go javascript (Node) on the server for a lot of performance things. It is really fast for some things.
einrealist 12y ago
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.
- smeyer 12y ago
  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%.
  - dietrichepp 12y ago
    The 1% includes a lot of crawlers, although not Google's.
  - einrealist 12y ago
    That is sad in a way. I expected the number to be much higher. I am interested in to know why the majority does not use Javascript blockers. Here is a source for the 1%: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
  - vanadium 12y ago
    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).
jgrowl 12y ago
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.
ebbv 12y ago
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.
daigoba66 12y ago
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. [0] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi... [1] http://dev.w3.org/csswg/css-grid/ http://dev.w3.org/csswg/css-grid/ [2] http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp... [3] https://developer.chrome.com/apps/ https://developer.chrome.com/apps/

cdnsteve 12y ago

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.

jbergens 12y ago
Nowdays they actually go javascript (Node) on the server for a lot of performance things. It is really fast for some things.

einrealist 12y ago

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.

smeyer 12y ago
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%.
- dietrichepp 12y ago
  The 1% includes a lot of crawlers, although not Google's.
- einrealist 12y ago
  That is sad in a way. I expected the number to be much higher. I am interested in to know why the majority does not use Javascript blockers. Here is a source for the 1%: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
- vanadium 12y ago
  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).

jgrowl 12y ago

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.

ebbv 12y ago

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.

daigoba66 12y ago

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. [0] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi... [1] http://dev.w3.org/csswg/css-grid/ http://dev.w3.org/csswg/css-grid/ [2] http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp... [3] https://developer.chrome.com/apps/ https://developer.chrome.com/apps/