Responsive site vs. Mobile site

Since the beginning of time, there have been many legendary ongoing battles… Good vs. Evil, Jedis vs Dark Sith Lords, etc. Since internet usage on mobile devices has gone wild, there has been a new battle added to the list: Responsive sites vs Mobile sites (you know, the ones). Add to this the fact that according to surveys articles featuring x vs. y are popular, I think that if I also add a photo of a cat or a baby, this post might get some good statistics. So, here we go, unleash hell…


Personally, I am biased towards responsive design. There is something inherently cool about the idea of having a site that looks good and is usable on more than one screen dimensions, it just feels like it is a more flexible, configurable approach and I feel comfortable with that. Having said that, I have to admit I am by no means a responsive design nor a mobile developer guru, I am just a RWD enthusiast, where RWD stands for Responsive Web Design (and Rear Wheel Drive by the way, I like both). So, let’s put it all out there on the table and see what we can come up with. You are more than welcome to join me on this journey and your feedback and opinion are of vital importance, this is meant to be an open discussion.

So, let’s dance…

Responsive Design

Instead of building a separate site for users accessing your site via a mobile device, you build a one-fits-all site, that adjusts dynamically to the size of the screen, all the elements get re-arranged or even resized, to provide a user friendly interface on all screen sizes.



  • Flexibility. There is only one site to maintain, feature and content wise. You don’t end up having an out-dated mobile site, just because you didn’t have time to apply that “new feature” on the mobile site as well. One site, one love. Peace.
  • Similar user experience on all devices. Users don’t need to re-educate themselves on using your site when they access it on a mobile device. Branding is kept intact and the user gets this feeling of continuity and consistency across all devices.
  • A/B testing. You can easily set up A/B tests or Experiments, since it is exactly the same codebase for mobile and desktop.
  • Reporting/Analytics. It is up to you to get either the sum of any analytics metrics for your mobile or desktop visitors or split it, based on screen resolution or any other criteria.
  • SEO, Google recommends it, and we trust Google. It makes web crawling easier for Google, and your site stands a better chance to get ranked higher.
  • One link to share, link, interact with. Any part of your site has one URL across all devices, making it really easy for users to share content, link to content and you don’t need to come up with some mobile to desktop URL mapping implementation.


  • Effort. Yes, setting up a responsive site is not an easy task, but thankfully, there are some frameworks that can help you with this, for example Twitter Bootstrap. Changing an existing site to a responsive site is even more of a big task, definitely feasible, but time consuming.
  • Performance. A responsive site will normally load everything that the desktop site would load. Of course, there are ways around this. Mobile devices are not as powerful as desktop computers or laptops, so this can be an issue. Add to this that mobile internet connections are slower than our internet connection at home and you might end up with some frustrated users leaving your site before they give it a chance. We all know how important performance is, and especially in case of e-commerce sites, this translates to revenue loss.
  • I could not (or maybe I didn’t want to find any more disadvantages of RWD, anything to add?)

