Forem: Tomas Rezac

[Boost]

Tomas Rezac — Tue, 08 Jul 2025 09:36:25 +0000

Tomas Rezac

Jul 8 '25

CSS Counting Magic: Converting Counter Values to Variables

#showdev #css #javascript #discuss

Comments

5 min read

CSS Counting Magic: Converting Counter Values to Variables

Tomas Rezac — Tue, 08 Jul 2025 08:54:58 +0000

Have you ever needed to count elements or sum variables across elements and then use the result as a CSS variable? No JavaScript involved. I'll show you how it can be done.

The solution is kind of insane, but beautiful. It took tens of hours of thinking, trying, and failing—again and again—until it was finally accomplished.

Why would one even bother? It opens up fascinating possibilities:

Changing layout based on content without needing media or container queries
Dynamically adjusting cells in grid/flex based on their position in the container
Determining whether a grid cell is in the first row or not

The Challenge

From the beginning, it was clear that a full-featured solution must be implemented using CSS counter(). You can count elements with the :nth-child selector or with the brand new sibling-index() function. However, both solutions only tell you the index within the parent element, not a sum of values. They cannot propagate the number to their parent element.

CSS counter(), on the other hand, can count elements or even sum variables. For example, you can define a counter in the body element and then use counter-increment: var(--any-number); on any child. Then display the sum in body::after. The issue is that it can ONLY be shown in ::after or ::before pseudo-elements, nowhere else.

The challenge is: How do you turn the text content of an ::after pseudo-element into a variable?

Solution: Converting Counter Values into Variables

There's a neat, hacky solution to get an element's width in CSS as a CSS variable. We'll explore this technique shortly. First, to leverage this approach, we need to turn the text content value of an ::after element into its width.

To better understand this concept, let's say we need to set the width of <div>17</div> to 17px. After spending ages figuring this out, I discovered it can be done with a custom font and a @counter-style. Let's examine the latter first:

@counter-style countStyle {
  system: additive;
  additive-symbols: 10000 'N', 1000 'M', 100 'C', 10 "X", 1 "I";
}

The above defines a counter style that describes how to convert a number to its visual representation on screen. For example, myCounter with value 2344 in this code:

.counter::after {
  content: counter(myCounter, countStyle);
}

will be converted to MMCCCXXXXIIII. The system works by starting with the highest number in additive-symbols and checking how many times it fits into 2344. N fits 0 times, M fits 2 times (resulting in MM), then those 2000 are subtracted from the initial number, leaving us with 344. This remainder is then tested with 100 'C' and so on, until the last additive-symbol.

Next, we apply a custom font to MMCCCXXXXIIII. We define the font only for characters N, M, C, X, and I. I is set to a 1px wide space, X is set to a 10px wide space, and so on. The font itself is created via Glyphr Studio with a maximum character width set to 10,000 points. Because of this, we need to set the font-size to an astounding ~~10000px~~(there is a new limit in chrome not allowing that big font. We need to stick with 1000px and then multiply the result by 10, or simply make the font 1,000 points). Character I will be displayed as 1px wide while N appears as 1000px wide.

This is the key insight: we now have width derived from text content. An element with MMCCCXXXXIIII will be exactly 2344px wide.

Converting Element Width to CSS Variable

Let's return to how to turn element width into a CSS variable. You can read the full article by Temani Afif on this topic: How to Get the Width/Height of Any Element in Only CSS.

The technique requires view-timeline animation and essentially states that if you know 3 of these 4 dimensions, you can calculate the 4th:

Dimension of the scroller
Dimension of the subject
Progress of the animation
Offset of the subject

We define a ::before element with width 1px (subject dimension) and align it to the very left. The animation progress and offset within the container is 0. This means we can calculate the dimensions of the scroller.

Once we know the scroller width, we can use the ::after element (the one from above with counter value represented by custom font). This time we already know the scroller width, and again the animation progress and offset is 0. We can obtain the width of the subject (counter) as a CSS variable. Because we use the timeline-scope property, the variable is available on the scroller (parent element).

Example

Please see the code below for the complete solution. Works in Chrome only now!

Limitations

There are several limitations introduced by this implementation:

Browser Support: Currently only works in Chrome and Safari Technology Preview (no Firefox support)
Layout Constraints: Uses overflow: auto on the count container. You cannot absolutely position elements outside of it unless using layer APIs like popover
Size Limitations: Requires defining a child in the container with width equal to the count. If the count exceeds the container width, counting stops working. This can be partially addressed by decreasing font size 10 time, so counter value 1 translates to 0.1px, but this may result in incorrect rounding in some cases

Practical Application: Detecting First Row in Grid

If you need to determine whether a cell is in the first row of a grid, you can sum all the children's spans (since one child can occupy more than one column). Sum these spans using the technique mentioned above to get --total-span-count-in-grid. Then use clamp() with the maximum number of columns available in the grid:

--is-first-row: clamp(
  0, calc(var(--max-columns) - var(--total-span-count-in-grid)), 1
);

If elements span only across the first row, --is-first-row equals 1; otherwise, it equals 0. Any CSS calculation can then be multiplied by this value to get either 0 or the desired calculation if we're in the first row.

Conclusion

This technique opens up new possibilities for CSS-only solutions to complex layout problems. While it has limitations and browser support constraints, it demonstrates the creative potential of combining CSS counters, custom fonts, and view-timeline animations to achieve what was previously thought impossible without JavaScript.

Why Sugar.css grid is so revolutionary?

Tomas Rezac — Thu, 07 Mar 2024 13:52:09 +0000

In this article, I want to introduce you to a novel CSS grid concept that differs significantly from what we're accustomed to. You can witness it in action within the Sugar.css documentation and delve into its code within the Sugar repository.

The Traditional Approach of Bootstrap-like Grids

For ages, we've relied on grids from libraries such as Bootstrap or Tailwind. Despite transitions from percentages to flex and later to grid, little has changed over the years. Both Bootstrap and Tailwind, along with many others, adhere to the same core principles:

A predetermined number of columns in a container (usually 12).
Generation of an extensive array of classes applied to cells to determine their column occupancy or offset.
Adapting the grid layout based on window width through the application of different sets of classes, ensuring responsiveness across various devices.

However, this approach comes with several drawbacks:

A fixed number of columns necessitates the use of media queries. The presence of media queries is particularly problematic for component-based front-end frameworks. Components should be agnostic to whether they occupy the full screen width or a mere 200 pixels. Yet, the width of the component is pivotal for effectively setting up cell classes in a responsive manner. This issue could potentially be addressed by transitioning from media queries to container queries.
To ensure optimal responsiveness, one must define a cell class for every breakpoint, such as col-sm-12 col-md-6 col-lg-4 col-xl-3. It results in lot of HTML markup, which is hard to read.
The generation of a vast number of classes to cover all scenarios. While this can be partially mitigated by CSS cleansing (the automated removal of unused classes), it is not ideal for larger projects where most classes are already in use.

The New Concept Introduced in the Sugar Grid

The core principles of the Sugar grid diverge significantly:

The container has no preset column count.
Users specify the optimal width of a column, and once a new column fits within the container, it is automatically added.
Instead of classes, CSS variables like --span:2 are utilised to span cells across multiple columns, eliminating the need for class generation.
Another CSS variable can adjust the span count of a cell based on different container sizes, such as --span-6:3. This means that if at least 6 columns fit within a container, the cell should span across 3 columns instead of the default --span value.

