FOLLOW US
Reinventing the Wheel? Introducing Wheel.js
For the past couple of months I have been focused on mobile web application development — almost exclusively front-end work. When we started work, we thought for sure there was a framework that could help us through the usual grinds of front-end development, allowing us to focus on our app logic. We looked at heavy-weight champions like Sencha. We looked at the fly-weight jQuery Mobile. We looked at collections of tools: Backbone + jQuery + Mustache. What we started to realize is that as much need as there is for a framework that met all our basic needs, there wasn’t one that we were satisfied with. As a team, we were disappointed. As a tinker, I was inspired to build my own wheel.
The Problem Space
Until 2007, jQuery did a lot for developers to ease the pain of normalizing development across different browsers. In 2007, the iPhone came out with an amazing touch interface. Because Apple wanted the mobile browser to just work, they helped convert touch events into some expected browser events, like ‘click’. While this meant that iPhone users were able to browse the web almost like they did with a mouse on desktop, it also meant that providing a specialized mobile touch experience has not been critical for web developers. Analytics show that more and more browsing is happening with these specialized mobile-micro-browsers. The websites who optimize for the mobile experience win users.
Other than touch events, there are a variety of issues specific to mobile web. Here are the biggest ones:
- Connectivity cannot be assumed
- Bandwidth significantly reduced
- Reduced real estate.
None of these problems require a rocket science solution. On the other hand, using a desktop framework and applying afterwards a mobile software shim is not going to address these huge differences. In most cases, this approach will degrade mobile performance. On the time and money topic, cobbling together a set of tools for each front-end app means lots of (unacknowledged) time devoted to concerns other than app ‘business’.
The Dream Space
There are an infinite amount of possible solutions to the problems of a front-end framework that takes into account the mobile web. Recently, I gave a talk at BlazingCloud about Wheel.js and the first thing I said is that we should all be trying to develop the right framework, because one does not yet exist. The world is ripe for a solution. With that caveat, I want to talk about my own dreams for this solution.
Big picture: The first thing I want is for the framework to be easy and intuitive to use. When I came across Rails in 2006, I had been building mini-MVC-like frameworks for clients in various languages. What made Rails a clear winner when I first saw it was how approachable and easy it was. I want that on the front end. That means there are intuitive defaults that I don’t need to tinker with unless I want to customize in some way. When I reach that customization need, I want it to be easy. For me that means that it is object oriented.
Related in some way to ease of use is the notion that the ‘View’ is king. A lot of frameworks seem to be duplicating server-side MVC on the client with huge emphasis on the model. While I want models that spawn events and talk to the server, the model concern is less critical than managing my views. Client-side applications have more in common with GUI MVC development than HTTP server-side MVCs. The thing I am calling a ‘View’, might be called a controller in Cocoa Objective-C land. In server-side MVC, I am not sure it exists. In this king of a ‘View’, I would like the concern of where the DOM is generated to not be a concern. I want it to be really easy to switch between server generated DOM to ‘View’ generated DOM. Why? When some of the DOM is delivered with the initial page load, the user has the experience of content availability more quickly. In other situations it makes clear sense to render the same DOM on the client. The ‘View’ should be able to be the king of all such situations, with very little change to the code.
Mobile First: I want a framework that is built with mobile concern addressed first and not as an add-on. That means there is an event layer that normalizes touch and mouse events while make gestures listening easy. It also will mean that file sizes are small and that there is a stepped loading process. Files will be conditionally loaded as needed. There will be a base layer delivered quickly that knows how to load the remaining code/templates/CSS while also giving the user visual feedback that something (or everything) is happening.
Outgoing requests also need to be managed differently. The application structure needs to monitor connectivity and send out requests when connectivity is available. That will mean storing a request queue, and allowing the application to continue functioning offline.
Widgets: JavaScript widgets have a lot of the same problems that I have seen with CMS style apps. Initially there is an amazing velocity payload. Then developer’s spend all their time working around the CMS. So, my icing on the framework cake would be an optional library of widgets that are useful but flexible. If they have a theme, it usually gets in my way. I would love a scaffold style basic javascript functionality that can be overridden and customized via their object-oriented flexibility.
Wheel.js
So, I am trying to build my dream. You should build your framework dream too. Or you could just read along and play.
The repository is on github: https://github.com/baccigalupi/wheel.js
Here are the slides from the presentation I gave this week:
Some of what I have created is original, but most of it is cobbled from other tools. That may sound like an irony given my earlier railing, but the point is to cobble a framework together once, not once per project. Here are some of my inspirations and/or open-source theft sources: