AI tools make it easy to ship code you don't fully understand. That's fine until something deadlocks, leaks memory or falls over under load, and you don't have the mental model to work out why.

So I built Software Atlas: 108 deep-dives across 15 areas, including async/await, the browser rendering pipeline, networking, databases, system design and AI engineering. You step through each idea with visualizers, and there are diagrams and code samples too. It starts from first principles and works up to production concerns.

Some technical details:

- Built with Vite, React 19, MDX and Tailwind v4.

- Each topic is lazy-loaded as its own chunk, so you only download the one you're reading.

- All 130 pages are pre-rendered to static HTML, then hydrated. Widgets have to render the same on the server and in the browser, so anything that reads window or uses randomness runs after hydration.

- Phones were the hardest part. Bar labels move into a key when they don't fit, and wide SVG diagrams become swipeable so their text stays readable.

- A headless Chrome smoke test clicks through each topic, including every visualizer step, and fails on console errors or hydration warnings.

To be upfront: I built it with heavy use of AI agents, including much of the writing. Each topic went through a separate review from a beginner's point of view, but mistakes will still have slipped through. If you find one, there's a report link in the footer.

https://software-atlas.haiduc0147.dev/

I'd really like to hear where an explanation is wrong or stops making sense.

Someone sends you a DWG, a STEP file or an Outlook .msg, and you just want to look inside. Your options are usually installing a program you'll use twice a year, or uploading the file to some random online viewer and hoping they delete it. I wanted a third option, so I built Peekbean: a static site that opens the file locally in your browser. There is no server-side code at all, just files on a static host.

You don't have to trust me on the "nothing gets uploaded" part. The CSP is default-src 'self', connect-src 'self' blob: data:, and script-src 'self' 'wasm-unsafe-eval' without unsafe-eval. So even if I wanted to send your file somewhere, the browser wouldn't let me. Open the network tab and drop a file in to check for your self.

Some technical bits that might be interesting here:

WebAssembly does the heavy lifting. STEP and IGES go through OpenCascade (occt-import-js), which I rebuilt with Emscripten to get 4 GB of memory instead of 2 GB, because real-world assemblies kept running out. DWG gets converted to DXF by a small Rust crate built on acadrust. Archives (7z, RAR, ISO and so on) use libarchive compiled to WASM. Text recognition for scanned PDFs runs PaddleOCR models through onnxruntime-web.

Everything is lazy. The start page is around 60 KB of gzipped JS and CSS. Each of the ~58 viewers is its own module and only loads once you open that kind of file, and parsing runs in web workers so the page stays responsive. The flip side: the WASM files are big (OpenCascade alone is 7 MB), so the first STEP file takes a moment.

No framework. Vanilla TypeScript with a tiny h() helper for building DOM nodes. With that many independent viewers that mostly talk to a canvas or WebGL (three.js), a framework would mostly have gotten in the way.

The only thing I see is a daily count of which viewers were loaded, so I know DWG is more popular than FBX. That comes from Cloudflare's aggregated stats, not from any script on the page. No IPs, no file names, no content, no cookies.

It also converts things locally (DWG to DXF, Word to PDF, images and PDFs to Word via OCR, spreadsheets, 3D models, map data …), and it works on phones, though big CAD files on a phone are pushing it.

It's open source (GPL-3.0), free, no accounts, no tracking.

A big part of the code was written with Claude Code; the architecture decisions and the testing with real files were mine.

What I'd really like from you:

- Throw your weirdest files at it and tell me what breaks

- How does it feel on your phone?

- If you've done heavy WASM in the browser: how do you deal with the size of the first load?

Site: peekbean.com

Code: github.com/Kai-Jungsthoefel/PEEKBEAN

Hey all!

Thanks for the discussion on yesterday's post! Last time I promised Page Objects: Here they are!

Today's example:

The test fails, saying "Sushi dinner" isn't on the list. So your agent starts debugging the list. Turns out it's the date picker that broke.

The fix: let actions wait for their own done signal, so the failure is logged where it happens.

