DEV Community: Piotr Gołofit

A brief history of PHP language & what we can learn from it?

Piotr Gołofit — Fri, 11 Apr 2025 10:05:02 +0000

This year PHP gets into its thirties 🎉 And on this occasion I would like to briefly summarise the history of PHP web development, to better understand the present and the future of the PHP programming language. I am pretty sure there is a lot we can learn from this story.

So let's begin...

It was in June 1995, thirty years ago... or wait, let's start even a bit earlier...

How did it all start?

It is November 1968 in frosty Greenland, when the future programmer Rasmus Lerdorf is born. The World Wide Web is still 21 years from being invented. And Greenland is still part of the Kingdom of Denmark, and no one is trying to buy it 😉

Would his parents know that Rasmus will become a programmer? Probably not, as the C programming language will be unknown for another few years.

Fast forward to 1994. Rasmus Lerdorf is working on his online resume. Yes, online, because the World Wide Web was invented in 1989 and became open to the public in 1993. He is probably one of the first to have a digital CV 💪

Rasmus wanted to track how many people had visited his resume. How would you do it back then? It was way before Google Analytics was launched. Heck, Google itself would be unknown for another four years! So what did he do? He coded himself a simple set of Common Gateway Interface (CGI) binaries first in Pearl and later in the C programming language, which eventually led to PHP being born. Here is his story.

"PHP began life as a simple little cgi wrapper written in Perl. I wrote it in an afternoon during a period between contracts when I needed a quick tool to get an idea of who was reading my online resume. It was never intended to go beyond my own private use. The web server where I had my resume was extremely overloaded and had constant problems forking processes. I rewrote the Perl wrapper in C to get rid of the considerable overhead of having to fork Perl each time my resume was accessed."

