Originally posted on the DCS Innovation Labs Blog.
The world of frontend development is ever changing. It seems like every week there's a new "groundbreaking" framework that claims to make last week's hotness obsolete.
Just finished rewriting all my ember apps on backbone, and now I get to rewrite them all on angular. Feels good to make progress!— Hipster Hacker (@hipsterhacker) May 13, 2014
While it's impossible for any individual, or even any team to constantly keep up with all of the new tech, we also can't just sit back and dismiss it all as a fad. We may not need to rewrite all of our UIs in new frontend framework X, but some of the advancements made in frontend tooling truly can improve developer efficiency and happiness.
In this series of posts, we're going to take a look at the state of modern frontend, pull out the most useful practices and tools, and get them set up in a .NET environment on Windows, all without causing pain for the rest of your team who probably couldn't care less about how your styles and scripts are built and served as long as everything works.
My hope is that these posts will be useful for those who are curious about all of the hubub, but maybe aren't ready to commit or see it as a waste of time and energy. If you are already a skilled frontend developer, hopefully you can pick up a thing or two you haven't seen before, or at the very least get a fresh perspective from an enterprisy .NET / Windows perspective. While there are a plethora of great tools out there to help in these new practices, I'm going to be focusing on those that I have implemented here at DCS Innovation Labs because I know them well and I know that they work well in this environment.
For this first post, we're going to focus on the most applicable new frontend practices. We'll get into the specific tools, and how to use them in part 2.
In days of yore, if you wanted to use a sweet JS or CSS library, you would go to the project website and download the JS or CSS files, and drag and drop them to your project. This works well enough, but, when jQuery comes out with an important bugfix, or Bootstrap releases a new version, you aren't notified, and when you finally hear the good news, you have to go to the trouble of finding the download again. If you have one or two dependencies, this is no big deal. The problem comes with scale (as it so often does in development). I personally don't relish spending hours tracking down updates for the dozens of dependencies spread throughout all of my applications.
If you are familiar with working with .NET, then you are probably familiar with how NuGet works. You specify the packages you want, specify the versions, and it takes care of downloading / installing them. It also makes it trivial to keep them up to date at the click of a button. The frontend world also has a package manager, in fact, it has several that offer all of the same features, and more! As of now, the two most popular frontend package managers are NPM and Bower. We'll be taking a loop at NPM in part 2 of this blog series!
CSS is great but it has the potential to be so much more, and with a bit of help it can be. CSS preprocessors act as a superset of the language, adding features to it while still being 100% compatible with the original language. Any valid CSS file is also a valid SASS, SCSS, or LESS file.
I could write several posts about the benefits that these preprocessors provide, but, for the most standard use cases, there are two big ones:
Have you ever been in the situation where you want to adjust the color in a theme, only to find that you need to go and changes 50 instances of
background-color: #353535? It's a pain, and it's exceptionally easy to miss one or two and create an absolute consistency nightmare down the road. The CSS preprocessors that we will be talking about both implement variables in a very intuitive way that will be second hand to any developer.
A function in most programming languages is a way to bundle up a section of code and make it easily reusable. We can also provide parameters to these functions to alter their output. While sometimes by another name, the CSS preprocessors we will talk about implement functions that achieve the same goals by bundling up style declarations into reusable units and allowing modification via parameters.
Of course there are many more features that these preprocessors can provide and I'll touch on some of those, but I'm going to focus on variables and functions as they are the most applicable in the widest variety of situations (at least in my experience). The two most popular preprocessors at this time are Sass and Less. Stay tuned for a future blog post covering these!
These are exceptionally similar to the lambda function syntax in C#, though, immensely more useful in a language that relies so heavily on anonymous functions and callbacks.
Bundling and Minification
While this concept has been around for a while, as we utilize more frontend dependencies and move more of our application's code base to the client, this has become absolutely critical. For those new to these terms:
Most browsers have a limited number of connections (usually around 6) they can be open at once, allowing only a limited number of files to be downloaded in parallel. Because of this, reducing the count of files that need to be downloaded on a web page will allow those resources to be retrieved faster. HTTP/2 should eventually remove much of the need for this, but it is still a very relevant practice until we see HTTP/2 out in full force.
Smaller files download faster, allowing them to be run on the client's machine faster. Because of this, we want any files downloaded to the client's machine to be as small as possible.
All of these new practices are great, but unfortunately, they come with a cost. Browsers don't understand code meant for a CSS preprocessor, and many browsers still don't understand all of ECMAScript 2015. There are tools to help compile those into browser-readable formats, along with tools to help bundle and minify, but running each of these independently is painful and slow. This is where task runners come in to play. They serve as simple script runners to automate running all of the tools needed to support these new practices. At the time, the two most popular dedicated task runners are Gulp and Grunt which we will be taking a look at in a future post.
Making use of these new practices
I realize that I just told you about some awesome-sounding ideas but haven't explained how to use them. Don't worry as we'll be getting more technical in part 2, but I feel that it is important to get to a common baseline and identify the trends that really do provide every day benefit to developers.
I hope that you found this useful and that you look forward to part 2 where we'll really start to dive into how to use these tools. Hopefully you will see how valuable they could be and pick and choose the ones that will make your team more efficient and happier.