Don’t Fear the Webpack

Complaining about things is fun.  My favorite one lately is that ‘getting a project started is so much harder now- back in the day, we just dropped a script tag at the bottom of the page and were off to the coding’.

And that used to be true- when ‘frontend development’ really just meant some form validation and simple page interactions and $ as far as the eye could see (jQuery, not money).  But the landscape has changed- grown, really.  Using modern frameworks and patterns, we can create much more interactive, responsive applications with much less work.  But with great power comes great responsibility- and in this case, that means a build process.

I dabbled in Gulp and Grunt- both were very useful- but was always intimidated by Webpack.  I think my early experiences with Angular 2 contributed to this.  Early on, Angular 2 configuration was done in SystemJS (at least in our project’s first iterations).  It was tricky and tempermental and tough to wrap my head around, but eventually, I was able to get it to work and even make useful updates.

Then we started looking at Webpack as an alternative.  I’d read some blog posts and it seemed to be the wave of the future- making things like lazy loading routes, minification, and even tree-shaking easy to handle.  But the process of manually migrating our existing project to Webpack proved to be a bit over my head.  We would need a dev server and a scss loader and a typescript config and a module loader- and this is just for the development process.  None of the awesome production build gains were even in view yet!  I had jumped in the deep end and am not a great swimmer.

When our team switched our project over to the Angular-CLI, however, Webpack came along with it.  No config necessary- the ng command takes care of that- and really does deliver on all the things (our production build version of the app became 3 times faster).  They don’t let you see the webpack.config file when you use the CLI- and that’s probably for the best in my case.  It takes care of so much that it would be quite intimidating to look at for someone just getting started with Webpack- and would be much easier to really muck things up than actually improve anything.  If/when the project is advanced enough that we need something the CLI can’t provide, then we’ll go digging.

Despite my initial intimidation, the performance gains were so good that I started looking at Webpack for my other projects.  My mistake: I started looking at config options others had used before really digging into the basics.  Sometimes this is great- getting started with Angular or React, I find it’s best to just generate a project and start experimenting with it/changing things.  It lets me see how the framework handles certain things- and if it won’t do what I want, then I can dig in to see what makes it tick.

But for Webpack to really ‘click’, I had to start from the beginning.  One current project on  my plate is updating an old php application to a node backend.  While we’re at it, we are also updating some of the frontend javascript (which was written circa 2003).  After a couple days, I discovered that it is possible to live without ES6, but I’d really rather not.  So, I installed Webpack and Babel and started from scratch.

This is part of the tradeoff I mentioned at the top of the post.  The time spent installing and configuring Webpack was not technically time moving forward with the project- no features were migrated to the new layout during that time- but the faster dev experience will more than make up for that in the end.  We get to use import statements and template strings and all that current generation javascript goodness.  Not to mention the possible performance gains when we incorporate a production build.

Webpack is for more than just single page apps, and doesn’t have to be complicated.  My project’s webpack.config file is current less than 20 lines and give me access to all ES6 and module loading (thanks to an assist from Babel).  With one line (and a couple node modules), I could add support for React/JSX transpiling as well.  It doesn’t have to be complicated- though I’m sure eventually it will.  If I want that great power (minifcation and tree-shaking and lazy loading and so on), I’ll have to extend this- but it sure was easy to get started.

module.exports = {
  entry: {
    adminPage: './static/js/src/admin/page.js',
    adminDashboard: './static/js/src/admin/dashboard.js'
  },
  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'static/js/dist')
  },
  module: {
    loaders: [
      { test: /\.js$/, loader: 'babel-loader', exclude: /node_modules/ }
    ]
  }
};

One note on the above
In the output section, the ‘filename’ property seems a bit odd. That [name] in brackets is a cool tip I learned- it automatically grabs the name of the entry property.  So, if you have more than one bundle (we will have a different one depending on the page the user is on), you can tell the output to just create a bundle with those names.  For example, in this case, the config builds two bundles: adminPage.bundle.js and adminDashboard.bundle.js.  After that, it’s up to me to remember to put the correct script tag for each bundle in the correct html file and we are good to go!

We are Willing to Learn

Great stuff.  If you’ve never seen Stripes, do yourself a favor and watch it this weekend.  Or now.

“No we’re not, but we are willing to learn.”  A great sentiment.  I listened to a great podcast the other day.  It’s called the Front End Happy Hour and it combines two of my favorite things- programming and drinking.  Anyway, they were discussing ES6 and all the cool new features.  The discussion went to knowledge and training- something I’ve found interesting lately.

With the internet at our fingertips, most info is available in seconds.  So the memorization of methods and syntax becomes far less important than 2 main factors.  1) How to apply that info, and 2) The willingness to keep learning about new info.

#1 speaks to the difference between copy/pasting some snippet of code off Stack Overflow into your app/site versus taking the time to understand how said snippet works, why you’d want to use it, and what the possible alternatives are.  You can get away with the blind copy/paste for a bit, but eventually, you’re going to have to know how it works- or know enough to recognize that an accepted answer might not work for your use case.  A personal example is regex – the few times I’ve had to write one, I’ve had to look up the syntax (thanks MDN!).  Every time- I’ve just never memorized that aspect of my job.  And it wouldn’t really make much sense to- it’s readily available and I know the basics of how the regex works and when/where to apply it (I know- the answer is ‘never’!).  Or some of the built in methods for manipulating strings – sometimes I’m writing JS, sometimes Python, sometimes C# and the call is different in each.  I’ll forget and type the wrong one, then do a quick search for the correct syntax.

#2 is what they discussed on FEHH.  It seems like every week there are new frameworks or tools to use in frontend dev.  Or the next ECMAscript release is bringing new tools.  Or there’s a new way of doing a task that you just have to know to stay current.  The willingness to learn new things becomes very important in a rapidly changing industry.  The panelists on the podcast had some really great things to say on the topic.

To bring it full circle, we come to imposter syndrome.  That heavily used term meaning that you feel like you don’t belong in the position you’re in.  I like to say I have imposter syndrome because I am, in fact, an imposter.

And it’s true- I don’t have a CS degree.  I’m not accredited by any governing body to code your Angular app or hook it up to a database.  I started learning this stuff because a job allowed it and I found it interesting.  So yes- I have to Google a lot of things during my day (point 1 above).  Why?  Because I’m still learning.  Every day.  And yes- this can lead to the feeling that I don’t really know what I’m doing.  That I’m an imposter.  But maybe the best way to combat that is to remember point #2 above.  We’re all still learning this stuff.  When you look something up and feel like you don’t really know it, dig deeper and learn about it.

Mostly incoherent ramblings, but if you take one thing away, take the link to Front End Happy Hour – it’s a good listen!