Today, the California-based product design team at ZURB announce the release of Foundation 5, the responsive web design framework that’s been adopted by millions of designers and engineers.

Designers have loved previous versions of Foundation for its mobile-first attitude and great documentation. Now a ton of features have been added and existing ones streamlined to make the framework faster, smarter and easier to learn.

“Front-end frameworks have reached the point where the next logical step is to work on efficiency and speed,” says Jonathan Smiley, a Partner at ZURB. “With Foundation 5 we wanted to pay a lot of attention to that, so we have an even better, leaner starting point for the next version.”

Here’s a rundown of what’s new and what’s improved from the ZURB team:

Faster to learn

• Foundation’s documentation has gotten a huge upgrade. There are more and better code examples, plus whole new sections so you can dig as deeply as you like.

• A new “Getting Started” guide will help new users quickly figure out how to fit the Foundation framework into their workflow.

• “Getting Started” videos have also been added.

• Connect with the Foundation community to get answers and share knowledge on a dedicated Foundation Forum.

Faster to code

• Foundation now has its own command line tool, plus it will use Libsass, a back-end Sass compiling library that will accelerate your SCSS changes by a whopping 5x.

• The team has also created its own CLI wrappers: just type ‘foundation new project-name’ and you’re off!

• New components will drastically shave off even more of manual work you need to do. For example, they’ve added a medium grid that ends the need for custom breakpoints and media queries.

• The new release comes with brand new templates.

• With Foundation Business, you can upgrade to get professional support, consulting, tools and training.

Faster for site users

• The Interchange plugin, which has allowed you to deliver different images to different devices, is now even more powerful. You’ll be able to deliver entirely different sections of the page depending on device type.

• Users will experience smoother animations and transitions as the result of Foundation’s robust support for hardware acceleration.

• The base visual style is simpler, cleaner and sexier — and quick and easy to restyle.

This is a major upgrade. Current Foundation users will find that lots of wishes have been granted. The framework remains highly responsive, Rails-friendly (but use it with any back-end) and is now more accessible than ever (fully 508 compliant).

If you’ve been waiting to check out Foundation, this may be the version that gets you going.

Are you a Foundation user? Which of the new features are you most excited to see? Let us know in the comments.

Elite Pro: 850+ Icons Usable As 13 Premium Web Fonts – only $29!

The following is a guest post by David Clark. I think David's new Sass library "Scut" is pretty interesting. It's like a design utility library, which is distinct from a design pattern library in that it enforces no particular structure or particular visual design. I've always found this kind of thing fascinating, largely because I've never been able to pull it off in a way that feels good to me. I always end up leaning too far into visual design, or too abstract to the point of it not being all that useful. I think David just might be on the right track here. I'll let him explain in detail.

I've started an open-source Sass utility library with a straightforward mission: to ease and improve our implementations of common style-code patterns. I'm calling it Scut.

Scut is a collection of Sass mixins, placeholders, functions, and variables that are generic enough to be widely reusable — within any project, any design — and easy to integrate into diverse workflows and coding conventions. Every Scut utility is an effort to reduce repetition, increase organization, and encourage the reuse and sharing of style code.

Scut is not a frontend framework, and offers no default styling: it does not concern itself with the gradients on your buttons, the padding of your boxes, the font-size of your headers, or the color of your skin. And it won't provide your vendor-prefixes: Scut's unique focus differentiates it from other preprocessor libraries. It should help you build websites — especially if you, like me, work on a lot of sites, rather than a single large app — but it doesn't do everything. It is a companion to, not a replacement for, other popular tools and practices.

I've written this article to explain my motivation, intention, and method in starting Scut, and, most of all, to seek your collaborative input.

So as you read, please keep in mind that Scut is in its infancy, and that you, dear reader, have the power to alter and improve it, whether by adding and upgrading utilities or by clarifying the principles behind them. If at any point you decide that you're ready to try it out or throw in some ideas, please head to Scut's documentation or the repository on Github.

How We Share Style-Code Now, and Why There's Room for Scut

Reusable Components: Insert Pretty Button Here

Consider Bootstrap, Foundation, PureCSS, etc. — whether we call them frontend frameworks, UI kits, design systems, or whatever else, their purpose is clear: to help developers build functional, attractive, reliable interfaces, quickly and easily, from pre-crafted components.

