Mentor Léo: ES6 javascript syntax (Week 2/Day 4)

Work from anywhere, be a developer

This series is about teaching Léo to become a professional developer from scratch. Léo can be any of you, desiring to learn and grow. Apply here, it will always be free ♥

See the story of the project on medium

Why the javascript community is weird

You may have noticed that I wrote the React snippets in the traditional javascript syntax in the previous days. This is ECMAScript version 5 (ES5) and it’s understood by every browser.

Javascript developers needed to have an improved syntax to write cleaner code. This is where ES6 comes. It is understood by only a portion of browsers (latests versions of firefox / chrome for example). We have 2 choices:

  • either we write only code that is compatible with all the browsers (ES5)
  • or we transpile our ES6 code into a ES5 bundle

That’s where the javascript community is weird. Most of the time we choose the transpilation. Javascript is the only language where we do that, you’ll never see that in PHP or in Java for example.

You already installed Babel with Webpack that does the transpiling job for you in Day 1. See here to review the configuration again.

ES6 key features

I will show you the few features that you’ll need to understand most of the snippets out there. I personally don’t use every ES6 features, and specially not the import. I use the good’ol require. Simply because at the time when I write this article, import is not yet correctly implemented in the versions of Node.js I use. Because yes Node.js now supports most of the ES6 syntax without the need of transpiling (please don’t transpile for Node.js).

We will rewrite our React snippets in ES6 because you’ll see a lot of React documentation and code written in ES6. I wouldn’t show you ES6 otherwise.

Const & let

Until now you only knew the var syntax. With ES6, please don’t use var anymore, but instead const & let. They are a bit less permissive than var and have these particularities:

  • let: you can assign a new value to the variable, just like var
  • const: you can’t assign a new value to a variable (but you can modify the object that is referenced)
let myVar = 0;
myVar = 42; // Okay
const myVar2 = 0;
myVar2 = 666; // Not okay
const myObject = {mentor: 'Léo'};
myObject = {react: 'is awesome'}; // Not okay
myObject.react = 'is awesome'; // Okay !

Inline functions

You can write functions without using the verbose function keyword. You can omit the brackets to let javascript know that the value is to be returned. These 2 below are equivalent:

const myFunction = (arg1, arg2) => arg1 * arg2
const myFunction2 = (arg1, arg2) => {return arg1*arg2;}

See the documentation to understand how the inline function behave, especially with “this” keyword.

As an exercise, you can rewrite all your functions with the inline notation ;)

Short functions

There is another notation for writing functions with less verbosity. I personally don’t like this notation as I found it less understandable. But you’ll see it in a lot of React snippets.

const myFunc = (arg) => {return arg.value};
const myFunc(arg){return arg.value};

Refer to the documentation if you need to understand a weird syntax: See all ES6 features !

Project Architecture

HTML, CSS, Javascript, now Sass and configuration files for webpack and firebase. Sounds pretty messy right ? Let’s try to have good practices on architecturing and naming things.

Code style

In software development, naming things is one of the hardest tasks. It seems useless, but in fact it becomes essential when teams and projects grow. By its name and the casing convention used (PascalCase, camelCase, snake_case), you can understand what is the file doing.

Every team has its own convention, and bigger teams use what we call linters: they are little programs that checks your code style and make sure everyone share the same convention. Otherwise when you are reading your colleagues code, it’s a hassle if he uses a different code style.

It’s not necessary that we won’t use one for now. But you can make small steps towards a better code style:

  • indent correctly your code
  • use the same casing everywhere (don’t mix PascalCase, camelCase, snake_case), or have a specific purpose for each variable/file like PascalCase (Avatar component and Avatar.js file) is for React components, camelCase is for all variables and all files which are not React components, and don’t use snake_case :p
  • have variables / file names that have sense. This is the most important: name your things to that someone else can understand quickly what’s going on. This is particularly an useful skill here at because we are reviewing the code of everyone else ;)


With firebase you should have specified that your public folder is what gets deployed on your server.

But I suppose you quickly dropped everything inside it, because that’s easy. And that’s a good mentality.

But we can take a look at what will happen further:

  • more files
  • more folders
  • more dependencies
  • and more files again

There’s another issue: we want to make firebase upload only the files we need, and not the entire earth (like node_modules).

That’s why the next exercise will be about what we call refactoring ! That’s a practice that adds no feature, the main goal is to take time now to architecture/name/secure better our applications, so that we spend less time in maintenance in the future.

In your public folder, you should only have what you want to expose to the entire world:

  • index.html
  • bundle.js generated by webpack that contains all your javascript code, style and images if you configured it so
  • 404.html auto-generated by firebase

Everything else is configuration, source files or assets (like images).

Your job is:

  • to move all your files except those we want in public in the parent folder
  • edit the webpack.config.js to generate the bundle in the public folder
  • edit the firebase.json to make sure the config is okay
  • deploy on firebase and make sure everything is okay


The following are only propositions of architecturing stuff to make your folder more organized. Use your own if it has more sense for you !

  • Move all your sources files in a /src folder
  • Move all your Sass files in a /styles folder

Stay hyped for Day 5 ! We will plug the data fetching with our stateful Skills buttons (=with state, stateless being the contrary).

→ click here to go to Day 5👍

Call to action

Join us ! We are creating a community of motivated Léos helping each other. Apply here, it will always be free ♥

Show your support

Clapping shows how much you appreciated Damien BRY’s story.