Let’s face it, Front-End is one of the most disliked Eco-systems. Weirdly enough it’s one of the most loved platforms as well.

Having valid HTML markup on the web is not a standard or the rule it’s a luxury.

CSS is often misunderstood.

Do I need to say how most of non JS people see JavaScript like this?

Performance is not a luxury though, it became a requirement. In the land of E-commerce, reducing rendering time / page load is directly affecting the conversion rates. Which means your web app either perform well or you loose money, simple as that.

Memory leaks

Try to be honest with yourself now… How many times have you removed or even were thinking about removing event listeners you attached to the window object?

Memory leaks in JavaScript can occur very easily in such cases when we need to add resize listener to the window object and then never remove it. That can even happen in the old fashioned way of doing Front-End by implementing pages. In the modern Component Based Development removing such events became the requirement.

Imagine that you have SPA, or any kind of client rich app, where navigation can happen on the level of Front-End. You add some component to the current view and it sets resize handler to the window object, which points to one of its own methods. If you don’t remove the handler from the window once that component is unmounted, it will continue to call now nonexisting method.

Beware of memory leaks in Front-End. They are a real threat to the performance.

Server Side Rendering (re)flow

SSR is tricky, and to understand why let’s think for a moment about what Phil Karlton once said …

There are only two hard things in Computer Science: cache invalidation and naming things.

Guess what? The tricky part here is not naming!

Not dealing with cache invalidation in a careful way can ruin your SSR experience. Since it will actually make your app performance worst than it would be without it.

I saw way too many complete page re-renders after the React was served from the server. Most of the time there is a slight difference in the DOM, which made cache invalid and BOOM re-render occur.

3rd party “evil” is the most common cause for that. Imagine that you have some part of your code base which does additional calculations and repopulates the DOM after it is done. Most cases for that are 3rd party scripts which are provided by some external providers. Problem may happen when the script executes document.write() or modify the DOM in any way. In some cases we can handle with it on the SSR level; but most of the time it is not so possible.

Transpiling

Please don’t get me wrong, I love the idea of Babel and similar tools. They do bring the future to the present; just that they actually don’t… Transpiling brings pseudo-future. Kind of not so cheap imitation of what will become a standard tomorrow.

Still, transpiled code performance is most of the time very close to native implementation of the feature. But sadly things will probably change long-term. Further optimization of the V8 and other JS engines will introduce the performance gap which will obviously work for the native implementation.

Good news is that Babel maintainers already know this and am sure that they will figure out the smart way to handle with it.