The basics as a frontend developer in 2019

Image for post
Image for post

We are now in 2019. Since 2012 and the first release of Angular and Sass libraries, web technologies have developped well. A lot of libraries/frameworks like React, Angular2 or Vue are born. With them, the setup of the frontend developer has also been upgraded. You have now a lot of tools to help developers to debug, embellish, optimize their code. Progressively released, a lot of them have quite well progressed during 2017 and 2018 and are now stable and with hindsight, I can say they save you a lot of time.

We are now in 2019. It’s time to play in the big leagues.

If you didn’t care yet to keep your project setups up to date, I suggest you to apply everything, it is now the basics in 2019.

If you already try to keep up with the industry standards, you may know most of these tools but read until the end , you might learn one or two tricks.

Ecmascript 7

The Javascript language evolves very quickly and each new version of the language fix some issues of the previous versions and optimize the way to write code. Norms Ecmascript 6 and, to a lesser extent, Ecmascript 7 brought the language to the next level. To the point that you might not understand a code written with ES7 coming from ES5 or prior.

Ecmascript 7 is THE norm to use now. Coding is now far less painful and it also adds a lot of useful features like classes. So I suggest you always use the latest version of Ecmascript available.

Of course, all browsers don’t handle latest versions of Javascript so you might need to compile your code using for example Babel. With version 7 of Babel, you need to use preset @babel/preset-env to be sure to have latest Ecmascript versions.

Image for post
Image for post


You know CSS the fuzzy language you use to transform your web pages into flashing christmas garland ?

Forget it, use SASS. It is still fuzzy, it looks like CSS, but it adds all features of real programming languages like variables, conditions, iterations, functions, classes, inheritance, and much more. With SASS, your style code will be more reusable and robust to scaling. At the end, it will be compiled in CSS to be readable by the browser but you will keep your code clean.

I often see people having conflicts between CSS rules of their different components. If you use a module bundler — like webpack, I suggest you to limit the scope of your style class names to only the related component to avoid these conflicts. With webpack css-loader, it is the option modules for example. It will replace the class names by random strings.

Image for post
Image for post
Set modules to true to scope your classnames.

In the past, I was using LESS but with hindsight, SASS is far more powerful in particular for iterations and inheritance.


We all know that Javascript is a very permissive language. You MUST absolutely have a linter to have your typing errors displayed in real time in your favorite editor.

Image for post
Image for post

A linter is useful to ensure an expected coding style but also to avoid common errors like an undefined variable or even to forbid dangerous expressions like ==.

While using a linter, you are enforced to keep your code clean. Moreover, it is easier to learn new versions of javascript or libraries since your editor detects errors for you. Besides, it is more confortable when you have interns or junior developers: they just cannot trash your code.

In conclusion, linter is very useful when you are coding alone but it is absolutely NECESSARY when you work in a team.

My favorite linters are eslint for the javascript because it is a linter compatible with a lot of libraries, and stylelint for the CSS/SASS. I suggest you install the plugins for your editors to have the warnings in real-time and to integrate the linter in your continuous integration system to avoid any wrong formatted code to be pushed in the repository.

For linter, I suggest you to use very restrictive coding style rules like Airbnb coding style and to customize the rules in order to “create” your own language.


Another very useful tool is Prettier that can automatically fix all your minors errors on the fly. It can also optimize your code when it detects specific patterns.

Image for post
Image for post
As soon as you save your file, Prettier cleans all your code

In collaboration with a linter, Prettier helps you to have a code consistent between all members of your development team. Besides, it save you some time since it make your code automatically compliant with expected coding style.

As for me, I use prettier-eslint and prettier-stylelint that directly use linter rules to avoid conflicts with the linters.

Hot reload

You may already have a auto-reload setup that automatically reloads your page when you change your code while you are developing.

With hot reload, you go further. Everytime you modify the code of a component, only this component is reloaded, rather than the full page. And the state of the component and other data — stored in redux for example — are also preserved during the reload.

Image for post
Image for post
You can reload a component while keeping its internal state unchanged

Hot reload is sugar but it may save you time, since you don’t need to reproduce a user behavior everytime you update your code during your developement stage. It may be very useful for example when you code a scrollable page. Everytime you update your code you won’t need anymore to scroll down until your component.

Of course, hot reload is only available on component-based libraries. For React, you need to activate the option hot for webpack. Then, you need to install a babel plugin and wrap your App.jsx with this hot reloader. For vue.js, it is often setup by default.

Lazy loading

When you use a module bundler, all your code is merged into one compiled file. But when your application becomes bigger, the compiled file may exceed 200MB which is the recommended limit for performance reasons. If your file is too large, it might slow down the download of resources and at the end the initialization of your page. In order to avoid this issue, you need to split the bundle into several chunks.

Most of time, your module bundler does it for you automatically. This will improve performances related to some network issues but at the end, browsers will still need to download all chunks in order to initialize your application.

Another solution is to split your code into smart chunks that will be loaded only when you need them. This tricks is called asynchronous loading or lazy loading. The browser only downloads what it really needs to display the first view then the rest of the application is downloaded when the user asks for it. Another optimization is to download new chunks every seconds after the first initialization. By this way, the browser won’t be overloaded but everything will be downloaded before the user will ask for it.

Webpack 4 natively integrates this feature. You only need to add a plugin to babel and use imports as promised.

Image for post
Image for post

This technology may be not very useful if your users agree to wait 5–10 seconds for the initialization. Otherwise, since it is very easy to apply, I suggest you to integrate this technology into your setup.

Server-side rendering

Frameworks/libraries like React or Vue.js are very comfortable for web development. However they had limits when you wanted to publish a website referenced by Google search engine. Search engine bots have trouble to crawl pages built with frontend javascript.

Now Google seems to manage web applications but it is not very sure since Google algorithms are quite obscure. Besides it is not ready for Qwant, Bing or Duckduckgo. If SEO is important for you, you should not rely on search engines capabilities and use server-side rendering.

Server-side rendering (called SSR) is a technology that allows your backend server to render a page and send it to the browser as a static page. On most advanced SSR frameworks, frontend javascript takes back the control once the first display done in particular for routing if javascript is enabled in the browser. So the user doesn’t see the difference with not-SSR web application. Besides, this technology improve performances since your server can cache the pages and your browser doesn’t need to interpret the first page.

Notice that at the opposite of other technologies described above, this technology is more intrusive. In order to use, you should use a framework like Gatsby or Next.js for React or Nuxt.js for Vue.js. So use it more specifically if SEO is important for you.


You have a lot of tools to help you as a frontend developer. And more and more are coming everyday. They help you organize your code, implement new features faster, or have a more faster web application. And it makes the difference. That’s why I suggest you to always keep your project up to date.

All what I explain may seem obvious, but I often meet developers (or managers) that don’t want to take time to upgrade a project or their development environment. But spending several hours to refactorize your setup will save you days later, not even considering performance increases or new features like SEO for web applications. So it is up to you to choose when it is more optimized to upgrade your project but do not wait to long or it might be a nightmare.

For react developers, latest version of create-react-app gathers most of stuffs described above.

If you are new in frontend development, this roadmap about what you should learn is also very useful.

If this article helped you, remember to click on the clap.

Image for post
Image for post

Written by

Tech addict, ux lover, ready for impossible missions, eagger to learn new user interface technologies like VR, AR, virtual assistants, etc

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store