Shared publicly  - 
After 6 years doing Flex, am I moving to HTML5?

Short answer: no. But I'm investing in HTML5.
(really) Long answer: see below.

After returning from the Flex Summit, many people have contacted me asking what was going to happen with Flex and if I was going to "migrate" our projects (like ) and services to HTML5. After plenty of exchanged emails and dozens of long talks, I decided to write down and share some notes of my first steps in the HTML5 world regarding the development of Enterprise RIAs (or not). These notes are not organized, they have typos and - as I said above - they are only my first steps so more experienced people might (and will) prove me wrong in some topics.


I founded Webfuel in 2004 and since then we've specialized in building long-term (> 6 months) enterprise-grade RIAs that had to scale well and be prepared for constantly changing requirements with a low cost in maintainability, while simultaneously providing a top-notch user experience. We've managed to offer our services comfortably with a very limited number of resources and small development teams (3-5 persons per project), much thanks to the way we leveraged existing knowledge on Software Engineering and applied it to our platform of choice - Adobe Flex (now fortunately called Apache Flex).
Our decision was purely technical and we have never regretted our choice, until it got badly affected by the bad PR around the Flash platform.

Worse PR ever in November 2011

The Flash platform was already in bad shape, much thanks to one year of chaotic PR and there were already some inconsistent signs from Adobe hinting what was going to happen. While disappointed, I was not very surprised when all hell broke loose in November 2011 with Adobe destroying the very last credibility that Flash still had, directly affecting Flex, our businesses and careers. Long story short, Adobe wasn't able to monetize the Flash Platform and the top managers who don't really care or understand its power simply decided to put the money where their mouth was: HTML5. I happen to strongly agree with the move on investing in HTML5, but they could and should have done it without destroying (the perception of) Flash. Especially because in the meantime it had turned into the platform of choice for Enterprise Development.

In December '11 Adobe has donated Flex to Apache. While this might end up in being the best thing that could happen to Flex, the initial reaction from the Enterprise was that Adobe was getting rid of Flex. Like someone said during the Flex Summit - "it seems to me that Adobe has built the best platform for creating enterprise-grade applications by accident". Adobe understands design; creativity; marketing; publishing; Adobe doesn't seem to understand Enterprise. Example #1: all corporate companies I worked with in the last 6 years complained about the lack of decent support from Adobe and they were willing to pay big money. Example #2: the pricing of LCDS.

