Tuesday, March 31, 2015

A Baseline for Front-End [JS] Developers: 2015

A Baseline for Front-End [JS] Developers
It's been almost three years since I wrote A Baseline for Front-End Developers, probably my most popular post ever. Three years later, I still get Twitter mentions from people who are discovering it for the first time.

In some ways, my words have aged well: there is, shockingly, nothing from that 2012 post that has me hanging my head in shame. Still, though: three years is a long time, and a whole lot has changed. In 2012 I encouraged people to learn browser dev tools and get on the module bandwagon; CSS pre-processors and client-side templating were still worthy of mention as new-ish things that people might not be sold on; and JSHint was a welcome relief from the #getoffmylawn admonitions – accurate though they may have been – of JSLint.

It's 2015. I want to write an update, but as I sit down to do just that, I realize a couple of things. One, it's arguably not fair to call this stuff a "baseline" – if you thought that about the original post, you'll find it doubly true for this one. One could argue we should consider the good-enough-to-get-a-job skills to be the "baseline". But there are a whole lot of front-end jobs to choose from, and getting one doesn't establish much of a baseline. For me, I don't want to get a job; I want to get invited to great jobs. I don't want to go to work; I want to go to work with talented people. And I don't want to be satisfied with knowing enough to do the work that needed to be done yesterday; I want to know how to do the work that will need to get done tomorrow.

Two, my world has become entirely JavaScript-centric: knowledge of the ins and outs of CSS has become less and less relevant to my day-to-day work, except where performance is concerned. I know there are plenty of very smart front-end developers for whom this isn't true, but I have also noticed a growing gulf between those who focus on CSS and those who focus on JavaScript. That's probably a subject for another blog post, but I bring it up just to say: I am woefully unequipped to make recommendations about what you should know about CSS these days, so I'm not going to try.

In short: if this list of things doesn't fit your vision of the front-end world, that's OK! We're both still good people. Promise.


Remember back in 2009 when you read that HTML5 would be ready to use in 2014, and that seemed like a day that would never come? If so, you're well prepared for the slow-but-steady emergence of ES6 (which is now called ES2015, a name that is sure to catch on any day now), the next version of JavaScript. Getting my bearings with ES6 – er, ES2015 – is hands-down my biggest JavaScript to-do item at the moment; it is going to be somewhere between game-changing and life-altering, what with classes, real privacy, better functions and arguments, import-able modules, and so much more. Those who are competent and productive with the new syntax will have no trouble standing out in the JS community. Required reading:

  • Understanding ES6, a work-in-progress book being developed in the open by Nicholas Zakas.
  • BabelJS, a tool that lets you write ES6 today and "compile" it to ES5 that will run in current browsers. They also have a good learning section.
  • ES6 Rocks, with various posts that explore ES6 features, semantics, and gotchas.

Do you need to be an ES6/ES2015 expert? Probably not today, but you should know at least as much about it as your peers, and possibly more. It's also worth at least entertaining the possibility of writing your next greenfield project using ES6; the future will be here before you know it.

New language features aside, you should be able to speak fluently about the asynchronicity of JavaScript, and using callbacks and promises to manage it. You should have well-formed opinions about strategies for loading applications in the browser and communicating between pieces of an application. You should maybe have a favorite application development framework, but not at the expense of having a general understanding of how other frameworks operate, and the tradeoffs you accept when you choose one.

Modules & Build Tools

There's no debate that modules should be the building blocks of client-side web applications. Back in 2012, there was lots of debate about what kind of modules we should use for building apps destined for the browser – AMD or CommonJS. The somewhat-gross UMD wrapper arose to try to avoid answering the question while still allowing code reuse – because hey, what's a few more bytes between friends?

I don't feel like this debate is anywhere near resolved, but this is the area where I feel like we've seen the largest transformation since my 2012 article, though perhaps that's a reflection of my personal change of heart. I'm not ready to say that I'm done with AMD, but let's just say I'm floored by how practical it has become to develop and deploy web applications using CommonJS, including modules imported with npm.

With much love for all that RequireJS has contributed to the module conversation, I'm a bit enamored of webpack right now. Its features – such as easy-to-understand build flags – feel more accessible than RequireJS. Its hot-swap builds via its built-in dev server make for a fast and delightful development story. It doesn't force an AMD vs. CommonJS decision, because it supports both. It also comes with a ton of loaders, making it fairly trivial to do lots of common tasks. Browserify is worth knowing about, but lags far behind Webpack in my opinion. Smart people I trust tell me that systemjs is also a serious contender in this space, but I haven't used it yet, and its docs leave me wanting. Its companion package manager jspm is intriguing, allowing you to pull in modules from multiple sources including npm, but I'm a bit wary of combining those two concerns. Then again, I never thought I'd break up with AMD, yet here I seem to be, so we'll see.

I still long for a day when we stop having module and build tool debates, and there is a single module system and sharing code between arbitrary projects becomes realistic and trivial without the overhead of UMD. Ideally, the arrival of ES6 modules will bring that day – and transpilers will fill in the gaps as the day draws closer – but I find it just as likely that we'll keep finding ways to make it complicated.

In the meantime, front-end developers need to have an opinion about at least a couple of build tools and the associated module system, and that opinion should be backed up by experience. For better or worse, JavaScript is still in a state where the module decision you make will inform the rest of your project.


Testing of client-side code has become more commonplace, and a few new testing frameworks have arrived on the scene, including Karma and Intern. I find Intern's promise-based approach to async testing to be particularly pleasing, though I confess that I still write most of my tests using Mocha – sometimes I'm just a creature of habit.

The main blocker to testing is the code that front-end devs tend to write. I gave a talk toward the end of 2012 about writing testable JavaScript, and followed up with an article on the topic a few months later.