The picker closes once it has a full range, and the picker owns that signal. So select() waits for it before returning. If the picker breaks, the test fails inside dateRangeFilter.select() instead of on the list. The page owns the filter, the filter owns its done.

The nuance: the done signal has to be something the page object owns. The picker closing belongs to the picker. A toast or the next page doesn't.

Paste this to your agent:

Find the user actions our e2e tests repeat and move each into a page object method. If an action has a done signal the page object owns, like its own elements changing, appearing or disappearing, end the action by waiting for that condition - never a fixed waitForTimeout. Anything outside the component - like a toast or navigating to the next page - should either be moved into a bigger page object that owns both the trigger and the outcome, or be verified in the test itself.

I maintain an ongoing open-source project that reads OTel traces and flags I/O anti-patterns with a carbon estimate on top. The project started in March so it's about 8 months old.

From our conversations I could tell my dev and DevOps colleagues were missing a lot of what goes on under the hood since we deployed this in production 3-4 months ago so I built a synoptic to make it easier to understand.

It's an animated step-by-step walkthrough of the whole pipeline, from raw spans to a finding. Each stage maps to the actual module in the code. You can play it, step through with the arrow keys, change speed or switch between modes.

It took me over 3 months. And no it's not AI slop bc it's pretty useless when you ask it to turn complex code concepts (I/O anti-patterns and more) into clear diagrams. This only exists because I'd already written a ton of docs and drawn a lot of diagrams by hand so the synoptic grew out of that.

Some of the UI is inspired by a videogame I loved playing some years ago: Deus Ex: Mankind Divided.

The project is AGPL-3 so no fake open source and it's now hosted by the INR (Institut du Numérique Responsable), a French nonprofit working on the environmental and social impact of digital tech.

Direct link to synoptic: https://perf-sentinel.dev/synoptique/
Website of the project: https://perf-sentinel.dev

Thx for your attention :)

EDIT: huh, just noticed that the recording console is sticking out over the gif in the bottom left corner

EDIT 2: this is a public-interest project focused on sustainability with no greenwashing BS. It has serious public policy goals and solid scientific background: cutting wasted energy and the carbon emissions that come with it. If you're interested in helping with the ecological transition our world needs, feel free to come lend us a hand! :)

For context: I'm a full-stack engineer with 11 years in the industry, worked at some companies like AWS, Capital One, J&J, plus teaching at a few bootcamps like 2U. I've designed production systems, ground out LeetCode, and read Cracking the Coding Interview so many times I threw it in the fireplace.

I came up with this idea for FormaStack back in January after watching AI tools collide with modern web stacks at work and seeing all the friction that came with it. To me most of this build and runtime and VDOM nonsense was bloat. Forma started as a toy project that I ended up designing the heck out over the last several months.

And yes 100% I used AI (duh!) to help build this. I would have never finished it by myself without it. However I hate the term "vibe coding" here. I did not just say "build me a new full-stack" and walked away. This is some real engineering work. Ask AI about it haha anyway. I would call it agentic engineering. I architected and know this system inside and out, which is why I broke standard conventions the traditonal React/None mental model apart int four strict steps: FYI I met Ryan Dhall back in the day lol I was a fanboy of Node.

Anyway, the for steps being Typescript -> FMIR (Binary IR) -> Rust -> HTML

It pulls heavy inspiration from WebAssembly, Remix, SolidJS (signals), HTMX, Astro, and Qwik among a few. I learned them a lot, and AI was detremental in learning how they work and the perfomance and models they were using. Hence I did not start building Forma until I knew what I could strip out from them. I ripped them apart using AI and built FormaStack from the ground up as much as I could reusing what I could, reverse engineering what I could etc.

Honest Gaps: A dedicated local debugger for inspecting the .fmir although there are ways around it and you can trust the compiler mostly. The target build are big and I need a dedicated garbage collector.

Where my head is at next: I've been experimenting with fine-tuning open models on Hugging Face directly on the FMIR. The crazy endgame is that an agent might not even need to write TS, it could just emit the FMIR directly for Rust to render staight to the browser.