Did Adobe kill Flex? No! A technology doesn't have a heart attack and drops dead on the floor. Flex is still alive and the reasons why we chose it are still perfectly valid. Flex didn't get worse suddenly - it's still the same robust platform for enterprise RIA development.
What was destroyed was the perception of the Flash Platform. And the perception is what matters on business. You can have the best product of the world, but if people believe it's bad they won't buy it (and they'll even be happy on telling everyone how much your product - that they never used - sucks). But if they think it's good - even if it actually sucks - they'll probably buy it (and complain later). Perception. That's what sells. Perception.

Will the perception around Apache Flex ( ) improve? Most likely, yes. In 9 days, there were more than 1.4 thousand emails exchanged on the Flex Mailing List ( ) ! It's pretty impressive the number of people that are now involved in pushing Flex forward and this number will most likely keep rising. But Apache Flex still relies (or, at least for now) on the Flash Platform and I'm not seeing the bad perception on the Flash Player changing in a near future. Of course there's still AIR, but what concerns me are browser applications.

We are desktop-developers-working-on-the-web

An important side note, is that I see Webfuel as a team of desktop developers working on the web. In other words, we use desktop development paradigms, best-practices and design patterns borrowed from the JAVA world and we've applied them to build applications that happen to run inside the browser. Our work consists normally in building at least two loosely coupled applications, connected by an RPC API: a client application (running inside the web-browser) and a server application that only exposes services and is not aware of the client application.

Most Flex developers out there think on themselves as web-developers, but in most cases the mindset of a Flex developer is closer to a desktop developer than to a web developer. IMHO, this is the single-most-important reason on why we, Flex developers, dislike so much the "normal" web development approaches.
We work with "views", web developers work with "documents". We do old-school MVC, DI, loosely coupled approaches, dependency management, RPC, code coverage, continuous integration [...], and when we're forced to do web-development these are the first concepts that we try to investigate and replicate... before we get frustrated and enter in "denial".
To be good at typical web-development, we have to change our mindset.

Is "HTML5" ready?

According to Twitter, online magazines, blogs, Apple, Microsoft and even Adobe, HTML5 is the silver-bullet for everything. It can be used to build websites, webapps, games, software, mobile applications, doing laundry and cooking. The focus is all on HTML5 right now. Is it the right moment to use it?

From the point of view of a web-developer - of course it is!!! For a typical web-developer, HTML5 means more tools, more power and much better cross-browser compatibility than what they had before. If you're working on the web, HTML5 and the storm of JS frameworks is simply the best thing that has happened to the web since.... humm... Flash. :o) Bottom line, HTML5 is for sure a giant step forward.

From the point of view of a desktop-developer-working-on-the-web - hell no! WTF? We work on the enterprise and enterprise means stability. We can't afford to have too many moving pieces all the time. We can't afford to deal with un-structured languages. If you've used Flash or Flex for the last 5 years, you'll feel that in HTML5 there's nothing new or better than what you already have. Worse, you'll feel that there still are hundreds of needed capabilities and tools missing. Exception to the rule, happens if you're targeting the browser of Mobile devices, where HTML5 is king.
It's quite understandable that a Flex developer feels frustrated. You feel you're going backwards 4 or 5 years. It happens that, as Ted Patrick stated ( ) , we were living in the future...

Ignore the PR shit storm. Ignore fanboys. Choose the right tools. Ask the right questions to the right developers

People like to take sides. If I like and use something, for sure it's because it's the best thing ever and all the rest sucks or is dead. That's how it works for most fanboys.
Newsflash: if 10.000 persons say that something sucks, it doesn't really mean that it really sucks. It means that they believe it sucks. It's like believing in a religion - each follower defends his religion, but which one is the "right" religion (or, is there a "right" religion)? The irony is that developers should be pragmatic people but we often see them becoming fanatic about their technology choices. "Infidel, infidel", they yell with their pitchforks in the air when you say the name of a "competitor" technology. WTF?

For me, technologies are just tools. Obviously I would like to have as many good tools as possible so I can be able to choose the right one for each task. Be it Flex, HTML5, Javascript, Actionscript, JAVA, PHP, whatever.

Bottom line: ignore the PR shit storm. Ignore fanboys. Choose your tools based on logic. You wouldn't choose a hammer to cut wood, would you?

Last year, when I started digging seriously into Javascript, I had many questions. I took for granted that someone who defends a technology with so much conviction, probably understands it pretty well. So I placed several questions to these guys expecting to learn new stuff and understand their best practices. It happens that I haven't learnt shit. It was like if me and they were from different planets, speaking different languages. Even similar words have different meanings (their MVC is not our MVC. their dependency management is not our dependency management... etc).

I've sent a couple of emails to mailing lists of HTML5 and JS development asking people what they were using for MVC, IoC, Unit Testing, Code Coverage, Compiling, Continuous Integration, etc, etc. The answers were like "WTF dude, IoC? What are you talking about?". I now know that I was doing the wrong questions, as you'll see below.

Since I couldn't get (or understand) answers from the gurus of the JS world, I started trying to find people who were doing both large-scale Actionscript and Javascript. They would understand me. :o) It happens that there aren't many and most of them were more or less at the same point I was. The best single advice I got was: "accept web dev for what it is and don't try to change it. Don't do RIAs. Do simple web development. Then improve.". Good advice!.

Redefining our focus

As I said above, technology-wise, Flex is still perfectly valid. But it's perception is at its lowest level and clients are quite confused and started asking us to use HTML5 to build the same type of solutions we were building with Flex.

So we had to rethink our business, and considering our desktop-developers-working-on-the-web mindset, we've decided to:

1- return to our roots: desktop development. That's what we're good at and we can still keep using Flex to build AIR applications, either for the desktop or mobile. Since we can embed the AIR runtime, those applications will be future-proof to any other crazy-game-changing decisions made by Adobe.
2- increase our investment in developing (simple) HTML(5) webapps, while accepting the web for what it is: broken. In other words, we have to be humble about what we can provide on the web. It's too hard and expensive to build the same type of applications we were building, so we're starting with just simple webapps.

We won't be accepting huge enterprise-grade projects if they're meant to be built in HTML(5). This is actually the hardest problem to manage. There are expectations from clients. They've gotten used to our beautiful RIA applications, with almost no waiting times, with beautiful and pixel-perfect interactive user interfaces. And now they want the same, but in HTML5, because Flash is "dead" and HTML5 will also run on their Mobile devices (all of them), faster and without consuming battery. At least, it's what they heard.... The solution for this problem is to say "No, we are not ready to develop it in HTML5". We'll be restricting our development to simpler web-apps, until we feel that we (and the web) are ready.

First steps in JS and HTML5

During 2011, I've read A LOT about JS frameworks, libraries, approaches, etc. Sometimes after finishing reading something, it was already outdated and a better library was available.

My first impression was that most docs were "meh": in most cases you have an excellent "Getting Started" guide, but as soon you start getting your hands dirty in more complicated scenarios, things start falling apart and you'll see none or outdated advanced documentation.

Another trend that I hated in my readings was the lack of objectivity: instead of the typical website and docs saying "this framework does A,B,C,D" , I saw a lot of "THIS IS THA MOTHA-FUCKA FRAMEWORK THAT WILL SAVE UR LIFE!", "MEGA-HYPA-SHIZZLA-FRAMEWORK". This type of communication felt weird and suspicious to me until I got used to it.

I've also seen several frameworks being dropped in favor of others, which was actually what scared me the most. I felt insecure choosing the "right" libs and frameworks, so most choices I did at start were the safe ones, as you'll see below.

Another irony was that most of the JS frameworks exist to overcome the limitations of the web development (normally, the crossbrowser issues). Coming from an environment where a framework tries to abstract application concepts, it felt weird to me to use frameworks to abstract technical limitations. Today, I've learnt to enjoy and welcome these frameworks. Accept them for what they are, because the technical limitations actually exist and without those frameworks you're screwed.

In October 2011, I decided to start a medium sized real-life HTML5 webapp with a partner company, so we could test the knowledge I gathered. (A medium-sized project in the point of view of a web-developer; as a desktop-developer I see it as simple stuff #notBeingHumble ). I've allocated two developers to the project - with myself being one of them. Below are the choices we made.


Despite having read about Backbone, Spine and other more complex frameworks, I've decided to start small and simple with Knockout.JS . I just wanted simple data-binding to start with, so I could get some separation between the data model and the view. Later, when we were more experienced, I would re-evaluate the choice of the framework and choose between Backbone, Spine, or another.

My choice has proven to be worthy since Knockout is actually quite simple - but far more complicated and intrusive than the ultra-easy and powerful binding we're used to in Flex.

The documentation of Knockout is quite good, with plenty of tutorials available. On Google you won't find as many resources on Knockout as you would like, but fortunately the website covers most of the important topics. The mailing list is pretty good, despite not being as active as the MLs I'm used to in the Flex world with dozens or hundreds of experts. Anyway, in the Knockout ML, there were always one or two people kind enough to point you in the right direction, which is great.


I had already a good impression on jQuery, but even still it turned up to be even better than what I expected. jQuery not only hides a lot of the crossbrowser issues - not all -, but also boosts up a lot your productivity with dozens of shortcut functions to most of the stuff people normally need to do on the web. Use it (can you live without it?).


Managing CSS can easily turn into a pain especially if you need to do many changes to an existing stylesheet with hundreds of CSS declarations. When Googling for best practices, I met SASS. SASS is actually pretty simple: it lets you define CSS stylesheets with declaration hierarchy, variables and mathematic expressions, saving them on a scss file. Then you start a command line task that listens for changes in your scss file and converts it to a CSS file on the fly.

I haven't looked at Less, so I don't really know which one is better.


I also discovered (the hard way) the pain that it can be to manage dependencies in Javascript. I was used to having all class definitions packaged for me in a single SWF and the Flash VM would take care of embedding and managing dependencies for me (pretty most like all bytecode VMs do). In the Javascript world, there's nothing taking care of this for you. You start by setting in the HTML file the location of the scripts needed, but then you cannot control the order they are loaded and run. So you can be calling a function myFunction() in fileB.js that was defined in fileA.js that was not loaded yet - resulting in errors.

I've chosen Lab.JS to solve the issue of loading dependencies on the right order. I'm also making sure that any initialization code only runs AFTER all the needed files are loaded.

I've found a problem with Lab.JS: if your code throws exceptions, they will be swallowed by the library and nothing happens. My workaround (read: ugly hack) was to do a " setTimeout(initialize, 1); " after the scripts are loaded. This way exceptions are now caught by the browser, as you would expect.


This was one of the biggest disappointments in the beginning. The biggest problem of JS is that due to its dynamic nature it's hard to be tooled around. For building large scale complex systems, especially in a team environment, I needed good refactoring capabilities. It happens that refactoring doesn't exist in the IDEs I tried.
Ok, there is something called "rename" in WebStorm but it works for very simple cases and I've seen it resulting in unexpected results (so I always use the "preview").

Flash Builder is a complete beast (in a good sense). I've seen many people ranting on Flash Builder and even I had some disappointments a couple of years ago. But after FB 4 it just got awesome, with its serious refactoring capabilities, find usages, metadata completion, autocomplete, inline docs, content assist, etc. Most of the best tricks from the JAVA world are available on FB. If you expect to find those in JS editors, I have bad news for you.

I've started with Aptana. It's free. It's based on Eclipse, so I felt at home at least with the shortcuts and the structure of the IDE, but with a black editor (wtf? is this the "fashion-color" for supa-dupa-web-developers?). Anyway, after two months I got tired of it. I couldn't do refactoring. I couldn't jump properly to a function definition with CTRL+click (and this was REALLY annoying). It didn't have decent auto-complete. I've tried making the debugging work but it only worked properly 15% of the time.

Then I've decided to give PHPStorm a try - which is the same as WebStorm, but also supports PHP. At first, I was lost: I couldn't find half of the stuff I needed. After one day, I was pretty comfortable with it and now I feel it's actually pretty well built. Ok, it's NOT Eclipse, but even still it's quite powerful. What those guys did was to implement really well the things you use most while developing and packaged all of them in a clean and objective interface. Kudos to JetBrains ( )!
In PHPStorm, refactoring "sorta" works in simple scenarios. If you complicate too much (like when you try to mimic packaging for your objects), it won't work. Click and jump to a function definition works. Debugging... works!! Autocomplete works a lot better than I expected. Actually, it works quite well. The catch: comparing to Aptana, it's not free.
Coming from Flash Builder, will you be happy with PHPStorm? No. But currently it seems to me that it is probably the best IDE for Web development.


I feel ashamed to say that I couldn't debug properly during the first two to three weeks. Every tool I tried didn't work as expected. It happens I was using the wrong tools, browsers and approaches.
I ended up using the debugging capabilities of both Firebug (in Firefox!) and PHPStorm. Firebug is also pretty helpful to inspect the DOM of the document, something you'll be doing every 5 minutes. Both Firebug and PHPStorm allow you to place a breakpoint in JS code and then run your code step by step, as expected. PHPStorm looks more comfortable to me, also because it's where I'm writing my code.
Bottom line: If your debugging is not working, don't blame JS: you're simply using the wrong tools.


This was probably my biggest pain point. I'll start with the conclusions: accept Javascript for what it is and don't try to mimic your common OOP techniques and classes.
Of course, you can try to mimic them - I've read half of a book teaching how to do that. But I've come to the conclusion that the complexity that you're adding to get you closer to your comfort zone ends up not being comfortable at all...
You have objects in Javascript. Some might argue that they're not "real objects", but wtf, they are what they are and bitching around all the time won't turn them into real objects. They are objects. It's the definition of "real" that is subjective :o)

The problems with JS:

- Silent errors. They happen. Get ready for them.
- Hard coupling everywhere. It's pretty hard to do loosely coupled architectures. It's quite easy to end up with a web of dependencies between different objects. I've read there are techniques to avoid hard-coupling, but I haven't had time to dig up more, so this might be my fault.
- Ugliness. I'm used to a HUGE-ULTRA-CLEAN separation between classes, libraries, modules, components and applications. In the webdev world, get ready to see PHP spitting HTML that has JS code spitting more HTML... Or function a() that creates another function in object b, that knows about object c and changes how c behaves. Things like that. In many known js libraries.
- It's not built for team work. At Webfuel we normally don't need to talk much with each other about development. Half a dozen guys can be working together for half a year on the same project, committing code every 5 minutes to the same SVN, without breaking the code of others. This was quite easy to achieve much thanks to the structured nature of Actionscript, on top of some very simple practices borrowed from the JAVA world. Enter Javascript and you'll see your code breaking the code of someone else. While developing JS in a team, it's normal that developers need to talk a lot about what each one is doing, warning the other to be careful about X or Y, or asking the other "where did you put the code for...". Actionscript makes teamwork a joy almost since moment zero - there's no rocket science for a healthy teamwork environment, especially if you're using a micro-framework. In Javascript, the trick is to put people working in very different unrelated parts of the projects and use techniques to encapsulate their code - I have yet to learn them, but I will soon. I've asked some JS developers about this but the ones I know are all lone-wolves so they didn't understand what I was talking about (apart from the reaction "SVN?? WTF?? Use GIT!".. hum... that wasn't my question...)
- Unpredictable. In AS3, the "this" refers to the instance where the method is defined. In JS, "this" can mean pretty much anything (remember AS2?). This was one of my biggest pain-points at first. Another problem is guessing by looking at the code the properties and functions of an Object. You can't. A function in an object can be defined pretty most anywhere. It's up to you (and your team; and your partners; and your library-providers) to make sure that you keep your house clean with everything organized in the right place.
- Code practices. These are completely different from everything you know. I taught everyone here at Webfuel to not be afraid of writing many lines of code. I want them to write self-explanatory code, like if they were writing English. Enter Javascript. And cry. By some weird reason, people like to write as much code as possible in a single line, making it not only very hard to read, but also very hard to maintain. I've got used to seeing the $('#huge').line({of: code, that: function() { looks() }).like('a').train(); . And this practice is everywhere, pretty most in all examples, libraries and worse: in books! One of the books I read had one line that took me around 5 minutes to understand! The fun part is that I had the book with me in San Francisco on the Flex Summit and I showed that line of code to several people just to scare the shit out of them. It worked!

Bottom line: if you're an OOP purist, with many years of experience on software engineering on Flex and/or JAVA, you're going to be scared. The mindset is different. The problems are different. The solutions are different. Even the slang is different. The good part: no compiling times. Which is actually a very good part...

There's so many people betting in JS, shouldn't it be good?

This is actually the question that confuses me the most. I simply don't have an answer... Some people seem to be able to pretty much do anything they need but that doesn't mean their needs are the same as mine. At the same time the language certainly has its fundamental problems that can frighten anyone who has a one-year-project ahead.
One thing is certain: it's being pushed forward and you can't deny that.


I haven't tried yet CoffeeScript. After reading a bit about CoffeeScript, I've learnt that you still need to be comfortable with Javascript to use CoffeeScript properly. And that's what I'm doing. On the next project I might give CS (or other language that cross-compiles to JS) a try.

Layouting and the DOM

This was actually my biggest disappointment. Flex (>4) is amazingly simple and powerful concerning pixel perfect skinning and layouting. You have pretty much no constraints in Flex regarding layouting, giving you immense freedom in creating perfectionist user-experiences. You don't think "how am I going to implement this?" because there's not much to know about Spark skinning: it's really powerful and simple.
The HTML world is different. You have to be aware of the constraints before creating the design and setting the user experience. I wasn't aware of these constraints so we had to change the designs of the product we're building a couple of times on the middle of the project to turn them into something possible/easier to achieve in HTML. I really hate constraints that end up affecting the user experience, but that's how it is.

You have also to be prepared to accept small (and big) cross-browser rendering differences. They will happen. A lot. But that's another topic...

Optimizations/Preloading content

Coming from the Flash world I was used to have to build one single application (the SWF) that has all (static) assets embedded. This results in pretty small files (yes, a SWF is smaller than it's HTML+JS+CSS+Assets equivalent, even after minimization and gzip, and etc), only one request to the server (which ends up in a very low load on the server) and the assumption that all the content you need is available at runtime since moment 0. If you want to achieve a similar result in JS, you have to do it by hand - there's nothing taking care of that for you. You have to join and minify Javascript and CSS files and resort to image sprites to reduce the number of requests to the server and the user perceived speed.

An image sprite is simply one PNG file with all the images and icons you use in your webapp. Then you simply apply that image as the background image of your UI component, using CSS to set a translation so it shows the icon/image you need. It's quite simple, but make sure you load this image before your content appears on screen. The same applies to other content, in case you don't want the user to see "glitches" on the layout while things load.

During loading I am hiding most divs (display: none) in the DOM, showing a preloader and after all content is ready (JS files through Lab.JS, Image Sprite, etc), I'm using jQuery to show stuff. It's quite simple, actually, but of course, Flex did take care of all that for you... BTW, I saw this today, but I haven't tried it yet:

I've started today looking for a Javascript minifier. I need something that can automatically watch a folder with several JS files and merge them in a single minified file. If possible, assigning a revision number to the generated file. I haven't yet found anything, but I'll update this post if I have positive results.

HTML(5), JS and Mobile

If you think you're going to build something in HTML(5)+JS that will work seamlessly and without problems in desktop AND mobile browsers, think again. Document based websites usually work without problems on both types of environments. But if you're doing a more or less advanced user experience that relies in some CSS and JS magic, then be prepared to be disappointed when you open your content in your Mobile device. Not that the mobile browsers are bad - they're actually pretty good. The problem is that the Mobile experience needs to be thought from the start - people will be using their huge clumsy fingers to interact, the screen will be smaller and the hardware resources are more limited. So at the end, you have to implement at least two different user experiences and switch between them according to the device capabilities using Media Queries. I haven't yet tried Media Queries, so there's not much I can say about this. I just mentioned this topic because I've seen several people getting frustrated after migrating their Flash applications to HTML expecting them to work right away on iOS. When in most cases it's probably cheaper to keep the Flash version on the desktop and build a dedicated version for iOS.

UI Components

DateChooser, NumericStepper, TextInput, DropDownList, RadioButton, Panels, Accordions, HGroup, Charts, Lists with Renderers, DataGrid, etc, etc, etc, almost all types of components you can imagine are available in Flex. And they are extendable and completely skinnable. You have great control in your hands. In the HTML world, either you go with the limited browser components - that are not extendable and are hard to skin but they integrate with the browser and the device -, or you have to choose a component library like jQuery UI, ExtJS or zkoss, among other - that are more or less powerful, but don't integrate with the browser or device.

After exploring dozens of options, all of them with their cons and cons, I felt unsecure on choosing one option, spending time and money learning it and teaching it to my team, to later conclude that I might have chosen the wrong one. So I've decided NOT to try any component library - apart from the limited jQuery UI -, simply because there are too many things changing right now and it's very hard to predict which libraries will succeed and which ones will not. I'm going to be lazy (also because I can't study thousands of stuff at the same time) and wait to see what other Flex developers will choose. In the meantime, as I said above I won't be using HTML(5) to build RIAs, but only simple webapps. And for that, jQuery UI is up to the task (with some quirks here and there).

Crossbrowser issues

Heck, this is my biggest nightmare. I tremble everytime someone says the word "web browser". Ok, I'm exaggerating a bit. Crossbrowser issues exist, they are a PITA and they will consume at least 30% of your time in a project (consider that when budgeting). But to be honest, at first I was expecting it would be a lot worse. Don't take me wrong here, crossbrowser issues are a nightmare. Simply, they're not as scary as I thought. If you follow me on twitter (!/joaosaleiro ) you've probably seen me cursing some web-browsers (hint: has two letters, starts with an I, ends with an E). Get ready to having to test something in several browsers and to change plans in the middle of the project because your approach doesn't work as expected in one or two major browsers - especially if you're building edge-cases and using HTML5 stuff.

You can't miss this article:

We had one crossbrowser issue this week that almost killed our current project. We needed to override the browser URL while the user was navigating the application and we couldn't rely in simple URL hashes. We were hoping that history.pushState was up the task, but it happens that it is not. Erratic behavior in Safari, doesn't work in IE, worked in Android until 2.3.3 and stopped working in 3.0 and 4.0 (WTF?)... Fortunately, we've found History.js which was built exactly to fix our problem and reduce (not fix) the cross-browser issues. See, the good thing is that crossbrowser issues happen to everyone, so there's a high chance you'll find a workaround on the web.

If you're doing HTML5 you probably know about . If you don't, go there.


Our productivity is pretty bad right now (but we are getting better!). We've spent 11 weeks of two resources to build something in HTML(5)+JS that we would have built in 3 weeks with the same resources in Flex, without any stress at all. Of course, I take a big part of the guilt here: we're still learning and during the first weeks there were a lot of readings, plan changes, tests and bumps on the road.
The real issue is how tight the relation between productivity and your experience with the tech is: the bumps on the road are there, they happen to everyone and you won't be able to predict them. So the only solution to be productive is to be experienced and be aware of those issues. They will simply happen, you'll curse them, search the internet for hours, fix/hack them and the next time you'll meet them, THEN, you'll be prepared and productive.
You'll end up implementing workarounds and hacks (on top of other hacks) constantly. Coming from the Flex world, you'll feel ashamed of your hack - don't be. It's normal. Most of the times, you won't have another choice but to accept the hack and move on.
Coming from a rapid development environment as Flex, productivity in JS and HTML can be quite frustrating until you get used to the bumps on the road. After you're experienced, it will get better, but I don't expect it to come any close to the productivity of Flex development in a near future.


The first conclusion is that we'll keep using Flex in long-term enterprise RIAs projects, especially targeting installable desktop and mobile applications. Neither the open-standards nor us are ready to build the same type of experiences that our clients expect us to.

At the same time, we'll be accepting smaller webapps. At this point, after three months, we're already pretty comfortable building web experiences, so it's a matter of raising the bar slowly, webapp after webapp. But I don't think we'll be able to do the same type of RIAs we were doing with Flex at least not in the next two years. Also, maintainability and its cost scare the shit out of me. And all the moving parts of HTML5 - new libraries appearing, others disappearing, browsers adding or dropping support of features, etc. There are lots of "ands", "ifs" and "nots".

I know I've missed half a dozen important topics and I know I'll have dozens of other to write about in a couple of months. Actually, there are no real conclusions here - only open subjects. There's much to be investigated and learned. I'm sure I'm not completely right in some of the above topics and I would love to get your feedback, pointing me in the right directions where I got it wrong. I can only hope that most of the stuff I pointed above won't look as bad in a couple of months as it looks now. Or that browser vendors shake hands and decide to stop fragmenting the web. Maybe they could all be friends and adopt the same rendering engine and VM ( giggles ). For example, Google Dart. ( yeah, right ...)

[Link to this post:]
Jirka Daněk's profile photoJoão Saleiro's profile photoToralf Richter's profile photoTyee Cambrón's profile photo
Same rendering engine and VM -> Tamarin ! :D Thanks again for this post.
Thanks João - this is huge (and I do not refer to the amount of words here)
Thanks for this objective post! Seems you red my mind.
As a 'married with children' lone-wolf AS3 developer I do not have the time/privilege to catch up on thee nowadays web-revolution.
Too many choices, too many pros & cons and, we all know, it isn't & it won't be over for the forthcoming years! I can live with the evolution of a language but not with hundreds of new ones from one day to another. In addition, this excellent article brings that kind of precious information that stops me to wonder and to think about my own future in 10 years time... kinda of scary!
Still, thank you for sharing.
Correct me if I'm wrong but you said, a few months ago, in a tweet something about 'Gardening' (?)...
I couldn't agree more! God Speed to Apache Flex !!!
You did a nice overall review, despite the fact that has a lot great js IDE out there. For example I did tough that webstorm was the best, but found out that VJET is a quite better one and I know Microsoft is working on a full IDE for not only JS but HTML5 and CSS3.

And I agree with you, I will be lazy to choose others, but backbone and jquery (ui mobile core) are my best choices because it's large used.

Thanks for the thoughts
Wow great post, thanks for sharing your journey so far, keep it up.
overall a decent overview. In regards to the UI components, I think your team is smart for waiting. There's simply no good UI framework if you're used to working in Flex. Hopefully we will see a good, open source UI component framework in the future, but I am not hopeful. Developing something like the Flex framework in JavaScript is a gigantic undertaking, especially if the goal is to have a clean and easy to use API like Flex does.
That's probably one of the reasons why Google is pushing Dart. JS is no good for large scale [enterprise] projects.
Very well articulated. But unfortunately these days it is much easier to be a fanboy. Nobody wanna listen to rational argumentation like this. Safari Mobile with its ~2% market share is considered as a main target platform no matter what application you build. Even smart people do not realize that if they really need to address the client platform fragmentation, they should build different client for different platforms. One for mobile phone, one for tablet, one for desktop. And if the application or at least most of its features is used primarily on desktop, Flex is more than a valid choice. It is just the best choice, because:

* You can develop faster.
* You can ensure better performance and quality.
* You can avoid browser inconsistency.

And at the same time you can develop web application or native application for tablets consuming the same APIs, but they will not be silver bullets to use them on desktop as well, particularly when it comes to more "authoring" rather than "consuming" applications.
Great Post Joao! Agree with everything. I wish there was some way to favourite this post so I can come back to it.
In strongly suggest you try haXe. It's based off actionscript, has classes, real objects, everything AS has and more. And it "compiles" to JS, among others (php, AS3, c++...). There's a good tweening library, actuate.
Thanks to Miguel Vaz for sending me an excellent email with dozens of corrections to the typos I had in the post. ;)
I started 8 months ago working with Titanium for mobile. However, I didn't feel comfortable with Javascript as well as with the framework (many issues, lack of docs but now it become better, and some other things). So, I decided to look for some other cross platform solution. Then I got interested in Flex/AIR for mobile. However, I am afraid to start with something which is fading already, or owner is slowly giving up with it. I have spent already 4 weeks learning and trying with AS3 and flex.

Now, I want to start creating some apps. My questions are:
1) Should I go back to Titanium or I can continue coding safely with Flex/AIR?
2) I want to dive in the 3D world, especially for mobile devices. I don't think HTML5 or Javascript is powerful or at least stable at the moment in this field (3D in browser with HTML and WebGL). What is your opinion?
Please advice. I am lost....
+Mohamad Nabulsi :

