DEV Community: Matthieu Lux

The Weight of JS

Matthieu Lux — Fri, 23 Aug 2019 08:24:15 +0000

There are two primary measures for JS performance. The first one, which is attracting all the attention, is DOM updating which is almost maxed out by modern frameworks. It also really depends on the application code and often not a real deal for your application (who cares about milliseconds of rendering performances when your back-end spent 2s gathering your data?).

For the second one, frameworks often don't even communicate real figures, they hide themselves behind features supposed to resolve the question like SSR, Tree Shaking or Lazy Loading. Yet, in many cases, it's a considerably more important performance issue than any other in your JS app.

It is the weight of your JavaScript code.

Never lose sight of the fact that even if we see today's websites as fully featured apps, the Web is still a platform where the whole app is downloaded, compiled and booted when you open a tab. Imagine that for Outlook, Word or Photoshop!

A webapp loading starts with the network bandwidth to download the file then the CPU to uncompress and compile it. The more code you got the most your app will need bandwith and CPU. Even then, more code will eventually mean a slower app. Look at this tweet from Nintendo.

// Detect dark theme var iframe = document.getElementById('tweet-1032276091279302656-801'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1032276091279302656&theme=dark" }

They have almost no network consideration to deal with (as far as I know) yet they care deeply about their app size for performances and fluidity.

