Why web languages are broken
As a part of my GUI technology review I recently finished implementing a Twitter client in Java/Swing and in pure Web languages (HTML, CSS and Javascript). After discussing my observations on the web implementation , my advisor asked me to give him feedback as a programmer on how I felt about the two different implementations. The first thing I pointed out was that the web version took much less time to develop than the desktop version in Java, even though I have 3 years of experience in Java and only basic knowledge in HTML. My advisor was a bit surprised at my comment. Then he asked a more interesting question? Were all component of the web client faster/easier to develop than the desktop version. I thought about it and said, “No”. Writing the code to parse XML in Javascript was a painful experience even though, there were built-in functions in Javascript to traverse XML documents like a DOM. The code for the Java XML parser was definitely more verbose than the Javascript version. But I felt that it was more consistent. Whenever the tree traversal code did not match the structure of the XML document, the Java program would crash with a null pointer exception. On the other hand, the web browser being more forgiving, used to print out blank lines where my extracted was supposed to appear. Because of a lack of consistent error messages debugging the XML parser was much harder in Javascript. I opined that this difficulty might have stemmed from my unfamiliarity with Javascript. But then my instructor pointed out that having bugs in a program is a natural thing and good languages are designed to help programmers catch the most common bugs during compile time. As I was on the topic of debugging Javascript code, I brought up the concept of dynamic content in HTML. The way any GUI element is added dynamically to a web-page is by injecting strings containing HTML to the DOM through Javascript. The web-editor I was using to develop the web client was helping me a lot by highlighting syntax errors and auto-completing tags and function names. But when I came to the point of writing code to generate dynamic UI elements, my IDE was of no use. At that stage I was writing pieces of HTML inside strings in Javascript and there was no way for the IDE to validate the HTML in that way. On top of this, the source for the dynamically generated content can never seen, even when the web-page is running in a browser. When the dynamic HTML code is malformed or buggy it is extremely difficult to debug it. Together with the forgiving nature of browsers, and the varying level of forgiveness across browsers, debugging dynamic content is even harder. As I was saying this, I realized that most of todays “Web 2.0” applications are dynamic. In fact they contain very little static code. Complicated web applications like Google Docs and Spreadsheets use a lot of dynamic content to power themselves. This means, most of the code for modern web-applications were not validated statically, rather they were developed by iteratively running the application and fixing the code until the desired result was achieved. One more issue I pointed out is that people have begun to use UI elements with rounded-corners in their design. Since CSS does not support rounded corners natively, web developers use tricks like positioning images of rounded corners over the edges of rectangular areas. While this creates the desired visual result, all the benefits of CSS is lost in this method. With the new setup, changing the color of a rounded rectangular region cannot be done through CSS alone; an image editor has to be used to edit the corner images. All of these issues are making web languages more unsuitable for the kinds of web applications we see today. Even though HTML, CSS and Javascript are letting us build interactive and dynamic web applications, the kind of “hacks” needed to make them work is stretching the limits and exposing the incapabilities of these languages.
Adobe Labs – Alchemy
C/C++ compiler for the Actionscript Virtual Machine. You have to be kidding me.
Merapi – AIR-to-Java Bridge « kennethteo.com
I stand corrected, it is possible to talk to Java backends while writing a GUI for the AIR platform. Merapi is an AIR-Java Bridge that supports message passing between the two languages.
Flex/AIR to Java Communication Using Merapi « Devgirl’s Weblog
An example of using Java to communicate with Flex
Flex/AIR to Java Communication Using Merapi « Devgirl’s Weblog.
Video: Programming the Real-Time Web with Leah Culver
Video: Programming the Real-Time Web with Leah Culver.
Programming the Real-Time Web with Leah Culver from ReadWriteWeb on Vimeo.
More on GUI builders
In my last post, I labeled GUI builders as "glorified one-way code generators" and I opined that once you start messing with the code, you are no longer in sync with the visual environment of the builder. Yesterday something struck that made me rethink my statement. I was limiting myself to GUI builders of desktop languages. Web Editors like Aptana, Dreamweaver etc. are essentially GUI builders too. But, unlike their desktop counterpart, these tools can work both ways. Any manual change in the CSS or the HTML is instantly reflected in the visual environment.
The secret lies in the fact that CSS and HTML can be statically parsed. Thus the look of the GUI can be reconstructed from the code. However, with the general purpose languages, once the code has been generated. Any changes in the code cannot be parsed until run time. This gives me something to seriously consider while designing Luna. Most, if not all, of the design elements have to be statically typed to take full advantage of development tools.