JavaScript is an adventure. After almost a decade of both amateur and professional development in various industries, I believe everybody would agree on this one statement.

Frontend projects give us, programmers, a lot of freedom of choice, of flexibility, and plenty space for creativity — but in return they also demand a bit of knowledge, planning, and self-responsibility.

Having gone through projects with jQuery, require.js, Angulars, React, ExtJs, and maybe a dozen others I may not recall (or wish to not recall) — I have seen things unimaginable to 2018's Frontend. And we all probably did at some point!

But there have always been some common patterns that made working on even the most uncoordinated projects somehow manageable. Below you will find a list of 10 most vital of those — driven by personal experience, these are surely opinionated, although I believe many of experienced developers may agree. These patterns provide a stable foundation for a project, of any framework, any methodology, any team size — reducing the need for documentation, refactoring, and amount of tears shed by the developers’ eyes.

I hope you will learn something new today, find it helpful, and use those to create something amazing! ?

1. Divide and conquer

Most of us heard it somewhere, but many seem to underestimate this rule. CommonJS, Webpack, and Node give us an ability to separate code into multiple files —but why would we even care?

Consistency. Dividing your project into single-export files will make searching and dependency management significantly easier when the codebase grows. Naming each file after the only thing it exports makes it intuitive and puts no strain on the brain when traversing the architecture.

Management. Separating each export into its own file allows you to quickly move it when necessary, and promotes decoupling¹. When your helper function is needed in a different part of the application, you may simply create a /shared directory, and drag it there — making it accessible to other parts of your code.

2. Make things embarrassingly obvious

Every variable, every function, every file —take your time and name them as if you were naming your newborn. You may save 0.3 seconds today by calling that variable “x”, but in a month you will spend 2 days trying to figure out what it means, then 4 more on refactoring. Think ahead, and don’t be afraid of long names.

Avoid hacks and things that make you think about applying to MIT straight away. Your solution may indeed be smart and complex —and sometime in the future you, or somebody in your team, will agree on that and then proceed to spend a huge chunk of time trying to figure out what is going on in the code. Focus on making things simple, without a need for documentation or comments².

3. Resolve magic numbers and strings

Similarly to naming — however tempting it may be, don’t use magic numbers or strings in your code. No matter how small or non-extraordinary the value seems, put it into a variable with a meaningful name and move it to the top of its scope.

Most of the time, any explicit value you put into the code will be reused somewhere else. Putting them in variables right away reduces code duplication, makes adjustments easier, and gives these values a meaning.

4. Fight nesting

If your code goes beyond 120 characters to the right, beyond 500 lines downwards, or your if -statement goes 3 levels deep — do your best to divide it.

You can resolve conditionals’ complexity by dividing code within deeply nested if-statements into separate functions, Promises, or Observables. If you use a lot of asynchronous calls, async/await can also significantly simplify your code.

5. Configure hard

If your application uses global values, API endpoints, feature toggles, or third-party credentials³ — put those in a separate config file.

There is a bunch of packages that help manage configs both on web and in node, like config. At some point your application will be available both on the server and locally for development. Creating config file early is much easier than in later stages, and will allow you to adjust how these environments behave, which credentials they should use, which features are available, et cetera.

6. Frameworks are there to help

Too many times you can see framework used because someone knew it, or because it is popular.

Take your time to think whether you need a framework for your project, and which one it should be. End-user couldn’t care less if your website or application is created in this one framework that has 100,000 stars on Github. From experience I would separate frameworks and libraries as:

• React: when you need total control over the architecture and build, but only for webapps built with components. React-ecosystem development takes time and requires a lot of planning beforehand. React pays back plenty, but only if you know what you are doing.
• Angular / VueJS / Ember: when you need a webapp done quick and reliable, in exchange allowing a big black-box instead of an architecture. These frameworks do a lot for you — taking away both pros and cons of architecture planning. Their strict structure will also forgive more mistakes than freedom of React would.
• jQuery / lodash / or similar⁴: when you need a webpage done quick, and you can spare a few kB. Those can significantly reduce development time, but require care, since they allow you to write unmaintainable code — use those as helpers, not as a foundation.
• Vanilla / No framework: for both webpages and webapps, when you can spend a lot of time on development and planning. Pure JavaScript is a good choice when your project does something experimental — introduces WebGL, Workers, in-depth optimisations, or browser animations — you will end up creating your own kind of framework. With transpilers it can also be used as a better and lighter alternative to jQuery.

Treat this list only as a suggestion — take time to decide which framework, if any, will be the best for your project.

7. Unless it is a prototype — write tests

Unit tests. Smoke tests. End-to-end tests. Sanity checks. Unless you project is only a prototype that will be rewritten soon, write tests. With increasing complexity your codebase will become much harder to maintain and control — tests will do it for you.

Sometime in the future, you will encounter a bug, look onto the cloudless, blue skies, and thank your past self for writing tests — as you would have never realised how many things quietly broke down in the background after you added your brand new feature.

8. Use version control

No matter if it is a prototype, full scale enterprise webapp, or a little, happy side project — use git, or other version control, from the very moment you write down the first line of code. Commit daily, use branches, learn how to merge, resolve conflicts, and return to previous commits. Give meaningful commit messages.

Version control allows you to travel through time, save broken things, see changes introduced in the past. If there is one thing you take away from this article, it is learning basics of version control and using it on a daily basis. Why? Because even if you ignore the rest, and accidentally go wrong on the way, with version control you can fix it — without it, you are usually doomed to start over.

9. Manage state responsibly

Find a pattern or a library for state management, and hang on to it like your life depended on it — because at some point it just may.

As Frontend developers, we usually face only two significant challenges — to display data and to store data. The later being far harder to maintain over time, as it is so convenient to ignore it — that is until your project becomes virtually unmaintainable several months later.

Storing data, i.e. state management, is tricky. Our applications usually have to remain in-sync with both what the client sees on their screen, and what server has stored in the databases. Our goal is not to add any more complexity in the middle — in our JavaScript structure. Components should deliver same set of data, synchronise changes made by the user, and react to any changes on the server. How can we solve this issues?

• Since its a very open ecosystem, for React there is plenty of solutions — Redux for Flux architecture, Mobx for an observable-based one. Each has its pros and cons — make sure to learn and understand the basics of the library before you use it.
• Angular, Ember, and VueJS serve their own build-in state management solutions — based on the idea of Observables. While not necessary, there are also additional libraries⁵ like ngRx, Akita and Vuex.
• For any other framework or Vanilla JavaScript, you can use Redux, Mobx, or your own state management solution. The main goal is to ensure that whole application has the same source of truth — this can be a service, a library, or a simple state Observable.

10. Question trends

In the very end, listen and learn from the community — but consider and question everything you read, every comment, every lengthy article on Medium written by a cat, any feedback to your code. Be open to new ideas — as those appear in our Frontend ecosystem quite dynamically — but make sure you are not following the hype just to follow the hype — this already led quite a few projects straight into oblivion.

Project written in an older, mature framework is often far better and more stable, than a project written in two frameworks at once — just because new one came out. While new trends may improve application and development performance a bit, little it beats the consistency. Stick to your choices to preserve maintainability and adjust when necessary — but only when necessary.