This approach seemingly resolves all the drawbacks associated with traditional grids.

We can also observe that this appears to be an intrinsic design, a design pattern that seems to be the holy grail after traditional responsive design. The distinction between intrinsic and responsive designs lies in the fact that the former does not rely on media queries and is instead driven by content.

While I would like to categorise the Sugar grid as intrinsic, it would only be partially accurate. It utilises container queries under the hood, although they are not essential for core functionality. Presently, their necessity arises due to a peculiar behavior of spans in the grid. For instance, if a grid has two columns but one of its cells spans three, the grid becomes disrupted, causing content overflow. Ideally, it should automatically adjust to a span of two, but this functionality is currently lacking. Perhaps this issue will be resolved in future iterations of CSS.

Advantages of the Sugar Grid

The results are staggering: a significant reduction in CSS. Sugar's grid comprises approximately 150 lines of code, compared to Bootstrap's 1500 lines. It's about 10 times smaller.
It also eliminates the need for an excessive number of classes applied to cells in HTML. In scenarios like cards in a grid container, you simply apply style="--span:2" to the container itself, and you're done. The span definition is passed from the container to the cells. If needed, you can still overwrite it on a cell level.
For more complex situations, syntax like --span:2; --span-6:3; span-12:6 can be used, although such cases are rare and mostly pertain to specifying page or large component layouts.

Disadvantages of the Sugar Grid

It is different! It requires new way of thinking. It employs modern CSS features like container queries, and careful consideration is necessary regarding its usage. Since there are no breakpoints, aligning with traditional designers who insist on pixel-perfect designs with specific breakpoints might pose a challenge. It requires a shift in their mindset.
It introduces an unnecessary div wrapper between the container definition and cells, primarily as a workaround for a Safari bug. Once resolved, this wrapper will be eliminated.

Conclusion

Is the Sugar grid revolutionary? I believe it is, albeit it requires some time for widespread adoption. The Sugar grid is rooted in the concept of intrinsic design, even if it's not a pure implementation.
Sugar offers additional features like offsets and specialised grid behaviours for layouts. However, the focus of this article is to highlight a new direction in which CSS grid "frameworks" can evolve.
Perhaps in the future, grids like Sugar will be further simplified. Currently, the main hindrances to such simplification are various bugs related to container queries (subgrids, Safari repeat column template).

If you haven't already, you should definitely give it a try!

Creating Modern Accordion Components with CSS and HTML only

Tomas Rezac — Wed, 21 Feb 2024 09:32:11 +0000

Welcome to the first instalment of a series dedicated to crafting common components using only modern CSS and HTML.

Note: I am the author of Sugar.css, a minimalistic CSS Framework built with the latest CSS. You can explore a more advanced implementation of a similar accordion on Sugar.css.

Assignment

What are the essential features of a proper Accordion?

Toggle content on user input or programmatically
Accessibility (toggle on Enter and Space)
Disable access to accordion content (by keyboard) when the accordion is collapsed
Stacking multiple accordions after each other
Auto close other accordions in the group when one is opened

Toggling Content

Gone are the days when the only way to toggle styles permanently was through a label with a hidden checkbox. For the past few years, we've been able to use a combination of details and summary HTML elements to achieve this. The details element hides all its content by default, except for a summary element if placed as a direct child. The summary serves as a toggle button; if not present, the text details is added as a default toggle. By clicking the toggle, the rest of the hidden content is revealed. Let's observe the default behavior and design:

Accessibility

All accessibility features are built-in; the summary has a default tabindex and can be toggled by Space and Enter keys, so no additional work is needed here.

Disabling Access to Content When Collapsed

While this functionality should work out of the box, there's an exception with Safari. If the details element is collapsed and contains focusable elements like input or button, tabbing in Safari will be consumed by those hidden elements. To ensure consistent accessibility across browsers, a simple JavaScript solution is required. The content is wrapped, and the inert attribute needs to be set to the wrapper once the details is collapsed.

Styling

Let's apply some CSS to enhance the appearance. First, we'll remove the original triangle indicator. This can be done differently in various browsers, but the following CSS accomplishes this:

summary::marker,
summary::-webkit-details-marker {
  display: none;
}

summary {
  list-style:none;
}

Next, we'll style the summary to resemble an accordion header and prepare it for a new chevron:

summary {
  list-style: none;
  display: flex;
  gap: 1rem;
  align-items: center;
  justify-content: space-between;
  cursor: pointer;
  padding-block: var(--padding);
  font-weight:bold;
}

details {
  --padding: 0.75rem;
  --border-width: 0.1rem;
  --chevron-size: 0.8rem;

  font-family: system-ui;
  font-size: 1rem;
}

To implement the new chevron for the base accordion, we'll create a rotated box with just two borders. The state of the opened accordion is selected by details[open]:

details summary:after {
  content: '';
  margin-inline-end: var(--padding);
  width: var(--chevron-size);
  height: var(--chevron-size);
  border: solid currentColor;
  border-width: 0 0 var(--border-width) var(--border-width);
  transform: rotate(-45deg) translateY(-30%);
  transition: transform 0.3s;
  flex-shrink: 0;
}

details[open] summary:after {
  transform: rotate(45deg);
}

Lastly, we'll add separators between accordions if there are more consecutive ones:

details:not(:last-of-type) {
  margin-bottom: var(--padding);
  padding-bottom: var(--padding);
  border-bottom: var(--border-width) solid gray;
}

Grouping Accordions

Another useful feature of details is its acceptance of a name attribute. All details with the same name behave as a group. When you open one, the others in the same group automatically close.

Check out the result

Additional styles like colours and spacings can make it more vivid

Conclusion

As demonstrated, details and summary are fully capable of replacing JavaScript-driven accordions. They make implementation easier and provide immediate accessibility (with the exception of Safari, which requires a workaround for a specific edge case).

However, there's one potential drawback: the lack of animation support. If animation is applied to collapsed content within details, it runs only once when opened and cannot be rerun when opened next time. This limitation may need to be considered based on the specific design and functionality requirements of your project.

Next time we will check the dialog element. See you soon.

Sugar.css is futuristic and minimalistic CSS framework

Tomas Rezac — Thu, 01 Feb 2024 22:15:39 +0000

Before diving in, take a look at Sugar.css to get a feel for what we're discussing. The entire documentation site leverages Sugar.css to give it a stylish appearance.

TLTR:
Sugar.css is an 8.4 kB CSS framework comprising only 7 CSS classes. The bulk of it revolves around enhancing the styling of native HTML components in an advanced manner.

Check out an example of Sugar.css design:

Why I Created Sugar CSS?

I grew weary of writing an excessive number of classes to style HTML for minimalistic and well-designed templates repeatedly.
I found existing CSS frameworks to be overly complicated and extensive, often leading to the creation of unattractive HTML.
I was dissatisfied with other minimalistic CSS frameworks, which made customisation a tedious and slow process.
I sought a small but robust grid system that seamlessly integrates with component-based JS frameworks but couldn't find any that met my criteria.

What is Sugar.css

