JavaScript Development vs. Flex Development (and why today, web development sucks…)
February 8, 2011
Blog post titles with »vs« in it are often quite controversial. Most of the time, eliminating bias in those posts is neither desired nor possible anyway. Same here. However, having worked on real-world projects both using Ruby on Rails/HTML/JavaScript and Flex/AS3, I think that I’m able to kind of compare these different ways of developing rich interactive applications. Note that this is not going to be a comparison of programming languages, i.e. JavaScript vs. ActionScript. While both languages are based on ECMAScript, the major difference is that the latest version of ActionScript is statically typed while JavaScript is a dynamically typed language. Both languages are equally well (or badly) suited for application development.
So, basically, from a developer’s point of view, it mostly comes down to what frameworks and UI toolkits are available because you certainly don’t want to do everything from scratch (which particularly applies to JavaScript because handling all the browser differences usually means a lot of additional work). Let’s start with JavaScript: What libraries are available? Well, first jQuery comes to mind. It helps you with manipulating the broken document object model, consistently across all browsers. Good stuff. Built on top of jQuery, there’s a multitude of more or less valuable plugins. There’s jQuery mobile (currently in alpha stages and very buggy) for mobile development and jQuery UI (also not really very mature yet) which provides some UI components with some basic API.
Then we have ExtJS (and Sencha Touch for mobile development) which probably has one of the most complete and mature UI component sets. ExtJS is quite a different from jQuery. First, the learning curve is much higher (that’s what you keep reading on blogs and in forums and I think it’s kind of true). Secondly, Ext is mostly about defining all components purely in JavaScript while jQuery (UI) is more about progressive enhancement of existing HTML elements. Then, there’s Dojo…and YUI…and…Prototype/script.aculo.us and [insert your favourite library here] and…- the list goes on and on and on. And there are also quite a few applications frameworks for JS: How about Sproutcore, Knockout, Backbone.js or [insert your favourite JS framework here]? Having the choice is great? Which one to choose for your application that wants to leverage the latest and greatest? It depends, exactly.
In my opinion, no JS library, toolkit, framework or whatever currently comes even close to what Flex/AS3 have to offer. The components of Flex have been developed over many years, have undergone major overhauls from one version to the next and are now what can be considered somewhat »mature«. There are different components for all kinds of use cases, good documentation, lots of examples, good styling and skinning options, good ways to customize and extend everything, layout management and data binding. Furthermore, there are lots of non-visual components and classes that help you building data-driven applications. It’s a one-size-fits-all solution. Just use the open-source Flex SDK and you’re good to go.
»BUT«, you’re going to respond: Isn’t the proprietary Flash Plugin (that you hate, of course) needed for Flex apps? Yes, Flex applications run in the Flash Player. That’s the way it is…and it has some major advantage: You get a mostly consistent experience across all browsers and operating systems (except for a few performance differences and other minor issues). And you can also build desktop and mobile applications with it. Even though HTML5 and JavasScript may be the future »standard« way of building rich applications, for developers it makes things just much more complicated. Sure, you can already use some of those cool new HTML5 features (canvas, web workers, web sockets, geo location, local storage etc.) in the latest browsers but that usually means having all kinds of JS fallback solutions in place until you can take it for granted that most of your users have modern browsers installed that support all these features (without relying on fallbacks – which will be at some unknown point in the future).
The situation is even worse for mobile development but that’s another topic… Basically, »standards-based« web development is just starting to suck more and more and getting way too complex. You easily find yourself having dozens of different JS dependencies in your project, just for the sole purpose of getting a nice UI, interactions and some kind of MVC/MVVM-stuff consistently across all browsers. VM-based approaches such as Flex solve some of this pain but they’re no silver bullet either and introduce different issues. On top of all that, there’s the server-side/database layer with another set of different frameworks and options. In a typical full-featured modern web application (which is everything more complex than some Hello-world- or How-to-create-a-blog-with-my-favourite-framework-example), you typically have dozens of moving parts you need to manage: Use framework X here, use library Y there and then spend time fixing all arising integration and performance issues.
What’s really interesting about all that is that a lot of all web application development isn’t really rocket science (for rocket science applications, essential complexity cannot be avoided). Most of the time, it’s all about handling simple data transport and syncing with the view layer. But even for those simple tasks, accidental complexity starts cropping up everywhere. So, no matter what tools you use: Today, web development sucks: http://harry.me/2011/01/27/today-web-development-sucks/
Filed under: Flex/AS3, RIA, Ruby / Rails, Software Development
Add a comment
You must be logged in to post a comment.