Estimate your project





Message sent

Thank you!

Your message has been sent. We’ll get back to you in 24 hours.

Back to page
24 hours

We’ll get back to you in 24 hours

to address your needs as quick as possible.

Estimation

We’ll prepare an estimation of the project

describing the team compostition, timeline and costs.

Code Review

We’ll perform a free code review

if you already have an existing system or a part of it.

Our work was featured in:

Tech Crunch
Forbes
Business Insider

Revolution incoming: CSS Houdini and the future of frontend development

The frontend development differs from other programming environments. It’s more limited, more pre-prepared. But things are going to change. There is a revolution around the corner that will determine the future of frontend, which makes me very excited. It will bring faster user interfaces, richer visual effects and brand-new possibilities. Additionally, the distant future of frontend may even erase browsers compatibility problems!

The problem

When creating effects on the website you often hit the wall of limited HTML and CSS possibilities. That’s why you use already existing JavaScript libraries to make up for the missing functionalities. But are you aware of all the consequences? Often, those libraries have hidden drawbacks that may harm your application. Animations on scroll, custom layouts, and many types of polyfills – all of them have pretty common problems:

  • A lot of data is not available for the frontend developers, e.g. displayed text width or values of unknown CSS properties. To collect that information, you need to use slow and dirty workarounds.
  • Some logic, instead of working under the hood of the browser, is running on the application level. It hits the overall website performance because it misses browsers’ optimizations done for the native code.
  • JS scripts often trigger extra view re-renders when you compare it to native functionalities. It forces the device to perform much more work and, as a result,  drains the batteries faster.

The latter is probably the most interesting, as it relates to how some types of polyfills work. That’s why we will take a closer look. Those are the small libraries that try to add missing functionalities to web browsers before they are ready to use there.

 

css houdini flow


In the scheme above you can see a typical view rendering process from web browsers like Chrome or Firefox. It consists of many stages that run one by one after something changes and every time the view needs to be updated. During that process browsers do a lot of magic – they parse code, calculate layouts, paint elements, and eventually, they put together the final view. It works well.

Now imagine you want a masonry layout on your website, just like Pinterest. Can you ask the browser to help you? Unfortunately, you cannot because browsers do not support those layouts yet. You need to do everything in your application using JS, totally outside the rendering process. This is how it will look like:

css houdini flow
This is how polyfills (and every other JS library) works. It does its job after the rendering process is over. Then it changes the HTML, updates the styles, and therefore, it forces the browser to start the whole rendering process again. The second run must happen to make the changes visible on screen, and that’s a big problem because every screen refreshing takes time. Currently, you can’t do anything about it because you don’t have access to the rendering process and the whole browser magic, but what if you could? As far as the future of frontend is concerned, here comes…

The revolution

Some time ago, a group of developers from well-known companies met and asked themselves: what if we could make a change here? They called themselves CSS Houdini Task Force, after an illusionist Harry Houdini, who was famous for demystifying magic.

The people behind CSS Houdini want something similar: to demystify browser magic and bring it closer to us – the frontend developers. They want to create a collection of low-level JavaScript APIs for better control of website rendering. Doesn’t it sound cool?

So think about creating advanced animations, layout compositions and image rendering. Everything in the blink of an eye. Without performance overhead. Deep under the hood of a web browser where the real magic happens.

I’m sure I’ve already caught your attention. Those new APIs will give you access to the rendering process. You will be able to read information that is currently inaccessible, and extend those rendering phases with your custom code, add new functionalities to the browsers or fix the existing ones. In order to do that, you attach small programmes to the browser. They are called…

The Worklets

These are not workers you may know from push notifications. Worklets are small ES6 classes that you register in JS files, attached separately to the document. Each class needs to implement one of the new CSS Houdini interfaces. However, you will not use these classes in your application directly. The browser will take responsibility for that and it will instantiate objects from those classes when needed.

What’s interesting, from worklets methods you will have no access to the outside world – that means no window, no document objects, no application data, no high-level functions like an alert. Every worklet will run in a separate context under the hood of a browser, without access to any of the listed information. The CSS Houdini designed them this way to make sure worklets behave like a native functionality. Fast and without footprint on the interface responsiveness.

The speed is very import because of another reason: Worklets run during the rendering process and some things, like animations, make them execute very often. Sometimes even 60 times per second. Because of that we, as frontend developers, must think about making the logic inside worklets noticeably light. It shouldn’t take too much time to execute your worklet because any time-heavy calculations will slow frames rendering. As you know for sure: with great power comes great responsibility.

But enough theory for now, let’s do some coding!

Paint API