A minimalistic CSS framework (only 8.4 kB) that styles native HTML elements with minimal use of classes—just seven classes for containers, grids, light/dark themes, and secondary buttons.
Fully-featured and responsive, including an advanced grid system, forms, tooltips, navigation, loaders, and more.
Built for customization, offering over 50 global custom properties to tailor your own Sugar.css build. It provides multipliers for spacings, roundness, and fatness to adjust sets of variables at once. Sugar.css also includes a built-in customization UI tool, including color accessibility checks.

Modular—create your build with just the features you need.
Designed with accessibility in mind, adding interactive elements like modals, tooltips, accordions, etc., without requiring JS or CSS hacks, all while supporting keyboard control.
Opinionated in styling certain elements (article, section). Customize your build's source code or easily overwrite styles, as Sugar.css applies styles with zero selectivity.

What it is not

It is not a CSS-in-JS framework. It cannot be used piece by piece directly in JS. It is based on HTML syntax for styling, not classes or direct styles.
Does not encompass the extensive features common in large UI frameworks. It does not aim to provide CSS solutions for components requiring heavy JS support, such as autocompletes, filtering elements, sortable data-tables, etc. However, you can still use preset custom properties in your own components and style them similarly to Sugar.css.
Not suitable for older browsers; optimised for the latest versions of Chrome, Firefox, Safari, and other Chromium browsers.

Why Use Sugar.css

Consider it a CSS reset that you can build upon with CSS in JS or any preferred method.
Fine-tuned with numerous features for its compact size. For example, the entire CSS framework, including the grid system, is the same size as a standalone Bootstrap grid.
Encourages the writing of semantic and accessible HTML—styles are applied only when all semantic requirements are met.
Brings consistency and simplicity to your design.

How to use it

How to Use Sugar.css
Numerous options are available, including installing the npm package, loading via CDN, or building via the command line. See all options.

Try and leave feedback, please

Sugar.css is currently in beta, and your input is invaluable. I encourage you to test it out and share your feedback either here or through the Github repo by creating an issue. Your insights will contribute to refining and enhancing the framework.

Thank you very much!

Palette generator you will ️

Tomas Rezac — Mon, 21 Feb 2022 08:47:45 +0000

You can check it straight away palette.rocks

Why I made yet another Palette generator

I have been using color generators for years. There are many great ones: Coolors, Adobe color, Color hunt, Paletton, Material color tool, Dopely, to name a few.

They have eased my color palette selection a lot. But maybe they could help me even more.

With such a tooling one would expect to generate the right palette within minutes. In reality, it is more like hours.

Maybe you know the feeling of generating super nice palette, transferring it to an accessibility checker and finding out it has too low contrast or it doesn't pass color blind test.
And once you generate a palette, which pass all the accessibility checks, it simply doesn't look well in your particular web project.

I have been thinking about how to make the color selection easier and how to save some time. How to try hundreds of palettes in my web projects in fraction of time I used to need? I decided I would create my own generator, which would be able to achieve that!

What a color palette generator should do

It needs to generate palettes easily.
It needs to give you all the accessibility feedback in real time.
It should show all the necessary data and feedback in one place (colors, their relations, accessibility report, preview, ...)
It should be easy to transfer generated palette to you project.

Most of the palette generators - mentioned in the introduction part - cover up to 2 of the above mentioned points. Mostly they don't provide any accessibility feedback. And if they do, they struggle with showing all the data at one place and in real time.

None of the palette generators make it very easy to transfer the generated palettes to your web. In better cases, they generate CSS variables for you. But you still need to copy paste them; reload your browser; remember how it looks like; generate new palette... and repeat the process until you are happy with result.

So I made my own palette generator, and tried to cover all the points.

The killer feature

Probably the most innovative palette.rocks feature is the possibility to connect it to your web and remote control its color theme in real time. Just spin the color wheel or generate random palette and see how it looks like in your web.

In order to connect your web to palette.rocks you need to fulfill following requirements:

1) Your web needs to use CSS variables for colors


:root {
  --your-color: #1ab291;
}

2) Add this script to your page, it will expose a global function mapPaletterRocks(mappingObject).

<script src="https://palette.rocks/script.js"></script>

3) Call the mapPaletterRocks(mappingObject) function with mapping object.
Keys of that object are colors in pallete.rocks.
Values are pairs of color variables used in your app.
To the first in pair, a color from palette.rocks is mapped. To the second in pair, the most contrast color (white or black) is mapped.

mapPaletterRocks({
    a:['--primary-color', '--primary-contrast'],
    b:['--secondary-color', '--secondary-contrast'],
    c:['--tertiary-color', '--tertiary-contrast'],
    d:['--quaternary-color', '--quaternary-contrast'],
    customColors:[['--custom-color-1', '--custom-color-1-contrast']]
});

4) Click the Connect YOUR WEB to live preview button in palette.rocks page. Paste your web's url into the input in top of the modal and submit.

Try it out

You can try it on my other project. Just go to palette.rocks, follow the point 4 from above and submit this url
https://fluid-grid.com/
Then click on the Desktop preview on the 'mobile phone' to see it in full size. And start changing colors ;)

More unique features:

And there are more advanced features in palette.rocks

1) Color Blender

Blender mixes all your primary colors and generates colors in between. You can then easily pick some of those as custom supplementary colors.

2) Reversed Backgrounds

This - not that well known color phenomenon - is based on something called color subtraction. I won't go for explanation, as it would require more than another article ;)
You better see it in two following examples:

As you can see, the inner squares are perceived as identical colors, until you compare them side by side.
In real world design, you would need such inner colors if you wanted to present just three colors in some kind of split color design. This tool helps to find 4 colors which are perceived as 3.
On the other hand, if you manually find a mid color between those two backgrounds and use it as the inner squares, you end up with 3 colors which will be perceived as 4 by your brain :)

Future of palette.rocks

There are definitely areas for more improvements: different color formats (LAB, CMYK) for manual inputs; locking custom colors (if you lock a custom color, it would change automatically, as you change your primary color); and there are probably more features, I don't think about now.
I'll be glad for your feedback. What are YOU missing in palette.rocks?

CSS grid system for future web - Fluid Grid

Tomas Rezac — Wed, 09 Feb 2022 23:17:35 +0000

You can directly try it at fluid-grid.com

But I encourage you to read on and get more info on why and how I created very different grid framework, than any other we currently have.

Two years ago I wrote an article about rethinking web design. It got several thousands of reads and it triggered broad discussion on that topic. Most of feedback was positive, but people complained about need of web components in order to enable this new responsive style.

Here I am two years later with reworked solution, which is pure CSS based. For now, it requires Container queries polyfill. Fortunately, there has been one, done by Surma (Google dev)

New enhanced grid framework

My first try was kind of prototype (more on that in mu above mentioned article). I used it on few projects and it worked well. But it was not ready for public use, as it required precise understanding of all predefined classes and ability to add custom ones, where needed.

This time, there is full featured documentation, examples, custom grid builder (wizard) and more to come.

Why new grid system?

I had two main reasons:

First of all, I have been working for past few years with various component framework and I found out, that current grid solutions based on @media queries simply don't fit to component driven web development. You cannot use media query driven grid inside component, because you don't know where the component will be used. Will the component be full screen wide or just 150px? You never know.