Even if we don't use these frameworks often, we should recognize their value and learn from them. Above all, they demonstrate the virtues of a systematic approach to site design. Mark Otto's exhortation to "Build your own Bootstrap" and Brad Frost's description of "Atomic Design" remind us that if we don't want to adopt someone else's reusable components, we should build our own bits and pieces to be equally systematic, equally reusable. Mailchimp's Pattern Library and Mapbox's Base serve as large-scale examples of that approach.

This variety of style-code sharing and reuse — the component collection, the design system — has garnered a lot of attention, and that's a good thing. But it is not the only variety; and I write all this in order say that Scut is different.

A good frontend framework helps us in many ways, but the scope of its reusability across diverse projects and designs is limited. Scut aims at a broader, more rudimentary kind of reuse — reuse not of polished components, but of the abstract, generic patterns and practices that underlie those components. (At least, those patterns and practices that are not clear and simple in vanilla CSS.)

Abstract, Generic Patterns and Practices: "Unfinished" Styling

Another way to share and reuse style code — Scut's way — involves the transmission of useful maneuvers, clever tricks, and best practices, but not finished components.

Here's the basic idea: Create and share modules that are as generic, flexible, naked as possible, so they can be used in any project to implement a useful pattern, without demanding or determining a particular environment for it.

This kind of sharing happens in two ways: tutorials and utility libraries.

Tutorials

For a paradigmatic example of The Tutorial, I refer you to this very blog, CSS-Tricks, where the eminent Chris Coyier explains and exemplifies patterns we can all apply in our own work. Then there are other blogs, books, articles, Stack Overflow answers, resources divers and sundry — more tutorials on this Internet then we know what to do with.

The writing and reading and sharing of tutorials is an indispensable practice, especially excellent because tutorials teach while they share. However, they provide practices we can reproduce rather than tools we can reuse: they disseminate knowledge, not utilities.

Utilities

The Reusable Generic Utility, Scut’s ideal constituent, is a kind of extension of The Tutorial. It turns out that many (if not most) of the styling tricks, tips, and best practices we read or write about can be abstracted into reusable utilities.

For a fine model of what I mean by "utility," consider the many functions of Underscore, the JavaScript "utility-belt" — and its offspring Lodash, of course (for this article, please just assume that "Underscore" = "Underscore or Lodash, whatever you prefer"). Let me explain: I've been reading Eloquent Javascript, by Marijn Haverbeke, and the other night I encountered a common, useful pattern called the "reduce" or "fold" function. In the tutorial tradition, Haverbeke explains what a "reduce" function does and shows me how to make one. So I could write my own — we could all write our own ... But Underscore already has a "reduce" function that we can all use — and since Underscore's function has run the open-source gauntlet, it's going to be better than whatever I might produce on my own (though I can't speak for you, in all your wisdom). As much as I benefit from the knowledge gained, I often gain even more by pairing that knowledge with an open-source utility.

In the world of style code, the best way to collaboratively create a similar utility collection is with a preprocessor library. (Two significant advantages of preprocessor tools over class collections are (1) that they have variability built in, and (2) that they only impact your final stylesheet, what's served to the client, when they are actually used.) So: enter Scut.

Let's parallel the JavaScript "reduce" example above with some style code. On CSS-Tricks, there's an immensely useful article, "Centering in the Unknown," about centering elements with indeterminate dimensions. The trickiest part is the vertical centering. After reading this article, I know about the method of setting display: table; on the parent element and display: table-cell; vertical-align: middle; on the to-be-centered child. And that's fantastic: it's a valuable trick to learn. But let's not stop there. To extend that tutorial and create a reusable, shareable utility, I can write a Sass mixin — something like this:

@mixin vertically-center ($child: ".vcentered") {
      display: table;
      & > #{$child} {
        display: table-cell;
        vertical-align: middle;
      }
    }

Apply this mixin to the parent; pass the to-be-centered child's selector as the argument (or give that child the default class vcentered); and you have achieved vertical centering — and done so by creating a tool that can be reused and shared.

Essentially, we're doing the same thing with CSS (by way of Sass) that Underscore does with JavaScript. Put together a bunch of these utilities, expose them to the open-source community, and you should end up with a helpful library.

(By the way, Scut provides three different methods of vertical centering, each one fitted for different contexts.)

I'll explain more about the methodology of Scut's utilities below; but first, you may be asking ...