This is first of the new CSS Houdini interfaces I want to talk about. It’s not only the easiest to understand but it’s also one of the most effective. Paint API will allow you to generate some extra graphics during the paint stage of rendering process and use them in CSS definitions. We can use those rendered images in every CSS property that accepts images as one of their values, e.g. backgrounds and borders settings.

So here comes the first worklet ES6 class. In Paint API we call them Painters. They must have a method named paint which takes three arguments. See the example below:

Context, the first argument, is a canvas-like object on which you will draw your image. Geometry informs you about how much space there is to draw on it. Parameters are an object with extra data you can pass to the worklet.

At the end of this code snippet, you can see we used a special function to register our class as a painter. In the same function, we give our painter a short name which we will use later.

Do you remember when I said that you must define the worklet code in a separate file? Now let’s learn how you can attach them to the document. As you can see below it’s extremely easy.

When you have done that, you can use the new worklet in CSS to finally do some work. For example, let’s make the background of menu more WOW:

As you see, to use this painter in CSS, you must choose a paint function and give it a name under which you have registered your worklet.

Looking for some real-life examples? There you go! Check this demo on CodeSandbox that makes a checkered background for a textarea. However, there’s a catch: only fully visible fields are allowed. The browser needs to adjust the size of every pattern field, depending on the size of textarea, to avoid rectangles cut in half. This is an effect impossible to achieve with plain CSS, but quite easy to make using Paint API.

Open the example below and try to resize the textarea by dragging the right bottom corner of it (on desktops). Please remember that this example will only work on the latest versions of Google Chrome and Firefox.



The textarea example was working on its own but what about more cooperativeness between a worklet and application? It is also possible. You only need to use CSS variables and pass them as parameters to your painter.



As you probably noticed, you have to explicitly define inside the inputProperties method which CSS variables will be available to your worklet. It’s required because of safety and performance.

The other thing – in the code snippet above we set the CSS variable in an external stylesheet. However, you can also do it dynamically by setting the style property of any element.


We will use this trick in the next example: a password input which calms down if your password becomes strong enough. Check it by yourself.



In a separate file, you measure how strong the user-defined password is and you set the value as a CSS variable. After every key pressed, a browser must re-render the whole input so it calls your worklet to get a new background image. Out worklet gets the current level of password strength and draws the background accordingly – that’s all!

So that’s Paint API. However, you may wonder if you can do some animations with it. We will cover this topic later. For now, let’s talk about a different type of animation.


Animation API

So, here’s a thing: currently browsers give us some tools to make native animations in CSS, like the transition property. The problem is that all those animations are time-based. When the time passes, the animation progresses. We call the source of animation progress a timeline. Nowadays, we often work with animations based on other timelines than time-based. For example, Twitter animates the position and size of a profile photo when the user scrolls their website. This is an animation with progress based on a scroll. Other types of timelines are also possible. We can image an animation of progress bar based on the percentage of file upload.

Unfortunately, we can’t make nice, smooth, native animations like that using only the built-in CSS tools. Luckily for us here’s where CSS Houdini group comes to rescue with Animation API that will work during the composition stage of the rendering process. Below I will show how you can use it.

We will start creating your animation by defining the source of progress: your timeline. In this example, we will use ScrollTimeline – an available out of the box timeline which progress when users scroll some element.

In the constructor, you need to pass the object with two properties. First one is a reference to an element which scroll position you want to follow. The second parameter is the maximum value of this timeline which will be set if the scrollbar reaches its end.

That’s the source of progress. Now let’s define how the animation will work. This definition we use to call an effect.

To define an effect, you need to get a reference to the animated element, keyframes of your animation and information how long should the animation be. In the example above, you are animating an image by making it smaller to one of fourth. The animation will take 100 seconds (yes, we still count animation progress in seconds).

You have the timeline, you also have the effect. Now let’s make the last part: something which will set the effect progress based on the timeline changes. This is the animator, the worklet which will work under the hood of the browser.


So here we have a quite simple animator. It takes the time from the timeline and sets it to the effect after multiplication by some factor. However, you can make it a bit more complicated e.g. with easing functions.

As you now have all the required parts, you can finally make your animation! Combine the timeline, effect and animator in one native, browser-friendly, stuttering-less animation. Also, provide a required object with parameters. The browser will pass it to the animator constructor.


As you can see, you can make use of the animator right there with methods like play, pause or stop. I didn’t show how I attached the worklet to the document, but you can check it on your own in the real-life example below.



This is a fully-working reading progress bar which makes use of Animation API. In this case, we used the animator parameters and the worklet became a bit more interesting than before. Check the comment inside it for explanations.