Second of all, I started to be pissed off declaring col-sm-6 col-md-4 col-lg-3 col-xl-2 just for sake of telling an element, it should always be around 250px wide. Once I'd found our there is a way to tell an element, it should stick to a grid and be always around 250px wide, by simply using col-1, there was no way back!

Fluid grid features

1. Container-query based

Component's grid depends on components size itself, not on window width

2. Automatic

Just define optimal grid cell size. Then tell how many cells your content requires. Rest is done automatically

3. Component ready

You can use gird containers inside components now and don't worry how big the component is in your page

4 .Declarative

Basic scenarios can be handled by minimal declarative rules .f-col-1. No more imperative description w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4

5 .CLI

You can create your own custom made fluid grid, with sizes fitting your needs. Just run npx fluid-grid and command line wizard will guide thru.

It is way better to see it in action to really understand how different it is compared to twitter bootstrap grid or a tailwind grid. Just go and check it fluid-grid.com if you haven't done already.

What's next

Fluid Grid is now in Beta, as there are several pending questions and the grid extent can change a bit.

It would be great to start discussion on, what can be changed, improved,... Why some approaches are now used over others etc.

For instance these are open topics for discussion:

Fluid grid greatly supports components' internal grids, tiles' grids and other smaller grids. However, usage for big layouts produces more code than desired. Should there be separate version for layouts only? Should a page layout support be omitted and outsourced to a developer. Or should there be some kind of breakpoints (I can think of 8, 13, 21 columns) like in the bootstrap grid system, when a grid is used for layouts?
Do we need more classes and more build in features, or should the grid stick to a bare minimum and try to be super lightweight?
Should the wizard let developer make even more customised builds, or should we rather stick to more uniform output?

There are, for sure, more questions and hopefully answers.
It would be great to discuss options and possibilities here or in the projet's github.

Looking for your feedback, ideas, pull requests and offers for collaboration ;)

Frontend checklist

Tomas Rezac — Fri, 13 Nov 2020 13:09:26 +0000

Few years ago I made a checklist for FE development and somehow forgot to let the world know about it. It is time to change it ;)

Let me introduce to you: Docket

There are already some FE checklists around here, but none of them worked well for me. They are mostly static and don't persist your choices over time. Also, you cannot share your progress with colleagues. So I made Docket, BTW its meaning, as in Cambridge Dictionary, is: "a list of all the things that someone has to deal with or discuss."

Docket's features

Provides templates with various checklists.
You can edit delete/add/modify all items in a checklist.
Every docket has its own unique URL, which can be shared with others.
You can register/log in to see all your dockets.
It is cooperation ready as it use sockets to emit changes. (more people can work on same docket at same time)
Items can contain description with links to articles, etc.

Templates

Docket contains following checklist templates:

HTML head
HTML
HTML for public Web
CSS
Javascript
Images
Webfonts
Code & Styleguide
Accessibility
Speed and performance
Web launch & SEO
Security

You can combine more templates in one docket ;)
You can also add your own checklist groups.

How can you help?

Try it. If you like it, you are encouraged to help me with improvements.
You can submit Pull Request to Docket repository on github with changes of templates, or you can come with your own template you would like to add to docket.

Happy coding!

Rethinking responsive Webdesign

Tomas Rezac — Tue, 09 Jun 2020 21:14:37 +0000

From idea to revolutionary web grid system ;)

How do we it do nowadays?

To be honest, most of us have never made a responsive web design, we all just make an adaptive webs (we only care about few specific screen sizes) and call it responsive!

Responsive means something more like the above. But can we achieve it?

After years of giving a UX lecture at university, showing this picture, and telling students, that this is a true responsive design, I realised, that we cannot. There is actually no grid framework (known to me) fulfilling this assignment.

As there is no ultimate solution for a responsive web design, most of us stick to something like Bootstrap grid system. Unfortunately, these kinds of grid systems are far from being responsive. And work badly with current FE tech stack.

From now on, I'll often mention Bootstrap grid system. By doing so, I'll refer to a group of grid systems (Bootstrap, Foundation, Tailwind CSS and similar), not solely to Bootstrap.

What's wrong with Bootstrap-like grids?

Best to start with an example. Just to illustrate that there are more grid systems similar to bootstrap, lets check a Tailwind's grid:

    <div class="flex flex-wrap">
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4 bg-gray-500"></div>
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4 bg-gray-400"></div>
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4 bg-gray-500"></div>
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4 bg-gray-400"></div>
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/2 xl:w-1/6 mb-4 bg-gray-500"></div>
      <div class="w-full sm:w-1/2 md:w-1/3 lg:w-1/2 xl:w-1/6 mb-4 bg-gray-400"></div>
    </div>

What can a developer complain about the code above?

It is a lot of code.
It is hard to read.
It is hard to reason about.

What a developer wants, is to get rid of this w-full sm:w-1/2 md:w-1/3 lg:w-1/4 xl:w-1/6 mb-4 bg-gray-400 in favor of something like this: col-2

What can a UX designer complain about the grid?

It doesn't support huge screens.
It doesn't work well with components.
It lets you declare behaviour for certain conditions, instead of letting you declare rules for that behaviour.

Let's investigate the 3 points above in closer detail.

1) Wide screen support

Just try a random Web of yours on 4k or 8k monitor ;)

Bootstrap-like grids are adaptive. It means they have some screen size limits; they use breakpoints. The biggest — xl, mostly stands for something around 1200px. Anything above is indifferent, and you need to deal with its responsiveness on your own. A lot of web pages break or look totally awkward on huge screens.

2) Grid vs Components

Bootstrap-like grids are almost useless inside components. Why?

Let say, you have 400px wide component with four 200px wide child elements. Obviously, its content needs to behave differently than in another instance of the same component, which has a width of 800px, right? In first case you prefer 2x2 grid, in other case you prefer 4x1 grid. Unfortunately, as the component code is the same for both instances and screen size is given, you are f.....

Bootstrap example where a column width is defined by percents

As we are already in a component era (React, Angular, Vue, Svelte, Web Components)… bootstrap-like grids seems to be doomed, but there is nothing to replace them, at least nothing generic that could be used across all front end frameworks.

You can still use bootstrap-like grids for page/app layout together with component oriented frameworks. But to be honest, when you see how much CSS code is generated for such grid system and how many classes you really use for a layout, it is better to get rid of it. You can always implement a custom solution.

Solution, fixing the Bootstrap example form above, seems to be definition of columns with min and max widths.

Columns take desired widths and proportinally consume the leftovers.

3) Grid's behaviour

Saying that bootstrap grid “lets you declare behaviour for certain conditions, instead of letting you declare rules for that behaviour” sounds bit philosophical. Translated to human language:

Bootstrap grid lets you declare how big certain blocks should be at specific breakpoints (you need to cover all page-width cases with your own overly declarative code, as in the Tailwind example). Mostly, lot of code must be written to reach a simple goal: to make an element similarly big at any screen size. The additional value of bootstrap grid system is just aligning stuff to a grid.
What we really want, is to declare a set of rules and let the grid's content to flow, span, shrink and stretch based on them.

Could we skip all the declarations for all the screen sizes and make the alignment to a grid automatic? Yes we can!