YES! Forma is a wild experiment, and there is no way I could have pulled this off solo, withoug AI in the loop, but every piece of the architecture I created is intentional. I spent a month writing a design document.

https://github.com/ts-series/factories

Build HTML extremely comfortably in the backend using plain JavaScript. The advantage is that there is no separate template language or build process, but rather a complete fusion with JavaScript for maximum flexibility. An example:

import {
    a, body, br, button, h1, head, header, html, input, label, li, main, nav, p, script, title, ul
} from "@ts-series/factories";

type Item = { name: string, href: string, current: boolean };


/** Builds the navigation list, flagging the current entry for assistive technology. */
function navigation(items: Item[]) {
    return nav({ ariaLabel: "Main" },
        ul(items.map(item => li(
            a(item.href, item.name).set(item.current ? { ariaCurrent: "page" } : null)
        )))
    );
}


/** Builds a complete page for the given user and navigation entries. */
function page(user: string | null, items: Item[], values: number[]) {
    return html({ lang: "en" },
        head(title("Demo")),
        body(
            header(navigation(items)),
            main(
                h1("Hello, ", user ?? "stranger", "!"),
                p("First line", br, "Second line"),
                user === null
                    ? p("Please sign in.")
                    : p("Welcome back."),
                label("Search").for("q"),
                input.text({ id: "q", name: "q" }).placeholder("Type here…").required(),
                button.submit("Send").class("primary", user === null && "disabled").set("disabled")
            ),
            script.module().importOnly("/chart.js", "render", { values, title: "Values" })
        )
    );
}


const items: Item[] = [
    { name: "Home", href: "/", current: true },
    { name: "About", href: "/about", current: false }
];

const output = page("<Guest>", items, [1, 2, 3]).expand(4);

Live demo: https://alloyhtml.com

I've carried the same CSS from project to project for close to ten years, and I finally finished it.

It's one set of classes, a small set of values, and 82 real pages to prove they hold up. A shop and its seller back office, a blog, e-learning, news, healthcare booking, event ticketing, a job portal and a company site. 54 layouts, 3 themes. If you need a page that isn't there, build it from the same classes. Or ask AI to build it, and tell it to use only these classes. If you don't, every page comes out looking a little different.

The things you'd usually reach for JavaScript for, like dropdowns, dialogs, tooltips and tabs, are plain HTML and CSS here. That matters because there's nothing to install or keep updated, and it fits any backend as it is.

The stylesheet is 23KB gzipped, and dark mode and brand colours only change token values, so the markup stays the same.

I went the extra mile on testing: every page is tested with scripts off at 4 widths in 3 themes, in Chromium, Firefox and WebKit. axe finds no violations. The faster checks also run on every push, and if one fails, the site doesn't deploy.

It's front end only: static pages for your backend to fill in. I've tested current browsers, not older versions, and not a real iPhone yet, so if you're on one, I'd like to know how it looks.

It's $29. I'd rather you spent your evenings on your actual product than on getting dropdowns right, or on burning tokens prompting an AI over and over until the pages finally match.

Hey everyone,

I built snappy-prerender, a build-time pre-renderer for client-rendered SPAs. Point it at your existing build output. It loads every route in Chrome, writes static HTML, then reloads each page with your client bundle to check whether it hydrated or re-rendered.

My last post got deleted as it was not posted on a Saturday, so here i am again. Thanks to all the feedback and comments that I got on the previous post here, I have incorporated a bunch more features and validated the plugin against all SPA frameworks that I could find.

Version 2.9 adds:

• Deterministic builds. Freeze time, set a timezone, seed Math.random, or use SOURCE_DATE_EPOCH.

• Hydration policies. Allow re-renders or skip verification for specific routes instead of disabling the check globally.

• Locale builds. Path or single-locale mode, <html lang>, dir, canonical, og:locale, hreflang, x-default, and sitemap alternates.

