Putting up with Javascript

Sylvain Hellegouarch wrote in "Client side application frustration"

I don't want to start a flame or whatever so I'll only say that Javascript is far from being THE solution for clientside application IMO. Don't get me wrong, the language itself is interesting and powerful enough for most things you might want to do, but the environment (the browsers) in which it sits is quite not there yet.

It looks like Javascript has never been seen as something browser vendors should pay much attention. So they did implement what the ECMA group had specified but with some variations which doesn't allow the developer to ensure everything will work the same way. For too long Javascript was seen as a toy for doing rollover menus or spamming you with popups all over the place.

He was trying to write a Weblog engine with a lot of the code in the browser and ran into endless portability problems, as well as security concerns and lack of friendly developer tools.

He also tried looking beyond Javascript.

Then I decided to look at SVG, XForm and the WHATWG effort but again I felt frustrated. Those are very well specified but have such a bad support (or none) amongst browsers that they are almost unusable. Should I come back to Java applets? sigh

And he finishes with a question:

So my question now is about the future of client side development, we do have a lot of different choices but there are no clear vision for the average joe like me on which one to focus on neither on how they will cooperate in the future nor what will be the support amongst browsers. Maybe people in the know could clarify things?

Kurt Cagle took up the question in his piece "Is Javascript Dead?", providing some historical perspective and exploring some code patterns as a way to illustrate the language's flexibility.

Javascript has traditionally been considered a lightweight language - useful for web pages, but not something appropriate for larger scale applications. There is some justification for this viewpoint - Javascript is almost invariably interpreted, meaning that it cannot optimize content cleanly prior to running it. While it does have classes (in the sense of functional prototypes), Javascript has no obvious concept of a package, which means that higer order organization can prove complicated and likely to impinge upon namespaces. There are, however, ways around this.

Kurt goes on to show an example of Javascript's elegance by turning what most people write as gruesome forms element processing logic completely inside out, and mapping events quite naturally to classes and functions. He concludes:

I think the final point of all of this is that, far from being too primitive for use with existing technology, Javascript is in point of fact still very relevent, and if anything is finally reaching a point where it can hold its own against just about every other programming language out there, at least within the domain of the manipulation of DOMs (or XML). Given the incipient emergence of E4X, I fully expect Javascript to become one of the predominent languages on the planet.

Kurt doesn't touch on Sylvain's concerns about portability, security and development environment, and those are still matters that need serious discussion (for one thing, they are issues that have always interfered with my productivity in Web development). I see Kurt's post as a bit of advocacy to underscore for developers why some of the pain is worth enduring. I look forward to more posts on the topic.

[Uche Ogbuji]

via Copia
Upvote Upvoted 0
8 responses
Kurt has extended his first message:

http://www.understandingxml.com/archives/2005/09/sleep_javascrip_1.html



Regarding my questions about security and portability, Kurt has still not really found any direct answer as I commented there : http://www.defuze.org/oss/blog/entry/2005/09/10/javascript-revival



Now I don't think Kurt hasn't answered because he's hidding something but in fact because altough he knows the technology is there browser vendors have yet to jump on the wagon. :)



- Sylvain
— Sylvain Hellegouarch
Copia Kurt doesn't touch on Sylvain's concerns about portability, security and development environment, and those are still matters that need serious discussion (for one thing, they are issues that have always interfered with my productivity in Web development). I see Kurt's post as a bit of advocacy to underscore for developers why some of the pain is worth enduring. I...
— Trackback from Main
My response to the original post covers how XForms addresses the specific issues of security, portablity and the like.  In addition, how XForms simplifies the process of building UI applications and completely alleviating the need for Javscript itself.
— Chimezie
I find it amusing that somewhere along the line I have become the defacto evangelist for Javascript's superiority as a language. This was certainly not my intent, nor has it been to claim that Javascript is the ultimate be all and end all of languages, only that it serves very well in certain circumstances as a general binding language as we move forward into a realm where binding languages are becoming increasingly important.



To be blunt, I would prefer to see a Python interpreter being standard issue in all browsers rather than a Javascript one, as I believe the language to be much more expressive, more object oriented, more secure, easier to write, and in general better suited to contemporary needs. Unfortunately, browsers in particular are informed as much by business and political decisions, some, perhaps even most, based less upon the best technology for a problem and more based upon what will provide the best backward compatibility to insure that existing websites do not break or that download sizes remain under some critical value.



This reality means that Javascript, while not perfect, will continue to be the language of choice for browsers for the foreseeable future. It's a frustrating reality at times, in very much the same way that HTML is a frustrating reality that will continue to be outside of the XML realm for some time to come, regardless of the known deficits of that language.



My hope is that somewhere along the line (perhaps with my own browser) a strong enough business case can be made for advocating a Python solution in conjunction with a Javascript one as the default case in a browser that we can alter the typically glacial pace of browser development, but until that day comes where Python becomes the de facto standard in most browsers, then the issue is not whether Javascript is a better technology, only whether there are things that can be done to Javascript to make it gooed enough to get the job done in the browser.



