flex

From Flex to Angular and Polymer

Published on August 23, 2015June 26, 2017 by Yakov Fain2 Comments

I’ve received an email from an enterprise Flex developer who’s looking to converting a number of applications to JavaScript. He asked a number of questions, and I decided to write a brief blog with the answers. His email started like this:

“We have a bunch of existing enterprise Flex web apps.
Since some of Flex libraries are not updated and no longer supported, first we try to find similar libraries in JavaScript and call them via iFrame.”

Below are his questions and my answers.

1) Do you see Flex -> Angular 1 transition as smart pragmatic move, or would recommend to wait till Angular 2 comes out?

Comparing Flex and Angular is not apples to apples. Besides being an architectural framework it included a number of rich and extendable UI components, which Angular doesn’t have. Angular will definitely help you in creating a Web application taking care of the navigation between the views, binding the data to the UI, and injecting services into your components. But this is pretty much it. It doesn’t have its own component that is often needed by the enterprise developers. This is one of the reasons why we started using Google’s Polymer for GUI components.

2) Does A2 has definite advantages over A1? Is it easier and has better tooling?

Yes, it’s easier to learn as Angular architecture is simplified greatly. A2 is component based. No need to worry about different scopes. Any service is a class. No need to create controllers in a special way: a class is a controller. Dependency Injection is easier to use – only constructor injection is allowed. The GUI for the component is specified in a class annotation and can be stored in a separate file. A2 rendering is separated from the rest of the framework code, so it’ll be possible to render not only HTML but the native UI as well (this feature is experimental for now).

3) When will A2 be released? Is it worth waiting for?

Currently, A2 is in its 35th build of Alpha. There are no official release dates, but I believe that A2 will go in Beta in October-November of this year. You can (and should) start developing in A2 today as long as the app doesn’t have to go into production this year. The API of this framework is still being changed so you may run into bugs here and there. But I’d recommend starting new projects in Angular 2.

4) Do you expect to have an easy upgrade from A1 to A2?

It may not be easy, but shouldn’t be overly complicated either. If you have resources you can upgrade existing apps to A2, but it’s not a must. You may live with two version of the app for some time.

5) When will you give an A2 class? When will your A2 book come out?

We were planning to run the A2 class online starting from the end of September, but since both my colleague/instructor/co-author and I have a day job plus a book project in the evenings, we decided to postpone the training until January.

Our book “Angular 2 Development with TypeScript” will be available as a part of Manning MEAP program in September. You’ll be able to buy it and get access to the drafts as we write them. So far we’ve written about 130 pages.

Now I’d like to add a brief comment about Polymer library from Google. Our company, Farata Systems, spent 9 years developing applications in Adobe Flex for different clients. Over these years we’ve created a library of smart GUI components that were not easily replaceable in JavaScript. During the last two years, we were evaluating different JavaScript alternatives but couldn’t find any that would allow us to leverage or experience and migrate our Flex components to JavaScript.

Being very pragmatic and careful, we’ve decided to see how difficult would be to re-create a Flex component in Polymer. Eight years ago we’ve created a combobox in Flex that could take an external data collection as a model and render its data as a grid when the user clicks on it. We gave this combobox to one of our developers, and he re-created it in Polymer relatively easily. Another developer started to work on a pilot project with Polymer and we also see good results. What we don’t like in Polymer is the fact that it doesn’t support module loading. You have to use HTML imports. At the time of this writing, our recommended set of languages/frameworks is TypeScript, Polymer, and Angular 2.

In September we’re planning to publish two technical articles describing our experience with Polymer. Farata Systems is a well-known name in the Flex community, and we’re going to build a good reputation in the JavaScript world as well.

Why I Didn’t Mention Flash Player

Published on July 30, 2013July 30, 2013 by Yakov Fain8 Comments

I was making a presentation to our client on mobile development. It’s a strong Flex-Java IT shop, and our company helps them with Flex development. I was comparing pros and cons of native vs html5. Spoke about the hybrids too. During the Q & A session one person asked me if I was avoiding mentioning Flash Player on purpose?

At this moment I realized, that it was probably the first time when I didn’t even plan to mention it. It happened naturally. I still like the technology, but it would be unfair to lie to the client.

I answered that we are still using the Flex framework and AIR in our own software product that’s being used in insurance industry, and our company will continue helping customers who need help with Flex. The desktop version of our product uses Adobe Flex, and for tablets we use Adobe AIR. But I don’t see commitment from the Adobe to Flex or AIR. The compiled AIR application works slower on tablets. Creating a build with AIR for iOS can take from 30 minutes to an hour. I also said (may sound pathetic, but this is what I honestly feel), that I spent 5 years of my life with Flex, but with tears in my eyes I say “Don’t do it”.

This product was abandoned by Adobe, support for new platforms/SDKs is weak, Flash Player crashes a lot more often than three years ago, eats up all the CPU – it seems that it’s been simply ignored.

Now Adobe has a new pet called PhoneGap. Similarly to Flex, Adobe donated PhoneGap library to Apache Software Foundation. But this time Adobe has a plan to monetize on such a gift – they created a Build PhoneGap cloud service, which can package your HTML5 or Hybrid Web application as a native app. I like PhoneGap, and wish Adobe to succeed with this product. But Flex is going away from the enterprise Web toolbox.