1) It depends on your objective. If you're learning a technology so you get proficient enough to work for a third party, then probably HTML5 and JS might be the right choice for you. But if you want to build your own product, it will depend on its characteristics. It's safe to choose AIR, because you can now package the runtime with your application. But will AIR (or Titanium) be the right choices for your application needs? One thing is for sure: going Native is always the safest choice.
2) I don't have enough experience with 3D to provide you an honest opinion...
This post is getting better over time! Keep posting!
There's definitely no reason not to use AIR for personal projects. CaptiveRuntime makes sure that user's can always install it, and with NativeExtensions mean you can do almost anything even if it's not supported by Adobe/AIR.

Unity is probably a good bet if you want to focus on 3d.
Excellent post +João Saleiro ! It seems that everybody out there is having a HTML5 injection! but not many are objective and understand well the real limitations and advantages of the different platforms. Using the right tool saves time and effort.
Thank you so much, much of my head scratching clearly explained in black and white. Excellent Info on how to work in html/ js too
JC Lang
Great post, thank you.
I think you've managed to express exactly what a Flex developer faces and thinks when he starts playing with JS and HTML. In some parts of the post I wanted to laugh and cry at the same time cause I thought I was the one who's weird and not willing to see the future.
For example the "coming from Flex you'll be ashamed of the hack" or to be ready to change the user experience at any point because of layout implementation problems. Its truly a shame that a tremendously productive technology like Flex has come to the point where its developers have to take steps backwards because the runtime has such a bad reputation (because everyone is convinced about it) that it cant provide the jobs needed anymore. Hopefully the move to Apache will change some illusions.
Joao, I'd love to share this post on twitter or on our website, would you mind if I reposted it as a quote from you, or do you have it somewhere public ?
duh, thanks... the link would be more obvious if this was a real RIA tool... ... :D just kidding :)
I think Adobe lost only a fight, but not the war.
Adobe will work hard to have a tool that generates HTML5/JS from AS3/Flex. They started already on this (Wallaby). Google has this since long time (GWT).
Adobe will after that have the title: "code once, publish to all: iOS, Android, Desktop, HTML5, and Flash".
Very big companies invested and still invest in the Flash platform. New features are also coming. All this cannot vanish suddenly or simply.
In addition, HTML5 final specs will be ready in 2014. Till that time, many things can happen. We cannot build on top of an "unstable platform"....
+Mohamad Nabulsi , I'm not putting any bets on cross-compilation from existing Flex applications to JS/HTML5 with the current state of the art. IMHO, I can only see that happening with a lightweight version of the SDK specially created for targeting HTML5.
Wallaby is meant to convert artwork and simple animations. FalconJS, an AS3->JS compiler is very experimental (not even alpha) and will pretty soon be donated from Adobe to the Apache Foundation. It will be up to the community to decide what to do with FalconJS. If you want to compile from AS3 to JS right now you can take a look at Haxe.
Great points and well written!

What struck me (again) when reading your story is how huge the web transformation is. We all sit in our respective corners of the world suffering the same frustration. Flash, C# and Obj-C have all gone from zero to hundred in almost no time compared to HTML5/JS/CSS to fix some of the problems, but the common factor is that they all have a centralised standardisation model behind them (ie. a "big tech" company).

The positive side of HTML5/JS/CSS is that it's a completely open set of tools for making computer programs and is being developed completely in the open (it's a empowering feeling to follow the Ecmascript mailing list!). I guess it's comparative to C/C++ in that sense, but the former are inherently made for the new connected era while the latter for the desktop era.

So while I live with the same frustrations as you do every day, I take comfort in the fact that, when "ready", HTML5/JS/CSS will be a completely new way of creating computer programs, without having to rely on the whims of companies constrained to making quarterly cash.

Exciting times ahead, don't despair! :)
Most of the JS issues are already solved by haXe and it still allow you to keep targeting Flash (when you can) while still investing your time in a not proprietary multi platform technology. Most of the people that have invested time in haXe don't regret it since they feel so free from all the bad things happening in either JS or Adobe worlds.

I think it's very important right now for developers to allow themselves to target many platforms (web, mobile, desktop, ...) while still keeping their habits when switching between platforms and so far haXe is one of the best way to do that.
I'm working with health systems (Flex + PHP) in the last years and, over the time, I had a few experiences with JS and I just HATE it... It just a mess, dham, we need a "degree" just to understand some parts of code! We are really going to step back a few years.

I'm just like you, I have a need to write self-explanatory code and well comment, just because I don't know if anyone else is going to work with it or, when there is the need to alter something, it doesn't matter, a few months, a few days, its the same, its easier, we just have to read it.

With JS... forget!

