A Good Front-End Architecture

Matt Carella
Matt Carella
Share

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:

  • views
    • common parts to every view
    • single views

But I am not discussing this case in this article, since I am assuming that there is only one view (an HTML file) for every page or layout in my project.

Starting from all of these preliminary considerations, this is how I decided to organize the architecture, here is my folder tree:

project
  \css
  \imgs
  \js
      \controllers
          pageOne.js
          pageTwo.js
      \libs
          angular.js
          jquery.js
          analytics.js
      \plugins
          jquery.tooltip.js
          textResize.js
          formValidation.js
      \views
          pageOne.js
          pageTwo.js
  \scss
      \framework
          _core.scss
          _forms.scss
          _input.scss
          _mixins.scss
          _variables.scss
      \layouts
          _all.scss
          _phablets.scss
          _tablets.scss
          _desktop.scss
          _desktop-large.scss
          _retina.scss

          \pageOne
              _all.scss
              _phablets.scss
              _tablets.scss
              _desktop.scss
              _desktop-large.scss
              _retina.scss

          \pageTwo
              _all.scss
              _phablets.scss
              _tablets.scss
              _desktop.scss
              _desktop-large.scss
              _retina.scss
      \libs
          _animate.scss
          _normalize.scss
          _reset.scss
      \plugins
          _jquery.tooltip.scss
          _jquery.fancyInput.scss

Folders explanations

imgs

I decided to put all images files here: .png , .jpg , .jpeg , wallpapers etc.

Examples: icon.png, home-background.jpeg, userAvatar.jpg

js (mainfolder)

I decided to put all .js files here, organized in subfolders as follows:

\ controllers (subfolder)

This is the folder for angular controllers, each one with the same name of the corresponding view. For example, if your home.html needs an angular controller, you should create a file like this: project\js\controllers\home.js.

Examples: home.js, user-registration.js, user-login.js

\ libs (subfolder)

I created this folder for javascript libraries. When I say libraries I don’t mean plugins, that’s why I decided to distinguish between the first ones and the second ones, creating two different folders.

Examples: jquery-latest.js, angular.js, googleAnalytics.js

\ plugins (subfolder)

Plugin need dependencies to work, libraries don’t. So here is why I created a different folder:

Examples: jquery-fancyInput.js, restangular.js, customPlugin.js, jquery-airport.js

\ views (subfolder)

I created this folder for all the presentational stuff. Each file has to have the same name of the corresponding view. For example if your home.html needs some effects, stuff, and plugins initializazion, you should create a file like this: project\js\views\home.js, that has its own document ready.

Examples: home-animations.js, user-registration.js,user-login.js, site-animations.js

css (main folder)

This folder contains all of the generated css from main the scss files. For example home.scss will generate the corresponding home.css file in this folder.

\ libs (subfolder)

Even for the CSS files I am distinguishing between libraries and plugins. Here are some CSS library examples:

Examples: _meyers-reset.scss, _normalize.scss,_animate.scss, _960gridSystem.scss

\ plugins (subfolder)

CSS files contained in this folder are necessary styles to make JavaScript plugins work.

Examples: _jquery-fancyInput.scss, _jqueryTooltip.scss

\ framework (subfolder)

I decided to put scss files shared across all project pages in this directory

The framework subfolder will be organized as follows:

  • _variables.scss (project variables declaration – colors, spacings, etc.)

  • _mixins.scss (project mixin declaration – typography, clearfix, animations, etc.)

  • _forms.scss (custom form styling & reset)

  • _input.scss (custom input styling & reset)

\ layouts (subfolder)

And here is the responsive part. Files in this directory are organized in that way that they cover all screens resolutions, following a mobile first principle. So, you should start declaring your own styles using _all.scss file. Rules declared in this file are valid for all screen sizes and all views. If you want your website to be adaptable, than just rewrite rules and declare them for any other screen resolution.

The folder is organized as follows:

  • phablets (481up) _phablets.scss

  • tablets and small laptops (768up) _tablets.scss

  • desktops (1030up) _desktop.scss

  • desktops with large screens (1204up) _desktop-large.scss

  • retina displays exceptions (@2x) _retina.scss

These files will handle layout exceptions and are called by mediaqueries.

