3 ms·

> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes? You have to remember that HTML is predated by SGML, and that

by nupark2 15y ago

> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes? You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job. However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform. HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.* > Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed. Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product. However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al. > Or "better" yet, some real universal client that works like Display Postscript or X-Windows? Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off. Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.

mjwalshe 15y ago
People who complain that js is ugly have no idea how ugly native X development is - I am just glad that the BT/MIC deal fell through so I never had to open that can of worms.
wwweston 15y ago
> You have to remember that HTML is predated by > SGML, and that HTML and its precursors were > designed for the purpose of providing document markup. I remember. I also remember there have been people arguing all along (back into the mid-90s, at least) that this document-centric approach has been totally unsuitable for a broader platform. And yet, it's been more successful at delivering applications to the widest possible audience than any other platform. Why is that? Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years. Then explain why you're certain that having a VM instead of a browser act wouldn't erode those advantages. (This is the most important part of my comment. Feel free to ignore the rest.) > HTML has fallen over in this context; > the DOM is ill-suited towards standard > re-usable UI widget programming, I don't think the evidence is on the side of your claims. Given the sheer number of web pages and apps out there vs the number of desktop apps, the widgets built in to HTML are more widely used and re-used than most desktop API widgets, and the sheer proliferation of derived DOM-composite UI elements out there (particularly contrasted to the desktop) belies any claim of unsuitability for use: DOM elements are creatively styled and glommed together with a regularity that dwarfs anything from the desktop world. That's use and suitability. Re-use? There are also several well-known and a lot more lesser known libraries that do indeed provide widgets at higher level of abstraction. JavaScript provides ample facilities for abstracting the DOM manipulation behind object and method calls. Whether or not it's used is another question, but any developer that can't learn to do that job in JavaScript either can't do it because they're unwilling to learn how to wield JavaScript, or because they'd be unable to do it with any language and API. > JS is frustrating for building large applications How so? There are plenty of developers out there who've found that if you embrace the features the language and most runtimes offer, it isn't any more difficult to build large systems with it than any other language. Though despite that, the language seems poised to embrace some of the features from others if for no other reason than to make developers who already know another language more comfortable. > Moreover, Adobe Flash was not standardized Standardized enough that the runtime was successfully targeted by a number of non-Adobe products. > the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product. And of course, our shiny new standard VM will avoid all these problems over its lifetime. ;) > the performance profile is tremendously bad on mobile devices It's actually better than I'd expect in a lot of cases, but it's true that it's not good enough for a lot of kinds of apps. But the language is not what's causing the problem, so adding other languages won't fix it, and might introduce other problems.

by nupark2 15y ago

mjwalshe 15y ago

People who complain that js is ugly have no idea how ugly native X development is - I am just glad that the BT/MIC deal fell through so I never had to open that can of worms.

wwweston 15y ago

> You have to remember that HTML is predated by > SGML, and that HTML and its precursors were > designed for the purpose of providing document markup. I remember. I also remember there have been people arguing all along (back into the mid-90s, at least) that this document-centric approach has been totally unsuitable for a broader platform. And yet, it's been more successful at delivering applications to the widest possible audience than any other platform. Why is that? Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years. Then explain why you're certain that having a VM instead of a browser act wouldn't erode those advantages. (This is the most important part of my comment. Feel free to ignore the rest.) > HTML has fallen over in this context; > the DOM is ill-suited towards standard > re-usable UI widget programming, I don't think the evidence is on the side of your claims. Given the sheer number of web pages and apps out there vs the number of desktop apps, the widgets built in to HTML are more widely used and re-used than most desktop API widgets, and the sheer proliferation of derived DOM-composite UI elements out there (particularly contrasted to the desktop) belies any claim of unsuitability for use: DOM elements are creatively styled and glommed together with a regularity that dwarfs anything from the desktop world. That's use and suitability. Re-use? There are also several well-known and a lot more lesser known libraries that do indeed provide widgets at higher level of abstraction. JavaScript provides ample facilities for abstracting the DOM manipulation behind object and method calls. Whether or not it's used is another question, but any developer that can't learn to do that job in JavaScript either can't do it because they're unwilling to learn how to wield JavaScript, or because they'd be unable to do it with any language and API. > JS is frustrating for building large applications How so? There are plenty of developers out there who've found that if you embrace the features the language and most runtimes offer, it isn't any more difficult to build large systems with it than any other language. Though despite that, the language seems poised to embrace some of the features from others if for no other reason than to make developers who already know another language more comfortable. > Moreover, Adobe Flash was not standardized Standardized enough that the runtime was successfully targeted by a number of non-Adobe products. > the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product. And of course, our shiny new standard VM will avoid all these problems over its lifetime. ;) > the performance profile is tremendously bad on mobile devices It's actually better than I'd expect in a lot of cases, but it's true that it's not good enough for a lot of kinds of apps. But the language is not what's causing the problem, so adding other languages won't fix it, and might introduce other problems.