I was recently asked by a friend to help him getting started with Angular. His problem was about routing/state management, but as soon as we dove into his code I realised what he really needed help with was a proper way to tackle a project using today’s tools (and also some help with
Before starting I’d like to point out that there are probably many other better ways, tools and combinations that might suit your needs, and depending on the project some things shown here might not be for you at all. Furthermore, if any of you have any improvements or correction, please do share, as it might help everyone, especially me.
Node/Npm, ES2015, wtf?
Before diving into the specifics and see the workflow step by step, I feel like we need to clarify a couple of concepts otherwise it would be very difficult to follow. You already know what Node and ES2015 are you can skip this part.
Node.js & npm
Npm works pretty much like any other package manager (
Some of the newer features are arrow functions,
const variable definitions, template strings, modules and many more.
Since there’s a lot cover about ES2015, I suggest you have a lot at this comprehensive overview of the features before you continue any further.
Why do I need all this?
Long gone are the days where you connect through FTP to your Wordpress setup and start editing some
index.php or some
main.js filled with jQuery and other libraries.
What we are aiming with this workflow for is a local (and remote) reproducible environment in which you are able to organise your project, add steps to your developing pipeline and automate your deployment process.
Here is what my workflow looks like these days. As you may notice it doesn’t specify any framework for building applications, as these tools will be helpful even if you don’t use any.
- Source control: Git
- Remote repository: GitHub / GitLab / BitBucket
- IDE: Atom / VSCode / SublimeText
- Module bundler: Webpack / Rollup / RequireJS
- CSS Preprocessors: SASS / LESS
- Code linting: ESLint
- Testing: Ava / Mocha / Tape
I strongly believe the order is important, since many things won’t be easy to learn if you don’t have some basis to work on.
Besides the softwares, each of the tools are installed in your project via
npm as explained earlier. Since many of them provide standalone CLI and
npm itself is a CLI the terminal will be your best friend (if it isn’t already). You cannot avoid it.
Source control: Git
As the name suggests, source controlling means having the ability to manage changes of your code over time, through useful operations such as creating alternative copies (branches) on which you can work on without touching the other copies, reverting the code to previous states (commits) whenever needed and other goodies.
Rather than the typical workflow where you just save files in a folder, source control gives you granular access to your project’s code (repository) at certain points in its development, allowing for more detailed editing.
Git is an open source project started by Linus Torvald to manage the revisions of the Linux source code. It’s a very powerful tool, and unlike many people think, it’s not necessarily used to develop in team. You may want to use Git even if you are developing locally all by yourself.
It would be pointless to dive deep in how Git works in general and some of the Git commands, so I suggest you take a look a this guide the start familiarise with it. On the other hand what I want to stress is that Git is just a tool, it doesn’t dictate on how you should take advantage of its functionalities to organise your developing process, that’s up to you (and your team). I recently read an interesting piece by Vincent Driessen on a great branching model and I’m following it with some tweaks based on the size and nature of the project.
Since you will be using Git a lot and you will face situations where it will make your life a lot easier, I suggest you don’t spend too much time on the topic now, as long as you understand the basics. You will learn the juicy stuff when you will need them and once you’re confident with everything else.
Remote repository: GitHub / GitLab / BitBucket
GitHub is a hosting service for Git repositories. It lets you host a copy of your repository online and provides powerful collaboration tools between you and your team or you and the open source community. So Git isn’t GitHub, and if you still have any doubt you can learn a bit more on differences here.
GitHub is the de facto service used by the open source community, and that’s why it got so much traction, since offers free unlimited public repositories. Many companies rely on GitHub for private repositories too.
Some of the features include a nice UI to navigate your code, the ability to clone other user’s public projects and start working on them under your account. It also works as a social network for developers.
Since front end development relies heavily on open source projects and GitHub is the plaza where everything happens, on the long run I suggest you start exploring it, as there is much more to it than what it may seem at a first glance. Often companies request to see your GitHub account to valuate your eligibility for a particular position.
I have been contributing to the open source community filing pull requests for various projects in the last months. Since than got to talk with awesome people that work on awesome projects, and being able to help them has been such a great experience so far.
IDE: Atom / VSCode / SublimeText
Integrated Development Environments are softwares that help the user with the development of a software program. They look like a more powerful text editor.
Some of the common features are:
- Syntax highlighting
- Project tree navigator
- Code linting tools
- Auto code completion
- many more
Since the IDE is where the developer spends most of his/her time, the choice of which IDE to use is very personal, and if you search online it looks pretty much like a softer version of the pc/console master race.
As they all are pretty powerful and eventually provide the same functionalities (more or less) it’s a plain matter of personal taste.
Module bundlers take care of wrapping all your code (and all its dependency) together and produce a single bundled file to be deployed. You can also apply additional transformations to your code, such a transpilation, minification, prefixing, programatic changes and so on.
These are very powerful tools and as such tend to be complicated. Getting to know even one very well takes time, so don’t worry if you don’t get everything the first time.
Choosing which one to use is also a difficult task, each one has its ups and downs and they are not perfect by far. I’ve been working with Webpack for the past year and I love it. It has everything I need. Maybe it’s not for you. I suggest you take a deep look at what each one can do before you decide, but also take in consideration how steep is the relative learning curve.
As already said before, transpiling code is necessary if you consider to use ES6, TypeScript, CoffeScript or any other language meant for the front end. Since these languages cannot be understood and ran by the browsers, you need to transform them to standard ES5.
CSS Preprocessors: SASS / LESS
CSS is a very primitive. Not as much in terms of styling / events possibility, but rather related to the developer experience: stuff like variables, operations, functions, inheritance. If you have worked on any medium-to-big project, you know that maintaining the code base is rather difficult, you often find yourself with dead code (styles that are not used anywhere, but you cannot/won’t delete in fear of breaking something or because you simply don’t know it’s not even used), a ton of styles repetition and so on. People came up with strong guidelines on how to write CSS smartly, and I suggest you have a look at them, but they are simply not enough.
Some of the common features you will find are: reusable variables, ability to nest your definitions, code splitting with
@import, mixins, inheritance, operations and many more.
Luckily SASS/LESS syntax is very similar to the standard one, so when you write code it feels like writing normal CSS with superpowers. I think you really need to dive in, to finally have the a-ha moment and realise you will never go back.
Code linting: ESLint
Code linters are tools that programatically read your code and spot possible errors (bugs) as well as check for code style consistency.
The term lint comes for a Linux software that reads your
C code and statically find bugs before compiling. Since than every software that does a similar job has been label as a linter.
Too often bugs are related to simple typos, like forgetting a semicolon or a colon, writing conditional statements that can’t be reached or stuff like that. In addition, when you work in team, having a way to enforce style consistency is vital for the longevity of the project.
Code linting is one of the best tools in terms of fatigue/benefits ratio. You just have to turn on the tool and that’s it! Warnings and errors will start to pop-up, and trust me, you are going to save tons of hours in debugging your code.
Since every modern IDE has a linter in form of plugin or even bundled in, there isn’t much to say about it to get started, just follow some guide on how to activate it in your IDE.
I personally use ESLint in the form of the linter-eslint package for Atom. What I love about ESLint is the ability to specify linting rules on a project/folder basis by dropping a
.eslintrc file in the folder with some JSON inside.
When I started using it I often felt a strange feeling of hate/love, the main reason being I didn’t want to really learn using the tool and just left the default options (rules). Since then the latest versions of ESLint don’t have rules by-default, and this enforces you to choose which one to use. And there are a ton.
Some companies and people even released what they think is the best set of rules that fit their needs. My advise is to start from one of those and tweak it to your style. This way you may find new best practices you weren’t aware of before.
Testing: Ava / Mocha / Tape
I find testing one of the most difficult topic to talk about, probably because I’m not a great tester myself. Testing requires discipline and time, but more than anything, requires experience. The experience to understand what is important to test, and as you go on and learn the way up, the experience to write testable code.
By testing I don’t mean opening up your browser, dropping in a .js file and see if it works, maybe by checking some console statements. Those are for debugging. Testing is the practise to write specific code that runs your source code and checks that everything works as expected, by making assertions.
In front end development there are two types of tests: unit tests and integration tests.
Unit test focus on testing small portions of your code. You have written a function that makes some calculations based on some input. Are you sure the function performs as you expect with any given input? just test it!
Integration test focus on the interaction of the user with the application. Given a user input (mouse click, keyboard pressed), does the application behave as expected? Does it show what it’s supposed to show?
They are two fundamentally different things, the first one being more abstract, easier to write and to run, the second one being more practical, verbose and complex to run in an automated way.
There are lots of tools/framework/suits to run your tests in automated way. Lately I’m running my unit tests with ava and I like it so far.
This is certainly the most advanced topic, so I suggest you feel confident about the rest before starting to dive in, or you will feel overwhelmed in no time.
I really hope this blog post can be helpful for anyone that find him/herself in a position to face this environment for the first time.
I’d really like you to share your experiences and workflow so we can help each other and build a greater community.