Today is a good day to code

Web UI Compilers – JSF, GWT, Microsoft AJAX

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

Web UI Compilers – JSF, GWT, Microsoft AJAX

Picture of IrvinWhy don't you use JSF, Microsoft AJAX, Spring, GWT… I get these questions constantly. I'm sure most UI developers do also. They are correct, I don't use these UI generators / compilers. So then we come to the question of why? To discuss why we have to look at the history of interface development for the web.

The first solution was to extend HTML to allow for the embedding of applets in the code. This was a great solution. Most developers realized that HTML would never be good at logic, and Perl wasn't quite there yet. The problems with this approach should have been clear early on. Java ran slow on the hardware of the day. That was the first problem. The second problem was that most users were on 36 Kbps or 56 Kbps modems, so the multi-megabyte applets took 20 minutes to download. This was unacceptable, but it was the only solution at the moment. For programmers it was a pretty good situation, they could write server-side code and then in the same language, write the client side code.

The main issue with applets was that they were often designed by the coders, so it isn't necessary to say that they looked awful. At the same time if they did have designers work on the applets they incorporated many images that slowed the downloads.

It was time for the revenge of the designers. Macromedia came out with Flash, and developers had mod_perl, the beginning of the code forking took place. It was easy for designers to work with the art friendly Flash, and its vector processing VM was light enough for the processors of the day to handle. The back end programmers would develop in the language of their choice, usually Java, and then the web designers would work in Flash. This approach took the web by storm.

During this time there were a few crazy developers who were working with DHTML and the beginnings of CSS. Netscape was fading away quickly and Microsoft was releasing really cool features to work with their JScript engine. In many ways, the situation was similar to now, the Netscape JavaScript engine was very different than Microsoft's JScript engine so developers writing code had to deal with both. Most of these people were working with Perl, Java or ColdFusion as a back-end language. The benefit of Perl and ColdFusion was that they didn't require compiling so changes were reflected immediately.

At any rate, browser forking, and a desire to compete with Flash prompted Microsoft to start building .net and the Visual Studio tools. Visual Studio was really cool for back end developers because now they didn't have to learn anything about browser incompatibilities or layout issues. Microsoft built into the runtime the ability to take object instantiated by the request into HTML, CSS, and JavaScript in the browser. The downside is that while they were usually compatible with most browsers, they were coded at the lowest possible common denominator. They used tables to lay out pages, they used inline CSS everywhere. They inserted poorly written JavaScript into pages, but this approach was successful because it made development easy.

These pages never validated, had tons of img tags in tables, and used too much bandwidth. The presentation was always heavily mixed with the business logic destroying the MVC pattern completely. Most professional web designers and some developers shunned this approach as it was often sloppy, and code changes caused regression bugs always. Even simple changes like adjusting the way forms validated caused regression bugs, because it wasn't always clear what other code was depending on the generated code. To use another companies JavaScript api was difficult because it was hard to determine what elements would be named or what CSS was going to be applied.

Unfortunately, the Java IDEs and frameworks were built on this premise, although their implementation was a little different. These IDEs “compiled” the JavaScript, CSS, and HTML. They did, unfortunately, not do a better job of creating optimized, valid, HTML, CSS, and JavaScript. Most people figured that it didn't matter, and JavaScript as the client language continued to fade away.

The problem with both of these approaches is simple. There is no way to control what browser the user is using, and it is quite impossible to somehow automatically make the different browsers render code exactly the same way. Microsoft tried to ignore that there were different browsers, and since they had 96% of the market, they could. The Java approach was different, they didn't ignore the other browsers, but they went to the most basic UI code that they could. If someone upgraded their IDE to the new version, imported their code in, and then recompiled, often the new libraries produced slightly different HTML, JavaScript, and CSS. This frequently causes code breakage. Since what is generated is almost always obfuscated either on purpose or by virtue of the machine generating code, IE Word, it was difficult to find exactly where the problems were.

Enter Google, they changed it so that everyone now wanted to make JavaScript the client programming language. I'm sure the first versions of Gmail were handwritten with later versions being developed using the GWT. GWT is a solution similar to JSF. It is a JavaScript compiler. It generates high quality JavaScript, CSS, and HTML for you, and you write in Java. It is a great solution, * again * , for back end developers.

So what's the problem. The problem is the same as before. If you upgrade from GWT 1.3 and use GWT 2.0 for example, and they change the way the CSS is applied or the way certain JavaScript objects are generated, then your application breaks. That in itself isn't the problem, the problem is that you don't understand where or why the breakage is happening.

Why can't this ever work. The biggest problem is the lack of a unified VM for processing web scripts. Since Mozilla uses Spider Monkey, and Microsoft uses JScript, and who knows what else is going to come out, it is impossible to use a compiler that will generate code. Each of these compilers encapsulates a point in time. Right now they work well because they understand the way browsers interpret code today. The problem is that every user could download a different browser tomorrow and with compiled JavaScript, CSS, and HTML as a developer you don't know, at an intimate enough level, the underlying code enough to make intelligent decisions about how to fix the problems with the new browser.

People frequently curse JavaScript but they should praise it. Yes it is a difficult language to work with because of the quirks, and etc… but they are forgetting what it does that is great. It doesn't have to be compiled, it is very fast, and its dynamic typing and prototype based design keep the barrier to entry very low, and its flexibility high. The reason JavaScript doesn't go away is because it is good at what it does. The solution is not to make a compiler, the solution is to write good, well documented JavaScript libraries. To be good at AJAX / DHTML, it is necessary to be a well disciplined developer. There is no magic bullet, there is no way to make it easy. The environment makes it impossible to make it so. It just is the way it is, until it changes.