My today’s hope is for Dart – an interesting language from Google that can run either in the compiled mode in the Chromium browser’s VM, or (automatically) turn the app code into JavaScript and run as usual. The Dart VM is not in Chrome VM yet, but you can run the JavaScript code generated by Dart in any browser (see http://try.dartlang.org/).

HTML5 or Flex Framework

Published on January 21, 2013February 1, 2013 by Yakov Fain6 Comments

More than a year passed since Adobe decided to stop supporting Flex framework and gave it away to Apache Foundation. This writeup is based on the conversation I had with my colleague Anatole Tartakovsky in January of 2013. In this conversation I’ve been representing the HTML5 community while Anatole fought for Flex framework. I’m trying to find arguments against using FLex framework even though I believe that it remains the best and the most production way for developing Web applications. I’ll be just playing devil’s advocate here. Anatolepoor and ill also believes that Flex is the best framework available today, but in our company we often argue about the tools to use for various projects. We hope that Web developers find this conversation useful and thought provoking.

Yakov. If you read this blog, most likely you know about our company, Farata Systems. Our engineers work on both consulting projects and develop a product for our sister company SuranceBay that creates software for insurance industry. Technology-wise, we have three practices:

1. Rich Internet Applications using Apache Flex and Adobe AIR
2. Web application with HTML/JavaScript/CSS
3. eCommerce applications (we have about 20 Hybris developers)

On the server side we use nothing but Java. We’re hiring people, but noticed that it’s getting a lot more difficult to find experienced Flex developers. Last week we made an offer to a Flex developer, but before accepting it, he asked me to share my opinion about the future of Flex. He knows about our company and is glad that he’ll be joining our team, but at the same time he’s worried that Flex skills won’t be a useful asset on his resume. I can read his mind, “I’ll waste a couple of years doing Flex, but my classmates, colleagues and the rest of the progressive mankind will be studying HTML5. Is it worth it?” I did my job defending Flex, now it’s your turn, Anatole, and I’ll try to prove you wrong.

Anatole. As I just learned, I’ve been working with useless technologies for 30+ years, and every technology I liked is not in use anymore. In my opinion, Flex framework has no future.

Y. What a nice way to defend Flex! Do you want to say that your programmer’s life was wasted?

A. I want to say that it was extremely interesting, but Flex has no future.

Y. Was this by M.Zhvanetsky who said, “Who cares about the soup if so much is going on in the kitchen“?

A. I’d rather say that Flex has no future, but it has the present. HTML5 has the future, but the present is dark and foggy. First, we need to decide if we live in the present or in the future. Second, it’s very difficult to properly guess the technology worth studying and using. Of course, the tools that are popular on the market will win, but they will also lose by attracting legions of low paid developers. Besides, being unproductive these tools won’t allow timely releases of high quality software. This leads to further degrading of software projects and programmers’ pay. There is a high end market, where more expensive and rare tools are being used by well rounded developers. And there is mainstream that uses various versions of HTML, Visual Basic and the like. These tools were never highly productive, but their better competitors could not attract even a one tenth of the developers community. At some point the psychiatric situation on the market causes people to not pay attention to the good tools, but rather go with the flow.

Y. Our company is not a typical one – each of the owners remains highly technical, and we don’t have any political reasons to select or reject any technology. Sure enough, we are very carefully monitoring the latest trends in the industry to be able to offer help in IT consulting. But we are down to earth people who want to deliver our own software as fast as possible without jeopardizing the quality of the product. You may be surprised, but new Flex projects are being started and the Flex-to-Flex redesigns are happening on the Wall Street – we continue getting requests for help. Such projects are typically run by smart and technically savvy managers who are not afraid to voice an opinion that may differ from the general software policy in their organiation. But an average manager does not want to take a risk and use a non-popular technology with a literally non-existent talent pool. Anatole is running the project where all developers know Flex and Java, and he’s not planning to switch to a different set of technologies any time soon. Why do you prefer Flex and AIR.

A. I’m planning to switch and will do so, when I’ll see a better than FLex technology that meets our needs. I agree to switch, but it’s like “Tomorrow I’ll marry the Queen of England. Half of this plan is accomplished – I agree“. The problem is to find a replacement. IMO, technologies like HTML5 will change the style of programming and the resulting product too.

Y. After making such strong statements, you need to say something to improve your credibility. Please tell the audience what did you work on in the beginning of this century.

A. There were no alternatives to HTML/JavaScript before the Flex framework was created. We had DHTML, HttpRequest and XMLHttpRequest, which was later branded as AJAX. The CSS capabilities were limited, but it was not that important because there was only one enterprise browser back then, and styling just worked without the need to worry about the incompatibility issues. We’ve been creating libraries having the functionality similar to ExtJS. They were not as polished, tested, and documented as ExtJS, but productivity-wise they were at least as good as today’s HTML5/JavaScript mainstream libraries. I was leading a team of 5 developers that were working on this library (XMLSP) from 1999 till 2004. But to create a product as good as Flex, the community would need to create 6-7 products that would comprise a platform that would include the following:

– a much more mature JSON that would support the skeleton generation on both sides
– a compiled JavaScript-like programming language (expecting to see it soon)
– an ability for creation of the finite state machine and CSS (give it another 2-3 years to appear)

Unfortunately, during the last seven years Flex didn’t have competitors. HTML is the future, but it’s a remote one. I don’t see it real in the enterprise applications for at least two years, but more likely till 2016.

Y. You’re talking about enterprise Web, not about small Web sites that can be easily developed in HTML5. All evangelists are happy to demo simple applications like Contact List to prove that HTML5 and their JavaScript framework is here to stay and is THE Framework to use. The rookie developers are often impressed by a demo of an HTML5 game moving objects using an HTML SVG element. To get cheap applauses at a Web conference you need to proclaim, “No more plugins like Flash or Silverlight. RIP!”. It’s even more effective than making fun of Internet Explorer.

A. True. If you want to write HTML5 application you need to seriously reevaluate what your application should be able to do. You’ll need to simplify it. A typical enterprise Web application serves the consumers that don’t use it anyway, and it also serves the professional business users that help consumers.

Y. Please don’t just make such ungrounded statements. Explain, what this means.

A. This means that consumers spend very little time using these Web applications – they they don’t use such applications from 9 to 5. These applications are being used on a weekly or monthly basis. The requirements for such applications are a lot simpler than for heavily used applications for professionals. The back office applications must increase productivity of business users and support a lot more functions. If you need to support wide variety of users, you’ll need environments allowing configurable applications that can be compiled and support quick refactoring for the new class of users or when the business requirements change.

Y. I agree that refactoring in Flex is more advanced than in JavaScript, but what are the problems with configurable applications?

A. By configurable applications I mean the ability to quickly customize the application with the same code base to support more complex or more simple interface and security. It’s not so easy to do with JavaScript, because it HTTP requests can be disassembled, you’ll have to deal with security problems, the code becomes more difficult to understand without having the compiler’s support.

Y. As far as I remember, Flash Player was also blamed for security holes, wasn’t it? Besides, since HTML5 is a mainstream, all major browsers treat security issues very seriously and all security holes will be closed a lot faster than any single vendor like Adobe, Microsoft, or Oracle would do.

A. The roots of Adobe’s security holes are in attempts to merge two incompatible security models of Acrobat and Flash Player. Now you can run Flash code inside PDF, which revealed security holes originated in incompatibility of the sandboxes. Most of these holes can be plugged by changing security settings of Acrobat and not by fixing Flash Player’s errors. But overall, Flash Player has less security issues than infamous cross-scripting of Web browsers and the likes. We are able to create secure Flash applications that would certainly had security issues should they be written in HTML5. What I really miss in Flash Player is the ability to integrate with telephony and work with peripherals that exist in natural environments. Unfortunately, Flash Player is not evolving fast enough to support new technologies for input/output and the voice interface. The main problem of Flash Player is that it was literary frozen since 2008. During the last four years Adobe didn’t do much to bring it up to date.

Y. It’s been more than a year since Adobe announced that their main interests for Flash are games and videos. You can’t expect any improvements in Flash for enterprise applications. Don’t forger that Adobe remains the owner of Flash Player, and no matter how great the Apache Flex contributors are, their hands are tied – the runtime is out of their control. I don’t like the way Adobe handled open sourcing of Flex, but they have business to run, and if they make money elsewhere, no one can force them to allocate proper resources to implement Flex and Flash Player improvements. Do you have any reasons to believe that Flex won’t lag more and more behind HTML5 technically?

A. I don’t have any hopes that Flex won’t lag behind. So far Flex and Flash player is still far ahead – we still live in the future comparing to HTML5. Yes, HTML5 has some features that make it appealing for enterprise and mobile development, and it would be great if Flash Player would continue evolving in these directions too. The main reason why Flash Player is dying is that ten years ago Adobe rejected Apple’s requests to create tools for their platform. Adobe considered this platform unproductive, and Apple had to recreate equivalents for all Adobe’s products themselves. After that, Apple stopped allowing Adobe’s products on their market. You can call it politics or personal vendetta, but unfortunately there is nothing you can do about it. Without Apple’s support Adobe’s tools will always have hard times. Will it change in the next couple of years? Not likely, unless the structure of both Adobe and Apple’s management will change.

Y. Based on what I see, Adobe won’t be willing to make steps toward Apple. Adobe prefers selling expensive and profitable software to corporations, and it’s not likely that they’ll return to Web browser’s plugins that are not welcomed by majority of the developers.

A. This is true for the most part. But historically, there were precedents when spin-offs were created to purchase some of the software products from large companies. Adobe is not the first company specializing in milking old cows (making money from old products). I.e they don’t improve some of their products, but purchase established third party companies and invest in cross-integration with their products charging the newly acquired customers for the new functionality. The chances are that non-profitable Flash platform can become a candidate for such a spin-off. Adobe might sell the Flash Player for a small chunk of cash to people who are interested in improving this technology. Unless this happens, Apache Flex is a still baby. I’ve attended several meetings in Apache Flex community, but I’ve yet to see people who can lead this community.

Y. There are lots of excellent Flex software developers in the world who could do it, but they simply can’t afford it. As I said, there is not many companies that can continue using a technology based on its merits. Flex experts need to make a living and feed their families. They can’t spread themselves thin doing both Flex and HTML5. They either work as independent contractors and want to keep their hourly rates high, or work as enterprise employees and don’t want to go against corporate IT policies. Many of them prefer to stay focused on one major technology to keep their skills in demand.

Our company is in minority, but we are not afraid to become known as one of the last Flex shops. We believe in hiring well rounded developers that are open to adding Flex to their skill set understanding that in a couple of years they may need to learn something else. By the way, some of the people are still doing Cobol and dine in Michelin-starred restaurants on a regular basis. The if-statement exists in every programming language. In some cases you’ll need to put a curly brace after if, and in some languages you need to write elseif as one word. Some languages support classical inheritance, and some – prototypal. This doesn’t scare me, but it seems that lots of people are reluctant to accept that learning something new is a way of life of professional software developers.

A. Of course, people have to take care of themselves, but if I were a young software developer, I wouldn’t worry that much about any particular technology. Let’s go back to the year of 2008, when Flash Player’s penetration on desktops was about 99% and no one could even imagine that this bulldozer could be stopped. Adobe offered to use ActionScript 3 as the ECMAScript standard arguing that they have a compiled and extended version of JavaScript, and Flash Player can be used as a virtual machine for the code produced by this language. Web browsers would simply need to recognize in HTML documents, which is an easy part.

Y. In the 90th, some people would even do language=”VBScript” for Visual Basic Script.Today, you don’t even have to specify that your scripting language is JavaScript – it’s a default in all browsers, and the language property is deprecated. Actually, you should be using the type property instead of language, and if it’s missed – JavaScript is assumed.

A. But browsers can support other languages, but there is no standard language. Sooner or later Microsoft and other companies that decided to deny ActionScript as a standard compiled language and solve the problems of performance and refactoring of JavaScript will need to solve these problems. And the future HTML6 or 7 will include a compiled language that will look very much similar to today’s ActionScript. Yes, it may have different keywords, support even more dynamic constructs and do a better job with eval, but the young developers doing ActionScript will be better positioned in three years than those who develop in JavaScript. Most likely, the ActionScript code developed today will be converted one-to-one to this new language of the future.

Y. Did you have a chance to get familiar with the Microsoft’s language TypeScript?

A. I haven’t. But when we were developing our own browser, when JavaScript would pass the first version of p-code we would create and cache automated objects to avoid recompilation of JavaScript.

Y. The syntax of Typescript extends JavaScript, but it supports static types, classes, and modules, and can be compiled into JavaScript, i.e. will require nothing, but JavaScript engine. On the other hand, Google’s Dart expect a browser to have a VM in addition to JavaScript engine.

A. No matter what language will win, the conversion from ActionScript will be mechanical more or less. It all comes down to your way of thinking and to the level of complexity you can afford in a compiled environment vs interpreted one. There is a major difference in approaches to programming in ActionScript
and in JavaScript. After spending some time designing and writing the ActionScript code you fix most of the syntax and refactoring issues during the compilation and linking stages . In JavaScript you can immediately test your code without getting error messages even if your code has the wrong syntax or linking problems. The time that Flex developers spend beatifying the code while writing it, JavaScript developers spend debugging their code in runtime. Programming in dynamic and static languages requires a big cultural shift. Developing complex projects in JavaScript is extremely difficult. If application developers have no prior experience in developing frameworks in JavaScript, they can only deliver Web applications with a set of relatively simple Web pages with limited functionality. Regular programmers who don’t remember what they have written yesterday, will have hard times debugging their own code. I’m not trying to insult people, but unless you can keep in your head all your code, the chances of producing well functioning large JavaScript application are very limited. I recommend to spend the next several years in a comfortable environment waiting till HTML6 or 7 will include a compiled language. In my opinion, when it happens, you’ll need to forget most of what you’ve learned about HTML5.

Y. I don’t agree with you. We didn’t talk about the development for mobile devices. You are talking about programming in a comfortable ActionScript environment, but why not spend a couple of years learning HTML5 methodologies and tools that would allow today’s Web developer digest the Mobile First concept, learn how to properly modularize JavaScript code, which frameworks to use in both desktop and mobile devices, what Responsive Design is about, is it possible to live with one code base for all devices or it’s better go hybrid or even native, and on, and on, and on. This takes a lot of time, and, putting yourself in the shoes of that young developer, spending these couple of years in learning all this new world won’t be a waste of time. By the way, in the book “The Enterprise Web Development” we show how to develop a Web application that will work in all devices from the same code. So I don’t believe that developing in Flex for a couple of years will allow this guy just to change the hat and start writing HTML/XYZScript/CSS code. I’m sure that just working in your team would make him or her a well rounded developer, but it’s not as obvious for other people.

A. If this developer would work in my team since 2006, he’d skip lots of frameworks like Mate or Parsley without losing much. People who say that their frameworks help in programming are the same that were promoting the Axe Soup before. One way or the other – good people is the solution. Frameworks rarely help. Tools do. HTML has a number of tools to test UI on different platforms. Similar tools were created for Flex and cross-platform CSS and skinning. But I don’t believe in miracles. I haven’t seen a single-code-base applications that work well on Android, iPhone, and desktop browsers.

Y. We need to compromise. In Flash Player applications you can choose pixel-perfect design: the user must have a 1024×768 viewport minus chrome and margins – my way or highway. But if you’ll need to make this application work on highly fragmented Android market, on iOS, Blackbery, desktops, and other devices, ask yourself a simple question, “Do we have money to hire two-three teams for developing and supporting several versions of the application for different devices or we’d rather compromise, and push the HTML5-based product out the door?” Money talks in the enterprise unless your project has unlimited budget. But if you’ll agree to compromise and move away from the pixel-perfect world accepting the fact that the Donate button will look a little bit different on different devices, go with the responsive design principles and have one code base. You’ll provide different CSS sections that will automatically apply different layouts based on the screen (a.k.a. viewport) size, but the HTML and JavaScript will be the same. I know, this approach has drawbacks cause some portions of CSS will be loaded for nothing to any particular device, but it can be a practical business solution.

A. People who promote the same design for different platforms usually talk about publishing information and not about interactive applications. If you need to publish the information using different layout managers, responsive design will help. But enterprise applications often have more than one target audiences. Consumers need an easily downloadable application and Web browser works fine here. Mobile applications should be compiled either into the native code or into some byte code that performs close to the native one. But UI must be different based on the available screen real estate and use touch interface.
If you’ll take any framework that works on both desktop and mobile devices you’ll get two sets of controls and the need to maintain two different source code.

Y. Nobody forces you to use any framework – just stick to JavaScript and, maybe, non-intrusive jQuery components and plugins.

A. Without frameworks I’ll have less UI controls to chose from. Frameworks may address the need in controls and convenience of UI.

Y. and browsers incompatibilities

A. Maybe. But when I hear that someone has the same codebase for the desktop browser and other devices, I want to see it and make suer that it doesn’t falls into the publishing realm.

Y. Of course, the Boston Globe site is a classical example of responsive design in publishing. But we can even take an application that we use in our book – Save Sick Child http://enterprisewebbook.com/#_responsive_design_one_site_fits_all. We have five areas (div’s) that include forms (a donation form or an online auction), each form is a separately loadable module, and if on the wide screen we could display three of these div’s horizontally and two underneath, on the narrow screen each of these sections will be scaled down and displayed one under another. And this is not just a publishing application.

A. When I’m porting an application to a tablet 800×600 with UI having large controls and fonts, I need to think about this application as a service to minimize the need of data entry. Don’t forget that half of the screen will be taken by a virtual keyboard, and if you ignore this, the user will have to work with your UI via a keyhole, and even these five separate div’s may not fit. So I’ll need to modify the UI and use the set of controls that will require minimal data entry. I don’t want to give the same UI to the consumers and back-office users.

Y. I keep trying to bring the money into our conversation, but you are avoiding this subject. Sure, it’s better to be healthy and wealthy, than poor and ill. But most of the enterprise projects are poor and ill, i.e. have limited budget and developers are not overqualified. Why a modern enterprise employs many low-qualified people is a subject of different conversation – let’s not go there.

Coming back to my five div’s, we can use CSS to hide what has to be hidden in certain devices, fonts can become larger, and we can use so called fluid grids to have our layout float. It may not be perfect, but it’s a compromise.

A. You can’t turn a truck into a car and then into a bike just using styling. I’m for complete redesign to use the features of a particular platform to its fullest. And the reason why IT has so many low qualified people is because these people allowed non-technical people to lower their qualification. We can help them to improve their qualification.

Y. Most people don’t want it. They live comfortably with what they know.

A. You and I are sitting now in a lobby of a fancy hotel that differs from a motel, right? Why? Because we’ve decided that the service has to be well compensated. And people working in this hotel do their job well. There is always market for the high-end things, which were produced better then others of the same type. If you’ll be producing low quality software, you’ll hate your job, which will shorten your life. Why?

Y. I hear you, but don’t agree with you. It’s great that you and I can afford now (it may change) to work only with interesting projects. But many young programmers have a long way to go before they will establish themselves to pick what they really want to do. Id your message “Just do what you like and the day will come”?

A. If you need to work hard to establish yourself, why doing it where the crowd is? Do it in the unpopular areas.

Y. Most of the people prefer to walk on the paved roads. It’s a reality.

A. Compare software and automotive industries. Some time ago you could have selected any car as long as it was black Ford of a certain model. Then General Motors started mass production of cars where people could select different models of different colors. By dong this they pushed Ford back. The software industry will go through the process of customization. We already reached the point when the software created for a certain enterprise is being replaced by a software-as-a-service (SAAS). The next task is not to create several versions of the same page with CSS, but understand what the user is doing with this page and to make it as convenient for the user as possible. If this will be happening, then software developers will transform into people who belong to service industries.

Y. I may disappoint you, but there were many attempts to cultivate a new creature – a cross of the user experience (UX) specialist and a software developer – it didn’t happen. These are different people with different mindsets.

A. in the end the winning applications will be not the ones that will have nice looking design, but those that will do what the user needs and will do it conveniently.

I have to finish this rather large transcript although our conversation didn’t stop here. Thank you for reading this far. I’m not going to give you a summary with recommendations or predictions of what tool or programming language is the best bet in today’s development of the cross-platform UI. Pick what you like, dig deep, and enjoy your work. It’ll pay off sooner or later.

Java Basics for Flex Developers

Published on August 10, 2012August 10, 2012 by Yakov Fain1 Comment

Our company continues using Flex framework for development of our own product for insurance industry as well as for various consulting engagements. Being responsible for interviewing Flex developers, I see how the situation on the job market of Flex developers is quickly changing. If a year ago finding a senior Flex developer was mission impossible, during the last two weeks I’ve interviewed five applicants for the job, and three of them were seniors.

But all of their resumes have one thing in common – no or very little exposure to the server side technologies. I can foresee that more and more seasoned Flex developers will have to face the same problem: no Java means no job.

That’s why I decided to run an online presentation for the members of the NJ Flex Users Group. This rather long presentation has been recorded and is available as a screencast.

I’ve explained the Java basics comparing this language with ActionScript 3 everywhere I could. This presentation started with a quick HelloWorld in Eclipse, and then quickly progressed to abstract classes, generics, multi-threading and Java servlets. The more time a Flex developer spends with Java the better.

Attending QCon, a Smart Conference

Published on June 21, 2012July 27, 2012 by Yakov Fain2 Comments

The last three days I spent participating in the QCon conference in New York City. This is one of the small group of conferences catering to software developers. Running a 100-speakers conference around the world is a hugely expensive project, and I hope the organizers broke even, which is very difficult in New York. Long story short – I like this conference. Speakers are well prepared, the crowd is eager to learn, the food is good, and the Wi-Fi works (I kid you not – 20Mbps up and down).

There were six parallel tracks at the event, which were changing each day. This is unusual, but smart. Every morning would start in the main auditorium, where the track chairs would introduce every presentation from their track. This is also something I’ve never seen before at any conference, and I can confess that these short intros changed my personal selection of the talks.The third thing that impressed me were presentation evaluation sheets. This is how they looked like:

The KISS principle in action! Instead of forcing people to fill out these annoying questionnaires from traditional evaluation sheets, the attendees were asked to pick a sheet of the appropriate color and drop it in the bowl. Green, if you like the preso, yellow means the presentation deserved to be a part of the event, and red if it sucked. If you wanted to add some comments, pens were right there – just write whatever you want on this little piece of paper. Smart. Keep it simple stupid.

During these three days I’ve attended a bunch of quality presentations:

Security weaknesses in Java was very practical, and I can apply the new knowledge to one of the projects I’m involved with.

Learning how NASA uses cloud computing to process information from Mars rovers is another fact that may finally push me into the cloud space.

I was surprised to learn that Node.js, a server-side JavaScript framework, can process 695K transaction per second. It’s really impressive even though Java did 3.5M TPS in a similar setup.

I like presentations by Cameron Purdy. This time he was talking about HTML5, Mobile, and compared the roles of Java’s and C++ in today’s IT. He’s well spoken and always add lots of appropriate jokes to his talks. Cameron listed a couple of reasons of why Java didn’t supplant C++. But IMO, didn’t mention the most importan ones:
1. Apple’s iOS has no Java
2. Microsoft didn’t upgrade JRE in Internet Explorer since ’98 (remember that infamous Sun-Microsoft las suite?)

Arun Gupta from Oracle is an excellent speaker, and it was interesting to see his first presentation showing how Java EE moves toward HTML5 clients (JavaScript – JSON-WebSockets-JavaEE).

I like FireFox’s add-on FireBug – the HTML/DOM/CSS/Network/JavaScript inspector/debugger. Now I know that it’s safe to install Firefox nightly builds to enjoy the latest greatness of this popular browser.

Peter Bell was showing how to use Spring Data with No SQL databases. While he was talking about a hierarchical databases, I felt like déjà vu. Seasoned (a.k.a. old) software developers knew about how great the hierarchical databases were since the last century. But working with them was not for the faint of hearts. SQL looked simpler, so programmers embraced relational DBMS. The years went by, and an average programmer became a little dumber, and SQL became a tough language to learn. This resulted in the flourishing of the Object-Relational Mapping frameworks. You know Java, but don’t know SQL? Not a problem. You’ll survive on our project – just write Java and XML. It’s going to be long, painful and non-performing, but ORM will allow us to bring juniors on board. Now, it seems that Spring Data can hide the complexities of dealing with hierarchical databases and even juniors will be able to work with them. Good luck, guys!

Charlie Hunt did a great job explaining the internals of Java garbage collector. Check out his recent book “Java Performance”.

Steve Souders is THE web performance guy. This time he was talking about performance of high performance in the mobile. Not sure if you are thinking about moving your application or a Web site to mobile, but you definitely should be.

Yesterday, I went to hear the presentation by Adobe’s evangelist Christophe Coenraets. I have a rule – if Christophe present at the conference I attend – it’s a must see. No matter what he’s talking about, his presentations are clear, well prepared and up to the point. In the past he was covering various Flex-related topics, but after Adobe decided to kill Flex, he’s working in the HTML5 field. Christophe’s presentation was about using JavaScript on mobile highlighting access to the native APIs via the PhoneGap library. IMO, this is a right way to go and I enjoyed this talk.

Adobe Flex framework remains a touchy-feely subject for me regardless of my own principle “Don’t fall in love with the Phillips screwdriver”. Any tool is just a tool, but I really enjoyed working with this framework. I understand that corporations exists to make profits. I understand that if a software product doesn’t bring money to the firm, one of the solutions is to nuke it. But it shouldn’t be done in such a cynical way. Last year, at Adobe MAX conference they said that the future of Flex is rosy, a month later they announced, “We donate Flex to Apache Foundation” explaining that Adobe’s changing the direction. That’s fine. A month later, they applied a hit man technique – an additional shot in the forehead – to make sure the body is dead for real. Adobe said that the Flash Player, the runtime required for Flex won’t go to Apache, and they won’t support new versions of Apache Flex. It’s as if Oracle would donate Java to open source, but the future version of JVM wouldn’t support future version of Java. I doubt Oracle would ever do something like this. Adobe won’t run the MAX conference in 2012 – are they ashamed of themselves?

I’ve attended two sessions on the agile methodologies, and have to admit that I’m still not sold. Sure enough, if a prospective client will ask if our company runs the project in agile mode, I’ll answer, “Sure thing!” And, most likely, what we do is agile. But we don’t do it as a religion with all paraphernalia that comes with agile methodologies. We work in a highly virtualized world. A bunch of VMs runs on our servers. But let alone VM’s – in some cases our developers are virtualized. They work from different countries and some of them never saw each other. Yeah, yeah, yeah…You put and shuffle the stickers on the board daily. Stand up meetings? I don’t care if our developers work in horizontal or vertical position, if they work in the morning, evening, or after midnights. As long as they get the work done, have good communication skills, speak English, and don’t behave as prima donnas, they are super agile. Please don’t show this blog to any of our customers or we can loose the project.

Finally, I’ve attended a great inspirational talk by Mike Lee, an American software developer living in Amsterdam (as he put it, the city that San Francisco wants to be). Now I’m also thinking of spending three-four weeks living and working from Amsterdam. I never been in this city, but plan to run JavaScript training there.

My QCon participation was not just about attending sessions. QCon organizers were kind enough to offer a meeting room to the members of the Java NYSIG – a huge users group lead by Frank Greco. I delivered the presentation “JavaScript for Java Developers” on Tuesday evening. This presentation was videotaped by the QCon’s crew and should appear at InfoQ soon.

You might have noticed that the most frequently used word in this post was JavaScript. Yes, as of today, this is my language of choice for developing the client portion of Web and mobile applications. If you want to hear more about it, attend our fifth annual symposium on software development in New York City. Rephrasing the well known statement about the water, “You can’t stop JavaScript – you can only redirect it”.

Good luck QCon! Hope to see you next year.

Reading another funny document by Adobe

Published on February 16, 2012February 16, 2012 by Yakov Fain7 Comments

Today Adobe released another document that brought tears into my eyes. Why they think that people are dumb? Why not just say, “We couldn’t figure out how to monetize Flex and we’re getting rid of the ballast”? Adobe is a public company, and, beside developers they have investors and their stock went more than 10% up since last (infamous) November. They’ve chosen investors over developers. This is understandable, but why keep lying to developers?

Today’s doc contains lots of words, but the most important section is this:
Adobe runtime support of Flex

Flash Player 11.2 and Adobe AIR 3.2, which are anticipated to ship in the first quarter of 2012, will be tested
with applications built using Adobe Flex 4.6. Adobe will test future releases of Flash Player and AIR against the
Adobe Flex 4.6 SDK and maintain backwards compatibility for five years.

While Adobe will ensure that the Adobe Flex SDK 4.6 and prior will be supported in future versions of Flash
Player and AIR, it will be the responsibility of the Apache Flex Project to test future versions of the Apache Flex
SDK against released Adobe runtimes to ensure compatibility and proper functioning.

In the past, features were added to Flash Player and AIR specifically to support the needs of Flex applications.
Going forward, features will be added to the runtimes to support Adobe’s vision for the Flash Platform. The
Apache Flex Project may choose to take advantage of those features; however, new features will not be added
to the runtimes specifically to support the Apache project’s efforts.

Let me re-write it in plain English:”We’ll release the new version of Flash Player, and we ‘ll test our past versions of Flex against it. We love (kinda) Apache Flex, but we don’t give a shit about what these guys will come up with. Flash Player is OUR runtime, and you’d better make sure that your smart-ass next generation Flex works with it, or else… In the past, every release of Flash Player would accommodate for the new features of Flex. From now on, ” We are not adding new features to Flash Player to support whatever you come up with”. Or as we say it in New York City, “Fuggeddaboudid.”

Keep reading Adobe’s doc. Their version states, “Flash Catalyst CS5.5 is the last release of Flash® Catalyst®“. BTW, why do they even add these ® signs to Catalyst? Anyone wants to reuse this lousy brand? OK, maybe. Let me translate it into simplified Chinese: “It was stupid in the first place to work on such a tool, and we wasted two years of our Flex team re-writing the FLex Halo components into Spark architecture just to accomodate the need of this still born baby – Flash Catalyst” .

Keep reading – it’ll get even funnier: “Development of Flash Builder continues. Adobe plans to maintain support for Flex projects in updates to Flash Builder 4.x, including additional work to ensure Apache Flex based SDKs can work within Flash Builder“. This is what it means in Bengali language, “During six years we tried hard, but couldn’t create a stable and performant version of Flash Builder for our own Flex SDK. For some weird reason, Flex developers would spend half of their time waiting for Flash Builder’s workspace to finish rebuilding itself. Design mode never really worked for Spark components. We are off the hook now, yay! Noone would even expect us to fix this for some Apache product. Just use IntelliJ Idea, will you? ”

The only product that was not mentioned in this doc was LiveCycle Data Services. What’s the fate of this highly overpriced monster? Is it dead in the water? I don’t really care about this one. During the last six years I ran into one client who bought its licenses. On multiple ocasions I was trying to convey to Adobe that they should lower LCDS price, but they didn’t give a damn.

Adobe has inspired these T-shirts. Still, it’s sad. I’m going to miss Adobe Max conferences. They knew how to put up great events, really.

Enterprise Development: Flex or HTML5?

Published on January 26, 2012January 31, 2012 by Yakov Fain11 Comments

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

or other tags so they would start shining, blinking, or do some other fun stuff. Such frameworks don’t promote component-based development. They may not include navigation components, grids, trees, which are pretty typical for any UI of the corporate tasks or back office as Anatole called them.

b) The frameworks that are similar to Flex in that they offer high-level components, which may be based on

