At HelloFresh (and like many other companies) we run a lot of different tasks on the front-end, and if we run them on the front-end we run them on the main thread. Running any task on the main thread will come at a cost, and you pay that cost for how quickly your app hydrates.

Front-end applications need to “hydrate” when you pre-render the HTML on the server. If you use next.js your app will do this out of the box for you. Hydration happens when the browser reads the HTML, loads the JavaScript, and the JavaScript needs to “attach” itself to the HTML to make it dynamic. Making this faster will improve almost all your core metrics.

Some of the tasks that we run on the main thread for initial hydration are:

• Providing context values to our entire application
• Bootstrapping third-party tooling (like AB-testing tooling)
• Bootstrapping metrics solutions
• Hydrating fetched server-side data
• Initializing legacy redux stores
• Hydrating all the visual components (the header, the content, the footer, etc.)

This list might not sound like much, but it can quickly add up. Our average hydration time before adding Web Workers improvements was 450ms!

If you profile your page, you can bucket the tasks executed into two buckets; hydrating components, and other tasks (like providing context and any other tooling initialization).

For us, this differs per page but it’s usually 60% time spent on hydrating the visual components of the page, and 40% on running the other tasks. If the page has more components usually it skews more in the direction of the hydrating of visual components.

Optimizing the other tasks could give us a potential improvement of 200ms (40%) in our hydration time. So it’s a no-brainer to try to fix this!

This is excluding any improvement we would potentially make on further render cycles. As some of these context providers have active communication with the rest of the app during the entire lifecycle of a user’s session.

Moving tasks to another thread — the Web Worker

There’s only one way to multi-thread on the web, and this is through a Web Worker. It is a new-ish API, but its browser adoption is quite good. According to caniuse 98% of the web’s users have access to this API. The Web Worker API isn’t as easy as doing everything in the same main thread, you will need to adapt your tooling to work with Web Workers.

To work with Web Workers you need to understand that the Web Worker code runs in a different environment than your main application running on the main thread. You can’t access things like window variables for example. The only way to send data to the web worker is through an event sent through the postMessage function.

As you maybe already noticed, this could make any synchronous API an asynchronous API, where you’d have to wait for the worker to respond with a message. This is why we split our tasks into another bucket, the send-and-forget tasks (where we don’t care for a response), and the tasks where we depend on the response of the API.

Send-and-forget tasks

We have a couple of these tasks, and we can also recommend a third-party library called partytown to offload your scripts to the web worker. It works great!

One of the tasks we started off with wasn’t compatible with this though, and needed some custom tinkering. We started off by moving our metrics and tracing to a Web Worker, for which we use OpenTelemetry. If you’re not familiar with OpenTelemetry, it’s one of the leading APIs for doing any kind of tracing, and they ported their library to many different platforms, including web. We’ve been using it for a while and it has been great. But never mind the tool, we’re moving it to a Web Worker! We found it was accounting for 5–10% of the total hydration time of our pages on average.

A simplified version of the API signature of the OpenTelemetry library looks something like this:

const span = tracer.startSpan(
  'mytrace',
  {
    attributes: {
      myAttribute: true
    },
  }
);
span.setAttribute('test', 'test');
span.end();

If we’re thinking about send-and-forget APIs this of course looks a bit more complex, as it depends on different stages of sending certain related data points to this API. The API needs to know when the span started, when a new attribute is added, and when it ends.

We worked around this problem by creating an interface on the main thread, where we give the other thread the ability to match the events of the main thread to the same span. The interface we built looks like this (the API is not the complete OpenTelemetry API, but we ported each function):

let spanCounter = 0;

const startSpan: Tracer["startSpan"] = (name, options) => {
  const identifier = `${spanCounter}.${name}`;
  spanCounter++;

  eventBus.pushEvent({
    name: "startSpan",
    payload: {
      identifier,
      name,
      options
    },
  });

  const span: Span = {
    name,
    setAttribute: (key, value) => {
      eventBus.pushEvent({
        name: "setSpanAttributes",
        payload: {
          identifier,
          attributes: { [key]: value },
        },
      });

      return span;
    },
    setAttributes: (attributes) => {
      eventBus.pushEvent({
        name: "setSpanAttributes",
        payload: {
          identifier,
          attributes,
        },
      });

      return span;
    },
    end: (endTime) => {
      eventBus.pushEvent({
        name: "endSpan",
        payload: {
          identifier,
        },
      });
    },
  };

  return span;
};

const tracer = {
  startSpan,
};

You can see that we send events on each function call to our event bus provider. This event bus communicates with our Web Worker, and each event has a handler inside the worker. The main events here are: “startSpan”, “setSpanAttributes” (we reuse the same event for setAttribute and setAttributes), and “endSpan”. Each event will have the identifier in its payload and that can then be referenced inside the worker.

For example the event handler for startSpan looks like this:

export const spanCache: Record<string, Span> = {};

