Everyone seems to be gung-ho about HTML5 or native mobile apps, and religiously preaching for one approach over the other. Yet, while mobile giants such as Apple and Google battle it out, some companies are already opting for a third option — mediating the two approaches in what is popularly known as the “hybrid app approach”.

Hybrid app development employs native capabilities while also serving as a strategic stepping stone towards adoption of HTML5.

A hybrid app is a native, downloadable app, that runs all or some of its user interface in an embedded browser component. To the user, a hybrid app is almost indistinguishable from a native one: it is downloaded from the app store or marketplace, it is stored on the device, and it is launched just like any other app. But to developers there is a huge difference, because instead of rewriting the app from scratch for each mobile OS, they write at least some of their application code in HTML, CSS and JavaScript, and reuse it across devices.

The term “hybrid” actually spans a wide range of possibilities. Some apps, like the Bank of America, Facebook and Yelp iPhone apps, simply load some pages from their web site as part of the app. Other apps, like the Tower Madness game, include a few embedded pages that are written in HTML. But there are other apps, like Harmonius (a graphical sketchpad) or Logitec’s Squeezebox Controller that have their entire UI implemented in HTML.

From a business perspective, it makes a lot of sense to adopt HTML5 as early as possible. Industry heavyweights have pointed to HTML as the only viable cross-platform technology. Add the rumors about Facebook’s “Project Spartan” (believed to be an app store for HTML5-based mobile web apps), and Microsoft’s announcement that developers will be able to use HTML5 and JavaScript to create applications for the touch-friendly Windows 8, and it almost becomes just a question of “when” companies will adopt HTML for app development rather than “if”.

A primary reason that many companies are not already jumping on the HTML5 bandwagon is the belief that HTML apps cannot access native device features. Indeed, pure mobile web apps (i.e., those that run in the browser – not hybrid ones) are currently restricted in their access to features such as the camera, microphone, address book, and so forth. And while there is work in progress at the W3C to allow web apps to access such device services, mobile browsers do not currently provide such functionality – a key requirement for many innovative mobile apps.

But in the world of hybrid apps, frameworks such as the open source PhoneGap library make it possible for JavaScript code to query the compass, take pictures, find or create contacts and appointments, and tap many other device features that mobile web apps are barred from accessing.

Access to device features is not the only difference between hybrid apps and mobile web apps. Another important difference is that hybrid apps are mostly distributed through app stores: You don’t browse to a hybrid app – you download and install it.

Also, HTML pages of a hybrid app can be transmitted by a web server, but that’s not a requirement. To improve performance, hybrid apps can include a bundled copy of all required web resources (i.e., HTML, JavaScript, CSS and images) so that users will get instant access to them, without having to wait for a web server to send them over.

Differences aside, hybrid apps share some traits with mobile web apps. Unlike pure native apps, which make direct use of the graphics APIs and UI services provided by the operating system, in hybrid apps, most pages are executed by the rendering engine of a browser – much like they are in web apps. This means that, currently, only natively coded pages can achieve game-quality graphics, and although this is less relevant for business apps, you probably won’t be seeing the likes of Ultimate Mortal Kombat 3 written in HTML for mobile devices anytime soon.

Fortunately, the leading smartphones and tablets have very powerful HTML rendering engines, which already support most of the upcoming HTML5 and CSS3 standards.

JavaScript toolkits like Sencha Touch, jQuery Mobile and dojox.mobile are fully compatible with the hybrid app development model, making it easier to achieve a look and feel that is often indistinguishable from native. As a result, hybrid apps running on mobile devices with reasonably modern hardware can achieve highly interactive and impressive user interfaces using just HTML5, CSS3 and JavaScript.

For those cases where your app does require special graphics or system-level interaction that cannot be achieved with HTML, hybrid apps can combine web pages with native ones. One interesting hybrid example is an app by Korean credit card Lotte (pictured below), which has 100 pages written in HTML (reused between Android and iPhone), along with a small number of native pages that implement an augmented reality feature.

Other organizations are developing hybrid apps, while planning to turn them into HTML5 web apps in the future without having to rewrite them from scratch.

From a strategic point of view, development organizations should seriously consider adopting HTML for mobile app development sooner rather than later. The hybrid app model, although not suitable for all app development needs, provides a cost-effective solution for a very wide range of downloadable app types and allows gradual entry into the new world of HTML5 while future-proofing your investment.

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

by João Saleiro

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 http://airgile.com ) 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.

Background

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 ( http://incubator.apache.org/flex/ ) improve? Most likely, yes. In 9 days, there were more than 1.4 thousand emails exchanged on the Flex Mailing List ( http://incubator.apache.org/flex/mailing-lists.html ) ! 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 ( http://tedpatrick.com/2011/11/12/living-in-the-future/ ) , 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.

Knockout.js

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.

jQuery

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?).

SASS

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.

Lab.JS

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.