tags, and even allow you to dig deep inside such components whenever you need to know the internals of Flash Player while coding in Flex. But overall, such components are meant to solve different problems – highlighting and CSS are less important here. Mainly these components process some events, offer support of the Model-View-Controller and so 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.

The Future of the Flex Framework in Enterprise IT

Published on December 15, 2011December 15, 2011 by Yakov Fain19 Comments

Disclaimer. Everything posted on this blog is my personal opinion and does not necessarily represent the views of my employer.

Part 1. Emotions.

Three days ago I’ve received the following email from an enterprise architect of one of our former clients (we’ve conducted two Flex training classes there):

“Adobe has been in the news lately with Flash not being developed for mobile devices and then the Flex SDK being donated to Apache. With all these things going on I was thinking if it still makes sense to develop using Adobe Flex for RIA applications. There are several opinions out there on the web but would like your take on the future of Flex and Flash. Is it still a safe bet to develop in Flash for RIA applications. Does HTML5+CSS+jQuery come close in terms of functionality that Flex offers? Please let me know.”

I’ve quoted this email because it described well what many of enterprise IT shops are talking about after Adobe simply decided to change their priorities. It started with that infamous blog of November 9th stating that Adobe didn’t care about Flash Player in mobile devices. But they didn’t stop there. Now they’re donating Flex framework as well as BlazeDS to Apache Software Foundation. Flash Catalyst was a mistake. It seems that Adobe decided that enterprise IT shops extinct. Apparently someone invited Adobe’s executives to a wild orgy, and the morning after one of Adobe leaders said, “How about changing our vision? I clearly see us in digital marketing and digital media! Enterprises are soooo boring, right hun?” Then Adobe went berserk.