const startSpan = (
  tracer: Tracer,
  { identifier, name, options }: StartSpanPayload
) => {
  spanCache[identifier] = tracer.startSpan(
    name,
    options
  );
};

And inside our other handlers, we can reference get the current span from the spanCache variable:

const endSpan = ({ identifier }: EndSpanPayload) => {
  if (identifier in spanCache) {
    spanCache[identifier].end();
    delete spanCache[identifier];
    return;
  } 

  throw new Error(`${identifier} not found, it was probably already ended!`);
};

const setSpanAttributes = ({
  identifier,
  attributes,
}: SetSpanAttributesPayload) => {
  if (identifier in spanCache) {
    spanCache[identifier].setAttributes(attributes);
    return;
  }

  throw new Error(`${identifier} not found, it was probably already ended!`);
};

Maintaining context

With tracing you want to maintain the context of the parent spans of your trace. OpenTelemetry needs the parent span object to reference this context. Because we don’t have this span object in our main thread we had to come up with a different API than the original API from OpenTelemetry. This is the only difference with the original API as we tried to keep everything as similar as possible to reduce refactoring efforts and prevent difficult upgrades when the OpenTelemetry API changes.

The reference to these parent spans only exists within the worker thread, so we needed to design a way to pass this reference from the main thread. Now when someone wants to reference a parent span context they have to write a slightly different function:

consconst parentSpan = tracer.startSpan("parent-span");
const span = tracer.startSpan(
  "child-span",
  undefined,
  parentSpan.getIdentifier()
);

This identifier, you probably guessed it, is the string value we create inside the startSpan interface, which we reference inside the event handlers of the web worker. With this in mind our startSpan handler will look like this:

const startSpan = (
  traceContext: TraceContext,
  { identifier, name, options, context: parentSpanIdentifier }: StartSpanPayload
) => {
  if (parentSpanIdentifier) {
    const contextOfSpan = trace.setSpan(
      context.active(),
      spanCache[parentSpanIdentifier]
    );

    spanCache[identifier] = traceContext.tracer.startSpan(
      name,
      options,
      contextOfSpan
    );
  } else {
    spanCache[identifier] = traceContext.tracer.startSpan(
      name,
      options
    );
  }
};

Timing discrepancies

When we send events to the worker it could be that there is some delay in when it is handled. According to MDN, this is 0–1ms, but we wanted to prevent polluting our data with potentially inaccurate timing due to eventing delays. This is why we started referencing all our timings inside the main thread, the worker thread was just a consumer of these timings.

This means that our startTimePayload would have the start time from the main thread; like so:

eventBus.pushEvent({
  name: "startSpan",
  payload: {
    identifier,
    name,
    options: {
      startTime:
        typeof options?.startTime === "number"
          ? options.startTime
          : getCurrentTimestamp(),
    },
  },
});

People also have the ability to add a custom start time, so we have to account for this, but the default will be the current timestamp when startSpan is called in the main thread. We did the same for the end time of our spans:

eventBus.pushEvent({
  name: "endSpan",
  payload: {
    identifier,
    endTime:
      typeof endTime === "number" ? endTime : getCurrentTimestamp(),
  },
});

Which had to be handled as well by the event handler:

const endSpan = ({ identifier, endTime }: EndSpanPayload) => {
  if (identifier in spanCache) {
    spanCache[identifier].end(endTime);
    delete spanCache[identifier];
  }
};

Creating the worker asynchronously

We noticed that creating the worker in sync with the rendering of the tree is also not the most performant. Imagine the following two components:

const TracerProvider = () => {
  const worker = useMemo<Worker>(
    () => new Worker(new URL('./worker/index.ts', import.meta.url))
  );
);

const TracerProvider = () => {
  const workerRef = useRef<Worker>();
  
  useEffect(() => {
    workerRef.current = new Worker(
      new URL('./worker/index.ts', import.meta.url)
    );
  }, []);
};

When we create the worker on an effect (after all the main rendering work is done), it doesn’t impact the hydration time. The one downside of this though, is that we don’t have the worker ready immediately for it to receive events.

So what we created instead was an event bus, which would relay events in bulk to the worker (which can also optimize the processing time needed to communicate with your worker). It keeps all the events locally and then when the worker is initialized it will send the events to the worker for processing.

Results

In the end, we measured a 4% decrease in hydration time on all our pages (with the same metrics solution) and an additional 5% decrease in subsequent rendering time!

We also found more opportunities to improve our core metrics. We were including all the OpenTelemetry packages in the main bundle as it was part of all pages and the bootstrapping part of the application. Now that we moved everything related to OpenTelemetry to the Web Worker we were able to move the packages into the bundle with the worker. This bundle can be loaded after we hydrate and render the application because we communicate with our Web Worker through the event bus! This decreased our FCP by another 4%.

We did have to make sure that no part of the app was or is referencing any OpenTelemetry packages. We had to port an enum to the main bundle for this, but the rest was easily extracted to just be used inside the Web Worker.

Tasks where we depend on the immediate response

