Node for Front-End Developers

Preface

Node.js has brought the JavaScript revolution of the past few years to the server. JavaScript, it turns out, has uses beyond the client, and many techniques for effective client-side development are applicable on the server side as well. Front-end developers can use their existing skills to work with Node today.

Depending on who you ask, there are several different definitions of “front-end developer”. Some of us deal only with client-side languages, relying on other developers to provide data and infrastructure on the server. Others create the server-side tools we need to make the front-end function, things like templates or REST interfaces. What we have in common is that we all probably understand JavaScript, and we are all probably the people responsible for implementing it on the sites we work on.

Even if you never touch server-side development in your work, Node.js is something worth your attention as a front-end developer. The arguments for using Node are well-documented, and you’re likely to hear them in the same breath you first hear it mentioned: it’s fast, it’s scalable, it’s evented, it’s already got an enthusiastic community of developers building tools. However, if you’re already used to coding in JavaScript, the most important reason to consider Node for new sites is a more subjective one: it simply gets out of your way and lets you work.

If you don’t often touch server-side development, the process of setting up an application from scratch, organizing files, setting permissions, and doing all the other configuration necessary before you start actually coding might be a bit intimidating. The nice thing about configuration, of course, is that it isn’t very hard. It just requires you to remember all of the steps, and in which order to execute them to be successful. As someone who codes websites—not someone who administers web servers—the setup bit might be kind of a painful exercise. This is the great thing about Node. You can do a lot of setup by just writing JavaScript. Adding functionality can be as easy as importing a module. Your paths, your permissions, your session tracking and data persistence are all configured by just writing JavaScript. There are no obscure menus to track down or fragile sets of instructions. You just begin writing code.

A more subtle benefit to Node, when considered from the perspective of those who work on the client-side for a living, is that it operates the same way a client-side application would. Atomic events drive the application, not long sets of instructions. It reacts to its user, rather than publishing static and unchanging information on its own schedule. Node feels more suited to the web than to the desktop, which sets it apart from other popular servers. It feels almost too light to stand alone, like a simple command-line tool instead of the basis for a web framework—and yet it does.

One of the most interesting differences in working with Node is that you can’t simply dump a bunch of files into a directory structure and make that public. Files have to be chosen explicitly or in more abstract ways for delivery to the client, and handled by your server-side JavaScript as what they are—content, templates, assets, etc. This can feel tedious when compared to most other servers, which provide the ability to serve static content automatically, but it’s easily handled on a larger scale and makes more sense for the type of single-page, client-based application that’s becoming prevalent. More and more people who’d consider themselves JavaScript developers are writing applications this way.

Note

Single-page applications communicate with the server via Ajax, so the user can remain on the same page while still saving their input and receiving updates.

Even without the abstractions and tools that have made Node so popular so quickly, creating a simple application is not difficult and should feel natural to anyone comfortable working with large JavaScript implementations. The basics of how Node serves content and performs essential server tasks are easy to pick up, and will make the popular abstractions you’d be more likely to use in a production application easier to understand.

There are more than 6,000 Node.js modules available in npm as of this writing. You could easily write an entire book covering just the most stable, but this is not that book. Once you begin building serious applications with Node, you will rely heavily on modules. This guide aims to show you how to write applications without them, to provide a better understanding of what Node does by itself, but keep in mind as you’re reading that for every problem we’ll discuss, there are a multitude of established solutions that are actively maintained, tested, and upgraded. The code samples in this book will show you the theory, but in practice you should take advantage of the excellent work already done by your fellow developers.

Conventions Used in This Book

The following typographical conventions are used in this book:

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.