What About Existing Preprocessor Libraries?

If you're a regular reader of CSS-Tricks, you've probably heard of Compass and Bourbon. There are other Sass libraries, and LESS and Stylus have spawned their own. These libraries exist already, bolstered by strong communities, and work splendidly; they do offer "abstract, generic patterns and practices" — so why build another? Because, from what I've seen, the existing preprocessor libraries have focused heavily on vendor-prefixing and legacy-browser support, without offering many reusable style patterns. (Some, yes, but not many.) Valuable as they are, they are also, like all things under the sun, limited.

Their limitations jumped out at me when I started using Autoprefixer. (If you haven't done so already, I suggest reading Andrey Sitnik's guest post on CSS-Tricks.) I had tried Compass and was using Bourbon regularly; but with my vendor-prefixing taken care of by Autoprefixer, Compass and Bourbon no longer seemed very useful. They offered a few helpers that I would invoke now and again, but not regularly.

I started to wonder what else a preprocessor library might be good for. And that led to the idea behind Scut — a preprocessor library that ignores vendor-prefixing in order to focus exclusively on abstract styling patterns.

The Principles and Purposes of Scut

What Problems do Scut Utilities Solve?

Scut utilities should epitomize the key benefits of CSS preprocessors. I'll list my favorites:

The Key Benefits of The CSS Preprocessor — which are also The Key Benefits of The Scut Utility:

• It helps me avoid repetition. Instead of typing the same code in various places, I use a mixin, extend, function, or variable, and my code becomes less annoying to type; more accurate — less vulnerable to typos and inadvertent variations; and easier to change and maintain — since each important part resides in one place only.
• It helps me organize code, by grouping associated rules into named patterns — so instead of tangled lists of various rules contributing in various ways to a component's appearance, I see which rules relate to which specific effects.
• It helps me reuse code (as explained above).

Additionally, the pattern that a Scut utility implements should suffer from one or more of the following problems — and the utility should, of course, solve that problem:

1. The pattern is non-intuitive

The CSS rules required don't explain themselves. There's some kind of trick involved: you must have been initiated to decipher the code. Also, because there's a trick, the pattern is hard to remember. Unless you've executed the operation a hundred times already, you probably have to look up instructions on somebody's blog; and even then, you'll need to do some thinking, experimenting, and tweaking to get it right again.

To illustrate: You may want to create an element of fluid dimensions with a fixed aspect ratio — let's say 16/9. After some searching, you've found a method that works — but you may not see why just by looking at the CSS:

.parent-element {
      overflow: hidden;
      position: relative;
    }
    .parent-element:before {
      content: "";
      display: block;
      height: 0; /* Huh? */
      padding-top: 56.25%; /* Wha? */
    }
    .parent-element > .child-element {
      position: absolute;
      left: 0;
      top: 0;
      width: 100%;
      height: 100%; /* Filling a container with zero height? */
    }

Use a Scut mixin, instead, and a glance at your code will make sense:

.parent-element {
      @include scut-ratio-box(16/9, ".child-element");
    }

The mixin organizes and names the pattern — and also, of course, saves you from repeating the complicated mess if you need a different ratio-box elsewhere.

For another example, consider the renowned CSS triangle. Without some explanation, the required style code is obscure. To make a blue right-pointing triangle 50px tall and 50px wide:

.triangle-right {
      width: 0; 
      height: 0; /* A shape with no dimensions? */
      border-top: 25px solid transparent; /* Why 25px here? */
      border-bottom: 25px solid transparent; /* Who needs invisible borders? */
      border-left: 50px solid blue; /* My right-pointing triangle is a left border? */
    }

The trick is ancient and venerable, and well documented in tutorials around the web. (Chris Coyier recently produced a clever animation to explain how and why it works at all.) So maybe you've read some things, you get it, you pull it off yourself. Still, despite your magnificence, the benefit of a good mixin should be clear, to transform the code above into a single intelligible line:

.triangle-right {
      @include scut-triangle(right, 50px, blue);
    }

And what if you want to build a more complex shape that involves multiple triangles — triangles that are themselves a little more complicated? Then the mixin becomes even more valuable:

2. The pattern deserves a shorthand

The pattern may be easy enough to write yourself — not complicated, plenty intuitive — but it consists of a set of rules that can be usefully and regularly grouped into a named shorthand.