Lastly: "less code is less bug". I always loved this quote. Shipping less code (both yours and third parties') will always be better for stability.

Tools don't solve everything

A good part of the so rich Web tooling we use nowadays is about limiting the size of your JS. All of these techniques are optimizations which are great and I recommend to use almost all of them. Yet, optimizations are not solutions and the real amount of JS is still a question.

Bundling

The first tool we use when tackling JS performance is bundling. We don't serve the browser as many files as we develop knowing that every request to the server has its cost. Most of the time, we compile a bundle of one, two to five bundled JS file. Yet, you still have as much code as before.

Minifying

For a long time, we've been using JS minification, which means modifying the code by removing most of white spaces and line breaks as well as renaming variables to shorter names in order to have almost the same code but with less characters and then, get a smaller weight. It's great and it has almost no downside except readability and then debuggability which can be handled with source maps.

Minification will reduce the weight of your JS from 50% to 90%! (if you have lots of comments 😀)

Compression

The most magical solution to reduce JS weight is binary compression. Most of the time, you don't even have to configure any tooling, it's your HTTP server which will compress your files with Gzip or Brotli. For best practices about compression, see this great article by Antoine Caron Why you should use Compression Webpack Plugin?.

Like the other solutions, compression is great and you should definitely use it. Nevertheless, it doesn't mean that you are free to serve any amount of JS.

First, no matters how great the percentage of reduction the compression offers, it's still a ratio of your original weight: 30% of 10MB is still 3MB…

Second, compression is only a network artifact. The amount of data to carry over the network is reduced but your actual amount of code is still the same. The browser will still have to parse and compile the same amount of code. Even worse, the client will have to decompress the file before being able to use it. These steps could seem unimportant but on an old smartphone, it can be really slow, sometime longer than network time!

Take the example of 6play.fr: 1MB of JS, 100ms compile time on my MacBook and up to 500ms with CPU throttling.

This illustration come from Addy Osmani and its post The cost of JavaScript. He's an important reference on the subject and producing measures on these type of things can be tricky.

Beware that most frameworks communicate about their size only after binary compression. "Preact: Fast 3kB alternative to React" but with an actual size of 8.7kB before compression (which is still great btw)

Tree Shaking

Another magic feature to reduce the amount of code is called Tree Shaking. It's the ability in modern JS code to statically analyze imports in your code in order to automatically detect unused parts and remove them.

Frameworks like Angular have deeply invested in Tree Shaking. They've optimized their own source code to import only what's needed. That way they ensure that only the necessary parts of the framework are imported and then, produce the smallest possible bundle.

Tree Shaking is available in almost all bundlers by default now.

Server Side Rendering

First of all, SSR is the Web frameworks' ability to be executed server side in order to serve a fully computed page in response to the initial request from the client, allowing the user to see something during the JS load time.

I'm a big fan of server side rendering yet today I will point its limitations.

SSR will reduce what we call the Time To First Paint (TTFP). The time between the initial request from the user and the moment when the user actually sees something. It's especially important for content websites and almost mandatory for SEO (most crawlers will not execute JS). Still, when TTFP occurs, you don't have any JS loaded and your page is not interactive.

After the JS is loaded, the framework will start over, "hydrate" the existing markup and then being able to handle user events. We call this, Time To Interactive (TTI).

In some ways, SSR could even be counterproductive. Mainly because running the framework server side use time and resources when returning static resources is faster. Also because most frameworks, to be able to "hydrate", need an export of the context used server side which can represent some weight too.

Lazy Loading

In the early days of Single Page Applications (SPA), we were used to bundle all our JS code. Which meant that as soon as we were requesting a webapp, we were sending all the source code the app would ever need before doing anything. That was bad and fortunately, frameworks and tooling evolved to manage JS code lazy loading with increasing ease.

A well implemented Lazy loading mechanism means that you will only start downloading the code needed to bootstrap your application at the beginning. You will load the rest of your code latter on, when you will be needing it.

Still, if you need a lot of code to run your app, at one point or another, you'll need to load it.

Compiling vs Runtime

A new approach has appeared recently. By compiling some application code, they can reduce the size of the library left to load. In a compiler the common code used by the compiled code is called the runtime.

Two frameworks illustrate this concept. Angular, since its version 4, proposes to compile template code at build time (the feature is called Ahead Of Time or AOT) to save up to half of its size. The second one is Svelte, the first framework which concept is to have no runtime at all.

Compiling is an interesting strategy but beware of backfire. Compiled code will ultimately be bigger than your source code and at one point, using a runtime could produce a smaller bundle.

And so on…

There is a lot of tools and strategies to reduce the weight of your JS. I didn't mentioned them all, there are also cache considerations, CDNs and I surely missed a few.

But you understand now that none of these techniques are absolute, you still and always have to care about the weight of the code you ship.

The weight of things

In order to manage your app dependencies considering their weight, you have to know how much things weigh.

There are popular plugins like VS Code Import Cost or Webpack Bundle Analyzer to show the weight of each import you do in your code.

They are pretty fancy but beware because the problem is that worrying about weight in your code editor is too late. You have to consider the matter before hand, when you choose your stack.

As explained before, there are different measures commonly used. Mainly before and after compression. To make it simpler, I will use the figures before compression (but after minification) from now on.

Common frameworks and library

Without larger comments, let see the weight of the most popular libraries commonly used nowadays (sorry if yours isn't there)

Lodash: 72kB
jQuery: 86kB
Backbone: 42kB (including Underscore but will need jQuery too)
AngularJS: 172kB
React: 117kB
Angular: 299kB (bundle of a Hello World app) with AoT, 663kB with JiT
Vue: 91kB
Preact: 8kB
Ember: 733kB (bundle of a Hello World app)
Leaflet: 138kB
Bootstrap: 152kB of CSS, 57kB of JS
Bulma: 186kB of CSS

Hello world weight vs real world weight

When it comes to JS Web Frameworks, figures have to be discussed furthermore.

Modern frameworks are deeply modular. As much Angular which considers each module as part of the framework, as React which considers each module as third parties. Yet you often need these modules for your app, so, considering only the core framework weight is a mistake.

It can create an important difference between the weight of an hello world app using only the core module of a framework and a real world app. The extensive use of Tree Shaking recently amplified the problem. The risk is that some framework would communicate on cool numbers with a very simple example using nothing and where Tree Shaking removed literally everything when the true size of the framework has not changed.

To perform these measures, I bundled the apps with the framework, a state management framework, a router and a Material Design component library (with an import all to prevent Tree Shaking). It's not really like "real world" apps it's quite similar.

We see that the initial weight of a framework does not necessarily indicates the final result. Yet, it looks like the Vue figure is mainly due to Vuetify which contains really a lot of components.

The weight of your code

In any other platform I know of (surely it should exists on hardware development) the size of your own code doesn't really matters. I remember Java applications where there was hundreds of megabytes of dependency jars when my jar was one or two megabytes. It's not a troll about Java, it doesn't really matter in this case.

In frontend JS, you can't think that way. Your dependencies has to be small and your code can really quickly be bigger than your frameworks.

It's not necessarily wrong. Big webapps exist and they need code. But you should be aware that it's an issue and you should use all the techniques explained before to minimize the weight.

For example, I used to work on a big webapp where the vendors was about 350kb (after compression) and the specific code was about the same.

The weight of other things

Until now, I only talked about weight of the JS files, yet a website is made of contents from several different types. When you take care of the weight of your JS, you also have to consider the whole pictures.

Your website will surely contains also HTML, CSS, images, fonts, videos…

Outside of special cases, HTML will be very light, yet it's always great to minify it.
CSS could weights a few hundred kB to more than a MB. So it has to be considered. Dead code elimination, lazy loading, minification, all of theses techniques can be applied to CSS too.
Images will often be the heaviest things to load on your website. They have frequently been used as an excuse to avoid taking care of the weight of JS files because "it's only a little percentage of the whole page". Images are a really important matter of your page weight. You have to carefully optimize it, download the smallest version possible, lazy load some and sometimes just remove some others. If images are handled carefully, they can weigh less than your JS.
Fonts are a content type often ignored in web page optimization but they are super heavy and they are a rendering bottleneck to display something on the page.
Videos are a really specific content type. It weighs a lot but are often not auto started, really well compressed (except gifs 😂) and are streamed most of the time so in these cases, it does not impact the website load time directly.

According to HTTP Archive State of the Web, the average website weigh today is 1.8MB on desktop and 1.6MB on mobile. The share of JS in that weight is 22% or about 400kB (on the wire).

Conclusion

The Web is a platform where no matter what you do, the weight of your code matter. We have an ecosystem full of great tools to optimize it yet there is no silver bullet and at one point or another, you will have to pay the price.

It brings the comunity to push forwards with new frameworks, new features without adding more line of codes sometimes even less (VueJS is smaller than AngularJS).

It has a very cool symbolic where each line of code is precious, highly well crafted and the comunity has to evolve with pure new ideas and never just stacking up new code over old one.

All the figures in this post are computed from this GitHub repository:

Swiip / weight-of-js

Weight of JS

This repo is aimed to back an article about JavaScript size.

Here is the DRAFT of the article: https://medium.com/@Swiip_51904/the-weight-of-js-44ae2f118506

You can comment to help me but it's not ready to be published.

Sections

There is 4 sections planned at this point:

minification: to list, run and compare majors minifyers
compression: to list, run and compare majors compressions algorythms
hello-world: to compare hello world app weight with different frameworks
full-app : to compare (almost) real life app weight with different frameworks

View on GitHub

Using React Hooks

Matthieu Lux — Tue, 26 Mar 2019 12:54:31 +0000

Photo by Robson Hatsukami Morgan on Unsplash

This is the follow-up of my first post React Hooks, my introduction. If you don’t know what hooks are or just want to start from the beginning please check this article first.

As promised, I have now used hooks on a PoC project: pokemon-arena and one in production: the zenika.com website (not open source, sorry, perhaps one day…). I don’t have a lot of feedbacks about the PoC but using hooks on a real project has opened new questions.

This post is the feedback of my experience with hooks regarding some developer perspectives such as: code-reuse, 3rd-party librairies and testing.

A last reminder about the fact that no one in the React team nor me is advising you to refactor your whole codebase like I did. It’s just a new opt-in feature you can use if you want. I made the switch aggressively out of curiosity not because I needed it.

Code reuse

One of the major benefits provided by hooks is the ability to reuse code. As a user of Recompose, I was already able to reuse code as custom HoC. That was one of the most important reason I used it in the first place. Switching to hooks first allowed me to remove the library on itself then to convert all of my custom HoCs to custom hooks. It was pretty straightforward as I could replace them one for one with the same semantic.

Not a huge code reduction then but I was happy to see that I could keep the benefits while removing a library.

Let’s see an example of component logic sharing. In zenika.com, there is a list of our agencies coming from a GraphQL request. I have a bit of logic (with Redux) to shuffle the list not to present the same order every time (and make no one jealous 😂). But I use this list in two places on the website.

There is a few requirement for this feature. Load data only once for several uses, shuffle once to avoid having different results at each rendering (avoiding inconsistent rendering). And simply don’t forget to use the shuffled list everytime (I mention it as I had the bug).

It quickly made sense to extract a custom hook gathering the logic of fetching data, launching the shuffle, then returning the list. With a custom hook, there is a lot of benefits :

Other developers only have to think of using that hook to get the agencies list. They can forget about the shuffle logic.
Two different components will always use the same logic to access agencies list and can’t behave differently.
It’s great for testing and isolation of concern. The hook will be able to be tested isolated from any component checking only for the logic of fetching agencies. The components can suppose that the agencies from the hook is good and focus on their own logic about displaying them.

We can also imagine guidelines in a project (even if I didn’t go that far) where the direct use of a data related hook like mine for GraphQL is prohibited in the components in profit of always using a custom hook. In that case, we would be able to fully isolate the data layer and to add logic like my shuffle or even changing the data framework without touching the components.

Third parties

With my own experience of switching from HoCs to hooks most of the time passed was not about converting lots of code to the new API but in finding and configuring new third party libraries.

I allow myself a bit of a digression. That’s typical in many structural evolutions. We estimate not enough time to deal with new libraries and too much about simple refactorings. But that’s another topic.

Let’s put some context. Zenika.com is a corporate website with not a lot of logic but has to deal with SSR, content and i18n. The main libraries I used besides React are: Next, Apollo, Redux and i18next. You don’t necessarily use the same ones but they covers most typical cases.

Next.js

Next doesn’t provide support for hooks yet.

That sentence doesn’t have any real sense but I kept it knowingly to open the question of the meaning of supporting hooks. Hooks are just a new opt-in API so any existing framework or library is compatible. A library which supports hooks would only be a library which offers some custom hooks to use its feature.

Next is more a framework and has a small API which can be proposed as hooks. The principal one is the router which has to be accessed through a HoC withRouter and where we would like to have also a useRouter. The lead developer of Next already teased it on twitter, also, there should be a way to add it manually.

But I chose to kept it as an example of cohabitation. I still use the official withRouter with no problem in a middle of an app which now exclusively uses hooks and almost any other HoC.

I asked myself another question about removing HoCs with Next but it’s a side question which I will only brush here. To configure frameworks like Apollo or Redux in Next, there is the use of HoCs on the _app.js component. I tried to remove those HoCs for some kind of “no HoC extremism” and failed. Indeed, these HoCs are more complicated as they have to handle server side and browser side. This is just a reminder that HoC are still an interesting concept which could keep some value even with hooks.

i18next

If you don’t know anything about i18next, it’s a i18n library (as indicated by its name) not bound to React, I use the official wrapper react-i18next.

In that case, react-i18next already published a major version containing a hook API when I started my work. That was pretty amazing, not much libraries reflect frameworks evolutions as quickly.

Hooks migration basically took the shape of a library update with its lot of breaking changes. But basically, switching from the HoC withNamespace to the Hook useTranslation was quite easy.

Redux and Apollo

I coupled these two libraries not because they are alike in any way but because my journey for using them with hooks was very similar. In both cases, the official library didn’t support hooks yet (react-apollo and react-redux) intends to (for Apollo and for Redux) but there is alternative implementations which already exists (react-apollo-hooks and react-redux-hooks).

I found both alternate libraries quite stable already and was able to use their hooks pretty quickly. In both cases, I mostly struggled with their Next wrapper which is not directly related to hooks. Once the wrapper worked server side, client side and handled the hidration (mechanism of restarting React on an existing markup), the rest went smoothly.

The only question left was about the hook API. The one from react-redux-hook has (at least at this moment) a really low level API forcing you to handle callback memoization by yourself each time. I was able to produce a wrapper more suited to what I wanted very quickly. We submitted a PR with a friend which will not be merged as is but the API should evolve soon.

Memoization

In my experience of using hooks, there was only one pain point worth to mention deeper. It’s about memoization. You have to understand that writing your logic inside the render method is cool but you can’t fully forget that it’s a function which will be called at every render of React and there can be a lot.

To avoid running some code too often, the entry point is the useMemo hook. It takes a function as first argument and an array as second. The array is the list of dependencies of the function. React will check by reference each of them and call the function only when there is a difference. The return value of the hook will be the return value of the function in first argument. (For the Vue developers, useMemo looks a lot like a computed property)

This way, you can control precisely when some code will be run or not and save some calculations but the pattern on itself is used in several other hooks. The second to mention is useCallback which is basically the same as useMemo but for functions. But the most important to mention is useEffect.

If you’re like me, you’ll suppose useEffect is like componentDidMount and you will be surprised to see that it’s ran way more than once. It’s in fact more the equivalent of componentDidUpdate. By default, it’s ran for each change in the components and it’s often not what you want. useEffect takes an array as second argument which is the same semantic as useMemo and will allow you to control when the callback will be ran.

It works pretty well but to be honest, having to care about when each code is ran considering each reference I passed in lists in second argument can be boring and error prone. I ended up many times putting a log in my useEffect to check if it was called when I wanted and no more.

Testing

There is a topic about hooks where I’ve seen everything and its opposite, it’s about testing. In my project, I updated all my tests and there is what I found.

First, there is the separation of concern. Being able to extract logic code from components and localize it in a dedicated file is, by essence, great for testing. Testing a custom hook is quite easy, not much to say, you don’t have component or rendering to manage, you just have to check the logic of the hook. It’s easier than testing HoC as you don’t have to handle a dumb component to wrap.

During a moment when hooks was just released, it was said that it was not working in tests. In fact there was a bug in Enzyme that lots of people are using but it has been quickly fixed. There is still no direct support with utility functions for hooks but at least you can test a component with hooks as any other.

I think, there is two major ways to test a component with hooks.

The way with a real mount: no mocking of hooks and interact with the component in a way which triggers hooks and tests the result.
The other way is to shallow the rendering but in this case, at least today with Enzyme, you have to mock all hooks. It could seem to be difficult but mocking hooks is quite easy.

Shallow rendering and mocking hooks is the way I chose and I was pretty happy with it. Mocking all hooks allows me to perfectly isolate my components and each frameworks like Apollo or Redux considering my components are in charge of only rendering data and hooks are in charge of behaving as they should.

Other remarks

Using hooks, I made several other smaller remarks

Heavy usage of HoCs blurs a lot what props your component is receiving or not. Props jump from one HoC to the next and you often end up with arguments in your functional components which are totally different of the one really needed in input. Hooks restore real props in your function declaration which helps readability.
One goal of removing HoCs was about to simplify the component tree of React. To be honest, it’s better but not so much. Mainly because I use styled-components ,“ok”, but not only. There is a lot of components in a React app and each use of a context adds a layer and to be honest, it’s still not really readable with hooks.

Component tree with hooks

Small pain but real pain. Switching from a real dumb functional component to a one with hooks asks you to add a function body (adding braces) and a return statement for the markup which is a pain to change in every single file.
I surely spent more time about updating libraries which use other new APIs of React than hooks. I think mostly of Suspense and the new context API. It’s just that these new libraries versions which offers hooks are more recent and use “also” the last features.
Perhaps you see this coming before but I didn’t use a lots of native React hooks. Some useEffect and some useState. But in the end, the hooks I used the most are useRedux, useQuery (Apollo) and useTranslations (i18next).

Conclusion

I’m still fan of hooks. It didn’t profoundly change my code because I anticipated the move through HoCs. But now, I can profit of the code reuse of sharing component logic as a part of the framework and not some trick I’m using and others doesn’t understand.

Photo by Chen Hu on Unsplash

As you would expect, it’s still fresh, several libraries are not ready yet and others are still in transition. But I’m pretty convinced that hooks are here for long and will progressively become standard in the React community.

React Hooks, my introduction

Matthieu Lux — Tue, 19 Feb 2019 14:55:31 +0000

Sorry, it was a bit easy 😂

How to write an article about React Hooks when so many has already been published? This is the question I asked myself before starting this one. I almost abandoned the idea then finally found a bunch of good reasons to continue:

Firstly, if you don’t write something someone could have already written, you never write anything.
I intend to start a series following my own journey using hooks on an existing project, so I need an entry point.
By being a bit hype driven by nature, using Recompose (see below) for a long time, looked at React Fiber under the hood and having the opportunity to test hooks in early stage, I may have some interesting insights about this new feature.

So I will simply start this article considering you know the basics about React but nothing about hooks.

React state of the art before hooks

There are two major ways of creating a React component : by creating a class or a function.

The function component is more fashionable because it’s shorter and fits well in a community in love with functional programming. To go further, it’s the direct application of the React concept saying that a component is a direct transformation of input properties into markup.

But before hooks, functional components were really limited. No state, no lifecycle, you were able to use those components only for really simple use cases.

To have full control, you had to convert your component to the class version.

I don’t want to enter the never-ending “functions versus classes” debate, let’s just say that switching from one to the other each time you need a state variable was painful (unless you’ve got some fancy features in your editor as in Webstorm).

Higher-order Components (HoC)

A pattern has emerged in the React community. It is now very common and has surprisingly no equivalent in other frameworks: HoC.

Basically, it consists in a function which takes a component in argument and returns a new component wrapping your component and passing props allowing you to use specific features.

This pattern has quickly spread and there are multiple open-source libraries that mainly rely on HoC to get access to the Redux store, inject GraphQL data, get i18n translation, and so on.

This pattern has a lot of benefits:

Your own components can stay simple, most often, they can be functional component.
Each feature your component uses can be easily identified. It can even be shared between several components.

Those who liked this pattern the most has even imagined to do everything with HoC. There is a de facto library dedicated to this concept which is called Recompose. Recompose offers a whole bunch of basic HoC to use every aspect of React, you just have to compose your HoC with each feature you need.

I was a big fan of Recompose, I built whole apps with it, using absolutely no class component at all. It was great for code structure and logic reuse.

But HoC have real drawbacks you have to understand:

The concept of component encapsulation is not easy to apprehend. I still need a moment of reflection when writing one from scratch.
Encapsulate 2, 4, sometimes 6 or 8 components around the one you wrote has a performance overhead, it’s a fact. It may not be heavy but it’s true.
HoC really make your debug panel looks like a mess. It makes me remember the dark days of JavaScript callback hell!

Hooks!

Wow, finally the main topic! I wanted to explain the context of the usages in the React community in order to understand what problems the hooks try to solve. Now we are ready!

Hooks let you use state and other React features without writing a class. You can also build your own Hooks to share reusable stateful logic between components.

That’s the direct quotation from the official announcement of the release of React 16.8.0 which contains hooks (yes, they are already released!)

If I tried my own explanation, I would say there is a new set of simple functions you can use in functional components to access to all React features, just the thing you couldn’t do before.

These functions triggers basic React features and you can use them directly. You also can, and are encouraged to do it, compose them to make more advanced ones. Or it will be your favorite frameworks which will use them to give you access to their features.

There are 3 basics ones easy to remember:

useState to declare a new state variable for the component
useEffect to interact with the component lifecycle
useContext to get a context value

The complete API can be find on the official React documentation.

As I have deeply introduced HoC, you can see hooks as the combination of the good parts of HoC: organizing and sharing component features, without their bad parts: extensive component encapsulation.

To me, as a user of Recompose, hooks have turned one of my favorite library completely useless but what better end a library could have other than the generalization of the concept directly in the framework it was trying to fill the blank?

For those who are concerned about Recompose itself, you have to know that the creator Andrew Clark is now in the React core team, he worked himself on coding the hooks and officially stated that it is destined to be abandoned. Big up to him!

What is not said at this point is that hooks are fully retro-compatible. Classes components still works as before, HoC still works the same too. The React core team even doesn’t advise developers to aggressively convert their codebases (exactly what I will not do 😇) but rather advise to get used to it on a few new components before considering to refactor the old ones.

Why is it so exciting?

If you are a JavaScript Web developer like me, perhaps you already think of all the benefits you can get from this new feature and why it is a really important one and not just a new gadget among others.

Yet I think that it’s a good exercice to sum them up. Let’s imagine what a React world full of hooks would look like (I’m pretty sure the community will tend to widely adopt them):

The end of the segmentation between functional and class components, at least in the same project. Functional and class components becomes a personal style choice just like space versus tab indentation or trailing comma…
Abandon of HoC to save complexity, performance overhead and debug obfuscation.
If there is no more class, there is no more this 🎉.
As component logic is just function calls now, it can be extracted in other files, shared, reused and tested way better than before.

This last point is by far the most important. It’s something I already tasted (yes, with an “a”) through an intensive use of Recompose. I have no word to tell you how amazing it is and I’m very pleased to see that I can now implement the same thing out-of-the-box using React itself!

How it works (roughly)

From the user’s point of view, you just call use** functions from your functional component and that’s all. But how can it be possible or even performant when you know that this component function will be called for each change detection?

It’s at this point that you discover that there are rules to use hooks.

Hooks are not standard functions.

In a nutshell: you can only call hooks from functional components and you have to always use the same amount of hooks and in the same order at each execution (so you don’t put hooks in a condition or a loop).

It makes sense looking at the hook implementation in pseudo code.

Originally written by Jamie Kyle

So each hook function get back to the running instance of React in a shared array. React is in control of calling your component so it knows perfectly from which component you used the hook.

The hooks array allows React to match a previous call to the next one of the same hook and that explains why there is a rule about the amount and the order. This implementation can be (and has been) discussed but the React core team concluded that this is the best choice considering several solutions as Dan Abramov explained it well.

More globally, as hooks can’t be called from anywhere, in any order, anytime etc.:

Hooks are not a safe pattern by design.

That’s a sacrifice the React team has made allowing a very simple API for the vast majority.

About performance, we add code in the render function which is called many times. It can have a cost and we have the responsibility as React developers to not do intensive computation in these functions.

Yet, we should only call a bunch of hooks from these functions and we are not supposed to do a lot more. On the opposite, we gain the overhead of not defining and instantiating a whole class which could me more important.

Finally, when performance really matters, several hooks have memoization options which allow the developer to precisely define when to run code.

Let’s write some hooks!

It was quite a long article yet we barely brushed the subject. Using hooks (and only hooks) in a whole application raises a lot more questions.

That’s why this is only the first, a bit theoretical, article on the subject. I planned to write another ones during my own process of switching to hooks.

As a modest cliffhanger, here is what I planned to address in the next articles:

Hooks in third party frameworks (in early 2019)
Examples of logic sharing between components
Comparison between Recompose and hooks
Hooks and SSR with Next
Testing custom hooks and components with hooks

Announcing: compo

Matthieu Lux — Mon, 25 Jun 2018 14:44:16 +0000

🎼 Compo·sing Web Compo·nents

compo is a new JavaScript Web UI library based on pure Web Components providing a modern API using function composition to easily define and enrich them.

Yes! It’s yet another new JavaScript Web UI library! Sorry for the “JavaScript fatigue” people still I thought there was some good ideas in this project and it deserved to be at least published.

Inspiration

It’s inspired by many populars library such React, Redux, Recompose or styled-components, applying the modern concepts and API to the Custom Element standard.

The Virtual Dom concept introduced by React some time ago has been used to free the user to manage DOM transitions. The concept can be applied to standard Web Component world, each component diffs its template evaluation to the own Shadow DOM.

Recompose introduced a full function composition API allowing to enhance a component feature by feature as needed. Once again it could perfectly match Custom Elements by extending the definition class with the features needed.

Finally, using CSS in JS with styled-components for a while pushes to consider CSS as an integrant part of a UI library and treat it the same way as the markup. Shadow DOM CSS scoping does perfectly the job.

API

What I regret in all the previous inspirations was the complexity of using a lot of different libraries to finally get a strange monster full of good ideas but with complex non homogeneous APIs.

So compo is a fully featured library presenting a single coherent API to manage all aspects of a component: state management, markup, style.

As said in the title, the chosen interface is function composition. You define a component with the component function, first parameter for the name, all others for enhancing functions like withStore , withMarkup or withStyle.

https://medium.com/media/b94188706ea7aad038c8bfc2f7524bdb/href

Standards

The whole process was driven by minimalism for both simplicity and bundle weight. What’s best for minimalism than taking as much as you can from your browser directly?

The point of compo is to present a powerful API by doing the less possible using as much as possible the standards. As such, it’s heavily built upon Custom Elements, Shadow DOM, ES2015 template strings. Even the Virtual DOM parser is in reality the native browser DOM parser.

Also, one of the guidelines was to use the power of new browsers. Not to ignore Web history or compatibility but to imagine what could be modern APIs without limitations. For example, compo is not (at all) transpiled. It’s written and published in modern ES2017. In fact, it works already in the vast majority of browsers and everyone can transpile it in its application if needed.

Ambitions

compo is not yet, production ready. To be honest, it only really works on Chrome out of the box and Firefox with a flag. There is a compatibility example using Web Component polyfills to use it on every browsers.

In terms of performances, concepts should not be blocking but at this point don’t try aggressive benchmarks compared to an industry framework, it could not end up well. Still it’s powerful enough to build “standard size” application without have real issues.

To be perfectly honest, compo is also some kind of child dream. “I published my own JavaScript library 😃”. We’ll see how far it goes but I do think there is some good stuff in the library. If it only influence a bit the community, it will already be a huge success.

https://medium.com/media/3c851dac986ab6dbb2d1aaa91205a8eb/href

Make Service (look) Great Again

Matthieu Lux — Wed, 24 Jan 2018 15:45:09 +0000

Aujourd’hui, si un développeur cherche un nouveau job, sa préférence ira le plus souvent sur les startups ou sinon un éditeur. Il est pratiquement admis par tous qu’aller dans le service est la voie de garage pour les “mauvais”.

Je suis dur et pourtant j’y travaille dans le service, et ce, depuis plus d’une décennie. J’ai vu ce sentiment s’aggraver et beaucoup de mes collègues démissionner pour aller en startup ou chez des éditeurs.

Photo by Helloquence on Unsplash

Je connais le marché français et j’ai tendance à penser que c’est un problème franco-français, mais je pense que c’est bien plus vaste que ça. Y compris aux USA qui ne se limitent pas (si si) à la Silicon Valley.

I try to write in english on Medium, especially for technical articles. This one is not technical and more for the french audience. So, I choose the easy path and wrote it in french, sorry ;).

Comment en est-on arrivé là ?

Tous ceux qui sont dans le domaine depuis quelque temps savent bien pourquoi. Encore que les mécanismes sont parfois plus profonds et insidieux qu’il n’y paraît.

Peut-être que tout commence par le fait que, pendant longtemps et encore aujourd’hui majoritairement, l’informatique est considérée comme un centre de coût de l’entreprise et non pas comme une richesse ou un cœur de métier.

À partir de là, le but est de produire les développements indispensables à la survie de l’activité, mais en évitant au maximum les dépenses et les engagements. Du coup, on préfère payer de la “prestation” qui correspond bien à la notion de “coût” plutôt que d’embaucher un informaticien puisque ce n’est pas le “cœur de métier”.

Pour répondre à cette demande, on a vu débarquer les mégas sociétés de services, véritables intérims de l’informatique qui vendent des informaticiens par paquet de 10 voir 100. Dans le milieu, on appelle ça les “marchands de viande”.

Photo by Lukas Budimaier on Unsplash

Vous pouvez imaginer le genre de production de qualité que cela peut générer. Hé bien! Je vous le confirme, ce qui en sort n’est pas fameux et ne doit pas réconcilier les dirigeants avec l’informatique et ses coûts.

Évidemment, travailler dans “ces” sociétés n’a rien de reluisant et encore, je passe sur une bonne quantité de dérives que cela produit.

À quoi le service devrait-il ressembler ?

Je vous préviens, c’est le moment “théorie”, détachez-vous du contexte actuel.

Le service devrait être le métier le plus valorisant dans le développement.

Imaginez-vous : votre client, son DSI, ses développeurs admettent ne pas pouvoir produire un développement dans de bonnes conditions. Ils vous font confiance, à vous, à vos compétences, pour venir les aider.

De votre côté, vous vous enrichissez au fils des missions, des applications, et des contextes toujours différents. Vous êtes les seuls à pouvoir éviter la terreur de beaucoup de développeurs : l’ennui.

Sur un produit, en startup ou pas, vous avez une stack technique et vous allez en bouffer pour les 5 ou 10 ans à venir. La tâche marrante de mettre en place ou changer une techno sera réalisée dans les 6 premiers mois et il ne vous restera plus que de la feature ou des bugs.

Photo by Ben White on Unsplash

C’est même vrai pour ce que beaucoup dans mon entourage considèrent le dream job : travailler pour un GAFA sur la techno du moment. En vrai, le rêve est d’inventer la techno du moment, ensuite, ce sera bugs et évols comme chez n’importe quel éditeur. Je sais, j’ai l’air terriblement négatif, mais allez voir un GitHub d’Angular ou React, imaginez vous en responsable, est-ce vraiment le dream job ?

J’ai même un exemple dans la Silicon Valley. Attention je ne connais pas ces gens, je peux avoir une interprétation limitée. Victor Savkin, travaillait chez Firebase puis a rejoint la core team d’Angular. Le rêve de tout développeur non ? Au bout d’un an ou deux il démissionne pour créer sa propre boîte de… vous avez deviné : service.

Il en faut pour tous les goûts

Même si bien sûr, je fais ici l’apologie du service, cela ne peut pas être la seule voie possible pour les développeurs. Ni même pour les “bons” développeurs.

Certains développeurs sont faits pour travailler chez un éditeur. Personnellement, ce n’est pas mon cas donc je suis obligé d’extrapoler. J’imagine que ce sont des personnes pour qui ce qu’ils produisent prend plus d’importance que comment ils le font. Je le respecte, cela pourrait même m’arriver un jour !

Cela revient à une question existentielle que chacun devrait se poser : quelles sont mes motivations à pratiquer le développement ? Si c’est un outil pour atteindre un objectif, l’édition semble être la cible, si la réponse est la curiosité et l’envie de toujours remettre en cause les pratiques, le service devrait être la destination naturelle.

Cela ouvre un plus grand débat sur les carrières et les évolutions dans le développement. La formation, la rémunération, les perspectives. Mais cet article ne peut pas tout traiter.

Comment s’en sortir ?

Je n’ai pas toutes les réponses et encore moins toutes les solutions (je serais riche sinon ;p) mais il parait étrange d’écrire un tel article sans tenter quelques analyses.

Je ne vais pas emprunter le chemin de la facilité et dire du mal des “marchands de viande”. Je ne les aime pas, c’est sûr, mais je pense qu’ils ne sont qu’une conséquence du problème.

J’hésite sur la question politique. Est-ce normal que ce soit plus facile pour une société de prendre de la prestation par wagon plutôt que d’embaucher ?Mais là encore je pense que si, intrinsèquement le client ne considère pas l’informatique comme une richesse, il fera ce qu’il faut, même si c’est débile, pour ne pas l’avoir en interne.

Idéalement, il faudrait que les clients changent de regard sur l’informatique. C’est en cours, mais bien sûr, ça prend du temps et c’est très variable d’une entreprise à l’autre.

De façon réaliste, je pense qu’il faut savoir dès aujourd’hui distinguer deux types de sociétés de services. Les “marchands de viandes” et les autres, celles qui essayent de prendre la position que le service devrait avoir. On les dit “société de services spécialisée dans l’expertise”, “société de conseil”, ces noms ont peu de valeur, elles sont pour moi celles qui cherchent à prendre la vraie place de la “société de services” à l’opposé de “la société d’intérim”.

Minute Zenika

J’ai fait bien attention de ne pas “vendre” ma boite jusque-là. Je pense sincèrement que le reste n’est pas lié à Zenika à proprement parler. J’ai quand même envie de parler de quelques points différentiants intéressants de “ma boite”. Si vous ne pouvez pas supporter ce moment de promotion flagrante, passez directement à la conclusion.

Je pense que sans prétention exagérée, Zenika fait partie de la bonne catégorie des sociétés de services. Ce n’est pas la seule, Xebia, Sfeir, Octo en font sûrement également partie même si on apprend à les détester par chauvinisme facile ;) Mais je parle de celle que je connais bien.

