Compiled Web vs. Interpreted Web

April 30th, 2009 by jeremychone

Software technologists tend to learn by oscillating. We never arrive directly at the right solution; we just come closer to it by going back and forth. We always think (or like to think) that our current solution is correct; only to realize, some years later, that we overshot and need to take a few steps back. The evolution of the software application model is a great example of this syndrome. Every technologist knows about the three main application model phases—Mainframe, Client/Server, and Web [1.0]—and many of them think they know what the next phase will be. In fact, two models are currently being promoted. In order to better understand the current trend, it is important to first understand the three original model phases.

1) Mainframe

The first application model was the mainframe;  the client was simply a screen (typically green) and a keyboard that could display and send characters back and forth through a network. The server had all the definitions of the screens (i.e. User Interface), application logic, and data, and was communicating with the client by sending characters (which represented the UI and data) back and forth.

This approach had the benefit of being relatively simple, cost effective to scale, and was easy to manage because the application could be centrally managed. The limitation was obviously that the client’s lack of richness limited the type of application that could be offered. For example, a Google Map on a green screen would have been a challenge to implement.

2) Client/Server

The second application model came with the popularization of personal computers by IBM, Microsoft, and Apple. Now that users were able to have actual processing and display power on their desktop, the application UI and the logic could reside on the client side, while the data could reside either locally or remotely on servers. The application UI and logic were usually packaged and optimized (i.e. compiled), and had to be physically installed on the client side. When the user needed a new application or a new version of the application, s/he had to explicitly acquire and install the new application or upgrade package. In this scenario, the server’s responsibility was to synchronize data.

The benefit was that new applications could take advantage of Moore’s law on both ends of the network, which consequently allowed for a wide variety of applications, such as word processing, CAD/3D tools, and games, just to name a few.

The downside was that the application life cycle (e.g., installs and upgrades) required the user’s intervention, making some application scenarios relatively expensive to deploy and manage.

3) Web

Then came the Web; at first, it was mostly used to access (i.e. browse) content. However, through its simplicity and network-centric characteristics, it quickly became a very effective way to deploy networked-based applications. The model was similar to that of the Mainframe, where the server sent UI instructions to the client. But this time, the client could do much more; although still relatively primitive, the Web model had some extended UI elements that included image, text, and input fields, and even allowed the payload to carry some logic (i.e. JavaScript) that would be interpreted and run on the client side.

Although not as rich as the Client/Server application, the benefits of the Web were unparalleled when it came to deploying applications over the network. The fact that the server had complete control of all aspects of the application—UI, logic, and data—made this application model a genuine standard for Internet applications.

However, there were two disadvantages to this model. First, the UI primitives were not as rich as its Client/Server counterpart, making the appearance and interaction of Web applications less competitive. Luckily, the Web had a very inclusive architecture, and allowed plug-ins vendors, such as Sun and Adobe, to extend the Web primitives with capabilities such as video and audio. Second, the application granularity was the screen (i.e. page), meaning that each user interaction required a screen refresh that updated the UI, logic, and data simultaneously. While the single screen model was easy for developers to understand, it made highly interactive applications quite a challenge to build, and often resulted in a poor or confusing user interface experience.

4) ???

So, where are we now? What is the fourth phase? Currently, there are two possible directions: the Compiled Web and the Interpreted Web.


4.1) Compiled Web

The Compiled Web model is, in a way, the Client/Server model inside a browser. First introduced by Java, with Applets, and now being revived with Adobe Flash/Flex, the concept is to compile all the application user interfaces and logic into one or more packages (.jar for Java, .swf/.swc for Flash) that will be downloaded and run by the client; this time, inside a Web browser. This model is often based on browser plug-ins such as Sun Java or Adobe Flash, and usually relies on typed and object-oriented languages like Java or ActionScript 3. Such applications communicate mainly with servers, as the Client/Server did, in order to synchronize data or to call Web services.

The advantage of this approach is that it offers Client/Server developers a very familiar application model while allowing the end-result application to leverage some of the Web deployment characteristics. The other significant benefit is that browser plug-ins such as Java, Flash, and Microsoft SilverLight extend a browser’s capabilities with video, audio, 2D/3D apis, and threading (for Java/JavaFX), allowing applications to take full advantage of the client’s computer processing and display power.

However, the Compiled Web model does not fully take advantage of the dynamic characteristics of the Web. By fixing the UI definition and behavior at the time of compilation (i.e., design time), the Compiled Web model removes the server’s ability to fully participate in the UI generation and orchestration, which could be limit many Web applications, such as model-driven applications. Also, this packaging phase reduces the application’s life-cycle flexibility since any update or enhancement will require a large part of the application, if not all of it, to be rebuilt and redeployed. While modularization is possible, modules have to be carefully thought-out; once designed, they are relatively fixed.

