A Good Front-End Architecture

Originally published at: http://www.sitepoint.com/good-front-end-architecture/

Setting up a good front-end architecture is a fundamental step to start developing a web app or a website. Good practices and coding conventions are essential, but what about the structure? How can we conceive a good architecture that is maintainable in time? But most of all, where should we start from?

When I started thinking about the problem, I realized I needed a couple of things:


  1. I wanted a multi-page project (a web app or website).

  2. I wanted my project to support different screen sizes and resolutions, in other words: I wanted it to be responsive.

  3. I wanted the final product to be maintainable.

  4. I wanted the final product to be performant.

  5. I wanted to reuse the same template for any future project.

The right tools

Nowadays we have a lot of cool tools that can help us in a modern front-end developing workflow. So, in facing points 1 and 2 I told myself I needed a breakpoint-based CSS architecture that could help me support different devices and desktop sizes. On the other hand, I also knew that such huge amount of CSS and files could be a bit messy (and so incompatible with point 3.), that’s why I decided to start using a CSS preprocessor (which was Sass with Compass in my case).

And what about the point 4? The answer was easy: I decided to use Gruntjs. Finally, what about point 5? Even in that case, the answer was there: Yeoman, the best solution in my opinion.

Organizing the workflow

Every front-end project always includes libraries, jQuery plugins, and a lot of JavaScript and CSS files (or SCSS files in this case) for different purposes and aims. Blending all those elements means working with different technologies and putting them together means setting up a good front-end workflow. We would find ourselves having to manage a huge workflow that involves different technologies. That’s why having everything organized in folders, following a pattern or a convention in order to keep things clear and neat, is really important.

We can choose to split all fundamental front-end components in macro-groups, such as the following:


  • SCSS files

  • scripts

  • views

Can we we split them in smaller groups? Of course we can:


  • SCSS

    • variables

    • mixins

    • common parts to every layout

    • single layouts


  • js

    • libraries (such as jquery, angularjs, gAnalytics and so on…)

    • plugins (typically jquery plugins)

    • controllers (I mean controllers such as angularjs controllers)


In a templating based architecture (for example using blade.php or jade with nodejs) we can also split views as follows:

Continue reading this article on SitePoint

2 Likes

Good advice. However, back in the days of dos this would have been standard practice. Are we re-inventing the wheel or has modern computing made us lazy?

What is old hat to some will always be new to others. Instructional articles tend to be aimed at newcomers unless the topic is an emerging technology.

2 Likes

My apologies, I didn't mean to sound patronising. I mis-read the article and thought the layout was being proposed as a new technique. As instruction, it is good advice and will create a sound base to work from.

Nice article. I'm also using sass in search of a template to streamline and organize the workflow find this, FireShell

I disagree. I think having device specific stylesheets is a bad idea. Also, with the above structure, if I have phablet.scss open, I've no idea which feature it belongs to.

Instead, give your breakpoint variables sensible names and name your stylesheets by feature. Then use media queries with your breakpoint variables to style each feature per device. See how http://refills.bourbon.io/ do this. It makes for very modular code and this is the approach I always recommend, especially with large projects.

This is why I choose ExtJs as my main platform. It has it all without all the hassle.

Because of the rise of phablets I've started working with size classes, orientation and aspect ratio in tandem to determine item placement.

Landscape width breakpoints: 480, 568, 667, 768, 840, 950, 1024, 1280, 1600, 1920
Portrait width breakpoints: 320, 375, 414, 480, 600, 768, 1080, 1200
Aspects (most to least square): 5/4, 4/3, 5/3, 3/2, 16/10, 16/9

You can easily end up chasing even more and more of these numbers. "Responsibly responsive" layouts (as they are being called) needn't worry about all those numbers, but only make sure there are a few key styles ("breakpoints" if you must) to accommodate the particular layout in question.

It really depends on the design. In any event, I rarely use more than a few with a given layout. But I test most all of those dimensions.

I guess I test them by just widening and narrowing the viewport on my desktop browser—which covers all widths. These days I prefer pretty much a single column, flexible layout where breakpoints are almost (if not entirely) irrelevant. Many designers are not prepared to go that far with layout, which is understandable, but I'm less and less convinced that multi-column, elaborate layouts really offer much of use on the web.

1 Like

I used to do that, but that can miss some outliers and my QA department would invariably find something I missed. I now have Firefox DE setup to run through the 16 most common devices sizes on the market, and so far that's kept them happy.

The problem with pre-defined device breakpoints is that you never know what size the next device will be and thus you may miss the next big thing. You are always working in the past instead of looking into the future.

A few years ago the ipad didn't exist so the existing pre-defined breakpoints were useless and missed a great share of the market. Designers then added the ipad breakpoints to their system but a year later the ipad mini came out so they missed that one also.

Phones first got smaller and now they are getting bigger again. The iphone 4 was a 320px wide device but the 5 and 6 have changed again.

Chasing devices is futile in nearly all respects.

Following the method that Ralph outlined above you would have collected all those devices old and new by simply catering for the design and not the device. You won't miss anything and nothing will break because you have created a page that goes from large to small with a few well chosen design-breakpoints.

Of course some designs are awkward to code like this where the designer has essentially created a series of fixed width sites but that is a methodology that is bound to fail at some point.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.