I'm learning it, of course, but it will need to change a lot if the market wants to used it in enterprise solutions... Right now it really seems to be the right tech from the costumer point of view but, just give it some time and I'm certain that the market will learn, by the hard way, that it's not ready yet, and it will need to evolve a lot to be another weapon in the closet.

Good luck to everyone ;)
Hey +Nicolas Cannasse, nice to see you around this corner.
I've actually started targeting enterprise development thanks to MTASC, in the good old OSFlash days with the AME workflow, but after the release of Flex 2 beta 1, I jumped out of the boat - more or less at the same time Haxe was getting some traction, am I right?
Since then, I've been following Haxe from the outside but never tried it. I'll definitely take a look at it as soon as I find some time.

I have some questions, though:

1. Can you recommend some resources on application frameworks (like the Flex SDK) to be used along with Haxe?
2. When using Haxe does it work fine with existing JS libraries (like jQuery) ? How are they managed?
3. Have you considered applying to be an initial commiter to Apache Flex? I surely would love to see you there! ;)

I would like to take this chance to say a huge thank you to +Nicolas Cannasse for all these years doing a great work contributing to the community. Keep rocking! ;)
No need haXe vs Flex it is irrelevant. Flex has only one of opponent -- HTML5.

Flex the Best! Today Flex has no modern alternative to a full app develop process -- code language AS3 (good) + markup language MXML (brilliant) + Flash Builder (good) || FDT (+good) || RASE with MXML (meditative).

1. In 90% cases I has no problems with performance bottleneck with Flex!
2. I need power GUI components with extremly short time for developing and extending!
3. I need system (framework) for developing with flexible (it is a key) Markup Language! (code + ML -- fastest variant in the world)

And look on situation from other side. My irony:

HTML is dead. It is very sad for all us but it is a fact it is a true. We has of millions of projects on HTML, but we can't see it today. All browser engeenes can do run-render only Flash! So stupid situation!

Don't give up! Our company has solution for you! We are presents universal translator HTML2Flex! This translator HTML2Flex to translate all HTML projects to real and stable Flex projects, without any compromises and pixel to pixel equvivalent. New Flex projects after comple to swf works more effectively, dynamically and fastly.
+Jorge Santos The definition of "ready" is subjective. HTML5 and JS are surely ready for most of the use cases (99% of the web is html and js, right?) - but that doesn't mean that they're ready or they'll ever be ready for ALL use cases. We happen to be working in the gray area: the enterprise. In this use case Flex results with lower costs, less maintenance headaches and a better productivity and user experience. But that doesn't mean you can't build huge systems with HTML and JS - while making several sacrifices.
+Dmitry Cherrymissoff "Opponents"? They're no living entities - they're just tools. Use both. Choose accordingly to what fits better your use case.
This is going a bit nuts, but for HTML5 to fulfill the gap that a "plugin free" browser would require, it would need all the things we have grown to know and love in Flash and Flex technologies. Dart looks interesting, but the HTML5 "claims" are about 3 - 5 years ahead of "what we are seeing in all browsers" and flex has been permaturely abandoned in the media due to terrible PR by Adobe. It would be altruistic to assume it was done to force HTML5 to move forward faster, but in reality Adobe couldn't monetize flash so they dumped it, without an equivalent browser technology to replace it. We just wrote a game where a client asked for HTML5 and I told them flat, no, they could not have it without flash, I'm not interested in spending $100k on something that should cost $40k just to assemble a doze JS libarires and hope it all works cross browser with a inferior experience. I do hope Google is successful in pushing languages like Dart, it would have been great if they had embraced Haxe, but that was a case of Not Invented Here, I'd completely welcome a cross browser solution with an advanced language that included classes, functions, injection and meta data support, full control of graphics, constructs such as Sprite and bitmaps, and for the browser to support graphics card accelerator, its just not here yet and HTML5 is far from it today. I see us continuing to provide Flash based solutions for Games and Rich Video applications, and as HTML5 matures we'll migrate to it, but I see this transition being years....
+João Saleiro My short answer: no. :)) I has no lives time and minds resources for some doubtful experiment. I close my HTML experiments in 2003. I need perfect tool and I use it for resolving many tasks. Good luck.

Don't give up.
Stay tuning.
Perfect tool ? When you find it, please let me know, I'll take a golden goose too :D
Absolutely love it +João Saleiro I have been saying this for months to co-workers, management and friends and often it falls on unexperienced or biased ears sadly. I have been doing php and js for 5 years on small business sites and flex/j2ee for two years for the Air Force in parallel. I have the experience and drive in both and you couldn't have hit the nail any more on the head. I even extend the argument to wdbgl another highly talked about technology that will save the world but isn't in a useable state yet like html5 /js for the enterprise.

My only hope is that Dart can take off. It has every opportunity right now with the pr of flex, has really really overwhelmingly smart people working the draft while also writing chrome. It is the best language I have ever seen as far as usability and syntax. I hope dart can save the future of the web.
+João Saleiro the goal of haXe is not to be a Flex killer, it's more to be a base technology that enable to implement frameworks such as Flex. So far there have not been such a complex project launched by the community but I guess it will come at some point when people will have a use for it. I'm myself too busy to either start or contribute it, including Apache Flex. But I highly trust open source to fill the missing gaps ;)

As for your other question, yes it is possible to reuse existing JS libraries by writing "extern" classes (remember AS2 intrinsics ?). Thanks to new "overload" metadata feature we also were able to fully type JQuery which is now available as js.JQuery in standard library.

Of course with haXe you will get strict typing, automatic dependency resolution/inclusion, real classes, but also full reflection api, crossplatform serialization, the ability to use the same language on both server AND client (which is a huge win for both small and big teams in terms of code sharing and communication) etc etc etc
Great Post - thanks for ordering my thoughts ;-)
+João Saleiro Highly recommend JavaScript: The Good Parts, by Douglas Crockford, if you haven't checked it out already. I'm just getting into it myself, but it covers some great stuff, and seems like a good fit for your current development team/situation. Thanks for sharing your thoughts here.
Thanks +Jamie Krug . It's already on my reading list - I hope to find some time to read it in the next month. ;)
Hey João - thanks for allowing me to post this on - it's now live and redirects back to this page (so we can keep the comments in a single place).
nice one Greg, I was hoping something like that would happen.
That's pretty cool Greg. I look forward to read more feedback from other developers, especially which solutions other people are coming up with.
Fantastic post, I can relate to everything you said.
Very good analysis. Love the train wreck code sample. I think we'll be better off in the long run w/ open standards, but it will always be difficult to make anything that works perfectly across all web browsers (until they stop innovating).
Thank you for this post! It's good to see that other Flex devs are feeling the same regarding JS, the HTML5 hype and the options out there.
> JS problems

> Silent errors.

Use strict mode and jslint. This fixes 80% of the silent errors. The rest are just run-time errors which you have to deal with because its dynamic.

> Hard coupling everywhere

Only if you write bad code. Use some infrastructure for aggressive loose coupling (I use nCore : )

> Ugliness

Again only if you write bad code. The examples you listed would be the kind of things I would take developers out back for (and break their legs).

> It's not built for team work.

Again infrastructure, Seperate everything into modules and then document cross module communication with your team. The issue with javascript is that it's not as self documenting as other languages though so other developers can't just use IDEs to figure out your API. Oh and tooling is poor.

> Code practices.

By some weird reason, ---people--- REALLY BAD DEVELOPERS like to write as much

> One of the books I read had one line that took me around 5 minutes to understand!

Yes, most books about javascript are absolutely shit. I'm sure I can find some shit flex books.

> migrating their Flash applications to HTML expecting them to work right away on iOS.

People that expect they can port a desktop application to a mobile application (whether HTML5 or iOS) without changing the UI are fools and get what's coming to them.
Hey +Jake Verbaten. Thank you for taking the time to share some knowledge - I do appreciate it!

I'll take a look at jslint and nCore, thanks!
Can you recommend a good reading that could help minimizing some of the issues I pointed in my post?

