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.
Flex is undergoing “Under New Management” transformations these days. Even though Flex remains the best framework for development of Web applications, you can feel the pressure of HTML5. But using just HTML5 is not enough for development of Web applications – you’ll need the same old Dynamic HTML – HTML, JavaScript, CSS, and XMLHttpRequest object.
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.
A. In fact, this was a more progressive model than what’s offered by today’s frameworks supporting HTML5, because you could use a markup language combined with JavaScript to support your components. This model was similar to what Flex offers. Today, we see some kind of a plugin environment (a lowest denominator between the Web browsers) that allows using various frameworks. The situation is this field didn’t get any better.
On the positive side, the Web browsers have changed and performance of JavaScript improved substantially. The browsers support 6-8-12 connections per domain (as opposed to 2 five years ago), which gave a performance boost to AJAX applications.
Y. But let’s get practical. Say, I’m an enterprise IT manager with a limited budget and a 5-men team that has to develop a Web application. If I’d be using a predictable VM-based environment like Flex or Java with good tooling (IDE, compilers, debuggers, profilers) my job would be easier. But with JavaScript, the situation is different. First, the development cycle with JavaScript is longer (read more costly).
Second, not only I need to find skilled AJAX developers, but they’d need to know a bunch of modern JavaScript frameworks. Third, compilers are not catching programmers errors so I’ll need to allocate more time for testing. Victor, what’s your take on this?
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.
Y. And now many enterprise architects will say, “We told you to stay with JavaScript 5 years ago…” But I’d like to get your opinion about the cost of development using Flex vs. JavaScript. What’s more expensive?
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.
The hourly rates of JavaScript developers are smaller than of those who know Flex. And development with Flex is easier, the results usually look better comparing to today’s JavaScript-based applications. Development with Flex may be more costly initially, producing better results, which is not that important to the corporate managers.
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.
Y. So what’s more expensive – Flex or JavaScript projects?
V. As you know, we develop in Flex all internal projects at Farata Systems. But if the clients are ready to open their wallets for JavaScript development, we gladly help them.
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.
You’ll save on the compilation time but will spend more time testing during the runtime. The final deliverable of an HTML5 project may have as low as half of the functionality comparing to the same project developed in Flex. But you’ll gain a little better Web adaptability, easier implementation of full text search and mashups. The integration with other technologies will also become easier with HTML/JavaScript. You have to decide if all these advantages are important to your application. If they are – choose HTML5.
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.
Y. All these people marching undwr the HTML5 flags will gladly start new JavaScript projects because it’s available everywhere, it’s free, the frameworks are open sourced and don’t belong to these filthy rich corporations like Adobe. In the past, it was cool to hate Microsoft, and in early 2012 is cool to hate Adobe. Do anything you can, cut any corners, lose functionality but don’t start a new project using Flex. This way we’ll belong to the mainstream – we’ll develop in JavaScript.
A. Yes, but JavaScript will enforce its limitations on any serious and complex enterprise project. You can develop a number of fairly independent windows, but creating a well debugged application (not a site) in HTML won’t be easy.
Now let’s return to the premise that performance of the browsers is substantially improved. Since JavaScript frameworks have to support various browsers from the same code base the size of their code increases, which lowers the performance and overall user experience if you compare similar Flex and JavaScript applications. I recommend establishing well defined boundaries between front and back office applications. You don’t worry that much about the productivity of the external end users. But if we talk about the internal enterprise users (back office), each of them is a salaried employee and they’d better be productive.
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.
Y. Let’s talk about the situation on the market of JavaScript frameworks. There were about 200 such frameworks five years ago. In 2012 the situation is a little bit different – we’re talking about dozens of JavaScript frameworks. But still, there is no one framework that could cover all the needs of your Web application. Victor, what’s your take on this?
V. After Adobe has shaken the Flex world, I was shocked for a while. But then I realized that any good tool or environment should be replaced with the newer one some day. After spending some time researching the modern market of JavaScript frameworks I noticed that there are two main categories of frameworks:
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.
I often use an example of a cat running over the keyboard of my laptop while a JavaScript file was opened in a text editor. Even if I didn’t notice this, I could successfully check in this file into a code repository, but it may not work afterward. Un-compiled environment is a dangerous place to be.
Y. Would your example work the same way for developers who have dogs?
V. Yes, but the number of errors will increase.
Y. Currently, the legions of developers are moving in the direction of JQuery framework. But we are moving perpendicularly. As you stated earlier, JQuery is good for improving an existing JavaScript site. With Ext JS you start with designing your application’s UI as close as possible to object-oriented principles. Ext JS has rich set of UI components, loader, offers an event model – it’s a different and better approach, right Anatole?
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.
V. Absolutely everything must be thoroughly tested over and over again. Refactoring in JavaScript is a nightmare.
A. A software developer has to remember everything – all unfinished pieces of code. Many things that we take for granted in a compiled language are simply not supported in JavaScript.
It’s worth mentioning another type of frameworks that use Java for development with further generation of JavaScript, which is a controversial idea, because after writing the code you’ll need to debug it. This is when you’ll meet JavaScript, which is a foreign language for you.
Y. I guess, you mean GWT. There is one more reason of why this is a stillborn idea. The ideology and psychology of programming in JavaScript and Java are different. Five years ago I’ve written an article demonstrating how Cobol, Java, and Lisp programmers solve the same task differently. I guess, it’s time to add a JavaScript version to this example.
A. A person who writes in Java/GWT has to know how to read and interpret the JavaScript code in the debugger. Besides, GWT hides a large portion of JavaScript functionality.
Y. Plus Java doesn’t support dynamic programming…
A. Not too many people use dynamic programming, but it would be nice to change the language. Twenty years ago there were mixed languages that would allow using the dot notation to request some code fragments to call dynamically and some statically. We had a choice to either compile an operator or interpret it during the runtime. It was up to the developer. I won’t have peace of mind until JavaScript will support this.
V. Anatole, how many years should pass till people will accept the notion of compiled language running inside the browser (JavaScript, ActionScript, et al) along with an interpreted language?
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. Exactly! Apple didn’t let Flash Player in their popular devices, and this became a huge obstacle for the evolution of Flex. The same thing may happen if some vendor decides to not allow any other language or environment in their devices killing these new ideas. For example, Google came up with a new language called Dart, but Microsoft says, “No, we’ll be improving JavaScript.”
Y. JavaScript frameworks promise to hide from you all incompatibilities and take care of the cases when a vendor won’t let some features in their environment.
A. I don’t think anyone will be able to translate the world literature into the language of the tribe Tumba-Yumba with very limited expressiveness. There are reasons why some languages are better then other for different tasks or application sizes. JavaScript is a very basic language.
V. But if you take Ext JS, their documentation suggests to use ext.create instead of the operator new. Technically they are extending or replacing the constructs of the JavaScript itself extending the alphabet. Any framework architect who wants to create a controlled environment will run into a JavaScript wall.
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.
V. I’d like to add to the subject of comparison of the JavaScript and ActionScript… I feel uncomfortable thinking that someone else will read, support, and refactor my JavaScript code. Actually, I’m not comfortable refactoring my own JavaScript code a couple of months later. In a non-compiled environment it’s tough. I don’t remember what’s the type of the parameter that’s given to the particular function.
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.
Y. I’d like to return to the question of JavaScript frameworks and browser compatibility. I like the analogy with TV sets. Even if I have the latest and greatest 3D LCD HD TV set and you have a 30-year old black and white television, we both can watch the same movie even though the quality of the picture will be different. In modern terms, you can say “The user experience will be different.”
Now let’s talk about the browsers. You use the latest Google Chrome, but I’m a corporate user who must use IE 6. Is it possible to ensure that the same JavaScript application works in both browsers?
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.
I have no hard feelings when I make fixes in someone’s framework. I understand that these guys simply didn’t have time to fix everything. You need to form an attitude that a JavaScript framework is similar to a good Legos set that will require your creativity too. Don’t get angry. Cure the framework. Spend some time working on the framework, and then work on your application code. At least this is how I see the current state.
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.
Y. To summarize, JavaScript developers will need to solve the same task as Java, JavaFX, Silverlight, or Flex developers face:
– 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?
I can keep adding items to this laundry list. So if the words HTML5 easily get you excited, calm down. It’s not just about adding a tag video to a Web page. It’s a hard work with JavaScript. It seems that our company will have a lot of interesting and challenging projects in the foreseeable future, and we don’t complain.
yakovfain.com 
I also think sencha is the only company that can provide framework for enterprise and they have their 5 minutes now after adobe pr disaster.
Good questions at the end, nice points about enterprise browsers and enterprise application most used gui components. To sum up in enterprise nobody cares about button or check box they care about data in data grids, fancy charts analyses, and trees 😉
Interesting discussion, but what do you think of approaches like Google Closure compiler, which compiles JavaScript with annotations, and provides custom libraries to extend the language. The Closure compiler and style checker will fetch most of the errors you could catch with an ActionScript compiler. Google created Closure since they had the need to work on huge JavaScript applications like Gmail, Google Docs and Google Maps.
http://code.google.com/closure/
http://code.google.com/closure/compiler/docs/js-for-compiler.html
Thank you for an interesting article. I suggest considering JavaScript MVC, which is a great framework. It is JavaScript brother of RoR, Djang and Grails. You can develop JavaScript components using MVC pattern, client-side templating, and what I like most is the ability to write functional tests for your components with FuncUnit which executes tests in browser.
Very good article. One should consider things very carefully when there is frenzy and excitement about something new. HTML5 looks promising but as the article points out, there is a lot more to Enterprise Development than simply adding a few new tags and new features. Always be cautious I would say when the masses go crazy over something new and not really mature enough.
It will be interesting to see what happens with Flash/Flex, but even more will it be to see what HTML5 ends up delivering and how long will it take to get there with the right tooling and frameworks. More importantly, how long will it take for JS to deliver a solid enterprise dev environment with the standard tools many other languages have been providing for many years now. We will see, looking forward to see history in the making!
What do you think about http://www.jangaroo.net/ ?
Addressed problems:
– using ActionScript instead JS
– line to line compilation to JS for easy debugging
Also what do you think about JS source mapping ?
https://wiki.mozilla.org/DevTools/Features/SourceMap
And in case of source maps browser adoption the chances of languages compiled to JS (CoffeeScript, Kaffeine, GWT-Java)
Thanks for great post!
One of the optimistic views of the Flash Player taking a back seat to markup-based implementations is that browser makers are including components such as date-pickers, format-focused input fields, and modals. Twitter is the first to market useful and beautiful components close to what we had with Flash Components in their Bootstrap framework. Most of the offerings in Bootstrap appear as if it is actually a browser or host component. I see Bootstrap igniting a trend toward more native controls included by Google, Mozilla, and Microsoft.
Great read, guys. Thanks for sharing. As a Flex developer who’s been working on enterprise-level applications since Flex 1.5, I’ve been soaking up as much information about JS frameworks and HTML5 as much as possible. Your article presents some good points. Have you looked into something called “haXe” at all? This was brought up in a Google+ post I read last week (you should check it out: https://plus.google.com/u/0/109047477151984864676/posts/CVGJKLMMehs) and was curious on what your take on it was? Could it be used to support enterprise development while still taking advantage of our existing knowledge of ActionScript.
Wow, the game has changed with the announcement that Adobe is no longer supporting development for FLASH for mobile devices or TV…it is focusing on youtube html5 and Adobe AIR apps instead….the news got around the game development community quickly. I think the market penetration of mobile devices like the iPad, iPhone, and iTouch from Apple being a merket leader who doesn’t support FLASH made a true impression on developers whose clients pages were losing views by this audience. Comsider Apple’s leadership history introducing CD ROM’s fiirst in computers, dropping the beige look of computers, introucing the iMAc, iTunes, Quicktime, and Jobs support of Blu Ray at Disney helped set standards in many industries…
i want to know career or future of flex learning ?please advice.
Very nice article/conversation guys! It is certainly on of the most mature opinions you can find on the net about the HTML5/Flex fight. Personally i think HTML5 cannot be used for enterprise level applications – the result will be a total mess. I searched a lot and no framework offered features like for ex: item renders in Flex etc. In our company we have created our own Flex framework that parses XML + AS3 Files and generates the GUI. You can also embed PHP or any-other server side scripting language. Let hope Apache will do a great job on Flex.