Feedback from a Flex dev investigating HTML5



João Saleiro, well known Flex Developer, author of Airgile and technical leader of Webfuel, has published a blog article: After 6 years doing Flex, am I moving to HTML5?. In this post, he is sharing his experience in trying to use the HTML5 stack for building a RIA. I think this is really a must read article.

I will only give some highlights here for quick-reading, without any comment from myself. But I really invite everyone to take the the time to read the original writing.

I completley agree with one of the first statement of João, though not coming from the same background:


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 another 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.

How well put is the last sentence, that is indeed how things are!


Then he moves to the point Is « HTML5 » ready?

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 (…)

From the point of view of desktop-developer-working-on-the-web – hell no! (…)

It’s quite understandable that a Flex developer feels frustrated. You feel you’re going backwards 4 or 5 years.


About cultural differences

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.


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!.


After covering JS frameworks, IDE, he comes to Javascript

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. 


– Uglyness. 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 with JS that spits 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. (…)

– Code practices. (…) 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 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 good part: no compiling times. Which is actually a very good part… (…)

One thing is for sure: it’s being pushed forward and you can’t deny that.


Then, he goes through Layouting and the DOM, Optimizations/Preloading content, HTML(5), JS and Mobile, UI Components, before entering into Crossbrowser issues.

Crossbrowser issues exist, they are a PITA and they will consume at least 30% of your time in a project. (…)

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. (…)

We had one crossbrowser issue this week that almost killed our current project. (…)


Finally, he states about productivity:

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 Flex development in a near future.


Time for conclusions:

The first conclusion is that we’ll keep using Flex in long-term enterprise RIAs projects. Neither the open-standards nor we are ready to build the same type of experiences that our clients expect us to do. 


But I don’t think we’ll be able to do the same type of RIAs we were doing with Flex at least in the next two years. Also, maintainability and it’s cost scares the shit out of me. 


And quoting him again , some final wisdom 🙂

Bottom line: ignore the shit storm and the bad PR. Ignore fanboys. Choose your tools based on logic.

But alas:

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.


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l'aide de votre compte Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s

%d blogueurs aiment cette page :