We have another heavy component that is slowing down our hydration time that loads a huge JSON file which we use for deterministic experimentation for our application. You can see that it’s an even bigger part of the hydration cycle than the OpenTelemetry provider:

Moving this to the Web Worker is a bit more complex and will be handled in part 2 of “Leveraging Web Workers for performance at HelloFresh”.

Leveraging Web Workers for performance at HelloFresh — Part 1 was originally published in HelloTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now, after a couple of years’ thought, we have a solution. It gets pretty close to what we envisioned a front-end microservice architecture to be and, since the rest of the world is also getting in on the front-end microservices train, we thought we should show off our solution as well.

Defining a front-end microservice

Firstly we had to define what a front-end microservice is, so what is a front-end microservice exactly?

Our definition was as follows (again we’re not sure if this is the right definition, it’s just our definition):

A front-end microservice listens on one or more HTTP hooks (endpoints) and serves the page HTML and links to scoped CSS and JavaScript.

The technology should be free to choose; there should be no external critical dependencies. This way we can serve React apps on one page, plain HTML on the other, and maybe a Vue app on another page.

Pretty simple so far. We also came up with the following additional requirements:

• It should have an isolated deployment cycle.
• It should be able to run in an isolated environment.

And something a bit more difficult, since we want the experience for our end-users to be the most optimal:

• The HTML should be server side rendered.
• The response time should be as fast as possible.

The design process

We need a couple of parts to make this front-end microservices thing work. The first part we needed was actually something we already had. It’s not the most optimal solution and it’s pretty hard to configure, but it worked. Meet entry, an NGINX server listening on the HelloFresh domain. This routes traffic to via consul, so it’s easy for us to launch new servers to serve these pages by simply adding a new location block:

As you can see we also intercept our errors here (404s and 5xxs), which are then proxied to other front-end microservices that serve the error pages 💪.

HelloFresh front-end microservice jargon

Of course we’re not going to call everything a “front-end microservice”. For the sake of saved keystrokes, we came up with some HelloFresh specific jargon for our architecture:

• Fragment (aka florp): The server serving the entire HTML bulk, CSS etc. — essentially a full page
• Particle (aka glorp): Shared parts of the page that need to be loaded synchronously
• Tag: Asynchronously loaded shared parts of the page

The back-enders were a bit confused by our ultra cool names; they had to come up with their own variations. I noted them in between the parentheses.

The fragment

Honestly, this name came to be because we initially thought to go with Zalando’s approach. It didn’t turn out this way, but we kept the name. This is a service that runs under one of these entry server locations and serves small SPA’s.

Currently we have only one kind of fragment running, but soon we will have some more kinds to serve legacy pages.

This non-legacy fragment is built up out of an isomorphic React application, that is served through an Express server. It’s like any other isomorphic react boilerplate, but with some of our own specific needs built in. One of these needs is the integration of the particles.

The particle

The particle is a bit special and tailored to our needs. We built the particle to create applications that are shared across our platform, but also need to be rendered on the server. A simple example is our header and footer, which are simple React applications. The cool thing here is that the parent application can be anything, since the particles are not dependent on the application that includes them; all they need is an element to bind to. The particle server returns JSON that contains the following:

• The HTML that is server side rendered.
• The critical CSS that comes with this.
• The state of the application at that point in time.
• Link to the script file to mount the application

So an example return would be:

{
    "html": "<div id=\"react-root\">Test</div>",
    "css": "#react-root{color:green}",
    "initialState": {
        "country": "DE"
    },
    "script": "https://assets.hellofresh.com/dist/my-particle.hash.js"
}

The fragment will basically request this particle, write the HTML and CSS and when the application is loaded mount the particle. There’s a lot more to it than that — a bit too much to talk about in this blog post. Watch this space for a future article dedicated to this glorp technology.

The tag

The tag is also something of our creation. We felt the need for some very small — but still a bit more complex than easy jQuery and CSS — applications that are triggered asynchronously on the page. Consider a modal that you want to load asynchronously — perhaps on a button press — and is not necessarily tied to a route. Using a tag instead of a particle, loading of these scripts is deferred, so doesn’t affect page load.

These are implemented as small React applications that expose a window function to initialise them. For example, to initialise the sign up tag we built:

window.signUpTag({
    bindToElement: document.body,
});

This function will then load the React application and mount it to the element.

How it all ties together

Will it blend!? Well we think so:

In the flow above, a client sends a request for one of our React pages. If the CDN doesn’t have a recent cached copy of this page, it will direct the request to our entry server which will then forward it to one of our fragments. I drew the RAF (recipe archive fragment), the FF (funnel fragment) and the MDF (my deliveries fragment) here to portray a part of our infrastructure. The fragments in turn will request parts (particles) of the page from the gateway. These particles will return the HTML and CSS needed for the fragment to return a full render. As fragments are cached by the CDN the experience is lightning fast ⚡️.

Here’s another view of the same flow:

The road travelled