Also, could you recommend a JS minifier that can join files and minimize them automatically by listening for changes in a directory with javascript files? I'm not happy with my findings :|
The problem with watching a dir and doing minimization is dependancies, certain files will need to be included is a certain order. When doing PiratesLoveDaisies we wrote a GUI for Google Closire in Adobe AIR, works great, but I'm not sure how directory monitoring would work given the dependancies issue.
+Shawn Blais I said a directory to simplify communication. It can be simply a list of Javascript files, and the minification and joining would occur in the same order you specify in the list. Every time one of the files change, the algorithm runs. Is there a ready-to-go tool for that ?
+João Saleiro Personally I use tools like [browserify]( and [modul8]( for my build step to join files.

Both of these can watch on files and if not implementing [watching on files]( isn't too difficult using some kind of scripting tool.

As for minification I either use [google closure service]( or use [uglify or closure through an api](

As for those issues you mention, loose coupling can be done by following some of the [large scale javascript patterns]( Personally I just use a mediator and use nCore as a dependency injection layer.

Silent errors can be fixed by using library that don't have silent errors (jQuery is full of silent errors) and by using strict mode and as mentioned static analysis tools like jshint.

Ugliness can be fixed by complying to a style guide (I have my own [style guide]( )

Handling team work, in my case would involve not having the same developer work on the same module at the same time (my modules are all rather small) and having good centralized documentation. I also highly recommend the [github workflow](

As for code practices, I can't think of a good way to handle them. style guides help. Just write good code and accept that 99% of the javascript out there on the web is not an example of good code.

Note cross browser issues can be reduced using one of the many [HTML5 polyfills](
Great article and thanks for the time it took you to experiment and write.

I started my career creating HTML/JS "applications" and abandoned that for all the reasons Joao outlined above. In the beginning, JS was itself a "plugin" in that it wasn't part of HTML and was used to extend the capabilities of HTML. What would be great is if Apache could get MXML/AS3 to be just part of the browsers like HTML/JS is now. People seem to be so against plugins but there wouldn't be the need for plugins if HTML/JS were remotely good at creating complex, useful applications.

HTML/JS is a duct tapped box with different kinds of covers to make it "appear" better than it is. AS3 has it's issues as any language does, but nothing like JS and it's endless hurdles to good productivity. I haven't created a single application in Flex/AIR that users turned around and said, nah give me the JS version instead. They are usually blown away at the speed, polish, turn around, lack of bugs and great usability, especially when it's an AIR app and not dependent on the plugin.
So basically, you are going with HTML5 because of hype despite the numerous problems HTML5/JS has? Great logic.

Every time I'm building apps with JS/HTML5/CSS3 I feel like someone is pulling my nails with pliers. It's an absolute mess of a language, it's a duct taped scripting language that has been patched over the course of last 15 years to look like a Frankenstein.

IDE/Visual tools like Flash/Flash Builder simply don't exist and probably wont' even come close to the level of Flash/AIR in the next decade.

I'm glad you have made a decision. Unfortunately, the amount of clusterf*** I have to deal with building JS/HTML5 apps and wasting time to make it all work and look on desktop first (never does btw) due to every browser trying to reinvent the wheel and add their own crap to dealing with 15 gazillion frameworks and hacks just to get things working is something that nobody will pay me for. It's taken as granted that you just have to deal with it. It's disgusting. Instead of investing time in thinking about creativity, features and functionality of the app, we have to waste time just making it work.

And then of course, when you make it somehow work or "fallback" on older browsers (which is like 50%+), then you are ready to face the fact that all that shit won't work right/or same on mobile.

Whoever says that HTML5 is the future is smoking some heavy drugs. Maybe it will be a viable thing to build RIAs when it gets to the level of Flash we have now, which is probably about a 5-10 years away and by that time, who's gonna be building these apps for the web anymore? I'll tell you, nobody. We are clearly moving to app model because our lives and internet access have shifted to devices and native/mobile apps are by far the best experience and monetization platform for devs as well as users.

And if that's indeed the case, who gives a crap about HTML5. People are welcome to waste their time finding workarounds on the ever-shifting standard such as HTML, while I'll be concentrating my efforts on AIR, AS3 and native languages. I'm sure people will see this soon enough. I guess it's not bad to know HTML5 as you will be able to write some things for wrappers like PhoneGap or in Titanium but the reality is that these will never work as good as AS3 which is soon going to be asynchronous and multi-core capable where it works across platforms and pretty much native speeds (not to mention ANEs and other things that allow you to completely extend it to whatever you need it to be). Again, something that JS/HTML5 won't probably see for another 15 years as every browser will need to do that on their own side and nothing you can personally do about it. And every browser will do it their own way.

I think that hype has damaged this industry in general. Thanks Apple (you cancer on the technology industry). Instead of concentrating on the best tools and solutions, people have become puppets of companies who have vested interest in pushing their browsers and platforms and using HTML5 as some excuse as it can do everything.

It's really sad.
You should try to get in contact with +Addy Osmani who was mentioned in the reading list of +Jake Verbaten. He is all about JavaScript MVC and large scale stuff.

Some resources in addition to Jake's that might help you during your journey:

A JavaScript Pattern Collection:

The Top 10 Javascript MVC Frameworks Reviewed:
(have a glance at Ember.js)

As a compiling and concatenation tool, Livereload might be something you are interested in:
It compiles all better known meta languages. It doesn't do concatenation by default but you can hook it up with additional custom post-processing tasks where you can do that.

Thanks for pointing to and writing about PHPStorm. I never had a closer look at it and that will change now. Cheers!
It will be very interesting to hear your opinion about desktop-in-the-browser-apps-with-java-on-server-side frameworks (vaadin, zk, ext-gwt, smart-gwt, ext.js).
Thanks for the great article! Was real fun to read and very informative.
HTML5 will never conquer all (has any language or framework?) but it's great for what it is. In some cases it's made better with wrappers to native device capabilities (e.g. Phone Gap, Appcelerator, App Cloud). I agree JS is hard to scale without great tooling.
From one disenfranchised Flex developer to another: you may want to look at AngularJS; it's the closest thing I've found to Flex in the Javascript world for DI, databinding and templating.

Still looking for a good UI component library...
A fast update on this topic: our current project is now at a point where requirements are starting to change so I'm doing a lot of refactoring. Now that I'm having some real life experience in refactoring JS, I think I was too nice towards JS in my article: refactoring is a complete nightmare. I cannot see us maintaining a project with constantly changing requirements without serious Unit Testing setup from the start. But Unit Testing will only help us making sure we didn't break something - it won't help in reducing the pain in refactoring.
Time to investigate what we have for Unit Testing in the JS world...
Not to mention that you're likely to spend more time fixing unit tests as the project increases in size and changes more rapidly. sounds like a nightmare :)
+João Saleiro I recommend you write unit tests with mocha ( ). As for refactoring being a pain, it's a pain to refactor badly written code ( no offence ). I've done plenty of refactoring that I never found painful.

Then again I do go out of my way to write code that's predicts changes and easy to adapt. Making sure everything is loosely coupled is a good start.
This is the elephant in the room with all this JS hype... unavoidable technical debt leading to sky rocketing maintenance costs.
+Shawn Blais what makes the technical debt unavoidable? Isn't that just programmers building up too much technical debt and thinking they can get away with it?

> "[...] you don't want people that aren't really programmers programming, you'll suffer for it! - John Carmack
Just the fact that you need to layer so many frameworks on top of each other, which adds a lot of cognitive overhead that can't easily be passed on. Plus the fact that re factoring is a really laborious and tough process (meaning it gets done less).

I mean at the end of the day, you're forcing a square peg in a round hole, you can only get so far. That's why you see both Google and Firefox proposing typed language alternatives.
And I hate the term "bad programmers", it's all about time, we don't work in budgetless vacuum's. Things need to get done, within a certain timeframes, and concessions are always made...
+Jake Verbaten naturally there's a lot of space for improvement in our code. But before saying "it's badly written" let's remember that my background is on Software Engineering and that's what I've been doing for the last, humm... 10 years? I'm sorry if I'm not being humble right now but I have plenty of experience to know that while this current codebase is far from being perfect, I also know that there's no comparison at all between refactoring a JAVA/Flex project or a JS project.
I would prefer if you have said "yes, it's very easy to refactor". It seems it's not the case. Saying "you're doing it wrong" (without knowing if I really am) does not invalidate my argument that Refactoring is a nightmare.

Second point: this project is being done by several people: team work. As soon as you start getting many people involved, it gets hard to keep track of the quality of the code - especially if you have third-parties involved. In structured languages this is also a problem, but it's certainly easier to locate and fix mistakes other people do.

Here's a simple example of what's happening: we built a full module for managing "Spaces" (it doesn't matter what it does). We have a "Space" object, with a "locateSpace" method, and another 40 methods in a couple of files inside a "package" like "com.myproject.spaces". We have dozens of calls to these methods. At a certain point, the "reality" changed and it seems we have to call them "Places". In Java/Flex, this would be done in 2 or 3 minutes, without many worries in breaking existing code. In JS I spent the full afternoon fixing naming and now I'm in a runtime-error-hell - I have to test every possible case to make sure it's not breaking... And it's breaking everywhere. I'm cursing myself for not having setup proper Unit Testing from the start.

+Jake Verbaten, I enjoy your comments and tips, but naturally, instead of saying "you're doing it wrong (no offense)" I would really love if you could direct me with some tips, urls and books that could simplify the refactoring nightmare. Let's start with: if I have 50 definitions and calls in a project to different methods with names like "yySpaceyyyyyy()" that need to be changed to "yyyPlaceyyyyy()", how would you fix it? (please, don't tell me "Find/Replace", I spent the whole afternoon doing Find/Replace, so if see that dialog box one more time....)
+Shawn Blais I appreciate deadlines exist. It's simply an issue that people need to be aware that cutting corners have a price in maintenance. I think the main issue is not being aware of how expensive code debt is in JavaScript and thus cutting too many corners.

I appreciate that we really aught to work on making code debt cheaper.

+João Saleiro Although I haven't worked on a complex project with thousands of files, re-factoring `grep`, `sed` and `awk` have not failed me on smaller projects so far. I find a lot of JavaScript programmers use [unix]( as their IDE.

I also understand the problems of code quality in teams. Generally these problems are migated because platforms like Java or Flex are good at "average programmer damage control". Languages like JavaScript penalize you heavily for mistakes and code debt in a similar fashion C does.

Admittedly we still have a large way to in go in terms of education people in how to develop effectively in HTML5/JavaScript technologies without accumulating code debt.
+João Saleiro 2-3 minutes!? You're being generous... 10 seconds tops... on a slow computer :p
Wow. Don't know where to start.

*HTML5 is unstable and nothing really new*
HTML5 being unstable? HTML5 is just an addition of HTML which has been out longer than Flash. Also, no real additions? HTML5 is more than markup. It includes all kinds of new JS APIs like video, audio, and even file browsing (yes, you can now browse your computer files purely with JS from your browser). So, WTF do you mean unstable and what do you mean nothing new? HTML has been around long before Flash, or do you mean the JS APIs? And if so, unstable and cross-browser compatibility are very, very different things. You can write apps with HTML/CSS/JS in things like AIR (nasty), Appcelerator, PhoneGap, etc and not have to worry about those things. Depends on what you're doing.

*Classes in JS*
JavaScript has no classes? Uh, yeah? C++ doesn't have prototypes? JavaScript is a prototypal language, it is NOT a classical language so why do you even compare those? You're comparing apples to oranges. It's like me complaining C++ doesnt have prototypes. JavaScript is heavy OOP if you're doing it right, where do you get it isn't? To be honest, im dumbfounded at where you get the idea it isn't. Learn prototypes. It's fucking JavaScript, not Java.

*Tightly coupled*
Loose coupling is easy, really easy. Sounds like you aren't familiar with general programming design patterns. Coupling has to deal with the design of your code, not the language itself. You should look at pub/sub and the mediator programming patterns. Yes, they work in JS and allow you to easily decouple things. I can throw entire pieces of JS out without it breaking anything, no errors, and you'd never notice anything is not working. You sir are doing it very wrong. and

*JS Is Scary*
The reason is scares you and you don't understand why people are places bets on it is because you don't seem to even have a vague idea of how to use the language.
+Oscar Godson HTML5 should not do file browser. Can you reference what part of it allows HTML5 to read my local files?
+Oscar Godson I saw you shared my post stating that I said things that I didn't and you are getting religious with this. I would appreciate if you did a proper reading before starting a flame war. I would also appreciate that you didn't distort my sentences or that you didn't take them out of context. Remember that the full post is around one use case: Enterprise RIAs behaving like desktop applications.

Remember that these are the steps of someone who's (was) trying to replicate the same workflows from Flex and JAVA in the Javascript world and I Know I'm Doing a Lot of Things Wrong which is something that is clearly stated in the post. So if you want to be helpful, instead of repeating what I said and adding a "WTF moment" you can provide resources that can help us doing it right. There's a lot of people reading this post looking for answers, so feel free to be helpful.
For concatenating JS files in the right order, and then minify the result, Ant together with yuicompressor are enough and work pretty well. The ant task in this post works pretty well:
You can use a file watcher to detect changes to files/directories and call the ant task automatically. Hope this helps other people with the same issue.
My next step is to take a look at PubSub - which pretty much looks like an implementation of the Observer pattern.
+João Saleiro The thing about "PubSub" is that it's just an implementation of the observer.

However when using pubsub for aggressive modular architecture your supposed to use a mediator (example:,html).

The mediator pattern is probably the best pattern for loosely coupled architecture. And is promoted by AddyOsmani on his scalable architecture article.

As for concatenating files. Any build script combined with your favourite minifying tool will do.
+Jake Verbaten, actually that's exactly what I'm doing right now: reducing coupling between objects by using mediators. We are already using ViewMediators (I think ours look more as Presentation Models...), but Controller objects were still calling each other or subscribing/publishing events between them. I'm in the process of cleaning the coupling between Controllers by using Mediators. It's starting to look a lot like PureMVC.

For those with experience in Actionscript, PureMVC approaches might fit well in the Javascript world (/cc +Cliff Hall). (Actually, I just checked and it seems there's a JS port).

Naturally, I would have preferred a DI+EventHandling approach based in annotations/metadata like Swiz, since it avoids a lot of boilerplate code and keeps the structure ultra clean. +Jake Verbaten, in case you know Swiz (or the very-basics of Java Spring), what's the closest library in Javascript to inject models and listen to events using an annotation-based approach ?
+Jake Verbaten , I would like to say thank you once again for all the helpful tips you've provided so far!
+João Saleiro I don't work with swiz or java spring and any data annotation I have seen I hate. I use inheritance and function composition to avoid boilerplate code.

As for DI I use nCore as mentioned to dependency inject the mediator into every module. And then use require to load other modules in if they are needed. (example :

I don't really know what your looking for, whether an equivelant exists in the javascript world and whether that equivelant is useful or just a wrong solution.
+João Saleiro There are currently several PureMVC JS ports each tied to a different UI framework out of (what seemed like) necessity. We're actually very close to releasing a fully tested and documented Native JS port that works with any UI/DOM/OOP abstraction layer. You can use your favorite class emulation library (e.g., Mootools, etc.) or the built in puremvc.define() method to create your classes. If you do the latter, you can decouple the MVC actors from the view components, allowing multiple UI libs, or to switch to another UI lib without having to rewrite everything.
+João Saleiro In the JS community we get a lot of people bashing it who don't understand it. There's plenty of bad things about it, but all the things you stated about it, for the most part, are completely false. I understand you're still learning the language, but even the most basic, shitty book would state JS is a prototypal language (which in turn means it is in fact OOP) which makes me believe you haven't really tried the language for the language it is, and instead because it's not like the languages you know. And as +Jake Verbaten also stated, many of the other things you stated as "bad" about JS have nothing to do with languages and more about designing and architecture of applications.

It's taken us, JS engineers, a long time to even be considered real engineers and I'm pretty defensive to people who start claiming it's not meant for "big" projects still, esp. since I now work at an enterprise company as a JavaScript Engineer pushing our project to nearly 4 million people using basically the same JS code base for web and desktop. I come off religious about it because I am, it's my life and it's what I do day in and day out and what I've put my faith into for the past 5 years as you have with Flex and ActionScript, but you wont see me bashing a language I dont full understand. So yes, I am very defensive about it and the passing of misinformation.
+João Saleiro Thanks for a great post, I've used QUnit for unit testing JavaScript with some good success. I use Netbeans primarily for my JavaScript editing and sometimes it refactors fairly well, but alas, it get's easily confused so you can't rely on it 100% - I always check-in my code to SVN first ;-).

An example (if anyone knows how to resolve this I'd be happy to hear)... if I use the prototypeJS library then Netbeans finds it hard to decipher what a class is and the associated prototype methods (presumably because it adds them through a 'method' method instead of MyClass.prototype.myFunction'). This means refactoring breaks and the intellisense gives up early.

Shame there's people on here bashing your article, it's the best I've read. You haven't bashed JS in my opinion, your views seem balanced and with experience behind it. The fact at the end of the day is that other languages can be more productive as they are statically typed, as JS is not, then the tools can't be expected to help you out as much.
+Rob Wilson thank you for your words and for suggesting QUnit - I'll definitely take a look.

In the meantime, I've seen that Sencha is promoting a Webinar in February: "Moving from Adobe Flex to HTML5 and Sencha" [1]. While the pricing of their products doesn't attract me much, I've already subscribed and I'll share some thoughts on their approach after the Webinar (/cc +Ted Patrick ).

+Rob Wilson netbeans has mediocre auto completion logic. Try web storm 3 or vs 2011 for an optimised js IDE experience.

And static vs dynamic in terms of tools is a myth. You can make an IDE that is just as good as a generic statically typed language IDE. There just hasn't been a company that has sinked significant money into this development.
Disclosure... I used to work at Adobe on Flex and I now work for Sencha.

Flex is great tech. Let me repeat that, Flex is great tech. ( Notice this is the end of the sentence. )

I joined Sencha because the company is focused on building professional frameworks, tools, and services to enable HTML5 Applications. As I am learning both Ext JS and Touch frameworks I have discovered some interesting things that stand out for me:

Modern Class Architecture - Customize and extend any part of the framework (containers/controls) easily using JavaScript
Runtime Class Loading - Load classes and dependent classes at runtime
Standard Library - Common features and functions need to build applications. (Ext.Array & Ext.ModelManager)
Containers - Rich containers with programatic layout support (hbox/vbox)
Xtype - Use JavaScript object literals to instantiate trees of components with support for loading UI remotely.
CSS & SASS - Use SASS templates to skin the frameworks programmatically and all styling is done with CSS.
Data Stores & Data Models - Use models to type loaded data and populate forms. Use Stores to load and sync data remotely
DataGrid, Scrolling, Gestures...

Sencha's Business - We license our frameworks (Dual: GPLv3 or Commercial) to developers as a business and are thus able to grow our development teams, constantly improve our framework quality, and support 50% of the Fortune 100 as customers. A desktop commercial license (Ext JS) costs $350 per developer and Sencha Touch commercial license is free. Additionally we are building a tools and services business and offer professional training and support for teams that need it. As a company we have raised $30 Million in venture capital and today Sencha is a profitable and rapidly growing business.

In my personal opinion, Flex developers, given their experience, have a golden opportunity to lead the market for HTML5 Applications. As developers, Flex has been building very sophisticated UI for the past 6 years, proven techniques to architect larger scale applications, and deep knowledge of an advanced form of ECMAScript. Combined with the right tools and frameworks, the opportunity with HTML5 is yours as developers.

I am presenting a webinar on Flex to Sencha on Valentines Day, Feb 14, and would love to see you in attendance. I will cover the basics and deep dive into Sencha's frameworks in the context of a Flex developer.


Look forward to seeing you at the webinar.


Ted Patrick
Developer Relations

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” - Charles Darwin
This post is fantastic in terms of the depth of understanding you have brought of the topic of "WTH to go next?!" a web designer/developer faces every day. I am going to refer to your findings as my next roadmap because you have so clearly outlined many of my much more incoherent thoughts. Thanks!
Great post, João. I found reading the comments was just as educational ;)

These days a lot more RIA developers will find themselves in your boat: comparing JS and HTML5 with Flex and most will come away disappointed to say the least. But these are first impressions and over time I'm sure many organizations will have to find a combination of technologies and frameworks that are better suited for their specific application needs. Flex has been a great catch-all solution due to the consistency and ubiquity of the Flash platform across browsers. I believe that any organization that jumps ship too quickly to whatever the flavor-of-the-week technology is will probably find themselves cornered into solving crippling technical hurdles or worse - going flat broke.

I've worked with enterprise-grade Flex applications for years now and the framework has truly been a remarkable asset once our code and architectural standards were ironed out. The same could be said for JS and HTML5 but we'll soon have find that out.
This is definitely one of the best readings on the " Enterprise Development: Flex vs HTML5 " topic:, published today by +Yakov Fain from Farata Systems.

I strongly recommend it to everyone who's been following my post - while mine was more tech-oriented, Yakov's post is more focused in higher-level business decisions regarding the cost and maintainability of both HTML5 and Flex projects.
For those looking for a better way to encapsulate their Javascript code, the module pattern might be a good start [1].

What I'm doing is basically:

var MyController = (function(model)
var public = { };

// private
function myPrivateMethod() { };

// public
public.myPublicMethod = function() { };

return public;


This will help you to:

- isolate MyController.
- have better control on the dependencies: if you force yourself to pass everything MyController needs (in the above case, myModel) as parameters of the function, it will make it easier for you to know and change dependencies.
- have a development model a bit closer to what we're used to
+Oscar Godson has published a post [1] where he criticizes some of my arguments. I find critics very welcome, but I would appreciate if he kept the sentences on the original context, since he's distorting their meaning. This is actually the third time I'm requesting +Oscar Godson to not do that.

Here are some of the sentences +Oscar Godson has taken out of context:

We work on the enterprise and enterprise means stability.
Wrote by Oscar: HTML is not unstable. HTML is far more stable than Flash and even has more support than Flash. HTML is supported on more devices than Flash is for a reason. It's more stable, less RAM hungry, and overall safer. Apple didn't want to support Flash for a reason.

In the original context stability refers to not too many moving parts (not many things changing at the same time), as I clearly said in the post exactly on the following sentence. You took this out of context and changed what I meant to a complete different topic. HTML5 there's nothing new or better than what you already have.
Wrote by Oscar: Err, nothing new? Let's see: [...] ...and the list goes on. Is it better than what you Flash people have? I don't actually know because he never mentioned any of these.

Once again, you took this out of context. Exactly on the previous paragraph I said that HTML5 is a complete new amazing world for web-developers but you just copied this paragraph where I'm referring to Flex developers who already have most (or all) of those tools - so there's actually nothing new for them.

Wrote by Oscar: I could have sworn the article said JS wasn't OOP, maybe it was edited, maybe I read it wrong, but just to be clear, JS is an OOP language.

Every time I edited this post was only to fix typos. In the post I clearly said that there are real objects in Javascript, despite other people disagreeing. I never said you can't do OOP. I just said that the typical Class definitions are not there.

Anyway, +Oscar Godson ends his post with a sentence that I completely agree with, which is exactly what I said a couple of times in my post:

If you're an engineer wanting to try JavaScript, forget everything you know about your classical-compiled-written-in-an-IDE language and learn JavaScript for the language it is which is a prototypal language
Great advice! ;)

+Oscar Godson, I recommend you read Yakov's post that I shared in a comment above.

One more thing: I don't really care about the languages. Since 1995 I've been into QBasic, Turbo Pascal, C, C++, Assembler (Mac1), Delphi, Visual Basic, C#/, Javascript "2002", JAVA, PHP, Actionscript/MXML (and a couple of others that I don't remember ATM). I don't really care for any of them. I only care that they make my life is easier, by helping me doing a better work and more money in less time and cost - independently of the language. I'm not a developer making my career on top a technology, but a business-owner focused in results. I want ALL languages and tools to improve so we can focus on what matters: building kick-ass solutions that work amazingly great.

Now, +Oscar Godson, can we just sort out our differences and work together to improve the web? ;)

In JS, if you have:

var myResult = myFunction();

how do you normally know what are the contents of myResult without having to look at the code of myFunction? Do you have to rely in documentation, or are there working techniques to make you more productive (i.e. not having to read other's code to find out what a certain object will contain)?

The bigger this project gets (and there are more people involved in the code), the more I find myself wasting time reading code and trying to figure out cases like the above. Are there techniques to reduce these delays?
+Jake Verbaten ? (and thanks in advance! :) ).
+João Saleiro In that case you could simple do console.log(myResult) (as long as myFunction isn't an async call, if so, do console.log(callbackData) inside the callback of myFunction)
+João Saleiro At the very least a good IDE has a go to definition function and a good project has block comments above functions defining their return value.

If your very lucky your IDE can crawl your block comments and show you the return type on hover.

The only alternative is a common style guide and sensibly named functions. Also guessing the return type based on how it is used.

My personal work flow is read the hand written documentation of an "interface" before I use that "interface".

I agree improvements can be made in this work flow. However I've gotten to the stage where I can just make good guesses by intuition and get it right most of the time. Call me lucky.
+João Saleiro also, the out of contexts stuff is how i read it. If HTML isn't "unstable" what were you referring too? And what do you mean "too many moving parts?"

And the nothing new part is a little weird if thats what you meant. It's a completely different language. Comparing Flex APIs directly with JS APIs seems strange. For example, I can write the same "to do" app in Node, PHP, or .NET. They'll get the same visual outcome, but the core app inside will be totally different. My choice between those 3 isn't going to be "who has the biggest API" or even whats the cheapest possible way of doing it (terrible way of building an app), it's going to be the best for the job and I'd never expect someone to write an article saying PHP is more advanced then Node just because PHP has more libraries and APIs. That seems odd to me.
+Oscar Godson Too many moving parts means that there are too much things changing, and it's hard to keep track of everything. In the Enterprise environment - ex: Deloitte - you're focused in business rules and you have to get things done in tight deadlines. You can't afford to be keeping track of everything that is constantly changing, especially if there's a high chance of something breaking.

Oscar, since you're not a Flex developer it's normal that you do not understand the frustration of someone who's working on a different stack, trying to put the pieces together to build something that was already working in another environment (Flex) for several years. That's what I mean with "nothing new" - and I think it's very well explained in the article. See how many people in this post feel the same way - that might represent something, no?

In all your comments, you simply seem to have not read properly the article. Why are you giving examples with PHP or .NET, when those belong to the server-side stack? What we're talking about here is about building complete Client-Side applications that almost don't depend on the server. Our (my company) projects in Flex are 85% client-side code and 15% server-side code (being the server-side only a two-tier exposing services and doing a couple of business rules).The equivalent in the HTML stack would be to build a SPA (Single-Page-Application). Your time is spent mostly building only the client side, normally loading data from Mock services. We have a couple of products where the client side is way above > 100.000 LOC.
Can you imagine Powerpoint running in your browser? Or MS Word ? This is the type of applications that I'm referring to - RIAs. While they're not easy to build, Flex gives you a very comfortable environment for building these types of applications (see SlideRocket. see Prezi. see ). These are desktop-like experiences running in your browser, that are very hard - but not impossible - to achieve with the HTML stack. Google Docs is great, but 1- it's still a bit far from their desktop version 2- it's not written in Javascript directly 3- It was built by Google, a behemoth with "infinite" resources.
The HTML stack is improving, that's for sure, but do understand that there's a huge difference between building a RIA today in Flex or in HTML(5).

I would like that this was kept as a constructive post with people sharing information and solutions.
+Jake Verbaten Lucky is something that I cannot afford to be, when we're building intranet banking solutions and real-time trading systems. There's no space for mistakes. You referred to IDEs that pick comments and show then on hover - do you know if WebStorm does that?
+João Saleiro the only IDE I know that does that is VS2011 if you use vs-doc as your documentation format.

Also it's about relying on luck and hoping you don't make mistakes. It's just if you luckily guessed the right return type then your coding experience is smoother. If the return type you guessed was wrong then your unit tests and 100% (yeah 100% is possible, do it. Especially for banking and real-time trading systems) coverage tell you that you got it wrong

I agree though the lack of return type and argument type information in the IDE is a right pain in the ass. My solution is to admit that it wont happen and to just get used to reading docs. Alternatively set up infrastructure so that it does work with your IDE of choice.
+João Saleiro A colleague of mine says that documentation defined in block comments above properties and methods is parsed by WebStorm 3 and shown in the IDE. So as long as you put the return type information in a comment above the method, the IDE should show you it.
We never use Flex 4 so take my words with caution. For almost 3 years, in 2 companies, we used Flex because we thought it was the right choice, having a java web application server background for more than 10 years. However we were disappointed for several reasons:
- very, very easy to do simple stuffs but we found that it was very, very difficult to do difficult stuffs. The learning curve was everything but not linear. That was the feeling of a team of 6 developers. Some kind of incompatibility?
- we used Eclipse and the Flex plugin. Developing big projects was slow. Refactoring was, almost, a nightmare (apparently changed with Flex 4 but again never used it). Poor performances.
- some components were very buggy (I think about the list tree for example we used extensively). Sometimes, it was difficult to customize the component, more difficult than we expected. And the bugs remain release after release of Flex 3.
- no real Adobe support except if you used Livecycle DS (which was very, very expensive for what it had to offer). So we used Blaze DS and even Granite DS for some project which worked great. However, Adode didn't care of Flex developers who didn't use LC DS.

Then we moved to native development for mobile so my purpose is not to compare Flex with Javascript. But I'm personally very interested by Javascript because, with node.js, it's the promise that all developers from the client to the server will talk the same language. However, as you pointed out, Javascript, in the modern form, is not mature but IMO, as it was for Flex 2 and Flex 3. So maybe, we have just to be patient…
+Philippe Rabier I do understand your pain with Flex 3. We (my company) managed to be quite productive with it, but while doing consulting and teaching it was usual to see other companies facing exactly the same issues you pointed out.
We had similiar pains developing large-scale enterprise applications under Flex 2 and Flex 3. Much of our problems stemmed however from the fact that we had little knowledge of design patterns and we were still attempting to solidify coding standards. We also were heavily dependent on Cairngorm and it's boiler-plate style. Still we got through the hurdles and even started and finished an 8 month long Flex 4.5 application that was heavy on skinning. The project went relatively smoothly with very few UI developers. I can't imagine that we could have accomplished this all with the same amount of UI developers under JS/HTML5 in the same time-frame.

I also read Yakov's article published the other day...good read.
Rex Luk
I had an experience in Director 6, 7, 8 - 8.5 from 1998 - 2002. I have no choice to move me from Director to Flash. After all the browser did not support shockwave player. Now it is similar case.... The most consideration is not on how well the tool is ..... but how much the platform is to be used....
Small tip: be extremely careful when refactoring in WebStorm/PHPStorm . What the IDE seems to be doing is something close to a simple Find/Replace. We did a refactor in a property - changed "geolocation" to "geo" in a certain object - but PHPStorm decided that calls to other objects with a "geolocation" property (like "navigator.geolocation") should also be changed (to "navigator.geo"). Conclusion: WebStorm doesn't have real refactoring (don't rely on it).
Very nice review and a lot of good comments. Not much talk on GWT though (only an unanswered question), IMO, coming from a Flex environment, GWT (+ExtGWT or +SmartGWT) should have been one of your first options to try, is there anything that stopped you from doing so?
+Manuel Desdin At first, I did a superficial research on GWT. I've decided to start by getting comfortable with HTML and JS (since that's what GWT generates) so that later I could approach more seriously platforms/languages that rely on cross-compilation. I haven't reached that point yet. ;)
"But that doesn't mean you can't build huge systems with HTML and JS"

Other than GWT, it would probably be worth looking at Google Closure (used for Gmail, etc.) and the book from O'Reily. I'm just starting to look into it, having been using JQuery or Prototype.js. I agree with the sentiment, there are too many options to know for sure what to invest in (sproutcore, backbone, etc).
Great post.. strongly agree on almost everything.
Hi Joao

First of all tks alot for your post i find it very helpfull and it gathers alot of usefull information that helps on this days of changes.

I have been looking for some IDE's to i saw your comments on some but during my search i stumbled on this one:

and this one:

any thoughts

Wakanda realy seemed good but i havent actualy tryed it out...
First off excellent post, and I am disappointed I just got to reading this but at least I was able to consume the mostly helpful and interesting comments. I myself has been developing since AS1 and moved onto Flex early and have had very similar experiences with trying to develop with javascript. Of course anyone who has developed with AS1 knows, it feels like falling back in time - where you are trying to deal with issues like "this" and scope.

I think you had some excellent, valid concerns, about the state of real world applications in javascript but what some tend to forget is that you have had experience with these issues already i.e. scope/refactoring/privates/class/prototype/inheritence/composition just to name a few. Just as you, and many other developers, we have walked down this path and we are just trying to maneuver through so we don't have to face the same challenges poised to us before.

Unfortunately our choices of a language is almost entirely limited to javascript, and I mean unfortunately in the sense of choice, and not the language. But most likely +Jake Verbaten is a smarter developer then I, and so has always named his variables and functions appropriately the first time so refactoring is a non issue. I for one, have somewhat taken for granted that I can refactor at will or name something arbitrarily and clean my code later. I also must be a very unlucky developer because every one of my peers seem to be "average programmer"s and they need tools to do "damage control". (If that is the case I hope I am lumped in with them.) I am also assuming +Oscar Godson is much more familiar with "general programming design patterns" because it seems, as we all know, that religion is the answer to all of my issues.

If I had a choice right now, it is hard for me to get behind the javascript bandwagon for any medium to large scale application (due to reasons noted and others - and yes I have read "the good parts" of javascript). And it seems that you find a lot of backlash, mainly due to server side javascript, on how to resolve these issues. Because many developers are just trying to find something to move onto in lieu of flex.
First, things got much much better with Flash Builder 4 and spark was a great step forward for the framework.
Second, there are basically two levels of development with Flex: the way the docs show everything with MXML or using ActionScript3 to harness the real power of Flex.
Third, there is always a learning curve with any sizable or useful language. The question you should ask is not about the learning curve but whether the learning curve gets you to be productive or if it just gets you good at hack workarounds.

Developers who believe or imply they are better than most other devs makes their comments and opinions so tainted by arrogance, they become irrelevant in a civil discussion. If everyone just named variables and functions correctly the first time, then refactoring would never have been thought of; stupid humans.

Religious attitudes aside, you should choose the best tool to accomplish your goals. With enough time, most technology decisions look questionable framed in current knowledge. I wasn't too long ago the universe revolved around the earth, right?
Flex is a pleasure to code, especially if you're a Java developer. The problem with developers with "big heads" often over-engineer and creates some "ultimate" custom frameworks that "does it all". Ridiculously pointless. They often neglect the limitations of the technology and the barriers imposed by the browser. In turn, application's performance suffers. Worsen by Adobe's poor technical support, it fuels the bad perception. Web apps are meant to be "lightweight" and simple. While Flex/Flash technology enhances the experience, one should not forget the "realm" your application is running on. For those who chose the path of HTML + JS + CSS, the rationale is that the "pain" is immediate if one gets overboard. You will be forced to keep it small and lean - lightweight... make it simple then improve. The same should be applied to any web development, regardless of the technology of choice. Give justice to your "art".

In Flex, it is very easy to fancy your application as a "god", but HTML5 will constantly remind you the limitation of the web.
Thanks a lot to João and to all posts here! Obrigado!
I think into coming days , Both Flex and html5 would be best . it up to you how to select which tech. depending on req..Really nice post .it's awesome , getting useful before dive into html5 css js..
+João Saleiro Quick background: longtime Java, Python and JS developer with a pretty eclectic skillset, but which does not (yet - learning it now) include Flex.

I was the architect and manager for a very large (huge? one of the largest for sure) enterprise Ext JS project. I suspect that at this point in time something like Sencha might be closest to what you were used to: standardized and consistent object model, wide array of nicely integrated UI components, decoupled data integration, and nearly pixel-perfect cross-browser compatibility. 3 or 4 years ago at the beginning of the project I evaluated Ext vs. Flex, and Ext won, not least because clients for enterprise applications can have issues with browser plugins like Flash, and certainly with installing things on the desktop like Air.

Upsides (in addition to what I mentioned above):

1) You never have to touch HTML or CSS if you don't want to: build the entire thing in Javascript using Ext layouts. Nest a border layout in the viewport and get a classic header/footer/content site with autosized layouts that looks exactly the same in every browser. It works pretty well on mobile as well. If you're careful you can maintain a decent separation between the code and UI, and use a design/CSS group to do that piece.

2) Extremely functional grids, better than what Flex had at least at the last point I did a comparison. The UI components in general are very good, certainly much better than JQuery's in my opinion.

3) UI configuration similar to MXML, excepting that it's JSON. Meh, not a big difference.

4) Most complete, consistent, powerful JS library out there that I've seen. JQuery is ok, but the scattershot of the UI and plugins weigh it down. Very few if any hacks were needed when I was using Ext.


1) Yes, it's Javascript. Coming from a love of Python and a background of Java, I get it, and I understand your pain. But I found with Ext that documentation is everything, and you can get most of the way there. Now, I use Emacs as my IDE so I can't help you there, although I've heard that IntelliJ is pretty good.

2) The learning curve is enormous. But then again I'm finding the same thing with Flex. It's not that Flex itself is so huge, but if you want to do it right that means also investing time in learning something like Cairngorm and Parsley. Lack of a usable UI painter is a drag, but from the sounds of it Flex is losing its design view as well. Flex is starting to remind me of the Java ecosystem.

3) It's slow. Not as slow as JQuery, but still performance is a constant battle, particularly if you attempt to build a large single page desktop-like app. 4.x is slower than 3 as well. For many uses it's fine, but put 15 columns of data in a grid with a few hundred rows and it becomes painful. If you really have issues you'll start to consider strategic downsizing to straight HTML and CSS instead of using the fancy layout system to get the performance at the cost of maintenance.

4) Like any large project with multiple developers, the stability and quality of the code will highly depend on the training and abilities of your team. And since it's a completely open language compared to AS3 or Java, you have to be very careful up front. Design reviews, training, lots of communication, and unit testing. Use a build system and decouple the UI so you can run unit tests in a standalone JS machine. Your Flex instincts will help, with your desire for continuous integration, testing, and IoC.