Le package que propose Zenika à ses collaborateurs devrait, sur le papier, être le Graal d’un développeur. La possibilité de faire à la fois : des missions de réalisations, c’est à dire du développement concret sur plusieurs mois, des missions de conseils pour se focaliser sur une problématique précise sur quelques jours et de la formation pour transmettre et apprendre à transmettre les connaissances est, de mon point de vue, la position la plus enrichissante pour un développeur avide de savoir.

Avoir à la fois la possibilité de participer pleinement à un projet de temps en temps pour avoir un lien et mettre en pratique ses idées dans la réalité d’une équipe de développement. Intervenir ponctuellement chez certains clients pour se confronter à des problèmes complexes et voir une grande variété de projets. Transmettre ses connaissances ce qui, on le sait, est la meilleure façon de consolider ses propres compétences.

Bien sûr, rien n’est jamais parfait. Zenika a “aussi”affaire à des clients qui ne valorisent pas l’informatique et qui cherchent juste à externaliser un coût. Et en interne, la tentation est toujours grande de placer un collaborateur sur une mission pépère où il facturera de façon fiable sur le long terme pour assurer les résultats de l’entreprise.

Changez de regard sur le service

On peut attendre que les grands dirigeants changent de regard sur l’informatique en se contentant de dire du mal des “marchands de viande” et des DSI (représentant du rapport à l’informatique chez nos clients). Mais je pense que les acteurs de l’informatique qui souhaitent que ça change peuvent également participer à ce changement.