(Of course, vanilla CSS already incorporates some shorthands. Scut just adds more.)

For example, Scut includes some positioning mixins: instead of —

position: absolute;
    top: 1em;
    right: 2em;
    bottom: 3em;
    left: 4em;

— you can use scut-absolute and write —

@mixin scut-absolute(1em 2em 3em 4em)

3. The pattern involves some important best practices

You may think you know how to do it yourself — but unless you're In The Know and have read all the right things, you may not be doing it the best way. And even if you knew the best way once, in your heyday, you may have since forgotten or missed some game-changing innovations.

There's nothing like an open-source library to take care of this problem. In fact, best practices is one of the areas where existing preprocessor libraries are pretty strong. So Scut's best-practice utilities — like scut-font-face, scut-clearfix, and scut-hd-bp (for resolution-based media queries) — resemble some mixins you'll find in Bourbon and Compass.

4. The pattern is extremely common and a little annoying

You use the pattern consistently — every project, usually multiple times per project. And every time, something in your mind mutters "Again?" and a dark psychic cloud passes over your psychic sun, a transient awareness that you're a few keystrokes closer to death.

If I had a dime for every time I nullified margin, padding, and list-style-type on an unstyled-list — O! the sandwiches I could buy —— So some of Scut's first utilities were scut-list-unstyled and its common variations, scut-list-inline and scut-list-floated, exemplified below (with various "skins" applied, to demonstrate how an abstract utility should be able to apply in all kinds of design situations):

How Do You Make a Scut Utility?

In short: maximize reusability. Reusability is what distinguishes a library-ready utility from a project-specific one.

Include sufficient detail to implement the pattern, but no more. The utility alone should not produce a passable component. Again, Scut isn't about passing around well-constructed, finished designs: it's about facilitating the construction and finishing of unique designs.

Use arguments to allow for typical variations on the theme. Whenever reasonable, include conservative default values for those arguments — so users may not have to enter every argument every time — and arrange those arguments according to the order in which they're likely to be changed. Additionally, use @content blocks, when they make sense, if you expect regular customizations that won't fit into arguments.

Namespace, to prevent conflicts with other libraries and project-specific code. Scut adds a scut- prefix to all its pieces. That way, we can include a "clearfix" utility in Scut without worrying that it will conflict with Bourbon or Compass clearfixes (which aren't namespaced). And we can use generic utility names like "size" (scut-size), generic variable names like "circle" (scut-circle), without disturbing the natural balance.

Lastly: document thoroughly, document well. I'm trying hard to do that with Scut's docs — and I would, of course, appreciate your input and advice. We've all been frustrated by documentation — we've all known that pain — so we all recognize that the effective reusability of a tool directly relates to the quality of its documentation.

Now To Address Some Reservations

I don't use Sass

Whatever your workflow, whatever choices you've made, good or bad, Scut can probably help, at least a little. If you don't use Sass, you might still look into the open-source code and either port it (to your preprocessor-of-choice) or read it, along with Scut's documentation, as a series of mini-tutorials, a kind of style-pattern reference.

I Love OOCSS and Cannot Serve Two Masters

Object-Oriented CSS (OOCSS) and Scut address similar problems with similar solutions: namely, extendable patterns (or "objects"). But they are by no means the same. Perhaps you're an OOCSS aficionado, and you consider all these mixins and extends to be inefficient nonsense. You want a "clearfix" class, not a mixin that will duplicate code, or a bunch of `@extend` directives that will clutter your compiled CSS. You want to make your triangles with classlists like triangle triangle-large triangle-down triangle-red, not one triangle mixin invoked multiple times with different arguments.

Well, that's OK. There's no need to argue here over the virtues of preprocessors versus those of class-heavy coding conventions, semantic versus presentational classnames, etc., because Scut doesn't preclude OOCSS-style coding, or any other style: simply summon Scut's utilities as needed to help create the classes for your objects and their extensions.

I Don't Like Some of Scut's Utilities

Let me know what needs to change (file an issue on Github), and we can work together to build a better Scut.

Keep in mind, also, that some of the current utilities are more experimental than others. As Scut stumbles through its unstable youth (v0.x.x), I'm looking for collaborators who are interested in figuring out what works and what doesn't, which utilities will improve a project's codebase and which might make it more cryptic and harder to maintain.

I Think This Whole Idea Is Stupid

Again, you're welcome to tell me what you would do differently. Show me how it's done. Or else you can go your separate way, do something you enjoy to cheer yourself up again — eat some pie, ride a bicycle — and forget you ever read this.

Curious? Convinced? Confused? Try Using and Contributing to Scut

I hope I've said enough, by now, to convince you to look into Scut, maybe tinker with it a little — or even, dare I wish, contribute.

If you're ready for a trial run, Scut's documentation will tell you how to install and apply the library. (Basically, use Bower or download the latest release on Github, then @import into your Sass. Easy as can be.)

And if you're thinking you may want to donate some modicum of your own brilliance to the project, please don't hesitate. Go for it. Scut is a simple library, an easy open-source contribution — which could be especially nice for those of us who work primarily in HTML and CSS and feel wary of wading into other Github projects. Scut is all about making your work, my work, and the work of other developers easier, maybe even a little bit better; extending tutorials into reusable utilities; encouraging best practices; and sharing good ideas — goals we can agree on. I hope you'll find it a worthy experiment.

Introducing Scut, a new Sass utility library is a post from CSS-Tricks

Nowadays, with any Web app you build, you have dozens of architectural decisions to make. And you want to make the right ones: You want to use technologies that allow for rapid development, constant iteration, maximal efficiency, speed, robustness and more. You want to be lean and you want to be agile. You want to use technologies that will help you succeed in the short and long term. And those technologies are not always easy to pick out.

In my experience, full-stack JavaScript hits all the marks. You’ve probably seen it around; perhaps you’ve considered its usefulness and even debated it with friends. But have you tried it yourself? In this post, I’ll give you an overview of why full-stack JavaScript might be right for you and how it works its magic.

To give you a quick preview:

(Large view)

I’ll introduce these components piece by piece. But first, a short note on how we got to where we are today.

Why I Use JavaScript

I’ve been a Web developer since 1998. Back then, we used Perl for most of our server-side development; but even since then, we’ve had JavaScript on the client side. Web server technologies have changed immensely since then: We went through wave after wave of languages and technologies, such as PHP, ASP, JSP, .NET, Ruby, Python, just to name a few. Developers began to realize that using two different languages for the client and server environments complicates things.

In the early era of PHP and ASP, when template engines were just an idea, developers embedded application code in their HTML. Seeing embedded scripts like this was not uncommon:

    <script>
        <?php
            if ($login == true){
        ?>
        alert("Welcome");
        <?php
            }
        ?>
    </script>
    

Or, even worse:

    <script>
        var users_deleted = [];
        <?php
            $arr_ids = array(1,2,3,4);
            foreach($arr_ids as $value){
        ?>
        users_deleted.push("<php>");
        <?php
            }
        ?>
    </script>
    

For starters, there were the typical errors and confusing statements between languages, such as for and foreach. Furthermore, writing code like this on the server and on the client to handle the same data structure is uncomfortable even today (unless, of course, you have a development team with engineers dedicated to the front end and engineers for the back end — but even if they can share information, they wouldn’t be able to collaborate on each other’s code):

    <?php
        $arr = array("apples", "bananas", "oranges", "strawberries"),
        $obj = array();
        $i = 10;
        foreach($arr as $fruit){
            $obj[$fruit] = $i;
            $i += 10;
        }
        echo json_encode(obj);
    ?>
    <script>
        $.ajax({
            url:"/json.php",
            success: function(data){
                var x;
                for(x in data){
                    alert("fruit:" + x + " points:" + data[x]);
                }
            }
        });
    </script>
    

The initial attempts to unify under a single language were to create client components on the server and compile them to JavaScript. This didn’t work as expected, and most of those projects failed (for example, ASP MVC replacing ASP.NET Web forms, and GWT arguably being replaced in the near future by Polymer). But the idea was great, in essence: a single language on the client and the server, enabling us to reuse components and resources (and this is the keyword: resources).

The answer was simple: Put JavaScript on the server.

JavaScript was actually born server-side in Netscape Enterprise Server, but the language simply wasn’t ready at the time. After years of trial and error, Node.js finally emerged, which not only put JavaScript on the server, but also promoted the idea of non-blocking programming, bringing it from the world of nginx, thanks to the Node creator’s nginx background, and (wisely) keeping it simple, thanks to JavaScript’s event-loop nature.

(In a sentence, non-blocking programming aims to put time-consuming tasks off to the side, usually by specifying what should be done when these tasks are completed, and allowing the processor to handle other requests in the meantime.)

Node.js changed the way we handle I/O access forever. As Web developers, we were used to the following lines when accessing databases (I/O):

    var resultset = db.query("SELECT * FROM 'table'");
    drawTable(resultset);
    

This line essentially blocks your code, because your program stops running until your database driver has a resultset to return. In the meantime, your platform’s infrastructure provides the means for concurrency, usually using threads and forks.

With Node.js and non-blocking programming, we’re given more control over program flow. Now (even if you still have parallel execution hidden by your database (I/O) driver), you can define what the program should do in the meantime and what it will do when you receive the resultset:

    db.query("SELECT * FROM 'table'", function(resultset){
       drawTable(resultset);
    });
    doSomeThingElse();
    

With this snippet, we’ve defined two program flows: The first handles our actions just after sending the database query, while the second handles our actions just after we receive our resultSet using a simple callback. This is an elegant and powerful way to manage concurrency. As they say, “Everything runs in parallel — except your code.” Thus, your code will be easy to write, read, understand and maintain, all without your losing control over program flow.

These ideas weren’t new at the time — so, why did they become so popular with Node.js? Simple: Non-blocking programming can be achieved in several ways. Perhaps the easiest is to use callbacks and an event loop. In most languages, that’s not an easy task: While callbacks are a common feature in some other languages, an event loop is not, and you’ll often find yourself grappling with external libraries (for example, Python with Tornado).

But in JavaScript, callbacks are built into the language, as is the event loop, and almost every programmer who has even dabbled in JavaScript is familiar with them (or at least has used them, even if they don’t quite understand what the event loop is). Suddenly, every startup on Earth could reuse developers (i.e. resources) on both the client and server side, solving the “Python Guru Needed” job posting problem.

So, now we have an incredibly fast platform (thanks to non-blocking programming), with a programming language that’s incredibly easy to use (thanks to JavaScript). But is it enough? Will it last? I’m sure JavaScript will have an important place in the future. Let me tell you why.

Functional Programming

JavaScript was the first programming language to bring the functional paradigm to the masses (of course, Lisp came first, but most programmers have never built a production-ready application using it). Lisp and Self, Javascript’s main influences, are full of innovative ideas that can free our minds to explore new techniques, patterns and paradigms. And they all carry over to JavaScript. Take a look at monads, Church numbers or even (for a more practical example) Underscore’s collections functions, which can save you lines and lines of code.

Dynamic Objects and Prototypal Inheritance

Object-oriented programming without classes (and without endless hierarchies of classes) allows for fast development — just create objects, add methods and use them. More importantly, it reduces refactoring time during maintenance tasks by enabling the programmer to modify instances of objects, instead of classes. This speed and flexibility pave the way for rapid development.

JavaScript Is the Internet

JavaScript was designed for the Internet. It’s been here since the beginning, and it’s not going away. All attempts to destroy it have failed; recall, for instance, the downfall of Java Applets, VBScript’s replacement by Microsoft’s TypeScript (which compiles to JavaScript), and Flash’s demise at the hands of the mobile market and HTML5. Replacing JavaScript without breaking millions of Web pages is impossible, so our goal going forward should be to improve it. And no one is better suited for the job than Technical Committee 39 of ECMA.

Sure, alternatives to JavaScript are born every day, like CoffeeScript, TypeScript and the millions of languages that compile to JavaScript. These alternatives might be useful for development stages (via source maps), but they will fail to supplant JavaScript in the long run for two reasons: Their communities will never be bigger, and their best features will be adopted by ECMAScript (i.e. JavaScript). JavaScript is not an assembly language: It’s a high-level programming language with source code that you can understand — so, you should understand it.

End-to-End JavaScript: Node.js And MongoDB

We’ve covered the reasons to use JavaScript. Next, we’ll look at JavaScript as a reason to use Node.js and MongoDB.

Node.js

Node.js is a platform for building fast and scalable network applications — that’s pretty much what the Node.js website says. But Node.js is more than that: It’s the hottest JavaScript runtime environment around right now, used by a ton of applications and libraries — even browser libraries are now running on Node.js. More importantly, this fast server-side execution allows developers to focus on more complex problems, such as Natural for natural language processing. Even if you don’t plan to write your main server application with Node.js, you can use tools built on top of Node.js to improve your development process; for example, Bower for front-end package management, Mocha for unit testing, Grunt for automated build tasks and even Brackets for full-text code editing.

So, if you’re going to write JavaScript applications for the server or the client, you should become familiar with Node.js, because you will need it daily. Some interesting alternatives exist, but none have even 10% of Node.js’ community.

MongoDB

MongoDB is a NoSQL document-based database that uses JavaScript as its query language (but is not written in JavaScript), thus completing our end-to-end JavaScript platform. But that’s not even the main reason to choose this database.

MongoDB is schema-less, enabling you to persist objects in a flexible way and, thus, adapt quickly to changes in requirements. Plus, it’s highly scalable and based on map-reduce, making it suitable for big data applications. MongoDB is so flexible that it can be used as a schema-less document database, a relational data store (although it lacks transactions, which can only be emulated) and even as a key-value store for caching responses, like Memcached and Redis.

Server Componentization With Express

Server-side componentization is never easy. But with Express (and Connect) came the idea of “middleware.” In my opinion, middleware is the best way to define components on the server. If you want to compare it to a known pattern, it’s pretty close to pipes and filters.

The basic idea is that your component is part of a pipeline. The pipeline processes a request (i.e. the input) and generates a response (i.e. the output), but your component isn’t responsible for the entire response. Instead, it modifies only what it needs to and then delegates to the next piece in the pipeline. When the last piece of the pipeline finishes processing, the response is sent back to the client.

We refer to these pieces of the pipeline as middleware. Clearly, we can create two kinds of middleware:

• Intermediates
  An intermediate processes the request and the response but is not fully responsible for the response itself and so delegates to the next middleware.
• Finals
  A final has full responsibility over the final response. It processes and modifies the request and the response but doesn’t need to delegate to the next middleware. In practice, delegating to the next middleware anyway will allow for architectural flexibility (i.e. for adding more middleware later), even if that middleware doesn’t exist (in which case, the response would go straight to the client).

(Large view)

As a concrete example, consider a “user manager” component on the server. In terms of middleware, we’d have both finals and intermediates. For our finals, we’d have such features as creating a user and listing users. But before we can perform those actions, we need our intermediates for authentication (because we don’t want unauthenticated requests coming in and creating users). Once we’ve created these authentication intermediates, we can just plug them in anywhere that we want to turn a previously unauthenticated feature into an authenticated feature.

Single-Page Applications

When working with full-stack JavaScript, you’ll often focus on creating single-page applications (SPAs). Most Web developers are tempted more than once to try their hand at SPAs. I’ve built several (mostly proprietary), and I believe that they are simply the future of Web applications. Have you ever compared an SPA to a regular Web app on a mobile connection? The difference in responsiveness is in the order of tens of seconds.

(Note: Others might disagree with me. Twitter, for example, rolled back its SPA approach. Meanwhile, large websites such as Zendesk are moving towards it. I’ve seen enough evidence of the benefits of SPAs to believe in them, but experiences vary.)

If SPAs are so great, why build your product in a legacy form? A common argument I hear is that people are worried about SEO. But if you handle things correctly, this shouldn’t be an issue: You can take different approaches, from using a headless browser (such as PhantomJS) to render the HTML when a Web crawler is detected to performing server-side rendering with the help of existing frameworks.

Client Side MV* With Backbone.js, Marionette And Twitter Bootstrap

Much has been said about MV* frameworks for SPAs. It’s a tough choice, but I’d say that the top three are Backbone.js, Ember and AngularJS.

All three are very well regarded. But which is best for you?

Unfortunately, I must admit that I have limited experience with AngularJS, so I’ll leave it out of the discussion. Now, Ember and Backbone.js represent two different ways of attacking the same problem.

Backbone.js is minimal and offers just enough for you to create a simple SPA. Ember, on the other hand, is a complete and professional framework for creating SPAs. It has more bells and whistles, but also a steeper learning curve. (You can read more about Ember.js here.)

Depending on the size of your application, the decision could be as easy as looking at the “features used” to “features available” ratio, which will give you a big hint.

Styling is a challenge as well, but again, we can count on frameworks to bail us out. For CSS, Twitter Bootstrap is a good choice because it offers a complete set of styles that are both ready to use out of the box and easy to customize.

Bootstrap was created in the LESS language, and it’s open source, so we can modify it if need be. It comes with a ton of UX controls that are well documented. Plus, a customization model enables you to create your own. It is definitely the right tool for the job.

Best Practices: Grunt, Mocha, Chai, RequireJS and CoverJS

Finally, we should define some best practices, as well as mention how to implement and maintain them. Typically, my solution centers on several tools, which themselves are based on Node.js.

Mocha and Chai

These tools enable you to improve your development process by applying test-driven development (TDD) or behavior-driven development (BDD), creating the infrastructure to organize your unit tests and a runner to automatically run them.

Plenty of unit test frameworks exist for JavaScript. Why use Mocha? The short answer is that it’s flexible and complete.

The long answer is that it has two important features (interfaces and reporters) and one significant absence (assertions). Allow me to explain:

• Interfaces
  Maybe you’re used to TDD concepts of suites and unit tests, or perhaps you prefer BDD ideas of behavior specifications with describe and should. Mocha lets you use both approaches.
• Reporters
  Running your test will generate reports of the results, and you can format these results using various reporters. For example, if you need to feed a continuous integration server, you’ll find a reporter to do just that.
• Lack of an assertion library
  Far from being a problem, Mocha was designed to let you use the assertion library of your choice, giving you even more flexibility. You have plenty of options, and this is where Chai comes into play.

Chai is a flexible assertion library that lets you use any of the three major assertion styles:

• assert
  This is the classic assertion style from old-school TDD. For example:

  
      assert.equal(variable, "value");
      

• expect
  This chainable assertion style is most commonly used in BDD. For example:

  
      expect(variable).to.equal("value");
      

• should
  This is also used in BDD, but I prefer expect because should often sounds repetitive (i.e. with the behavior specification of “it (should do something…)”). For example:

  
      variable.should.equal("value");
      

Chai combines perfectly with Mocha. Using just these two libraries, you can write your tests in TDD, BDD or any style imaginable.

Grunt

Grunt enables you to automate build tasks, anything including simple copying-and-pasting and concatenation of files, template precompilation, style language (i.e. SASS and LESS) compilation, unit testing (with Mocha), linting and code minification (for example, with UglifyJS or Closure Compiler). You can add your own automated task to Grunt or search the registry, where hundreds of plugins are available (once again, using a tool with a great community behind it pays off). Grunt can also monitor your files and trigger actions when any are modified.

RequireJS

RequireJS might sound like just another way to load modules with the AMD API, but I assure you that it is much more than that. With RequireJS, you can define dependencies and hierarchies on your modules and let the RequireJS library load them for you. It also provides an easy way to avoid global variable space pollution by defining all of your modules inside functions. This makes the modules reusable, unlike namespaced modules. Think about it: If you define a module like Demoapp.helloWordModule and you want to port it to Firstapp.helloWorldModule, then you would need to change every reference to the Demoapp namespace in order to make it portable.

RequireJS will also help you embrace the dependency injection pattern. Suppose you have a component that needs an instance of the main application object (a singleton). From using RequireJS, you realize that you shouldn’t use a global variable to store it, and you can’t have an instance as a RequireJS dependency. So, instead, you need to require this dependency in your module constructor. Let’s see an example.

In main.js:

      define(
          ["App","module"],
          function(App, Module){
              var app = new App();
    
              var module = new Module({
                  app: app
              })
    
              return app;
          }
      );
    

In module.js:

      define([],
          function(){
              var module = function(options){
                  this.app = options.app;
              };
              module.prototype.useApp = function(){
                  this.app.performAction();
              };
              return module
          }
      );
    

Note that we cannot define the module with a dependency to main.js without creating a circular reference.

CoverJS

Code coverage is a metric for evaluating your tests. As the name implies, it tells you how much of your code is covered by your current test suite. CoverJS measures your tests’ code coverage by instrumenting statements (instead of lines of code, like JSCoverage) in your code and generating an instrumented version of the code. It can also generate reports to feed your continuous integration server.

Conclusion

Full-stack JavaScript isn’t the answer to every problem. But its community and technology will carry you a long way. With JavaScript, you can create scalable, maintainable applications, unified under a single language. There’s no doubt, it’s a force to be reckoned with.

(al, ea)

© Alejandro Hernandez for Smashing Magazine, 2013.

This is Gallery image