The second biggest blocker to testing remains the tooling. Webdriver is still a huge pain to work with. Continuous automated testing of a complex UI across all supported browsers continues to be either impossible, or so practically expensive that it might as well be impossible – and never mind mobile. We're still largely stuck doing lightweight automated functional tests on a small subset of supported browser/device/OS combinations, and leaning as hard as we can on lower-level tests that can run quickly and inexpensively. This is a bummer.

If you're interested in improving the problem of untested – or untestable – code, the single most valuable book you can read is Working Effectively with Legacy Code. The author, Michael Feathers, defines "legacy code" as any code that does not have tests. On the topic of testing, the baseline is to accept the truth of that statement, even if other constraints are preventing you from addressing it.

Process Automation

You, hopefully, take for granted the existence of Grunt for task automation. Gulp and Broccoli provide a different approach to automating builds in particular. I haven't used Broccoli, and I've only dabbled in Gulp, but I've definitely come to appreciate some of the limitations of Grunt when it comes to automating complex tasks that depend on other services – especially when that task needs to run thousands of times a day.

The arrival of Yeoman was a mere 45 days away when I wrote my 2012 post. I confess I didn't use it when it first came out, but recently I've been a) starting projects from scratch using unfamiliar tech; and b) trying to figure out how to standardize our approach to developing third-party JS apps at Bazaarvoice. Yeoman really shines in both of these cases. A simple yo react-webpack from the command line creates a whole new project for you, with all the bells and whistles you could possibly want – tests, a dev server, a hello world app, and more. If React and Webpack aren't your thing, there's probably a generator to meet your needs, and it's also easy to create your own.

Given that Yeoman is a tool that you generally use only at the start of a project, and given that new projects don't get started all the time, it's mostly just something worth knowing about. Unless, of course, you're also trying to standardize practices across projects – then it might be a bit more valuable.

Broccoli has gotten its biggest adoption as the basis for ember-cli, and folks I trust suggest that pairing may get a makeover – and a new name – to form the basis of a Grunt/Yeoman replacement in the future. Development on both Grunt and Yeoman has certainly slowed down, so it will be interesting to see what the future brings there.

Code Quality

If you, like me, start to twitch when you see code that violates a project's well-documented style guide, then tools like JSCS and ESLint are godsends, and neither of them existed for you to know about them back in 2012. They both provide a means to document your style guide rules, and then verify your code against those rules automatically, before it ever makes it into a pull request. Which brings me to…


I don’t think a whole lot has changed in the world of Git workflows since 2012, and I'd like to point out Github still hasn't made branch names linkable on the pull request page, for f@#$s sake.

You should obviously be comfortable working with feature branches, rebasing your work on the work of others, squashing commits using interactive rebase, and doing work in small units that are unlikely to cause conflicts whenever possible. Another Git tool to add to your toolbox if you haven't already is the ability to run hooks – specifically, pre-push and pre-commit hooks to run your tests and execute any code quality checks. You can write them yourself, but tools like ghooks make it so trivial that there's little excuse not to integrate them into your workflow.

Client-Side Templating

This may be the thing I got the most wrong in my original post, for some definition of "wrong". Client-side templating is still highly valuable, of course – so valuable that it will be built-in to ES2015 – but there can be too much of a good thing. It's been a hard-earned lesson for lots of teams that moving all rendering to the browser has high costs when it comes to performance, and thus has the "generate all the HTML client-side" approach rightfully fallen out of favor. Smart projects are now generating HTML server-side – maybe even pre-generating it, and storing it as static files that can be served quickly – and then "hydrating" that HTML client-side, updating it with client-side templates as events warrant.

The new expectation here – and I say this to myself as much as to anyone else – is that you are considering the performance implications of your decisions, and maybe not restricting yourself quite so thoroughly to the realm of the browser. Which, conveniently, leads to…


You say you know JavaScript, so these days I expect that you can hop on over to the Node side of things and at least pitch in, if not get at least knee-deep. Yes, there are file systems and streams and servers – and some paradigms that are fundamentally different from front-end dev – but front-end developers who keep the back end at arm's length are definitely limiting their potential.

Even if your actual production back-end doesn't use Node, it's an invaluable tool when it comes to keeping you from getting blocked by back-end development. At the very least, you should be familiar with how to initialize a Node project; how to set up an Express server and routes; and how use the request module to proxy requests.

via rmurphey.com by

Wednesday, March 18, 2015

6 advanced web typography tips

6 advanced web typography tips

Elliot Jay Stocks reveals how to take your web-based typography to the next level.

Typography on the web has made huge leaps forward in recent years, allowing web designers to realise their designs with an almost print-like level of control. However, the details surrounding that control can still be challenging, and bleeding-edge technology like OpenType support is still in flux.

In his talk at Generate London, Typekit's creative director and 8 Faces founder Stocks took attendees through some of the most exciting recent developments that allow us to take web-based typography to the next level. Here are six tips of Stock's tips for upping your type game on the web…

01. Use font-feature-settings

Ligatures are very widely supported – they're on by default in Firefox and are very easy to turn on. This is often how people turn on ligatures and a bunch of other Open Type features: text-rendering: optimizeLegibility;

However, use with caution. A far more powerful way of doing so is: font-feature-settings.

This allows you to be a little more granular; to go in and say: "I want to turn this specific Open Type feature on or off". Also, optimizeLegibility isn't standardised and is a little bit buggy so generally not recommended – especially for body text.

02. Consider the typeface

The typeface is the design – the thing that exists in the ether that was created by the designer. Does the actual design contain swashes? Ligatures?

If it's not in the actual design, it's never going to make it into the font file and will certainly never make it to your browser. At the base level: did the person who designed this typeface actually design your secondary A style set option? Possibly not.

03. Consider the font file

Is it actually an OpenType font file being served? You're never going to be able to turn on an OpenType setting if you're serving a TrueType font, so this is a really important thing to consider. Even if it is OpenType, are the actual glyphs that you need inside the font file? Possibly not.

04. Consider the browser

Some browsers support some features, some they don't, some it's different on different operating systems. No matter how robust your CSS is, if you're testing it in a browser that physically doesn't support that feature, you're not going to see it.

