Code Extraction, Astro Framework Performance Report, and Comparing Rendering Patterns

Code Extraction, Astro Framework Performance Report, and Comparing Rendering Patterns

Newsletter

JavaScript Jam Live on Wednesday

This week we'll be joined by Miško Hevery to discuss Qwik and Qwik City. Topics will include an assortment of explanations and recommendations drawn from their recent blog posts such as:

Last week's open mic episode drew numerous participants to discuss signals, ChatGPT, WordPress performance, and more. Guests included Dev Agrawal, Henri Helvetica, Theo Browne, Dan Jutan, and many others.

Articles of the Week

WTF Is Code Extraction

Code extraction allows writing both client and server code in the same file while extracting out separate files at build time for more readable, maintainable, and testable code. In WTF Is Code Extraction, Miško Hevery contrasts code extraction in current meta-frameworks like Next.js and newer ones like Qwik City.

He enumerates the benefits and challenges of code extraction such as faster development, better performance, and security concerns. You can also check out the WTF is Code Extraction video on Builder's YouTube page for a conversation about the topic between Ryan Carniato, Miško Hevery, Adam Bradley, and Manu.

Were React Hooks a Mistake?

Following up on last week's content around Signals, Jake Lazaroff asks is React Hooks were a mistake or not and argues that they introduce more complexity and confusion than benefits. By comparing React hooks with signals, he contends that they're a simpler way of managing state and effects in components.

He claims that signals-based components are closer to the intuitive mental model of components as “things that have properties and behaviors." He also criticizes some of the design decisions and tradeoffs made by React hooks, such as the rules of hooks, dependency arrays, and stale closures.

Astro's 2023 Web Framework Performance Report

In tandem with releasing Astro 2.1 and the newly revamped Astro homepage, the team also published a web framework performance report based on real-world data from HTTP Archive, Google Chrome, and The Core Web Vitals Technology Report.

The report compares six JavaScript frameworks (Astro, Gatsby, Next.js, Nuxt, Remix, and SvelteKit) along with WordPress. Metrics sampled are First Input Delay (FID), Cumulative Layout Shift (CLS), Largest Contentful Paint (LCP), and a newer, experimental vital called Interaction to Next Paint (INP).

As with all performance related content, there were wide ranging opinions about the validity of the measurements, how to interpret the data, and the applicability of the results. After prefacing his message by saying he has a lot of respect for the work the Astro team has been doing, Evan You tweeted the following criticisms:

(1) Over-indexing on initial page load while comparing wildly mixed use case. Generic frameworks like Next and Nuxt are much more often used for building "apps" compared to content-focused "sites", which frameworks like Astro are explicitly designed for.

(2) Framework age bias. This is mentioned at the end of the report, but it probably deserves more prominent call out. In particular, latest Nuxt 3 provides significant perf improvements over Nuxt 2, but the dataset likely largely consists of existing Nuxt 2 sites.

(3) Selection / sample bias. The report did not specify how many sites were detected for each framework in the datasets, but I imagine the amount of Astro sites will be a small fraction of those of older frameworks.

See Fred's response and ensuing discussion with Evan:

Appreciate these callouts! A quick response:

1) This dataset only looks at the root page (homepage) per origin, so I don't think we suffer from wildly diff use-cases here.

2) Agreed.

3) All frameworks tested have meaningful # of datapoints, Astro came in smallest /w ~450 sites.

Rendering Patterns for Web Apps Explained

In Rendering Patterns for Web Apps (Server-Side, Client-Side, and SSG Explained), Germán Cocca explores different web app rendering patterns. He explains how each pattern works, their advantages and disadvantages, and when to use them. Patterns discussed in the article include:

  • Multi-page app (MPA)
  • Single-page app (SPA)
  • Server-side rendering (SSR)
  • Client-side rendering (CSR)
  • Static site generation (SSG)
  • Incremental static regeneration (ISR)

End to End Type Safety

Robin Wieruch introduces tRPC in Full-Stack TypeScript with tRPC and React. tRPC is a library that enables full-stack TypeScript development with React and Node.js. It allows defining type-safe functions on the server and calling them from the client without writing any boilerplate code.

Robin shows how to set up a tRPC project with Express, Vite, and React Query and walks through creating and using tRPC procedures, handling errors and authentication, and data fetching. The article also compares tRPC with other alternatives such as GraphQL and REST.

In related news, Zero-effort type safety announces a new feature in SvelteKit that enables "zero-effort" type safety for special methods/variables such as load, page and session. Type definitions are generated based on their usage in Svelte files and don't require any manual configuration or annotation.

Composability Summit

Filip Rakowski (CTO/Co-founder of Vue Storefront) covers building the perfect frontend for e-commerce in The Perfect Frontend for Composable Commerce. He details how a composable architecture helps you meet the core requirements an ideal e-commerce frontend should fulfill on design, speed, SEO, and content.

Podcasts of the Week

One More Thing

Ryan Carniato looks at the latest React architectural trend (server components) in his stream Into the Depths with Server Components and Functions. He speaks at length about the mechanics in an attempt to bring clarity on what they accomplish, what are the alternatives, and why are people excited about them.

JavaScript Jam on the Web

Find us online at the following links: