Month: July 2015

Why is web technology ideal for mobile

I’ve developed websites for over 15 years now, since Netscape came out. So I’ve done a lot of different websites and web applications, recently over the last 2-3 years mobile web has really grown, but there has always been the native vs web argument over which stack to use to develop mobile applications.

As a web developer I’m on the web side of the argument, the reasons for me that web suits me are, it allows me to develop mobile apps for both Android and iOS from one code base. This allows me as to develop both my own as well as apps for clients to reach both of the major platforms quicker and at the same time. 

It brings a real benefit to small to medium business who want to have a mobile app developed to hit both Android and iOS at the same time instead of getting both a iOS developer and a Android developer to create their app. Twice the number of developers cost twice as much and takes twice as long. I believe the mobile web is an ideal solution for SMB to create their mobile strategy.

Also mobile web allows me as a web developer to use the skills and experience I’ve gather over the last few years to create both responsive websites and mobile applications, using a framework like ionic to create cross platform apps.

Native is still a valid choice, but for me as a web developer the web wins.

My approach to responsive web

Over the last few weeks I’ve been working on a large responsive site using Sass.

Starting working on a responsive site as opposed to a mobile app using something like Ionic, means a lot more thought has to go into how you’ll manage and set out your sass files and use media queries.
When I worked on other responsive sites I always created a separate ‘responsive’ sass or less file (I’m mainly using Sass now, but did use Less a while ago), which contained all my media queries.
I would then load that as the last Sass/Less file, so it would pick up any styles that I wanted to amend in my media queries. This was fine, but as the site grew and there was more and more in my media queries, the single Sass/Less file became huge.
So now I’ve changed my approach, what I’ve been doing to separating my Sass files into components, so I’ll have a Sass file for each page, one for the header, one for the footer section, one for fonts and one for constant variables. I took this approach after reading this great article in SitePoint (http://www.sitepoint.com/architecture-sass-project/).
Now instead of having this single ‘responsive’ file, I’m putting all my media queries in each separate Sass file. So for example in my header Sass file I may have to site title. Within that css class I’ll have the media query for each screen size.
One extra benefit this has, besides getting rid of the massive ‘responsive’ Sass file. Is that when you work as part of a team, with other developers who are not focused on the front-end, if they are .Net developers who work a bit with the front-end work, but leave it mainly to the front-end developer. Which is how I’m working now.
If they need to amend a style that is in a media query they will be able to find the correct style a lot easier. This removes the problem where another developer may want to add a new style, and they are not sure where to add the style so they add it to a new Sass file. With this more modularised approach if they want to amend a media query based style they know where to go. Then as the main front-end developer I can manage the Sass files a lot easier.
This approach may have problems, but I’m going to give it a go on the project I’m working on.