Frontend

Netlify acquires Gatsby | Frontend Weekly vol. 123

Gatsby have been acquired by Netlify! Although you might thinkt this transaction is all about the Server Side Rendering framework but the truth lies elsewhere.

Article cover

1. Netlify acquires Gatsby

Gatsby development started in 2015 and after almost 2 years version 1.0 have been released. At the time, Gatsby have been one of the first frameworks that allowed you to compile your React code into HTML and serve it statically. To say that Gatsby gained some popularity it’s like saying nothing. The whole community went crazy about it. To this day Gatsby remains one of the most recognizable React frameworks that almost every React developer heard of.

The last few years haven’t been easy for Gatsby. Competitors like Next.js or Remix presented much more complex server-side rendering strategies. Of course, the Gatsby team has tried to fill up the gap. In October 2021 Gatsby 4.0 has been released and it included features like deferred static site generation or on-demand rendering on the server. In November 2022 Gatsby 5.0. have been released and brought experimental support for partial hydration and React Server Components. Unfortunately, at this point, the gap between Next.js has been very big. From my observations, Gatsby is also struggling to get rid of the static site generator label.

And Gatsby has been the first one to find the gold…

To be honest, comparing Gatsby to Next.js is a bit unfair as the Gatsby team has also built a lot of great tooling around their framework. The Valhalla project is a great example of that. It is supposed to provide a data layer over multiple CMS systems and expose it through consistent GraphQL API. This way you can completely decouple your CMS from your front end. Do you want to migrate your CMS? No frontend changes are required! Do you want to change your frontend framework? No changes to the data fetching are required! Do you want to gradually migrate to another CMS? Valhalla is also here for you.

All of the achievements described above wouldn’t be possible without proper funding. In 2018 Gatsby Inc. have been announced together with 3.8M$ Seed Round from Trinity Ventures. In the following years, Gatsby Inc. also raised Series A (15M$) and Series B (28M$) funding. In summary, the company has raised almost 40M$ to build something called content-mesh that later became the Valhalla Project.

Last week it have been announced that Gatsby Inc. has been acquired by Netlify. If you haven’t heard of Netlify yet, it is a web development platform that provides hosting, continuous deployment, and serverless functions for modern web projects. It aims to make it easy for developers to build, deploy, and manage their websites and web applications, by offering a streamlined workflow that integrates with popular front-end tools and services. Netlify has raised quite a lot of money too – over 200M$ in 7 rounds of funding.

Netlify has a long history of investing into Open Source JAMStack technologies. In February 2022 they have hired Zach Leatherman to work full-time on his popular Static Site Generator called Eleventy. In May 2022 they have hired Ryan Carniato to work full-time on SolidJS – a React-like framework without VirtualDOM and a very interesting server-side rendering approach.

At first glance, you might think that Gatsby is just another framework in the Netlify portfolio. Although Netlify promises to keep the Gatsby development on track, it seems like the acquisition has been more about the Gatsby Cloud and Project Valhalla. Unfortunately, the transaction amount hasn’t been publicly disclosed.

To wrap up this section I would like to share with you a little trend I start to notice. The rather small startups built around Open-Source technologies in recent years are starting to look for an umbrella in form of larger and better-established companies. Just take a look and Shopify’s acquisition of Remix, OutSystems’s acquisition of Ionic, or Vercels’s acquisition of TurboRepo. All of these acquisitions make a lot of sense but somewhere deep inside I feel like none of them would happen a few years ago when the global economy has been thriving. On the other hand, I am no economist or market researcher so don’t overlook my opinion.

Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

2. The future of Create React App

Create React App is a CLI tool that enables you to set up a modern web app by running a single command. Unfortunately, it has been pretty much abandoned for the last few years. About 2 weeks ago a quite popular JavaScript celebrity Theo Browne tweeted this.

This tweet got so many reactions, that he really decided to open a PR to React repository changing the recommendation from Create React App to Vite. This triggered a massive wave of discussions.

  • “Theo has done this PR only to gain more followers. All of the issues discussed here have already been discussed elsewhere”
  • “Create React App isn’t the best tool but it helps complete beginners do the job without going into tooling details”
  • “React team shouldn’t pick their favorites – Rollup is an as good suggestion as Vite and Remix is a good alternative for Next.js”
  • “React documentation should be straightforward for complete beginners who don’t know yet what are build tools and meta frameworks”
  • “React should not recommend obsolete tools. No recommendation is better than the obsolete one”