We’ve now been working with this architecture since the Summer of 2016. Luckily the way we built it, it allows us to constantly evolve this architecture. We’re able to iterate on it really quickly due to a project manager we built in-house, called 🐙. Now, after almost a year, we’ve gathered a lot of experience and data on how this approach has worked for us.

Development velocity

At first, we found development speed to be a bit slow. Since this approach requires you to own your entire project E2E, the learning curve can be steep. But after cresting the curve we were able to push out projects like never before; the new HelloFresh shop for example took 3 people 4 weeks to roll out. Our developers also claim increased confidence and breadth of knowledge after adopting this approach.

Isolation and code freedom

At the beginning of this project, one aim was to be able to write projects in Vue, React, or Angular and to have it work seamlessly with the rest of the website. While this is possible, in practice everyone has adhered to our React boilerplate so far. Of course, the fact that we have the possibility is already a big win in flexibility and future-proofing.

Error tracing

Fragments’ logging is unified, consistent, and fairly verbose. With all the applications following our boilerplate, we’ve gained a lot of speed in triaging issues as they arise, which helps us to fix issues much more rapidly.

Development

This win is probably the most noticeable. While previously we had this huge monolithic application that was unmaintainable and nigh-on unbootable in a local environment (shortly described in our previous blog post here), now each project has its own server, and its isolated dev environment. All the external dependencies can be configured, so you can talk to the live, staging, or your own environment to debug problems.

Credits

Credit goes to Tom Söderlund blog post, wherein he describes the approaches other companies have taken to front-end microservices. I think it’s also important to showcase all the benefits we got from this approach at HelloFresh.

I couldn’t have built this without the help of a lot of my colleagues. I need to thank all the front-end developers, who hung in there during many intense patch periods, the front-end leadership team for being critical about the process and the implementation, Joanne Wong for making the beautiful graphs in this blog post and last but not least to Nuno Simaria for giving us the freedom to develop this infrastructure next to an already full roadmap.

Looking for a new job opportunity? Become a part of our team! We are constantly on the lookout for great talent. Help us in our mission of delivering fresh ingredients to your door and change the way people eat forever.

Front-end Microservices at HelloFresh was originally published in HelloTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We think every developer has a ❤️/👿 relationship with A/B testing. It’s either about loading bulky scripts with jQuery written by marketing people, or it’s about having to hack something into your own code. It’s never really nice or cool, it’s always a drag.

We at HelloFresh wanted to make at least some part of it easier to handle, to keep the disruption from A/B tests to our shiny React / Redux apps to a minimum. This is when we came up with external alterations.

The idea basically sprung from changing the state of the store from a window function. But since we didn't want to add a reducer for everything and we also didn't want to expose every action in our application, we had to think of something special.

The kernel

First we have to add our actions to the window object in an elegant way. We came up with the fancy word ExternalActionKernel, which is basically a very simple React component.

import { Component } from 'react';
import { connect } from 'react-redux';

import { setAlteration } from '../../store/actions/externalAlterations';

class ExternalActionKernel extends Component {
    componentDidMount() {
        window.triggerExternalAction = (action, payload) => {
            return this.props[action](payload);
        };
    }

    render() {
        return null;
    }
}

const mapDispatchToProps = { setAlteration };

connect(null, mapDispatchToProps)(ExternalActionKernel);

And then to execute this action you would do something like:

window.triggerExternalAction('setAlteration', {
    showTestModal: true
});

The alteration reducer basically holds all the alteration information. We’re not going to bore you with the code there, but it’s basically an object that gets updated through actions. The payload can be any kind of object.

Using the alterations

Now to use this alteration that we just set, we need to connect our component where we would show this: TestModal.

import React, { Component } from 'react';
import { connect } from 'react-redux';

class TestComponent extends Component {
    render() {
        if (this.props.showTestModal) {
            return <div>AB Test</div>;
        }

        return <div>Normal</div>
    }
}

connect(state => ({
    showTestModal: state.alterations.showTestModal,
}))(TestComponent);

Look how elegant that is! No more:

$('.ab-test-modal').show()

The only thing the asynchronous scripts have to do now is call this window function with the right parameters and you have an A/B test!

Example

You can play around with our website a bit as well. For example, on our shop page you can change the highlighted product by using this technique.

You can even try yourself, in your browser! Simply go here, pop open your console, and execute the following:

window.triggerExternalAction('setCategoryPromotedProductFamily', {
    category: 'kits',
    productFamily: 'slice-n-dice-kit',
});

🎉🎉🎉🎉🎉

Looking for a new job opportunity? Become a part of our team! We are constantly on the lookout for great talent. Help us in our mission of delivering fresh ingredients to your door and change the way people eat forever.

A/B Testing with Redux was originally published in HelloTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We ended up going with Aphrodite, because:

• Cool name.
• Khan Academy built it, so they probably also use it.

This was mostly it for us actually, the other options didn’t suit our criteria well. Like some of them were bound to another view framework, for example how Radium is bound to React.

