The tech stack for front-end web development has expanded vastly in recent years. For veterans of the industry, the progression has been gradual, however for folks just starting out, these changes may not be the easiest to digest. Thus, I compiled a list of front-end tools I use on a daily basis along with the steps I’d take as a newbie to the industry.
The Basics
- Core Tech
- HTML
- CSS
- JavaScript
- Terminal
- Chrome DevTools
The foundational technologies that make up any website are HTML, CSS and JavaScript. If you’re just starting out, the Web Platform Docs and the Mozilla Developer Network are good places to look. While there’s a lot to learn with core HTML, CSS and JavaScript, a solid understanding of the basics is required, and as we’ll see in a bit, many modern tools are layered on top of these foundational technologies.
Additionally, many of the modern tools used in front-end development rely on a basic working knowledge of the command line, which on OS X is Terminal. Pluralsight has a great video by Dan Benjamin that introduces the basics of the command line. Again, its not necessary to become a command line pro to be a front-end developer, but a basic understanding of how to move around, create files & folders, and familiarity with the following will get you further than most: grep, ssh, find, curl, git, npm.
Finally, as a front-end developer, you need some way to inspect the generated HTML markup, CSS styles, and JavaScript that make up any web page you’re working on. The standard for modern web developers are the Chrome DevTools, and CodeSchool has a great course covering what you can accomplish. One item to note here: most modern websites modify the HTML markup using JavaScript. This means the text you see in your source HTML file may differ when you inspect it using the “Elements” tab in Chrome DevTools. This is a concept I became very familiar with while working with jQuery Mobile years ago (and playing with jQuery Mobile may still be a very effective tool for this purpose), but its also something you’ll encounter as you start working with some of the additional tools below.
UI (User Interface) Frameworks:
When you build websites every day, you’ll start to notice some patterns emerging in the projects you’re involved with. Components like navigation bars, buttons and labels, and pagination are all common patterns you’ll likely find yourself repeating over and over. UI frameworks are an attempt to abstract the common elements into reusable modules, so web developers can have a base starting point for the various elements used in their sites or apps.
The most popular of these, by far, is Bootstrap. Bootstrap allows you to rapidly build responsive user interfaces, and as a result is very popular both as a prototyping tool and as a production framework. The Bootstrap docs are organized such that you can become familiar with the basic CSS, progress to CSS components, and move on to the more advanced JavaScript components when you’re comfortable. It’s also worth noting that with some Bootstrap components, you’ll see generated markup that I mentioned in the previous section.
There are many more UI frameworks out there (Semantic UI, Foundation, ChocolateChip-UI, Topcoat, etc.), but one that’s really picking up steam currently is Ionic. Ionic is a mobile UI framework, focused on building iOS and Android apps using Cordova to wrap HTML code as a native app, and uses AngularJS (which we’ll get to shortly) as its JavaScript framework. We’re getting a bit ahead of ourselves, but suffice to say that if you want to build an app for iOS or Android using web technology, and learn AngularJS in the process, there’s no better way than spending some time with Ionic.
Version Control (prereq: Terminal):
You’ll want to keep a record of the work you do, and probably collaborate with other developers. Version control, or source control management, is a way you can incrementally save versions of the file or files you’re working on, and leave notes in the process, which, when grouped together, is called a commit. When you commit the code you’ve been working on it creates a version of that code locally which you can then compare at a later time to remind yourself what changes you made and when you made them. Git and Mercurial are two popular command line tools that serve this purpose. If you’re not comfortable on the command line, there are a variety of GUI applications available like GitHub’s, GitX, Git Tower, and SourceTree.
Taking this one step further, if you want to work on the same code with other developers, you can push your commits to a communal server, where everyone can access your changes. Enter GitHub. GitHub allows you to share your code with other developers, and pull down the work other developers have completed, and merge it with your changes. Overall, version control offers a very visual way to compare your work with the work of other developers, and as such is a great collaboration tool. CodeSchool has a great free course called Try Git, if you’re just getting started.
The Next Layer
Once you’ve covered the basics, there’s another layer of tools that sits on top of foundational web tools. Each of these tools requires a prerequisite understanding of the underlying technology.
Templating Languages (prereq: HTML):
HTML templating languages are an abstraction of common HTML. They exist to make writing HTML less repetitive, less error prone, and more rapid. They require an understanding of compiling the code you’re writing, which means the end result will look very different than the source code you’re editing. Both Handlebars and HAML compile to HTML.
Handlebars is most frequently paired with Backbone, and used in place of standard HTML files in Backbone applications. Rather than writing static HTML, web developers write small chunks of markup in standalone Handlebars files, that can be reused in various locations throughout a single application. Handlebars pairs nicely with Backbone as it gives developers access to data directly in the HTML markup, so you end up writing less JavaScript to get the same result.
HAML is frequently found in Ruby on Rails applications, and is a shorthand method of writing HTML that integrates directly with Ruby code. The driving factor behind HAML is that Ruby’s ERB syntax, like PHP, requires the author to “pop” in and out between writing HTML, and writing markup that will be generated by Ruby. This can lead to code that’s very difficult to read. HAML solves this issue by allowing the author to generate HTML markup without any of the repetitive angle brackets seen in both HTML and ERB.
CSS Preprocessors (prereq: CSS):
Like HTML templating languages, CSS preprocessors allow you to both write code that is compiled, and require a healthy understanding of the underlying language you’re writing (in this case, CSS). They’re very powerful, allowing web developers to write less code, reuse portions of code to decrease repetition (something very common in CSS), and modularize your CSS so you can benefit from conditionally loading CSS rules only when needed. The two most popular CSS preprocessors are Sass and Less.
Sass is an incredibly powerful language that allows developers to introduce more complex programming techniques to CSS, like variables, nesting, and mixins. Sass (and Less) have gained in popularity as the backend techniques of writing object-oriented code have migrated to the front-end. You may have heard of object-oriented CSS, and Sass is a great starting point for learning how to do some really powerful things with CSS. CodeSchool has a great introduction to Sass called Assembling Sass.
Less is an alternative to Sass, but is very similar. Basically, if you understand Sass, you’ll understand Less. There are syntactical differences, but the principles remain the same. Less is what’s used in the Twitter Bootstrap project (mentioned earlier), and as the CSS preprocessor of choice for the most popular UI framework on the planet, has become very popular itself.
JavaScript Preprocessors (prereq: JS):
Rounding out our trilogy of front-end preprocessor categories, CoffeeScript is very similar in that you write CoffeeScript, which then compiles to JavaScript. CoffeeScript is the brainchild of Jeremy Ashkenas, the author of Backbone and Underscore. The goal of CoffeeScript is to allow developers to write JavaScript that reads more like natural language, resulting in source code is very easy to read and understand. What’s actually served to the browser is vanilla JavaScript that can be very difficult to read, though more optimized for performance in a browser (also referred to as being “machine readable”).
The CoffeeScript docs are a great place to start, but there are many free and paid resources available to learn the language, like the CoffeeScript Cookbook, The Little Book on CoffeeScript, Smooth CoffeeScript, Meet CoffeeScript, A Sip of CoffeeScript, or the CoffeeScript Basics RailsCast. Of course, they all require a very good understanding of core JavaScript, so make sure you have a good grounding in the foundational language.
JavaScript Frameworks (prereq: JS):
JavaScript frameworks abstract a lot of the functionality typically left to developers to solve on their own. In the case of jQuery, its main purpose is to allow web developers to focus on the functionality they’re building, and not get distracted with browser inconsistencies with regard to JavaScript. jQuery also abstracts common JavaScript patterns, the most common of which is AJAX (short for Asynchronous JavaScript and XML). jQuery probably should be earlier in the learning stack, but an understanding of it is required to some degree in order to use portions of both AngularJS and Backbone, so I grouped it here.
Backbone and AngularJS are two of the more popular MVC or MV* JavaScript frameworks used in production today. A solid understanding of JavaScript is recommended before diving into JavaScript frameworks. They both allow developers to rapidly produce single-page applications (SPAs), albeit in very different manners. Backbone covers a core set of basic functionality and then gets out of your way, while AngularJS is more robust and opinionated.
Taking the example of AJAX, you have to first understand what AJAX is (The best guy at explaining AJAX is Jeremy Keith, hands down), then understand how the jQuery.ajax function works, in order to understand how the implementations in Backbone (Backbone.sync) and AngularJS ($http) work.
Some resources I’ve found very helpful in getting up to speed with Backbone and AngularJS include The Anatomy of Backbone.JS, Backbone.Marionette: A Gentle Introduction, AngularJS: Up and Running, Shaping Up with AngularJS and A Better Way to Learn AngularJS.
Ready to dig deeper?
Check back next Tuesday for an Intro to Advanced Front-End Developer Tools. In the meantime, let us know what you think! Any questions, thoughts, ideas? Send ’em our way!
Can’t get enough? Well here you go!
- Sass Functions: Play and Profit
- SEO for Single Page Applications
