Standardized Front-end Tools to Increase Productivity
When I played with Angular, React or Meteor back in 2014-2015, I had a lot of questions. Some involved the tooling, but many were based in how to setup a project.
- How do I structure a project?
- What are the recommended best practices?
- How do I deploy?
- How do I handle testing?
- How do I manage importing libraries and other packages?
Lost in the forest
These Modern frameworks required a lot more planning, thought and research for me to get running. Having to development my own project structure, or having a few restructures, was frustrating.
Starter Packs and Generators
One of the ways we used to start projects was using existing starter packs, or Yeoman. This gave us a better experience in generating an existing project, and allowed us to get up and get going.
Set it up for me
Having a default preference set up allows us to move onto the more important areas of our app. Starters usually fix issues like:
- ES6 Transpiling
- Minification and Compilation
- Generating a Production Target
- Wiring up the folders
While this made it a lot easier to build out projects, it had some issues. Some starters that exist are specific to a certain configuration. I used an older Yeoman starter for Angular, which used less recent build tools like Bower and Grunt.
It was also structured in an MVC project structure, while the community recommends a Feature based project structure.
- Relied on the generator’s documentation
- Could use older, not current best practices
- Hard to debug if you don’t know what the different tools are doing.
We love Official Command Line Tools
I’ve been playing with Angular 2’s ng-cli, and I feel it improves my qualify of life for development. Other than generating default code, it allows for the following:
- Well defined conventions
- Easier support
- keeps my mental overhead small
Conventions reduces conflict
While people argue about different kinds of conventions, many will agree that conventions are a good thing. By having a defined set of conventions for a project, people would generally know where to put things.
When the documentation is not a best practice
One of the issues I ran into while learning Angular 1 came from a lack of agreed upon conventions. While the official documentation showed one way to create directives, the community documentation and best practices recommended a separate way.
Have defaults cover most common use-case
Angular 2 took recommendations and practices from the community and have built tools that support the best practice. The issue of how you should set up your Components or Services is already made up. Calling
ng generate component my-component-name creates all the steps you need.
One of the benefits of having a standard structure in an application is easier ways to support the application later.
Problems are Google-able
When we have to create our own structure while we’re learning, lots of minor breakage and mysterious problems occasionally appear. We try to google issues, and many of the cases found are almost close to ours, but don’t work.
When standards exist, we have an understanding of what should happen, and it makes it easier to communicate.
Easier to onboard new developers
Newer people have an easier time looking up documentation, and can use the built-in tools to do accomplish tasks better. When we work on a project that has lower documentation, or using a bespoke framework, it can be difficult to comprehend what is exactly going on.
I can focus on the big things.
There are times where I feel like I’ve written the same set of code over and over again. Looked up similar documentation each time, because it was not obvious on how I should structure an area.
Standard Tools allow me to not think, and have it be easily available to do some things.