As you can see, the issue isn’t simple and the fix isn’t obvious. This week Dan Abramov (the React Core team member and the guy behind React Hoosk and React Server Components) decided to speak up. His comment could easily be an RFC or a separate blog post. He goes through the history of Create React App and lists all its problems and all possible solution. If you have some spare time I really recommend reading it. TLDR for all the busy ones. Create React App will become an app launcher asking developers to choose the right toolset. The current implementation will be available as a “classic” option and will offer beginners an easy starting point. We can expect full-blown RFC in the upcoming months.

3. Update from Evan You on Vue.js Nation

To begin with, Vue.js Nation recordings are out! If you are a Vue Developer you will definitely find something for yourself here. Just to mention a few talks that cought my eyes:

  • “You’re probably using Lighthouse wrong: How we misuse most common tool to measure web performance?” by Filip Rakowski
  • “Decoding web accessibility through testing” by Anuradha Kumari
  • “Let’s talk about Security in Vue & Nuxt” by Jakub Andrzejewski

Anyway, we are not here to talk about Vue.js Nation and I would like to focus on a keynote by Even about Vue in 2023. To begin with, we are saying goodbye to Reactivity Transform. If you haven’t heard the term before, Reactivity Transform was a big back of improvements to the Reactivity API. Basically, all methods like ref and computed would get a version prefixed with $ that would not require .value calls.

// Without Reactivity Transform
<script setup>
import { ref } from 'vue'

let count = ref(0)

console.log(count.value)

function increment() {
  count.value++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>
// With Reactivity Transform
<script setup>
let count = $ref(0)

console.log(count)

function increment() {
  count++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>

After gathering some feedback from the community Vue team decided to drop off the feature. Many people didn’t like the new feature and this could cause a massive fragmentation in the community. If you are already using this experimental feature you have nothing to worry about. Existing implementation will be exported to a separate package/plugin so you can use it as long as you need to and experimental API will be supported in Vue Core until Vue 3.4. In the end, it’s worth mentioning that there is one feature from Reactivity Transform that will be split out and land in Vue 3.3: Reactive Props Destructure.

// Vue 3.2
const props = withDefaults(
  defineProps({ foo: number }>(),
  { foo: 1 }
)

props.foo
// Vue 3.3 (Reactive Props Descructure)
const {
  foo = 1
} = defineProps({ foo: number }>();

foo //stays reacitve!

In Q1 Vue Team wants to focus on Quality of Life Improvements, Bug Fixing, and finally delivering Vue 3.3. In general, in 2023 the team really wants to focus on smaller incremental releases, as the Vue 3.3 delay has revealed some real problems with the current process. It’s also worth mentioning that we will not get promised stable Suspend in Vue 3.3.

In Q2 Vue Team will focus on Server Side Rendering improvements. The only mentioned feature is lazy hydration. Unfortunately, we will need to wait for an RFC to get more details on that.

In Q3 and Q4 Vue Team wants to focus on Vapor Mode – a Solid inspired compiler for Vue. Given the same Vue Single File Component, Vapor Mode will compile it into JavaScript output that is more performant, uses less memory, and requires less runtime support code compared to the current Virtual DOM-based output. There is still a long road ahead of Vapor Mode but you will definitely hear about it in some of our future reports.

Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

Bonus: Don’t use return types (?)

Throughout the last few days, the TypeScript Twitter bubble is talking about one thing – the video of Matt Pottock “Don’t use return types, unless…”. The thesis is quite simple: If your function has only one return statement, then don’t write explicit return type for it and let TypeScript infer the type.

Twitter community went crazy about it. Some people completely disagreed about it:

And others extended it to “Never write explicit return types”

If you want to deep dive into the topic I really recommend a fragment from Theo’s live stream where Prime joins him and they start arguing. It’s almost an hour of talking about preferred code style and I love it.

Some of you might feel like such discussions are a bit toxic. After all, I feel like following the drama learned me a bit about TypeScript and a lot about others people’s perspectives. After all, sometimes it’s ok to agree to disagree.

PS: Meme battle is something that could become a real thing in the future