Today is a good day to code

CSS 3 Keyframe Animations: A Step Too Far

Posted: April 16th, 2009 | Author: | Filed under: CSS, JavaScript, Programming | Tags: , , , , | No Comments »

I understand the desire to push the development of web based applications to the next level, and allow them to truly compete with their desktop counterparts.  I like the functionality with the new perspective properties, keyframe animations, transformations and the like.  For years we enjoyed these features as part of Flash, which could never really figure out what it wanted to be.  Was it a programming environment or some sort of design environment?  We continually had poor tools that we made the best of to do some incredible things, but I think its time to take a step back and look at what we are actually doing, and where web application development should be.

For example, have a look at this syntax for defining a keyframe animation:

@-webkit-keyframes 'wobble' {

0 {

left: 100px;


40% {

left: 150px;


60% {

left: 75px;


100% {

left: 100px;



This is strange in that we are now defining properties in CSS.  This is ultimately a named structure which defines the behavior of a function, that doesn’t exist to, and is not accessible from JavaScript, the supposed language for logic and control.  The problem here is that we have variables and objects that are outside of the scope of the primary programming language.  This creates a second language with overlap, and set of objects that controls and defines data for UI behavior.  So far, the only functional code in CSS is via the pseudo-classes such as :hover which can then trigger the animation or transition outside of JavaScript, but it wouldn’t stretch the imagination to see a future where CSS is doing more.

With HTML 5 we are packing more functional logic into the “structured data” tier of our web applications, which undermines MVC and creates unique problems to developing web applications that traditional desktop application developers do not face.  The complexity introduced by making developers use 3 different functional languages for UI, each with their own data objects, variables, and execution or functional code should not be underestimated, not to mention the complexity of the language they need to use for their application server and its interaction with JavaScript / CSS / HTML  languages.

As more desktop applications are moved to the “cloud” the engineering effort required to build applications approaching the complexity of Eclipse for example would be daunting, and could perhaps be more expensive than developing it natively for each platform.  This is due to platforms becoming less diverse as time goes on through things like Mono for ( C# ), Ruby and Java on Linux, these same things with native UI bridges on Windows and Mac OS X as well.

I don’t really want to see that happen, but for the web as an application development platform to mature, I think these languages need to be consolidated.  Typically in a normal windowing environment, such as Windows, Linux, or Mac OS X, there are libraries that are typically written in C / C++ that drive the UI and access to the hardware.  Previously, a developer would write code to that specific library on a specific platform for performance reasons, and be required to maintain multiple sets of controller / model code.  The performance reasons for doing this today are fading, so abstractions like the Cocoa – Ruby bridge are becoming more prevalent.  This allows a developer to implement most of their business logic once with a minimum of code dealing with specific platforms in the language of their choice.  Most of this code is usually portable to other platforms, including web.

The increasing complexity in web development, and decreasing complexity and homogeneity of desktop platforms / hardware, is setting up what I believe will be a renaissance of desktop style development, or mono-language application development.  I think, however that the new class of desktop / mobile native applications are different than the traditional applications in that their model may be in the cloud with just a data cache on the actual client.

I believe that this approach, having a cloud model with a less complex native client rendering content, represents the best of both worlds.  A robust service based model that makes tables of data accessible to the client, whatever its configuration is optimal for keeping your options open on the UI implementation.

You get the power of the local CPU, a reduction in complexity by utilizing the same language on the back end as the front end ( possibly ), and the flexibility of having the data model in the cloud by writing native clients in Ruby | Java | C++ | Cocoa.  There is a side benefit of being in closer compliance with the MVC pattern that should help reduce complexity and promote code reuse and readability.

Most web developers are doing this today, but they are doing it either by not using HTML / CSS and focusing all of their efforts on JavaScript, and treating HTML as the basic building blocks of a widget approach, building up the “windowing system” themselves, and then using another chunk of JavaScript as the “controller.” Or they are doing it by pre-generating the HTML / CSS / JavaScript on the server, and abstracting it away into their native language ( GWT as an example ).  Both approaches are fine, and they work, but they do not address the increasing complexity of the resulting applications.

I think that the most effective method for solving the problem is, as always, to meet in the middle.  XUL was an early attempt at this, but it still ended up requiring developers to use multiple languages.  What I am hoping to find time to work on is a browser that does all of the existing standards compliant stuff, but in addition to that gives developers a method to use the native windowing system through a scripting language, sort of like using JavaScript to do desktop application logic, but that is downloaded from the server and cached on the client in the HTML 5 manifest method.  The resulting application would use only that language for all UI and logic. The language would be required to bridge over the 3D engine ( OpenGL ), a widget interface that looks like native windows ( could still be web based behind the scenes ), and the sound APIs.  More importantly it would have to handle binary data as native objects and streams.

I think that currently the languages that are good candidates are Ruby, Python, and JavaScript.  Ultimately it would be best if the web application had access to the camera and other hardware with the user’s permission, but I don’t know if that is really required or desired,  Flash currently does a good job of managing permissions around this stuff, but I think more sandboxing is needed for something of the scale I am thinking of.  Microsoft tried it and failed with Active X, which was a good idea, but gave too much access to the local machine.  I’m working on it, but I’m just one guy with a day job, so it takes me a long time.  Eventually I’d like to make it an open source project, but I’m a long way off from it.

To sum it up, I think that for the web languages to keep going the way they are is courting disaster; making CSS more beefy and complicated isn’t a good solution.  Already JavaScript, through the canvas tag, is impinging upon CSS’s supposed territory, but most of this display stuff should have been there exclusively from the beginning.

There is too much overlap between CSS / JavaScript and HTML.  We will be stuck with fail whales everywhere because there are too many points of failure, and too many areas to specialize in.  Even if IE fully embraces web standards the general development pattern will be too complicated to support the pace of development, and the complex feature sets available in desktop applications.  If you look at the cost of hiring a CSS specialist, a JavaScript specialist, and a server side specialist, web startups will be more expensive than desktop or mobile native app startups.  Hiring a “mono client” specialist that can do all of the things that previously required 3 people, it will reduce to cost of application development in the way that AJAX did originally, and keep the the more ambitious web startups viable.  Today for example I saw a startup offering to do video editing through the browser, wow!  The future is super bright for web development, but I think some refactoring is necessary to fuel the next surge of productivity.