Linked: The case of partial hydration (with Next and Preact)

22 May 2019

Lukas Bombach has written an article on partially hydrating server-rendered HTML so that less client code is needed. Hydrating becomes an opt-in process per top-level component. This is used to make a performant news site.

Now you end up sending your entire application code to your users including React components for every headline or text paragraph anywhere on your page. The result is an unnecessarily huge bundle that needs to be loaded, parsed and executed. This results in suboptimal performance, your page will be slow(er) especially for mobile users and for no good reason!

The issue with Gatsby is that it has to generate all of your pages and subpages at compile time which does not really work when you have sites linked to a CMS that updates everyday and that hosts millions of articles—which is exactly what we need for our news media sites. This is why we are using Next as well as modifying it to suit our needs.

The basic idea behind our version of partial hydration is: Instead of doing SSR and then sending your entire application to your client, only parts of your application’s JavaScript would be sent to the client to hydrate the parts of your website which specifically require JavaScript to work.

Typed Subatomic Styling: Part 2 — Comparison to Styled-Components

11 April 2019

CSS-in-JS is a popular approach to styling components within React apps. These libraries are much more sophisticated than simply inline styles. I chose one popular library, styled-components, to compare to the Subatomic CSS approach I detailed in my previous post. I look at the clarity of components, the amount of flexibility, and performance.

Read more…

Programming language ⚡️ energy efficiency compared

30 March 2019

A team of Portuguese researchers have compared 27 programming languages by their energy use. They compared both CPU and DRAM energy usage with total time of execution and memory usage to build a fuller picture of efficiency.

The aggregated figures for energy, time, and memory across 27 programming languages.

Unsurprisingly compiled languages such as C and C++ perform best or near the top. Their modern successor Rust also does well.

Golang uses more CPU, but is still relatively lean. It’s especially impressive with memory usage, using even less than C or C++.

Swift and C# are not standouts, but both do very well both with energy and memory use. This contrasts with Java, which is faster and uses less energy, but has over twice the memory usage of these two.

JavaScript is one of the fastest interpreted language, having had over a decade of focused performance improvements. I have to assume they tested with NodeJS — I think server-side JavaScript has many interesting futures outside of this one particular tool.

Ruby and Erlang are both at the high end for energy use and CPU time. This could be because many of what were benchmarked were computationally intensive algorithms, which if you are building web applications you may not be writing many of yourself. However, many of the underlying libraries may still exhibit this sort of performance and energy profile.

All in all, I think it’s an interesting comparison, and I think it’s great to be putting a focus on energy usage as an important metric — it is something to be mindful of for both code running on servers in the cloud, and code on users devices.

You can read the full paper here, and there’s also more analysis to read.

Handy SPA config for Netlify

27 March 2019

Although Netlify out of the box won’t work with single page apps’ routing, it is easy to add. You can configure it to send all /* subpath requests to a single index.html file.

Steps for create-react-app

Here we will be using a create-react-app project. This should be easy to apply to other SPA toolkits.

Add a netlify.toml file to your src folder. In it write:

  from = "/*"
  to = "/index.html"
  status = 200

Edit your package.json file. Find the scripts section.

  “scripts”: {
    "build": "react-scripts build”,

Replace the build rule with three:

    "build": "npm run build:react && npm run build:config",
    "build:react": "react-scripts build",
    "build:config": "cp src/netlify.toml build/netlify.toml",

This rule builds the static assets using create-react-app’s toolkit, then copies the netlify.toml file to this build directory.

That’s it! As long as Netlify is set to run npm run build then this will work. You will be able to visit subpaths and get the same index.html page served for all.

Typed Subatomic Styling: Part 1 — Benefits of TypeScript and CSS

16 March 2019

The benefits of components have been realized with systems such as React and VueJS. Styling these components has a number of approaches, from CSS classes written in SCSS, inline styles, and dynamically generated stylesheets via something like emotion.

Each styling approach has trade-offs in regards to reusability, performance, and developer experience. Also, special considerations often have to be made when doing server-side rendering.

In this post, we’ll explore TypeScript combined with functional CSS. I believe it offers big benefits over the other choices — it’s extremely reusable, fast, and offers a very pleasant developer experience.

Read more…