Now, some months later we decided to revise our decision (read up on how we built the entire application here). We were happy with the choice we made, but we wanted to see what new stuff was out there. Luckily at the time we built it we decided to have some kind of interface layer between what was actually output to our component’s classNames and what library we actually used. So the refactoring part will not be too difficult (hopefully).

The contenders were (as far as we could find them):

• Aphrodite, still going strong, still a cool name.
• Glamor, really really like the rule based API.
• JSS, awesome logo, nice API, can also do nested styles.
• CXS, functional CSS, say WHUT!?

The battle

We put all the libraries up against each other and checked out their bundle sizes, API’s and performance.

Performance

The first test we ran was just a simple case:

This is of course a very simplified version and it won’t work, because style-lib is not a thing. But it shows the way we tested pretty well.

For the benchmarks, we were testing on a Macbook Pro with a good amount of memory and CPU, and ran the tests with the help of Benchmark.js.

Try 1

These are the results of the first test we ran:

5 tests completed.

aphrodite          x  3,178 ops/sec ±13.32% (43 runs sampled)
jss                x    107 ops/sec ±67.27% (8 runs sampled)
jss-without-preset x  71.44 ops/sec ±7.87% (45 runs sampled)
glamor             x 11,968 ops/sec ±9.31% (50 runs sampled)
cxs                x  7,774 ops/sec ±9.49% (56 runs sampled)

Fastest is: glamor

As you can see JSS was slow, very slow. Tiago, one of our front-end developers, created an issue on the repo, which you can read up on here. Turns out we were writing on top of the global JSS object all the time, without resetting it. Seems like the default implementation is not that stateless.

Luckily they had a fix for us so we could create a new instance for every test. The new results were a bit more in line with what we expected:

5 tests completed.

aphrodite          x  6,088 ops/sec ±7.65% (62 runs sampled)
jss                x 11,291 ops/sec ±8.39% (75 runs sampled)
jss-without-preset x 11,622 ops/sec ±17.20% (52 runs sampled)
glamor             x  6,623 ops/sec ±14.67% (67 runs sampled)
cxs                x 12,121 ops/sec ±3.80% (75 runs sampled)

Fastest is: cxs,jss

Along with creating class names we were also rendering the HTML with the help of React components. We found this to be an unnecessary constant through our tests and continued with just rendering HTML as a string. As you can the overall performance increased as well.

We ran the tests one more time and this time also with cxs/optimized, a library by CXS that is supposed to have better performance on the browser.

We decided to start measuring string length as well on the output from the library. This will include the rendered HTML with the CSS.

aphrodite          length 470
jss                length 447
jss-without-preset length 439
glamor             length 422
cxs                length 400
cxs-optimized      length 445

  6 tests completed.

  aphrodite          x  8,943 ops/sec ±14.55% (68 runs sampled)
  jss                x 11,697 ops/sec ±27.81% (55 runs sampled)
  jss-without-preset x 46,684 ops/sec ± 7.89% (62 runs sampled)
  glamor             x  5,042 ops/sec ±14.27% (47 runs sampled)
  cxs                x 19,122 ops/sec ±10.24% (69 runs sampled)
  cxs-optimized      x 12,843 ops/sec ±10.52% (69 runs sampled)

Fastest is: jss-without-preset

Expanding

Of course just testing one class is probably a piece of cake for every library. So we turned it up a notch and added one test that added a lot of classes with the same styles. And another one that added a lot of classes with different styles (a simple incremental paddingLeft).

With these new tests we are also evaluating which libraries manage to keep their output the leanest.

The classes overload test

aphrodite          length 3044
jss                length 3085
jss-without-preset length 3064
glamor             length 1935
cxs                length 1943
cxs-optimized      length 1943

  6 tests completed.

  aphrodite          x 1,145 ops/sec ±23.06% (55 runs sampled)
  jss                x 1,305 ops/sec ±31.53% (39 runs sampled)
  jss-without-preset x 2,723 ops/sec ±17.48% (38 runs sampled)
  glamor             x 2,698 ops/sec ±18.00% (48 runs sampled)
  cxs                x 1,697 ops/sec ±15.10% (46 runs sampled)
  cxs-optimized      x 2,359 ops/sec ± 7.45% (72 runs sampled)

Fastest is: jss-without-preset,glamor

The styles overload test

aphrodite          length 3594
jss                length 3509
jss-without-preset length 3430
glamor             length 3298
cxs                length 3022
cxs-optimized      length 3063

  6 tests completed.

  aphrodite          x   853 ops/sec ±19.51% (54 runs sampled)
  jss                x 2,200 ops/sec ±10.85% (66 runs sampled)
  jss-without-preset x 4,301 ops/sec ±17.48% (55 runs sampled)
  glamor             x   665 ops/sec ±17.53% (56 runs sampled)
  cxs                x 1,032 ops/sec ±24.12% (43 runs sampled)
  cxs-optimized      x   743 ops/sec ±21.16% (45 runs sampled)

Fastest is: jss-without-preset

