Mobilize.js versus responsive web design (RWD)

Mobilize.js versus responsive web design (RWD)

Both mobilize.js and responsive web design offer solutions to having a mobile and desktop site from the same codebase.  This is a comparison and evaluation of the 2 approches

mobilize.js rendering
I previously blogged about mobilize.js and how it can be used to transform a website dynamically between a desktop and mobile-enabled site.  As a brief background, mobilize.js is a javascript library that detects if a mobile browser is being used and, using client-side javascript, and re-renders the page using predefined
mobile-optimised css.  However mobilize.js is no longer being developed - the developers now recommend using responsive web design instead.  In one of the comments to my original post I said I would check out the relative merits and report back - this is me reporting back

Responsive web design works by detecting the size of the display and rendering differently using css (css3) media queries.  The screen size can be set in the css (or different css files loaded) - this means that for small-screen devices a mobile-optimised css can be used, for larger screens a different css.  There can be multiple configurations for different sizes and configurations. The css for that configuration is the one that is loaded and therefore the site rendered using that css.  I found a really useful guide which formed the basis for my approach

responsive web design rendering
Since I had already transformed my own website using mobilize.js, I thought the best indicator of the approaches would be to transform the same website using responsive web design.  As it turned out the results and approach were very similar - I simply adapted the css I'd created for the mobilize.js solution to render the small screen size using responsive web design.  As you can see, the results are very similar

I was pleasantly surprised at how easy it was to adapt the site to use responsive web design, so I tried another one I'd created for Becky Whittaker Counselling.  This one was much more complicated - mostly, I feel, due to it being static-width whereas mine was elastic-width. However since a mobile css needs to be created in both cases, the resulting css would likely be the same for both approaches.  I did make a schoolboy error whilst doing this which is that I forgot about the viewport.  This is IMPORTANT as I discovered when I had weird varying results due to the viewport on any given devices

 <meta name="viewport" content="width=device-width">

Before responsive web design
Attempting both approaches has led me to believe that they have their relative merits which I've grouped into 4 categories:

  •  Configurations
    • What types of configurations are available?
    • How many configurations can you create?
  •  How is the page rendered?
  •  Which technologies are used?
  •  How flexible is it for changing the page?


Configuration Type
After responsive web design

mobilize.js uses the brower's user agent to recognise if the page should be rendered as a mobile site or not - if a mobile user agent for example

Mozilla/5.0 (Linux; U; Android 4.0.3; en-gb; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

is detected then mobilize.js kicks in and renders the page using the mobile css.  This essentially means that a 10 inch tablet will render the same as 2 inch mobile phone

RWD uses resolution (in effect, screen size) to optimise the page regardless of what is being used, so a tablet with a larger resolution may render differently to a small mobile phone screen.  The user agent is ignored. This may mean that a large resolution phone renders the desktop site or that a small resolution netbook renders the mobile site

It might be that what you really want isn't to optimise for screen size but for touchscreen devices.  In this case mobilize.js might work, but there are probably better solutions for this particular case

Number of Configurations

mobilise.js has only 2 basic configurations - desktop or mobile.  As described above this is decided by the user agent

RWD has as many configurations as the creator decides - I don't know why you'd want to
but you could have hundreds if you wished. I've gone for 2 to most emulate what I did with mobilise.js

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 767px)" href="" />

<link rel="stylesheet" type="text/css" media="screen and (min-device-width: 768px)" href="stylesheet.css" />

which cuts over to the desktop site at a width of 768 pixels.  However you could have a smaller one for really small screens for example, or a tablet sized one etc

I feel that RWD has the edge here - the idea behind mobile sites is to optimise them for smaller screens rather than being for mobile phones per se.  If you want to alter content based on user agent there are javascript libraries for that already (see for an example).  It also may mean that the javascript needs updating occasionally as user agents change

Edge: RWD


mobilize.js essentially loads the page, including the javascript which detects the browser and re-renders it using the mobile css if required.  This means that the page is potentially rendered twice including downloading content, such as images, which may not be required for the mobile site

RWD renders the page based on the required css which means it is only rendered once and only with the content required by the page and css.  So if the mobile css doesn't specify an image usually used in the desktop css it won't be loaded

Edge: RWD

Technology stack

mobilize.js utilises (according to the creator) HTML5 and javascript. This makes it heavier weight than RWD. There might be an occasion when this choice is forced due to the lack of CSS3, but realistically I can't see many occasions when HTML5 is available and not CSS3

RWD uses HTML5 and CSS3 making it lighter weight than mobilize.js since no javascript is required.  I'd also argue that performance is better since it doesn't rely on loading and running javascript nor re-rendering the page

Edge: RWD

Flexibility of design

As mobilize.js relies on you specifying the location of existing <div> tags it is pretty easy to reorder them and apply new styles.  This means that, if I so choose, I could display the footer <div> at the top or whatever as the page will be re-rendered.  This provides a lot of flexibility for creating a page that is optimised for small screens

RWD relies on the current markup and how flexibly this has been created. There is potentially limited flexibility on optimising the page.  For example if my desktop site has a side menu I might be able to alter the CSS styles to display it at the top - or then again I might not since the existing markup might prevent that.  This is probably possible with some less-intensive javascript, though I haven't tried it

Edge: mobilize.js


It is important to note that in both of the cases I tried I have been adapting an existing desktop site to render nicely on mobile devices.  If I were designing a new site I would certainly go with responsive web design and design it accordingly.  I feel this is more in the spirit of designing mobile sites which isn't specifically to create a site for mobile devices but to optimise for the screen size

For an existing site mobilize.js has some advantages that may make you consider it, especially the ability to reorder the page.  I think your choice depends on how easy it is to adapt your website to be responsive - if it isn't possible then mobilize.js may provide your answer


  1. This is great. Thank you for sharing. Mobile application design is becoming increasingly more important!

  2. Hi Antony, Dylan here - hope you're keeping well. I had an idea that mobilizejs could be used to equip small businesses and small charities with a way to adapt their website to responsive without needing necessarily to re-design/code. Actually, given the possible variability of each site, the mobile.css would need to be very generic and top-level. Moreover, it easier for web designers to use certainly, but I'm interested in allowing business owners with no background/knowledge in web design to work DIY-style. In terms of implementing, aside from XSS, the js files could be loaded with Ajax (haven't tried) or with LABjs maybe, but it would nice to say "submit your url here", "done"! Then mobilizejs would be injected, ideally. I understand why DudaMobile, for example, functions as it does, and I also realise why Mikko Ohtamaa discountinued the experiment. Mobilizejs is a great idea, but is it practical, in general? I feel an spin off from mobilizejs would be a browser based plugin for altering no mobile/responsive website... Kind regards...

  3. Hi, hmmm interesting idea. The problem I foresee (which you might have already solved, I don't know) is how you would alter the source - so mobilize intercepts the HTML rendering and re-renders it based on a new template and CSS (potentially). I'm sure you could somehow run mobilize server side (node.js maybe?) but how would you make the website display the mobile template without altering the source of it? Even if you used AJAX they would need to add the AJAX call into their source code? Antony

  4. This comment has been removed by the author.

  5. This comment has been removed by a blog administrator.


Post a Comment

Popular posts from this blog

Launch a website as a mobile app using PhoneGap/Apache Cordova

How to manually add Cordova plugins to your app

Adding Multiple Google Accounts to Kindle Fire