IDEs

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 ( http://www.jetbrains.com/ )!
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.

Debugging

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.

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. There.are.no.real.classes.in.javascript.
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.

CoffeeScript

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: https://github.com/thinkpixellab/PxLoader

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 ( https://twitter.com/#!/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: http://www.joelonsoftware.com/items/2008/03/17.html

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 http://caniuse.com/ . If you don’t, go there.

Productivity

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.

Conclusions

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

Sencha Ext JS is Viable Technology Choice for Flex Developers

Posted on February 14, 2012 by JesterXL

Below, I describe my experiences with Ext JS after the Sencha Fast Track training, my challenges with doing browser based work in a consulting context, and my thoughts on why it matters to Flex Developers.

I’m in a hurry.

I don’t want a history lesson.

Get comfortable, this is long.

Preface

I had the pleasure of attending a 5 day fast track for Sencha’s Ext JS 4 in New York last week with my partners from Web App Solution. Of the 13 people that attended, 7 were Flex Developers working on Enterprise Applications. Yakov and Victor from Farata Systems were there and Universal Mind had John Yanarella representing.

While the technical future of Flex is extremely bright and exciting, the business and marketing future of it is over. Adobe, with the community’s help, has ensured that it is in the best hands with the Apache foundation. With a multitude of capable, brilliant, and diverse contributors to the open source project, there are definitely a lot of great things on the horizon for the next Flex SDK.

Adobe has also ensured, intentionally and unintentionally, it has a limited future which will ensure Flex is no longer invested in any technical capacity from small, medium, and large businesses unless absolutely essential, or under the radar. The mobile revolution has happened, and while Flash had the opportunity to play a pivotal role, Macromedia, and later Adobe have failed to take the initiative and successfully execute on it.

While there is still a significant business & technical advantage from a design, development, and workflow perspective in the Adobe AIR stack for developing & deploying on Android and iOS, Adobe has made it a clear that they perceive it is an opportunity they are not interested in pursuing on the developer front. This is a huge topic mostly discussed from a technical perspective in the community, and only a select few blog articles got it right from a business one… and even then, those missed it from a technical perspective.

Bottom line, Flex Developers are between a rock and a hard place in the industry right now.

The type of work they do for desktop web applications is different from what Flash Developers do, mainly in team size, project scope, and client base. It’s not as simple as “just use jQuery, and move on”. While the tools & runtime we use are technically sound, even clients who have a technical understanding of the marketplace & toolset will not invest in a perceived abandoned platform. Server-side offerings do not offer the rich client experiences we’re used to creating. The plethora of frameworks in the web market, both open source and proprietary, do not offer the same tooling, performance, and expedient workflow we have on the Flash Platform.

… except Ext JS. Sort of.

As stated by John Yanarella at the training last week:

“Out of all of the web based frameworks out there, Sencha’s Ext JS is the best safety net there is for Flex Developers.”

It has the necessary component framework, a growing company with enough resources & funding at a specific size behind it, with a competent web & mobile technical story that has the potential for critical mass within an Enterprise context.

Thus, given my company’s need to offer my clients an HTML5 alternative to Flex, Ext JS seems to fit the bill. Considering time is at a premium nowadays, the fast track training Sencha offers seemed like a great opportunity. And I love New York so any excuse to go there is great.

Given the whirlwind that was the past 3 months, as well as reflecting upon what I learned from the training, I thought it prudent to write down my thoughts here. There are a lot of Flex Developers who are looking for direction, so I’m hoping this is one for them to follow.

Background

As a Flex Developer faced with a forced career change driven by forces beyond my control based on the infamous events of November 9th, 2011, I had 2 choices. Do what I always did back in my 20′s and dive headlong into the unknown, or let the pioneers get the arrows in their backs as it were. Now that I run a business and am a father of 2 children, I don’t have the free time I used to back being single and W2. Flash & Flex, even on death march projects, allowed me to get up in the morning fueled by the passion of using my favorite technology, and attack problems full bore.

Surveying the landscape, things were pretty grim… even for someone positive like me.

While the iOS stack had a clear advantage with both a growing developer base, mature tooling & framework, and customers who actually paid for content, none of my large clients actually had initiatives around iOS work. Enterprise applications, known for their copious amounts of input needs from the user, do not translate well to the small screen size and lack of keyboards on smart phones and tablets.

As such, while the uptick in service based software shops servicing the needs of clients who need iOS applications has increased, the scope of said projects is not as large and often is more consumer based. The latter is troubling as it’s hard enough utilizing ActionScript 1 in a deadline driven environment that Design Agencies employ; dodging technical debt for as long as possible in Objective C, even with superior tooling is not appealing when longer and more profitable projects exist with the opportunity to have competent peers beside me vs. being a lone wolf. Learning a lower-level toolset for shorter engagements that pay less makes it a non-starter.

Android, while being easier to deploy to as well as more easily iterating with your customer base, is notorious for it’s fragmentation, both programming and design. It’s hard enough for designers to lessen the overall experience via responsive web design to compensate for a variety of screen sizes. You now have developers who cannot turn as fast as designers can and thus have to spend more time on a platform that doesn’t generate nearly as much, if any, revenue from consumers compared to iOS. This doesn’t even broach the business topic of how do you lessen the maintenance cost on your customer when they have to hire both an iOS and Android developer, or some awesomely expensive hybrid who can do both, to handle both platforms. The other bizarre thing about Android is that it is taking the PC approach to competing on price with iOS and continually increasing market share, yet doesn’t seem to be generating the service revenue compared to iOS (ie people who own Androids don’t buy apps as much as those on iOS). Same problem as iOS: Invest in a lower-level technology with massive fragmentation for shorter projects that pay less money… again, non-starter.

The multi-development & deployment problem was what the web was supposed to solve. While native development does give you significant user experience & tooling advantages, it seems wrong to invest my career for applications that my current client base do not target. Every single large client I’ve had treats mobile as either a fun skunkworks project, experiment with no perceived ROI, or as a necessity with the minimal amount of money devoted to it, sometimes taken from another project’s budget ad hominem.

Both don’t bode well for a future career from a consulting perspective in mobile.

While consumers bringing their smartphones, tablets, and technology of choice to work has had a huge impact on large companies, most Enterprise customers still target the desktop web as the main avenue of both B2C & B2B based revenue. While many have made huge and wonderful strides in providing value for their mobile websites, it’s clear many either provide a lot less functionality than their desktop counterparts, or strain at even that.

With large media companies it’s a little different. Studies have shown that tablets are better at allowing consumers to consume content whereas desktops/laptops are better for producing content. While “duh”, having studies like this made and corroborating themselves verifies what we already know. They have a vested interest in increasing consumers ability to purchase and access that content in a controlled manner.

The problem here is that the budgets for those projects doesn’t increase with the needed targets.

For example, while working on HBOGO.com, the initial release of the iPhone app did not allow you to watch videos. The Flex app we did at the time was the only way to view videos. Overtime, it was prudent to support both iPhone and iPad versions. A lot of companies, however, don’t magically get 2 budgets, 1 for the web and 1 for the iPad just because the iPad is so cool. While the GUI’s needed for iPhone and iPad are simpler, you still want to create the same user experience for the customer, especially if they are using all 3 to access their content. The Iron Triangle verifies that something must give, and thus, the scope/functionality/user experience often does.

Investing in a mobile technology where consumers pay less, and larger businesses devote less capital to the same projects doesn’t bode well for investing the smaller portion. If I were back in 2002 still doing design agency work, I’d totally be an iOS developer right now. As a consultant who does more than build software, and who doesn’t see his clients changing their plans, I see no prudent reason to go the iOS/Android device route. …… beyond them being really fun (another story).

Appcelerator, Corona SDK, Sencha Touch, and PhoneGap, technologies which allow you to deploy to multiple mobile platforms with mostly the same code base and skillset, can be lumped in the same bag as native with the above perspective.

Why invest in technologies that offer less money and my clientelle isn’t using?

On the flip side, the HTML5 moniker has taken on a life of it’s own. While not necessarily representing the full JavaScript, HTML, CSS, and associated libraries & frameworks stack, a lot of clients big and small have been sold the bill of goods that it solves the same multi-platform, multi-device problem that the Flex/Appcelerator/Corona/Touch/PhoneGap attempt to solve: single code base, single developer toolset, and multiple targets within their same organization.

I won’t get into the phenomenon that is HTML5. All you need to know of the context of this post is that a lot clients either suddenly think HTML, CSS, and JavaScript can provide the same experiences we can do in Flex for the same price using the same teams… or they know it’s false, but either their Board of Directors or Business Customers force them to use the tech anyway for political reasons that have nothing to do with engineering ones.

The Challenges of the New Platform

The issue, however, is that it’s not that straightforward. There are 5 main issues that the HTML/JS/CSS stack (which I’ll here after refer to as the HTML stack), have when coming from the Flex platform in a consulting context (there are more, but these are the ones that matter with regards to the context of this post). They are:

DOM as a dynamic display technology
JavaScript lacking mature language constructs
There are larger problems for multiple Browser Vendors to solve
the industry’s libraries & frameworks are young from an Enterprise context (yet not!?)
The Video Codec Issues
Tooling

The Document Object Model

The HTML DOM wasn’t made to do the type of applications we do in Flash, more specifically Flex. Flash Player was developed specifically around cross platform visual fidelity with a web bent. More importantly, though, it was built around redraw. This perspective of “frames per second”, and continual improvements around the underlying timing of redraw, building upon what a platform does well, and then abandoning a “new” 5 year old display technology to support a GPU future.

Browser vendors are doing some pretty amazing things with the DOM, from hardware accelerating the display, continuous redraw optimizations, all the while doing their best to follow ever evolving standards amongst our changing technological landscape. …based on a tech designed and created to show text. That’s awesome.

Sadly, the redraw performance isn’t awesome. While a lot of Flash and Flex developers never really got the purpose and value of invalidation in Flash Player, even with a technology created for displaying and animating composited graphics, as your application scales, it’s easy to create a system that redraws too much. Invalidation helps mitigate (usually solve) that problem for 90% of the use cases in applications. In a nutshell, it means you can set properties on your visual components as much as you want to in a single thread and ensure it only actually redraws the screen 1 time.

For browser DOM’s, this is exemplified even with the drastic CSS improvements. The philosophy is to never redraw the DOM if you have to, and if you do, do so on the smallest section possible. Browser toolkits such as Ext JS, Dojo, and some others do this very well. While they have the advantage of browser CSS to help mitigate some of the redraw performance drags, compensating for both past, current, and future browser incompatibility in an easy to use & scalable API shows just how brilliant some of those browser developers really are. Based on what I’ve continued to read, this seems to be getting better although not as fast, nor as widely deployed, as Flash Player did which means the problem isn’t going away soon and thus the need for x-browser, x-platform invalidation continues to be important. Thus, Ext JS’ commitment to efficiently redraw the DOM is appealing.

One thing John brought up at the Ext JS Fast Track training last week was the lack of positive sales around hybrid solutions: using Flash Player and the HTML stack together. If you need to play video or animate/show a lot of composited objects, combining the 2 technologies together.

Hulu and YouTube proved it can work with video and movie subscriptions. Grooveshark proved it can work with music (and video, heh). Google Finance and Analytics proved it can be done with charting. Balsamiq proved it can be done with desktop designer tooling.

Bottom line, things are pretty bad but getting better slowly, and there are mitigation paths that can utilize Flash Player in the interim. Canvas is finally getting hardware acceleration across platforms also making it another another tool to help.

This doesn’t seem to be getting much play, but considering we’re all supposed to magically know a multitude of platforms, languages, and yet have multi-talented sub-contractors that meet that criteria and deliver the projects in the same time frame clearly means that option is also on the magical table.

JavaScript in the Enterprise

Surprisingly for me, JavaScript the language has dominated the discussion the past 3 months in where I’ve lurked in social media circles amongst the Flash & Flex Developers. For those of us who grew up in the industry and our careers with Flash, it came quite as a shock for the industry to fall back in love with JavaScript.

While it made sense for server-side developers to reduce their code size as more logic goes to the client and their servers get faster and cheaper, we’re still a little confused as why the industry isn’t salivating for a statically typed Harmony (resurrected, non-elven remains of ECMA 4).

Most of us Flash turned Flex developers grew up using ActionScript 1. For those who don’t know, this is near exactly the same as JavaScript/ECMA 3. The difference is instead of doing an innerHTML on a div tag, you just call methods/properties on a Sprite. As our projects grew in scope and # of developers, the language started to show its scalability problems. You’d run into more and more null pointers from misspellings, even with better tooling to help provide code hinting. You’d also get errors, but no clue where they came from since there was no common way of handling errors in ActionScript 1.

Furthermore, if you didn’t provide source, the developer was screwed because there was no way to easily introspect API’s unless you read the documentation or source; things like Aptana didn’t exist back then. This also implied, however, that even though there were things that weren’t public, developers would still call them anyway if they didn’t understand your name spacing convention (such as using an underscore (_) prefix for private variables and method names). While Lua and other languages have tricks using closures to emulate access modifiers, this never caught on in the early Flash world. The path for RIA’s at the time was larger projects with larger teams, and thus they adopted a more Java esque method of language development while still trying to match ECMA 4 as best they could.

Finally, loose typing/variants also made it harder (in theory… which has been proven wrong by Google’s V8) for Macromedia/Adobe compiler engineers to make the language run faster than JavaScript.

Thus, the natural evolution was for a strongly-typed language with proper packages and namespaces (or access modifiers like public/private) to help us address the larger applications we were developing. It did. It was, and is, awesome.

…for some. About the same time as I started getting more consulting, I also started noticing a larger awareness to the different types of businesses using Flash and Flex. In the Design Agency world, the majority of the work was 2 months to 2 days, and in between. The teams were often 1 developer; if there were more devs, they both weren’t on the project the whole 2 man months. They hardly ever payed their technical debt (unless you were a consultant with them). You started to see a strange love/hate relationship for a lot of these devs. In some cases ActionScript 3 helped these developers, who were on a deadline and often never paid their technical debt, manage said technical debt with AS3′s improved strong-typing and runtime exceptions with the ability to use loosely typed constructs when needed or in unknown territory.

On the flip side in the Flex world for larger companies that gave a flip about design, and more about feature count, the language constructs were barely enough. Constantly we’d get barraged from developers in more low-level languages like Java, C#, and C++ about why is AS3 is missing this or that (true Singletons, true Abstract classes, threads, blah blah blah), and how do you emulate such features.

It was very clear there was a split was growing. I could elaborate on all the niceties, but suffice to say, the Flash Devs didn’t need all the language features & strict complexity rules whereas the Flex Devs couldn’t get enough. Again, a simplification on the nuances of a thriving, diverse, and changing community, but accurate.

Most of the Flash devs have had little trouble beyond the first 2 hellish weeks of getting immersed back in the DOM, CSS, and JavaScript variant world… only with better tooling and libraries + choices than they had 7 years ago when they 1st abandoned it for more creative pastures.

The Flex devs, however, haven’t seemed to budge en-masse. We have people telling us we don’t need those things in a language, yet when we ask them to show us a large Enterprise Application that utilizes JavaScript, they either are using an intermediary language to compile to it (Java in Google GWT or Oracle ADF, C#/VB in .NET, or CoffeeScript), or just can’t deliver the goods. Same excuse us Flex developers gave the Slashdotters around “show me a cool app built with Flex”: “It’s behind the firewall”.

There’s also a lot of misunderstanding about simple things like OOP. Using Object.prototype for “emulated” classes is what I did for 4 years… I have no major qualms about going back. Ext JS in version 4 abandoned this practice as well. While I grew up with Object.prototype insanity and learned to love it, the debate vs. clsoure/function inheritance vs. Object.prototype rages still. If you care, Keith Peter’s has a good article on the nuances of it, or you can read what I did to learn ActionScript, Robin Debreuil’s book. There are others, but the point here is we Flex Devs expect classes not just for encapsulation, but create organized code with a common workflow to share code amongst many developers. JavaScript wasn’t made for classes, but using Object.prototype or the closure method in a declarative manner works just fine (like ImpactJS or Ext JS does).

While I like Keith’s take and respect his opinion, not having classes and encapsulation won’t work in large teams, often setup to fail at the outset by politics, nor all being Keith Peter’s caliber (me included). The other option to “not working” of course (Goonies never say die), which I’ll cover later, is that it’ll just take longer and/or we’ll accomplish less. The rules of Mythical Man Month, Technical Debt, etc. still apply regardless of language/platform. It’s worse in Consulting when coding software, extremely hard in it’s own right, is the least of your problems.

Compiling to JavaScript

In fact, some are so staunchly opposed to utilizing JavaScript as a serious language to build Enterprise Applications, that they’ve investigated alternatives to compile TO JavaScript using an intermediary language. This has long been the process for server-side platforms with a variety of templating engines out there that make it a hybrid process of injecting data into your HTML. The problem is, they either have a server-side bias, or aren’t ready for prime time in a large Enterprise Scale. Remember, you can’t just be good; you have to have money, a company of decent size behind the tech, funding, and have reached critical mass for your product.

While the reaction was very positive around the work Adobe was doing with FalconJS for those in attendance at the FlexSummit, it was very clear to me it was a science experiment with no hope in providing the needed migration path for Enterprises. The amount of work, resources, and time needed to bring it to Oracle ADF, Google GWT, or .NET caliber is clearly something Adobe didn’t seem willing to devote. That, combined with their clear direction of no longer focusing on developers.

Google Dart seemed like a light at the end of the tunnel. It, too, however, seems to be a science experiment of Google scale. It has all the hallmarks for a bright new project:

Google is behind the engineering effort
has a strongly-typed language that, like CoffeeScript, not only sets out to improve upon JavaScript’s problems, but provide mature language constructs you need in larger applications within the language itself (unlike CoffeeScript’s/Google Closure’s/TypedJS annotations
has 2 compilers: 1 a Flex Developer would use (dartc) and 1 a Flash Developer would use (frog).
is based on Eclipse (good and bad, let’s just pretend the good parts here)
brought on Alex Russell of Dojo fame to take a fresh look at the DOM event API
Cliff Hall of PureMVC fame (multi-language framework used a lot in Flex) made a first version port for Dart.

…yet doesn’t seem a priority since while a web based technology, it still hasn’t reached critical mass, nor does it show any signs of doing so yet. I’m more concerned about the amount of resources I’m seeing being devoted; maybe there are more, and like all things Google, they just don’t advertise it. I really wish I could just parachute drop a Porter & Bogusky contingent in Google someday…

So far, the only contender is CoffeeScript. Here is a video and slide presentation to check out on if you have time. However, Ext JS uses declarative JSON + JavaScript. I have not seen any signs to see if Sencha is interested in porting Ext JS to Dart. Just say it… “Ext Dart” (pronounced “X Dart”); sounds like a dope dubstep ninja weapon, right? You’d certainly get better jokes from non-tech savvy people at parties when someone hears you’re a “Flash Developer”.

The other problem is that you need everyone in your organization coding the same language. In product companies, it is TOTALLY fine to have a technology du jour with Ruby running your builds, PHP running your render farm, and Java running your back-end, but for development purposes on 1 particular platform, you standardize on a language and usually have company ordained standards on it. This is for maintenance costs, and hiring standards, and a variety of other reasons that aren’t just around cost.

If anyone has CoffeeScript running atop Ext JS, let me know how you got your build process setup.

Browser Issues

Notice I’m specifically talking not just about incompatibilities between browsers, but missing features. For example, just 3 days ago Google added weak collection keys into V8 (their JavaScript engine for Chrome). Developing data models with string based keys can be extremely hard for complex model logic. Having a Dictionary (or Object) that can use something other than a String as a key is extremely useful… until you have to remember to kill the key when the object is destroyed. Enter weak keys and queue the “woo hoo!”.

One of the great things about Google’s approach with Chrome is not only is it the fastest updating piece of software that matters in history (faster than Flash Player), but they iterate quickly on features. While we’d wait 18 months for AS2 and then 24+ months for AS3, and in between get language updates… JavaScript is getting that piece by piece. It’s a wonderful thing, but also brings up a larger issue.

What do you today?

You have to do SOMETHING. Given each browser implements different features different ways, and JavaScript’s functional + prototype nature, you can easily (*ahem*) abstract away these problems into a useable API that hides the differences. Certain low level things like maps can be tricky, however, and come at the cost of performance, library maintenance costs, etc.

Fine, no big deal, you just move forward using an Object hash approach. We’ll just wait a couple of projects before maps + Dictionaries catch on in all browsers.

…but what about Web Worker (also known as threads for web developers)? It’s only supported in IE9 while Firefox/Safari/Chrome are good to go. While you can emulate via green threading, this is a FAR cry from emulating the lack of getter/setters in older versions of IE, or even emulating Canvas for Internet Explorer 8 via a VML wrapper. Those work. Green threading is not the same thing as a separate process that ensures it doesn’t lock up your GUI thread. The lack of full browser support will prevent some features from actually working and there aren’t any fall backs that can be utilized.

For some charting/plotting applications, these are essential features: no web worker, no application. Now in Flash, you’d just plan around upcoming features, both those you voted to be actual features, or those you knew were coming down the pipe. One tactic of design agencies, and Macromedia/Adobe in general was to have them launch a high profile app/site/widget to showcase these features upon launch.

If you are to inspect all upcoming features in browsers, not just JavaScript, but CSS, hardware & display related, etc. it really slows down when we expect certain experiences in our applications. While Macromedia/Adobe would drag their feature on certain things like right click and threads, the process was generally the same:

identify a problem you had on projects
bring it to your peers & Macromedia’s attention
rally support through email list/blog/twitter posts/talking to company reps at conferences
make writing & validating the use case easy
get community votes when desperate
await new feature(s) in upcoming Flash Player, beta test if lucky

While this process for Chrome seems EXTREMELY quicker, for the rest of the browser market as a whole, including smart phones and tablets, not so.

My college professor said, “There will always be work to be done.” Unless we use hybrid implementations, clients will just have to live with the slower pace of innovation if they want broad adoption. I guess I’ll live, I’m just curious where my excitement will come from if the toys remain the same, or only 1 browser implements a new feature I can’t easily abstract. That, and it seems a lot of innovative projects will either start to be browser specific feature branches, or just wait for broader adoption amongst modern browsers. It’s sad. And frustrating for both my clients and my team.

Wild West: Libraries and Frameworks

What’s fascinating to me about the JavaScript landscape is how much longer it has been around with a lot more people and yet the landscape with regards to frameworks and libraries is still in major flux on a few fronts.

In the Flash World, there were 2 frameworks that people would use, if ever: ARP and… just kidding, 1. While the tweening libraries got a little out of control, and the component frameworks became pretty niche, overall there was a library for everything, sometimes with an alternative if you didn’t like one particular implementation. A lot were ported from other languages, like Java and C/C++.

Frameworks didn’t really start to rear their head until Flash RIA applications started to become mainstream, and Flex was born. The Java developers coming over didn’t see any common MVC/MVP/MVVM frameworks that allowed them to manage copious amounts of code on the client side vs. middle tier. Cairngorm, PureMVC, Swiz, Parsely, and Robotlegs were born. Cairngorm is still around, but Swiz/Parsely get most of the play in the Flex world with PureMVC and Robotlegs hitting both Flash and Flex.

With exclusion of Cairngorm, all 3 have a lot in common. While everyone somehow manages to make their own implementation, learning one helps in learning another. Additionally, most never made it past a version 2, and even then most of the changes weren’t a dramatic workflow change.

JavaScript is nuts on the framework front. While the libraries themselves are great in that once you get over the burden of reviewing 5 of the same thing, the frameworks on the other hand are all over the map. Some are just query helpers with binding thrown in. Some are actually a certain group of existing libraries with a defined way of working with them, and thus named a framework… even though no code is actually associated with the framework itself. Worse is the versions can sometimes be drastically different. If few in #, this wouldn’t be a problem.

Worse, there are 100 times more people in the JavaScript community with their own opinions on what MVC means. What MVP means. What MVVM means. What the differences are between the 3. Their own descriptions for what the differences are between Passive View, Supervising Controller, and Presentation Model… and sometimes pretending (innocently) that the only thing that exists is MVC, period.

The other thing that is clear is that there are a variety of applications (not progressively enhanced websites) that are done with JavaScript, and thus each framework targets that particular version. For example, PureMVC and Robotlegs have Mediators which make it easier for the View (what you actually see) to change a lot during the project, yet still keep its ability to get it’s data without race conditions, and have it produce the necessary user gestures through Events. Swiz on the other hand, had a Presentation Model injected into the View, and you had a nice API the View could call/get it’s data from. A lot of Swiz guys I talked to NEVER used the states features in Flex 4… nor saw the point. GUI changes didn’t affect PM API, they weren’t complex enough that you had to use mock interfaces for the PM’s to test View’s in isolation… so for this group, it worked well. In retrospect, this was a nice, natural evolution that happened.

I’m seeing the same thing in JavaScript, but it’s massively larger, and a lot of times you’re cherry picking either a specific feature of a specific library to be used with other ones, and you’re settling on a version. The last one is worrisome from a consulting perspective. When dealing with clients, Technical Architect/Directors want to ensure whatever framework you settle upon has good online documentation, you can hire people who know it, and it has a future. Using the same metrics I use to do so for frameworks in the Flash/Flex world is a little harder; just because its someones side science project doesn’t mean it’s not immensely useful, nor easy to learn.

The other challenge from a consulting perspective is leaving clients with work that they can support… or my firm would even want to get involved in. For example, there are copious reasons Ext JS 4 moved away from Object.prototype modifications. If you adopt a Ext JS 3 project from a client, you now adopt those problems even if you didn’t write it. With Flex projects, you eventually learned what problems there were from porting a Flex 2 app to 3, or what parts of mx were supported in Flex 4, and could find blog posts covering these challenges. With JavaScript, I’m finding a hard time finding commonality between the stacks that different companies are using.

I. Do. Not. Want… to be a non-Enterprise TA right now. Holy fish. Like, it’s 2008: “Yes, we’re using YUI version 2, it’s rad, has a large company backing it, and we can hire for it.” It’s 2012, and you’re either a jQuery, Sencha, or Dojo kid… oy vey.

So far, with the exception of Ext JS’s MVC implementation, it seems to have all of that solved in version 4 as best it can with the ability to have your own libraries added in with your own modified build process over theirs as well if you see fit to do so.

Video Codecs

No one has solved the codec problem yet. This is where HTML5 video just doesn’t work as advertised. I won’t go too much into this topic as for Enterprises, you’re usually more concerned about VOD, DRM, multicast and live streaming which Flash owns for desktop and HLS owns on iOS. More info about the WTF here and the OMG here.

I only bring it up because it’s just accepted in our world that video and compositing of it + assets is expected in our content, yet now… it’s not. Good designers can make it work, but the point here is from an integration perspective the cost of integrating that content.

Tooling

Lastly is tooling. While Aptana makes an attempt, it seems that Microsoft’s Visual Studio is the only IDE that seems to take web development seriously for those building large applications. Since me and a lot of people I know in Flex development use Mac’s, it seems our only alternative is JetBrain’s WebStorm. Granted, they have other flavors of their IntelliJ IDE, but without commonly expected functionality like code hinting, intelli-sense, and re-factoring, it’s hard for use to take web development seriously.

There is a huge productivity cost that people seem to forget when you move from Eclipse/IntelliJ with those features to Notepad. When you have multiple developers, that time spent adds up, as does the lack of accuracy on your team’s velocity in solving issues.

In 2004, a lot of Java Developers tried out Flash. They then left. Adobe then created Flex. Some came. When Flex 2 came out, the runtime worked, the language worked, the components worked, but more importantly, the Eclipse IDE at the time… worked. The refactoring was, and still is not the best compared to IntelliJ and Visual Studio, but it’s enough for them to take it seriously. That’s when they came en masse, and peeps like Bruce Eckel were like, “Flex is good stuff”.

Going into an Enterprise and telling developers they are no longer allowed to work on Enterprise software with intelli-sense and code hinting isn’t going to work. Thankfully Ext JS is working with a few tools vendors, and some, like WebStorm, can be customized to improve the hints you get, including on your own code.

At the end of the day, we Flex Developers are concerned about the overall reduced project velocity & resolution prediction that comes with losing static typing (“What and where is the problem and when is it going to be resolved?”). For smaller projects with smaller teams, I guarantee you the point is moot. In doing both, if you CAN do both, dynamic languages are so much faster and fun to develop quickly, and flexibly in. For 18 month, multi-developer teams on code that’s alive for 5 years, it doesn’t.

Introduction

As a business owner, we have to meet the needs of those clients that have adopted the HTML Stack, or feel they need to and cannot be convinced otherwise. In the following article I’ll cover what Ext JS is from a Flex Developer’s perspective, why you should care, and some conclusions on how using it + Flex changes our business for the better.

As I mentioned before, the events of November 9th, 2011 shook the Flash & Flex world to the core, and I had 2 choices: figure out where to go, or let other key members of the community figure it out.

I chose the latter plan: play Skyrim and disappear for 3 months to let it all shake out. If things hadn’t been figured out by key members of the community, I’d just figure them out for myself. It’d also be around the same time as Groundhog Day: If the Flex community saw their shadow, and freaked out, I could come out and help them weather the longer winter.

It’s been 3 months and so far, it seems all the Flash Devs went jQuery/Backbone (or Angular) whilst the Flex Devs are debating between Dojo and Ext JS (pronounced “X Jay S” if you’re French Canadian) (yes, I tried YUI and left just as quickly). After talking with members of the community and doing some of my own research, it seems Ext JS is the right choice for the type of work I do. Like using Flash vs. Flex, it’s clear it may not be the right choice for you. If you’re a Flex Dev doing large, multi-developer projects, I’ll bet it IS the right choice. Read on.

What is Ext JS?

Ext JS is a component framework for building web applications atop JavaScript, HTML, and CSS. It’s made by a company called Sencha who also makes a mobile version called Sencha Touch.

It’s attractive to Flex Developers because:

It has components. Lots of components.
It has styling and theming features.
It has a Model architecture built around data store & server CRUD operations.
It has charting components that do not utilize Flash Player (for good and ill)
It has awesome item renderers for grids.
It has classes for JavaScript with inheritance.
Layouts with Containers
Standard Focus Manager
Core Library with DOM helpers as well as JavaScript language extensions
A big company, with investment, and tons of docs who’ve adopted a prescriptive MVC framework.

There’s a lot more, but that is what we Flex devs actually care about.

How’s it work?

Ext JS is a framework; a collection of classes, 3rd party technologies, and a prescribed methodology for building web applications. HTML is used to show the components. CSS is used to style and modify interactivity. JavaScript and declarative JSON is used tomake things appear and work.

JSON, traditionally used by Flash and Flex Developers for data transfer, is actually the main way you code Ext JS, similar to how MXML makes up most of your GUI in Flex. Since JSON itself can be written in a declarative way, this is usually the core of how you define a lot of your application; both GUI and data. This JSON + JavaScript is interpreted to create classes, components, and listen to event handlers. Internally, the Ext library will redraw the GUI as necessary, whether that’s modifying CSS styles on the DOM objects that visually represent them, or swapping out innerHTML wholesale.

You include a javascript library on your HTML page, code some boostrap JavaScript/JSON on the page, and voila, you have an Ext JS app. It can be as small as using 1 or 2 classes from the Ext JS library, to a full blown application that uses their components, their model classes, their MVC, their default module loader, their implied CSS abstraction layer, and their build system… up to you how much you want to use.

Prescription & 3rd Party Integration

Sencha has to walk a fine line with Ext. From an Enterprise stand point, they have to lay the ground work for a prescriptive way to utilize their technology. You need to make a framework easy to work with, have good documentation, and not be too flexible that developers can all go their own way. This allows larger organizations to hire/cross-train easier, have those developers actually be successful with minimal investment, and basically ensure any skillset “knows how to build an app”.

It’s a sales pitch, yes, but it does need to try to work like that. In reality it never does, hence consultants like me existing, but that’s not the point. You don’t want many different ways to skin a cat from an architecture perspective. It’s fine if you cuddle your brackets, use TextMate to code, and prefer Mercury over Git… it’s not fine if you prefer MVVM over MVC, want to be intimate with the DOM, and the other developers in another part of the company on a companion product don’t. Unlike Design Agencies, Enterprise companies do have to pay their Technical Debt. In fact, I’d argue they pay more than they should, compensating in a bizarre karma like way for Design Agencies who get away it. You want to mitigate this problem by making something easy to use, easy to hack, but prescriptive enough that if you don’t know any better, you won’t cause undue costs down the line in the way your team built something.

JavaScript, currently, is all about libraries, more so than Flex and Flash was for a variety of reasons. Namely abstracting browser differences, abstraction over new features with fallbacks, and the sheer number of developers from a variety of backgrounds. Each company is going to use different libraries merely based on the number of library choices out there. The same goes for internal projects. A lot of companies have their own internal libraries utilized on products for their business, whether B2C or B2B. You need to be able to integrate with these in your native language.

Sencha needs to support prescribed direction in how you build web applications with the ability to support 3rd party libraries.

There are a few things they’ve done to facilitate this. Here are a few that matter.

First, they’ve abandoned Object.prototype as of Ext JS 4. If you’re a Flash Developer, you’ll remember having your language suddenly act different because some developer or 3rd party library overwrote a core property/method in Flash, and suddenly your entire application worked differently… or it only did it sometimes because of later loaded class. Unless you knew what you were doing, these were nearly impossible to debug since the documentation stated a method did one thing, but clearly during testing did another. Even if you did know what you were doing, there aren’t many language, nor tooling facilities to help you debug this inheritance mixin whackness.

Considering JavaScript library inclusion amounts are significantly higher than say Flash or Flex, the risk of collisions are higher. On multi-person teams across an organization, with already strained communication this can be horrible to try to resolve.

Also, from a module perspective (those of you using PureMVC multi-core or many Robotlegs Contexts will get this), you need to sometimes run may applications in parallel on the same page. Not having to worry about stomping on someone’s method/properties is a nice feeling to have.

Second, they’ve commited to bootstrap.js their own bootstrap.js from a library/module perspective which supports both debug and production mode. With the build process, this allows you to develop with new classes on the fly, and in production mode actually have 1 file for you’re entire application. This is for speed & ease of development purposes.

We take this for granted in Flash/Flex where all our classes are included, and zlib compressed in a minified bytecode format into a single SWF file.

Remember, Day 1 of Flash Development had 1 SWF. As a binary format, everything you needed was right there for you, ready when you started. The HTML stack was different. Everything is a bunch of files all loaded at different times from different places. As a coder, you know this is a nightmare to figure out. From a networking perspective, initiating a lot of HTTP requests to the server and downloading them in parallel is also slower. So JavaScript has a habit of allowing you through build processes to put all of your classes into 1 massive file to help alleviate the race condition pain as well as improve performance, compression, etc. However, during development or when building modules/lazy loading, you still need the option to load on the fly.

Third, their MVC is prescriptive. I won’t get into too much detail because as a Swiz/Robotlegs aficionado and PassiveView h8tr, I already want to use my own or Angular… anything but theirs. That doesn’t matter, though, the point here is that they’ve provided the built in mechnisms, it works great with the framework, and they have documentation on it as such. This ensures organizations take them more seriously, have a chance to at least be forced into some known structure, and you as a consultant have a chance of understanding how they did things if you come onto an existing project (assuming they didn’t just use Ext JS for it’s query syntax and get all intimate with the DOM… which you can do if you wish).

That’s Great, Show Code

Here is some Hello World code:

As you can see right off the bat, closures are the word of the day. Ext JS is full of either closures (anonymous functions or variables that equal functions) and/or JSON. You’ll intermingle both a lot.

Components

Components are the main reason most Flex Developers dig Ext. Not only are there are a lot of components, but some of the ones they have are better than their Flex equivalents. And this, folks, is one of the reasons why software developers often tell you to try another language or platform, at least 1 per year. You’ll see what the competition has, and YOU’LL GET PISSED OFF!

Why didn’t Adobe build this level of components for Flex? Why does Django, Rails, Coccoa, and countless other frameworks have a Model with optional Facade on top to support offline storage with online CRUD syncing out of the box… and Flex does not? How come our DataGrid didn’t come with built-in paging?

Enough ranting, check them out yourself (scroll down, check out list on bottom left) while I cover a few here.

T3h Über Grid

You’ll notice right off the bat their DataGrid is pretty bad ass. Three things I want to point out about it.

Notice they have paging built-in. This is, in part, to their Model/Proxy/Store setup. In Flex, you had to code this yourself (don’t get me started on Blaze DS/LiveCycle).

Notice their filtering actually has a GUI with a drop down menu to customize (and which YOU can customize) on how to filter the data. No server trip needed. Hot.

And finally… “row editing”. Yes, an entire row can be modified. You can also allow a row to be edited, but only allow certain columns in that row to be edited, as well as customize this renderer. Awesome, right?

Charts

Charts, like Grids, play a central role in a lot of financial & insurance software. You see the data in lists and you visualize it in charts. Ext JS 3 used Flash, but now they use SVG (and I think VML in some cases) and no canvas. This ensures it’ll work without a plugin. The downside is you can’t print yet. They’re working on it, and there are a lot of server-side plugins where you can easily wire up the chart data to a button to have the server assemble a PNG or PDF for you to print so solutions do exist.

You’ll notice, too, that they are interactive. You can customize a lot of their display + tooltips I believe to degree using templates (I’ll go over that later). They also have the standard animation built in as well. From a sales perspective, these charts + the grids demo very well.

While we at WASI have our own Dashboard, it’s nice to know you can accomplish the same style of application and product using Ext’s components to create Dashboards.

Everything Else

Everything else is what you’d expect your team would need from Tabs to layouts to forms. The layouts are a little tricky if you’re not a CSS/DOM savant, but again, they abstract a lot of that from you (including that weird IE vs. the rest of the world padding measurement insanity).

There are a lot of little innuendo features too that make a big overall difference like all windows having the capability of being resized with a resizer, from all sides.

The components all have the standard DOM interaction events usually abstracted away so you just add an event handler for it, and you can create your own as well.

Yes, they have drag and drop.

Yes, they have a variety of ways to handle state, both in components and within your application itself.

Their drawing package uses SVG I think… not really sure why they aren’t using Canvas, but I’m sure they have their reasons.

Localization & Accessibility

They have localization and accessibility built in. I had some concerns during the fast track course because it seems the localization requires the application to be totally reloaded just to have text changes take effect. Meaning, there aren’t default framework bindings to a resource manager like you do in Java or Flex.

Either this was a bug or we couldn’t figure it out, but bottom line the components built into Ext JS do work with it, and you can see their text match the language; we just couldn’t get this to work at runtime, only compile time which is fine.

Event Model

Just a quick note on the event model. In Flash Player, we have the standard ECMA event model in terms of capture, target, and bubble phase. Since IE is backwards from the rest of the world and is in the minority camp, Ext JS flips it around and gives you their own Event class as well.

They key difference, however, is that interaction burdens are put on developer, much like Corona SDK does in Lua. If you want to handle an event, you need to return true to ensure it doesn’t bubble up and get run. I’ve seen other frameworks which just code gen the event.stopImmediatePropagation() and event.preventDefault(), but not here… and sometimes you need to return true from event handlers vs. calling the event methods. I haven’t figured out yet where the consistency is.

Anyway, a small thing, but good that they abstract the browser differences for you and provide a common event class + mechanism for you. The addEventListener and/or callback way of doing things will be extremely familiar. I believe they have an event bus, but it’s not like Robotleg’s Actor or PureMVC’s Notification system.

Styling & Theming

If you know CSS, you know how to style and theme a Ext JS application. Yes, that’s it. I unfortunately didn’t get to see, nor play with, a lot of the skinning in the Fast Track, just styling. I’m not sure how much of the image issues in various browser they abstract away since you’re using your own CSS styles.

Ext provides some template theme CSS files for you that you can modify, both built in classes as well as Ext JS ones. Combined with SASS/Compass, this really makes things a lot easier to handle. If you’re not familiar with SASS, there are just 4 things you need to know:

You write 1 CSS style, and it’ll generate the browser/vendor specific ones if any (1 line of SASS could be 3 lines of CSS)
You can utilize variables in your SASS code which helps dynamically create the appropriate CSS (like determining width/height on the fly, etc).
They actually treat it like css CLASSES… so all the inheritance feels like inheritance vs. some “I’m not really code, but I’ll pretend I know what OOP is”
SASS files get generated through Ruby’s Compass into CSS files for your project. You don’t write CSS; you write SASS and Ruby’ll regen the CSS for you.

Models, Proxies, and Stores

Most Flash and Flex projects I’ve worked on have some form of Value Objects (classes that hold data that represent a server-side entity with additional data the client needs), Models or Proxy classes that allow the client retain data and state, and service classes that form the basis of the CRUD operations with the server.

In branching out into other languages/frameworks/platforms, it’s clear most have a large sub-system and abstraction layer upon this setup. Django has Model, Rails has ActiveRecord (or did… been awhile), Coccoa has CoreData (amongst other things), and Java has all sorts of things. Even with the large influx of Java, Flex never really got that kind of abstraction unless you went with the full Blaze DS / LiveCycle stack. It was abstracted away enough that you could build both non-Blaze/non-LC apps and not know the difference, but the point is that it was clear Adobe didn’t think that was a core part of most apps, or rather that particular part could be monetized in Enterprise only offerings.

Whatever the reasons, it’s a core need in a lot of applications nowadays. I need to persist data in RAM, on the client cache (whether SQL or cookies), and with the server. Using a Facade or Proxy to make this part not only easier, but allow client side validation, as well as being built into all components, is a huge win.

All you need to know is it’s like an ArrayCollection that can save both locally to disk as well as sync with the back end as well as work as a dataProvider to all your components. And yes, when the dataProvider updates, Ext JS will update your GUI controls. Yup.

Sencha has specific meanings in the Ext world between Model, Proxy, and Store so don’t necessarely think design pattern as each is completely different than the other.

JavaScript and Core Classes

While Ext JS primary value to Flex Developers is their component framework and browser insanity abstraction, they also have a plethora of helper/utility classes for JavaScript, CSS, and the DOM as well. You can actually just use Ext just with the DOM using their DomHelper, DomQuery, and your own JS stack if you wish as their helper classes alone are nice to have. Some of it is open source, not sure.

You’ll notice they actually have a layer over top of low-level functions of JavaScript like apply, they have their own version of Delegate (yeah, remember that bullshit? LIVE IT LOVE IT SUCKAZ AND THANK STEVE JOBS FOR IT), as well as a rudimentary binding syntax.

They support inheritance and package names for your components. Although I’ve never done Ext JS 3, it’s clear they are constantly improving because the syntax in 3 was nasty compared to 4.

Templates

I’m still learning about the world that is HTML Templates but suffice to say there are 2 main uses in Ext JS.

The first is custom components. Creating custom components in Ext JS is pretty straightforward; you just extend Component or Container, similar to Flex. However, they’re creating the DOM for you. What if you want to create your own HTML elements based on some strange PSD/AI design comp the company Crayon Pusher sent you? You can create your own HTML and have the data actually bound into it through a similar binding syntax we’re used to.

The second is item renderers. Any type of list, whether a small Container, or an actual component within a DataGrid itemRenderer can use a template. This allows quick creation of an itemRenderer without having to write a lot of code if you want to. Pretty sick.

MVC, MVP, MVVM, Your Mom

I’m not going to go into their MVC too much. Suffice to say, they like the Passive View and have no qualms with a Controller managing multiple Views (at least, that’s what the Fast Track implied, but they don’t have time in those types of courses to show you all avenues). Worse, their naming scheme assumes you have a flat file structure, so you don’t name something “MyModel”, just “My” because they’ll append a name to it anyway causing it to be MyModelModel. That, and I fail to see how a flat directory structure of model, view, controller will scale to an application of any reasonable size, even with Ext ability to use string namespace aliases to refer to your classes.

Keep in mind the instructor was only given 1 day to show 1 way to do MVC, and we didn’t get too much time to dive hard core into the internals. It was clear, though, none of us liked it, and already Flex 1 era framework ideas were churning to bring our ideas (and biases) to Ext JS.

What Sucks

Built on JavaScript, not CoffeeScript or Dart
They have horrible naming conventions for optimization purposes that no longer matter in todays world.
Tooling

The top of this post covers my major concerns about JavaScript for applications of this size. I’m not worried about performance, just team velocity compared to ActionScript. In my experiences with Lua and ActionScript 1, your velocity in the beginning tends to be faster, but you hit a plateau and the lack of strong-typing annihilates your teams velocity and ability to project accurately. Unit tests help, but are more of triage vs. a tool.

The naming conventions are bourne of an era no one should care about but they still do. We’re in a gray transition as browser makers bring the HTML Stack up to speed to build applications, so you can’t just full stop ignore all the lessons learned.

However, I’d argue, as would countless others, that code readability trumps performance concerns. This goes way beyond “premature optimization is the root of all evil”. On extremely large code bases, verbosity is a virtue. You want readable code that it is easy to understand, both for your team and for yourself.

Because of String lookup costs and the ability for JavaScript minifiers to only compress none-reserved words like “this”, countless techniques are used to obfuscate the code to compensate. That may have mattered back then, but it doesn’t matter now. Worse, though, is that the counter justification is that for larger code bases, you do in fact need to make every optimization you can which in turn I counter double fold:

Readable code trumps performant code.
If this is such a concern, why are we using this over Flex again?

More importantly, however, is for API development. API’s are given to people who you sometimes have no contact with, nor have any clue about their adeptness. Thus, you need to make it as easy and obvious as possible. For an Enterprise framework such as Ext JS, you’d think this would be top priority. It’s clear Ext JS has some highly experience web developers involved in developing the API. I respect their knowledge, but it’s time to change.

Examples include Ext.getCmp vs. Ext.getComponent, Ext.getEl vs. Ext.getElement, and baseCls vs. baseClass. It’s prevalent throughout the framework, and mixed in with good verbosity… which makes it worse.

Ext JS 4.5 clearly needs a name overhaul if they expect senior programmers to take it seriously. Considering it’s JavaScript with Ext JS’s alias support, you’d think this would be easier to do.

While Ext Designer completely blows away Adobe Catalyst, it still has some issues with regards to the code generated and code round trip/merging. While looking nice, the results are not always being correct. We had easily duplicatable issues where the code generated did not match what was in the IDE GUI. Still, an extremely useful tool for generating a lot of the needed visual component code.

Finally, the lack of out the box code IDE is a near deal killer, at least for strict TA’s we deal with at large organizations. I know Ted said they’re working on it. Without things like intellisense and code hinting, you’ll make it hard for people to take things seriously, as well as making it harder to learn for more traditional programmers who suddenly have none of their mature toolset available… like… Java Developers… who came to Flash… and left… and… then they created Flex Builder…

Critical Mass

It seems Sencha has all the hallmarks for success and reaching critical mass with Ext JS. This is the ONLY reason I and others have given them any attention. As previously mentioned, you need a mid-size company, with money, and a good product to have it adopted as a targetable platform for large organizations. Sencha seems to have all 3. That, and again their components are pretty cool.

As a consultant, their components, charts, Ext Designer, and website all demo nice as well making it easier to sell as an alternative to Flex.

Mobile Story

I won’t get into much here, but suffice it to say I’ve yet to see the mobile revolution impact our clients as much as it has impacted the Design Agency sphere. While both focused on consumers, for a lot of brands, smart phones and tablets are seen as a growth market, or the ONLY market, to reach certain demographics. All the statistics point to both the behavioral change of society using their devices to interact with the digital world vs. computers, yet those same statistics also who the desktop still being the leader in PRODUCING that content that the world consumes. Yet given that, the money doesn’t seem to be flowing in lock step.

As such, most initiatives have been “it’d be cool to blow some money on”, “we have to provide something for iOS, even if it’s crap”, and the most common “wait… this won’t make any money”. While I know there are a lot of device work going on out there, it’s just not in my consulting sphere, or if it is, it’s at a extremely low profitability area and thus not worth investing in.

For now, the same large interfaces that we make on desktops do not transfer at all to smart phones nor tablets. Just like how people started to taking their iPhone’s to work, and companies stopped installing company phones, and later with Macs so companies started offering Mac’s as well as PC’s… so too will this have to happen with tablets before large companies even have it on their radar as a focused set of initiatives.

Obviously this is dependent on industry type, but we’re just not seeing it in the financial/insurance area, only slightly in the media company area (which I might add are the only ones who seem to care about Android).

…but let’s pretend it DOES matter. Let’s say a Director wants to know your mobile portability story? What do you tell them?

With Flex it was pretty straightforward: 60% to 80% of your Service and Application Layer code could be ported, with no change, to have the same Flex desktop application work on iPhone, iPad, Playbook, and Android devices. The missing piece here, is the device’s web browser.

While I’m a huge/firm believe in a long term native future for devices, there are still many use cases when a consumer is in a hurry and hits a company’s website expecting it to work. Considering some Operators only allow some applications to be downloaded over Wifi vs. 3G, this makes the website more important since even 3G can act as Edge. If you’re a business traveller, regardless if you’re on AT&T or Verizon, you know exactly what I’m talking about.

2 key examples include Marriott.com and PapaJohns.com. I encourage you to play with both on your iPhone/Android’s web browser. You’ll notice they try to duplicate the native look & feel paradigm. “It works like an app!”. Sometimes it works, sometimes it doesn’t. The responsiveness is the first thing you’ll notice that falls on it’s face. Apps just perform better, and consumers can tell. At least for now.

That’s not the point, though; notice how the functionality they need is forced to be simple because of the screen real estate being so small. There are a lot of use cases where even just a company mobile app is needed for its Desktop equivalent. Other times, you really do want to get as much information as possible from the user (a la Papa Johns). To me, Papa Johns is the perfect example of an application that an Enterprise would want on a phone, then they realize at the design/analyze phase/outset that most funtionality couldn’t be done, but shove in as much as they could anyway.

If you’re forced to comply, what do you do?

You use Sencha Touch.

Now the same story applies like it did in Flex with 1 key differnence: Using PhoneGap, you can now target everything. All devices including their web browser, all while sharing 60% to 80% of your Service and Application Layer code. In theory… I’ve heard a lot of negativity towards Sencha Touch v1, but apparently v2 is a lot better, haven’t investigated the code yet, just testing the components on devices.

Pretty cool, huh?

Conclusions

If you haven’t read João Saleiro’s article, and you’re a Flex Developer, I encourage you to do so. I’ve reached many of the same conclusions as he did. The comments also have a lot of good info as well. The most important being team velocity. Time is money. This isn’t important to just large companies, either.

There are a lot of things we can do better and faster in Flex for large scale applications. It doesn’t matter, however, for 2 reasons. First, while from a technical perspective Flex’ future is bright, from a marketing and business one it’s over. The next 5 years are the sunset. Like FORTRAN and Cobol, companies invested billions, and those applications that run parts of their business don’t magically disappear overnight. Second, even if we know it may be a better solution for some use cases (many objects like Visio, highly dynamic interactions w/many redraws, compositing images & video, etc), we’re ultimately beholden to what our clients want, even if we know what they need is different. Thus we have to do both: Flex and Ext JS.

Based on all of read and seen, next to Dojo, Ext JS is the best solution to utilize for HTML5 web application development if you are a Flex Developer dealing with large applications and teams. Their components, documentation, mobile story, company size, and growth show that they are close to reaching critical mass where it can be adopted by large companies as a viable product to use for things traditionally done by Flex. Additionally, a lot of what you already know carries over to Ext JS quite well. If you’re like me, you just need to freshen up on your DOM and CSS knowledge, and re-examine JavaScript with fresh eyes compared to the AJAX revolution bs of 7 years ago.

Furthermore, unlike other server-side solutions, Ext JS lends itself quite well to hybrid solutions with Flex being used for certain use cases and the HTML stack for others, all on the same project. You and/or your firm having the capability to provide both is immensely valuable. Utilizing Sencha Touch and PhoneGap, you now have multiple mobile options in your tool belt as well.

For the record, I still believe using Ext JS will take longer and have a harder to track velocity compared to using Flex. That said, I’m still diving into Ext JS with a positive attitude.

Good luck!

Te original article is available here:

Geoloqi launched its location platform today, offering developers and business customers a complete stack of geolocation tools, including geo-fencing, messaging, security and analytics. The start-up created by Amber Case and Aaron Perecki is designed to help developers enable persistent background location tracking that can incorporate location information from cellular networks, GPS and Wi-Fi. And it does it in a way that’s very battery efficient, attacking one of the key shortcomings of other location tools.

Read more ..

http://gigaom.com/mobile/geoloqi-helps-location-based-services-take-flight/