On class merging CXS and Glamor are doing great jobs, but when the styles are different everyone is doing an equal job at keeping it lean. Only CXS is a bit better than the rest.

All libraries don’t merge classes on a higher level (when the styles are the same), you can see that here:

Looking at the operations per second, JSS without preset is definitely winning on all sides and Glamor is getting into trouble when there are different styles at play. Since you would actually use JSS with a preset the library that won this challenge is a close call. CXS is definitely a good contender overall, but JSS with the default presets is still a good runner-up and they managed to get the core performance without presets very tight.

Winner: CXS

Bundle sizes

Of course all this processing power is worth nothing if the library is huge, so next what we did is check what the sizes were when bundled by Webpack. These are the results:

Size cxs 9.766KB
Size cxs-optimized 12.668KB
Size jss-without-preset 24.183KB
Size jss 37.04KB
Size aphrodite 18.919KB
Size glamor 35.436KB

As you can see, JSS is the fastest but also one of the biggest. The results of CXS are also really good, they really do what they say. Functional libraries should be small. Glamor say in their README that they are small as well, but actually they aren’t that small when you compare them to the rest.

Winner: CXS

API

Having a good processing time and a small bundle size are very important, but we also need to work with these libraries every day. The API of the library is just as important an aspect.

We made some showcases of how the API’s are used in their simplest forms.

Aphrodite

Aphrodite is very verbose and they are keeping a close relationship with actual CSS. The API uses words like StyleSheet and css. The renderStatic method is a method to render the CSS as a string.

CXS

We really like this, because you don’t really care about classNames and naming things anymore, you just create rules and attach these to components. Also the reference of the styles in the form of a string is created on the fly, so no need to render anything.

Glamor

Glamor’s API shares elements with the APIs of CXS and Aphrodite. Glamor also requires HTML to be returned in a callback function.

JSS

The API of JSS is a bit harder to grasp. It uses a little bit of the way Aphrodite works and the way they render the CSS is more like CXS.

Winner: CXS

Integration with the client

The previous tests only take rendering code on the server into account. When you render your CSS on the server you of course don’t want to execute the same operations on the client. So which library takes the best care of this? Well calculating it with benchmarks is actually pretty hard; since you’re going from your server to the client we would have to make some crazy PhantomJS contraption. But we thought probably explaining and checking out what each library does to solve this is probably a better idea.

Both Aphrodite and Glamor are careful to rehydrate before bootstrapping on the client; Glamor explains how to do so very well here. However neither CXS nor JSS really care about what was already rendered on the server. The instruction from CXS, for example, is to just remove the style tag that was put there by the server after the client is done generating all the CSS again.

Winner: Glamor

Conclusion

There’s a lot of libraries out there and they all do it a bit differently. Since writing the first draft of this blog post, we already got numerous Pull Requests of more css-in-js libraries and we created several issues for the libraries that we documented here. Some library creators actually also pointed us to better ways of using their library, which was really helpful.

I think there’s still no clear winner for us. Definitely the rehydrating is an issue, as we tend to have a lot of styles and having to re-generate them again for one page seems a bit wasteful. I created an issue on the JSS repository about this and the maintainer has some good points on the topic. We do hope that the aftermath of this battle is going to be of some help at least!

Oh yeah, and don’t forget to check out the source code for the benchmark tests! 🌟 (Feel free to contribute with more css-in-js libraries as well!)

Looking for a new job opportunity? Become a part of our team! We are constantly on the lookout for great talent. Help us in our mission of delivering fresh ingredients to your door and make home cooking accessible to everyone.

The css-in-js battle was originally published in HelloTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This was a time where Angular 1.2 applications were still the world standard for single page applications. Coming from an environment that was built with rogue JS files filled with jQuery that themselves were then in Yii1 templates, the Angular application was already a big improvement (we also were just 3 front-end developers at the time, in the entire company!). We decided that before we would let the bug reports from this Angular application drive us up the wall, we would totally revise it from the bottom-up. That brings me to the main theme of this blogpost, JavaScript con Carne: a wink to the multi-cultural team and hardcore development period we embarked upon to phase out this angular application that we created.

We at HelloFresh also like to codename our projects with food, because we like food. The codename of the angular application was „Ginger“, the new application con Carne: „Senf“. Which means Mustard in German and for the ease of reading let’s dub the Yii fiasco that was there before the „Brussels Sprout“ era, because no one likes Brussel Sprouts.

I will try to make the journey as clear as possible from the beginning, so you have a better context, so you can try and understand our decisions better.

Brussels Sprout (2012 – Summer 2015)

If you have experience with working for or working with or doing anything with Rocket companies that were bootstrapped in this time, you probably heard of Alice and Bob.

If you did, you can skip this short introduction:

Alice is a ~5 year old PHP framework written with the dark horror that is known as Yii framework 1. This PHP framework was there to generate all the views and pages and not to contain too much logic. Of course that is already where it goes wrong in most companies, these things become bulky as hell and since only front end developers were wriggling around in these parts of the code, you can probably imagine how bad the PHP was…