Changez de regard sur le service. Arrêtez de croire que seule la caricature de la société de services existe.

Et surtout, au lieu de fuir cet univers en décrétant qu’il est pourri. Allez-y ou restez-y et “pratiquez-le” de la façon dont vous pensez qu’il devrait l’être. Si votre boite ne le permet pas, changez là, si ce n’est pas possible, changez-en. Mais pas lâchement en allant chercher un éditeur chez lequel vous vous ennuierez.

Le “vrai” service existe, il peut vous combler tant techniquement que financièrement.

C’est un bel objectif qui mérite qu’on se batte pour lui.

Wrong comparisons between React and Angular

Matthieu Lux — Fri, 09 Dec 2016 15:09:28 +0000

For a while now, I’ve been used to switch between Angular 1, Angular 2 and React in different projects. I’ve also been talking to many different people which are fans of one or another framework. I’m able, now, to compare each solution for what they really are.

The purpose of this post is not to make another comparison between these frameworks in order to define which is best. It’s to point out that the most common comparison arguments I heard are wrong.

Most of this post will not differentiate Angular 1 and 2 as the points are valid for both. There are more similarities between Angular 1 and 2 than people tend to agree, but that’s a subject for another post!

Angular is Fullstack, React is a tiny UI library

That’s a bit of a joke, sorry for the strong words. By considering the initial design of both solutions, perhaps, yes. But today React is a complete platform. Who, recently, has ever included React as a tiny brick of their bigger Web application? Most of the times, the UI framework is the first choice for your frontend app: will you choose Angular or React (or something else)?