Five years ago no one in the enterprise IT considered Adobe capable of anything but making nice tools for designers. They put tremendous effort into getting their foot in the door and be treated seriously by most (if not all) Fortune 100 companies. Back in 2006 enterprise developers didn’t want to hear about Flex framework. It changed. Very serious applications were developed and deployed into production using Adobe Flex and AIR as a front end tool. Will Adobe respect their existing support contracts with all these customers? For how long? Who’s going to provide such support if Adobe laying off hundreds of people second year in a row? As of today (Dec 14, 2011) Adobe didn’t care to make a clear statement about support of their enterprise customers.

Adobe’s executives keep silence. Santanu Narayen, the CEO was always the man of few words. But is Kevin Lynch, the CTO, in town? On Earth?
A couple of technical managers and evangelists are trying to fix the ugliness of the situation, but there is not much they can do. They can’t speak up for executives. Their words like “we’re absolutely committed to…” can’t be trusted anymore. These nice professional people are not being invited to decision-making orgies.

One of the very respected software engineers (a former Adobe employee) twitted, “Watching Adobe remove engines, wings, drop fuel, seats while in midair flight with customers aboard is truly fascinating.”

I see the situation similarly: today’s Adobe is a plane driven by pilots who lost control and are trying to press random buttons hoping to find the way home.