Remember, that if this example doesn’t work for you, use the latest Chrome version and go to chrome://flags/ to enable Experimental Web Platform features. After re-launching the browser everything should be fine.

So, we’ve already discussed Paint API and Animation API. Worklets, however, aren’t the only innovation that CSS Houdini tries to bring to the table. There is a whole new interface connected with how browsers are interpreting CSS. It’s called Properties and Values API.


Properties and Values API

The classic CSS programming interface called the CSS Object Model… sucks. See for yourself, if you don’t believe me. Let’s start with setting the opacity of some elements by half. We will use the document body in this example.


Now let’s get that value back.


What do we get? A string “0.5”, even though we had set a floating-point number earlier. This happens because the old CSSOM, the style property in elements, is a black box which automatically casts every set value to a string. You can try this yourself. If you’re in Desktop Chrome, just type CMD/CTRL+ALT+I (like India) and put those two lines in the Console.

It gets even weirder when you try to increase the opacity by 0.3 with the += operator.


Oh well, that’s JavaScript for you. Fortunately, the CSS Houdini group is trying to stop this madness. They’re creating the Properties and Values API. It’s a bigger thing, an interface for changing how browser understands your CSS rules and how you can work with them.

Part of the Properties and Values API is a successor for CSSOM: the totally new CSS Typed Object Model (CSSTOM). It fixes a lot of problems like the one I showed you before. CSSTOM will be available in the attributeStyleMap property of any HTML element and it will deliver more intuitive setter and getter:


This command sets the elements top margin to 5 pixels. What will you get after using the getter for the same CSS property? Surprisingly not a number nor a string. An object of CSSUnitValue class which will have two properties: the numeric value and the unit.


The pros of setter in CSSTOM is that it tries to parse every passed value to the appropriate object. For complex values (like translations) CSSTOM offers some special value objects too.

If you want, you may pass a value object to the setter. CSSTOM gives you ready to use constructors for distinct types of values like seconds, pixels, and degrees.


Look at this line. Did you notice something? We are setting the width of the element to 5 seconds! It doesn’t make any sense, does it? Fortunately, this is CSSTOM and T for Typed is there for a reason. Every type of unit is like a different type of variable and the CSS properties can now recognize what types are good or bad. Because of that, the last command will end up in an error.


Browser will validate the values of known CSS properties against type correctness. But what with custom CSS variables like ––effect-color used in this article earlier? CSS Properties and Values API have already given us some tools to manage this. You can define the type for every custom variable like this:


You may ask, why do you need this, and that’s a good question. It’s connected with animations. If the browser recognizes the type of given property or variable, it can animate the change of it. It knows how to iterate over it. The value of opacity is a plain number, so the browser just increments or decrements it. For sizes, browser iterates over the number and concatenates it with the unit like px or em. Colours are trickier because the browser must iterate every component of it separately, e.g. R, G and B.

Now when you know how to make custom variables animated, you can combine it with Paint API and create very cool background animations. Check this demonstration below.



In this example, inside CSS file you set the variable ––rainbow-progress to 0 for a normal button and 100 for a hovered one. You also set the transition time for this variable and define it to be a number. The browser knows now how to transition it between two states which manifests itself as an explosion of colours after moving the mouse on the button.

That’s CSS Properties and Values API in short. We only scratched the surface of the topic because this augmentation is much wider, e.g. CSS TOM will have many tools to improve mathematical operations on CSS values.


Other things

We discussed some of the new tools that CSS Houdini project wants to bring to the frontend development world. However, there is still much more work in progress or in early development. Now let’s quickly go through them.

Remember when we talked about the masonry layout? We said it is impossible to create this layout natively in browsers nowadays.

That is the reason CSS Houdini is working on a possibility to extend the layout stage of the rendering process by creating the… Layout API. Thanks to it, we will be able to arbitrary position elements on the website in a more browser-friendly fashion without using CSS position property. The browser will pass a list of elements and information about the container to our worklet.

Our job will be to calculate their position. You can also decide to not render some of the elements. You may even implement your version of the flexbox or grid layout. To make it happen – except the worklet – you will only need one line in CSS:



CSS Houdini also wants to deal with one of the most magical things in the frontend development: text rendering. This is a black box that you can’t control in any way. You can set some CSS properties connected to it, but there is no programmatic way to “see” how out text is visible on the website. This is where the Font Metrics API will come in handy. It will not only give us access to some interesting font metrics (e.g. baseline position) but also will allow checking how browser rendered the text, which font the browser used and how it wrapped long lines. Unfortunately, this API is still on the early stage of development with nothing to demonstrate yet.