There is also a misunderstanding about performance, which asserts that because a compiled code runs faster than an interpreted code, a Compiled Web application performance must be greater than a regular Interpreted Web application. While theoretically correct, this reasoning does not take into consideration the on-demand nature of the Web, whose applications are expected to be instantly accessible from several entry points. The compiled approach is not suitable for this requirement because it requires the entire application (or large parts of it) to be downloaded before anything can be displayed to the user. This is retrograde from the Web application model, which allows a more organic interaction in which only the required resources for a specific interface (i.e. a screen) need to be downloaded. As a result of this limitation, loading progress animation has become a very common experience for many Compiled Web-style applications.

4.2) Interpreted Web

On the other hand, the Interpreted Web, is just the natural evolution of the traditional Web application model with an extended set of user interface constructs and capabilities, as well as an asynchronous way (i.e., AJAX) to send requests and to recover resources over the network without requiring a screen refresh. This AJAX capability, coupled with the complete dynamicity of Web technologies, where any part of the application such as UI structure, UI style, logic, and data can be dynamically updated, offering limitless architecture possibilities.

This approach still leverages all the benefits of the Web model, while extending the user interface richness and breaking down the page granularity to virtually any piece (UI, logic, and data) of the application. This allows a wide spectrum of application styles, from a single page style (Google Docs) to a page-based style with highly interactive components (Facebook or By allowing the server to be a complete part of all aspects of the application (UI, logic, and data), this model is an ideal approach for model-driven applications that require the user interface to be dynamically generated from the server, as well as large suites of applications such as Google Apps or Facebook. Also, the extended granularity offers unparalleled application life cycle agility. Upgrading or enhancing an application only requires updating of the necessary pages or resources of the application, and the user will only download these modified resources when he requests the updated interface.

The downside to all of this is that browsers still have a limited set of UI capabilities. For example, video and audio still require third party plug-ins (which usually rely on a different application model); and 2D/drawing apis are still cumbersome (no DOM for Canvas and not-as-HTML-friendly SVG). Thanks to the Web-inclusive architecture, it is relatively easy to embed plug-in components for these advanced functionalities (i.e. charting, video, audio, and drawing), although they do not always blend very well with the Web model.

Now, to add some confusion to the mix, it is possible to implement Compiled Web framework with interpreted technologies and vice versa. Google GWT is a perfect example of such hybrid model by exposing a Swing API to the developer and deploying HTML/Javascript code. The reverse can also be done in Java/JavaFx by interpreting XML UI elements (e.g., Nexaweb XAL technology) and using a scripting language like Groovy or JavaScript/Rhino. Interestingly enough, SilverLight is already a hybrid of the two models because it supports dynamic and compiled languages via the .Net CLR technologies and allows XAML to be dynamically evaluated. Unfortunately, it is harder to have an Interpreted Web architecture using Flash technology since, for business and performance reasons, Adobe seems to have rejected the interpreted model by making most of their technologies—ActionScript 3, Flex, FXG—compiled centric: no evaluations and no runtime MXML (you can build your own, but you are up for a ride). (see also: Why FXG is not based on SVG).

Which one?

So, which one is better? Which one should you base your application on? Well, it depends on what type of application you want to build and what skills you have available.

If you want to make a desktop application and deploy it over the web, the Compiled Web approach might be a good solution. This is also true if your engineering team has strong Client/Server development expertise (i.e. Windows MFC, Swing, etc.). Using a modern Compiled Web framework, such as Flash/Flex, might be a good path, because Open Web (i.e. Html/CSS/Javascript/SVG/Canvas) development could be frustrating for non-Web developers.

On the other hand, if you want to do a rich Web application that leverages as many Web characteristics as possible, and most of the logic needs to be on the server side, the Interpreted Web approach will give you unparalleled flexibility and functionality.

The good news is that if you choose the Interpreted Web model as your main framework, you can always add compiled-based components. YouTube or are good example of such an approach. However, the reverse is much harder, if not impossible.

This was a relatively long post, but was the reflection of many years working on the subject.

If you are in the midst of designing your rich Web application architecture and would like third-party validation and advice, I would be more than happy to offer an hour or so (free of charge) over the phone (i.e. Skype). Just email me at

26 Responses to “Compiled Web vs. Interpreted Web”

  1. Ray Cromwell Says:

    Pretty much every compiled system permits dynamic loading/dynamic linking. There is no need to produce an all-in-one executable.

  2. Jeremy Chone Says:

    @Ray, oh yes, obviously. As I said you can build an interpreted model on top of a compiled system. And in a way, scripting languages are based on compiled system. Here I am addressing the application model more than the underlying technologies.

  3. Jeremy Chone Says:

    Agree, GWT is kind of an hybrid model, they did a good job keeping many of the Web benefits.

    RT: @cromwellian @jeremychone Startup time claims dont really apply to GWT. Starts up faster/smaller downloads + code splitting yields auto dynamic loading.

  4. Ray Cromwell Says:

    I agree with most of what you say, but what I meant was, I could produce a compiled C executable that loads a usable startup screen with minimal functionality, and then dynamically loads other compiled components on demand or asynchronously. Dynamic loading/linking is not limited to interpreted languages.

    This is of course, especially true with Java, where you could download a small 1-2K bootstrap app, and then have it dynamically load the rest of the classes in the background.

    With flash, can’t you dynamically load SWFs? That way, you could send down the “main screen” only, and then download more compiled SWFs in the background.

    GWT has a new feature called code-splitting which takes all this a step further by allowing you to compute, at arbitrary parts in your program, the sum total of all reachable code up to that point, and optimize only that chunk and load it separately. Thus, you can write a complex app with say, 10 Tabs, each tab would invoke code-splitting in the compiler, and so, the compiled classes for those tabs would not be in the initial download, but loaded asynchronously later.

    Doing this by hand in Javascript is a major pain, since you have to fulfill the role of the compiler yourself, dead-stripping away routines not used, and arranging the chunks by tracking everything manually.

  5. Jeremy Chone Says:

    @Ray, ok, I think we are exactly on the same line.

    Yes, this was my point with “it is possible to implement Compiled Web framework with interpreted technologies and vice versa.”

    For example, at Nexaweb we provided a dynamic model based on Java. The runtime was a small boostrap that interpreted and ran the UI definitions and macros (defined in XML).

    In Flash it is more problematic since Flash does not support eval(). So, you will have to somehow get around that. But, should possible. Obviously, you can ask the server to compile the script dynamically and load a swc, but this model will lead to many issues. Also, Flash does not currently have a class-loader (and no, the LoaderClass is not a Class loader ;).

    Now regardless of the capabilities of the system itself, the big RIA Framework vendors, Sun and Adobe, are mainly promoting the compiled way. Again, an application developer could write its own dynamic framework on top of them, but this will take some time.

    GWT, being based on HTML/JavaScript system, can easily benefit from many of the Web characteristics (as you mentioned in your comment).

    However, personally, I am not a big fan coding a Web application the Swing way. I think we should go all the way back, and create a CWT (Cobol Web Toolkit). MicroFocus might be already working on this one.

  6. Ray Cromwell Says:

    GWT doesn’t necessarily imply using Widgets. If you’re going to Google I/O this year, I’m giving a big presentation on Gwt Query, which is a jQuery-style library for GWT, where you write HTML first, and then attach behavior.

    With respect to the dynamic loading stuff, I think maybe what you’re getting at is dynamic extension. That is, without eval() you can load stuff dynamically, but all of the pieces had to be seen by the same compiler originally.

    This is certainly true for GWT. The solution to the ‘dynamic extension’ problem, e.g. third party plugin problem, is to export a dynamic interface that all extensions must adhere to for dispatching or marshalling between them. In a compiled system, communication between libraries not all compiled at the same time (separate compilation) has to be done by prior agreement, and is very similar to a remote procedure call.

    COM is a good example of this.

  7. Jeremy Chone Says:

    @Ray Yep, agree with your points.

    Google I/O is $300, almost an iPhone or Kitesurf Board. So, I will pass and go Kitesurfing this day.

    Developer events should be $49.99 including beer and pizza.

  8. Chris Ryland Says:

    The trend is for Javascript in the browser to be compiled (witness Google Chrome’s V8 engine), so the compiled/interpreted split doesn’t really make sense in the long run.

  9. Jeremy Chone Says:

    @Chris, Chrome V8 is just a clever JIT. Developers still code in an interpreted mode, and the assembly is still done dynamically on the client side (at runtime). In other word, the whole point of Chrome V8 was to keep JavaScript a dynamic language while reducing the performance gap with compiled languages. Chrome V8 is just go a step further in enhancing the performance of scripting languages.

  10. Ray Cromwell Says:

    A JIT cannot optimize code it hasn’t seen. No amount of dynamic optimization will. That is, V8 cannot reduce the wire size of the download. A tool like GWT does dead code elimination, inlining, folding, et al, prior to your browser fetching it. It also can perform capability/browser detection prior to downloading the bulk of the application, meaning that the browser only needs to download the code that is appropriate for it. That’s leaving aside all of the other tool chain benefits you get on large projects when you have early bound namespaces in your language. This has a huge impact for larger applications like a spreadsheet or GMail-like app.

    Jeremy, the videos will probably be online.

  11. Jeremy Chone Says:

    @Ray Yes, agree, a JIT like Chrome V8 does not change the nature of the language/application model.

    @Ray cool, looking forward to see your video.

    More I read your comments on GWT, the more I realize that GWT really leverage the interpreted model very well. Seems to be a very good hybrid solution (although I still do not like the fact to code a Web app the Swing way )

    I am a jQuery fan!

  12. Ray Cromwell Says:

    There’s a video from last year’s I/O on GQuery when it was just a prototype:

    The syntax is effectively as terse as jQuery, and prototype extension is simulated rather nicely using generics. As an example:




  13. Topics about Microsoft » Compiled Web vs. Interpreted Web Says:

    [...] Bits And Buzz, by Jeremy Chone created an interesting post today on Compiled Web vs. Interpreted WebHere’s a short outlineSoftware technologists tend to learn by oscillating . We never arrive directly at the right solution; we just come closer to it by going back and forth. We always think (or like to think) that our current solution is correct; only to realize, some years later, that we overshot and need to take a few steps back. The evolution of the software application model is a great example of this syndrome. Every technologist knows about the three main application model phases—Mainframe, Client/Server [...]

  14. links for 2009-04-30 « My Weblog Says:

    [...] Compiled Web vs. Interpreted Web | Bits And Buzz, by Jeremy Chone (tags: web) [...]

  15. Compiled Web vs. Interpreted Web Says:

    [...] click here [...]

  16. Posts about xml as of May 8, 2009 | Shirasmane Says:

    [...] XML API Settings (21 Apr 2009) Javascript Loop through key value pairs from an associative Compiled Web vs. Interpreted Web – 04/30/2009 Software technologists tend to learn by oscillating . We never arrive [...]

  17. James Ward Says:

    Good thoughts Jeremy.

    Two major things I like about the compiled web is that compiled languages usually have better debugging and testing tools.


  18. Jeremy Chone Says:

    @James True, although some good tools like Aptana Studio and Firebug can help too. But true, developer get a best debugging experience with compiled application model.

  19. Oracle on Sun Java, MySQL, OpenOffice, and Linux | Bits And Buzz, by Jeremy Chone Says:

    [...] Bits And Buzz, by Jeremy Chone Technology, trends, and opportunities. « Compiled Web vs. Interpreted Web [...]

  20. Patrick Farrell Says:

    I hate to sound old-fashioned, but I am thinking there’s a 3rd model that represents a return to a hybrid of mainframe and client/server. I’m thinking of devices a lot dumber than the iPhone that will still want to have rich communication. Nice analysis.

  21. Patrick FArrell Says:

    I see a 3rd phase the can coexist with the two you foresee. I anticipate a return to hybrid mainframe (session lives in central computer) and client/server (some horsepower on the client). I see a host of client much dumber than the iPhone that will still want rich communication. I’m not much of an oracle though. Nice analysis.

  22. How I got Censored from Techcrunch: L’Arroseur Arrosé | Bits And Buzz, by Jeremy Chone Says:

    [...] think I could do 10 times as "well" twice as well. My best content articles, such as “Compiled Web vs Interpreted Web”, average 2,500 visitors in the first 48 hours (which I am very proud of). I will make it a [...]

  23. To Flash or to Open Web | Bits And Buzz, by Jeremy Chone Says:

    [...] Web applications is usually sub-second responsiveness. As outlined in a previous post about Compiled vs. Interpreted Web, the interpreted nature of the Web makes it very efficient for executing on-demand content & [...]

  24. PhilG Says:

    While internet speeds have continued to climb dramatically, it still seems as though the bandwidth is still the single factor that holds back compiled languages on the web. In addition, interpreted scripts are quite easy to create. It still seems like the benefits of a compiled web are years away.

    Just my 2 cents

  25. Jeremy Chone Says:

    @PhilG, I personally think that the Compiled Web is the wrong way for on-demand type of application.

  26. Earl Colabrese Says:

    Hi, I found this article while searching for help with Microsoft Silverlight. I’ve recently switched internet browser from Opera to Internet Explorer 7. Just recently I seem to have a issue with loading sites that use Microsoft Silverlight. Every time I go on a page that requires Microsoft Silverlight, my computer does not load and I get a “npctrl.dll” error. I cannot seem to find out how to fix it. Any aid getting Microsoft Silverlight to function is very appreciated! Thanks