5) You will have great difficulty finding Ext-specific talent when you need it. I suspect the Flex talent pool is many times greater than that of Sencha tech.

A few random observations:

1) Beware module and runtime dependency resolution systems on the web. They're cool and easy, but you're absolutely right when you pine for the simplicity of a SWF. However, there's an added issue with HTML development: if you have hundreds of JS modules or components and you download them as individual files, your load time is completely hosed. Use a build system (JSBuilder is one) to catenate your JS files. Runtime systems can work if the resolution and packaging is done on the server, and the browser only ever sees a single (or a few) files. You can also use something like head.js, a Javascript loading system that parallelizes file fetches by cleverly (mis)using the browser cache. Clients with over-committed T1s at their branch offices will thank you for being careful.

2) SVN? USE GIT!!! ;) - Actually I would have loved to have been able to use either, so count yourself lucky.

3) Important for reuse: don't get accustomed to using DOM IDs. Make it a point to avoid them as much as possible until you understand when and how you can use them safely in a DOM-based application. Because an HTML app is a meld of Javascript and DOM (even if you aren't directly manipulating the DOM), you will have to be aware of the danger. Dependency injection helps, but it won't help you debug a nasty hidden problem caused by a component with a hard-coded ID used more than once.

4) YUI compressor works pretty well. I haven't used Google's tool but I understand that it also works well. If you have minified code, compression turned on (hopefully you don't have to support IE 6/7), and your caching scheme is rational, you're most of the way there and using a different tool will probably get you incremental gains at best.

This is getting long so I'll wrap it up. Feel free to ask more questions of me since I have some hefty direct experience in this area.

Nice article !

The reason why so many people like HTML, CSS and Javascript is because they can avoid the pain involved in getting OO into your brain. They don't care about elegance, longevity, good practice or good patterns . They just want to build it and forget it. Lets face it if everyone had a choice Javascript wouldn't be the language of the web, its just an unkind fluke. Speaking as someone who has 'done' HTML5/CSS/Javascript/PHP and then Flex/Actionscript , the latter just is so much better, logical, elegant and reliable. We live in interesting times but I am sticking with Flex/Air for now...
Nice Post, Thanks for sharing your experience so far.
Flash/Flex and Adobe inspire HTML/JS/CSS to get to the point they are now, but to be able to develop on that platform we need more tools, and richer frameworks. However just like the new mobile devices pushed Flash plugin out of the frame, new ways of using these devices are pushing the "non-sense" of webapps out of the frame, since users prefer the native apps over the web browser. As a Flex developer, and as many others Flex developers, I think that we are going back to native apps, just like we did more than 10yrs ago, but this time these native apps are native online apps.

New layers of desktop OS will drive the user to focus on native apps, like Win8 metro, MacOS iOS layer, TVs, media tanks, game consoles, etc. Of course mobile will continue to evolve and stay there with more native apps. Luckily for us Flex provides a rich framework and a flexible RT to be able to write once and run everywhere, with the same exact powerful UX/UI.

So, I'd hang in there Flash is coming back with more users, is planning to become the new OpenGL, with Flex you could even create a compiler to output to WebGL, or (real) HTML5 using a lot of the new Canvas and WebSockets. We'll see in a few months.
João, great post. Any thoughts on how MS .Net compares to Adobe Flex, especially regarding HTML5?
superb post, and I appreciate your efforts
Joao, was curious if you would provide a brief update to this article? It's been about 6 months since the original posting of this article.  And I was curious if your viewpoint on flex or html5/js/css development has changed at all.
I think you should read Javascript - the Good Parts to get comfortable with javascript. And then switch coding between plain js and jquery - whichever feels most comfortable. I've done some AS3 coding as well, but I think I code the fastest in js than as3 - but that can also be that I know it best too. But for me js-development feels the fastest, but Flex seems quite fast also.
oh god, soooooooo huuuuuuuge ... I will read it later
great! This is what I want to say。Thank you, I will use flex again and agin, and will start to learn some html5 as you suggest.
" You have pretty much no constraints in Flex regarding layouting, giving you immense freedom in creating perfectionist user-experiences. You don't think "how am I going to implement this?" because there's not much to know about Spark skinning: it's really powerful and simple."

This is so true that make people bragging HTML5 look so s**pid, and they don't even know it.
I've been a Flex developer for the past 2 to 2.5 years and an ardent fan since, of the great possibilities I could achieve with this wonderful tool. This post, as for many Flex developers like me, exactly represents the train of thought we all went through when Adobe's "horrible" PR surfaced on Nov '11.

Being a fanboy of Flex myself, I was sceptical till now of HTML5, churning out new theories of how ancient HTML5 is, in comparison to Flex. Your post has given me a very imortant change in my outlook and I completely agree with your point that whatever "technology" that we use is just a tool. The skill of a developer really lies in identifying the best tool that suits the requirement. Thanks a lot for that. :)