Please note: those files are shared across all views (HTML pages). That’s why you need to create a new folder under scss\layouts to give a specific style to a specific page.

EXAMPLE – if you want to style a responsive home page and a responsive user-login page

  1. Create under scss\layouts a new folder naming it with the same name of the views that you want to make adaptive (ex. home and userLogin) so: scss\layouts\home and scss\layouts\userLogin

  2. Put the same files listed up above into these folders: _all.scss , _phablets.scss , _tablets.scss , _desktops.scss , _desktop-large.scss and _retina.scss.

The final result

The final result is a Yeoman generator to scaffold a responsive multipages web app or website. I also decided to include some Grunt tasks for minification, obfuscation and Sass compiling. You can have a look at it here https://github.com/mcarella/wormhole, or download it directly from NPM: https://www.npmjs.org/package/generator-wormhole.

Where to go from here

I know this is not a universal solution, maybe in your case it looks like it includes some redundancy, and I know that it cannot suit all situations, but I think it is a good starting point. You can add as many grunt tasks as you want or organize your scss in a different way, making it lighter or fatter. No matter what your aim is, I usually advice people to roll their own architecture or framework tailored on their needs, paying particular attention to performance and maintainability without neglecting user experience.

Frequently Asked Questions on Front-End Architecture

What is the importance of a good front-end architecture?

A good front-end architecture is crucial for the success of any web application. It provides a structured approach to coding, making it easier for developers to understand and maintain the code. It also enhances the performance of the application, providing a better user experience. Moreover, a well-structured front-end architecture ensures that the application is scalable and can easily accommodate future changes or additions.

How can I structure my front-end application effectively?

An effective front-end application structure should be modular, scalable, and maintainable. It should be organized in a way that separates concerns, meaning different functionalities should be kept in separate modules or components. This makes the code easier to understand, test, and maintain. Also, consider using a framework or library like React or Angular, which provides a standard structure for organizing your code.

What are some best practices for front-end development?

Some best practices for front-end development include writing clean and readable code, using a version control system, following the DRY (Don’t Repeat Yourself) principle, and testing your code regularly. Also, it’s important to keep up with the latest trends and technologies in front-end development, as the field is constantly evolving.

How can I ensure my front-end code is maintainable?

To ensure your front-end code is maintainable, it’s important to write clean, well-commented code. This makes it easier for other developers to understand your code and make changes if necessary. Also, consider using a linter to enforce a consistent coding style, and a version control system to keep track of changes.

What is the role of a front-end developer in designing the architecture of a web application?

A front-end developer plays a crucial role in designing the architecture of a web application. They are responsible for structuring the code in a way that is efficient, scalable, and maintainable. They also need to ensure that the application provides a good user experience, which involves making decisions about the layout, design, and interactivity of the application.

How does a good front-end architecture improve performance?

A good front-end architecture can significantly improve the performance of a web application. By structuring the code efficiently, you can reduce the amount of unnecessary processing and network requests, which can speed up the loading time of the application. Also, a well-structured front-end architecture can make it easier to implement performance optimization techniques, such as lazy loading and code splitting.

What tools can I use to help structure my front-end code?

There are many tools available that can help you structure your front-end code. Frameworks like React and Angular provide a standard structure for organizing your code, and also offer many useful features for building complex web applications. Linters like ESLint can help enforce a consistent coding style, and version control systems like Git can help you manage changes to your code.

How can I make my front-end code more readable?

To make your front-end code more readable, it’s important to follow good coding practices. This includes using meaningful variable and function names, writing clear and concise comments, and following a consistent coding style. Also, consider using a linter to enforce these practices and catch any potential errors or inconsistencies in your code.

How can I test my front-end code effectively?

Testing is a crucial part of front-end development. To test your front-end code effectively, you should write unit tests for individual functions or components, and integration tests to check how different parts of your application work together. Also, consider using a testing framework like Jest or Mocha, which can make the testing process easier and more efficient.

How can I keep up with the latest trends and technologies in front-end development?

Keeping up with the latest trends and technologies in front-end development can be challenging, but there are many resources available. Consider following relevant blogs, podcasts, and online communities, attending web development conferences, and taking online courses or tutorials. Also, practice regularly and try to implement new techniques or technologies in your own projects.