Part 2. Business.

Coming back to the original question, “Is it still a safe bet to develop in Flash for RIA applications?” This was the question of an enterprise architect of a mid-size IT shop, who’s not into politics and honestly tries to make the right technical decision.
The short answer is yes, you have nowhere else to go if you’re planning to deploy applications in production in 2012-2013. Flex is the best Web framework available today, and the fact that Adobe is donating it to Apache is better for everyone. The same applies to BlazeDS. As a matter of fact, Adobe stopped supporting BlazeDS two years ago, anyway.
I’m sure, under Apache Flex framework will go strong. My main concern is if Adobe will be willing to keep their future releases of Flash Player in sink with the future releases of Apache Flex?

What about HTML 5 (a.k.a. JavaScript)? At least for the next two years HTML5 should be used only by the early adopters. But we are in the enterprise development and have to deliver a number of cross-browser Web applications under limited budget and with a team of regular developers, not geeks. Six month ago I joined the project that was developed in Java/Swing by a team of 4 developers. There seniors left the firm. The person who left had 2 years of Java experience but was a quick learner. This week the new financial Flex/Java application developed by two of us goes to production. I’m trying to be fair to all technologies, but it wouldn’t be possible to pull something like this off with any JavaScript or Java front end framework.
If you are planning to go mobile, the most cost-effective platform is Adobe AIR. Can you afford to hire three teams with three sets of skills to develop for desktop, Android, and iOS? If you can’t, stick to AIR.

