Front-end best practices

Pushing any front-end project from development to production is always challenging. Lots of tools help developers to focus on delivering value. Whatever you’re working in a team or on your own, solutions exist to optimize your coding workflow.

I’m Franck and today I’m sharing with you a list of tips and good practices to produce more securely and enjoyably.

Principles reviewed in this post

I assume most of those practices are well established, but here is a short reminder:

• Don’t repeat yourself
• Write tests
• Document your code
• Keep it simple
• Lint your code
• Architect by domain
• A good CI/CD tool
• A good set of browsers and devices
• Keep your knowledge up to date

Now how to put it in place and follow on?

IDE

To get the most out of it, your IDE is a cornerstone. This is the end of writing code in Notepad++. You need a tool that will integrate well with others and help you as much as it could.

A good IDE is the one that:

• Don’t put your development machine down
• Allow you to run anything right from it
• Gives you immediate feedback about what you are typing
• Allow you to find as fast as possible anything you need, be it a file or a function
• Allows easy code refactoring
• Integrates with any language or framework you may use
• Gives you the ability to disable features you don’t use

I’ll write a complete article about IDEs in the future. Stay tuned ;)

Don’t repeat yourself

As a rule of thumb, if you repeat something more than 2 times, factorize it. There are many reasons for that:

• It makes your code easier to maintain
• It allows less bug to happen
• It adds more clarity to your code
• It narrows down the performance of your IDE (and your machine) in the long run
• Like the previous, it narrows down the application’s performance for the end-user

By the way, if you work in a team, this will help a lot not confusing mates.

Write tests

If you already read my previous post about Fast and reliable coding through Test-Driven Development you know that I’m fond of testing.

Testing is mandatory. Some may say that “testing is doubting”. And actually, it is! Always doubt yourself. Because this is the first step to become better at something. In development, this has never been so true.

Testing challenges your solutions. This is for me a starting point, never the end. You don’t deliver tests but value. Tests are helping to do so.

In this area, I’m sticking with Jest since I discovered it when beginning ReactJS. It’s versatile and integrates well with any front-end stack. Even with NodeJS backend by the way.

As of now, I use Jest and Testing Library in most of my projects. It makes tests fun again :)

Document your code

Be it through testing or markdown documents in the project, documenting helps you and your mates to get started quickly. It enlights the purpose of your projects and the subtleness of some of their parts.

Keep it simple

This is easy to lose from sight what is the purpose of what you are coding. Keeping things simple may sound easy at the beginning. But soon the codebase can become over-engineered and cluttered.

To avoid that you have to write tests of course, but also to refactor often. This is the guarantee to avoid complexity. In that area, your IDE is a masterpiece: Use its ability to inspect your code.

Lint your code

Eslint does a great job: A good eslint config file can save you from developing dumb things. It highlights the weakness of your code and gives you advice on what to do to fix them.

It also enforces consistency if you use it with a style guide like Standard JS, Airbnb, or Google Styleguide JS. It’s customizable and compatible with TypeScript if you use it.

Domain-driven architecture

I’m not talking about Domain-Driven Design here. But it’s related. Something which can be debated is how a frontend application should be architected. So this is purely a matter of needs.

I use to group things by domain to create context and consistency in my codebase. This is mainly a matter of understanding and easing refactoring. This allows you to identify things easily and not have to jump up and down in the file tree to get to what you want. Moreover, it allows having a quick overview of what’s related to a specific domain.

But again, this is subject to debate and may not be pertinent for any project. Decide wisely.

A good CI/CD tool

Continuous Integration and deployment is a great way to automate things. Be it on your development machine or in your code repository.

The ideal CI/CD should have:

• Lint runner
• Unit Tests runner
• Functional Tests runner
• End to End Tests runner
• Staged deployment scripts

All the commands to run them (except deployment) should be runnable on the developer’s machine.

If you’re not practicing TDD, at least leverage Git hooks to run your tests on pre-commit thanks to husky. This will prevent you from pushing untested code or failing tests.

I know this involves discipline, but you will thank yourself later for that.

A good set of browsers and devices

Ok, I know that the difference in rendering between browsers is lesser than at the time of Internet Explorer. But bear in mind that you cannot presume on what device or browser your code will be executed.

Always target ES5 in your compiler. Always keep an eye on caniuse.com in case you’re not sure a language functionality is implemented or not for a specific browser. Be it for JavaScript or CSS.

The browser list involves knowing your targeted audience. This will help you narrow down the list of supported browsers. If you cannot have them all on your machine, you can use tools like BrowserStack. It’s a paid service but free for open source and non-profit projects. If you really cannot afford to invest, you can try a more root way of doing it: Virtual Machines.

Keep your knowledge up to date

This one may sound obvious but keep in mind that frontend technologies are evolving very fast. Staying up to date is mandatory. It’s easy to forget trivial language-related things when you’re using frameworks that add syntactic sugar and abstractions.

Never forget that mastering the root language will always help you in a way frameworks and libraries won’t.

Conclusion

I hope you enjoyed this post. It’s the result of years and experiences. Some of its parts may be subject to debate. But if some helped you or if you want to discuss it, be my guest. This will be a pleasure to talk about it with you.

I will finish with a Commit Strip :)