I still believe though, that the weakest point for HTML and related technologies is standardization, without which a developer is gonna literally "waste" his time, trying to find a way to make something work in a particular browser (yes, I'm talking about IE) thats already working fine in other browsers.

Anyway, great post and thanks to all for all the information provided.... this has certainly helped me in understanding various frameworks and technologies and to respect them. Cheerio! ;)
Adam P
Hi João, what a great post. I has helped me to add context to many unconfirmed opinions I have had about the changing state of Flex and HTML5. As some other comments have asked, will you have an update on this article?
I am glad I came across this post, you just put pretty much ALL of the aspects/problems of the current state of flash platform developers facing these days. Big picture review you did here was something I spent last year on, and whatever you pointed out here is PRECISELY my current point of view.

Thank you, because I am tired myself trying to introduce to anyone why I will never waste a second of my life in supporting Adobe (or any proprietary corporation) ideas any more. (10 year was enough).
Sencha's ExtJS has:

* Plenty of smart UI components (cross-browser tested)
* MVC programming model (ExtJS 4+)
* Stores (REST based operations towards your server side API, maybe you can reuse your existing backend?)
* Decent event model for all components, add your own as needed

It's not a silver bullet. It works quite well for us in many scenarios to build a "Single Page Application", as close to the desktop as we can go with HTML5 at this time.