The same goes for Scroll API. Do you sometimes dream about having more control over how scrolls work? To control how much the website scrolls after one swipe on a mobile device? It will be possible when this API will be ready. You may then forget about libraries implementing custom scrolling, as you will be able to set up everything in a few lines of CSS.

The last thing worth noting is the Parser API which will allow you to extend the browser parsing mechanisms. Custom CSS properties and custom units – they will allow us to create better CSS polyfills that don’t need to parse stylesheets by its own.

The list is still not complete. The CSS Houdini project is huge and requires a lot of effort. There are few other interfaces drafts that will allow extending browser capabilities even more. Most of those things, however, are only part of the future of frontend.

 

The bright future of frontend?

In this article, I’ve presented a lot of cool features. Can you use them in your applications now? The short answer is… no. Check this table from ishoudinireadyyet.com.

is houdini ready yet
Open source enthusiasts slowly implement all the features into Google Chrome. Firefox also will be implementing them later on. Microsoft Edge column is red but it’s basically a dead browser now, so nobody is surprised.

Will browsers adopt CSS Houdini widely? Nobody knows. But if they do, it will change the frontend development image forever. It will be the biggest change since HTML 5 and CSS 3. It may even change the way we build websites on HTML templates. Do you want a fancy layout? Good, there is a worklet for that! Just download it and add one line to CSS. Having to add too many worklet files to the application? No problem, in a few years there might be some Webpack plugins to help you with that. Who knows?

I hope it won’t be just another cool feature in Chrome and Firefox that people will soon forget but rather a positive impulse for the future of frontend. Keep your fingers crossed!

Code splitting with React & Webpack: advanced app optimisation

When the code base grows, your app tends to slow down. To defend performance, developers arm themselves with various optimisation techniques. Unfortunately, a lot of them reach their limit pretty quickly. But there is one that can let you go beyond conventional restrictions. Let’s get the gist of code splitting with React & Webpack.

Your single page application is growing. Every week, new features are being added and its size increases. You want to provide great user experience, but downloading a lot of megabytes of the application’s code just to display a single screen doesn’t seem right. Sure, you can enable code minification and compression, or caching mechanisms, but eventually you’ll end up having the same problem – a large amount of data required to download to initialise your application.

Code splitting with React, or any other JavaScript library of choice, is the answer to this exact problem. It’s a technique that makes the application ready to be split into multiple independent chunks loaded on-demand. As a result, you don’t have to bundle the application’s code into one or a couple of files. You can decide which modules should be separated and quickly load them when they’re necessary.

react logo
You can use code splitting with React or any other JavaScript library you like

When is it worth it to use code splitting? In particular:

  • in large JavaScript applications,
  • when you need to initialise the app quickly, without using too much processing power (e.g. for mobile devices),
  • or when the application has multiple permission groups or sections visible only to specific users.

As well as in many other cases.

The term “code splitting” may sound quite fancy and advanced. In fact, it’s pretty straightforward and it only takes a while to understand the basics and start implementing.

When should we use code splitting?

To understand when we should use code splitting, it’s helpful to introduce the term Time-to-Interactive (TTI). It’s a value that specifies the time required to load all assets essential for the website to initialise and become interactive for the user. Unfortunately, when it comes to SPAs, TTI is often too long for the user to patiently keep waiting. Various surveys by Akamai and Gomez.com conclude that almost half of all users expect the page to load in under 2 seconds. Extending it by another second compels the user to abandon it.

To provide excellent user experience, we should try to make TTI as low as possible. We’re going to achieve that with code splitting.

In theory, you can use it in any JavaScript-based application. However, think of it mostly as a code optimisation strategy. Therefore, you probably shouldn’t dive right into it, when the application is in the early stages of development.

Analyse first which modules are necessary at all times and which you can load asynchronously when a user enters specific routes. It will help you understand the performance aspect of your application and optimise it to a greater extent.

Does anyone actually use code splitting?

Many companies use code splitting to make their products load faster. Let’s analyse a couple of the most popular websites:

Instagram

instagram logo
Biggest social media brands search for all kinds of ways to speed up their apps

The entire Instagram production codebase has the size of a little over 2 megabytes. Thanks to code splitting, when a user enters the homepage, only a quarter of that, necessary for the homepage to display, is loaded for a logged-in user.

Code splitting implementation details:

  • uses Webpack as a bundler,
  • code is split into 15 chunks:
    • 3 main chunks contain the code and external libraries for the entire application,
    • 1 translation chunk,
    • 11 code chunks load on-demand – for the homepage, profile, post, tags, location pages and more,
  • stylesheets and small images under a few kilobytes are bundled directly with chunks.