There are two additional points brought up by Uche Ogbuji that I should address. Javascript is like any other language - it has a formal (reasonably well defined) specification - but it is only as portable as the degree to which the implementations adopt that specification. Obviously, Microsoft has been a major factor here in retarding the adoption of Javascript in their efforts to retain the standard for their own web environments, and it is in fact the overwhelming weight of subsequent developments that are finally showing the folly of this strategy. Most browsers outside of Microsoft have adopted much if not most of the feature set of Javascript 1.5, but keep in mind that even here, browser are generally released on a minimum of an eighteen month time frame.



I would contend that if Python instead of Javascript were the default language of choice in browsers, it too would be subject to this same balkanization. Purity of language discussions aside, the price of such fame is that very balkanization, especially when there is an antagonistic implementer in that space with the clout of a Microsoft.



I am a major advocate of XML, precisely because it is much more difficult to isolate a language when a mapping is essentially an XSLT transformation away. For this reason, XForms is a very attractive model to be moving towards, certainly, and I look forward to the day that I can build XForms applications that work in all browsers equally. However, XForms is not even remotely widely implemented yet nor are there standard forms of declarative binding languages along the lines of XBL (sXBL is getting there, but so far there are perhaps two still very much test implementations in existence).



However, even that will not eliminate the need for an imperative language at some point in the equation - from personal exerience, declarative solutions can usually solve 80% of problems very well, and is hideously inappropriate for the remaining 20%.



I'm hoping within the next two years there will be a browser that supports Python - with my suspicion being that it will likely end up being Mozilla Firefox (I know of some efforts in that direction). I cetainly hope with my own efforts to see Python in certain other browsers as well (getting ActiveState directly involved with the Mozilla (or Netscape!) development team makes the most logical sense here, but again there are business realities that sometimes transcend what SHOULD happen).



Until then, I think we need to look upon Javascript as being the existing reality for some time to come, for all its warts and ideosyncracies, and work to improve it as much as possible in places where it can be.



Kurt Cagle
— Kurt Cagle
I find it amusing that somewhere along the line I have become the defacto evangelist for Javascript's superiority as a language. This was certainly not my intent, nor has it been to claim that Javascript is the ultimate be all and end all of languages, only that it serves very well in certain circumstances as a general binding language as we move forward into a realm where binding languages are becoming increasingly important.



To be blunt, I would prefer to see a Python interpreter being standard issue in all browsers rather than a Javascript one, as I believe the language to be much more expressive, more object oriented, more secure, easier to write, and in general better suited to contemporary needs. Unfortunately, browsers in particular are informed as much by business and political decisions, some, perhaps even most, based less upon the best technology for a problem and more based upon what will provide the best backward compatibility to insure that existing websites do not break or that download sizes remain under some critical value.



This reality means that Javascript, while not perfect, will continue to be the language of choice for browsers for the foreseeable future. It's a frustrating reality at times, in very much the same way that HTML is a frustrating reality that will continue to be outside of the XML realm for some time to come, regardless of the known deficits of that language.



My hope is that somewhere along the line (perhaps with my own browser) a strong enough business case can be made for advocating a Python solution in conjunction with a Javascript one as the default case in a browser that we can alter the typically glacial pace of browser development, but until that day comes where Python becomes the de facto standard in most browsers, then the issue is not whether Javascript is a better technology, only whether there are things that can be done to Javascript to make it gooed enough to get the job done in the browser.



There are two additional points brought up by Uche Ogbuji that I should address. Javascript is like any other language - it has a formal (reasonably well defined) specification - but it is only as portable as the degree to which the implementations adopt that specification. Obviously, Microsoft has been a major factor here in retarding the adoption of Javascript in their efforts to retain the standard for their own web environments, and it is in fact the overwhelming weight of subsequent developments that are finally showing the folly of this strategy. Most browsers outside of Microsoft have adopted much if not most of the feature set of Javascript 1.5, but keep in mind that even here, browser are generally released on a minimum of an eighteen month time frame.



I would contend that if Python instead of Javascript were the default language of choice in browsers, it too would be subject to this same balkanization. Purity of language discussions aside, the price of such fame is that very balkanization, especially when there is an antagonistic implementer in that space with the clout of a Microsoft.



I am a major advocate of XML, precisely because it is much more difficult to isolate a language when a mapping is essentially an XSLT transformation away. For this reason, XForms is a very attractive model to be moving towards, certainly, and I look forward to the day that I can build XForms applications that work in all browsers equally. However, XForms is not even remotely widely implemented yet nor are there standard forms of declarative binding languages along the lines of XBL (sXBL is getting there, but so far there are perhaps two still very much test implementations in existence).



