Choosing Front End Developer Tools
As I wrote about in my post on planning a side project, the initial front end tooling that could help get the project up and running seemed to be gulp, npm, and webpack.
This post covers the framework I used in choosing front end developer tools for a side project in the ever-changing front end landscape.
Review of the tools
To give you a quick overview of what I found, here is what I wrote in that post:
npm package manager – I came across bower and npm. Apparently, according to this post, it looks like npm is the better choice to ensure dependencies play nicely together and is what one JavaScript developer at Spotify recommends.
gulp – Task runner that lets you automate repetitive tasks (sass compilation, running of unit tests, browser refresh, etc.) Here is my source: http://brandonclapp.com/what-is-gulp-js-and-why-use-it/
webpack – Module bundler that generates static assets and splits the application into multiple chunks to load those chunks on demand. You can read more about it on quora and web design weekly.
How to Get Up and Running Quickly with an Unfamiliar Front End Toolchain
To get up and running quickly, I like to start by learning from experts after doing some preliminary research.
Step 1 – Learn from Experts
Because I didn’t know anything about using webpack, gulp, and npm together, I recall posting a question somewhere online looking for a GitHub repository that had all of this put together.
In response, a poster pointed me to this repository which I then forked.
Step 2 – Get Something Up and Running
Since I was new to frontend tooling and Angular in general, my goal was to get something up and running locally without adding a Rails backend.
This helps me implement one feature at a time more quickly.
Step 3 – Come back later and clear up anything I didn’t understand
As I was trying to clarify my understanding of webpack, I came across this medium article.
The upshot was that you could use Gulp with a tool called Browserify to build your own process to get the front end libraries you are using ready for production. For example, you may want to bundle, minify, and lint your libraries. Browserify and Gulp will help you do this, but you have to do a lot of manual work to set this up.
On the other hand, webpack was a very opinionated tool that uses a configuration file to define the build process. So instead of having to manually setup your own build process, webpack takes care of a lot of the decisions that would go into that for you.
So if you used webpack, you’d likely not have to use Gulp according to the author. Now the particular repository I was using did have a Gulp file which looked like it was being used to help “build” the webpack related files.
Step 4 – Don’t be afraid to move on
This brings me to step 4. I decided to go ahead and move on even though my understanding of frontend tooling was imperfect. In general, I’ve found it’s easier to hit problems and learn as I go along. Plus, I wasn’t sure at this point if I was going to use the Rails asset pipeline instead of trying to figure out how to get webpack working in a Rails environment.
Summary
When you’re choosing your tooling, especially if you’re unfamiliar with it, it’s easiest to try and learn from the experts (i.e., borrow someone else’s code) and get something up and running. You can always come back and clear things up later, especially if shipping something is a priority.