Part 3. Political stuff in the large enterprises.

Back in 2006, enterprise architecture groups of large enterprises were the main obstacles for making Adobe Flex an approved tool for development of the Web applications. Now, because of those drunk pilots, it’s their “Told’ya!” time.

They will try to squeeze Flex out of the list of approved tools arguing that Flash Player has too many patch releases, security holes, and, after all, the mankind moves to a no-plugin Web browsing. If I’d be running an application development team of Flex developers in a large enterprise, and an enterprise architect tried to to push me away from Flex toward an XYZ Javascript framework, I’d ask if the suggested XYZ framework would patch these security holes. Most likely, the answer would be “No, but at least we can set the Web browser’s security to the highest level for the JavaScript applications, which is not the case with Flash Player”. This can be a valid argument, and if Adobe cared, they could have created a special JavaScript wrapper for Flash Player to mimic security settings of the Web browser. It doesn’t take a rocket scientist to write such a wrapper, but since Adobe remains the owner of Flash Player, it has to be done by them.

Part 4. What to read next on the subject?

I like this post by Adam Flatter from Roundarch.

Part 5. Summary

1. Flex remains my first choice framework for developing RIA and AIR for developing desktop and mobile applications.
2. I’m also planning to go deep under the skin of one JavaScript framework, and it’s not jQuery. I like to have more than one tool in my toolbox.
3. Our company, Farata Systems will offer commercial technical support for Flex, AIR and BlazeDS both on the desktops and on tablets. We’ll make an official announcement about it shortly.
4. Our company continues offering training in Flex and Java as we always did, but next spring we’ll add a class “HTML5/JavaScript for Enterprise Developers”.
5. Under such management Adobe won’t last long and will have to be acquired by another company.