Alice, along with Bob (a Zend Framework 1 application; her best friend, partner, or worst enemy — you choose!), does a couple of things. It holds the core business model, which was basically a subscription model hacked into an e-commerce store application, and it’s also a CMS and a management system for anything customer related. I should probably also mention, that the version we were using was basically an alpha version of the Bob and Alice system. It was already broken by design.

So basically everything on the front end was inside Alice, so our first account area, „Brussels Sprout“ as well. It was a beautiful thing with gradient header background and content bubbles used way more than necessary.

Small side note: I myself have never really worked a lot on these systems (luckily).

Ginger (Launch: Summer 2015)

Yes you read that title right: if you’re still early enough to read this, you might be able to catch the old account area in the wild. For most of the countries we are still in a testing phase, but it’s safe to say it will be extinct very soon!

When I joined HelloFresh, the guys already started the Angular 1.2 applications. We had a short timeline and a lot of stuff to do. For me it wasn’t my first angular SPA, for the guys it was. I never built anything this big though!

However, sometimes you have to know when to throw one away. Which brings us to:

Senf (Launch: Summer 2016)

As the name indicates, Senf is here to introduce a new spice in HelloFresh. I won’t spend a lot of time on the design part since this is an engineering blog. But safe to say the UX team did an amazing job at fine-tuning this.

Why was the old so wrong?

Well:

• Response time for the subscription page in the account area was around 14 seconds on a good DSL connection.
• The old code had so many corner cases hacked in, meaning one little change could throw over the entire Jenga Tower.
• Angular 1.x was nice when we didn’t know any better. The amount of watchers to keep track of the data and update the DOM were insane. Also 500 line directives were not a rarity.
• We were loading around 3MB’s of JavaScript onto the client, without gzip and without a CDN. So you can imagine how slow this was, and how costly for users using a limited data plan.
• To develop on this application that you had to run a vagrant box (which took a day to provision in the good old days) which contained everything — and when I say everything, I really mean everything. So API’s, back-end tools, forecasting tools — and you have to run all this just to change a small thing on the front-end. Those times were pretty sad.

So how do we prevent all these things, whilst also implementing a totally different design? Well, there were actually a lot of solutions out there before the summer of 2016, when we started. Decisions had to be made quickly and had to be made concisely. There wasn’t much room to change since we didn’t even convince business yet that the new project is viable.

The team

I haven’t mentioned yet that HelloFresh is a very back-end heavy company. We have lots of PHP and Go developers, but sadly we were still lacking resources on the front-end side. To implement „Senf“, we had the following warriors:

• 1 Mexican developer (@josemussa)
• 1 Portuguese developer who wasn’t even in the office, since he’s in the remote year program (@tiagojsalmeida)
• 2 weeks of help from our very own HelloFresh Australian from another team, working on customer related topics (@MichaelFBA)
• And me, Head of Front-end, Dutch and mostly busy keeping the rest of the front-end for the company running as well (@PepijnSenders)

The server

The first choice that was clear is that we wanted to have a universal code for our components and that we need to able to render as much as possible on the server. Having JavaScript on both the front-end and back-end we could avoid most of our problems originated from working on our out-dated PHP back-end.

Again, easier said than done, getting a grip of a methodology as new at the time as SSR (Server-Side Rendering) is really hard. We had to do a lot of mind maps, to be able to get a grip of what we actually wanted to build and how we wanted to build it.

For the back-end router we choose Express. I know there’s a lot of Hapi fans out there and I have to say I’m becoming a bit of a fan myself. But at the time Express was definitely the right choice since we were the most familiar with it.

The view layer

This was a struggle as all that any of us really knew was maybe Backbone and Angular 1.x, both not really suitable for what we wanted to accomplish. The view layer, must definitely be able to be rendered on both back-end and front-end. Another thing we wanted to get rid of was this watcher soup that was a common thing in our Angular 1.x applications. The technologies that we had considered were:

• Riot (it’s small, it’s fast, it’s simple)
• React (huge community and API, used by Facebook)
• Vue (bit of an unknown player at the time, but should be a smaller step to take from angular 1.x)
• Elm (big fan, but big learning curve, sadly no time or resources for this)
• Angular 2 was obviously also considered (no proper RC at the time though and we all felt pretty uncomfortable using TypeScript)
• … and a couple more that were not worth mentioning for this story

In the end we went for React, simplest explanation why is: the amount of documentation, ease of reading through the source code, and the community backing it. We personally still think that whatever library you’re going to use, if it has no community behind it’s probably better to look somewhere else.

No one of us had any experience with React other than the usual „playing around with it“. So we ordered ourselves some Egghead.io videos and started binge watching all the react related stuff out there.

State

When you say React, you said Flux, but at the time people were actually already dispatching to redux. We didn’t really know much about both to be honest, but YouTube was another great help here. We taught ourselves all the new patterns and decided that Redux was the best option for our unborn application.