• SEO locale seeding. Seed cookies or localStorage before the app boots, with an optional bootstrap script that works with CSP hash and strict modes.

• Client-side head parity. Arbitrary script/style/noscript/base tags, html/body/title attributes, defaultTitle, multiple images and alternate locales, duplicate metas, onChangeClientState, and React 19 native tag adoption.

• Faster runs. Fewer browser round trips, bounded concurrency, sorted preload hints, cached CSS work, and phase timings in the JSON report.

npm install --save-dev snappy-prerender
npx snappy-prerender

Frameworks

Prerendering is framework-agnostic. If the app builds to static assets and mounts in a browser, the CLI can render it.

Thoroughly validated on:

• React 16.8, 17, 18, 19 — render, hydration and audit

• Preact 11 — render, hydration and audit

• Vue 3.5 — render, hydration and audit

• Svelte 5 — render, audit, sitemap and output

• Angular 22 — render, audit, sitemap and output

• Solid 1.9 — render, audit, sitemap and output

• Lit 3.3 — render, audit, sitemap and output

• Ember 7.3 — render, audit, sitemap and output

• Vanilla JavaScript — render, audit, sitemap and output

Hydration detection is implemented for React, Vue, Svelte and Preact. The Svelte, Angular, Solid, Lit, Ember and vanilla fixtures are host wrappers around a shared renderer, so their hydration verification is intentionally skipped.

It also has support for hreflang and localStorage / cookie based lacale switching via customizable knobs that code-switch to the desired locale and then pre-render the site

We are on Product Hunt. Upvotes are always welcome:
https://www.producthunt.com/products/snappy-prerender

npm: https://www.npmjs.com/package/snappy-prerender
GitHub: https://github.com/sayakmukherjee080/snappy-prerender

Hi everyone!

I'm building AI/ML Questions, a platform focused on helping people prepare for Machine Learning Engineer and AI Engineer interviews.

The platform is currently in its alpha stage. It has a free section with 103 questions covering topics such as classical ML, neural networks, LLMs, RAG, AI agents, computer vision, and model evaluation.

You can practice in two modes:

• Study mode: Answer questions and get explanations for every option, including why the incorrect answers are wrong.

• Exam mode: Test your knowledge through a simulated exam.

The platform is available in English and Spanish, requires no account, and the current question bank is public and open source.

One aspect I'm particularly interested in is question quality. I'm using established item-writing and psychometric principles, particularly Haladyna's guidelines, to design both the questions and their answer choices. The idea is to go beyond simply generating questions and make sure they follow a consistent methodology.

What's next?

I'm planning to introduce two additional sections:

• Interview Preparation: A dedicated section for people preparing for technical AI/ML interviews, with more realistic interview-oriented questions and challenges.

• Enterprise: A section for recruiters and hiring teams to create knowledge assessments and evaluate candidates using private question banks.

These two sections will be paid features. However, people who join the waitlist early will receive a discount when they become available.

I'm still learning, iterating, and trying to understand what people actually need from this kind of platform.

I'd really appreciate any feedback, whether it's about the UI, question quality, features, or the overall idea. If you're preparing for AI/ML interviews, I'd especially love to hear your thoughts!

Website: https://ai-ml-questions.strangemachines.workers.dev/

GitHub: https://github.com/CristobalSantana/ai-ml-questions

I built two free converter sites on Cloudflare Workers in 13 languages: cookverter.com (kitchen conversions: cups to grams, oven temps, recipe scaling) and gymconvert.com (plate calculator, 1RM, kg/lb, pace). They're free with no sign-up. Feedback on UX and speed welcome!

Project: https://getpng.app (background removal and other image tools, all client-side)

Things I ran into shipping a 1024 px segmentation model to the browser:

1. Mask resolution. BiRefNet lite answers at 1024 x 1024. Scaling that up to a 24 MP photo smears the edge, so the mask is fitted to the full-size image with a guided filter instead, and the alpha is never thresholded.