Happy New Year, everyone! It’s going to be fun.

The Rumors of Flash Player’s Death are Greatly Exaggerated

Published on November 9, 2011November 26, 2011 by Yakov Fain16 Comments

This morning ZD Net published an article stating the Adobe will cease development of Flash Player on Mobile in favor of packaging mobile applications in Adobe AIR.

The Flash Player haters quickly picked up this news and to draw attention to their blogs/tabloids started to cash on Steve Job’s name stating that he won the battle with Adobe since Steve was the one who didn’t let Flash Player on iOS.
As of now, I don’t know if these rumors are valid, but even if they are, this ain’t breaking news. Let me explain why in three simple sentences.

1. Adobe AIR includes Flash Player
2. Adobe AIR remains the main and the only means (at the time of this writing) for development of cross-platform mobile applications
3. Adobe AIR 3 Captive Runtime is a way of packaging the runtime inside the mobile application.

In other words, a mobile application developed in Adobe AIR and deployed in Android or iOS has inside the entire AIR runtime (this increases the size of the app only by 6-8MB) and won’t require neither iOS nor Android to ship the proper version of the runtime separately.

Once again, your mobile application has AIR inside, which, in turn, has Flash player under the hood. Machinarium is a good example of a console-quality game for iPad written in Adobe AIR.

The only question remains what will happen with Web pages that includes the videos requiring Flash Player. Most likely Web browsers will use HTML5-based video players. But let’s not confuse mobile applications and Web sites.

Anyway, no need to mourn. Have a wonderful day!

Update. The morning after

Next morning, Danny Winokur, Adobe’s VP and General Manager published a blog confirming the information from Adoleaks. This caused a storm of posts in the blogosphere, which predominantly blamed Adobe for betrayal. Peter Elst, an independent Flash developer even started gathering signatures to have Adobe CEO realize that he’s a bad guy and step down.