However, even that will not eliminate the need for an imperative language at some point in the equation - from personal exerience, declarative solutions can usually solve 80% of problems very well, and is hideously inappropriate for the remaining 20%.



I'm hoping within the next two years there will be a browser that supports Python - with my suspicion being that it will likely end up being Mozilla Firefox (I know of some efforts in that direction). I cetainly hope with my own efforts to see Python in certain other browsers as well (getting ActiveState directly involved with the Mozilla (or Netscape!) development team makes the most logical sense here, but again there are business realities that sometimes transcend what SHOULD happen).



Until then, I think we need to look upon Javascript as being the existing reality for some time to come, for all its warts and ideosyncracies, and work to improve it as much as possible in places where it can be.



Kurt Cagle
— Kurt Cagle
I've taken the body of these comments and expanded on them a little farther in my own blog:



http://www.understandingxml.com/archives/2005/09/javascript_and.html#more



-- Kurt
— Kurt Cagle
re: XForms wide implementation



I beg to differ.  Though it may be true that it doesn't quite have the traction that Flash has at the moment, I wouldn't go as far as saying it isn't remotely, widely implemented.  There are several very mature implementations (listed here in order of maturity):



formsPlayer

XSmiles

Chiba

Mozilla

Deng



re:delcarative binding languages



I wholeheartedly do not see the value in a seperate delarative binding mechanism/language when XForms native binding mechanism is about as solid as the component it is completely based on (XPath).  I have yet to come across a situation (and I've pushed the spec to it's limits in attempting to do alot of the things that a few years ago could only be done via unportable,undecipherable javascript) where the ability to bind to the XML instance that drives the UI was limited in anyway, which is why I believe XBL has little value for XForms other than component customization and fringe use cases.  The majority of UI use cases are covered by XForms (it was built for that purpose).



re:eliminating the need for an imperative language





Once again, I have yet find myself in a situation where I needed javascript for UI-related capabilities that weren't covered by XForms event processing, instance binding, and other such programatic components.  The only time I did was when I had to encode XML content as base64 encoded binary (see: http://copia.ogbuji.net/blog/2005-08-19/BinaryEncodingAndXMLRPCs) and had little to do with XForms but more with the means of remote communication (SOAP).  I'm not suggesting that frameworks such as XForms will eliminate the need for an imperative language, but rather that the need will be more like the reverse of your 80/20 proposition.



I must give the disclaimer that I'm not suggesting XForms will be a user interface / browser-based application building panacae, but rather that the potential it has to eliminate the unportable, architecturally unsound code that often drive DHTML web-sites with minimal complexity is very much overlooked.
— Chimezie
Chimezie,



I do not disagree with any of your assertions - the day that we can in fact get rid of any imperative code in programming is the day where things become far more stable, manageable, secure, and in general easy to automate. I do not, however, think that you're acknowledging mine here. Of the XForms solution that you've mentioned, all but one of them are plugins to specific browsers, most have ideosyncracies that make it remarkably difficult to make a given XForm work from one system to the next, and the solutions that are deployed tend to have VERY different ideas about the degree of abstraction that a given component should offer in terms of its implementation.



I'm a BIG fan of XForms. I believe the potential for XForms is huge, to the extent that I want to see both the Mozilla and Netscape implementations offer functional versions of XForms SOON. However, until that happens, XForms will only be deployable in closed environments, which means that while it may have some application to enterprises, it will not in fact be accessible to the majority of users out there.



There's no more compelling proof about why this is critical than to look at the mess that's SVG. SVG is about to come to the masses -- only five years after it was ratified as a standard. SVG as a plugin just did not hack it, because there was no effective way of distributing that plugin to the extend necessary for wide-scale adoption. It has only been in the last year with Opera and Firefox both getting SVG into the trunk that the POSSIBILITY of adoption finally became realizeable.



Once we get a declarative forms (read application) framework in place, I suspect that things will likely move even to 90/10 as far as adoption. XForms + XPath is a powerful combination, especially if you can move to XPath2. In that particular case, the imperative code again moves into a support role where XPath is extended for system level access and related purposes.



However, we are not there yet. It is up to evangelists like you to push the XForms meme, the declarative application meme, into public consciousness, and it is up to people who are involved in the "distribution" system of web browsers such as myself to try to push these technologies into the browsers themselves. I think we're looking at two years before XForms actually begins to "catch fire", and maybe as many as five before XForms reaches a point where it seriously threatens the existing Wintel hegemony.



To summarize - yes, ultimately pushing the declarative programming paradigm should be one of the most important things that all of us do, but without recognizing that we're fighting a major rearguard action from any number of players who have a huge political stake in keeping the status quo we're dooming ourselves to failure. Javascript is a bridge technology, and perhaps not even the best one, but the alternative is to end up in the programming ghetto while Microsoft pushes its own agenda into the web-space.



-- Kurt
— Kurt Cagle
Add Website URL »