The future of HTML5/JavaScript vs. Flash/Flex?

The email discussion quoted below started with this "innocent" question raised by Lior... Read and comment...
 

Adi Baron (Feb 1)
 
I believe that HTML5 + JavaScript are the future. The reasons are mostly 
1. Support (flash isn't always supported, e.g. RedHat Linux). 
2. Expertise - easier to find/ develop HTML/JavaScript expertise. 
3. Cost - decent flex development requires a good IDE, and these cost money. 
4. Adaption by the market - today you already have JavaScript/CSS libraries that support HTML 5.
5. Shorter/easier development cycle (impossible to debug a flash object on a remote server).
6. Integration with the server side (take for example Gad's last community entry about Flex+Seam).
7. Flex is no longer the only solution for live media.
8. With <canvas/> you can get great presentation like here: http://scripty2.com/
 
I'm sure I forgot tons of stuff... I'll think about it more when I'm less tired.
 
 

Lior Kanfi (Feb 6)
 
 
 

Adi Baron (Feb 6)

 

 

So I guess we have a pretty good idea about where to go :o)

 

Do you know what's Ilan's approach in this area?
 
 

Lior Kanfi (Feb 6)
 
Forward to Ilan Avigdor...
 
 

Ilan Avigdor (Feb 7)
 
I don't have any hands on experience with HTML5, but from what I understand, it is an extension to HTML, allowing you to do stuff you couldn't do with old HTML by adding more tags, but use the same concept of mixture of pages which reside on the server side which contain code which produces something which can be interpreted by the browser + javascript which runs on the client side.
If that is still the case, then I might agree that this is the future for web developers, as oppose to developers.
 
The way I see it, web developers is a special breed of developers, which feel comfortable with this unintuitive development experience of the ui created on the server and being passed to client. writing a line of conditional code on the server to be interpreted on the client is not intuitive. A web developer is always aware of what code is being run on which side.
When I was involved in web applications (ASP.NET) I always needed a web developer besides me.
 
As oppose, when developing a Flex application, your common development skills of object oriented/event driven programming are 100% valid. You program like a desktop, but it runs on the web. You have everything you need in your fat client, and only gets data from the server.
 
I just talked to one of our customers who is an experienced web developer  and he feels the same. He also mentioned lack of good javascript IDE (how come? javascript is around for such a long time).
Given the additional elements of HTML5, he still feels that he would prefer Flex.
 
This is my general feeling. To be specific to the points raised by Adi, I added comments below.
 
That said, in case you tell me that you can develop massive applications with javascript, with classes, event handling, good layout mechanisms, effect libraries, easy customization of UI components and it will only require my desktop development experience, I wouldn't mind use it. Some say that Action script is very similar to javascript, who knows ? 
 
Comment to #1:
The major problem of HTML5 is standard support between browsers. It is easier to support features by a proprietary company then get an agreement of several companies which all want to differentiate themselves.
 
Comment to #2:
Easier to make a Flex developer from a developer, then a web developer from a developer.
 
Comment to #3:
Maybe this is the reason for the lack of good javascript IDE? Flex customers are usually corporates which consider this cost as a good ROI.

 
Comment to #4:
So? Today you have flex adopted by very large corporates as their preferred technology for B2B applications. And this trend is on the rise as other corporates see the benefits of this technology.
 
Comment to #5:
Yo are kidding, right? shorter development cycle?? intuitive programming model leads to shorter development cycle. And you can debug Flex applications emotely if compiled to being debugged. you just point your IDE to run the application in the remote server.
 
Comment to #6:
I read the post and don't get the point. I'm not familiar with SEAM so I'm not sure what the problem is. Most companies comfortably use BlazeDS/web services/http request to get data from server.
 
Comment to #7:
This is hardly the reason for major corporates for choosing Flex. None of the applications I developed used any kind of media, and still Flex was chosen.
 
Comment to #8:
I'm not familiar with this canvas, but Flex which is based on flash which is a primarily a drawing engine, has absolutely no limits of what you can achieve.
 
 

Lior Kanfi (Feb 7)
 
I think it's worth a community post, what do you say?
 
 

Adi Baron (Feb 7)
 
Comment to #1:
HTML 5 is a standard! Not extension. Except for IE which is on its way there - all major browsers already support it. And speaking about standards - the Flash engines on IE and Firefox behave differently. The acknowledgments send from the flash engine to the server (in terms of hand-shaking are different. we had to modify our code to handle this)
 
Comment to #2:
The thing is we have web developers already... no need to make new ones out of OO programmers. Also, somehow, there are always more experienced HTML JavaScript developers then Flex ones.
 
Comment to #3:
Not true... Aptana is a good JavaScript IDE and Intellij is the perfect JavaScript IDE (comes in free community addition now). BTW, Intellij is better for Flex development then Flex Builder. Fact!
 
 
Comment to #4:
he Market is tried of waiting for Adobe... They look at the new features and echo system around JavaScript and envy.
 
Comment to #5:
No, I'm not kidding! I'm doing both (web and Flex development). I wrote (and maintain) an above-standard, complex, Flex application and I know for a fact that if you have your flex object embedded inside other web technologies you cannot debug it
 
Comment to #6:
The point is that once the server side gets more involved then stateless HTTP request/response you start to feel the lack of integration. BTW, the only officially tested (but not supported) framework that runs with Seam is GraniteDS (Just one...).
 
Comment to #7:
You're right. But I was referring to the small portion of applications (or web sites) that chose flash for these capabilities. For example: deezer.com - the whole site is written using HTML and JavaScript aside for the music related parts. This is no longer necessary. Think of it - in terms of resources - the same web developers that created the major part of the site can not facilitate standard HTML/JavaScript to do the rest. No need for Adobe tech.
 
Comment to #8:
Same with <canvas/>
 
Finally - I'm not against Flex. I'm using it with great satisfaction. It's far from being perfect but that's because there's no magic. Nothing is perfect! 
What I was trying to say is that they're on to some really challenging fight against the new features of HTML/JavaScript, and as it looks today - they won't necessarily win. It doesn't mean it will vanish from this world. Not at all! Flex/Flash will always be there. The question is in what volume.
Lot's of it depends on how Adobe reacts to their developers community demands...
BTW, If you want to present a Java/Flex backing argument, you can always give SpringSource as an example. They made integration with flex part of their platform and (this is important) they have an IoC (Spring for Flex) framework developed.

 

 

 

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com