I know you can have hard time, arguing with your designers/product owners, when switching to a smart 'automatic' grid. You just need to explain to them, that even if they provide you with designs for mobile, table and desktop, there always will be some designs in between, which they don't have under control. Design should be specified on level of guidelines, component libraries and very basic understanding of layout rules, not on few pixel perfect mocks ;)

New Grid — design brainstorming

What characteristics should a truly responsive grid system have?

To be independent from the screen size (to be usable in components).
Grid should contain elements aligned to a virtual grid (grid gaps should align precisely in all directions)
A child of a grid container could span across several virtual columns (optimally also across rows)
Columns should have optimal sizes, given in units like px or rem, not in percents. Problem of defining columns only in percents is, that it forces us to define element's behaviour for specific breakpoints -sm, md, lg. Percents represent different real sizes under different conditions.
Grid should be defined by columns, not vice versa as in Bootstrap. Bootstrap grid has always 12 columns; it is too much for mobiles and too little for UltraHD.
Columns should adjust to container size (if column is wider than container, it should shrink itself to container's width).

New grid — choosing a technology

What technology to use? Available technologies seems to be Flex-box and CSS Grid. They both seem to fit to most of our requirements, but not to all of them. Let's see what these approaches miss:

Flex-box

In case we want to avoid definition of columns in percents of parent element, we would need to define grid elements by something like:

.col {min-width:100px; max-width:200px;}

Unfortunately this works only as long as last .col element is aligned to right edge of grid container. If first row has 3 .col elements and the second only has two .cols, then the elements no longer align to an imaginary grid. This behaviour cannot be fixed. That's a no go for Flex-box.

Grid

display: grid performs bit better, we can use:

    grid-template-columns: repeat(auto-fit, minmax($grid-col-width, 1fr));

auto-fit tells the grid to stretch existing columns, until there is space for a new one.
minmax() defines minimal and maximal width of a column. Min is the desired column width, max (1fr) tells the column to take 1/number of columns, in case there are not enough columns, which would fill the container with their minimal widths.

It does exactly the same as the flex-box example above, with the difference that it always fits to a grid, hurray! But it has another flaw. When you tell an element to span across three columns, but only two would fit the container. The spanned element leak outside the container. The only meaningful solution for this problem seems to be the long-wished Element Queries (queries where 'responsive conditions apply to elements on the page instead of the width or height of the browser.'). As they are still in a form of opened proposal, I had to program 'Element Queries' on my own.

Element Queries

I first tried to use some kind of polyfill, but those with good support were slow and relatively big (around thousand lines of code). As I was aiming for super small grid framework I had to find another way. Best fit was to use new 'ResizeObserver' and 'customElements' JS APIs. Their support is not optimal (about 70% of world market), but they are fast and exactly fit to what needs to be done. Element Queries for my grid can be done in something like 35 lines of code, which is awesome.

CSS and JS code required is 1KB (gzipped) and cover all the requirements form the brainstorming section. It actually does even more!

I now skip implementation details and show you the results, what my grid can do ;)

The “Eq Grid”

In order to avoid serving JS and CSS separately, adding event listeners to DOM elements, listening to DOM mutations and so on, I created a 'Custom Element' which you just need to import and init. It generates all the required CSS classes based on supplied parameters. All you need is:

npm i eq-grid --save

then in you main.js file:

import { initEqGrid } from 'eq-grid';
initEqGrid(120, 10, 'px', 10); // ['column width', 'gap width', 'units', 'max-columns-span/collapse']

From that time on, you can use <eq-grid> element in your html templates, and all the magic is done in background.

It works literally everywhere, in pure JS/HTML, React, Angular, Vue, Svelte and other modern frameworks.

Let's see some examples… Just open following sandboxes in fullscreen mode and try to resize them.

Grid used for content:

Useful for something like article teasers, cards, thumbnails, etc

In the example above, you can see classes .eq-col-3-5 .eq-col-2-4, which you can use to declaratively overwrite the automatic behaviour of the grid.

Nested grids:

By nesting, you can avoid some element breaking freely across 'rows'. It can be useful when creating layouts as shown below.

Grid used for Layouts:

You can wonder, why the grid has so wide .eq-col-1 on the right side. How is that possible? The root grid here has only two .eq-col-1 columns, all the stuff on left is in a nested grid. Each column has min-width 100px and max 1fr (one part of parent's width). In this case the max value takes the lead. If there are many elements in the root grid, then min(100px) rule is used instead. This applies to the nested grid on the left side.

Remember that content of child grids has no influence on its parents.

This example has 3 nested grids, btw. With this nesting technique, you can be in better control of what , when and how should fold or stretch.
It can be useful for big layouts.

Eq Grid and rem

There is one more cool feature this grid can offer, when you set it to use rem units:

initEqGrid(10, 1, 'rem');

Anything using rem units derives its size from font size of HTML element. It give us power to scale columns by media queries on the HTML element. If we use poly fluid sizing technique, we can linearly scale font up. Below I scale a little up to 1280px. Then I start scaling in same pace as the window grows.

html {
  font-size: 14px;
}

@media screen and (min-width: 320px) {
  html {
    font-size: calc(14px + 4 * ((100vw - 320px) / 960));
  }
}

@media screen and (min-width: 1280px) {
  html {
    font-size: calc(18px + 158 * ((100vw - 1280px) / 10000));
  }
}

@media screen and (min-width: 11280px) {
  html {
    font-size: 176px;
  }
}

Result of the above, together with eq-grid in rems is cool. Once window grows up to width over 1280px, everything (grid, fonts, etc) starts scaling up as if you zoom in. This way, you can see your web nicely on 8k monitor. You can set what the ratio between zooming and adding of new columns will be - simply by adjusting the font-size 18px + 158 and 176px.

See an example here (you need to click the 'Open Sandbox button', otherwise it wont work). Then zoom out a lot to see how it works ;)

Conclusion

I hope, the Eq Grid system is able to cover all common development/UX requirements. You can use it in very simple and automatic way and let the content flow like a water in the first picture. Or you can be more declarative and fine-tune how grid elements fold and shrink, based on the grid size. It is up to your requirements.

It is truly responsive.
It can scale from zero to infinite without compromising UX.
It is also first implementation of my own idea, and it definitely can be improved, so...

I'll appreciate if you leave a comment — what you think about it, what you miss, or what you like/dislike. Any feedback will be appreciated! Maybe we can make usage of grid systems, in era of components, viable again.

You can check eq-grid grid on npm: eq-grid on npm.
It is the place where all Eq-grid classes are described - what they do, and how to use them.
You can also check how the grid is used inside a React app

SPA with 4x100% lighthouse score — Part 3: Weather forecast app

Tomas Rezac — Wed, 01 Apr 2020 20:09:18 +0000

After previous two parts of the series, we know why I've chosen Svelte and Sapper to reach our goal and how to build with them a super performant app. We also have a functional ‘Hello world’ app with maximum lighthouse score.

In this 3rd part, I'll show you "production quality app", I made, as proof anyone can build a nice looking functional app with a great load performance. I'll not explain line by line, how the app was made, but will rather share my experience of building this app and dealing with all the restrictions, I imposed to myself.

The app showcase

Let's check few screens from the final app:

UPDATE 28th of April 2020: As city search API was removed from open weather API, I provide temporarily link to a specific city (Prague) and you do not have a chance to search city from the main page (I'll try to fix it soon)
You can try the app here or check its code on github

(Please don’t use it as regular app, it is limited to 60 requests per hour using openweathermap API. The app is meant just as a demo)

Here is a list of features the app can do:

PWA — works offline with cached data
Is installable on phone as a web app
Search forecast by city + Remember searched cities
Each of six main weather parameters can be visualised as a chart
Shows forecast via animated scenery (generated clouds with different size, opacity and colour based on rain, cloudiness and sun angle)
Shows animated rain and snow fall, based on it intensity
Shows animated thunderstorms
Shows times of sun/moon rise/set and animates sun/moon accordingly
Shows sun/moon directions from East to West
Shows sun/moon angle above horizon, based on time and period of year
Shows phases of moon

The app is not overloaded with functionality, but it is more than one needs from one screen of an app.

App size limitation

Good news is, that with Sapper each screen is lazy loaded. If you can reach the best lighthouse score on every single page, then your app can be as big as your imagination. You can still prefetch any routes in advance, either once processor is free of work - you can leverage the new window.requestIdleCallback() api. Or simply after user submits such an offer. Asking user to prefetch all routes makes sense, in case he/she is going to use your app in offline mode.

The conclusion: the extent of an app does not really matter, because every page is lazy-loaded by default.

My journey to 100% lighthouse SPA

You can think, I just took the optimised 'Hello World' app from last article and gradually turned it to the weather app without ever dropping below 100% in Lighthouse performance. Well I did not. I even dropped to something like 50% for a moment. Let’s check the hiccups I had, one by one.

1) Requests chaining

Sapper was build with some ideas in mind. One of them is not to load same things twice. In reality it means, if some component is loaded in several routes, it is bundled in a separate chunk. Also pages are not composed only from pre-rendered html and one JS file, but rather two or more, one for routing and minimal svelte api and one for the main component. It makes sense, you don’t want to load same components or the svelte and sapper api on every page again, you want to serve it from the service worker. With http2 many small request are actually good as they can be downloaded and parsed in parallel. The only drawback comes to play, when some code is dependent on code in different file. Unfortunately that is the case of Sapper builds.

After I got warning by Lighthouse about Requests chaining, I decided to get rid of it. Beside rewriting Sapper from scratch, there was only one solution, to rewrite Sapper, just a little and let it generate <link href="/client/index.ae0f46b2.js" rel="modulepreload"> for every single JS file. The rel=modulepreload tells the browser to start downloading and parsing a file before it is requested from real code.

As I was already at this, I also manually added links to 3rd party api: <link href="//api.openweathermap.org" rel="preconnect"><link href="//api.openweathermap.org" rel="dns-prefetch"> to <svelte:head>. Those help with getting DNS info before you ever call it. All these little tweaks have real impact on Time To Interactive.

If you are interested, there is a fork of Sapper on my Github with preload support. I changed what was needed, but was not 100% sure of what I was exactly doing ;) so there is no PR to Sapper — sorry. To be honest, Sapper source code would really appreciate some finishing touches, there are lines of dead code, some //TODOs etc.. Compared to very well maintained Svelte code base, I had a feeling that none cares much about Sapper. If you are good with Webpack or Rollup, I do encourage you to have a look and do something for Sapper community ;)

2) Main thread overloaded

Another warning by Lighthouse told me, that my main thread is too busy. It was a time to use some other threads :) If you are not familiar with javascript threads and Web Workers in particular, the important things to know are

Worker's code is executed in parallel to code in main thread.
It is executed in different file and
main communication between worker's code and your main thread is done over postMessage() api.

Post message api only lets you send strings back and forth, which is not very nice.

Luckily there is a 2kb Comlink library wrapping this communication to a promise based api. Moreover, it lets you call remote functions as if they were in the same thread. With Comlink, I moved to separate threads all the calculations related to a position of sun and moon and moon phases. It was a perfect fit as Web Worker’s only bottleneck is size of data being transferred. You don’t want to send pictures through it, because the serialisation and deserialisation would be very expensive. In my case I just sent latitude, longitude and time to a worker and it returned back stuff like directions, angles, phases. Because these calculations are quite complex, I was able to save some meaningful time from the main thread. With Comlink you can outsource even trivial tasks, as the overhead is minimal. Here is little example:

worker.js

 import * as Comlink from "comlink";

  const workerFunctions = {
      factorial(n) {
          if (n === 0) { 
              return 1; 
          } else { 
              return n * this.factorial( n - 1 ); 
          }
      }
  }
  Comlink.expose(workerFunctions);

main.js

import * as Comlink from "comlink";

const workerFunctions = Comlink.wrap(new Worker("worker.js"));

workerFunctions.factorial(50).then(console.log); // 3.0414093201713376e+64

3. Below the fold

Most significant drop in performance was caused by my cloud generator. I started with a naive implementation. I took all 40 records of weather forecast for next 5 days and for each of them, if it was rainy, I generated a cloud via Canvas. Generating 40 clouds is time and memory consuming, nothing one can afford when aiming for best-in-class performance. I needed to get rid of computations, which are related to stuff below the fold. So I implemented ‘infinity scroll’ with on demand cloud generation. As you scroll further, new clouds are generated. To avoid generation of same clouds twice (when you scroll back) I used powerful functional technique called memoization.

It simply, by creation of closure, adds a caching ability to any pure function you want. If you later call a memoized function with same arguments, it skips any computation and gives you the result from cache. In my case, it granted me yet another advantage. My clouds are actually partly random (the generator function is not pure, ups :0 ). And I don’t want to see different clouds for same scroll positions, when I scroll backward. The memoization ensured that cloud is randomised only on first call, second time I got it from cache :)

Let check together simple memoization function:

function memoize(func) {
    const cache = {};
    return function memoized(...args) {
        const key = JSON.stringify(args);
        if (key in cache) return cache[key];
        return (cache[key] = func(...args));
    };
}

Here is one example how to use it:

function addOne(x){
    return x +1;
}

const memoizedAddOne = memoize(addOne);
memoizedAddOne(1); // value counted => 2
memoizedAddOne(1); // value served from cache => 2

It makes sense to use this technique for any pure function, which is often called with same arguments. You shouldn’t use it for cases, where there are thousands of calls with different arguments as it would consume lot of memory by creating huge cache objects.

4. Lazy loaded functionality

If we can avoid loading of any content or code to a browser, we should avoid it. Beside lazy loaded pages, we can use IntersectionObserver to lazy load images, as user scrolls down a page. These are widely used techniques, which should be used where possible. Moreover, there is out of a box support for lazy loaded code in new versions of bundlers like Webpack or Rollup. It is called dynamic import, and it gives you the power to import code on demand from inside functions.

I used dynamic imports to load charting functionality once it is requested by user. You can see it in my app. Only after you click on one of the 6 icons, code responsible for drawing svg paths is downloaded and executed.

In rollup the syntax is very straightforward:

async function showStats(event) {
    const smoother = await import("../../helpers/smooth-curve.js");
    smoother.getPath();
    …

Final Results

I am happy to say, that the Weather app got 4x100% in Lighthouse audit. It is SPA, PWA, installable on phones, with some limited support for offline usage.

Conclusion

As you can see, modern tools and libraries like Rollup and Comlink make lazy loaded and performant app architecture so easy. I would say, there is no excuse not to use similar techniques in web apps and JS heavy pages, especially in those dedicated to general public.

I hope that the app I made is good enough example of what can be done in field of load performance. I am aware of poor animation performance of the app on slower machines. And I know, that too many animations triggered by scroll event is no-go. But this app has never been meant as something anyone should use in daily life. It was just satisfying for me to add more and more animations to it and make it more like a real world experience, rather than presenting some boring numbers.

The animation performance could be improved by using OffscreenCanvas inside a web-worker, but as it’s not supported by all current browsers, I decided not to use it. Maybe one day, I’ll return to this series and make the animation flow in 60 fps, who knows.

I hope you enjoyed the series and and learned something new.

In case you haven't checked it yet, here is The weather app

Aloha!

SPA with 4x100% lighthouse score - Part 2: Building an app

Tomas Rezac — Tue, 24 Mar 2020 20:06:54 +0000

Setting up the app

In last part we decided to go for JS, Svelte js framework/compiler and Sapper. If you want to know more about my reasoning, why I picked these technologies, and you haven't read my previous article, go and read it ;)

This time we will attempt to build together a demo app and hopefully reach our goal. In this part of the serie, we just finetune the Sapper hellow world app to max lighthouse score. In next part we'll build on top of our skeleton and create a fancy weather forecast app.

Beware, this is not an article about Svelte/Sapper, so we will go through the implementation in rather fast pace. But don't worry, if you dont know these technologies, I'll guide you through.

Be sure you have node js, npm and npx installed. Now let's get a hello world Sapper app running.

npx degit "sveltejs/sapper-template#rollup" lighthouse-app
cd lighthouse-app

npm install
npm run dev

Our Sapper app is now running on http://localhost:3000
If we run the lighthouse audit now, we are in green numbers but we won't get 4x100%. There are more reasons for getting 100% score:

Page is server rendered every time we hit a url
CSS assets are loaded via <link> element
Image is not in future format (webP)
Image doesn't have optimal size
Page metadata are missing
Missing apple touch icons
App is not running neither on http2 nor https
Http is not redirected to https

Let's fix them one by one:

1) Page is server rendered all the time we hit a url

This one is easy, Sapper has another set of commands for exporting web app as a set of static pages and assets. Just run the build and commands like this instead of the one metioned above

npm run export & npx serve __sapper__/export

Done app is running on http://localhost:5000 and the performace is already rated to 100% ;)

2. CSS assets are loaded via `<link>` element

The <link> behavior is not that bad, css files are made per component. So once you hit other page with same component, you already have the CSS cached by service worker. The default behavior seems to be good for apps with heavily repeating components, not for our app ;) Probably better for us, in terms of speed, is lighthouse's proposed way of injecting crucial css inline to the <head> element and thus avoiding the render-blocking request for sepearate css files. Let's change it.
Open rollup.config.js and change emitCss flag in svelte plugin to false.
There is one more render blocking request and it is the global.css. Go to src/template.html and comment it out (we will maybe use it later).
For now lets use some base css directly in template.html. Add following code above the commented stylesheet link:

     <style>
      html {
        box-sizing: border-box;
        font-size: calc(14px + 6 * (100vw / 1280));
      }

      @media screen and (min-width: 1280px) {
        html {
          font-size: 20px;
        }
      }

      body {
        margin: 0;
        font-family: Roboto, -apple-system, BlinkMacSystemFont, Segoe UI, Oxygen,
          Ubuntu, Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
        line-height: 1.5;
        color: #333;
      }
    </style>

Congratulations, you just made your app half way responsive.

The weird font size calculation is my minified version of something called poly fluid sizing. your base font size now scales from 14px to 20px as the screen grows to 1280px. To whatever you apply size in rems, will scale with it. 1rem is now something between 14-20px depending on screen width.

Rebuild the app and voilà. Even with the regular npm run dev we get 100% performance.

3) Image is not in future format (webP)

Just take the image static/great-success.png and turn it first to jpg (so we loose alpha channel). Then convert it for instance with webP convertor. Copy the image to the static folder and adjust its html in src/routes/index.svelte accordingly.

4) Image Doesn't have optimal size

Not only it has wrong size, it is also one and only size the img tag offer. We can do better, we will use <picture> with srcset tag. Go to responsivebreakpoints.com and upload our webP img, set max resolution to 400 (it is the image max size it can get in our app). Save images to static folder. Replace old img tag with new picture one, which was generated by the tool. Done.

5) Page metadata are missing

Go to src/routes/index.html and any other page(route) you want to optimize and add following metatag into the <svelte:head> tag.

 <meta
    name="description"
    content="Welcome to sapper app" />

Now we get 100% SEO rating on every page where we added the meta description

6) Missing apple touch icons

Grab some nice simple icon and process it with realfavicongenerator.
Copy generated code to src/template.html and files to static folder

7) App is not running neither on http2 nor https

Now it is time to move our app to the internet. We could also run our local server with npm spdy server and self signed certificates. But it won't prepare us for real internet conditions. We will deploy our app to Netlify. it is free for testing purposes, it is fast, works as CDN, and even provides serverless functions and auth middleware.

Easiest setup is to create netlify app from github repository. Create a repository on github and push your lighthouse-app to it.
Now sign up for netlify. In your netlify site page, click New site from git. Once you are in step 3, you will be asked for Build command and Publish directory. Fill first with npm run export and second with __sapper__/export. Then click Deploy site

Each time you push to a chosen branch in github, netlify hooks into it and builds and deploys a new version.

8) Http is not redirected to https

This is already done, as Netlify provides https, http/2 and redirects out of the box.

Now we only need to measure the results. Copy the url netlify generated for your web app. For me it is https://eloquent-dijkstra-d8bd7b.netlify.com/.

Now go to the new online measuring tool (lighthouse) web.dev. We should measure by this one, not by plugin in chrome or dev tools. The web.dev tool give you more stable results, not influenced by quality of your internet connection and your computer's power.

Here are the results, not bad, considering, it took us 10 minutes from start to end.

We have a skeleton for a future app. We are backed by full featured component based framework with all the things like 2-way-binding, state management, routing, animations etc.

In the next part of this serie we try to turn this hello world app to a more real-world app example: a Weather forecast app. We will see whether we are able to keep our perfect score with a growing complexity and connection to an external API.
In the meantime you should go and learn some basics about svelte and sapper.

See you next time ;)

SPA with 4x100% lighthouse score - Part 1: The tech stack

Tomas Rezac — Sun, 22 Mar 2020 16:07:29 +0000

The goal

To choose a right tech stack for building an SPA (Single Page App), which gets the best possible score in lighthouse audit. Just telling in advance, we are looking for something simple and elegant, not for a pure JS solution or some rocket science.

Why to even attempt?

There are multiple benefits:

Our app will get best technical rating by Google Search Engine. SEO is no longer the only indicator, responsible for sorting of search results. Performance and accessibility are getting more and more important. See more in searchmetrics.com study from 2019.
Users of Our app will be happy even when opening it with slow device or poor network connection.
We’ll be forced to make simple app, containing only what’s really needed. With no bloated, hard to understand functionality.