Our company, Farata Systems, has been working with Adobe’s product that were relying on Flash Player for more than five years, and we managed to build great relations with lots of corporate customers who used our services in building Flash-based rich Internet applications. After the announcement we started getting questions – was Flex the right choice? Can we reuse our investments in Flex in the mobile space? Should we abandon Flex and switched to HTML5 and JavaScript?

Adobe have caused serious damage to their image by having Mr. Winokur writing this infamous blog. I’m sure the top management of the company has approved it so Danny Winokur bears only a partial responsibility for this. My question is why Adobe decided to use one person’s blog for spreading this rather important news instead of publishing press release prepared with collaboration with their PR agency? Were their top executives ashamed to state it in a manly fashion?

Can you imagine the president of the USA making a war announcement by posting a blog? Adobe just did it. Professionally prepared press release could have include the proper wording along with the quotes of industry analysts who would offer their interpretation of the news. Have anyone seen an official PR on this subject? I didn’t.

I guess, after Adobe’s executives realized the size of the damage caused by that unfortunate blog (I hope Mr. Winokur is still employed with the firm), they asked other managers and technical evangelists to save the situation. Have a read:

1. Your Questions About Flex by Andrew Shorten & Deepa Subramaniam. Nice try, but these guys failed to deliver the main message: Adobe AIR 3 is a solid replacement of Flash Player for the mobile.

2. Adobe’s technical evangelist Lee Brimelow has mentioned AIR, but has deliver another wrong message, “No longer having to support the mobile browser version of Flash frees up valuable resources that we can redirect to these more important areas.” This is yet another mistake. Does Abobe put their customers first, or the most important goal is to do a reorg after laying off 750 people?

3. Mike Chambers, the lead product manager, speaks about AIR, but this message can be understood only by techies, and not corporate clients who were sitting on the fence trying to decide if they should develop with Flash or go with HTML 5. And we are talking about the corporate world that brings a huge portion of Adobe’s revenues.

4. Ben Forta, the Director of Technical Evangelism stated “For in-browser experiences on devices, browsers can finally do what they really should do, and we have HTML5 to thank for that.” Really? Who’s ready to start the development of their next cross-platform enterprise project using HTML5 and JavaScript? Does Adobe or any other company have any production-grade solution in this area? Would love to hear about such tools.

Why people didn’t realize that Steve Jobs was heavily promoting writing pixel-perfect applications for iOS-powered devices, not Web pages? Adobe AIR 3 fits this bill. And as I wrote earlier, replacing engines in the browser-embedded Flash videos with HTML-5 one is not a major undertaking. So what the mobile world as the result of this misinterpreted Adobe’s announcement? Nothing. MXML, ActionScript, Flex framework, and AIR 3 remain the tools of choice for cross-platform mobile applications.

When HTML5 can be considered as a main choice for development of applications for both mobile and desktop platforms? It may happen several years from now. It’s great that Adobe is working into this direction, but they should have done it in parallel, not by stopping development of Flash Player without offering HTML5 alternative.

Anyway, the damage is done. Adobe spent years to become a recognized tool maker for the enterprise developers. Five years ago they were known as a company that created Photoshop. They managed to change this image. I really hope that they will find a way to remain on this market.

Here’s my message to Flex, Flash, and AIR developers:

“All IT shops that have invested in learning Flex or ActionScript for developing their desktop-based Rich Internet Applications will use these skills in development of the mobile applications in Adobe AIR. There is no need to jump the ship”

Update 2. After publishing this update I’ve learned that Oliver Goldman, a tech lead from the AIR team has been moved to the team that develops creative cloud. It’s time for Adobe to give away AIR to open source too.

Update 3. Two weeks after the infamous blog of Danny Winokur was published, Adobe made a statement explaining its upcoming strategic transformations.

mailto: an elegant solution with limitations

Published on October 21, 2011October 25, 2011 by Yakov FainLeave a comment

On my current project (Flex and Java) the client wants to email certain data to certain recipients. If the mail content and recipients wouldn’t require manual processing, I’d written a Java server side program that would retrieve the data and sent it to a predefined list of recipients. This is not the case though. The client wants to see the data in an email client (MS Outlook) and be able to add some text to the email body, edit the To, CC, and the subject fields.

That’s why I decided to go with a client side solution. There is this handy protocol mailto, and if you’ll prepare the URL that starts like “mailto:…”, contains the To, CC, Subject, and Body – your program will obediently open the mail client with all the field pre-populated. In Flex, you need to use the function navigateToURL(), but this solution works for any programming language or HTML links. So far so good. I’ve easily implemented this elegant solution giving the client the best of both worlds – automatic mail generation with the ability to massage the text.

But my happiness didn’t last long, cause there was yet another innocent requirement – the data should be formatted. Nothing fancy – like columns in the grid. For example, the email body could have contain the following part:

John Smith                5,678
Mary Lou                        12
B Ramalinga Raju          101

Not a rocket science, right? I also though so and quickly wrote two functions to pad a string with spaces from the left and from the right to a certain length. Then I formed each line concatenating the right-padded 20-char long name with the left-padded 10-char long number. Quick test with printing the result in the console of my IDE – it works! What a great programmer I am, aren’t I?

After passing the same data to the mailto, it opened MS Outlook, and the mail body looked similar to this:
John Smith            5,678
Mary Lou                      12
B Ramalinga Raju         101

My perfect alignment went down the drain. And the worst part is that there is no solution to this problem. The mail client was using a font that allocated different width to each characters and my padding was resulting in different width depending on what characters presented in the name of the person. If I could pass HTML to the mailto URL, this would solve my issue. I could have used HTML Table with cell alignment. But mailto allows to pass only simple text (URL encoding didn’t help either).

I hit the wall. What’s next? Will tell the client, “I give you an elegant and flexible solution, but I can’t align the text. Either manually change the font of the data to one of the monospace font, or set Courier to be a default font in MS Outlook “. I’ve implemented lots of non-trivial solutions for this client, but hey, technology has its limits too.

What if the client answers, “No, I need perfectly aligned report and I hate Courier font?” I’ll answer, “No problem, everything can be fixed. I can certainly come up with a custom solution. It’ll take me N days to implement” After multiplying my daily rate by N the client may reconsider and agree to live with my monospace font solution. This is is good example of a situation, when there is a huge price difference between 100% and 99% automated solution.

P.S. If you run into a similar problem in the Flex TextArea component, the solution is the same – set the fontFamily attribute to use one of the monospace solutions, for example:

<s:TextArea fontFamily=”_typewriter”/>