Mobile Site (

Build a site that will be rendered in case the user visits via a mobile device. This is a separate site, new code base, that of course might re-use some of the backend services or even share the same CMS with your main site. This is completely up to you and the way you will implement it. In some cases, developers tend to strip features off the desktop site, to create a less cluttered environment. This is tricky… In some cases, if there is a need to start chopping features or reducing steps (i.e. checkout) maybe it is time this happened on the desktop site as well. After all, it is the same users, and it might well be the case that some features should be removed from the desktop site as well. Moreover, it can get really frustrating, when you realize that some features can’t be reached via your mobile. You add an additional level of complexity, by having to remember all the things that have been excluded from the site. So, in many cases, the task that should take place before building a mobile site, is actually revisit the desktop site and get rid of all the extra “fat”.



  • Fully customized user experience. Since we are talking about a different site, different code base, sky’s the limit. You can provide your users with a totally new user experience, tailored for small screens. This could make sense especially in case of e-commerce sites.
  • App look and feel. Yes, you can make your mobile site look and behave similar to a mobile app.
  • Less effort. It is generally an easier task to create a mobile site than switch an existing site to RWD. But of course, eventually, you end up with two sites to maintain, and keep synced with each other.
  • Performance. Loading less resources can significantly increase the performance of your site and drop loading time, which means, more happy mobile users.


  • Flexibility. As mentioned above, with two sites to maintain, making a decision to add a new feature means that you have to consider how this feature or any kind of change can fit or reflect to the mobile site. And of course, in many cases (been there, done that), you make the decision that you will leave the mobile site as is. Little by little, you end up with a mobile site/time machine, stuck in last year’s desktop site.
  • Redirection. The same pages, from a business point of view, for example a product page, have actually different URL’s, which means that you have to come up with some URL’s mapping logic, when switching from mobile to desktop and vice versa. Also, you are responsible for checking via what kind of devices your users access your site, so that you redirect them to the right version, mobile or desktop.
  • Sharing. As the URL is not the same, sharing a page becomes more tricky.
  • SEO. Google recommends that your site is responsive, who am I to disagree?


Let’s just make one thing clear, there is no perfect solution, or a solution that works in all cases. And of course, there is bad implementation of RWD or extra-ordinary implementation of a mobile site… At the end of the day, it all boils down to what the timeframe for the project and the available resources are. For example, if you have a live, non-responsive site, it might be more difficult to change it, or your team might be specialized in building mobile sites, instead of using RWD. It would be really interesting to hear what you have to say and share your experience with either of the two approaches.

Grails with Twitter Bootstrap


Twitter Bootstrap is awesome. So is Grails. It is a match made in heaven, and these two are now officially BFF’s. For those, not familiar with Twitter Bootstrap, it is a bundle of CSS (or LESS) files, along with Javascript goodies and some graphics, enough kickstart your site/app and make it look professional. Seriously, it rocks, you should definitely check it out.

So, the idea of this exercise (and it is by no means mine), is to apply all the Bootstrap goodies to a vanilla Grails installation, both on the sample pages and the dynamic scaffolding (the CRUD UI for all the domain classes in the app).

I won’t go through the steps of downloading, and setting up Grails on your PC/Mac, let’s assume, you have all this figured out, and you are ready to create a Grails app. FYI, you can find the end product on GitHub, feel free to pull/fork, but if you feel like going through this exercise with me, see below. So, it begins:

  • For the sake of keeping this simple, this works with Grails 2.2.2, haven’t tested this with any other Grails version.
  • grails create-app grails-twitter-bootstrap. OMG, you have just unleashed hell…
  • You will need to add two plugin dependencies to your grails-app/conf/BuildConfig.groovy file:

compile “:twitter-bootstrap:2.3.0”

compile “:lesscss-resources:1.3.3”

  • The first, is for the Twitter Bootstrap plugin, which adds all the Bootstrap resources, ready to be used by the mighty Grails Resources plugin. There as some steps that you need to follow, before you start using this plugin, that can be found on the plugin’s full documentation page. To cut the long story short… by adding
    <r:require modules="bootstrap"/>
  • to a view, or layout, you make all the Bootstrap resources available on the page. You can selectively, add parts of Bootstrap, for example
    <r:require modules="bootstrap-modal"/>
  • for the modal JS windows, but you can just add the whole thing. I want to use the Responsive Bootstrap and I would like to use the LESS files instead of the CSS, so my require looks like this
    <r:require modules="bootstrap-responsive-less,bootstrap-js"/>
  • Don’t forget to also apply the rest of the configuration listed on the plugin’s documentation page.
  • Happy days! Of course, in order to be able to use the LESS files, I had to install the LESSCSS resources plugin, which is the second plugin, listed above. That’s it, no more plugins for today.
  • Grails, by default, comes with the main.gsp layout, which is used on all the pages and the scaffolding pages. So, I just remove the reference to the Grails CSS files from the layout and add the above Bootstrap require.
  • So far, so good. We have reached the part where we need to tell our Grails scaffolding templates, to use Twitter Bootstrap. But, wait a sec, where are these templates? There are two ways you can generate scaffolding for a domain class, either statically, or dynamically. By static, I mean, run
    grails generate-controller
  • and this will create the .gsp’s files. However, in this way, you will have to edit all the .gsp files for all the domain classes. Instead, we can use Grails dynamic scaffolding, just by adding:
    static scaffold = true
  • and then, we will be using the mysterious Grails scaffolding templates that are nowhere to be found. Keep in mind, in the above command, “true” works based on convention over configuration, for example for a BookController and a Book domain class, other wise you will have to explicitly say which domain class, this controller provides scaffolding for, like
    static scaffold = Book
  • So, in order to get the scaffolding templates, you need to run
    grails install-templates
  • The templates will be created under the src/templates/scaffolding directory. You are looking at the familiar create, edit, list, show and _form gsp files. Any change on any of these files, will affect all the scaffolding for all the domain classes using dynamic scaffolding.
  • And this is where the Twitter Bootstrap magic will have to kick in. I won’t go into detail, the commits on the GitHub repo with the sample application are pretty self explanatory, but allow me to list the changes applied:
  • Use responsive design for both the index/error pages and the scaffolding pages
  • For the scaffolding pages, I used fluid layout
  • Bootstrap styled buttons, forms, navigation, and some nice slideshow for the front page.

Hope you enjoyed this post, feel free to ping me if you have any questions, the easier way to get the hang of it, would be to pull the project from GitHub and have a look at the few commits that reflect the steps taken into this post.



Run more than one Grails versions


So, you have some old Grails project, that for many reasons would be way too complicated to upgrade to the latest Grails version, but you still want to take the latest Grails version for a spin. And of course, you want to be able to call “grails” from the terminal, without having to type the exact path of each executable, grails-jurassic and grails-latest. No problems, here’s a nice little script that solves this problem,

The instructions are pretty clear, but just to make it easier for you, here are the steps:

  • All the Grails installations should be under the same directory, i.e. /Users/me/
  • The GRAILS_HOME environmental variable should point  to the default Grails installation (this is the top directory of the installation, not the executable grails file). Yes, did I mention you can have a default Grails installation?
  • Download the script from here,
  • Include the directory where the script is copied, to your PATH environmental variable.
  • Exclude $GRAILS_HOME/bin from your PATH, so that instead of the Grails executable, the shell script you just downloaded gets executed.
  • Hopefully, now, you should be able to run “grails” like before. By running “grails”, the default Grails version will be executed, alternatively, you can run grails version, for example grails 2.2.2. You can find the version on the name of the Grails directory.

Happy coding!

Hello World!

What else could you expect as the first article of this blog? It is meant to be a tech blog after all.. Let’s see how it will turn out. Searching for answers, killing some time, mispelling some other site, whatever the reason you ended up on this blog is, I honestly hope you enjoy your stay here, and it would be great to see you back!

if (you enjoyed this) {

keep reading;