Lighthouse indices

Lighthouse audits sorts out its findings and proposals into four categories: Performance, Accessibility, Best Practices and SEO. All of them are important for ranking in google search, but some are more important than others. Getting the last three to 100% won’t be that hard. We just need to add all required metadata to a page and set up server correctly. Getting Performance to 100% is different story — we will focus on that later. Based on searchmetrics.com study Lighthouse Ranking Factors 2019, top ranked search results (when searching generic keywords like “shoes”) have something in common. They are best in: Performance, time to First Contentful Paint, following best Practices, size of DOM, they use webP images and run over https or better http/2.

searchmetrics white paper showing top 20 search results in google search with data about their speed of FCP

SEO and Accessibility are also important for them, but correlation between its score and ranking in top 20 is not obvious, and rather misleading.

searchmetrics white paper showing top 20 search results in google search with data about their SEO

Why making fast SPA is so hard in real world?

We as developers experience era of fancy frontend frameworks. Interactive functionality, which we could have dreamed about 10 years ago, is not only possible these days, it is often matter of minutes to implement. It has been a giant leap for developers, but rather small one for users. Our networks are 10 times faster; our computers are 10 times more powerful, our frameworks are 10 times more awesome, but it takes similar time to load average web page, as 10 years ago. How is that even possible?

You always wish to have extraordinary web, which is step ahead of your competition. Full of interactivity, animations, images and videos. Your product owner wants it as soon as possible. Your stake holders want all stats about visitors. Your FCO wants more ads to make more money, and so it goes on. It is a common pattern I have been observing over 13 years of my professional carrier as web developer ;) In the end, requirements in its MVP (Minimal Viable Product) are already so demanding and way beyond what users really need and want. Performance is simply not a priority for most of software teams. As Jeremy Wagner says in: Innovation Can’t Keep the Web Fast. A “hello world” app with all above mentioned requirements would already be 1 or 2 MB. Especially if you use something like React, or Angular. We can do better. We should start creating web for users again!

Let’s try to learn from big companies and their successful products. Facebook for instance; its SPA homepage (on desktop) is loaded in about 10s, has 9.8MB and it is all done in 350requests. There are some advanced techniques used, but it is not point of this article. I can just say it performs better than it looks. To be honest, its visible content is loaded in 4s; it is not bad, considered the app complexity. But do we need all that complexity on initial load? I would say no. Just check facebook.com lighthouse ratings; it is a disgrace.

facebook.com in desktop chrome MacBook Pro 2018 i7 (Simulated Slow 4G, 4x CPU Slowdown

Maybe it is not that great idea to have one of the most loaded pages on the internet as a model. We will try to achieve 4x100% with far less complex app. You always need to think twice, whether an app really needs to be so huge and complex. Especially when you can lazy load most of the stuff.

Choosing right tech stack for 4x100%

I am sorry, but very probably your favourite framework won’t do it. To choose one which will, we need to understand all restrictions and requirements.

First of all, we know, we need a JS code because we want to build SPA. We cannot do that with server rendered pages, without JS.

We need either vanilla JS or a lightweight framework. I can tell you straight away, that if we aim for 4x100% on slower mobile devices, we cannot use any of the holy trinity of JS frameworks (React, Angular, Vue).

Just for illustration, a React hello world app itself (one dummy screen with no routing and data management) won’t pass the audit with 100% Performance. Not even Next.js (server prerendered and optimised React app) can reach the desired Lighthouse Performance score, as it still contains a minified build of React and only gets us to 96% for Performance.
Why? Because even if an app is prerendered on server, React itself is still loaded for later hydration. Processing(parsing and compiling) React code by a browser is quite expensive operation, responsible for the score. It is important to understand that cost of 100kB of HTML is very different from 100kB of Javascript. An option is to load javascript in async mode, after page is rendered. But it has negative impact on other measured index —” Time to interactive”. Not even mentioning that above stated score was achieved with blank page, on very fast machine on local server. Once we start adding our own code and move the app to internet, we will be doomed; the score will drop significantly.

Inferno, Preact and some other clones of react would be able to reach the score, but we won’t use them. They wouldn’t give us the luxury of full featured framework and we would end up with writing a lot of pure JS code along those libraries.

Fortunately there is an unspoken demand for what we are attempting here. There are frameworks, popping up right now, trying to please both, users and developers. They offer rich features and minimal trace at the same time. For our purpose we need two things from such a framework:

1) to support easy lazy-loading of almost anything and
2) minimal or no size on its own.

Splitting code to lot of smaller bundles enables parallelisation of JS parsing and releases the main thread for more important tasks (see more on V8 blog The cost of Javascript). If we want to fulfil the second point, we will need to get rid of a framework. But as long we want to keep framework’s declarative syntax, there is only one solution to this riddle: a compiler.

A compiler

Probably the most endorsed “framework” of this type is Svelte. With Sapper, its pre-rendering counterpart, they fit to our requirements. So let’s focus on them.

It will be good to know, what are the limits of compiler compared to regular framework, The fundamental difference is in a way how its code is run in a browser. With regular FE framework you are able to load such a framework by <script src=”framework.js”> tag and then just write your code inside another <script> tag. None of the modern frameworks encourage developers to follow this pattern, and with most of them you would have hard time to get it running this way. But you can, it gives you power to dynamically create components and inject them during runtime to your app. It can be “must have” in some apps, but — let me exaggerate a bit — in 99.9% of them you don’t need it. For those 99.9% you can use a compiler.

Svelte is a compiler, which accepts code written in similar manner as in React, Angular or Vue (component centred architecture), but is compiled to direct DOM manipulation instructions. If you don’t use a feature of Svelte, it won’t be output to a production bundle. If your page is just 10KB of HTML and CSS, then the svelte generated page will have about 10KB. If you use one two-way binding in that page, you will get maybe 0.1KB extra. Definitely there won’t be a 100KB framework handling your one two-way binding ;) With Svelte you can write high level declarative code and you will end up with highly optimised native JS code. With svelte we know, we start with minimal burden.

The Jamstack

So we chose the tech, but there are still decisions to do. Should we just bundle an app to big JS file, prerender it on server, or serve it as static assets? Best option seems to be be the last one. It has several advantages: 1) Code is split to smaller chunks. 2) Content loaded for first meaningful paint is served from a static HTML file which can be easily served over CDN.

Once static page is loaded, we can fetch JS and add some dynamic functionality to it. We can even do some api requests and customise the page for a user. This approach is called Jamstack, it is successor of statically generated pages. Jamstack is bringing API and more custom content to static generators. Jamstack stands for JS, Api, Markup.

Fortunately for us Sapper does support static generation of pages. It also provide basic setup of service worker for subsequent loads of the app. It comes with some minor bells and whistles supporting prefetching of pages before you hit them, basic in app routing. It all in cost of 13KB (before G-zipping).

FE is just one side of the puzzle. We will also need reliable CDN server, fast API (cloud - optimally - distributed database). User Authentication and authorization of requests. These BE and middleware related topics are not main focus of this article, but we will touch them, because…

In Part 2 of this serie, we will try to prove our tech stack in a demo app. We are gonna build and deploy hello world SPA… In Part 3 we will turn our dummy app into real weather forecast SPA.

See you next time;)