Today is a good day to code

JavaScript Will Either Die or Dominate

Posted: December 31st, 1969 | Author: | Filed under: Uncategorized | No Comments »

JavaScript Will Either Die or Dominate

Picture of IrvinThinking about the state of Web Development, two things come to mind. The first is positive, that people are doing really awesome things with limited resources providing users with mind-boggling, plugin-free rich experiences that are platform independent. The second thing is less positive, and that is a set of broken languages and standards that make for varying experiences on different browsers.

I actually think that most of the problem lies with the business and architectural decisions that spawn these applications than the technologies. To develop AJAX applications, a developer must know, if it is a single engineer project, some back end language, probably PHP. They must know CSS, XHTML, and JavaScript well, and on top of all of that, they need to know what the current standard is. If they don't do this, they need to know Flash or now Silverlight, and then they can build an application that requires a plugin to run.

So I am starting to think, and I'm not convinced yet, that it may not make sense to build a single application to serve all browsers. Here's my reasoning:

When building my last large application, I was thinking about how much effort it was taking to make it work across the board. I also was thinking about how many libraries I had written that will perform browser detection and morph themselves to work in whatever browser based on what level of JavaScript they had and the like. The problem was that Firefox, since it supports JavaScript 1.8 has some nifty functions like Array.prototype.indexOf that make string matching in arrays much quicker than what one can do if they dumb down their JavaScript for the limited 1.3 that IE supports. I realized that I could probably have written two or more UIs using a SOA (Service Oriented Architecture) utilizing the advanced features of each browser in about the same time as I did in writing one monster application to service everything. In addition, I think I could have done it in less code. One example is Microsoft's onreadystate HTML element attribute. When lazy loading JavaScript libraries, I can use onreadystate to figure out a particular file has loaded yet. This is a particular nicety that I wish other browser manufacturers would adopt even though it isn't ECMA ratified.

Where the business and architectural logic is at fault is that since the AJAX craze, people have forgotten about Flash for building rich web applications. Sometimes Flash makes sense, in that download sizes for code are way smaller and performance is way better. Sites like netvibes almost certainly would have better performance and capabilities if they were developed in Flash using Flash Remoting. Flex also has its places, although I think the XML as everything approach to scripting languages is getting a little ridiculous. XML is fine for data, but when you need to define logic, XML is a little bulky at best.

The next generation of browsers and technologies are going to fragment things a lot more. Firefox 3 “Gran Paradiso” is going to be a great browser, the Mozilla foundation is accepting that users want features, and they have to add more features to stay competitive with Microsoft. But the cost is a bigger download, and slightly different behavior from JavaScript. Some of it is welcome, such as the abolishment of the XSS (Cross site scripting) issues current web browsers impose on web developers limiting mashup development, but with this comes the fact that we will have to do different things for each browser.

Ultimately all of these languages need to converge into a single web language. It is silly to learn XHTML and all its quirks, CSS and all its quirks and different syntax, and JavaScript and all its quirks. It takes nearly all my time to stay on top of these three languages and it is impossible anymore to keep up. Either JavaScript needs to Die, or it needs to become everything. It should have language to describe all of the visual behavior of elements, and events, or things related to the view, the business logic, as well as have rich objects to support varying data types. It should be threaded, if not type checked as well. I don't want to see it complicated, but it should be simplified. I am working on yet another web browser called Welsh Corgi to try to accomplish the system above, among other things. Maybe I'll be successful, maybe it will be someone else, but I think the need exists.

Still, even with the above happening, I think that the future will be where we have been in the past. Detecting a browser and through various means, serving the appropriate application for a specific browser. Web teams are going to get bigger, because the future isn't in OSs or desktop applications, it is on the web.