This article is a transcript from a recorded conversation I had with Anatole Tartakovsky and Victor Rasputnis – my business partners at Farata Systems. This conversation took place on the mountain after the day of skiing.
Yakov. There are many ways of creating Web applications and creating them for the enterprises is not the same as developing a Web site for a pizzeria in your neighborhood. During the last five years we’ve been using mainly Adobe Flex for development of the front end of Web applications. Flex applications work in a well known and predictable run-time environment called Flash Player. The code is compiled and you have convenient tools for development.
Anatole, we did it in the past and it seems that we’re entering the same waters again. Is it still the same river 7-8 years after?
Anatole. DHTML has been introduced in the Internet Explorer 5, and several years later it was renamed to AJAX.
Y. Back in 1999 Microsoft created XMLHttpRequest object to allow their Web version of the mail client Outlook to update the browser’s window without the need to refresh the entire page. Is this right?
A. Partially. IE5 also had the XSL transformation tool for HTML generation and sopported development of custom plugins. The market share of IE5 was about 90%, but in enterprises it was literally the only approved browser.
Victor. At the same time, IE5 supported the model of HTML components called HTC. It allowed you to create htc files containing your own custom components with properties and methods, which were visible in the Web browser’s DOM with all these properties.
V. If you ask me what has changed the most – it’s perception. In the beginning of this century we worked in the DHTML environment. Only a small number of developers was involved with this “suspicious” development. Enterprise architects had hard time adopting this pre-AJAX model and often asked the same question, “This is not J2EE, right?” We’d answer, “No, it’s not”. Then it was clear to the architects that it’s some amateurish offering that could be ignored.
During the last six years, development with Flex slowly became an approved enterprise technology – it’s compiled and controlled environment with good performance, testing tools, and internationalization support. Then, Adobe turned its back on Flex.
Y. And the way they did it could be included in the Bad PR section in textbooks. Instead of starting Adobe MAX conference in October of 2011 with a proud announcement that Adobe is donating Flex to Apache Foundation, which would get a standing ovation, they waited a month and made the same announcement right after declaring that they wouldn’t support Flash Player (Flex runtime) on the mobile devices. This sounded as if they wanted to kill Flex. But we know that Flex is alive!
V. Yes, it’s alive. Technically it remains the best environment for development of Web application, but politically it became the product of the past.
V. It depends on the type of the person who’ll be managing this project. Is it a corporate or a startup manager? A corporate manager is a temporary person. He works 6-12 months and the either gets transferred to another position or leaves the company. He’s not really interested in the end result. He can stay within the budget during specific period of time, but the project may fail in the long run.
Y. Yes, the main goal of the corporate managers is to climb up the corporate ladder and earn good bonuses and pensions rather than creating advanced applications.
V. They don’t always climb up the ladder. Sometimes they move sideways to another firm, where the same position brings more money or other career opportunities. That’s why the success of a specific project may have a lower priority to these managers.
A. If you want to develop two identical projects in Flex and HTML5, there is a high probability that the HTML5 project will be more expensive. But I doubt that anyone will even try to reach the Flex-level quality in an HTML5 project. Any HTML5 enterprise project will have lower requirements in the first place. From the very beginning parameters like reliability, ability to adapt to different the screen sizes and densities will be simplified. Instead of implementing these features, the functional specification will include testing under seven browsers, and developers will spend most of their time in the debugger.
But often the HTML part this is just a tip of the iceberg. The base functionality is usually developed in Java or .Net, and back-office applications should be using Flex for UI anyway.
We spent more than six years in DHTML. We wrote our own framework and implemented DHTML enterprise applications for the Fortune 100 companies. We know all the loopholes in these environments and which ones still remain unpatched. As of today, you can’t compare Flex and DHTML. But there are some narrow fields, where you must complement Flex applications with DHTML.
Most enterprise applications have front end, back end, and back office (support, error fixes, et al.). The front end tier can consist of DHTML and Flex parts because today it’s hard to develop front and back office application in the same environment.
a) Those that allow you to take an existing Web site and, by a magic wand, add new attributes to all
b) The frameworks that are similar to Flex in that they offer high-level components, which may be based on
After further analysis I’ve learned that the framework Ext JS by Sencha is close to what Flex offers, but without compilation, data binding, and with less control.
Y. Would your example work the same way for developers who have dogs?
V. Yes, but the number of errors will increase.
A. Today I lead projects that use both frameworks. JQuery is a light framework (code wise) and it can be used to program about 80% of a Web site. You should use it for the look and feel support, which is what it’s meant for. But you can’t use it for building your application component model. The component model of Ext JS is applicable in about 20% of a Web site, which includes an application piece rather than just being a set of Web pages. Typically it’s a serious view navigator or a wizard to implement a serious business process or a workflow that includes a client’s part.
Y. Data grid, of course…
A. Yes, high-level components and a workflow because often the user needs to perform several steps to complete a business process. And these 20% of an application will require 80% of the project time of complex development. So you won’t need to choose between these two frameworks. My main problem with AJAX projects is not how to pick THE best framework for development, but finding the right software developers. It’s hard to find people who don’t have cats around and can concentrate.
V. Absolutely, an extreme concentration and attention is a must.
Y. Or you can use one more framework that will take care of testing.
Y. Plus Java doesn’t support dynamic programming…
A. These questions were raised many years ago – remember the languages like curl? These languages were in R&D…
V. But they never became standardized for the use in Web browsers.
A. Partially this is correct. If you want to create a real dynamic or static language with the error checking and runtime compilation, you’ll have to substitute their constructors with the strongly-type ones that can throw exceptions.
C++ supports operator overloading and people used this feature for some time. But it didn’t last long – they realized that it’s hard to read and understand their own code. If a language allows you to write a code fragment that’s hard to understand – it’s better to remove this code.
In the compiled environment I’d always known each type and if an object still had certain properties or they were removed. But there is nothing like this in interpreted environment.
A. You can research the code, open each base class and check the references and find out what the properties are – the language will help you with this. I liked dynamic languages when I was 26 years old. A development manager will also have to hire young and very enthusiastic but inexperienced developers.
V. Today’s labor market consists of such people – inexpensive, enthusiastic, and inexperienced.
A. On AJAX projects such a developer will spend the first two months studying, on the third month he’ll start working, and in six months he quits for a simple reason – development is hard and the project arrived to a dead end. When the code base of such project reaches critical mass, the development process gets stuck.
V. The developer will quit not necessarily because the project got stuck. This developer will get more rewarding offers on the job market.
A. In other words, the project stops in 5-6 months – it becomes unmanageable because of its size. That’s why I’d like to stress that there is big difference between AJAX projects and those that are being developed in a compiled environment like ActionScript.
V. The core part of frameworks try to address browser compatibility. They try to ensure that the page works as good as possible in every browser within its limit. But the script will work.
A. I don’t agree. In my opinion you can achieve browser compatibility not on the framework level, but by testing and adjustment of your application in different browsers. The statement that it’ll work somehow is an exaggeration. The chances are that you’ll have to fix the framework.
V. True. I already started making some changes in the framework even without developing overly complicated code. Maintaining compatibility is a huge challenge for any vendor that supports a framework. I remember our XMLSP framework that we created in the beginning of this century. We had a client form Great Britain who said, “This product is bigger than your company”. If I’m not mistaken, there were five of us who worked on XMLSP.
I’m sure, Sencha has more developers who work on Ext JS, but the framework is a lot bigger than we had. Most likely the code base and the task they are trying to achieve are comparable to Adobe Flex. No wonder that any such framework will always need some fixes and improvements.
A. To rephrase what Victor said, either work with the simplest framework components that don’t give you compatibility problems or get ready to roll up your sleeves, learn what’s under the framework’s hood and staff your project with not not only application developers, but with systems engineers too who will spend half of their time on customizing the framework.
V. At this point the framework becomes your product too. I wouldn’t agree that half of the time should be spent on customization of the framework. It all depends on the long term plans. If you bet on a particular framework and plan to use it for years, than invest into its improvements But if this framework just had to address the needs of one project, just apply some patches and move on. In most projects patching a framework will suffice.
– Reliability of communications. What if the data never arrive from/to the server? Is it possible to recover the lost data? Where they got lost? Can we re-send the lost data? What to do with duplicates?
– Modularization of your application. If a user never clicked on a certain menu item on the main screen, don’t even load the code that should process this menu.
– How quickly the main window of your application is loaded to the user’s computer? How heavy is the framework’s code base?
– Where to store the application state – on the server or on the client?
– Does the framework offer a rich library of components?
– Does the framework support creation of loosely coupled application components? Is the event model well designed?
– Does the framework of your choice cover most of the needs of your application or you’ll need to use several frameworks?
– Is well written documentation available?
– Is there an active community that can help you with technical questions?