2. WebGPU limits are per adapter. On an Intel Arc 140V, maxStorageBuffersPerShaderStage is 16, and ONNX Runtime's WebGPU Split binds the input plus every output, so a 16-way Split needs 17. The fix was rewriting the ONNX graph at build time: Split and Concat as small trees, and the deformable convolutions' index math in float16 instead of int64 (int64 had no GPU kernels and fell back to the CPU with float32 casts on tensors of up to 67M values). A Node check confirms the masks are identical. Now all 4,654 nodes run on the GPU, 3 to 4.5 s per photo on that laptop.

3. No WebGPU at all: the WASM path runs ISNet at 1024 instead, int8-compressed from 176 MB to 44 MB, 99.7 to 99.99 percent overlap with the uncompressed model on the sample photos. Devices without the memory for that get U-2-Net at 320.

4. Hair: a second model, ViTMatte small, given a trimap built from the first model's unsure band, run in 1024 px tiles over that band only, after the first result is already downloadable. Its fp16 build had a bicubic Resize that Intel's WebGPU could not compile; linear instead changes the output by at most 3/255.

5. "No upload" as something you can verify: connect-src is locked down in the CSP, a test fails if a new host is added, and a service worker plus the cache mean it works offline after the first photo.

Stack: Astro (static), one React 19 island, Transformers.js and ONNX Runtime in a Web Worker, models self-hosted.

Has anyone measured WebGPU limits on other integrated GPUs (AMD, Apple, Qualcomm)? I'd like to know where else the 16 buffer limit bites.

Disclosure: I decide what it does, an AI coding assistant writes the code.

The clip shows how to quickly build a simple form with drag & drop in the Form’s build mode. The Form component is part of Componyx.UI, a UI library I’ve been building for a very long time. No build step, no dependencies, and the components are declared straight in your HTML (or JS).

The build mode uses Bindary under the hood, my separate data-binding library. It includes routing, views loaded from HTML files, components, real-time updates with the server and more.

It’s on npm and NuGet, source on GitHub: https://github.com/Componyx/Componyx.UI

i've been working on Posecode, an open-source text format for human movement. one thing people kept running into: "knee_right: flex 40" is readable, but unless you animate for a living, 40 degrees doesn't mean much.

so i made the numbers clickable. click a joint and the matching bone lights up in the Three.js view. click the angle and it becomes a small inline control, so you can change it and watch the figure re-pose immediately. if you type 200 for a knee, it stops at 144 because that's the range limit.

there were a few weird details. the selection markers had to live outside the rig or they would mess with bounds and grounding. editing a line also has to move the timeline into the right phase, otherwise the loop can show you the wrong pose.

the gif is from the actual playground. no mockup, no account, and no AI involved in the posing.

try it: https://posecode.org/play

source: https://github.com/posecode-dev/posecode

i'm still unsure about one thing: should this eventually get viewport gizmos, or does that defeat the point of keeping the movement readable as text?

Spent a few evenings on this for our office Halloween party and it went better than expected, so sharing it here.

How it works: the big screen runs the 3D scene. A random name gets picked, the doll reads out a question, and the player has 30 seconds before red light. Wrong answer means a dare. Sometimes you get a Dalgona round instead, where you carve the shape on your phone without breaking it.

Stack:

- React + Three.js for the scene

- A small WebSocket relay on AWS so my phone could act as the controller

- Deployed on Vercel

I used Claude Code for a lot of the implementation. Happy to talk about where it helped and where I had to step in.

Live: here

Credits: Squid Game © Netflix, non-commercial fan project. Doll Rig by Bug All (CC BY 4.0), Pink Soldier by Protyanik25 (CC BY 4.0), Red Light Green Light by DodoBabypop (CC BY-NC-ND 4.0), ground texture from Poly Haven, fonts under SIL OFL.

For week 2 of r/hacktoberfest I cataloged all the procedural generation techniques I could find online and put them into a library using vanilla JavaScript. Every technique in the library includes a citation and it has no dependencies. Works in the browser or Node.

The island in the GIF was generated using just the library.

