On Wednesday 12 June 2024 I went to the 16th edition of AdvancedJS Amsterdam, a JavaScript meetup sponsored by Xebia (its banner stood next to the screens). I mostly work on infrastructure and platforms, but the web layer is where platform teams meet their users, so I like to see how the frameworks are evolving. This post is a recap from the slides I photographed. I left out the sponsor, Wi-Fi and contact slides.
The agenda
The opening slide listed the evening in local time: 18:45 âSolidStart: A New Beginningâ by Daniel Afonso, 19:15 âWeb Frameworks at Googleâ by Minko Gechev, a short break at 19:45, lightning talks at 20:00, and drinks and networking at 20:45.
The eveningâs agenda, with the two main talks and the lightning-talk slot.
SolidStart: a new beginning
The first talk was a demo of SolidStart, the meta-framework built around Solid. The official site, start.solidjs.com, describes it as bringing fine-grained reactivity to full-stack development, built on Vite, with features such as server actions and request deduplication.
The slide I photographed from the demo is a small data layer for a cars app. It imports action, cache and redirect from @solidjs/router and wraps getCars and getCar in cache(...). Each function starts with a "use server" directive and reads from a storage item called cars:data. So the data access runs on the server while the component code stays next to it, which is the main idea behind these full-stack frameworks.
The SolidStart demo: cache and "use server" around the data functions.
Danielâs own intro slide listed a book, âState Management with React Queryâ. That is where the React Query connection in my notes comes from: it was on his introduction, and I did not photograph a React Query section of the talk. If you want the library itself, TanStack Query describes itself as the server-state standard for frontend apps: caching, refetching, mutating and observing server state.
Minko Gechev: web frameworks at Google
The main talk was âWeb Frameworks at Googleâ by Minko Gechev, whose slide gives his role as Engineering Product Lead at Google. It was about two frameworks used inside Google: Angular and Wiz.
One slide put them side by side. Angular was labelled âhighly interactive, more enterprise clientsâ, and Wiz âlatency sensitive, more consumer clientsâ. The talk then looked at whether the two could converge.
Angular for highly interactive enterprise clients, Wiz for latency-sensitive consumer clients.
The âchallenge and solutionâ slides described how Wiz gets a page to be usable fast. According to the slide, the server responds with HTML, CSS and minimal JS, so the server-side rendered page is immediately interactive. Wiz then loads JS for the key UI elements while the page continues loading, and preloads the JS for the rest of the app as needed.
Wizâs loading sequence: minimal JS first, key UI next, the rest preloaded.
Foundations of convergence
The slide I found most interesting was âFoundations of convergenceâ. It lists five layers where the frameworks could share work: reactivity, interactivity, component model, runtime and authoring format. Next to it is a flowchart of milestones. It asks, in turn, whether the two agree on a UI update model, whether Angular can adopt partial hydration, whether the frameworks can share a runtime, and whether they can share an authoring format. The exits are explicit: âWe accept that Wiz and Angular wonât fully convergeâ, âWe stop at sharing primitives only (e.g. signals)â, and âWe stop at Shared Runtimeâ.
Foundations of convergence: five layers and a flowchart of how far the two frameworks go.
My take: this is how platform decisions look in any large organisation. You rarely get âone stack for everythingâ. You find the layer where sharing is cheap, here the signals primitive, and stop before the cost outweighs the benefit. Angularâs own overview now highlights signals, server-side rendering and hydration, so that direction matches what the slides described.
JavaScript meta-frameworks in 2024
A later slide showed a comparison table of Angular, Astro, Next.js, Remix, Nuxt, SolidStart and SvelteKit, credited to the @addyosmani account and marked âEdits based on Minkoâs opinionsâ. The rows run from basics (component-based, SSR support, static site generation, file-based routing, TypeScript support) to recent trends: fine-grained reactivity, partial hydration, server components and an image component. In the fine-grained reactivity row the cells are annotated with the mechanism: Signals for Angular and SolidStart, shallowRef for Nuxt, Runes for SvelteKit, and a question mark with âForgetâ for Next.js and Remix. In the partial hydration row, the dots are under Angular, Astro and SolidStart, and Next.js is crossed out.
The meta-framework comparison table shown during the talk.
Lightning talks
After the break came four lightning talks, listed on the second agenda slide:
- â.http, a simple take on HTTPâ by Ozan Incesulu.
- âGetting to the Bottom of type rabbit holes with the TypeScript Compiler APIâ by Fardjad Davari.
- âWriting product-proof E2E tests with Cucumber & Playwrightâ by Patrick Huijten.
- âGreat Senior Engineers go Beyond Codingâ by Patrick Akil, whose slide gives his role as Consulting Software Engineer at Xebia.
The lightning-talk agenda, cropped to the slide.
I also photographed a slide titled âZero to Zod (ish) in Under 100 Linesâ by Josh Goldberg, an open-source developer according to the slide, and the end-of-evening speaker line-up included him.
The TypeScript compiler API
The compiler API talk was a short introduction, and its stated goal was to âintroduce the TypeScript compiler API in a few minutes and inspire people to explore itâ. The slide drew the overall architecture of the TypeScript compiler as a pipeline: Read TSConfig, Pre-process Files, Tokenize and Parse, Binder, Type Check, Transform, Emit, followed by the same steps in code. If you want to build custom linters, codemods or code generators, this is the pipeline you hook into. The language itself is documented at typescriptlang.org.
The compiler pipeline as drawn on the slide, cropped to the title and the diagram.
What I took away
- Full-stack frameworks keep moving server-only code closer to the component: SolidStartâs
"use server"functions are one example. - Even inside one company, two frameworks can stay separate if sharing primitives such as signals gets most of the benefit.
- Lightning talks are a cheap way to see where the TypeScript tooling ecosystem is heading.
