Space48 Logo
stock-photo
June 10, 2015

Front-end development and automation

How do you approach your development?

Are you old-school or new-school? Ben and Stacey have put their heads together to jot a few thoughts down on frameworks and automation.

CSS/HTML/JS framework

Frameworks have become very popular over the last few years, and there lots of them out there. To be honest, I’ve only had a little flutter with a few as I’ve been down the WordPress / Magento framework bunny-hole for a few years now. New technologies appear so often that it’s hard to keep up.

These are perfect for those ‚’lazy’ developers or when working on time critical projects, which, for us developers, is most of the time.

They also allow for designers and developers to work efficiently and consistently on a project together. Everyone can follow the framework guides, speeding up workflows and making sure we don’t reinvent the wheel. It also eliminates any cross-browser-specific nasty bugs early on.

There are lots more benefits for using an open source framework and usually they have plenty of help and documentation available and are well tested. But they also come with the potential hazards to, such as:

  • Most frameworks are heavy/bloated
  • The more tools/code = the higher chance of conflicts/bugs
  • You need to learn and remember the markup
  • It’s third-party
  • Updating can occasionally cause problems forcing you to re-develop parts of the website

Everything has its limitations – it’s up to us to try to break the boundaries and create your own amazing framework (time dependant)! There is no right or wrong answer when it comes to using a framework as it’s mainly down to personal opinion. Using your knowledge to leverage it to the best of your abilities.

Automating tasks

Being a bit of an old school developer myself and knowing the pain of testing hours in IE6, I will always be a fan of being hands-on and I don’t quite agree with a ‚Äòlazy’ developer being a super duper developer.

Yes, automated tasks can speed up development time and ensures that all developers are on the same page and version. But, when a job takes a few minutes to do manually is it not best to just do it, rather than waiting for a developer to set up a script, setup an environment or learn to build a script. Letting the ‚Äòrobots’ do the job for you? We’ve all watched The Terminator, that doesn’t end well.

Most importantly though first making sure our code is properly written, and that images are always optimised, is a standard everyday task. If you’re a ‚Äòlazy’ developer or ran out of time an automated script would be ideal for this. The main 2 are Grunt and Gulp, although some people choose to just use NPM. Next on our horizon is Gulps Clean Css or Image Min plugins.

I believe it’s all about the right balance and setting automated tasks for larger projects in advance. If they’re set-up and working consistently use them, if not, just copy and paste.

Using Compass with Sass

Like Sass, Compass is whole new level of satisfaction. Being able to write one line of code instead of four lines of code is truly amazing! This is the type of automated task that I think is worthwhile. Compass is also extremely useful to set up and again for those ‚Äòlazy’ developers it’s has an inbuilt sprite generator.

However, like every framework it comes with its drawbacks such as –

  • Drastically increases compile time. There are some benchmarks online showing an 18 second Compass compile time being reduced to 0.6 seconds using Libsass. I’d recommend using Libsass with Bourbon instead of Compass.
  • Very heavy/bloated, there are much lighter libraries that do similar tasks.
  • Most of it’s features are rarely used (on the projects I’ve worked on anyway).
  • Time consuming to learn everything it can do
  • Requires a specific version of Sass

So we’ve recently decided to trash Compass all together and start using and creating our own mixins in Sass. This allows us to compile faster and write cleaner code ourselves. Useful mixins we’ve found are –

Opacity

@mixin opacity($opacity) {
opacity: $opacity;
$opacity-ie: $opacity * 100;
filter: alpha(opacity=$opacity-ie); //IE8
}

Usage:
@include opacity(0.7);

Output:
opacity: 0.7;
filter: alpha(opacity=0.7);

Convert PX to Rems
@mixin font-size($sizeValue: 1.6) {
font-size: ($sizeValue * 10) + px;
font-size: $sizeValue + rem;
}

Usage:
@include font-size(2.5);

Output:
font-size: 14px;
font-size: 1.4rem;

Border Radius
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
-ms-border-radius: $radius;
border-radius: $radius;
}

Usage:
@include border-radius(5px);

Output:
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
-ms-border-radius: 5px;
border-radius: 5px;

Conclusion

This is just a little food for thought. There are many different ways of working and of approaching development, you need to find the way that suits you and your projects. I don’t believe any one person has the answers and that the best work comes from collaboration and team expertise. Discuss the issues and come up with the best solution in plenty of time. What are your thoughts?

Related Articles