In this episode of The Rabbit Hole we tackle the world of front end build systems. The field has come along very quickly and things have developed at an almost breakneck space with new systems and frameworks popping up all around us. We welcome Jonathan Belcher to help us break down the current climate and look back at some of the landmark events in recent front end history. We talk about Grunt and Node and then move on to some of the more recent tools that have entered the field. We also look at task running and the effect of the combinations of today’s systems. Jonathan gives us great insight into possible futures for the field before we weigh the involvement of companies like Microsoft in the open source world. For all this and more be sure to tune in!
Key Points From This Episode:
Transcript for Episode 73. Front End Build Systems
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey Manhattan. I’m your host, Michael Nunez. Our producer today -
[0:00:09.6] WJ: William Jeffries.
[0:00:11.0] MN: Today, we’ll be talking about front end build systems. Before we begin, we have a special guest today, we have Jonathan Belcher. How’s it going JB?
[0:00:19.1] JB: It’s going great.
[0:00:20.1] MN: Could you give us a little bit about yourself for our listeners?
[0:00:23.4] JB: Yeah, I’ve been a developer since 2006, 2007 and primarily a focus on the front end. I am currently a JavaScript electro wizard at Automaticc working on WooCommerce.
[0:00:35.9] MN: Awesome. That is, you said, 12 years, that’s a lot of javascripting.
[0:00:40.3] JB: Most of it was java scripting, I mean, there were some PHP and some C# along the way.
[0:00:44.6] MN: We don’t talk about those. That’s not a big PHP. I’ve never done PHP, people tell me not to. I’d love to hear why I should but I don’t think I’m going to get any responses for that.
[0:00:57.5] WJ: I mean, we should also not shit on the PHP community because those people are very nice and they have their own thing going on and like, you know, one of the largest platform in the world is WordPress.
[0:01:11.2] MN: That work at the WordPress company?
[0:01:13.2] JB: I do use a lot of PHP. You know, PHP is better these days.
[0:01:17.3] MN: Okay.
[0:01:17.6] JB: It’s gotten better.
[0:01:19.0] MN: I have to give that a try. Going back to the front end build systems of back in the day, do you want to shed some history and some light on what that was like? I think I started developing in 2000 - my first professional programming gig was in 2011 but it was Java so I didn’t have to deal with front end build systems, I had to deal with Ant Build, that’s a whole other episode in itself.
But I didn’t do any JavaScript till 2013, 2014. You have some thoughts on the history of front end build systems?
[0:01:48.2] JB: When we got this topic, I was wondering, I could not remember what build systems were like before Node and before Grunt, those sorts of things. I went and did a little research and of course, there really weren’t a whole lot of build systems, it was – you took your jQuery and you just in line it via script tag and then you took your custom JavaScript and you might have even just like included it in your HTML page or you went to some sketchy website and you minified it via that sketchy website and then put it in a file. Copied it and pasted it into a file and then just inlined it in your HTML.
[0:02:29.1] MN: How was that safe? I mean, how was that ever safe?
[0:02:33.5] WJ: I can’t imagine that someone on the internet would do something bad.
[0:02:38.6] MN: Wow, William.
[0:02:40.9] WJ: I’m sure it would also be extremely difficult to include a back door that people wouldn’t notice when they copy and paste blindly a huge chunk of code.
[0:02:51.2] JB: That’s sarcasm?
[0:02:53.1] MN: That was sarcasm, ladies and gentlemen, do not paste their code on to the internet nowadays.
[0:02:58.6] JB: Yeah.
[0:02:59.4] MN: You would just straight inline, you know, jQuery if necessary, any other java script package.
[0:03:05.8] JB: You wouldn’t even – you might not even in line it from your server, you might inline it from some sort of CDN. Which I mean, have its benefits because you go from site to site and it was already cached and everybody was using jQuery and everybody was using it from the same CDN, that was helpful.
But I mean, what about at CDN? I mean, I guess you trust the CDN but yeah, I mean, it was basically the wild, wild west, there wasn’t really a whole lot of build systems.
It was fairly simplistic and websites were simpler in those days. You didn’t need a lot of the things that we have today.
[0:03:43.8] MN: I always look back at the Space Jam website just to go back into history and how websites were built. Much less, it was much less like complication, it was just like hey, you click here, get your pictures and go watch the movie, that was it.
[0:04:00.2] WJ: Yeah, if you haven’t seen the Space Jam website, it is definitely still worth visiting.
[0:04:05.7] MN: Yes.
[0:04:07.3] JB: Fantastic. Now, that Space Jam 2 is coming out.
[0:04:09.2] MN: Yeah.
[0:04:10.4] WJ: What?
[0:04:10.6] MN: Yeah, supposedly they got LeBron James.
[0:04:11.9] JB: LeBron James, exactly.
[0:04:14.2] MN: That’s going to be something else. Hopefully they upgrade the website for space jam two.
[0:04:18.9] JB: No. They need spacejam2.com. Don’t upgrade the old one.
[0:04:23.4] MN: Exactly. Soon after the wild, wild west, when did Node get introduced to the JavaScript world also?
[0:04:33.5] JB: Yeah, I mean, in 2009, Node came around and these are all – it’s just ish dates because I don’t know exact dates. But node really wasn’t like a thing in the front end world, I mean, it was used for server side things at first but then people started realizing that we could use it for build systems and I guess, you know, Grunt came along in 2012-ish and that was really – it was a system for doing front end builds.
You provided a configuration via JavaScript object and it did a bunch of things then I’ll put some build target, you know, a build file.
[0:05:18.5] MN: This would also, and Grunt was able to minify your JavaScript and do all sorts of stuff like that.
[0:05:26.1] JB: Yeah, I was doing, you could do a lot of things but you know, mostly, you were talking about minifying, you're talking about [inaudible] – taking multiple files and making them one, maybe some like LaaS or Saas into CSS, maybe some auto prefixing. I mean, the things that we were doing with build systems back then was not, you weren’t doing a lot.
[0:05:49.0] MN: Right, then there were a couple of things soon after Grunt. I think Bower was one of the bigger ones that I started listening to when I became a front end JavaScript developer. Bower was pretty big.
[0:06:01.0] JB: We talked about how you would just inline jQuery.
[0:06:04.0] MN: Right.
[0:06:05.2] JB: That’s not a really fantastic way to do it because you would have to go out, download, the zip file, unzip it, take that minified file and then put it into I guess, your code revision system, maybe it was SVN back then, who knows. Those are some shivers.
How do we get these front end libraries or packages and how do we get them injected into our site? I mean, on the back end, you would have MTM and you would just MTM install all of these things to build but then you wanted to include a jQuery or you want to include like Bootstrap or like Bootstrap, you would just go download it.
Well now, Bower, what it does is it goes out there and has a package library and you specify in like – I don’t even know what it was called, like a package at JSON file and you would specify the packages you want, download to your site and then you would just include them from the Bower folder.
[0:07:05.7] MN: Right.
[0:07:06.1] WJ: Was it a Bower file?
[0:07:08.3] JB: Yeah, it was a Bower file.
[0:07:09.0] WJ: Yeah, I think it was.
[0:07:09.9] JB: I think it was a Bower file.
[0:07:12.2] MN: It’s been a long time. So many other – like today, we’re just, it’s everywhere. You find your build system of choice, I mean, we have the one that’s commonly used in all the clients that I work in this WebPack, like everyone is web packing right now.
[0:07:31.8] WJ: I just remember how dope that bird was, like the Bower bird, their logo? My god, the fire.
[0:07:37.6] MN: The Bower bird, they still sell t-shirts. Even though Bower is now deprecated, they still sell t-shirts and I want one.
[0:07:45.4] JB: Yeah, today, Webpack has really, after the Bower and the Grunt, there was Gulp and Gulp made it a little bit easier and you’re just writing, plain JavaScript.
[0:07:58.0] WJ: But the streams.
[0:08:00.5] JB: Yeah, you would do something and then you would give it to another, you would pipe it to another command and then that other command would run and you could do the things asynchronously and it was – compared to grunt, you know, it was a fantastic improvement and you were writing like plain JavaScript rather than this esoteric, like java script object that was like a million miles long.
You know, Grunt and Gulp are both, they’re task runners. Today, Webpack and a lot of the new build system pieces are more packagers. What they’re going to do is you’re going to use modules and you’re going to specify an entry, and then you’re going, it’s going to go to that JavaScript file and then it’s going to go traverse all of the includes and take all of those things and do something and then output a series of files.
[0:09:03.0] MN: Right.
[0:09:04.4] JB: Webpack has done, you know, they were really one of the first to do that. There are plenty of others, I mean, there’s Parcel, is one of the newest ones and they’re all about zero configuration. And then there’s Brunch, well, Parcel is also about making it fast too. But latest improvements to Webpack is way faster. Then there’s Brunch and Roll Up and Browserify.
All of these, they all have their own thing that they try to focus on but a lot of times, you know, they all copy from each other so if somebody comes out with a new feature and then it gets included in a different one.
[0:09:48.8] MN: I mean, I think JavaScript, the community of JavaScript is like that. You have, you use Backbone JS and then there’s like Angular and React and they go back and forth on the things that they want to build and JavaScript seems to just create a new thing and that it’s going to be the hot new thing and then there’s like 50 other hot new things that ends up happening because they’re all copying from each other.
[0:10:10.6] JB: Yeah, it’s fantastic. It’s much like a React came out and then from React, it was Preact and like another thing, and then, react took the features that made those other things better and included some of those into the core. Very much, I mean, it’s very much the same with a lot of the front end build systems, the Ember framework came out with a CLI and then Angular came out with a CLI, Polymer, React, everybody comes out with a CLI to do all of those things and it gets included. I mean, sharing is caring, right?
[0:10:49.6] WJ: It’s like a weird corollary to a competition and like a paid market place. Because it’s all open source, it’s free.
[0:10:57.9] JB: It’s fantastic. Yeah, like today, with Webpack and all of these other pieces, because they’re the bundlers, they’re not really task runners, there’s also NPM, we were using make files for a while, I mean, that was a thing that sprouted up and then everybody started using NPM scripts.
Now, what we do is we say, NPM start, that’s the canonical entry into a front end to build it and do all of the things. What’s really great about that is you can, under the hood, in your package.json, you just specify a java script file and that JavaScript file can do all the things that it needs to do tucked away nice inside like a bin folder, wherever you want to keep it.
[0:11:49.2] MN: Just want to run that script, you can configure it in the package.json to you know, run your tasks, start the server. I think the other one that I’ve seen is like check your coverage, you want to see how much coverage you have in the code base and whether you’ve gone up or down and stuff like that.
Those are all scripts that were used in NPM which is not exactly what Webpack is built to do, is that correct?
[0:12:13.1] JB: Yeah, Webpack is the bundler and then NPM scripts is really your task runner and so that’s traditionally the space that Grunt and Gulp were in but they’re not really – they’re not as necessary, I mean, they definitely steal serve a purpose but if you’re just doing some simple task running, you can do that via your NPM scripts.
[0:12:33.3] MN: Could you see yourself developing, like going back to the ways of Grunt or Gulp in that regard? What are some advantages that you have using the old frameworks versus like the new ones per se like React. I mean, excuse me, like Webpack or Parcel and stuff like that?
[0:12:52.6] JB: Yeah, I mean, that would be pretty difficult given that like, you know, Webpack gives you the – the bundlers give you the bundling. So I can like Bower would give you the ability to pull in things from that Bower folder. With Webpack, I can NPM install things that I want on the front end via NPM and I can just include them via an include inside of the JavaScript file because Gulp and Grunt really don’t have that infrastructure. It would make it a lot more difficult.
[0:13:29.7] WJ: What do you think is coming next? What do you think the next innovations are going to be in the packaging world?
[0:13:34.2] JB: Wow, that’s a –
[0:13:34.8] WJ: That build the building world.
[0:13:36.2] JB: That’s a tough question. Yeah, I think now we have a lot of the features that everybody is asking for, you know? Like tree shaking so that you’re not including things in multiple times and sort of that you are reducing the amount of code, chunking like, “I don’t want one one megabyte file. I want six files that I can include on different pages and at different times.” So like code splitting. That’s been something that everybody’s been wanting and I think that the next year is really going to be focused on speed.
Because a lot of these and Webpack and some of the other ones are already making those speed improvement. There is I think might have been an Airbnb. They said that their build time was 11 hours and that the new one pack version they’ve reduced it from 11 hours to 15 minutes. Don’t quote me on that but there is a Medium post about it and I mean, I have never seen a build time that long but when you fire up Webpack and it takes a minute, two minutes to build the project.
Then you’re sitting around doing nothing during that time and you are just like waiting, waiting, waiting and then you are on to something else and so I think that a lot of the focus is going to be on speed but I don’t know. It’s tough to see the future and I currently have all the features I pretty much need for the projects that I work on, I don’t know.
[0:15:14.9] MN: I mean I know one of the headaches that I see working with this build tools is the fact that Webpack does have all of these different configurations that you have to look out for. I am really interested in diving into Parcel because of this people can’t see me but I am doing the air quotes of the zero configuration and see how that works and see if they expand the zero configuration framework so that people are not afraid to use Webpack, let’s say.
[0:15:42.8] JB: So zero configuration is fantastic but as a project becomes more complex, it is going to require some sort of configuration and you’re going to probably not fit - I mean a lot of projects might fit inside of that zero configuration but I mean knowing me, I am probably going to be on the one project that doesn’t fit that zero config.
So I mean if you are working on something simpler like a Node module or something like that, yeah Roll Up or Parcel is going to work really well because you can do it with that small config.
But if you are on something more complex, Webpack is probably going to be there. Ah the future, CSS as like primary entry points, right? So right now if I want to compile a CSS tree of like SaaS files or whatever it may be post CSS, I have to create a JavaScript file and then I have to include that CSS file inside of that, inside of that JavaScript file and then I have to tell Webpack to extract the CSS using like mini CSS or extract text HTML plugin or something like that and so, CSS and other file types as primary targets rather than just out there.
[0:17:06.5] WJ: Nice.
[0:17:07.8] MN: The future is coming.
[0:17:09.4] WJ: We’re going to come back any year from now and see.
[0:17:12.6] JB: It’s coming. It was promised in the Webpack four Medium post that it is coming soon-ish. So I trust them.
[0:17:22.0] MN: And we trust everything that is on the internet because the internet would not lie to us. It would not deceive us, it would not hack us.
[0:17:28.9] WJ: Who is making Webpack? Is that just regular open source contributors?
[0:17:32.9] JB: It is a regular open source contribution - I mean it just started out with I think it was one or two developers and then they grew their team. You might have heard like the person that has been doing a lot of this spokesman-ship is Patrick Larkin. He went to work for Microsoft as a developer advocate. So I mean that is part of his job to make Webpack better and thank you Microsoft for making that part of his job requirement because he’s great.
[0:18:01.0] MN: Yeah.
[0:18:01.7] WJ: It is cool to see some of these bigger companies sponsoring open source like that. Facebook did it with React, Google did it with Angular. It’s nice to see Microsoft doing that as well. It does feel a little weird.
[0:18:14.3] MN: That Microsoft is doing it, right? Yeah.
[0:18:16.5] JB: Well I mean we could do a whole podcast on this but I mean Microsoft started focusing on open source and they said this is an important thing for us and it was like the Scotts you know at Microsoft like Hanselman and the rest of the crew over there said this is important to us and open source matters and I think they have done a great job. Hopefully their stewardship of GitHub will be a good thing.
[0:18:45.7] WJ: Yeah that is a really critical piece of open source infrastructure that we need.
[0:18:49.0] MN: Yeah, no doubt about that. With the advancement of like I think I asked JB earlier if there was a reason or if he would every use Grunt or any of the old front end web built systems and I would not be able to do that.
There is just so much that I depend on including like whether its linting my files and all of these different scripts that run that I need to have access to, you know run my spec and stuff like that. I can’t imagine not having it in a place where it’s just configured and works for me and for the project that I am currently in whether it’s a zero configuration, a small project or something massive and we use Webpack.
[0:19:27.4] JB: So I mean today, we are doing a lot of things that we didn’t really do in the past, you know we are transpiling, we are using NPM 6 to 5 or Babel as it’s now known.
[0:19:39.3] MN: Yeah, what is that, EMCA or whatever.
[0:19:42.8] WJ: ECMA Script.
[0:19:43.6] MN: Yeah ECMA.
[0:19:44.5] JB: Yeah, so ECMAScript they came out with six and so somebody created a library called ES 6 To 5 and we’d trans pile your ES6 down to five so they could be run in the browsers and then –
[0:20:01.7] WJ: Some marketing genius came along.
[0:20:02.9] JB: And said, “Well we now have ES 2016, 2017, 2018.” So now the name didn’t really worked so well and so then it was renamed Babel and so now, everybody is using Babel if you are writing modern JavaScript and so we are trans piling from ES Next, ES Star, whatever your settings are down into whatever browsers you support. And so we are linting and we’re testing and we’re doing a lot of things that we just didn’t do in the past.
So it is a combination of we need Webpack to compile all of these crazy JavaScript into a build target. We need to lint that code, you don’t necessarily have to have Webpack do that but we are using ES Lint or JS Hint or you know there is a bunch of them but we are using Prettier to take our code and when we hit that save button or when we commit, automatically reformat all of our code.
[0:21:10.1] MN: What? Yeah I don’t want to think about that. That’s amazing.
[0:21:14.0] JB: When that first happened, when I first saw that in action I was like, “The future is here.” Where we no longer have to fight over like, “Do I use tabs versus spaces?” Well, you know Prettier just tells you what it’s doing and it’s done.
[0:21:30.3] MN: It’s spaces, it is spaces though.
[0:21:33.0] JB: Uh well I mean the WordPress style guide, JavaScript style guide specifies tabs and you know, it’s actually a very comfortable like style guide. There’s lots of spaces and once you try and go back to no spaces and you look at a codebase that’s the traditional JavaScript style, oh man, it’s really tough. You feel like you are in a compact car or something.
Today, we are doing a lot of things that we didn’t do before and by using a combination of all these tools like the build systems are so much more powerful than they were in the past.
[0:22:10.0] MN: Right.
[0:22:10.5] WJ: So what do you like about all of these? What do you like most about all of these modern build systems?
[0:22:16.1] JB: I think what I like most is that I could just write the code I want to write in whatever language I want to write it in and then it just works in the browser. I can use Fetch for instance which may not be available in all the browsers but it’s already being automatically poly filled for me in the build systems.
[0:22:38.2] WJ: Stop trying to make fetch happen JB.
[0:22:41.5] MN: That just never going to get –
[0:22:42.6] JB: It’s so a thing but yeah, if I wasn’t using the modern build system to add the polyfill for firing dom events, I would have to write like 20 lines of code because I have to worry about IE and I don’t want to have to do that ever again and so the modern build systems, I can write when I want to write and it’s just going to work in the browser as long as I have set up the build properly.
[0:23:08.3] MN: There you go.
[0:23:08.7] WJ: Amen.
[0:23:09.4] MN: Yeah but JB how can people contact you?
[0:23:12.2] JB: I’m @belcherj on Twitter. I am @belcherj on GitHub.
[0:23:17.2] WJ: Anything you want to plug?
[0:23:18.3] JB: Yeah, Liberty JS is coming up in November in Philadelphia. It’s a JavaScript conference and it’s going to be awesome.
[0:23:28.2] WJ: I can vouch for this, I’ve been to Liberty JS in the past. It is awesome, it is a wonderful organizers, great speakers, definitely check that out.
[0:23:34.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole.
And never miss an episode, subscribe now however you listen to your favorite podcasts. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
