35 Matching Annotations
  1. Jul 2026
    1. I ported Kubernetes to the browser
      • Project Overview:
        • Named webernetes, it is a highly experimental, browser-based partial port of Kubernetes written in TypeScript, running entirely client-side without backend server components.
        • Developed at ngrok to provide a long-term, low-maintenance simulator for creating interactive and visual educational content about Kubernetes.
      • Architecture & Features:
        • Includes ports of core Kubernetes controllers (deployment, ReplicaSet, pod scheduler, and namespace) along with a partial port of the kubelet binary.
        • Features a simulated browser-based container network interface (CNI) for pod-to-pod communication over DNS/IP and a browser container runtime interface (CRI).
        • Avoids pulling massive images from registries like Docker Hub by utilizing a custom browser-based registry defined via a TypeScript API.
      • Why WebAssembly (Wasm) Was Not Used:
        • A simple "hello, world!" Go binary compiled to Wasm is ~540KiB gzipped, whereas the entire webernetes project is much lighter at ~140KiB gzipped.
        • Compiling the real Kubernetes codebase to Wasm failed due to compile-time errors from missing system-level APIs in the browser.
      • Development & LLM Challenges:
        • Around 90% of the code was translated line-for-line from the original Kubernetes Go source using LLMs, though the author had to strictly review every line.
        • LLMs consistently introduced errors such as cutting corners (e.g., replacing complex caches with a simple JavaScript Map), adding unrequested helper functions, and omitting cases in table tests.
      • Testing & Behavioral Parity:
        • To ensure lexical similarity translated to correct execution, hundreds of differential tests were written.
        • These tests validate behavioral parity by running the exact same client code against both webernetes and a real k3s cluster using the official kubernetes-client/javascript library.
  2. Jun 2026
  3. May 2023
  4. Jan 2022
  5. Jun 2021
  6. Dec 2020
    1. The compiler architecture moves complexity from the runtime and source code to buildtime and tools. Behind Svelte’s simple APIs sits a beefy compiler. Frontend web development has become very tool heavy in the webapp era, so in practice this adds little cost beyond what developers like myself already pay, but increased build complexity is important to acknowledge.

      tool-heavy dependence on build tools / heavy/complex build-time

  7. Nov 2020
    1. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
  8. Oct 2020
  9. Sep 2020
  10. Jun 2020
  11. May 2020
  12. Apr 2020
  13. Nov 2019
  14. Jan 2019
  15. Jul 2017
  16. Apr 2016
  17. Jan 2016
    1. Learn the actual underlying technologies, before learning abstractions. Don't learn jQuery, learn the DOM. Don't learn SASS, learn CSS. Don't learn HAML, learn HTML. Don't learn CoffeeScript, learn JavaScript. Don't learn Handlebars, learn JavaScript ES6 templates.

      Very true and a useful way to evaluate potential developers.

  18. Dec 2015
  19. Sep 2015
    1. Implementation of the mix-blend-mode property is more complex than background-blend-mode so it is taking a bit more time, but don’t let that get you down. Blend modes will be here soon

      Where possible, using multiply blending would avoid highlights making the underlying text less readable in PDFs where the <span> created by H does not actually contain the visible text of the element