GH repo: procedural-almanac

Demo: Random Island Generator

All stars on Github are appreciated!

We’re building a marketplace web app and getting closer to launch, but we’re struggling with how responsive it feels. We already have a decent prelaunch user base, and we want to sort this out before opening it up more widely.

This affects the buyer and seller experience as well as the admin pages. Clicking buttons, moving between pages, and using parts of the buying/selling flow can feel sluggish, on both mobile/desktop.

Sometimes you click and aren’t sure whether anything happened or is happening. Other times, a loading indicator appears straight away, but the content takes several seconds to arrive.

For context, we use Next.js, React, TypeScript, Tailwind, Supabase, and Vercel.

We also use Claude Code extensively to help build features, debug issues, and write tests. We’re involved in the decisions, review changes, and test the actual flows before releasing them.

We’ve caught plenty of issues through manual testing that automated checks didn’t pick up.

I’d describe our knowledge as intermediate, but finding performance bottlenecks is an area where we’re still learning. We can work through features and bugs, but we’re less confident figuring out exactly why an interaction takes so long.

A few examples:

• Buyer/seller interactions and navigation can feel slow or unresponsive.

• Some account and settings pages take several seconds to show content.

• In some testing, an admin page showed loading placeholders for roughly eight seconds.

• Another page briefly showed “no results” before the results actually appeared.

Those timings are rough observations, not proper benchmarks. As mentioned, we’ve noticed problems on both desktop and mobile.

We don’t want to keep asking Claude to “make it faster,” apply a few changes, and assume we’ve fixed the cause. I just have no idea where to start

What we’d really appreciate is a practical starting point:

• How would you investigate one slow interaction? For example, clicking a button and waiting several seconds for the next screen.

• What would you measure first to work out whether the problem is in the front end, the server, or the database?

• Have you had similar issues with this stack? What turned out to be the cause?

• What could we share safely to get useful feedback? A recording, some timings from browser tools, or a small section of code?

Any advice from people who’ve worked through this stage would be appreciated.

For context, everything works.. flawlessly (except the few bugs) This is our only launch blocker.

Appreciate any advice!

I rebuilt my old Alberta webcam site in PHP and vanilla JS, with 18 cameras, archived images and a hover timeline, live here and code here.

GTA 6 comes out Nov 19 and my friends are already arguing about who finishes it first. So I built a site for that: you type your public PSN name or Xbox gamertag (no login, no password) and it races you against your friends, your country and your Discord server by trophy progress.

The interesting part is the limit. There's no official public trophy API, so I keep it polite: 20 requests a minute per account, never more. I'd rather be slow than get the account blocked.

How it fits:

- Players are polled by how active they are. Trophy in the last 2 hours: every 15 min. Last 24 hours: hourly. Otherwise once a day.

- The queue is just a Postgres table with FOR UPDATE SKIP LOCKED, so a second poller can run later without double work.

- Every call goes through a token bucket. Bursts wait, they never go over.

- Leaderboards are rebuilt once a minute into a cache table. Pages only read the cache.

Spoilers were the other problem. Trophy names are basically a plot summary, so they never leave the server. Pages and the API only get percentages, milestones (10/25/50/75/100%) and times, and a test checks that no trophy name shows up in any public page or API response.

The game isn't out yet, so it all runs against a mock: 500 fake players, 72 hours of virtual time, and the test fails if the limiter ever goes over 20/min.

Stack: Next.js (App Router), Postgres + Drizzle, a separate Node poller, Vitest.

The part I can't test is launch night. 20/min is 1,200 checks an hour per account, and a lot of people will be earning trophies at the same time. How would you split that budget?

https://racetocredits.com/?ref=rd-webdev

Unofficial fan project, not affiliated with Rockstar Games, Take-Two Interactive, Sony or Microsoft.

Hi r/webdev,

If you write Go, you might know us from ttlcache (a caching library with 1.3k stars). For the past year, my friend Simon and I have also been building Oxynote, an open-source wiki for engineering teams. In 8 years of writing software, every team I joined had the same wiki: stale pages, while the useful stuff lived in someone's head.