__Debugging Javascript
Chrome's built in debugger is a lot better than Firebug. Firebug tends to hang when you work with events such as mouse clicks, drag-and-drop etc. Chrome debugger is stable. IE debugger is the buggiest of them all. :/

Visual Studio 2012 has been the winner for us. Eclipse tends to hang and be sluggish, and the code completion in Eclipse is just ridiculous. Visual Studio has built-in support for minifying CSS and JavaScript  as well as batching them together in single script file or CSS file (a "Bundle"). It will run compilers for Coffescript, typescript, SASS etc out of the box. Can even publish latest version via FTP (it keeps tracks of what has changed so you only need to upload the changed files).

As for assets, SVG is better suited for doing UI icons etc today, looks neat on high resolution displays too.
You completely read my mind... thanks a lot for your post... Lot lot lot of efforts are there in Flex. Sure apache flex will raise in near future. Lot of advantages are there in flex compare to html5 and javascript.  But why don't we create separate application for devices in html or something. Then still we can use flex for all other platforms. I don't understand why people are downgrading flex. Still Flex is a 100% flexible & maintainable language for RIA applications. What is HTML? its for only web sites/pages. It is not suitable for large scale applications. I really felt as i am going 5 years back while developing application in HTML which is uncontrollable and maintainable even whatever toolkit you use.  
Thanks for the comprehensive post. I also think that it would be a waste to lose such an interesting tool set. But the decisions that Adobe is making keeps getting me further worried!
Accidentally found your article and i share all your feelings and concern. I'm a huge fan of Flex because it offers the most excellent way and tools to program RIA/Desktop applications being the best example of how frameworks should be. HTML5 is going towards what Flex is, but it has a long way ahead and a really messy one. Why reinvent what is already there?
Once you experience the simple philosophy and logic behind Flex architecture you have no choice but to simply love it.
And i'd like to point out that Flex is not Flash, it happens to run on Flash but it is more than that, is a revolutionary way of thinking and making software, a way that HTML5 wants to mimic with no success because as long as there will be the old way of programming and interpreting JS it will still be shitty and chaotic.
No matter if adobe drops flash or flex altogether because the desire, knowledge and experience exists to keep it going even in other programming languages, it should not end with Flash, this is just the beginning.
Lucas N
The IDE problem might be mitigated now with Microsoft's "TypeScript"

It's a superset of JS language that compiles to simple JS. They claim IDEs could use it and finally make it possible to easily refactor & organize your typescript (js) code.
I just spent the last 3 months or so diving into the world of FLEX for the first time, looking to change careers from IT/Helpdesk/Managed Services to development.  I've done a lot of reading on the future of FLEX and am a bit scared.  Should I continue learning?  Or move on to something else?  Any input is welcome please!  and thanks!
Good post. Hard for an enterprise application developer to move from flex.
Since you have written this article one year before, do you have any latest recommendations for the tools and technologies chosen?
One of my concern is the REST based approach compared to the AMF(rpc) calls which we are used to in the flex world (We use spring/blazeds in the server with POJO).

This is the best article I have read so far.
Unfortunate with the mess that Adobe make in their ads about the future of Flash platform, I spend a lot of time search for the future of flex, flex vs html5 and this kind of thing. I'm a new entrant in web and enterprise development, I see after a lot of articles, looking in the Apache Flex community, that Flex is definitively with a long future in enterprise applications. HTML5 replaces flex in animations, like banners and this kind of web page development. I see HTML5 as what they are: Web page technology, and in this field flash have no future because HTML5 is capable for animations and other things, and is ubiquitous on mobile and desktop. But Flash platform and Flex is not only about animations and presentation, is about programatic Rich Interfaces, and in this field is still very attractive and with much more powerful tools, in this field flex is years ahead. Unfortunate I don't feel that adobe is give enough attention to this areas with their recent announcements to keep the flex platform ahead and are following the euphoric, this is a business decision. In the future this can change.
And by the way I'm doing exact the reverse, I have experience in building RIA in the browser using frameworks like Extjs and IDE's like eclipse, netbeans and Intellij IDEA and I'm exploring the Flex framework, that feel more mature for my needs. I prefer the compiler, completion and strong typing than the "keep documentation open, try, run, test in the ui to be shore and write testes to every single line, is 1 + 1 = 2 ? :-)
And I'm a Object Oriented guy that like Java, so, Action Script is the heaven for me.
Hi João,
I wonder how your view has changed or not changed 1.5 years after writing your initial post (which is a really good and very well-reflected one!)?
Hi João, I would be also very interested in your current opinion on the matter.
I think, the web still have somethings to learn from flex, but this will be better soon. I'm using the Google Dart language with the port from AngularJs called AngularDart. And is a coesive language and enviroment to build web applications. For this people that like me, search for a coesive platform, with components or easy to create new components, best pratices, security, abstractions, and so on. Well is better check this out:
The emerging webcomponent standard will be a huge step forward, I think. 
While I would like to update this post with more info, my time is currently very scarce.  
Here's a very fast update on our policy for the development stack:

Just a note: we're no longer a services company, but a product company.

If we were a services company, I would probably try to go with the web-stack as much as possible, and use Flex and AIR only on the (rare) cases where it fits the use-case.

As a product company, we still love Flex (and AIR), and everyone here codes both in actionscript and javascript simultaneously.
Oh, and I just forgot to mention Flash on the browser. And you should (forget it) too! ;) 

(Except if you're doing Video, 3D or a very immersive experience)

We use the webstack for everything we do for the browser since 2012. So, no Flash on the browser for us.
Hi Joao, my appreciation for taking the time to reply, eventually :-)
Also thanks for the your views on the matter. We are a product / SaaS company too. While still using Flex for the browser, we notice there are aspects that are becoming more cumbersome (as e.g. Google retiring the Flash API/SDK for maps, iOS support missing for good as it seems, ...). IN the investigation what our future stack is going to be we also currently revolve around HTML5 and Angular, plus X. I'll have a look at what your web / mobile stack is to learn from that.
Thanks again, Toralf
I just got back into developing Air apps using the combo ActionScript and Air. I use command line to compile because I don't know how to use all the gui junk in flash builder (or even visual c++).

But I just heard about FlexJS to compile flex into Javascript. I want to try it out since I am already in the Flex game. And be cool for my next project that I got of making a music rap-band page for a friend. My last Javascript page failed after the big browser updates so I quickly reverted to html only.
Add a comment...