05. Consider the user

Will the design break if ligatures are missing? Probably not. But it quite possibly will if the swash characters are missing and you're actually representing the company logo in web type. Perhaps, in that circumstance, you need to find another way of doing it.

06. Be responsible

Responsive web design is where our heads are at – but it's also about responsible web design. All these cool new shiny features are great, but we need to be mindful of when we use them. Pick the right features you want for the right scenario. This is a really exciting time to be working not he web because we've essentially caught up with what you can do in print.

Words: Elliot Jay Stocks

Wednesday, March 18, 2015

Important factors of on-page optimization and SEO checklist

optimization and SEO


  • Content should be original and unique
  • Content will reached with reference
  • You have a clear content strategy
  • You have to write the content with related keywords in it's body

Friday, February 27, 2015

How to Make Your WordPress Site Blazing Fast

WordPress Site

Today's web users have the need for speed. With internet and cellular connections getting faster and faster, users expect sites to feel snappy. As developers, we must make sure we're doing our best to serve those pages quickly. This article will focus on what you should be doing to make sure your WordPress sites are as fast as possible.

Make your Wordpress site blazing fast

There are essentially two main categories that performance can be broken down into: front-end and back-end. Back-end is anything related to the server and how data is populated on a page (PHP code in your theme is the "back-end"). The front-end consists of all your assets (CSS, JavaScript, images, etc.) and markup. Everything a web browser reads and interprets is the "front-end". This distinction is important because it's good to know what you're optimizing and, even more importantly, where you need to optimize the most.

To actually test site speed, use a combination of WebPagetest and Google PageSpeed Insights. WebPagetest gives you a good idea of the actual time (in seconds) that a site takes to load, explaining where bottlenecks may be. PageSpeed Insights is best for looking at how your front-end is site is rendered by the browser.

Front-end performance

The golden rule of performance, according to Fastly's Steve Souders is that 80-90% of a page's total load time consists of the front-end. The back-end's 10-20% is crucially important, but even if you're using the fastest host around, your site still won't live up to its full potential without optimizing the front-end and users perceive it to load quickly. Perception is an important part of front-end optimization. A user doesn't care how many seconds a site takes to load. A user cares about how quickly they can interact with a site without a delay. Not that you shouldn't be worried about the actual load time (you should), but by following these techniques, you can make sure that your site is in a usable state fast, before loading the rest of the page assets.

WordPress Site


Before delivering CSS to the browser, it’s important to compress it and remove unused selectors.

Once your stylesheet is ready to go, the easiest (and standard) way to load it is to reference it in the head. The browser will load and parse it before the rest of the DOM is loaded. However, there's a new technique where "critical" styles are inlined in the head and then the full stylesheet is loaded asynchronously using JavaScript. This technique can be used when trying to get a site to load (or perceive to load) in under a second, but it's a great tool to keep in your arsenal. Check out this great extensive article on using this technique.

WordPress Site


The golden rule(s) of optimizing JavaScript are simple: serve as few JavaScript files as possible and minify and concatenate. Third-party WordPress plugins can bloat your document with unminified blocking JavaScript files, so it's important to be mindful when choosing plugins. Ideally, you'd concatenate ALL JavaScript files into one and then minify it. When that's not possible, HTML attributes called async and defer can be used to load JavaScript files asynchronously or once the rest of the page is loaded.

The most common place to reference JavaScript is at the bottom, right before the closing tag. However, there are more advanced techniques to load JavaScript. The Filament Group has several tools you can use for this. The best approach is to load scripts dynamically by inlining a small function in the head that appends script tags without blocking the rest of the page. For more information, check out the loadJS script.


Images are often the biggest files on a page, responsible for the largest load time delay. The good thing about images is that, unlike CSS and JavaScript, most browsers load them asynchronously. That helps with the perceived performance of a page. But it's still important that A) you're serving as few images as possible and B) those images are compressed as much as possible.

Compression tools are necessary for squeezing out as much excess as possible on images. ImageOptim is a great free Mac compression app, along with OptiPNG and jpegtran for use with task runners like Grunt.

WordPress Site


Web fonts are super common these days. Google Web Fonts make sites pop. It's easy to not realize the performance hit you take by just referencing them in the head. The performance hit is small, but every little bit counts! For best performance using web fonts, check out the the Web Font Loader, co-developed by Google and Typekit. It's an open source script that both manages the loading of your fonts from third parties like Google Web Fonts and allows them to load asynchronously (getting tired of that word yet?).

As to be expected, there's some configuration needed to get Web Font Loader integrated into your project, so check out the project on GitHub for setup info.

WordPress Site

Back-end performance

The front-end has all kinds of tricks for speed, but we're not so fortunate on the back-end. A server is either fast or it's not. It's critical that your site gets to the browser as quickly as possible, which can be accomplished by getting on a quality host. Managed hosts like Flywheel are the most realistic way to see true performance gains for WordPress sites.

Dedicated Wordpress Hosts

There are are a host of managed WordPress hosts (pun intended). What managed hosts typically provide is a dedicated VPS (virtual private server), a caching layer and other infrastructural bonuses that set them apart from your typical shared hosting. These all matter when it comes to loading your site fast, so the best and first step to a super fast WordPress site should be the host.

For example, let's take a look at Flywheel. Flywheel is a managed host, and their infrastructure is designed so your sites never touch another customer's. Compared to a host that crams as many sites as possible on the same server, having your site on a server by itself works magic for speed. It means that server's resources are just working for you, not for everyone else.

WordPress Site

Theme Logic

There are many things you can do while developing to make your back-end as performant as possible. Nasty loops that do tons of comparisons and use lots of memory slow down a site down. There are lots of articles on performant PHP, but just take care when writing theme logic!

Another important time saver during database queries is the Transients API. WordPress transients store cached data in the database temporarily, which means your logic only has to run once (whenever the first visitor loads the page). The results are then stored in the database. The Codex has good documentation on the usage of transients.