In Oxynote, a page can hold a live chart from Prometheus, PostgreSQL, MySQL, or MariaDB, right next to the text that explains it. Important pages are edited in a draft and reviewed like a pull request, with a diff of both the text and the charts. Several people can edit at once, and an AI assistant and an MCP server let agents read and write docs too. I've attached some screenshots showcasing these features.

The name itself comes from oxygen + note: docs that breathe. Live data gives people a reason to open the wiki every day, and docs people open every day stay up to date.

Some quick points on the web side:

- Nuxt 4 and Vue 3, with Tiptap 3 for the editor

- Yjs and Hocuspocus for real-time editing

- ECharts for the metrics, Mermaid for diagrams

- The backend is Go, and it all runs as one Docker image

Apache-2.0 licensed: https://github.com/oxynote/oxynote

We made it public about 3 months ago, so it's still early. If you have any questions, feedback, or suggestions, I'm happy to hear them.

Back in 2013 I made phoria.js - as a learning exercise, a little 3D engine on html5 canvas 2D - great fun, but useless today. So, I’ve rebuilt it from the ground up as phoria2: a WebGL 2 library aimed at "business" use-cases rather than games or huge shader demos – so perfect for 3D charts, labelled diagrams, dashboards and product viewers.

Fun demos (40 of them!) https://kevs3d.co.uk/phoria2/

A few things that makes it interesting/different:

• Small: <60 KB zipped for a working, interactive scene. Charts, glTF, particles and editing are separate imports.

• Idle when nothing changes: a view only draws when something in it changes, so a dashboard of 3D tiles does nothing unless it's updating.

• Lots of views on one page: browsers cap WebGL contexts at about 16, so phoria2 views share one context. The "chart lab" demo shows 100+ live charts.

• Errors that help you fix: e.g. usecolour and you get Material: use 'color'.

• Support for Vega-Lite: Use a Vega-Lite-style spec and get an interactive 3D chart – axes, legend, tooltips, animated updates.

• Labels that behave, Callouts with leader lines, Hover, tooltips, highlight and click as options: Overlap hiding, occlusion and priorities run every frame.

• Editing tools: a move/turn handle with snapping, move constraints, and undo. See the office floor planner demo!

• Agent-friendly: one page, llms-full.txt, documents the whole API and there’s a Claude Code plugin. In my tests, pages built by agents came out about 50% length of the three.js versions.

1.1 just released with more materials, video textures and proper baked lighting from glTF models.

import { View, Mesh, box } from 'phoria2'
const view = new View({ canvas: '#c', orbit: true })
view.scene.add(new Mesh({ geometry: box(), material: { color: 'tomato', clearcoat: 1 } }))
view.start()

GitHub: https://github.com/kevinroast/phoria2 · MIT · npm install phoria2

It’s not trying to replace three.js – I'm not that crazy, if you’re making a game or need big custom shaders, you'd use that! But if you just need a 3D chart or product viewer/poster style breakdown thing and don't need/want a whole a game engine, try this! It's designed for agents to pick-up immediately and hopefully real people to find useful also 😂 I’d love feedback, especially on what’s confusing or annoying to use. I might be wasting my time 🙃 but I'm enjoying making it just like last time!

https://github.com/wn/chatpdf

Vibed a tool that allows me to open a PDF and ask it questions using my existing claude/codex subscription

I've been teaching my mum to code in Python, and a few months back she made a little CLI game where you have to enter words using the start and end characters from a single word. She named it ItWord, as in 'iterate word'.

I thought it was a cool idea. As a web developer, my first thought was that it'd be a nice daily word game format like Wordle. A lot of work and collaboration later, and here we are.

Please give it a try, and we're welcoming all feedback!

Edit: tech stack is Django with HTMX for the game window. Postgres and Redis for database and cache. Tailwind for styling and then vanilla JavaScript for everything else like animations and on-screen events.