Once you chose React, you’re almost forced to use Babel and Webpack, nowadays you’d use create-react-app, you’d use react-router because it’s almost the only solution out there. Your code base will certainly be completely shaped by the choice of React. So basically it has the role of a “framework” and not a tiny lib whether you want it or not. Regarding the logic structure of your app in React I suggest you to wait for the second section below.

On the other hand, nobody asks questions about Angular as it’s sold as a full-featured framework. As a side note, Angular 2 supports server side rendering via a different project (Angular Universal) while React supports it out of the box. So the position of both frameworks are a bit different for sure, but in the bigger picture, they are both “big frameworks”.

People defending this difference often bring a strange last argument. It’s the question of “the requester lib” (you know, fetch, $http, Http, axios, superagent). Ok, React doesn’t provide one, Angular does. It’s almost the only real freedom you have with React so I think this is not a sufficient point to keep this strong line between the two solutions…

Angular organizes your logic, React doesn’t and you have to use Flux

If you look at most of the open source projects with Angular or React, it’s true. Most of Angular apps are organized with “Angular services” and most of React apps use a Flux implementation. However, I spent some time recently to really analyze the conception differences between React and Angular on this question.

My results are very different from the common acknowledgement. Angular is not organizing your logic. Angular provides you dependency injection system which allows you to manage singleton easily and improves testability. But your logic is still contained in a whole bunch of singletons. People whoever have developed a big Angular application knows that singletons are not sufficient to a logic organization.