Caching assets is one of the best ways to improve performance. Once a user loads your site the first time, you can take advantage of browser capabilities to cache the contents of that site locally, so on the next visit the user already has them loaded. The most common WordPress caching tool is W3 Total Cache plugin. This plugin (or one similar) is needed on most shared hosts. However, WordPress specific hosts like Flywheel handle caching for you behind the scenes. With hosts like Flywheel, all of the caching is done on the server outside of WordPress, which means your sites are already tuned for max performance.

WordPress Site


Gzip is a file format that's used to compress other files together, similar to just zipping files. Gzipping allows files to be sent over the web at a compressed size. Once a browser receives gzipped data, it unzips it to get the source data. Gzipping is super important for speed, as it sends your data over the wire in much smaller packages (50 - 70% smaller, in fact). Smaller file size equals faster load times!

You should always check to see if your host supports Gzipping. Managed WordPress hosts like Flywheel enable Gzip compression by default, so it's one less to to worry about!

WordPress Site


A content delivery network (or CDN) is a network of servers that serves up your website and its assets from different locations based on the user's location. For example, let's say you're not using a CDN and your site is hosted in San Francisco. When someone from, say, Spain visits your site, they have to retrieve all your assets from your server in San Francisco. The long distance between the two locations clearly takes longer than if someone from San Francisco loads your site that's hosted in San Francisco. A CDN serves your assets from the closest geographical data center. Users will hit the server closest to them, speeding up the physical time and distance required to load the page.

Some of the most popular CDNs include Amazon Web Services, CloudFlare and MaxCDN. If you want a super easy setup, check out Flywheel's MaxCDN add-on.

WordPress Site


Tuning a web site to maximum capacity can be challenging. There are a lot of moving parts. By working through both the front end and the back end, a site can be designed or overhauled for maximum speed. On the front end, saving as much time and space as possible means the con-tent you’re serving gets to the content faster. But if even if your front end is brilliantly designed, none of that will matter the servers you host the site on aren’t running at their peak performance. Managed WordPress hosts tune sites to peak performance and take out the frustrations behind web hosting. Hosts like Flywheel will not only make your site fly, but make your hosting experience worry-free.

Tuesday, February 24, 2015

The Problem With Raw CSS

The Problem With Raw CSS

Writing raw CSS is not a pleasure nowadays. Pure CSS has a very simple and, as a side effect, very inflexible syntax that doesn't always suited our needs in building high quality products. The overall complexity of systems are increasing day by day and modern web developers need more and that's why CSS preprocessors exist.

The Overall Structure

In order to explain what a CSS preprocessor is and why we should use this kind of tools I'll build a little demo with raw CSS. After that I'll take this further by translating it in sass, the preprocessor of our choice for this article. This demo will be big enough to see the difference between each tool. I'll try also to explain along the way some new concepts about preprocessors pretty quickly, so that you can start using those right now.

For the rest of this article I'll use this HTML structure:


I'll skip the repetition from the code, just to be clear. You can taste full code listing and the demo in this codepen. Later we'll discuss about implementing this demo using sass, the preprocessor we used to talk about in this article.

See the Pen yyvBVZ by Andrei Glingeanu (@andreiglingeanu) on CodePen.

Sass: Syntactically Awesome Style Sheets


We have 2 options: to use command line or a GUI application.

If you have ruby installed on your system, be it windows, osx or linux, you can type into command line this line to install sass:

gem install sass

Now you should have sass binary on your computer. You can compile a file named input.sass into corresponding output.css using command below. We have --watch switch to indicate that we want to recompile automatically as we change the input.sass file.

sass --watch input.sass:output.css

Another option will be to use a tool like Prepros to compile sass files for you. Many other options at Official Installation Page.

Nesting rules

The most used feature that preprocessor gives us is rules nesting, just like we nest elements in each other in HTML. For example, when we write a rule like this:

#main-content {
    h1 {
        em {
            text-transform: uppercase;

it will generate the following CSS:

#main-content h1 em {
    text-transform: uppercase;

Using variables

We can treat variables as a named container, where we can put several things. For example we can store a color in a variable and use this color in multiple places. Storing a size in a variable, be it in pixels, percents or ems, is also a good idea. Let's see a demo using variables next.

$itemBackground: #867e7e;
$itemPadding: 5px;

ul.menu {
  list-style: none;
  padding: 0;
  li {
    display: inline-block;

    background: $itemBackground;
    transition: background .5s ease-in;
    // we can use several functions to modify our colors
    // here we lighten $itemBackground by 50% in order to ensure
    // that we are able to read the text
    color: lighten($itemBackground, 50%);
    padding: $itemPadding;
    // we can use arithmetic operations, if variable is a number
    margin-right: $itemPadding * 2;
    cursor: pointer;
    font-size: 2em;


See how I defined variable $itemBackground in order to store background color for our menu? This is a very common pattern to define our palette of colors at the top and then use this colors throughout the file by explicit name. In this way we can change all colors very easily. In this demo we also have used rules nesting.

Another trick about storing colors in variables is that we can modify them using several predefined functions like:

  • lighten
  • darken
  • saturate
  • alternate

You can see full list of them and their usage on this great resource.

Parent reference

Sometimes, when using rules nesting we need a way to reference the element inside we nest rules. Let's say we need a way to target paragraphs inside an article, but only those who have the class special. We can express it this way:

article {
    p {
        color: #333;

        &.special {
            color: #f00;

The key idea here is to use & in order to reference the current element. Sass will give us back the following css:

article p {
    color: #333;

article p.special {
    color: #f00;

We can use this trick in order to target all the pseudo elements and pseudo classes of current element together. In this demo you'll see how I target :last-child in order to give it margin-right: 0; and also how to style :hover pseudo class for lis using &.

$itemBackground: #867e7e;
$itemPadding: 5px;

ul.menu {
  list-style: none;
  padding: 0;
  li {
    display: inline-block;

    background: $itemBackground;
    transition: background .5s ease-in;
    // we can use several functions to modify our colors
    // here we lighten $itemBackground by 50% in order to ensure
    // that we are able to read the text
    color: lighten($itemBackground, 50%);
    padding: $itemPadding;
    // we can use arithmetic operations, if variable is a number
    margin-right: $itemPadding * 2;
    cursor: pointer;
    font-size: 2em;
    &:hover {
      // another function which modifies color
      background: darken($itemBackground, 10%);

    &:last-child {
      margin-right: 0;


Mixins and extending rules

In a nutshell, mixins are a way to encapsulate many useful properties into one block, and then using @include insert this properties into our rule. This is somewhat a similar concept to functions in JavaScript and PHP. The main idea is that you can pass different parameters to the mixin, and it will return you the right properties, depending on the parameters you passed. Let's see an example where we define a mixin in order to write vendor prefixes for transform property.

@mixin transform($transformation) {
  -webkit-transform: $transformation;
  transform: $transformation;

div {
  width: 100px;
  height: 100px;
  background: red;

  @include transform(translate(40px));

Let's see, here we have transform mixin, and we include it into div, using @include. As a named parameter $transformation we receive translate(40px). The generated css for this mixin will look like this:

-webkit-transform: translate(40px);
transform: translate(40px);

Another way of reusing existing styles is to @include already existing rules. This one is not so common as mixins, because it does not have the ability to pass parameters to it, therefore it is not so flexible. You'll have an example on using this technique in the final demo for sass.

Hence, we have many ways to not repeat ourselves by defining mixins and including already existing rules. There is available online many collections of predefined mixins for sass, which provide many neat things. Most popular ones are bourbon and susy. You can read about them by clicking on the links I provided for you. Among the others, susy is a great alternative to bootstrap grids and it will prevent your html being polluted with unsemantic classes like col-md-4. You definitely should check them out.

Reimplementing demo

Now let me give you a full reimplementation of our kitties using sass, you can skim through code on codepen, it is very simple. Try to reveal all the new concepts we've covered here in the code for this demo.

See the Pen JopZRj by Andrei Glingeanu (@andreiglingeanu) on CodePen.


As a conclusion, all the preprocessors and sass specifically gives us a more flexible way to structure our styles, in comparison to pure css. Now all the nesting from HTML is expressed very naturally in our stylesheets. We also don't repeat ourselves by writing colors and scalar values, which is highly error prone and is very easily to commit a mistake by using sass variables. The ability to group multiple rules under one named mixin is also a beautiful and readable way of structuring css.

These little explanations should really get you started on using sass. If you really want more you can go ahead and read official guide for this preprocessor. You may find useful documentation, which gives many more ideas and insights on using and integrating sass on different platforms and development stacks.

Tuesday, February 24, 2015

Effective Web Typography: Rules, Techniques and Responsive Design

Effective Web Typography: Rules, Techniques and Responsive Design

Responsive Web Design isn't just about columns, grids, images and icons. All of this will not make sense without text for content. As Bill Gates once said "Content is King".

When it comes to content, we need to talk about web typography. Looking at modern web design trends, having responsive typography is a big factor every web designer and web developer shouldn't miss.

Here, we will discuss creating responsive web typography and factors you need to know about it.

Typography Basics

Good typography is all about selecting the right type for web or printed media. From font type, color of the text to the length and font-size on different viewports, good typography ensures that the final letter forms generate the highest quality end result.

Before we dive in to the process of creating successful responsive web typography, here are a few terms that you need to understand.



Also known as font family. This is a collection of design of characters with a complete set of letters, numbers, symbols, special characters and weight.



This is the actual computer file that contains information about the lettering used, such as typeface, weight, width, style and so on.



This is the line where the letters rest and where descenders extend.

Cap Height

Cap Height

This is the height of the capital letters above the baseline.



Also known as corpus size. This to the distance between the baseline and midline (half the distance from the baseline to cap height)



This is the part of a letter that extends below the baseline.


Also known as letter spacing. This is the consistent increase or decrease of space between letters uniformly.


The process of adjusting the space between individual characters in glyphs of varying widths.


Also known as line height in CSS. The distance between the baselines of successive lines or types.

Points to Consider on Web Typography

Words, phrases and sentences have meaning but each character can have emotion. Aside from being responsive, you must also consider presenting better web typography to your audience.

The complete design will not make sense if your audience will not understand or is not attracted to your content. In web typography there are four basic elements:

  • Type
  • Color
  • Texture
  • Image

All of these will have a big effect to your typography end-result but the type will magnify the expressiveness of your message.

There are five factors that can help you create presentable web typography.

1. Choose the best typeface that corresponds to your topic

Most sites nowadays are using the same typefaces. Yeah, you guessed it right; I am talking about Arial and Helvetica. However, it would make a lot of sense if you could align typefaces with your message.

For instance, your web pages talks about a children's book would it be good if you'll use something like DK Crayon Crumble or Little Miss Priss in your header text?

I am not suggesting you need to do this all of the time but the point is make sure that typography aligns with your target audience and the text is clear and readable.

2. Use web fonts

One of the greatest improvements of web design nowadays is the support for Web fonts on all modern browsers via @import command and standard link tag. Check out the demo below.

Using @import tag:

@import url(http://fonts.googleapis.com/css?family=Open+Sans);

Using the standard link tag:

This means that you can use any font that is available on the hosted web font site such as Google Font, Typekit and Fontdeck. Here are the following the advantages of using web fonts:

  • It saves money. You don't need to purchase fonts online.
  • It saves time. While you can integrate fonts manually in your folders file, using web fonts can be done with a line of code.
  • They are compatible on all new versions of web browsers and are SEO-friendly.

3. Use proper color combinations

One of the major issues web designers commit nowadays is throwing unnecessary color combinations to their sites. Remember good web design can be identified by how well the site functions and how good the design is.

Speaking of design, you don't just design your web pages randomly and throw a lot of colors that doesn't mix especially with your text and background of your site. This will make your text unreadable and will bring pain to your visitor's eyes.

But how do you use proper color combinations? While there is no general rule, there are some guidelines.

  • Use proper contrast or distinction colors between text and the background as suggested by W3C. Colors that have the same value but different hue may be easily read with a person with a good vision but not on color blind person. It is important to check the contrast before applying it to your design. You can use this great tool to simulate contrast.
  • Use flat UI colors if possible. These colors are light and have great combinations that are not painful to the eyes. Check out flatuicolors.com for more information, based on Flat UI.

4. Use text instead of images

As we all know images make web pages slower. Most often images are the only way to force the web browser to display a preferred font and the exact layout you want. However this might not work. Using real text is the best way to go especially with responsive web design. Remember, search engines can't read images but they can read text.

5. Use fallback text style when clipping text

There might be a time wherein you need to clip text on images to create a textured or image text. The problem here is that not all browsers support this technique.

The best way to do this is using Paul Irish's CSS Browser Selector plugin. This is a lightweight plugin that detect the browser and manipulates the styles you want to appear on specific browsers. Here's how to use this cool plugin.

  • Download the plugin here and then link it to your head section:

  • Set CSS attributes (either id or class) with the code of each browser you want to change specifically on your stylesheet.

    .opera #header { margin: 20px; }
    .webkit #header { margin: 30px;  }
    .ie #header{ margin: 10px; }
    .ff3 #header {margin: 15px; }

For more information about this cool plugin check out this site.

Responsive Typography Ground Rules

Most of the fundamental typographic elements can be manipulated with CSS. However, it actually more than just adapting or optimizing the size of the text on each viewport. Now that we've discussed how you can achieve presentable web typography, it's now time to talk about the basic ground rules that we can apply to achieve better responsive typography.

1. Use rem instead of pixels and ems

The use of both pixels and ems is popular. While pixels are fixed, ems are relative units to the parent element. This means when you resize the browser it's hard to figure it out the size you need to set to achieve the output you want to attain.

A better option is using rems. Rems or also known as "root em" are always equal to the font size of the root HTML element and what's more exciting with this is that it was being supported by modern browsers.

html { font-size: 16px;   // 1rem = 16px }
h1 { font-size: 1.9rem // 19px }
h2 { font-size: 1.8rem // 18px }

In this example I'm defining a base font-size of 16px which is the reference of the font-size of the other element. The size of the h1 and h2 will change as the viewport changes.

For older versions of Internet Explorer, we can specify the font-size in px units first and define the rem units along with it and we can have a resizable text on all browsers.

html { font-size: 16px;   // 1rem = 16px }
h1 { font-size: 19px; font-size: 1.9rem; }
h2 { font-size: 18px; font-size: 1.8rem; }

2. Experiment rem units on different viewports

Now that you know how to use rem, you need experiment on different sizes of screens via @media queries. The output will depend on the typeface. You need also to use actual font sizes and see if you'll get the result you want.

@media (max-width: 640px) {
h1 { font-size:1.7rem }
h2 { font-size: 1.6rem }
@media (min-width: 480) {
h1 { font-size:1.9rem }
h2 { font-size: 1.8rem}

Notice that on smaller screens the font size is a bit bigger compared to the wider screens. This will make text more readable as users read via phone or tablet.

3. Use CSS3 pseudo-classes to specify specific styles

One of the great features of CSS3 is that it can target a specific letter, line or paragraph and give it a different style. This gives designers the freedom to resize or adjust the text on different sizes.

As you can see on the example below, we use the following the CSS3 pseudo-classes:

  • first-of-type – selects the first child of the paragraph tag
  • first-line – selects the first line of the the paragraph tag
  • first-letter – selects the first letter of the paragraph tag

4. Control your measure

As suggested by Robert Bringhurst, the most ideal measure or line-length is around 45 to 75 characters per line. For responsive web design, the measure is not that easy to control especially on smaller viewports. If you can't control measure, you can't control legibility of your text.

There is a good article by Elliot Jay Stocks that talks about this topic on how to use media queries to achieve a desirable line height and measure.

Using Plugins

While there are a lot of jQuery plugins that we can use for responsive web typography online, the most popular one is the FlowType.js. This jQuery plugin counts character per line and set font sizes at definite line length at any viewports.

Let's take a closer look on how this works.

Step 1: Set Typography Values

Start adding CSS basic set up for FlowType.js.

body {
   font-size: 16px;
   line-height: 20px;
h1,h2,h3,h4,p {
   font-family: inherit;
   font-size: inherit;
h1 {
   font-size: 3em;
   line-height: 1em;
h2 {
   font-size: 2em;
   line-height: 1em;
p {
   font-size: 1em;
   line-height: 1em;

These values will be used by FlowType.js and change each values as the viewport resizes. Setting up font size and line height will enable you to access and set up your web pages when JavaScript was disabled.

Step 2: Link FlowType.js to your head section

Download FlowType.js and include it the head section of your html document.

Step 3: Call FlowType.js

Activate FlowType.js, we just need to add the following codes just before the closing tag.

Step 4: Customize FlowType.js Settings

There are some values that FlowType.js has by default, however you tweak them to the settings you want it to be set up. To do this, you just need to include some other options on your jQuery code.

   minimum   : 500,
   maximum   : 1920,
   minFont   : 16,
   maxFont   : 40,
   fontRatio : 34,
   lineRatio : 1.50

Aside from flowtype.js there are some other jQuery plugins that might help to create responsive web typography. Check out the following jQuery plugins:

  • FitText – A jQuery plugin that makes font-sizes flexible making text and headlines fluid or responsive.
  • js – A great plugin for radical web typography. It helps control the kerning of text in a just a line of jQuery code.
  • Responsive Measures – A simple script that enables you to create ideal measures for a container’s text.

What's Next?

Responsive design is becoming more and more advanced. We may think that images, layout and grids are what matters. However, we must not forget that the content or the text is what’s read by people and search engines.

Just like putting effort on layouts and images, you must also put some effort on how your text will appear. After all what matters most is that your text is readable, understandable and is easy for eyes on all viewports.

Wednesday, February 18, 2015

4 tips for a smarter CSS workflow

CSS workflow
Creating fancy CSS effects is great, says Shopify's Jonathan Snook, but it's more important to craft code that's fast and efficient.

You've only got to look at the amazing things people are making with CSS to know that, as a language, it's changing. People are creating stunning animations, and amazing images.

Whether you've been coding for years or just getting started, the landscape for CSS development has changed dramatically in the last few years too. Now, we have plenty of tools at our disposal that can help us to build lean, performant CSS.

Here Shopify's Jonathan Snook gives four top tips that will help you craft light-weight and fast CSS.

01. Identify unused code

Over time, projects change and your CSS may not have gotten with the times. Unused CSS impacts performance by sending needless code to the browser and making the browser work harder to identify what styles should be applied.

UnCSS will take a list of files and URLs, checks that each CSS rule is found in the HTML, and then spits out a CSS file that only includes the rules that are being used.

UnCSS requires compiled HTML & CSS and therefore may not be as helpful depending on your dev environment.

02. Identify duplicate code

As you build out a site, you'll set your sights on individual chunks of the design. When all is said and done, you may not have realized that many of the styles for the modal dialog were actually very similar to the styles for the drop-downs.

Using csscss, a redundancy checker, will help identify duplicate properties across all of your CSS rules. You can then consolidate your code into a single CSS rule.

03. Identify poor code

You've removed unused and duplicated code. What other improvements can we make to our CSS? Parker and analyze-css are two tools that analyze your stylesheets and provide metrics on the quality of your code.

Both Parker and analyze-css can help unearth parts of your code that you can simplify and refactor. Run these tools on a regular basis to help keep your CSS in check.

04. Write better code

Getting rid of bad code is one thing but writing good code to begin with is even better. Recently, a couple of guidelines have been written to help guide you to better code: CSS Guidelines and Sass Guidelines. Tooting my own horn, you should also check out SMACSS for ideas on how to write lean modular code for your project.

Tuesday, February 17, 2015

The When, Why and How of Designing in Browser

Designing in Browser

If you're a designer in the tech industry, you've probably been exposed to or read articles about a hot topic in design today: designing in browser. The concept is as simple as it sounds. Rather than spending hours, days, weeks and months designing those pixel-perfect comps in Photoshop, a mainstay in a waterfall-oriented development process, designing in browser allows you to take whatever sketches and preliminary work you've conducted and enables you to jump right into the text editor and emerge with shippable code.

But how do you design in browser effectively?
How do you know when the project calls for it?

Let me walk you through when, why and how you might decide to design in browser vs. doing it a more traditional way. Which, for the sake of this article, will be designing in Photoshop.

To start, my version of "designing in browser" is less "designing" and more "hacking in browser to get what you want". To me, design is solving a problem for your users. The "in browser" is just another tool in your arsenal, the fastest way to ship clean code that has a considered design via a series of collaborative meetings and sketching.

When do you design in browser?

There are many articles in the tech community that sing the praises of designing in browser — it's future of web design, we should Kill Photoshop — to name a couple. I agree that while designing in browser can be your go-to when kicking off a design project, there will be times when factors — client needs, nature of deliverable, time constraints, for instance — don't allow you to work that way. Here are some potential scenarios where you wouldn't:

The client's needs aren't suited for designing in browser. You may tell yourself, "well, just don't work with them!". But we all know this can't always be the case. Maybe the client's priority at the time is to present a highly polished website to stand out from their competitors or to get more capital from their investors. Perhaps their feature backlog is ever-changing, or they have many fundamental issues with their vision. In this case, traditional wireframing, then comping, may be the most efficient way to prototype their needs for their users.

Many clients see visuals as results. Sometimes it's more effective to deliver 10–20 high fidelity comps in one week as opposed to 1–5 working, but uninspiring, pages.

The system and layouts of the website in question are too complex to visualize and code at the same time. We're human. Most of us have limited brain capacity to think in two spheres. Whereas some may tell you that coding and designing go hand in hand, it's really tough for me to envision a complex layout with many moving parts while writing divs for it at the same time. Studies show that we suck at multitasking, and designing in browser often feels that way. Granted, time and experience will definitely make you better at visualizing faster and writing cleaner code. So keep at it.

This sometimes happens. Like, whaaaaaa?

You're in the "refinement" stage of design. Let's say you're past the point of MVP with your project. You have a working website with a decent layout, and you're ready to add more features. If your users have expressed pain points over certain design decisions you made in browser, like maybe that call to action wasn't clear enough, or they don't know what to read first on the page, it could be an opportunity to jump back into Photoshop and revisit those pain points in a thoughtful, refined way.

To me, the biggest challenge of designing in browser can be summed up by Andy Budd:

As the best design tools are the ones that put the smallest barrier between the creator and their creation (the pencil is a good example of this) designing in the browser adds an unnecessary level of cruft to the process.

Andy Budd

To add onto that: You actually enjoy the process and craft of pushing those pixels around on the artboard. Many web designers come from formal graphic design backgrounds. Taking it slow and scrutinizing over every detail is in our blood.

The reasons why we design in browser vary greatly, and the approach we take highly depends on the task that is called upon us. That being said, when the situation does call for designing in browser, here's my take on it.

How do you begin designing in browser?

There are so many ways to begin a project. Let's say for this article, I use the way philosophie typically begins a project with the product owner(s) of a newly incorporated, newly funded startup: a kickoff. Many thought leaders in design, Dan Mall for one, detail ways to facilitate a successful kickoff, so I won't go into the details here.

During our kickoff, let's say we've determined a set of users and their pain points for our product, a brand statement defining the what, why and how, a hypothesis statement that we intend to solve with our first sprint, perhaps even rudimentary wireframes or a feature list. At this point, we've gained a vague understanding of who we're designing for and what the client wants to convey to them.

I like to start off with moodboards. They help to paint the picture of the brand expression without wasting too much of my time and effort. For this, I tend to trawl Pinterest, Dribbble, whatever designer fodder I can find to curate visual options for the client.

Designing in Browser
Even if the visuals change over time, moodboards are easy to create and can act as a quick win to get the client in your favor.

From here, I pick a framework, the skeleton for which to quickly markup the layout and paste in the UI. For marketing or consumer-facing sites, I tend to prefer Foundation because the options are presented to you in the code. They're more rudimentary, in my opinion, and easier to override than Bootstrap. Bootstrap is a robust framework ideal for admin-facing applications. There's less work out of the gate with Bootstrap, but more options to painstakingly overwrite in the CSS.

Next, the style guide. Beginning with a style guide, or a series of "style tiles" is pretty important to keep your design elements organized and succinct within a design system. I won't go into the importance of style guides because the reasons have been well-explained by others, but I will say that a style guide is the easiest way to make sweeping design changes as they come down the pipeline. And that's one of the biggest reasons we design in browser in the first place. I'm accustomed to building style guide UI elements manually on an as-needed basis, but you can use KSS methodology, or even a gem like Hologram to help you automate the generation.

Designing in Browser

Finally, the composition. Something I try to keep in mind: don't lose sight of your design principles. Eye movement, hierarchy, contrast — it's easy to get lost in code. When I used to exclusively design in Photoshop, it enabled me to think more conceptually and granularly about the design: I could experiment more with new ways to call to action, a new layout, a compelling animation. Designing in browser fundamentally prevents you from thinking outside the box in that regard. The easiest way for me to do it is to go from lowest fidelity to highest. That means, plain text, then html markup, then add framework layout, then add selectors, then style selectors in CSS.

Designing in Browser
Plain text, then html markup, then add framework layout (Foundation in this case), then add selectors, then style selectors in CSS.

Using browser tools

So you've gone and created the first iteration of your site in browser, and it's time to review with the client. This is where the magic happens. Rather than the typical unending back-and-forth design loop, you can potentially take care of most to all design feedback in one meeting. Here's how I use the inspector in Chrome:

Designing in Browser

We decide to add a new content column in a section on the page. Open inspector, "edit HTML", copy and paste column. Boom, new column. Screenshot the change.

Designing in Browser

We need to increase the size of a radio button, tucked inside a form. Click magnifying glass, right click the button. The magnifying glass hones in on an element nested inside a parent. Make the changes in the styles. Screenshot.

Designing in Browser

We need to change the color of something, make something bigger, anything related to style. Edit styles, screenshot screenshot screenshot.

Designing in Browser

Note that I prefer taking screenshots over using Chrome tools to save the code. This is because using the inspector is not the way to generate the most beautiful, semantic code; it's just a cheat to experiment with a design decision or get approval from a client. Using screenshots, however, lets you preserve the change and figure out the best way to integrate that with your code base later.

Working in teams

Disclaimer: philosophie uses Pivotal Tracker as the project management tool of choice, and usually Ruby on Rails as our go-to stack.

Rather than a typical waterfall-oriented design process I described in the beginning of this story, designing in browser allows you to work in sprints with the rest of your team. The first sprint may consist of chiefly foundation or bootstrap styles. This is merely the MVP design. From there, the second sprint can slowly work on the branding, revisit typefaces, improving hierarchy, and other improvements you and your team have decided. You can even enter the refinement period here and use Photoshop, which I mentioned earlier.

As for how we integrate design stories into Pivotal Tracker, I've found that it's been effective to create user stories for front-end tasks, separate from back-end stories. This way, you can let design run ahead of development, or let the engineer create models and controllers first, leaving you to style the view. It's interchangeable.

For instance: while you as the front-end dev can create and style the static pages such as the homepage, a contact form, or text page, the back-end dev generates inputs and views for the login. Then, the front-ender can jump on the login pages and style them.

Designing in Browser
The same user story, but the view layer (front-end) is tagged and separated from the other part of the story

How has this worked in the "real world"?

On a recent client project, we determined that designing in browser was the best way to keep within budget but still deliver a fresh, clean look. I quickly mocked up layouts and pages in using Bootstrap as my framework and Sublime Text as my text editor, making low-hanging-fruit improvements where relevant. I also worked in tandem with developers as I mentioned in the previous section, taking on front-end stories and bugs while they worked on the back-end.

Midway through the process, the client wanted to explore new home page directions. Not wanting to limit myself on design, I decided that Photoshop was the best way to execute several well-composed iterations of the home page. It was relatively painless to go through a couple of rounds of feedback on just one page.

With these new styles composed in Photoshop, and with my UI elements in place, I merely had to change the styles in one place, and the whole site conformed to the new homepage design.

Concluding thoughts

There is no end-all-be-all to designing for the web. Just because you mostly design in browser doesn't mean you should give up Photoshop.

For me, the most valuable aspect of designing in browser is to curtail the pain that comes with traditional design process and to work with your team in the leanest way possible without having to sacrifice of your own design principles.

Tuesday, February 17, 2015

Frequently Used Functions in Magento Development

Magento Development
Magento is a very powerful and thus slightly difficult to tame CMS. It is built on the mighty Zend framework, and it often becomes a difficult task to create or edit Magento templates. Here in this article, I'll try to compile a brief list of useful Magento template development functions, which are used frequently during theme development. We have to cover a lot in this article, so without further ado, I'll start explaining the functions.

Sunday, September 28, 2014

All You Need To Know About Vertical-Align


Often I need to vertically align elements side by side.

CSS offers some possibilities. Sometimes I solve it with float, sometimes with position: absolute, sometimes even dirty by manually adding margins or paddings.