~Rasmus Lerdorf (source: https://www.php.net/manual/phpfi2.php)

From PHP Tools to PHP Foundation

Later more people using the same Web Server contacted Rasmus if they could use his wrapper. And as usual, if you give something to people, they keep asking for more. So Rasmus added more and more features to his toolset leading eventually to a semi-complete distribution along with documentation, a mailing list and a FAQ. How did he name it? A "Personal Home Page Tools", or in short, a PHP Toolset.

PHP/FI (aka PHP 1)

Back then, Rasmus also began experimenting with databases and developed a tool for seamlessly integrating SQL queries into web pages. This solution, essentially a CGI wrapper, parsed SQL queries and simplified the creation of forms and tables based on those queries. He named this tool a Form Interpreter or FI for short. And that's how a PHP/FI was born. By many called a PHP v1.

PHP 2

In 1997 the PHP acronym was formally changed to PHP: HyperText Preprocessor. In the second version of PHP/FI 2.0, Rasmus has completely rewritten the PHP and FI packages and combined them into a single program. It also evolved to the point, where it was a simple scripting language embedded inside HTML files. That's probably the moment where the term "dynamic web pages" was born, as PHP enriched static HTML sites with server-side generated content. And in this very way, it was to be known for many years to come, until web development got into templating and finally APIs and SPA applications.

PHP 3

In 1997, two Israeli students from Tel Aviv - Andi Gutmans and Zeev Suraski — reached Rasmus online regarding his implementation of PHP. They wanted to use it for their university project, but it was simply inefficient and lacking some features. So they started discussions around various aspects of the current implementation and their redevelopment of PHP. And that's how PHP version 3 was born. It introduced included object-oriented programming and was the first version that more or less resembles PHP as it exists today. Two years later Zeev and Andi would combine their first names to register their new company - Zend Technologies. You might have heard of it 😉

PHP 4

May 2000 brought us PHP version 4. It was the one which, among other features, introduced HTTP sessions and output buffering. Andi Gutmans and Zeev Suraski started working on it just after the official release of v3. Their goal was to improve PHP and its performance for larger and more complex applications. The result of their work was a release of Zend Engine 1.0 which became the core of PHP 4.

Thanks to OOP introduced in version 3 and new features from version 4, PHP became something more than just a simple scripting language for dynamic web pages. It evolved from a hypertext preprocessor to a fully fledged programming language for building more and more popular dynamic web applications and API's. It was around this time when the first ever RESTful API started to appear.

PHP 4 was also the first one that powered... WordPress 1.0! The very first public version of this popular CMS was released in May 2003 when most of the servers were running on PHP 4.1. This was probably one of the crucial moments in the history of PHP. It was also the spark that led to a famous statistic saying that PHP powered over 80% of the whole internet. A year later, a young Harvard student Mark Zuckenber (ever heard of him? 😉) will code thefacebook.com using PHP 4.

First logos of Facebook (named TheFaceBook back then) and WordPress from 2003/2004.

PHP 5

Quick jump to July 2004 and release of PHP v5. By this point in time PHP's development community comprises dozens of developers, along with numerous others contributing to PHP-related projects such as PEAR, PECL, and documentation. It is a huge success for PHP and it is believed that this programming language is currently installed on even hundreds of millions of domains worldwide.

PHP 5 represented a fundamental redesign of the language, featuring the new Zend Engine that improved performance while expanding object-oriented programming features with better syntax and functionality. It also added innovations like exception handling and enhanced error reporting. These advancements helped cement PHP's status as a powerful and widely used language for web development.

The first version of Symfony released in 2005 extended PHP code with many useful components.

The year 2004 and the release of PHP 5 was also a turning point for a passionate Perl developer Fabien Potencier. That's exactly when he decided to switch his focus to PHP and created the Symfony framework project (released a year later) to help his company leverage the power of PHP for complex web applications.

And what may surprise you, as of April 2025, still more than 10% of PHP pages use version 5!

PHP 6

Legendary 🦄 sixth version of PHP. How to summarise it? I think this comic does it pretty well:

No PHPun Intended comic about PHP 6.

And now being more serious - why PHP 6 was never released? The plan was to introduce deep native support for Unicode in PHP. Unfortunately, the number of technical difficulties around this implementation (including performance issues and backward compatibility) led to abandoning the PHP 6 project in 2010 and its Unicode features. Many of the non-Unicode features that had been developed for PHP 6 were incorporated into PHP 5.3 and 5.4 instead. For the next PHP version web developers had to wait for over a decade. But in the meantime, two important things happen to PHP. First of all, in 2009 we founded Accesto 😉 And a year later, Taylor Otwell released the very first version of Laravel. For some reason I see the first one as a more important fact - but I guess you may disagree 😉

PHP 7

This version feels like yesterday, but is already 10 years old! Released in 2015, delivered substantial performance enhancements (up to twice as fast as PHP 5.6 🚀) and reduced memory consumption. With its subsequent versions 7.1-7.4 added a lot of language features like the ?? operator, anonymous classes and return type declaration, just to name some.

PHP8

PHP 8.0 was released in 2020 with many new features (eg. named arguments, union types, attributes, null safe operator) and significant performance improvements (huge difference thanks to the JIT compiler). Further minor releases brought us enumerations, fibers, readonly classes, DNF Types, and typed class constants. And many more! An impressive list for just a minor release I must say.

The last PHP version (8.4) introduced property hooks, asymmetric visibility and array functions.

PHP.... The Foundation

November 2021 sets another important milestone in PHP history. Nikita Popov, one of the significant contributors to PHP is leaving the project. Is it the end of PHP? On the contrary! This event became a catalyst for a series of events which in the end led to the PHP Foundation being established. With its mission to ensure the long-term prosperity of the PHP language. From now on, PHP as a programming language has a solid team of core developers, contributors and supporters.

The goal of The PHP Foundation is to ensure the long-term prosperity of the PHP language.

What we can learn from PHP history for today?

The history of PHP shows that this was never a hype-driven language. Throughout its history, PHP wasn't the first one to introduce various features. It adopted object-oriented programming pretty late and for many years was pretty far from types. But at the same time, it never stopped evolving! PHP may not be up to date with what's latest or sexy and may not have all the sugar yet. But it is getting the modern syntax eventually. May not be the first one, but thanks to that, it does implement only those solutions, that proved to be useful in other languages and other technologies. And eventually, modern PHP code does not differ much from any other contemporary language used by web developers.

Getting mature, not old!

For the last 30 years, PHP has constantly developed and improved as a language. It wasn't getting old through these years! On the contrary, it was constantly evolving and adapting to modern web development.

How much more you can improve after 30 years of constant development? PHP shows that quite a lot. The last version 8.4 introduced property hooks, asymmetric visibility and array functions. But one thing is language features, another is better security and performance improvements.

And speaking of performance. Last month we upgraded PHP for one of our clients from 8.1 to the latest 8.4. Results? Approximately 15-20% performance boost:

Web transaction time was shortened by 15-20% after upgrading PHP to the latest 8.4 version.

We have already seen some good performance boosts in this project with previous upgrades within version 7 and version 8. So I wasn't really expecting any significant further improvements this time. But PHP continues to surprise me. After 30 years we can still expect some nice gains. Good job to all the core PHP developers! 💪

PHP was built out of necessity

Personally, I also like the fact that PHP was created by Rasmus Lerdorf to solve his real-life problem. And for years it continued to evolve in that very manner — driven by real needs, not by hype. Also the same was with the PHP Foundation. It wasn't established to gain power over PHP development or because having a foundation is cool. It was built out of a real need to support PHP and its growth.

Recently our CTO did a small interview with Roman Pronskiy, an Executive director of the PHP Foundation. Roman revealed couple of initiatives that will shape the future of PHP in the upcoming months and years. And of them are driven by real needs, not by hype. Examples? Introduction of generic types in PHP, and extensive security audits for PHP language, supported by German government-backed agency!

Happy birthday, PHP!

Some may think that a programming language that is 30 years old is a finished history. That after so many years we should not expect any new language features. But that's definitely not the case with the PHP! It may not be the first one that introduces various features, but you don't have to be first to be solid, reliable, and thanks to that... relevant. Personally, I like PHP because after 30 years it can still get better and better.

Creating Angular Tooltip Directive - Part 2: adding customisation

Piotr Gołofit — Mon, 17 Oct 2022 13:54:15 +0000

In my previous blog post, I explained how to create your own angular tooltip directive without using any third-party component libraries (like using angular material tooltip). Today, I will show you how to add more customisation to build a fully-fledged tooltip module.

Note: the whole code from this tutorial is on GitHub

Customising Angular tooltips

The tooltip directive created in tutorial part 1. should be good enough for many basic use cases. But in more complex situations, you may be tempted to install some dependencies to external angular tooltip libraries. Let's avoid this, and instead, let's take our own tooltip directive to the next level. Today, we will make it way more universal by adding a few features & options:

tooltip position (below, above, left or right);
tooltip themes (dark theme vs. light theme);
tooltip delay time (separate tooltip delay show & tooltip delay hide);
dynamic tooltip that follows the mouse cursor;
support for touch devices / mobile devices.

Without further ado, let's jump straight into the first customisation.

Tooltip position - angular tooltips in the right place

So far, our tooltip was always displayed below the parent element. Now we will add an additional attribute position that will allow us to display it more flexibly. We will allow it to be placed below, above, left or right of the host element:

export enum TooltipPosition {
    ABOVE = 'above',
    BELOW = 'below',
    LEFT = 'left',
    RIGHT = 'right',
    DEFAULT = 'above'
}

To keep our code nice and clean, let's create tooltip.enums.ts file, where we will define enum types for all the available customization properties. In addition to apparent options for TooltipPosition (above/below/left/right), you can also define a default position in our enum.

Now, let's update the ts file of our directive to accept the position attribute as an @Input:

export class TooltipDirective {

  @Input() tooltip = '';
  @Input() position: TooltipPosition = TooltipPosition.DEFAULT;

In part 1 of this tutorial we created a method setTooltipComponentProperties(). In that method, we calculated the position of our tooltip relative to the HTML element on which the user hovers (to display it right below it). New version of this method will have separate calculations for each of the TooltipPosition options:

private setTooltipComponentProperties() {
    if (this.componentRef !== null) {
      this.componentRef.instance.tooltip = this.tooltip;
      this.componentRef.instance.position = this.position;

      const {left, right, top, bottom} = this.elementRef.nativeElement.getBoundingClientRect();

      switch(this.position) {
        case TooltipPosition.BELOW: {
          this.componentRef.instance.left = Math.round((right - left) / 2 + left);
          this.componentRef.instance.top = Math.round(bottom);
          break;
        }
        case TooltipPosition.ABOVE: {
          this.componentRef.instance.left = Math.round((right - left) / 2 + left);
          this.componentRef.instance.top = Math.round(top);
          break;
        }
        case TooltipPosition.RIGHT: {
          this.componentRef.instance.left = Math.round(right);
          this.componentRef.instance.top = Math.round(top + (bottom - top) / 2);
          break;
        }
        case TooltipPosition.LEFT: {
          this.componentRef.instance.left = Math.round(left);
          this.componentRef.instance.top = Math.round(top + (bottom - top) / 2);
          break;
        }
        default: {
          break;
        }
      }
    }
  }

We will also define the position property in the .ts file of our TooltipComponent:

export class TooltipComponent implements OnInit {

  position: TooltipPosition = TooltipPosition.DEFAULT;
     ...

The value of the position property is assigned in the setTooltipComponentProperties in the code above. We will use it to set a proper modifier to our CSS tooltip class...

<div class="tooltip"
     [ngClass]="['tooltip--'+position]"
     [style.left]="left + 'px'" [style.top]="top + 'px'">
  {{tooltip}}
</div>

...to properly align our tooltip in the desired position:

.tooltip {
   ...
  &--below {
    transform:translateX(-50%);
    margin-top: 7px;
  }

  &--above {
    transform:translate(-50%, -100%);
    margin-bottom: 7px;
  }

  &--left {
    transform:translate(calc(-100% - 7px), -50%);
  }

  &--right {
    transform:translateY(-50%);
    margin-left: 7px;
  }
}

I am using a BEM notation, so it will be eg. tooltip--below or tooltip--left, but feel free to adjust it to the CSS conventions of your project.

Also, if you added a small triangle indicating the tooltip anchor point, you should also adjust it for new positions. Below is just an example of the right-positioned tooltip, feel free to check the repo for the full CSS here: https://github.com/accesto/angular-tooltip-directive

.tooltip {
   ...
    &::before {
      border: 5px solid black;
    }
   ...
  &--right {
    ...
    &::before {
      border-top-color: transparent;
      border-bottom-color: transparent;
      border-left: none;
      left: -5px;
      top: calc(50% - 5px);
    }
  }

And that is it:

  <div class="cat-icon" 
    [tooltip]="'Meow on the right!'"
    position="right">
</div>

Note: if your project setup (in tsconfig.json) requires angularCompilerOptions.strictTemplates you may need to import the enum type and use [position]=TooltipPosition.RIGHT instead of simple position="right".

Tooltip themes - angular tooltips that match your UI

Our next customisation will allow us to use our tooltip in both light and dark UIs.

Again, we will start by defining an enum type for our TooltipTheme options:

export enum TooltipTheme {
    DARK = 'dark',
    LIGHT = 'light',
    DEFAULT = 'dark'
}

Depending on the theme, we will adjust the tooltip background, and of course the tooltip text colour. We also have to adjust the tooltip anchor point (small triangle) to match the tooltip background:

.tooltip {
   ...
  &--light {
    background-color: white;
    color: black;

    &::before {
      border: 5px solid white;
    }
  }

  &--dark {
    background-color: black;
    color: white;

    &::before {
      border: 5px solid black;
    }
  }
   ...
}

And to make use of these themes, we have to pass the theme property to our component template the same way as we did with the position. I will skip that part here but feel free to check the complete code in the repo: https://github.com/accesto/angular-tooltip-directive

Tooltip delay time - instead of showing the tooltip immediately

Now, let's play a little bit with the tooltip behaviour. So far we just wanted to show the tooltip immediately when the user's mouse hovers over the selected HTML elements. But common practice is to show the tooltip after the user hovers over the tooltip's trigger element for a longer period (measured in milliseconds) - which may indicate that he needs some help or explanation. Let's add some delay time before we make our tooltip visible. Options are two - we can either instantiate our tooltip component after the delay, or do it immediately, but play with its opacity. I'll go with the second option, as it will give more options to control the potential show animations/transitions:

.tooltip {
  opacity: 0;
   ...
  &--visible {
    opacity: 1;
    transition: opacity 300ms;
  }
}

To control visibility, we have to define visible: boolean = false property in our TooltipComponent and use it in the class directive:

[class.tooltip--visible]="visible"

Let's now add setTimeout() to our onMouseEnter() method of our tooltip directive:

 onMouseEnter(): void {
   if (this.componentRef === null) {
       ...
      this.setTooltipComponentProperties();
      this.showTimeout = window.setTimeout(this.showTooltip.bind(this), this.showDelay);
    }
  }

  private showTooltip() {
    if (this.componentRef !== null) {
      this.componentRef.instance.visible = true;
    }
  }

Where this.showDelay (defined in milliseconds) will of course be another @Input() property of our angular tooltip directive. For formality, let's also clear the timeout if the user's mouse leaves the tooltip's trigger element:

  destroy(): void {
    if (this.componentRef !== null) {
      window.clearTimeout(this.showTimeout);
      ...
    }
  }

The same we can do with the hide delay. For that, we need to modify onMouseLeave() method of our angular tooltip directive:

   @HostListener('mouseleave')
  onMouseLeave(): void {
    this.hideTimeout = window.setTimeout(this.destroy.bind(this), this.hideDelay);
  }

Again, hideDelay will be an @Input() property that will define closing time in milliseconds. And of course, we also have to clear the timeout of our close delay in case the user hovers again over the parent element.

And that is it - see an angular tooltip example in action, with delays for showing and hiding the tooltip:

You could also add some hiding animation/transition after the hide delay, but I will leave that to you.

Dynamic tooltips - eg. when the user hovers over an area

Tooltips, as the name suggests, are often used to provide additional information on tools that users have in the UI. Let's assume you are building an online graphics editor. It's a common case, to show the mouse coordinates over the editor canvas. For that, we will need a tooltip that won't appear in one place, but will rather follow the user's mouse. For that, we will let our angular tooltips listen to pointer events, and update their position whenever the user moves the cursor. Let's call it a dynamic tooltip position:

export enum TooltipPosition {
    ABOVE = 'above',
        (...)
    DYNAMIC = 'dynamic',
    DEFAULT = 'above'
}

We could also define the tooltip position left/right/below/above the mouse cursor, but let's not overcomplicate this and stick to just the default behaviour. We will simply display the tooltip next to the cursor, and will hide the anchor point:

&--dynamic {
  margin-left: 20px;

  &::before {
    display: none;
  }
}

Listening to the pointer events is quite straightforward, we just need to add another @HostListener that will update the position of our angular tooltip whenever the user moves the mouse:

@HostListener('mousemove', ['$event'])
  onMouseMove($event: MouseEvent): void {
    if (this.componentRef !== null && this.position === TooltipPosition.DYNAMIC) {
      this.componentRef.instance.left = $event.clientX;
      this.componentRef.instance.top = $event.clientY;
      this.componentRef.instance.tooltip = this.tooltip;
    }
  }

You may be wondering why we also update the this.componentRef.instance.tooltip? It's because otherwise, we won't be able to dynamically update the tooltip content. This allows us to achieve tooltips like these:

Support for touch devices - mobile tooltips

Last but not least, we will focus on making our tooltip module compatible with mobile devices. What's different on mobile? Lack of the mouse pointer of course! So how we can show our angular tooltip if the user cannot hover his mouse over anything? It's quite simple actually. We just need to adjust our tooltip directive and in addition to pointer events, listen also to touch gestures.

First, let's determine what kind of gestures we want to detect. Shall we show the tooltip whenever the user taps (touches) some button or other HTML content? That would be quite straightforward to implement, but would actually prevent users from using that button. We still have to allow all the standard taps for the normal usage of the UI. Instead, let's detect the situation when the user long presses the screen over the HTML content. But how do we define the long press?

Unfortunately, there is no touch event that would express the long press. But no worries, we can combine touchstart and touchend events, to detect if it was indeed a long press.

So far we have been initialising our tooltip right inside the onMouseEnter method. Now, because we will have more than one trigger than the mouse, let's move the initialisation to a separate method:

@HostListener('mouseenter')
  onMouseEnter(): void {
      this.initializeTooltip();
  }

  private initializeTooltip() {
    if (this.componentRef === null) {
    ...

And we will use that method also after we detect the long press:

@HostListener('touchstart', ['$event'])
  onTouchStart($event: TouchEvent): void {
    $event.preventDefault();
    window.clearTimeout(this.touchTimeout);
    this.touchTimeout = window.setTimeout(this.initializeTooltip.bind(this), 500);
  }

  @HostListener('touchend')
  onTouchEnd(): void {
    window.clearTimeout(this.touchTimeout);
    this.setHideTooltipTimeout();
  }

  private setHideTooltipTimeout() {
    this.hideTimeout = window.setTimeout(this.destroy.bind(this), this.hideDelay);
  }

Simple as that, now our angular tooltips are ready for mobile devices. Cheers! 🍺

Summary

In part 1 of this tutorial, we created a custom angular tooltip directive for displaying very basic tooltips. Part 2. brought many customisations to our tooltip module. You should now be able to use it in most of your angular applications. Sure it still has fewer features than the best angular tooltip libraries (like an angular material tooltip), but if you miss some features, feel free to extend it further.

You can play with the default options & default values like default delay. You can add further settings like font size or passing custom css class. Or you can even consider creating an angular tooltip service, for non-manual triggers (to show/hide the tooltip programmatically).

I will leave it to you. And in the meantime, you can check the complete code of the angular tooltip directive from this tutorial here: https://github.com/accesto/angular-tooltip-directive

How to create your own Angular Tooltip Directive - a short tutorial

Piotr Gołofit — Tue, 09 Aug 2022 14:45:00 +0000

Tooltips may seem insignificant, shy, and sometimes neglected. But they are real superheroes of many user interfaces. And like superheroes, they appear from nowhere, right when you need them, exactly where the help is needed. But, what is their superpower?

Tooltips are really powerful at delivering information. They are a perfect way to provide contextual help, without overloading users with too much information at the first glance. Tooltips appear wherever users need some additional data or explanation. No sooner, no later. This allows you to maintain the UI nice, clean and minimalistic.

Tooltips are commonly used as a pop up tip to explain the meaning of various tools, buttons and icons

Providing help in form fields, explaining complex features or tools, displaying additional information over charts... There are many ways tooltips can improve the user experience of your application. So if you are a front-end developer building an app in Angular, there is a huge chance that sooner or later you will be adding tooltips here and there.

How to add tooltips to an Angular app?

Before we dive into creating our own Angular Tooltip Directive, let's see some other ways to add tooltips in the Angular app. One of the most popular ways is to use the Angular Material component library. It provides a large set of components that follow the Google Material Design system. Another common UI library that you can consider is ng-bootstrap - it is an Angular version of the previously most popular HTML/CSS/JS library in the world - Bootstrap. If you seek something more lightweight yet powerful, you can also check ng2 tooltip directive.

Examples of Angular Material & NG Bootstrap tooltips

So why should I create my own Tooltip directive in Angular?

With so many tooltip solutions available, creating your own tooltip directive may seem like reinventing the wheel. But here are some reasons why you still may want to consider building it from the scratch on your own:

Because you don't want to rely on yet another npm package or you just want to keep your app lightweight - without adding the whole Angular material to achieve tooltips;
Because you may need more customisation to your tooltip style (like light theme vs dark theme) or behaviour (eg. dynamic tooltips that follow your mouse - I will cover that in part 2. of this tutorial). You may also want to add some directive options like content type, custom hover options (animation, hide delay, show delay) or a support for touch devices / mobile devices;
Because you may be building a whole component framework for your app and want tooltips to be part of it;
Last but not least - because you may want to learn how to build angular structural directives, and although there may be some simpler directives to start with, tooltips will give you a good lesson.

So if you already decided to build your own tooltips, let's see how we can approach that task and what building blocks of Angular shall we use.

Tooltip as a Directive, Component or as Service?

It depends, of course 😉 The same way as a custom button in Angular can be implemented as a standalone component tag, or as a directive applied on a standard HTML tag. Today I will show you how to implement a tooltip in Angular as a directive because I find it the most common use case. Usually, tooltips don't live on their own (like Components) and don't need to be invoked programmatically (via Services). They are usually add-ons to existing HTML content, and that is where structural directives work best.

But as your use case may be different, you may consider implementing tooltips as an:

Angular Directive - plain and simple, just an add-on to existing HTML code, usually containing just a string or a short text;
Angular Component - when you need to place inside a tooltip something more sophisticated than a text or an image, eg. some additional data above an interactive chart, or even to make universal tooltips that can display any given content inside the ng template tag;
Angular Service - mostly if you need to programmatically add or manipulate tooltips from the TypeScript code, eg. from within the functions of other components or services.

Tooltips above charts - potential place where you can consider implementing tooltips as a components

Creating Tooltip Directive in Angular - step-by-step recipe

Ok, so let's start from the short todo list with the steps required to build our reusable tooltips:

Create a tooltip component with a template;
Define tooltip background and other styles;
Create a tooltip directive;
Add basic tooltip logic;
Wrap it up in the tooltip module;
Give it a test ride!

And here is a list of necessary ingredients for our Angular tooltip directive recipe:

1 component - to define a template and a style of our tooltip;
1 directive - to attach tooltips to HTML elements;
1 module - to wrap it all up and make it reusable.

Component, directive and a module?! You mentioned only a directive before! Yup, you got me! I did cheat on you, but just a little. You can actually achieve all of that with just an Angular directive. But having a component inside a directive (kind of) gives us a more convenient way for styling, and a module will help us to wrap it up and keep our code clean. So apologies, but I had good intentions 🙈

Note: you will find the whole code from this tutorial in our repository: https://github.com/accesto/angular-tooltip-directive

Step 0 - set up an Angular project or use your existing one

For those of you willing to reuse your existing project, just skip to step 1. but if you want to start from scratch, please open your favourite IDE, and in the terminal type in:

ng new angular-tooltips-tutorial

And follow the standard installation process of a fresh Angular project. After the project is up and running, replace the contents of app.component.html with a single button:

<button>Do something</button>

Or, with a cat icon.

Step 1 - create a tooltip component

Let's start by generating a tooltip component via Angular CLI:

ng generate component common/ui/tooltip

I like to keep all the common UI building blocks (like buttons, tooltips, labels etc.) in app/common/ui/directory, but of course, feel free to adjust to your preferences.
Our tooltip component will actually be just a nice wrapper for a template and some CSS, no fancy logic required, so tooltip.component.ts can be as simple as:

import {Component, OnInit} from '@angular/core';

@Component({
  selector: 'tooltip',
  templateUrl: './tooltip.component.html',
  styleUrls: ['./tooltip.component.scss']
})
export class TooltipComponent implements OnInit {

  tooltip: string = '';
  left: number = 0;
  top: number = 0;

  constructor() {}

  ngOnInit(): void {}

}

Later we will add some customisation, but for now, the only difference from an empty component boilerplate are three properties - tooltip, left and top. These will keep a tooltip text and position (tooltips will be placed globally within the browser window and we will be using position:fixed for locating them).

In the template, we just need to display tooltip text and attach its location to the left and top properties of a component, so HTML content of tooltip.component.html would look like this:

<div class="tooltip"
     [style.left]="left + 'px'" [style.top]="top + 'px'">
  {{tooltip}}
</div>

Simple enough, isn't it? Let's now add some basic styles to make template content look like an actual tooltip.

Step 2 - define tooltip background and other styles

Here is an exemplar styling with a black background, white font and some rounded corners, but feel free to make it your own:

.tooltip {
  position: fixed;
  background-color: black;
  border-radius: 4px;
  color: #ffffff;
  font-family: Arial;
  padding: 3px 6px;
  font-size: 13px;
  margin-top: 5px;
  transform:translateX(-50%);
}

As already mentioned, tooltips will work globally, thus position: fixed. Last line with transform:translateX(-50%) will ensure that tooltip self-positions itself horizontally.
You may also want to define some max width or z-index, but I will leave that with you. Right now, let's maybe just add a nice triangle indicating an anchor point:

.tooltip {
(...)
  &::before {
    content: '';
    width: 0;
    height: 0;
    border-left: 5px solid transparent;
    border-right: 5px solid transparent;
    border-bottom: 5px solid black;
    position: absolute;
    left: calc(50% - 5px);
    top: -5px;
  }
}

So the overall tooltip will look like this:

As for now, we aim to display the tooltip below the HTML element, but in part 2. of this tutorial I will explain how to add some additional usage options - including tooltip location/direction, show delay or closing time. But first, let's finally create an Angular Tooltip Directive.

Step 3 - create a tooltip directive

Directives can be created via Angular CLI in the same way as components:

ng generate component common/ui/tooltip/tooltip

Mind the additional /tooltip in the path, as we want our directive to be generated in the already existing folder with a component.

Now, let's declare, inject and import a few objects that we will need inside our directive:

import {TooltipComponent} from "./tooltip.component";

@Directive({
  selector: '[tooltip]'
})
export class TooltipDirective {

  @Input() tooltip = '';

  private componentRef: ComponentRef<any> = null;

  constructor(
    private elementRef: ElementRef,
    private appRef: ApplicationRef, 
    private componentFactoryResolver: ComponentFactoryResolver,
    private injector: Injector) {
  }
}

We start by importing our tooltip component class, as we will create its instance (via component factory) every time we want to show a pop-up tip to your users. We also need a few objects to be injected into our constructor:

elementRef - we will use it to access the HTML element on which we place the directive tag, eg. a button or a link, to check its position in the browser window;
appRef - reference to a whole app, that will allow us to inject our tooltip to the application HTML content globally;
componentFactoryResolver - that will provide us with a factory for creating our TooltipComponent programmatically inside the TooltipDirective code;
injector - that will provide Angular dependency injection for our TooltipComponent.

Then, we declare a componentRef property, to store the reference to a TooltipComponent, which we will be instantiating via the factory.

Remember also to provide a meaningful selector name for the directive. I just used a [tooltip] for convenience, but you can name it eg. [appTooltip].

Then, let's define an attribute that we will use to pass as an @Input() to our tooltip. Right now we just need a tooltip content, so you can name it simply a tooltip or something like tooltipText.

Again, for convenience, I stuck with the tooltip as it allows me to simplify the syntax, and use the directive easier. So instead of:

<div appTooltip [tooltip]="...

I can skip the selector part and simply write:

<div [tooltip]="...

That is of course, convenient, but may sometimes cause you trouble if a tooltip property conflicts with some other directives you may have, so watch out!

Step 4 - add basic tooltip logic

After having all the groundwork done, let's implement some tooltip logic. We will start by creating an actual tooltip on hover, or more precisely onMouseEnter.

@HostListener('mouseenter')
  onMouseEnter(): void {
    if (this.componentRef === null) {
        const componentFactory =
              this.componentFactoryResolver.resolveComponentFactory(
              TooltipComponent);
        this.componentRef = componentFactory.create(this.injector);
        this.appRef.attachView(this.componentRef.hostView);
        const domElem = 
              (this.componentRef.hostView as EmbeddedViewRef<any>)
              .rootNodes[0] as HTMLElement;       
        document.body.appendChild(domElem);
        this.setTooltipComponentProperties();
    }
  }

This method will be listening (thanks to @HostListener) to mouse pointer events relative to the DOM element, on which we have applied our tooltip directive. Event mouseenter is emitted each time the user's cursor starts to hover above our DOM element. When that happens, we first check if our tooltip does not exist yet (using its reference this.componentRef) and if not, we will move on with its creation:

First of all, we need to use the resolveComponentFactory to get the factory that can manufacture our tooltip component;
Then, we use it to create the component, passing the dependency injector;
Next, we attach our component to the virtual DOM of the whole app, via the appRef;
We also attach it to the real DOM via a standard document.body.appendChild;
Last but not least, we define and invoke methods to set up the position and title of our tooltip.

This method for setting up the properties would like this:

private setTooltipComponentProperties() {
  if (this.componentRef !== null) {
    this.componentRef.instance.tooltip = this.tooltip;
    const {left, right, bottom} =           
          this.elementRef.nativeElement.getBoundingClientRect();
    this.componentRef.instance.left = (right - left) / 2 + left;
    this.componentRef.instance.top = bottom;
  }
}

Method description is quite straightforward:

Access to this.componentRef.instance allows the use of an actual instance of our component so we can set up its properties like tooltip text (I did access component properties directly, but I encourage you to define some setters instead);
getBoundingClientRect() - allows us to get the HTML element location and based on that calculate the tooltip coordinates relative to a browser window.

That is how we handle hover, now it's time to take care of tooltip hiding:

@HostListener('mouseleave')
  onMouseLeave(): void {
    this.destroy();
  }

  ngOnDestroy(): void {
    this.destroy();
  }

  destroy(): void {
    if (this.componentRef !== null) {
      this.appRef.detachView(this.componentRef.hostView);
      this.componentRef.destroy();
      this.componentRef = null;
    }
  }

There are two situations in which we have to make sure that our tooltip hides: when we hover out (mouseleave event), and when the element on which we applied our angular tooltip directive is destroyed (ngOnDestroy).

And... that's it! Let's only wrap it up and we are good to go.

Step 5 - wrap it up in a tooltip module

Again, we will use the Angular CLI:

ng generate module common/ui/tooltip

And inside the module, we will declare our component and directive, and will export our final Angular tooltip directive:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import {TooltipComponent} from './tooltip.component';
import {TooltipDirective} from './tooltip.directive';

@NgModule({
  declarations: [
    TooltipComponent,
    TooltipDirective
  ],
  imports: [
    CommonModule
  ],
  exports: [TooltipDirective]
})
export class TooltipModule { }

And... done. Let's now give it a test ride.

Step 6 - give it a test ride!

To use tooltips we just have to add our TooltipModule in app.module.ts:

...
import {TooltipModule} from './common/ui/tooltip/tooltip.module';

@NgModule({
    ...
  imports: [
    ...
    TooltipModule
  ],
    ...
})

And we are ready to apply the directive like this:

<div class="cat-icon" [tooltip]="'Meow!'"></div>

or for a button:

<button [tooltip]="'Some explanation'>Do something</button>

And that was it - you can now hover above your button (or a cat 😺) and see how our tooltip appears:

How can we improve our Angular tooltips?

That was just a very basic tutorial on building your own angular tooltip directives. Bear with me and wait for part 2. in which we will extend this with many useful customisation and usage options. Part 2. will include:

Tooltip hide delay / show delay;
Tooltip position: above/below/left/right;
Dynamic tooltips that follow the mouse cursor;
Tooltip themes eg. dark vs tooltip background;
Default options & default values like default delay;
Tooltip showing and tooltip hiding animations;
Support for touch devices / mobile devices.

Cheers! 🍺

Making sure your website won't crash again

Piotr Gołofit — Fri, 17 Jun 2022 06:55:26 +0000

In my previous blog post, I wrote about situations when an increase in user traffic could cause your website a lot of trouble. Unexpected popularity, instead of bringing you new customers, could cause the web services to go down. Today I would like to share with you a story from my own experience, a lesson learned from the spectacular crash of a popular startup. How did it happen? How did it recover? And how this spectacular disaster hardened the website and made it ready for the future?

A successful startup gaining traction

SzukamLapka is a very popular polish website that advises on purchasing laptops. It helps both IT newbies, and more tech-savvy customers as well. Its AI-driven algorithms review specs, benchmarks and offers to "understand" the industry and generate personalized rankings of the best gear.

Advice on purchasing laptop for non-tech and more tech-savvy customers

As Accesto, we have been their partners since early, MVP stages of SzukamLapka. This year they are launching a global version under the brand NotebookRank, but a few years ago, they were just a local startup, growing and gaining traction on a polish market. But in the late Monday evening of August 2017, this growth got out of control...

Surviving the hug of death

Almost every country has its equivalent to Reddit or Digg websites - places where users share, rate, and discuss useful links. In Poland, it is Wykop.pl, and on that day, someone who considered SzukamLapka to be very useful shared this knowledge with Wykop users. And it wasn’t the only person who found the named service worth using...

In the first hour after being mentioned the number of visitors doubled, but that was just a beginning. The exponential growth continued for the next 5 hours, reaching almost 10,000% late evening. That is a hundred times more users than usual!

Google Analytics: 1,000% increase in day-to-dday traffic, and 10,000% in the peak!

Usually, it is called a Reddit Hug of Death, or a Slashdot Effect, and in Poland... a Wykop Effect. It derives from the names of popular websites that caused many other sites to crash due to the abrupt increase in short term traffic.

So what happened?

Probably you won't be surprised if I tell you that the website crashed. But, to be honest, we were a little bit surprised back then. The website was already prepared to handle quite high volumes of traffic. It was optimized and performed well. Even when we did load testing with 20× more users than on an average day, all the rankings were generated in under 1 second. But sometimes you can't spot the bottlenecks until you see them stuck.

So what may be the bottleneck of a website that displays laptop rankings? The thing is that it isn’t just a simple website. Like most of the modern digital products, it is a complex web application, a multi-layer platform that consists of many services. And the bottleneck emerged between two of such services. The one that does all the complex calculations, and the other that uses these bare technical data and makes them more human-friendly. The question arose, why even though these two were connected via a robust and lightspeed API, the problem occurred?

Both services were performing very well, but sometimes the connection between them was lost for a few short milliseconds. And that was the part that we did not take into account. Although this was a very short break in communication, one of the services, instead of retrying to connect, kept hanging for around 3 minutes. We didn’t notice it in advance as it happened only once every few thousand page views. And of course, we had a few services like this working in parallel. So if one user waited too long, he could easily refresh the page and get the results immediately from another non-hanging service.

But on that day, the volume of users was so high that this quite rare situation of stuck service happened on all the services, and users started to get 504 errors - indicating that the server did not respond in time. The site went completely down.

Solving the problem

The temporary solution was quite simple. When we diagnosed the problem, we quickly increased the number of available services and restarted all the stuck ones. We had to repeat this few times, as new services kept hanging. But in general, that temporarily solved the problem and allowed us to survive till the morning.

The next day, we started by making sure that last night's nightmare won't happen again. We did it in 4 steps.

Step 1: adopt the fail-safe approach in your web application

We already knew that there could be temporary connection issues with the API, and to handle this, we added proper timeouts and retries. So if the connection is lost, service does not wait long, and after a second or so, tries to connect again. And there are few attempts, each with slightly longer timeouts (to get the response even if the network connection is slow for some reason).

According to Murphy's law, if something can fail, it will fail, and it is true also for web applications. It is good practice to take potential failures into account and make web apps ready for them by design. This is known as a fail-safe approach and is especially important if you integrate with some external, third party API’s - which may not always be available, or behave in the way we expect.

Step 2: make sure you calculate same things only once

Although the connection with the API should no longer cause the trouble, we knew that this was the most compute-heavy part of the platform. So the fewer requests are sent to that API, the better the website performance would be. We used Blackfire.io to check how often the web app uses the API and we got interesting results. We noticed that the homepage, the most frequently visited page, used the API twice per each view. Why would a rather static page even require any API calls?

Ranking sneak peak in header was calculated on every page view

The reason was that on the homepage, there was a small sneak peek of the ranking, to engage users. There were also a couple of statistics shown, as the total number of laptops or offers analyzed. But how often did these numbers and results change? Every few hours. And how often did we calculate them? Every single page view. Huh. Adding an HTML cache for the whole homepage worked like a charm, making it just a static HTML resource, that can be served by servers in a quite effortless way.

Blackfire is a very good tool that helps to find bottlenecks. To learn more, make sure to read our recent blog post “My homepage is slowing down” in which our developer describes how he reduced page loading time by 93% in just 4 hours of work.

Step 3: learn your user's behavior and use it to plan the performance

Another optimization became easy when we analyzed data from Google Analytics. SzukamLapka generates personalized rankings based on the individual needs and preferences of the users. But according to Google Analytics, most of the users go for the predefined presets, like gaming, office, or mobile laptops. So why generate them for every user separately? Adding a Redis cache for most frequently selected rankings reduced the computations by almost 70%.

Step 4: use CDN to cache your static resources

Last but not least - we added Cloudflare. It is a service that provides an additional cache layer in front of the whole website and distributes all its static resources in CDNs. It makes the assets, like images or scripts, highly available for users, and light for the server.

Cloudflare reduced bandwidth by 60% and page load time by 80%

Adding Cloudflare saved around 60% bandwidth traffic, making the website significantly lighter for the server. At the same time, the user experience improved thanks to the reduction of the total load time to less than 1 second! To learn more about caching with Cloudflare, check the blog post of our CTO on "Top 5 hacks to fix slow web applications".

Fast forward

Thanks to this lesson learned, the website was adjusted, and right now can handle a significantly large number of users. After a few years SzukamLapka is playing an important role in consumer decision making in Poland, generating millions in revenue for its partners. This year, SzukamLapka is launching its global version in multiple countries around the world. Thanks to the lessons learned, it is prepared to become popular in the new markets.

Current version requires less than 1 second to be full interactive!

How about your web application?

The story of the SzukamLapka startup can happen to almost every online business. If you want to check how your web application can be hardened just drop me a message. At Accesto we look after, monitor, and improve web applications to make sure they are secure, scalable, and ready for growth.

Let us help you

Optimizing website? Careful with lazy loading!

Piotr Gołofit — Thu, 05 May 2022 10:02:30 +0000

A few weeks ago I was asked if Accesto could help to optimize a popular online store selling natural cosmetics. Of course we can! I thought. That is what we do for a living, we improve existing web applications like SaaS, marketplaces, or eCommerce sites. Thus I thought it would be an optimization like every other. But it wasn’t.

Quick wins for website speed

Although every online product is unique, they usually struggle with similar web performance pitfalls. Non-optimal database queries, poor caching, too large images/resources, or unused imports, to name a few. Usually, there are a few things that can be fixed relatively quickly and will result in quite a speed boost. Our CTO recently gathered such tweaks for you in his blogpost on top 5 hacks to fix slow web applications.

Top performance, which will hold the exponential growth of users, cannot be achieved overnight. But if your website is slowing down, and you haven't yet put a lot of effort into its optimization, there is a high chance that it can be refined in a quite reasonable time. Like in one of our recent stories where we managed to decrease website loading time by 97% in just 4 hours of work.

Initial PageSpeed results for online store selling natural cosmetics

The case of natural cosmetics eCommerce seemed similar. The store owner sent me an email on Friday morning with the Google PageSpeed Insights report. It evaluated the overall site performance on 61/100 for desktop, and 42/100 for mobile. Not a tragedy, but indeed a lot of room for improvement. Great! We will apply a few quick tweaks that will speed up the website and I will have good news for a customer even before the weekend!

Let’s start with a website audit & checking Core Web Vitals

We already knew the overall score for this website - our starting point for optimization. This score is a composition of 6 metrics evaluated by PageSpeed, which for that particular site presented like this:

](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/50jualml4g4hqdi74z7f.jpeg)

Quick look at the metrics and we see that 4 out of 6 metrics look fine (Web Vitals), but the remaining two: Speed Index and Largest Contentful Paint (LCP) seem way too high. Understanding these metrics helps to decide where we shall start our optimization, how much we should improve, and whether we can find some low-hanging fruits. Each of these metrics has a different weight (importance). To see how exactly they influence the overall score you can use the scoring calculator.

Although PageSpeed evaluated both SI and LCP as poor ones, LCP has a higher weight (25%), so improving it will have the highest impact on the overall score. LCP is one of 3 important metrics introduced by Google, called Core Web Vitals. Ok, but what exactly is this LCP? In short - it is the time at which the largest visible part of website content is painted. This content could be an image, a large block of text, or any other element that occupies a significant part of the screen when the website loads. And the faster this element is displayed to the user, the better.

Knowing that, we could assume that perhaps some product image or banner is too large, not scaled properly, or maybe not compressed. Or maybe images are served by PHP and not cached? Few basic checks should show us what is going on.

We used a Lighthouse tool built-in Chrome web browser to profile the website. We were looking for any performance pitfalls, but the audit results were… surprisingly good! The site wasn’t performing that bad at all! Server response time was quite decent, images were served in a modern format and with proper sizing. All the site assets were properly optimized and served with proper cache policy. They even used some of the Progressive Web App capabilities to make the site work smoothly.

Lighthouse built in Google Chrome Developer Tools can be used to audit the website performance

Ok, so maybe it was a traffic related issue? Maybe site speed is good as long as the number of users using it is low? Worth a try. It is quite a common situation, many websites are tested only on a small number of users. When the user base grows website starts to clog. More on that topic you can read in my post on why new users can kill you web application. I did a few checks with the website load testing tool k6.io, but nothing, still a decent response time.

We also dug into the code to do some checks, but it only confirmed what was already obvious to us. Someone already did a great job to optimize this website. We weren't asked just to do the basics, they know how to do that themselves. We were asked because none of the popular tweaks worked. Great, finally some challenge!

Profiling the website performance

It was a time to dive deeper and do a step by step analysis. First of all, we had to figure out which site element was taken to calculate the LCP. Performance tool built-in Google Chrome shows a precise timeline of all the elements requested, loaded, and painted. It also indicates moments when LCP and other metrics are measured.

Analysis of this timeline confirmed our assumptions - the Largest Contentful Paint element was one of the product images on the homepage. Why is this image displayed so late to the user? We checked the image format and size, and all looked good. Actually, the image itself was loaded in just 122 milliseconds. So why did this image appear after almost 6 seconds if it loads in just a fraction of that?

We analyzed the timing of that particular image, and what surprised us was that it started to load after 5.7s since the website was requested. But why? Server response time was decent and all images should begin to load as soon as the browser receives the HTML from the server, right? Well…

Lazy loading done wrong

The title of this article already revealed the diagnosis - yes, it was a lazy loader that delayed fetching that image. But why? Isn’t the lazy loader one of the most common mechanisms that improve the website speed?

Lazy loader prevents images from being fetched if they are not in the current viewport. This minimizes the amount of data transferred in situations when only part of the site is seen by the user (eg. user views only the top of the page). Usually, it is good and makes the website load visibly faster. Usually...

Unfortunately, it also has a side effect that not every web developer is aware of. The lazy loader is simply a javascript code, that checks the image position and calculates whether it is in the current viewport. But this means that before the image is fetched, the web browser has to fetch the Javascript code and run it. The user won’t see the image until Javascript decides that he should see it. And that causes a delay.

And of course, there are many ways to implement the lazy loader so that delay is minimized. But in our case, the code responsible for lazy loading used an external, third-party javascript library that had to be fetched first. And what is more, this code was implemented in an onload event handler, which means that it was executed only after all website elements finished loading - including styles, fonts, scripts etc. And that all took 5.7s. It's quite a long time to decide if an image should be downloaded or not, isn't it?

Results of website optimization

There are many ways to solve this problem. We could get rid of the dependency on the external library or execute the lazy loader earlier than in onload. But the quick fix was to simply switch off the lazy loader for images that are always seen above the fold (the portion of the webpage that is visible without scrolling). This simple solution took just one line of code and did a job. Just see how the website speed improved:

It took us a few hours to find the cause of the poor LCP and finally add this single line of code. Website optimization is usually not about coding, it is analytical work of searching, digging, and investigating. Of course, this wasn’t the end of the optimization, still room for improvement. But we were surprised how much Core Web Vitals score improved with a simple fix in a lazy loader. This made me curious so I also checked other popular eCommerce websites and I was surprised. Many of them did have the same issue! Seems that lazy loader is seen as a great, out of the box solution for optimization, but very often added carelessly. And adding it too quickly (too lazy?) may actually harm the overall site speed. So be careful and don’t add stuff to your site just because everyone does it!

5 tools for Core Web Vitals to measure and improve website UX

Piotr Gołofit — Thu, 14 Apr 2022 09:16:35 +0000

Core Web Vitals are components of web analytics that belongs to Web Vitals. Their primary purpose is to improve the experience of website visitors. They apply to web pages displayed on desktop and mobile. The goal of CWV is to examine the page load length and accessibility before and after rendering. For website owners, high scores on these metrics influence the popularity of those sites by Google's algorithms. The friendlier a site is, the more willing users are to use it, which translates into a better ranking position on the search results page. In that case, you should learn about 5 tools to check and optimize Core Web Vitals.

How to measure Core Web Vitals metrics?

Core Web Vitals is a topic we introduced in a previous blog post. However, as a reminder. The metrics in question take into account:

LCP - Largest Contentful Paint (time to render largest element on site)
FID - First Input Delay (delay of the first action)
CLS - Cumulative Layout Shift (page layout offset)

LCP assesses a page's loading performance, focusing on the loading time of the biggest, main element (eg. blogpost cover photo). However, FID is the period during which visitors can engage with the website. FID is a statistic that counts keystrokes, taps, and clicks as input events. Thus, both of these indicators can be measured statically.

CLS is a statistic that assesses a website's visual stability. The amount of apparent shifts during page loading has an impact on the total score. Hence, it stands out from other indicators; its measurement is done dynamically because the current shift of the page is taken into account. So remember, when comparing the results of CLS measurement, to constantly compare them in the same fragment of the page during its actual use, and not during the static loading.

If you're curious about a specific example of optimizing the website of a popular natural cosmetics store, you can follow our work here.

Tools to check and optimize Core Web Vitals

Although Web Vitals are a relatively recent development in aspects related to user experience, many tools or plug-ins are now available to help generate analytics. Google's principal web developer tools currently support Core Web Vitals measurement, making it easier to detect and address user experience concerns.

Chrome UX Report (CrUX)

Chrome UX Report (CrUX) is a public collection of real-world data showing the user experience when visiting websites. All of the data collected in CrUX comes from users who have consented to download data in specific areas. By actually measuring site activity, it is possible to verify the actual Core Web Vitals indicator data.

Google Chrome User Experience Report data on BigQuery is a collection of details about the output for CWV and is available in monthly snapshots.

The CrUX API, on the other hand, thanks to its daily update, allows you to investigate the source or URL and segment that data by various factors.

The most recommended way to calculate how visitors perceive your site is to measure its performance in the field as users load and interact with the page. This type of measurement is commonly referred to as Real User Monitoring - or RUM for short. Even if you don't have RUM on your site, CrUX can provide a quick and easy way to evaluate Core Web Vitals.

A tool to visualize data, for example, based on reports like CrUX, is Data Studio. It allows you to create dashboards based on source files and thus capture trends in user behavior.

Google Search Console

Based on actual data from CrUX, Search Console's Core Web Vitals report may help you discover groupings of pages on your site that want improvement. The performance of URLs is divided into three categories: metric type, status, and URL group (groups of similar web pages).

LCP, FID, and CLS are three Web Vitals indicators used in the report. A URL is removed from the account if it does not contain the required reporting data for these metrics.

PageSpeed Insights

With PageSpeed Insights, it is possible to get both lab and field site performance. The PSI tool provides data on what site visitors' experience is like on both mobile and desktop devices. The PSI report contains information about meeting thresholds of adequate user experience, which is indicated by passing or failing Core Web Vitals assessment. The result of each analysis is a set of recommendations that should be implemented to improve the indicators (using Lighthouse).

Lighthouse

Lighthouse is an automatic website audit tool that assists developers in diagnosing issues and identifying ways to improve their sites' user experience. The tool provides lab data of the metrics. Two of them - LCP and CLS - are lab implementations of Core Web Vitals and allow you to draw diagnostic conclusions about the performance score calculation. The third metric in Lighthouse is TBT (total loading time), which correlates strongly with the FID field metric. Implementing the changes recommended in the Lighthouse report allows you to optimize and improve the user experience of your site visitors.

Lighthouse is automatically installed in all versions of the Google Chrome browser as a part of Chrome DevTools (version 60 and above). You need to right-click and choose "explore" and then go to the "Audits" tab.

It is also possible to install a plug-in for Chrome. It works analogously. The main difference is that you launch it from the top right corner of the browser (it's a bit more convenient). The principle of operation is the same.

Lighthouse is worth using in conjunction with the "Performance" tab, where it is possible to track the total page load so that step by step, you can catch possible elements to optimize.

Chrome Web Vitals Extension

Web Vitals extension is dedicated to the Google Chrome desktop version. It works great in the early diagnostic stages when it is possible to catch basic errors. The extension is available to install from the GitHub repository.

As of September 2021, Google Analytics does not have web vitals tracking, but with the library's help from GitHub, you can send this data as events to Analytics.

Your favorite SEO tool

Using the tools mentioned above dedicated to Core Web Vitals should give you a complete picture of the state of your sites in terms of UX. However, SEO tools also play a significant measure. When it comes to rankings, it's always better to optimize your site from multiple angles rather than just one. So let's look at how popular SEO tools enable you to optimize for Core Web Vitals.

SEMrush

SEMrush is one of the most preferred cloud SEO tools by various companies. Thus, in order not to lower its popularity, it has been customized for Core Web Vitals.

After performing a general audit of a given site, it is necessary to select On Page & Tech SEO > Site Audit, choose the domain to be analyzed, and then select the type of user agent. Once you have the report, you will have a graphical representation of the current state of CWV.

It's worth reminding that SEMrush doesn't use Google's API and gets all the lab data from Lighthouse. Therefore it's impossible to get the FID report. While SEMrush works well for internal use, it is impossible to export the report. The only way to present the statistics to website owners, for example, is to take screenshots. SEMrush, in its statistics, shows only data for the Core Web Vitals page. Thus it is a tool that supports or offers a slice of statistics for Core Web Vitals.

Screaming Frog

Screaming Frog is a tool that allows you to audit your website for all aspects of SEO thoroughly. It is also possible to verify CWV coefficients. For this purpose, data is taken directly from Google; downloading Google's API key makes it possible to check up to 25,000 pages per day. The report of a given website in Screaming Frog contains a complete set of recommendations for better domain optimization.

The inability to create an aggregated site speed report is one of the drawbacks of this tool. However, if you need one, it is necessary to transfer the information to Excel and create a table manually. However, it is possible to download reports with Page Speed optimization options and submit them to developers to implement the recommended solutions.

WebSite Auditor

WebSite Auditor is an SEO measurement tool, mainly dedicated to desktop devices. If you have ever used it, you know that a large amount of information to process is an ideal environment to work in. WebSite Auditor reports on over 80-page speed metrics and uses Google's API to download the data, so there are no discrepancies in the statistics provided by the two tools, and the analysis is automatic.

WebSite Auditor allows you to verify all addresses linked to a single site in a single analysis. Hence there is no need to prove each URL as with PageSpeed Insight or SEMrush.

Unlike the previously mentioned SEO tools, WebSite Auditor allows you to create a bulk Core Web Vitals analysis report in CSV format. Thus, this tool will work great if the information you make needs to be frequently sent to clients or other teams.

Is it worth it to measure Core Web Vitals?

Measuring Chrome Web Vitals is a must if you want to rank properly in Google searches. However, don't forget that CWV is not the only metric that affects your domain data. Google also considers mobile-friendliness, HTTPS, secure browsing, and non-intrusive interstitials in its analysis. However, optimizing Core Web Vitals is beneficial, even if the ranking impact turns out to be lower than expected because it affects user experience. Also, visitors are more likely to navigate the site if you reduce various aspects that hinder them. And organic traffic is still one of the main factors considered in Google's analysis.

How Docker reduces development costs?

Piotr Gołofit — Thu, 07 Apr 2022 13:18:43 +0000

Docker is a great tool and in recent years became almost a must-have for many development teams and projects. Why? For many reasons, which I share in detail in one of my previous posts. Today I would like to focus purely on one aspect… money.

Can Docker save my money?

TLDR; Yes, it can.

But let’s see how, and more importantly, how much.

To do so, I would like to introduce you to an imaginary project called RevoCRM. I will use it as a case study, to calculate the impact of Docker on software development costs. Talking about money is always a delicate topic, so I won’t share the details of a particular project, but rather a composition of my experience from a couple of projects I had a chance to work on.

Let’s say that RevoCRM is a gaining popularity CRM tool, for a small-medium size business. It is distributed in a SaaS model and has ~5,000 active subscriptions globally, mostly in the US and Europe. Although RevoCRM is an Amsterdam-based startup, its development team is fully remote and consists of developers from different countries, mostly from eastern Europe.

Currently, RevoCRM uses Docker both for the development and as a part of the hosting infrastructure. But it wasn’t always like that and in this study, I will estimate some of the costs saved thanks to Docker. I will consider the following:

costs of employee churn;
costs of everyday development;
costs of testing and quality assurance;
costs of introducing infrastructure changes.

Let’s see in detail, how much can be saved thanks to Docker.

How Docker reduces the costs of employee churn?

Introducing the new employee to the team is always a time-consuming process. This is especially true regarding software developers. Software products, like RevoCRM, consist of many different components like databases, services, third-party libraries, and other tools. Each newcomer, before writing his/her first line of code on the project has to install and configure all of these on the computer. Thanks to Docker, right now it is all reduced to one single command:

docker-compose up

But in the old, docker-less days of RevoCRM, it took between 4 to 5 days to make the whole platform up and running on a developer's computer. RevoCRM development team is fully remote and each developer has its favorite operating system and configuration. Thus the process was slightly different for each employee. But usually, it was a collaborative work of at least a few people, to help the new developer set up the project on his machine. On average, each new developer spent 36 working hours of his time, and additional 24 hours of other team members trying to help him, which results in 60 hours spent on the initial setup.

RevoCRM development team consists of 8 developers (6 back-end, and 2 front-end developers) and 2 testers. Their average employee churn rate is 20%, which means that every year they introduce 2 new team members. Knowing that the mean hourly rate of a single RevoCRM employee is €30, we can calculate the overall yearly cost saved thanks to Docker:

2 developers / year × 60 hours × €30 / hour = €3,600 / year

Not that much? Bear with me because savings start to accumulate quite quickly when the newcomer and his teammates start their everyday work on new features.

How Docker reduces the costs of everyday development?

Unfortunately, Docker won’t do the coding for you, you will still need developers in your project team 😉 But what Docker can do, is to ensure that whenever one of the developers introduces any changes to the project configuration it will automatically be available for other developers. Before the RevoCRM team switched to Docker, they were constantly struggling with changes in the technology stack. When a new integration, or a database, or some other service was added to RevoCRM, it did not work automatically for all the developers.

Sometimes a small change could prevent the whole team from focusing on their own tasks for a decent amount of time. Most fierce were the fights between back-end and front-end developers. Each side complained that the other one always adds things that do not work out of the box on their machines. Struggling with these technical issues took on average 5 working hours per month, for each developer. Introducing Docker helped to save:

5 hours × 8 developers × €30 / hour × 12 months = €14,400 / year

Docker clearly helps to introduce changes to the technical stack with fewer complications to other team members. But it can also make the change easier for the developer that introduces it. Instead of searching for manuals on how to install some new database server, developers can use one of the available templates (Docker Images) from a publicly available repository called Docker Hub. This can save a day of work every quarter or so.

8 hours × 4 quarters × €30 / hour = €960 / year

Docker helps to reduce the cost of coding. And what about further phases of the development process? Does it also bring some savings in the testing phase?

How Docker reduces the costs of testing and QA?

One of the most important advantages of Docker is that it ensures consistent behavior of software on all the machines. This is true for the developers’ computers, as well as for the test servers. Why is it that important? Because it significantly reduces the time of testing and quality assurance. Have you ever heard of the famous phrase “Strange, it worked well on my machine”? It is a very common issue. Testers blame developers for delivering faulty code but in many cases, that code actually did work on developers' local machines.

Before the RevoCRM team introduced Docker, almost 17% of all User Stories delivered for testing had to be rejected just because testers were unable to make them run and test properly. These Stories had to be then refined by developers, and once again delivered for testing.

The whole ping-pong process was taking approximately 2.5 hours per each problematic User Story delivered for testing. RevoCRM development team is actually divided into two smaller teams, each with 4 developers and one tester. And each of these teams has the capacity of approx. 10 User Stories delivered per month. So the savings in the testing process after introducing Docker looks like this:

2 teams × 10 US × 17% failure rate × 2.5 hours × 12 months * €30 / hour = €3060 / year

Also, the RevoCRM developers were able to better test features themselves, ahead of delivering these to dedicated testers. This was possible as Docker's setup made end-to-end testing simpler for them. Previously, backend developers focused only on introducing API changes but were not validating if these work well with the front end. This reduced overall issues and time spent on bug fixes by almost 10%. By then each developer was spending 20 hours per month on fixes and refinements. Thanks to Docker the time and cost savings were significant:

8 developers × 20 hours × 10% improvement × 12 months * €30 = €5760 / year

Development and testing savings add up to quite a sum, and there is one more aspect that Docker helps a lot with - the infrastructure.

How Docker reduces the costs of infrastructure changes?

Speaking of hosting infrastructure, Docker, combined with additional tools (like Kubernetes or Docker Swarm) brings multiple benefits. Ease of infrastructure management, ease of scaling… just to name a few. I won’t describe all these in detail as it would require a separate blog post. Instead, I will focus on two particular aspects: great portability and lack of vendor locking.

Not so long ago, the CTO of RevoCRM decided to improve their disaster recovery plan. This was perhaps inspired by the recent event that happened to the popular hosting provider OVH. One of their data centers went on fire and burned down completely, leaving a lot of their customers with data losses and services being down for a few days.

If it happened to OVH it may happen to everyone - he thought. And thus, he decided to have at least two hosting providers at a time. Fortunately, RevoCRM was already running on Docker and Kubernetes. Thanks to that, the process of recreating the infrastructure with a second hosting provider was not only possible (no vendor locking), but also was a relatively simple task (because of the portability of Docker containers). Instead of spending a week or so on configuration, the whole process took just around 3 hours! Although it was a one-time job, different infrastructure changes happen every few months, or at least once per year (especially if your start-up has plans on scaling). This particular change brought €2500 of savings. Instead of hiring an external consultant to do the job, the CTO managed to set up the environment himself. And now he can sleep soundly 😉

Summary of savings

Ok, time for the final answer on how much money can you save thanks to a Docker? Let’s summarize all the RevoCRM savings:

Over €30,000 saved each year thanks to Docker. It is approximately 5% of all yearly development costs of RevoCRM. Or in other words, free additional 3 weeks of development hours. Hours that can be spent on at least a few additional features that can be delivered to your end-users each year.

Will Docker reduce the costs also of my project?

Still not convinced that Docker would be a good solution for your development team? Although Docker is a very useful tool and may help you reduce development costs, there are of course some cases in which it won’t be the best choice. Make sure to read my previous post on When to use and when not to use Docker? to see if your project will benefit from Docker.

From my experience, many development teams complaining about Docker simply don't use it properly. In such a case, all the money you could save thanks to Docker may be the lost opportunity. Thankfully, our CTO decided to write a book on Docker optimization. In his book, Michal explains how to work with Docker images and containers to make the most of them. Make sure to recommend it to your dev team.

Technical Debt - the silent villain of web development

Piotr Gołofit — Wed, 23 Mar 2022 10:13:20 +0000

Over 4 years ago our CTO wrote a blog post claiming that technical debt is the number one reason why software development projects get derailed. Years have passed since, and I can say that he couldn't be more right. Although I see that business owners get more familiar with the term technical debt, it quite often plays the role of an elephant in the room. And in the long run, such stories rarely have happy endings. So if you don’t know what the technical debt is, or you do but you don’t think you should worry about this villain - better read further.

What is technical debt?

10 years of leading web development projects gave me the knowledge of how various technical decisions influence web applications development in the long run. I observed how hours of work invested in code quality and good software architecture enable future growth of software products and their business success. At the same time, I followed the stories of other products struggling to scale up and develop further due to all the shortcuts taken in the early stages of development.

The lesson is simple - the more hours you save by doing things quick-and-dirty today, the more difficult the product development will be in the future. All the shortcuts taken, all the savings on code or architecture quality, accumulate as a metaphorical technical debt.

Technical debt impact on productivity

Ward Cunningham, an author of that metaphor, highlighted its similarity to the financial debt and interest that you have to pay in the future. A technical loan, that you take out by saving some coding hours today, will make further development and product maintenance more difficult, time-consuming, and expensive. And that is the interest that you pay for cutting corners. But unlike financial, technical debt is way harder to measure and track, so it’s costs are often overlooked or neglected. Let’s see them in more detail.

What are the costs of technical debt?

Technical debt accumulates slowly, usually invisible at the beginning. Gradually making product development less efficient and thus more expensive. Like in a popular among software developers anecdote of a boiling frog. If placed in boiling water, the frog will jump out, but if it is placed in cold water and slowly heated, it will overlook the danger and may be cooked to death. And this is very true for the web applications, slowly boiled in a soup of technical debt, getting way too expensive to develop and unprofitable to maintain.

Anecdote about a boiling frog - metaphor for IT projects slowly boiled in a technical debt soup

We experienced it ourselves at Accesto when we had to shut down our own successful product a couple of years ago. It was a popular SaaS tool for the online gaming industry, used by the majority of hosting providers in Poland. Despite the great market traction, we had to discontinue its sales, when costs of development and maintenance outgrew all the profits. After years since we shut it down, we are still getting requests from people willing to pay for it. It was bitter, but a valuable lesson on the technical debt for us.

These days I see more and more web products struggle to grow due to the technical debt. The startup boom for web applications and SaaS products continues for over two decades now. Many of the products that made it to the market did it by taking technical shortcuts. The pressure to deliver quickly and within the budget has its side effects and now some of these products struggle with growing costs of technical debt.

Our main focus at Accesto is to help such products grow, by fighting technical debt and reducing its costs. Among such costs the most common are:

Decreased web development pace - slowed down by technical roadblocks, rework, hard to understand code, and focus on workarounds instead of efficient development
Longer time to market for new features - slow development and constant bug fixing makes it difficult to meet any deadlines for releasing new features
Expensive maintenance - finding and fixing bugs becomes more difficult, lack of automated tests adds a cost of manual testing work with every change in the code
Reliability issues and recurring bugs - fixing one bug leads to another
The increased cost of introducing changes - even small update may require changes in many places, that’s because code is tangled with unnecessary dependencies
Hidden performance defects - software that worked well for a few users starts to clog when the amount of data and number of users increases, app slows down
Higher uncertainty - more difficult to estimate and plan the web development work
Technology locking - poor code or architecture makes it hard to update current technology or migrate to a more modern one
Risk of security defects - old technology makes web app vulnerable to breaches, unreadable code makes it difficult to secure
Decreasing customer satisfaction - due to recurring bugs, poor performance, and a long time to market for new features, competition won’t miss that chance!!
Decreased development team motivation - everyday work becomes a constant fight with messy code, bug fixing, and trying not to break something
The increased cost of hiring web developers - poor availability and high cost of hiring specialists with expertise in old technology and willing to work with legacy code
Cost of knowledge transfer - lack of documentation and unreadable code makes it hard to understand the project and introduce new team members
Inability to respond to market opportunities - the cost of missed chances due to long time to market for all changes and features

Development hours wasted on on rework and fixing defects

If you see that your web development slows down, the number of bugs increases, or your dev team starts to complain about the code, do not neglect these symptoms! Further in this article, I will show you some ways of fighting technical debt. But before fixing things, let’s first make sure it won’t get worse. To do so, we have to eliminate (or at least reduce) the drivers of technical debt in your project.

Where does the technical debt come from?

“Don't overcomplicate it, just do the simplest!”

“No matter what, we have to publish it before black Friday!”

“Why is the estimate so high? It’s a simple feature!”

Do these or similar phrases sound familiar to you? Time and budget pressure are among the key drivers of technical debt. Code quality and deliberate planning simply stand in a way of such short term, more urgent goals. This forces developers to take the shortcuts and implement features in an easier, quick-and-dirty way. When pressure is high, even experienced developers take that path, usually with a hope that this code will be improved (refactored) someday. But will it?

Big ball of mud - a result of a quick-and-dirty development

Experienced developers are at least conscious when the debt is introduced. But another popular driver of technical debt is the lack of qualified specialists in the product team. Lack of certain skills generates hidden debt that nobody is aware of, which is very risky. This is why projects run by junior web developers may happen to be cheaper at the beginning but quickly lead to the roadblocks very expensive to overcome.

Some would also say that technical debt comes simply from the laziness of developers. Although it may be true in some cases, I would argue if it is that popular. It may be the case with junior developers, but the more experienced developers are, the more they like clean and well thought out solutions. I noticed that instead of cutting the corners they rather tend to overthink and over-engineer.

For sure there is one more catalyst of technical debt - a constant change in business goals and requirements. And in a similar way to time and budget pressure, it may lead even experienced team members to get off the track of deliberate development. The more thought a developer puts in good code design and implementation, the bigger demotivation when he has to throw it away when requirements change. If this happens very often, team members start to care less about the quality and long term impacts of the code they create. There is a lot of truth in saying that the only constant in IT projects is the change. But it is important to discuss all the business goals and underlying purposes with the development team. This will allow them to assess the required quality and foresee the probable changes. Otherwise, they may spend hours meticulously designing something that is just some proof of concept. At Accesto, we make sure that all developers know WHY do they implement particular featrues and that's maybe why they stay with us for many years.

Short term benefits of keeping the budget low while developing features quickly are hard to argue, especially in the early MVP stages of the software product. But like with finance, if you neglect the long term perspective and base your cash flow only on the liabilities, you will end up in the debt spiral, sooner or later. So should you avoid technical debt at any cost?

Should I avoid a technical debt at any cost?

The analogy of financial debt is very true here. Should you avoid any financial debts? If you can run and develop your business without taking out any loans then good for you. But in many cases to grow, to develop, you cannot avoid banks. You are not waiting until you save enough money to open a new production line. You take out a loan, you open a line, and you use the profits out of it to pay off the debt.

Paying off the technical debt accumulated in MVP stages helps to restore good development pace

Same is with technical debt, you accept it to make thighs faster. Especially in the early stages of the business, or when you want to test a new business opportunity. If you are not sure whether some product or feature will get the market traction it is usually a wise choice to limit the initial investment and cut some technical corners. As Neil Ernst mentioned in the Carnegie Mellon University field study, technical debt conceptualizes the tradeoff between the short-term benefit of rapid delivery and long-term value.

But when decide on that tradeoff, and deliberately accept technical debt, please remember that:

When you take a bank loan, you can’t forget about it. If you do, costs are even higher and you won’t risk that situation. But it is way easier to forget about the technical debt, as the interest rate and cost of code shortcuts are not that obvious. So remember, whenever you agree on some technical debt, do it considerably, note it, manage it, and pay it off. Better sooner than too late.
You can't take out loans over and over again and it is true for both finance and software development. If you borrow too much, next time your financial institution will deny lending you more. With technical debt, there is no special institution that will limit your liabilities. So listen to the development team instead. Do they complain about the code quality? Do they mention the refactoring? Talk to them, there is no one else to tell you when too much is too much.
All debts must be paid - simple as that. You borrow money to scale your business and pay off that debt later on. Same for technical debt. You release a new feature, you get more users, more revenue, and... you pay off the technical debt. It is always tempting to leave it as it is, do not improve that feature, just start working on another one. But that will lead to a metaphorical big ball of mud and trust me, it is not something that you want your web application to be.

Technical debt quadrant (by Martin Fowler) - different types of technical debt

Not all debts have to be avoided and in many cases a deliberate technical debt can have a positive effect on overall product and business development. But only if you are going to pay it off. But how to do it?

How to pay off the technical debt?

The only solution is to rewrite it from scratch - that may be a popular phrase that you will hear from software developers when they see the codebase of your web application. Don’t be surprised, developers usually don’t like working with old, legacy code, but love new, greenfield projects. Rewriting from scratch is of course one of the solutions to get rid of technical debt, but it is usually unnecessary and we discourage that approach. Although it significantly lowers technical debt, it freezes the product development for a long time and competition and users won’t wait.

Another approach is to continue the development of new features in the old codebase, but with a focus on refactoring. Creating a new module? Do it without taking any shortcuts and also improve parts of the application that relate to that module. This won’t freeze your development and will let you pay off the debt in smaller chunks.

Working with clients at Accesto, we usually implement a solution that goes slightly further. Instead of developing new features in legacy code, we create a new, separate codebase for them. All the new features are implemented in that new part, and the old code is step by step migrated to that new part. More on that approach, you can read in a blogpost of our CTO on possible scenarios of handling technical debt.

During the last 5 years at Accesto, we focused mostly on helping successful web applications to get rid of technical debt accumulated by years of growth. If you are not sure whether it is worth fighting debt in your software let me just mention two of our case studies:

One of our customers reached us when previous developers denied further work on his product, burdened by accumulated technical debt. The approach mentioned above turned into a 35% yearly debt reduction. Their legacy application evolved to highly scalable SaaS in just 2 years, with time to market for new features reduced by 87%.
And our recent story of accelerating SaaS growth by gradual improvements in web architecture. After 1.5 years of cooperation with Accesto, our customer won the Atlassian’s Codegeist 2020 contest for the Best app for remote working. Thanks to the new architecture, the module that won the contest was created in just 3 weeks. Something that would be impossible before.

I am glad that, although a couple of years ago technical debt made us shut down our product, we are now helping others to avoid such bitter decisions. If you are also looking for help, just let me know, we can verify how much debt is hidden in your web app and suggest the best approach to get rid of it.

What is Docker and why to use it?

Piotr Gołofit — Thu, 10 Mar 2022 08:19:05 +0000

What is Docker and what are Docker containers?

Let’s imagine you would like to build a website or a web application. What do you need to make your next Facebook, Youtube, or Twitter up and running? For sure you will need to develop some code, as it is a key part of every or web software. But the code on its own is not enough. Websites and applications consist of many additional parts, like databases, configuration files, runtime libraries, and other third-party software. Docker is a tool that allows you to take all the parts and bundle them together into one package, called the container.

But why would you like to close your application in the box? Because you can then use Docker to launch this box on any server (including cloud) or a local machine (eg. developers computer) you want. And it will run everywhere in exactly the same, predictable way. With no additional configuration, installation, and adjustments required for each environment you run it. Trust me, that will save you a lot of trouble, effort, and in the end - money.

Not convinced? And what if I tell you that you can use Docker to run many such boxes at the same time? That becomes quite useful if you want to build a scalable website or web application that can handle many users.

Let’s see what else Docker can do for you.

What are the benefits of Docker? Is Docker worth using?

1. Easily introduce new developers to your project

How quickly a new developer can start working on your product? Assuming he already has code on his machine, he still has to install some local server, set up a database, install required libraries, third party software, and configure it all together. How long does it take? From a few hours to many days. Even if your project has a good onboarding manual that explains all the steps, there is a high chance that it won’t work for every laptop and system configuration. Usually, onboarding a new developer is a collaborative effort of the whole team that helps the newcomer to install all missing parts and resolve all system issues.

And with Docker? With Docker all these manual installation & configuration steps are done automatically inside the Docker container. So it is as simple as launching Docker and running one command (docker-compose up), that will do all the work for the developer. No matter if he uses Docker on macOS, Windows or Linux.

This will requrie to create a Docker setup for the project first, but that is something you do only once and later everyone can benefit out of it ( see an example Docker setup for Symfony project ).

2. Make your app behave in a consistent and predictable way in all environments

Ever heard of a famous developers’ excuse “It worked on my machine”? The fact that something works on a developer's computer is not a guarantee that it will work on your server. There may be some library or a tool missing, or a mismatch in required versions of installed software. Each computer or server is different, and configured in a different way. Without Docker you have to set up each of the machines and system manually, and this is time consuming and error prone.

Docker solves this problem with bundling not only the code, but all the parts required to run the application or website. These parts are closed inside the Docker containers, which are isolated and independent from the outside world. And this makes them run in the same, consistent and predictable way everywhere. This means less time spent on fixing issues and more time spent on delivering new features.

3. Host your app wherever you want with no vendor locking

Website or web application bundled into a Docker container is similar to a stuff packed inside a freight container. Docker containers, same as cargo ones, are standardized, so most of the computers, servers and cloud (as container ship, freight trains, trucks) can handle them. This gives you a great flexibility on the hosting technology and provider.

You can start with a small and cheap server, and scale when needed into another machine or to the cloud. And what’s more, you won’t get stuck with one hosting vendor.

4. Flexible scaling of your app or website

Although using Docker won’t make your website or web application scalable out of the box, it may be one of the key ingredients of your software scalability. Especially if you use some cloud services like AWS or Google Cloud as your hosting solution. Docker containers, if built properly, can be launched in many copies to handle the growing number of users. And on cloud this scaling can be automated, so if more people use your website, more containers will be launched. Same is about downsizing, less users, smaller the bill for your hosting.

5. Easily compose your application with third party software

As mentioned before, Docker helps to bundle your code together with third party software inside closed containers. But it also provides a large repository (Docker Hub) of available templates (called Docker Images) that can be used by developers to create containers for your website or web application. This shortens the development process, because your development team, instead of starting from the scratch, can reuse the configuration already created by the docker community.

6. Track all the changes in your application components, not only code

Docker allows developers to define the whole environment around the code in a programmable way. So no more written or spoken instructions have to be executed by the human factor. No manual installation or configuration is required. No more guessing, and no more misunderstandings when one of the developers installed some library but did not bother to inform others that from now on it will be required to launch the application. Docker converts all these manual processes into the code. Code that is saved, tracked, and that will execute automatically doing all the installation and configuration on all developers' computers, as well as on the servers. And that saves a lot of development time.

As you see, there are many benefits of using Docker. But simple adding it to your project won’t bring you any benefits just out of the box. It has to be used property. Our free ebook on Docker optimizations and advanced techniques will definitely help with this. Make sure to recommend it to your development team.

How is docker different from Virtual Machines?

If you are not familiar with virtual machines (VMs), just skip that section. But if you do, you may ask yourself the question: how does Docker differ from VMs? These may seem similar at the first look because both Docker Containers and Virtual Machines are kind of boxes in which you can put some code and mix it with additional software, files and configuration.

But each virtual machine requires a separate operating system (like Windows or Linux) installed inside of it. And operating systems are not the lightest pieces of software. So if you have a couple of VM’s it may get quite heavy (both when it comes to the disk size and computing resources). Docker containers instead of having its own system, use the operating system of the computer/server on which Docker is installed. The whole magic of Docker engine is that it enables computer resources to the containers, as if each docker container had access to its own operating system.

In other words, each VM has its own cargo ship that carries it, while docker containers can be carried in bulk on one ship.

Is Docker free for commercial use? Who is the owner of Docker?

Docker was originally created by Solomon Hykes from dotCloud Inc. (later Docker Inc.) as an open source project and since it’s launch in 2013 Docker is available for free. In March 2017 the open source version of Docker was rebranded to Docker CE (Community Edition) and Docker Enterprise Edition (EE) was released.

Docker CE is still completely free to use, also for commercial use, and for many web applications will be perfectly sufficient. Core features and functions of both CE and EE versions are the same, both are updated quarterly, and both are available on a wide range of popular hosting solutions including cloud infrastructures - which gives freedom of choice without lock-in.

You may ask yourself, do I need Docker Enterprise Edition then? Docker EE has additional features for launching, managing and securing containers in a more efficient way. It is the same Docker as in CE, but surrounded with additional tools, services and with official support. This may simplify Docker management and maintenance if your application uses many different containers.

Can Docker make a pizza 🍕 for me?

To better understand Docker, let me leave you with one tasty metaphor.

Imagine you would like to open a pizza business. What do you need to start serving the best pizza menu (features) in town? First of all, you need an experienced chef (developer) to create pizza recipes (code) for you. These recipes (code) can be used to combine the ingredients (data) into a tasty pizza (application features).

But to run an actual pizza place, you also need some infrastructure. Building (operating system), storage compartments (database), well stuffed kitchen (frameworks) and various appliances (third party libraries). And of course you need an employee (runtime environment) with some cooking skills (programing language) to bake your delicious pizza (application/website).

And what if you want to open a chain of the restaurants? You can use the same pizza recipes, for sure. But to ensure the same pizza taste and quality you will have to carefully recreate all the infrastructure, resources and procedures as well.

And here comes the Docker. It allows you to write down not only the recipe for a pizza, but for the whole pizza restaurant franchise. But with one difference - instead of a stuffed building, you will get more like a recipe for a pizza food truck, that can be easily copied and placed in any place you want. And it will serve there the same tasty pizza your chef has initially developed. Enjoy!

Docker sounds like good solution for your project?

Want your team of developers dive into a Docker world? Make sure to show them our Docker Deep Dive free ebook on that topic. They will find inside good practices, tools and techniques that will help to make the most of Docker.

When to use and when not to use Docker?

Piotr Gołofit — Wed, 02 Mar 2022 10:32:03 +0000

If you are reading this post, you probably already heard about Docker. You may be wondering, why is Docker so popular? Is it just another hype word, or is it really useful? Will it bring you any value in the long term? Or will be gone in the next few years like many other fancy tools? And finally, should your development team start using Docker?

In this article, I will show you a few good reasons to use Docker, and a couple of examples where it may not be the best option. But let’s start by clarifying, what Docker actually is?

What is Docker?

In a nutshell, Docker is a tool that allows developers to bundle all the ingredients of software they create into unified boxes - called Docker containers. Key ingredient is usually the code, but most apps or websites won’t work without a database, configuration files, runtime libraries or other third-party software. Putting these together in a box makes it easier to launch the app on another developer's computer or the server. And because Docker containers are unified and independent from the outside world, the software built with them will work in a consistent, predictable way on each machine.

If you want to understand it better, make sure to check my previous blog post on What is Docker?. Knowing the basics, let’s see when you should consider using Docker in your project, and when not.

Good reasons to use Docker

From my experience, you should consider using Docker in your project if:

1. Your development team is not set in stone

How often do your development team change? Introducing new developers to the project always takes some time. Before they can start coding they have to set up their local development environment for the project - eg. some local server, database, or third party libraries. This may take from a few hours to many days, depending on the project complexity and how well is the project setup manual. Docker automates this setup & installation work so new developers can be productive from the first day. Instead of doing everything manually, they simply run one command that will prepare the development environment for them. This saves a lot of time, and the bigger is your development team and higher rotation, the more you will gain by using Docker.

2. Your software runs in different environments

I assume your software runs in at least two different environments - developers computer, and some server. Even in such a simple case, you can notice inconsistent behavior of your app between the machines it runs on. Something that worked on a developer's computer may not work on the server. And the number of issues grows with every new environment - like another server (test server vs production server) or simply another developer’s computer with a different operating system. Docker allows you to run the software in containers separated from the outside world, so your app can work in a consistent, predictable way in every environment.

3. Your software grows and consists of many bits and pieces

Developers add new libraries, services, and other dependencies to the software daily. The more complex becomes your software the harder it is to keep track on all its parts that are required for it to run. Without Docker, all the changes in the project setup have to be communicated to other developers and documented. Otherwise, their version of the code will stop working, and they won’t know why. With Docker, all the required components of the software are specified in Docker configuration files (like Dockerfile and docker-compose.yml). And if something is specified to this configuration it is automatically added for every developer working on the project.

4. You want your software to be scalable and handle more users

Want to scale your application to new markets or branches? Great! But will it handle the growing number of users? Docker won’t automatically make your app scalable but can help with this. Docker containers can be launched in many copies that may run in parallel. So the more users you have, the more containers you launch (eg. in the cloud). Before you do so, your software has to be prepared for running multiple instances at the same time. But if the scalability blockers are already removed, Docker containers will come in very handy to launch a scalable application.

5. Your hosting infrastructure may change in the future and you don’t want to be locked

Small websites and applications don’t require complex hosting infrastructure. But when a business grows and evolves, so do the server requirements. In the fast-paced business environment, web infrastructure needs to be flexible enough to adapt quickly. Both to ensure that your website won’t crash and that the costs of the infrastructure correspond to the actual needs. And because Docker containers are unified and very well adopted, they can be launched in almost any server environment. So when your needs change, your software can be placed somewhere else. So you won’t be locked by any hosting vendor or a specific type of infrastructure.

6. You do some proof of concepts and test new technologies for your software

Docker is quite useful if you want to experiment with different technologies. Want to adopt some new database, programming language, or other tools? Most probably there is already a Docker template for this (called Docker Image) created by a docker community. Docker Hub is a large repository of ready docker images for almost any technology you want to use. Just find the image you want and add it to your Docker configuration. No need for time-consuming installation or debugging compatibility issues.

If at least some of the above statements are true for your projects, you should probably give Docker a try. It can be useful for the majority of web development projects, but there are also some cases when it will not bring a lot of value. Let’s see some of them.

When to avoid Docker?

None of the below cases (except maybe the last one) automatically make Docker useless for your project. But if you hit any of these, you should rethink if Docker will be the best solution for your software development. Better think twice before adopting Docker if:

1. Your software product is a desktop application

Docker is very useful for web applications running on a server or console-based software. But if your product is a standard desktop application, especially with a rich GUI, Docker may not be the best choice. Although it is technically possible to build such an app with Docker, it isn’t the natural environment for running software with a graphical interface and it requires additional workarounds.

2. Your project is relatively small and simple

Docker is really handy if your software consists of multiple parts. It makes it easier to install these and keep a track of all the dependencies. But it does not come like this out of the box. Someone has to prepare the initial project setup for Docker (Dockerfiles, docker-compose.yml, entry points, etc.) and maintain it in the future. So if your app is relatively simple and does not require any additional tools or services, you may start without Docker. It can be added later on when your software grows.

3. Your development team consists of one developer

If your development team is simply a one-man-army, the benefits of Docker will be smaller. Docker helps to ensure that all the developers have access to all the necessary bits and pieces of the software they work on. So if someone adds software dependencies, everyone has them when needed. If it is just one developer, there is no such need. But even in this case, Docker may help, eg. if that person resigns and someone has to take over the project. But that can be handled with proper documentation instead. Docker simply automates this, but the fewer people in the team, the smaller the need for automation.

4. You are looking for a solution to speed up your application

Docker may speed up your development process significantly, but not necessarily your app itself. Although it helps with making your application scalable, so more users will be able to use it, the single instance of your app will usually be just a hint slower than without Docker. Fortunately, Docker containers are smaller than for example Virtual Machines and require much fewer resources. In most cases, the performance overhead of Docker won’t be visible for you, but if your goal is to boost the speed of your app, Docker itself is not the solution for that.

5. Your development team consist mostly of MacBook users

Speaking of speed, Docker has serious performance issues when running on macOS. These are related to how volumes are mounted, and the underlying osxfs filesystem. In short, if your app performs a lot of read/write disk operations (and almost every app does some) it may be very, very slow on Mac. So if your development team consists of Apple fans, Docker may not be the best solution. Fortunately, there are a few things that MacBook users can do to improve their experience with Docker. Our developer Krzysiek summarized them in his recent post - Docker on Mac - how to speed it up?.

6. Your team don’t know how to use Docker properly

Last, and maybe most important case when you should not use Docker. Docker can work like charm and significantly speed up the development process. But as well may become your nightmare, if it is not used properly. Very large Docker images that start up for many minutes. Difficult to debug issues that do not produce any useful logs. Security issues when using random, third-party Docker images. Developers that install dependencies on their machine and not in the Docker images. Docker configuration mixed with additional manual commands to be executed. These all can cause a lot of frustration, issues and in the end, may cost real money. So if your development team doesn't know how to use Docker properly, don’t use it just because everyone does.

So should my team use Docker?

Well, in most cases, yes. Docker, when used properly, can be beneficial quite quickly. And will work for most of the software products. Containerization, in general, is the natural next step in the software development industry and won’t disappear anytime soon. Docker may be replaced by other tools or next versions of Docker, but the general concept will remain. But as with every tool, Docker won’t help you if it is not used properly. So before your development team starts to complain about Docker, let them read our free ebook Docker Deep Dive - they will thank you later.