This singleton approach is perfectly doable with React and JavaScript modules. You define a class and export an instance of it and… voilà, or you can event just export an object literal. You perfectly “can” develop pretty big React interfaces just with this.

But in the real world, motivated by Facebook intents, the React “Community” started to consider that this is not enough and wanted more. They added the Flux pattern and now, (almost) everyone agrees on using Redux. But Redux is not at the same level as Angular services, it’s a new paradigm, and I’ve seen many Angular apps which could/would/have benefit of using this new paradigm too.

My point is: an Angular app can have an architecture fully based on dependency injection singletons. In the same way, a React app can also be managed by JavaScript module singletons exclusively. Flux and Redux are cutting edge patterns which are interesting for any app, whatever the framework it uses.

Zone.js is the revolution of change detection

I’m not a true expert of how Zone.js works, but its main feature is to monkey-patch (replacing built-in functions) of all browser events to let a framework, in this case Angular 2, know if it happens anything that requires a new rendering.

To trigger a rendering, in Angular 1, you have to call $scope.$apply(), generally, the framework does this for you and you don’t have to do it yourself but basically it was the mechanism. In Angular 2, with Zone.js, you don’t have to worry at all: Zone watches if something append without any explicit call. What about React? React API makes things a lot easier by making you change props or call setState, so basically, it’s completely explicit. React re-render nothing if you don’t say to.

