Machine Learning Authors: Yeshim Deniz, Liz McMillan, Pat Romanski, Elizabeth White, Zakia Bouachraoui

Related Topics: Machine Learning , Agile Computing

Machine Learning : Blog Feed Post

Compiled Web vs. Interpreted Web

Software technologists tend to learn by oscillating

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 SalesForce.com). 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 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 SalesForce.com 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 [email protected]

If you liked this article, a vote on Hacker News would be greatly appreciated.

Read the original blog entry...

More Stories By Jeremy Chone

Jeremy Chone is chief technology officer (CTO) and vice president of development and operations at iJuris, an innovative startup offering a rich Web application for lawyer collaboration and document assembly. In his role as CTO and vice president of development and operations, Jeremy is responsible for overseeing the company’s strategic direction for the iJuris service and technology as well as managing the service architecture, development, and operations.

Chone has more than 10 years of technical and business experience in major software companies such as Netscape, Oracle and Adobe where he has successfully aligned technology visions with business opportunities that deliver tangible results. In addition to a combination of technical and business acumen, Jeremy also possesses an in-depth knowledge of Rich Internet Application technologies, as well as holding many patents in the mobile and enterprise collaboration areas.

See Jeremy Chone's full biography

CloudEXPO Stories
David Friend is the co-founder and CEO of Wasabi, the hot cloud storage company that delivers fast, low-cost, and reliable cloud storage. Prior to Wasabi, David co-founded Carbonite, one of the world's leading cloud backup companies. A successful tech entrepreneur for more than 30 years, David got his start at ARP Instruments, a manufacturer of synthesizers for rock bands, where he worked with leading musicians of the day like Stevie Wonder, Pete Townsend of The Who, and Led Zeppelin. David has also co-founded five other companies including Computer Pictures Corporation - an early player in computer graphics, Pilot Software - a company that pioneered multidimensional databases for crunching large amounts of customer data for major retail companies, Faxnet - which became the world's largest provider of fax-to-email services, as well as Sonexis - a VoIP conferencing company.
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
With the mainstreaming of IoT, connected devices, and sensors, data is being generated at a phenomenal rate, particularly at the edge of the network. IDC's FutureScape for IoT report found that by 2019, 40% of IoT data will be stored, processed, analyzed and acted upon at the edge of the network where it is created. Why at the edge? Turns out that sensor data, in most cases, is perishable. Its value is realized within a narrow window after its creation. Further, analytics at the edge provides other benefits.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by FTC, CUI/DFARS, EU-GDPR and the underlying National Cybersecurity Framework suggest the need for a ground-up re-thinking of security strategies and compliance actions. This session offers actionable advice based on case studies to demonstrate the impact of security and privacy attributes for the cloud-backed IoT and AI ecosystem.
Enterprises that want to take advantage of the Digital Economy are faced with the challenge of addressing the demands of multi speed IT and omni channel enablement. They are often burdened with applications that are complex, brittle monoliths. This is usually coupled with the need to remediate an existing services layer that is not well constructed with inadequate governance and management. These enterprises need to face tremendous disruption as they get re-defined and re-invented to meet the demands of the Digital Economy. The use of a microservices approach exposed through APIs can be the solution these enterprises need to enable them to meet the increased business demands to quickly add new functionality.