Lesson Weekend

Imagine we're part of a development team working on a huge application. The application is live and thousands of people visit our site everyday. It has hundreds of pages, JavaScript files, and dependencies. After all, it's a huge site and many people use it!

Now imagine our site uses only the HTML, CSS and JavaScript techniques we've covered so far. Our index.html page has one hundred script tags in it, each representing a JavaScript file or dependency we need. This would be very messy and hard to work with. A single small change to a file could break everything.

There'd also be another huge problem: our site would be incredibly slow. Each file we load has its own overhead. When multiplied over many files, that overhead quickly adds up and leads to lost customers and lost revenue. Our customers expect the site to load as quickly as possible and it should be reliable!

We can actually get a sense of how many resources a site is loading via the Network tab in Chrome Dev Tools. This tab shows how all the resources that are being uploaded and downloaded when we visit a page. We can open Chrome Dev Tools, click on the Network tab, and then visit any site we like to see this exchange of resources.

Let's take a look at Flickr's home page:

This shows all the resources being downloaded to the browser for Flickr's splash page.

That's a ton of resources! And that's just for Flickr's splash page - without even logging in.

Modern JavaScript Development

Welcome to the world of modern JavaScript development. Performance and reliability are extremely important. It's essential to optimize our applications so they run faster, whether in production or development. A site like Flickr seamlessly downloads photos, giving users a good experience. It's simply not possible to build such resource-intensive sites efficiently with just the basic tools we've been using so far.

As our applications grow bigger, we need to consider two very important issues. We need to make our lives easier, not harder, as developers. However, we also need to make our applications faster, too. However, these two goals often conflict with each other. Here are some examples:

  • With very large applications, it's much easier to organize and understand the code if we break it down into smaller files. Better for developers! However, because each file has additional overhead to load, it takes longer for our machines to process them. Not so great for having fast, efficient applications...

  • Clear variable names and easy-to-read syntax help developers write, read, and reason about code. However, our machines don't care whether a variable is named veryClearlyNamed or x. But there's one significant difference between the two - x takes less space. To make our applications load faster, our files should be smaller if possible. But that's hard for developers to read...

For example, take a look at a small chunk of minified jQuery:

!function(e,t){"use strict";"object"==typeof module&&"object"==typeof module.exports?module.exports=e.document?t(e,!0):function(e){if(!e.document)throw new Error("jQuery requires a window with a document");return t(e)}:t(e)}("undefined"!=typeof window?window:this,function(C,e){"use strict";var t=[],r=Object.getPrototypeOf,s=t.slice,g=t.flat?function(e){return t.flat.call(e)}:function(e){return t.concat.apply([],e)},u=t.push,i=t.indexOf,n={},o=n.toString,v=n.hasOwnProperty,a=v.toString,l=a.call(Object),y={},m=function(e){return"function"==typeof e&&"number"!=typeof e.nodeType},x=function(e){return null!=e&&e===e.window},E=C.document,c={type:!0,src:!0,nonce:!0,noModule:!0};function b(e,t,n){var r,i,o=(n=n||E).createElement("script");if(o.text=e,t)for(r in c)

Good luck reading and understanding that! The code above isn't for humans - but rather to make the files smaller so our machines can load them more quickly. It has automatically been minified (made smaller) to keep the file size as small as possible.

We can address the issues above by separating our code into development and production environments. Code in a development environment is convenient for developing - easier to read and work with but slower. Code in a production environment is easier for machines to work with and much more efficient.

Because we aren't building polished, production-ready applications yet, we'll be focused on working in a development environment. Even so, we will still utilize tools to make our code more efficient and our lives easier as developers.

Here are some of the tools we'll add in the following lessons:

  • npm (Node Package Manager) will allow us to easily install and manage JavaScript packages in our projects.

  • webpack is a module bundler that will concatenate and minify our code. That means we can write code that's easy for developers to read. webpack will automatically concatenate all our files into just one file and then minify the code (like the jQuery example above). We can use webpack to add lots of other useful functionality to our projects as well.

  • Jest will allow us to run automated tests to ensure our code is working correctly.

  • html-webpack-plugin will allow us to easily generate HTML templates.

  • webpack-dev-server will automatically reload our code in the browser as we make changes to it. Great for development!

  • eslint will automatically notify us when our code is poorly-written and has errors - helping us quickly identify and fix bugs.

We'll do all of these things this week and more. In the process, we'll learn how to use new JavaScript features that were released with ES2015 (EcmaScript 2015, the latest stable release of JavaScript).

One Last Thing...

The next two sections of class are going to look and feel very different from the work we've been doing. Specifically, these sections are a big step up in terms of difficulty. Up until this point, we've been taking things slowly and focusing on learning the fundamentals. From this point on, we're going to be writing our code the same way it's done in a professional setting. We're about to jump into the deep end.

Creating a development environment can feel very abstract and it's often difficult to debug when things go awry. This is a common feeling among developers both new and experienced. You may feel frustrated while going through these examples but keep pressing forward. While struggling through this material may feel frustrating at times, there is no other way to get comfortable with setting up and problem-solving environments than to just jump in. Do your best, accept partial understanding, and know that your efforts will benefit you not just at Epicodus but also in the programming industry. Right now, we are building the toolset we need to succeed as developers. That includes problem-solving, being patient with ourselves, managing frustration, and learning how to be comfortable even when we feel like we are in over our heads.

Lesson 2 of 48
Last updated more than 3 months ago.