YouTube

Google itself uses code splitting to boost the speed of their most popular products

The popular YouTube desktop app is in fact a group of multiple connected applications. All the main views, meant for browsing and viewing videos, comprise the main app. Homepage, playlists, video page, comments, user profile, and others pieces have over 1.2MB in total, but to play videos you need as low as half of that. Other chunks are loading on-demand.

For most of views, YouTube uses Polymer. However, the upload view is using Angular 1.6.4. Its bundle contains the uploader logic. Angular itself has over half a megabyte in size.

Benefits of using code splitting

The most important code splitting benefits include:

  • Drastic reduction of the data which you need to download and parse in order to make the application interactive (achieving much better Time-to-Interactive).
  • Physical separation of different parts of the application and being able to decide when a browser should load them.
  • The ability to exclude administrative code for regular users to optimise file size and hide potentially sensitive data.
  • Client-side caching improvements achieved by updating only those parts of the application which have actually changed.

Of course, all technologies have their downsides and code splitting is no different:

  • It may sound obvious to you, but you should keep in mind that code splitting requires downloading some data after the page initialises. When the internet connection is down, there’s no way to load additional modules. Be ready for this and prepare an appropriate message for the user.
  • You also need to write additional logic to load multiple modules when they are required. However, thanks to Webpack, implementing it is as easy as using one function called import()!
  • Each bundle needs to have a header code that allows it to be injected into the application. For Webpack in the production mode, it’s only 80 bytes per file.
  • There is a slight delay caused by the need to load additional code chunks (but only during the first load).

If you’re ready to try code splitting in your project and you use Webpack or Browserify, all the code required to load modules asynchronously is already there – implemented and ready to use!

Code splitting with React – configuration and implementation

Please note that examples below are presenting code splitting with React as the library of choice and Webpack 4. If you are running an older version of Webpack, you’ll need to modify the configuration a little. For details, please look at the proper documentation. However, your choice of libraries and framework is not relevant here – code splitting will work all the same.

Code splitting is one of Webpack’s most notable features

Pre-requirement: separating vendors

Before splitting the actual code, we should start with excluding vendors (basically files from the node_modules directory) from the application bundle. Since the vendor code is not updated as frequently as the application code, it’s a good idea to prevent it from downloading every single time and keep it in the browser’s cache instead.

Webpack 4 doesn’t require any external plugins to make this happen. Edit your Webpack configuration file and add the optimisation key to it:

This section creates a cache group named vendors. It groups all modules that match the regex passed in the test key which, in reality, is matching all files in the node_modules directory.

When you compile this project, you get another file named vendors.js. You should add it to the index HTML file.

Importing modules

In this step, we use a fake router-8000  module, which creates routes inside your application. The typical method of creating routes would be:

Now, let’s make it run asynchronously, using dynamic imports and our code splitting functionality:

As you see, not much has changed. The getRouteComponent is asynchronous and uses async/await to wait for a Promise returned from import() to resolve. Take a look at the import call – besides the path to the component that contains our route and gets a proper exported module, it has a comment block inside. This comment block is a “magic comment” that Webpack utilises to decide to which chunk it should put the code that it imports. The value between quotes defines a name of the chunk. If you are curious, go to the Webpack docs to discover what the other magic comments are.

And that’s it! You’ve successfully created an asynchronously loading route, which the code fetches on demand.

You can check it out live or clone and try it yourself here.

Chunk preloading

We already know how to load chunk asynchronously by calling the import() function and utilising the Promise it returns. What should we do to prefetch the data before it’s needed, without having to display any loading screen and making the application freeze for that time?

It’s much easier than you might have thought! The first thing that import() does is check if the requested module is not already loaded or in the process of being so. If this is the case, Webpack uses the data from its cache to resolve the import without wasting time to fetch it again. Therefore, the easiest way to preload any module from its chunk is to call the same import() as in our routes configuration. In this case, we don’t need to do anything with the returned Promise.

Keep in mind that chunk names have to be the same in all the places where you want to use an asynchronously imported module. To make it DRY (in accordance with the Don’t Repeat Yourself principle), consider creating a factory module that calls import().

Advanced Webpack configuration and further reading

If you are curious about how Webpack handles its implementation of dynamic imports to offer code splitting functionalities, or you want to try other configuration options, see Webpack docs.

If you want to know what other features the Webpack 4 optimisation plugin has, take a look at the docs where everything is well-documented.

I hope you’ve learned by now how code splitting with React (or any other library you like for that matter) works, what its benefits and downsides are, and how to use it yourself. If you have any questions, feel free to ask them in the comment section below.