What attracted us the most was the single source of truth we could create with Redux, this would definitely help us to prevent a watcher soup and a ridiculous amount Angular Services holding our data.

The kick-off

After making these three base decisions, I jet started the server and development tools. We went for Webpack in combination with our own babel and ESLint configuration. I created a development wrapper for the React/Redux application so the other developers didn’t have to worry too much about the SSR part.

Not worrying about the SSR part seemed like a good idea in the beginning, but at some point you’re going to run into problems that you simply don’t have inside the development environment. Stuff like non matching output between client & server, because stuff was for example done according to window attributes (bad idea anyways). We currently have the SSR built into the project itself, duplication over depending!

One very smart decision looking at the process afterwards was to start with mapping out the dependencies and actions of all the components by looking at the wireframes the UX team gave us. After we did this we started modelling, very basic and with no styling at all! This choice let us catch a lot of gaps in the provided designs, before we even started thinking about CSS.

All this was mostly a one man game by @josemussa, with some help from @MichaelFBA and supervised by me. Progress was smooth, focus was on performance, we wanted to make this stuff fly!

Styling

If we had to style something fast and beautifully we always asked @tiagojsalmeida, our remote worker, to do some CSS magic. But we were nowhere near convinced of the style loaders that were used in Webpack at the time.

We were afraid of having a huge dependency on Webpack, since it was kind of new and the JS files that would require the CSS files would subsequently be unreadable by any normal JS engine. Also loading the CSS as part of a JS dependency felt a bit weird for us, we wanted to be more in control of our CSS and the way to do that was to make the CSS more programmable.

After some research we found the new css-in-js techniques. We were all pretty intrigued by its latest developments. Again another technology that was just on the horizon and there was almost no writing about it.

The good thing at this point in time was that the entire account area was already there, every component was working and all the logic already clicked. We could easily test out these technologies on this bare bone frame.

So we finally got the help from @tiagojsalmeida on this project too, I know he and the rest of the team had some trouble wrapping their heads around css-in-js, but I was really convinced this could be the salvation to a couple of problems we had in the past:

• SSR with css-in-js works really well.
• This will finally make CSS have a bigger part in the code reviewing process, before CSS was always overlooked and left behind.
• Way less files and boilerplate, the account area with all its components, actions, reducers and configuration only contains around 250 files.
• Better exportable components that already contained all the attached styles.
• Freedom of how to push your CSS to the client, because it is now programmable.

Of course with all the young options out there, we still had to make a decision on this, good or bad. It was very early to know which one was the good one, when most of the solutions we looked at had fewer than 500 stars at the time and only a handful of issues and pull requests.

In the end we decided to go for the solution that looked the best and that was probably already battle tested: Aphrodite. Since it was built by Khan Academy we figured they must use it in production as well.

Still, we weren’t 100% sure of our decision so we decided to build an interface layer which most of the css-in-js libraries would work with. The only thing we needed to change was the implementation inside the interface and not the implementation in every component.

Going live

We have an internal joke in our team that you hopefully won’t mind me sharing. You can find the joke about us pushing a project live on youtube here.

Probably you will hate me now for putting that song in your head. Sorry, not sorry.

So after developing the full application there were a couple of things to wrap up on, deploying the entire thing, security, assets caching, a CDN and performance.

Setting up the express server was pretty easy. Some nice middlewares we used were for example: helmet for security, some gzip compression middleware and some more logging and stats tools.

I followed this guide on medium by Andrey Okonetchnikov, found here, for how to generate the Webpack chunks. Our application didn’t depend that heavily on require.ensure before, but I can definitely recommend considering this from the start!

The CDN was the latest addition. Actually the application was already live for a couple of weeks before we added this on top of it.

As you can see we sadly still have a big dependency on our API layer (it’s pretty slow) and as you can see without caching the first response from the node service is also pretty slow. However, it’s a vast improvement on what came before:

The road ahead

We are convinced that these new techniques will give us the power to make a super fast website and on top of that also make it more enjoyable to build and maintain.

The next step will most probably be moving our homepage to this technology, whilst improving the underlying infrastructure for these applications as well. I can recommend reading up on the tools and infrastructure that Zalando Tech built, more on that here. Also, having some kind of in the middle API layer is one of the things we will definitely be looking at (GraphQL!).

Conclusion

Even though you’re low on resources, there should always be time to take on new stuff, even though it means late nights and a lot of Club Mate intake. As you can see in this project we actually totally replaced what we had before and this is now paving out the future structure for all new projects that are built at HelloFresh.

Of course this version of the new account area is not perfect, I definitely recommend starting small. Very small, smaller than we did at least. If I could go back in time. I would probably just start with one single page, or one single flow. Start so small, that throwing it away entirely, doesn’t hurt.

There’s definitely still a big road ahead of us, but where is the fun if there wasn’t any. Never stop improving, never stop learning!

JavaScript con Carne was originally published in HelloTech on Medium, where people are continuing the conversation by highlighting and responding to this story.