So my point is that you can like or dislike Zone.js. But you have to understand that is not where change detection magic is happening. It’s a convenience for triggering change detection but nothing else.

Finally, back to Redux (or NgRxStore), if you use a solution like this, no matter the framework you use, Redux will be aware of any change happening in your application state and will be able to trigger a rendering. In this context, there is no need setState, $apply … and Zone.js as well.

So… Are there any difference?

Yes, of course, there are. Just not these ones! The one I value the most these days is the global design and API. The API is the thing you’ll deal with the most of your time, you’d better like it. I was about to sum up both React and Angular with 2 or 3 main ideas but I realized it was way too risky. Take a look at the key features of each frameworks and choose the one which fits the best for you.

Testing an AngularJS app with Jest

Matthieu Lux — Fri, 21 Oct 2016 15:16:26 +0000

I will not try to write the ultimate guide to test an AngularJS app with Jest, this article is only my feedback after trying Jest on my project.

TL;DR It works pretty well :)

First, let me add some context. I was a huge AngularJS fan and slowly drifted to React. That’s probably why I was aware of Jest and wanted to try it. Still, my biggest ongoing project uses AngularJS, it’s the member part of the new data exchange plateforme: Dawex (https://www.dawex.com/)

Also, I’m one of the developers of the Yeoman Fountain generator (fountainjs.io) and as such, pretty familiar with the use and configuration of new Web tooling.

The app is, I think, a pretty modern AngularJS app. It’s fully component oriented with AngularJS 1.5.x and uses NPM, Webpack and Babel for tooling. We even added some new stuff like RxJS and Redux.

The test environment is based on Karma and Jasmine. We use the karma-webpack plugin and tests are running in Chrome since we encountered some problems with PhantomJS.

Tests work with watching mode and coverage but there are some pain points remaining. The test bootstrap is very slow as Webpack has to build the whole bundle. Then, it starts a real Chrome (which need the xvfb trick on CI) and we didn’t find a way to have proper source-mapping (through Babel / Webpack / Karma) for proper error stacktraces. Finally but perhaps the most important, the global runtimes seems to be slow (real figures comes next).

Here’s an extract of the Karma config.

Trying Jest

In this context, I read about jsdom and thought that it could be huge to remove the real browser part since pure JavaScript implementations differences are not an every day problem anymore. jsdom is a Node library which is able to simulate the context of a Browser with its API in a pure Node execution.

I was considering trying AVA with jsdom but also looked at the testing framework used by the React team at Facebook: Jest. I was bothered at first because it looked as a nice integration of jsdom for frontend tests but I couldn’t find a blog post about using it outside the React world. As I noticed that there was no reference of React on the Jest front page, I concluded that the solution means to be framework agnostic. So, I decided to give it a try.

The PoC process was incredibly simple. I was sure I would have to deal with some AngularJS dependency injection edge cases or with the Jest mocking system. For a reason or another, I was quite sure I would have to refactor, even for a simple thing, every single test.

In reality, I only had to point my source folder and write a tiny script which imported my tests common lib and my tests were passing.

The biggest part of this script was to mock localStorage API as it’s not yet supported in jsdom.

Figures and facts

Even if I am pretty convinced by full plugin architectures like the Karma one, the drawback on the Karma configuration is obvious: 35 lines of code, not trivial for the Karma configuration against 4 lines in package.json for Jest. (I’m not counting the jest init script as Karma / Webpack needed one too).

According to coverage reports, the project counts 5917 JavaScript lines and 43.91% (2598) is covered (56000 actual source LoC). It could be better, for sure, but at least, it’s a real world example. There is also 103 tests suites and 363 tests.

Let us speak about execution times. For the execution of all tests once without coverage, Karma takes 47s in total. The bootstrap / bundling part is the most important as Chrome only takes 10s to execute tests once everything is ready. Jest, after a bit of learning (5 executions) only takes a total of 18s.

Yep! 47s for Karma against 18s for Jest! Same code, same tests.

With coverage, the bootstrap time of Karma is less problematic. Karma takes 100s against 80s for Jest.

The watch mode is harder to compare. Karma / Webpack has a strange delay on the change detection and triggers a new execution which is not measured. I manually counted 7s followed by a full pass at 10s. Using Jasmine fdescribe or fit, the run can fall at 1s. Jest works very differently, it only runs the modified test and takes approximatively 1s to detect the change and another one to execute it.

A final but important point is that with the stack Karma / Webpack / Babel we have never figured out a good solution to have a robust source-mapping in JavaScript stack traces. To be honest, sometimes, we had references, other times not. Jest is far more straightforward, The error reports are just perfect with only references to our Babel source code et good line numbers.

Conclusion

Jest popularity is shamefully restricted to the React world and really deserves to cross that frontier since it’s a very good agnostic solution for frontend testing.

I didn’t find any reference of Jest outside React before writing this article, I hope this will be the first.

I think, but some could disagree, that modern frontend unit testing doesn’t really need anymore real browser testing as most Web API are quite stable nowadays.

Configuration, performances and features are really good in Jest and the “Developer eXperience” is better than with Karma. And yet, I only used it as a test environment and didn’t played with the mocking features!

The only problem I see is that jsdom is not working right now with Zone.js and then not working with Angular 2. I really hope that it shall be fixed even if I don’t see motivation on any side (jsdom or Angular).