Tooling, runtimes, and build systems
Build tools, runtimes, linters, bundlers, editor integrations, and TypeScript execution/transpilation workflows.
46%
Best tweets about TypeScript
50 Best Tweets About TypeScript (2026)
Browse the best tweets about TypeScript, from type-system techniques and releases to tooling, architecture, migrations, libraries, and developer workflows.
Technical TypeScript language features, type patterns, tooling, migrations, architecture, releases, and real codebase lessons.
- Creators
- 44
- Updated
Original Xholic analysis
What 50 top TypeScript posts reveal
The supplied TypeScript discussion spans tooling, agent workflows, quality practices, UI engineering, architecture, and releases. Posts frequently position types alongside other safeguards; agent posts explore typed code and API interfaces; and the analytics identifies UI, release, agent, and quality posts among the score outliers. [2037713766205608234, 2041372914067321312, 2080331924732850687]
- Dominant tone
- Positive
- Median score
- 14.1
- Leading format
- Other
- Recent posts
- 26%
72% of posts
All-time engagement
100% of posts
Published in 90 days
Conversation map
The themes creators return to
AI agents and MCP
AI coding agents built with TypeScript, agent harnesses, MCP/code-mode SDKs, typed tools, and agent-oriented project design.
26%
Quality, testing, and reliability
Testing, CI, static analysis, quality gates, security checks, and production-readiness practices for TypeScript projects.
26%
Frontend and UI engineering with TypeScript
Frontend and UI engineering in TypeScript, including React, Canvas, layout, terminal UI, and interactive applications.
22%
Full-stack APIs and integrations
Full-stack TypeScript APIs, typed SDKs, authentication, database clients, schema/type generation, and backend integration.
20%
Type-system patterns and safety
Advanced type safety practices: strictness, null handling, narrowing, generics, unions, type sharing, and generated types.
18%
Codebase architecture and migrations
Codebase structure, deep modules, dependency boundaries, monorepos, migrations, and maintainable architecture.
12%
Language releases and upgrades
TypeScript 6/7 release news, compiler evolution, language-service support, and upgrade guidance.
12%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 76
- Median reposts
- 5
- Median replies
- 4
- Median views
- 6.6K
Posts with media make up 52% of this collection. Their median all-time score is 9.43, compared with 31.2 for text-only posts.
Format mix
- Other 100% · score 14.1
Consensus and debate
Where creators agree, and where they do not
Shared view
Types are one layer in a quality stack
Several posts present TypeScript as one reliability layer alongside explicit null handling, linting, tests, CI, reviews, monitoring, and other checks. The confidence-stack post explicitly argues that no single layer should carry all risk.
Shared view
Typed code surfaces are used in agent designs
Agent-focused posts describe TypeScript as an interface for defining workspaces or interacting with APIs. Two posts describe designs that expose type discovery or documentation search plus code execution instead of a large set of directly exposed tool schemas.
Shared view
Boundary enforcement and decomposition are recurring practices
Posts advocate package boundaries enforced with dependency-cruiser and identify very large functions and route handlers containing database queries as codebase red flags. One deep-modules proposal limits external imports and tests to a package’s index entry point.
Open debate
Supabase type generation receives contrasting assessments
One post praises Supabase’s automatically generated TypeScript types for columns, views, and functions. Another argues that Supabase’s SDK defaults and type generation are poor. These are opposing user assessments.
Open debate
MCP concerns coexist with code-oriented agent designs
One post criticizes MCP for tool-call overhead and context bloat, while describing code-mode MCP results with fewer tools and lower reported context usage. Other posts describe agent tool models and dynamic MCP integrations, showing active experimentation with these approaches.
What performs
Patterns behind standout posts
Outliers cover UI engineering, releases, agents, and quality
The supplied analytics lists these five tweets as score outliers: pure-TypeScript text measurement, the TypeScript 6.0 release, Canvas text layout, Notion as code, and a code-quality red-flag checklist.
UI posts provide detailed implementation accounts
The UI-engineering evidence includes a pure-TypeScript text-measurement algorithm, a Canvas layout experiment based on text measurement and collision intervals, and a terminal-table implementation that moved initial instantiation from over 70 ms to under 1 ms according to its author.
Architecture and migrations has the highest theme median
Codebase architecture and migrations has the highest supplied theme median all-time score, 114.06. This is higher than the listed medians for tooling and runtimes (6.66), language releases (8.7), type-system patterns (12.95), and AI agents and MCP (12.193).
Statistical standouts
- View standout post 1 Score 11119.4 · 791.41× median
- View standout post 2 Score 899.3 · 64.01× median
- View standout post 3 Score 632.4 · 45.01× median
- View standout post 4 Score 596.3 · 42.44× median
- View standout post 5 Score 533.7 · 37.99× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Danila Poyarkov
@dan_note
2 posts
-
2. Encore
@encoredotdev
2 posts
-
3. GitHub Projects Community
@GithubProjects
2 posts
-
4. Matt Pocock
@mattpocockuk
2 posts
-
5. Prisma
@prisma
2 posts
-
6. TypeScript
@typescript
2 posts
Release posts frame the 6.0-to-7.0 transition
The TypeScript account announced the 6.0 release and its release candidate, describing better method checking, standard-library additions, and Node.js module features. A separate post characterizes 6.x as the final self-hosted major release before 7.0.
Encore connects framework implementation and project structure
Encore posted about building a TypeScript framework powered by 60,000 lines of Rust and separately linked project structure to how AI agents write TypeScript.
Matt Pocock advocates deep modules with import constraints
Matt Pocock’s two cited posts focus on dependency-cruiser and deep modules. The longer post proposes one public index entry point and a single externally accessible test seam per package.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best TypeScript tweets
Top TypeScript tweets from 44 creators
Ranked 01–50
- 01
@_chenglou ·
My dear front-end developers (and anyone who’s interested in the future of interfaces): I have crawled through depths of hell to bring you, for the foreseeable years, one of the more important foundational pieces of UI engineering (if not in implementation then certainly at least in concept): Fast, accurate and comprehensive userland text measurement algorithm in pure TypeScript, usable for laying out entire web pages without CSS, bypassing DOM measurements and reflow
Watch video
- 02
- 03
@AhmedShahnab ·
Nothing Fancy... just experimenting and exploring with the available ones before exploring the new trending ones.. The core trick here: ctx.measureText() pre-computes every word into a data object with a baseX, current x, and targetX. Each frame, a 120-segment dragon emits collision nodes with anatomically-computed radii. For every line of text, it projects each node onto the line's Y axis, compute the X exclusion span via √(r² - dy²), merge overlapping intervals, then run a relaxation solver (forward + backward pass) to find stable non-overlapping target positions. Words lerp toward those targets each frame - giving the parting/closing flow you see. Sometimes i feel platform APIs that's already shipped in every browser are still criminally underexplored. #CreativeCoding #Canvas #WebDev #TypeScript #InteractiveDesign #GenerativeArt #Frontend #TechArt
Watch video
- 04
@NotionHQ ·
Now in beta: Notion as code. Define an entire workspace in TypeScript: teamspaces, databases, custom agents, all of it… then deploy it through the API. Build workspaces with coding agents, version-control your setup in git, and reproduce the same setup anywhere you need it. https://t.co/1ENjbBA93k
- 05
@Hartdrawss ·
25 red flags hiding in your VIBE CODED app : Bookmark this before your next PR ! 1/ no .env.example file > new dev joins. cant run the app. nobody knows what env vars exist. 2/ API keys in git history > deleted from .env doesn't mean deleted from history. rotate those keys. 3/ no README with setup instructions > three steps to run locally that only you know. 4/ functions with 500+ lines > AI fills files. nobody splits them. untestable, unreadable, unmaintainable. 5/ catch blocks that swallow the error > silent failures. user sees nothing. you get no alerts. bug persists. 6/ hardcoded localhost URLs > breaks in staging. breaks in production. search "localhost" in the repo right now. 7/ no TypeScript or type definitions > you refactor one prop and nothing tells you about the 12 places it broke. 8/ console.log statements in production > performance overhead and sensitive data leaking into browser consoles. 9/ zero tests > you change one utility function and don't know what broke until a user tells you. 10/ missing loading and error states in the UI > API call takes 3 seconds. user sees blank screen and refreshes. request fires twice. 11/ dead code everywhere > AI generates functions. AI forgets them. nobody knows whats active. 12/ no linting or formatting config > every file has different indentation. code reviews become style arguments. 13/ mixed naming conventions > camelCase, snake_case, PascalCase. all from AI. all in the same repo. 14/ god components doing everything > 500-line React components handling state, data fetching, and UI simultaneously. 15/ DB queries directly in route handlers > business logic tangled with framework code. change one thing, you touch everything. 16/ secrets in committed config files > not .env. config.js or settings.json that didnt seem like a secret file. 17/ no CI/CD pipeline > deploy = "i hope nothing breaks." you find out in production. 18/ direct DOM manipulation inside React > mixing jQuery patterns with React. breaks silently on re-renders. 19/ state mutated directly > `state.items.push(item)` instead of a new array. causes unpredictable renders. 20/ memory leaks from uncleaned intervals > setInterval inside useEffect with no cleanup. fires after the component unmounts. 21/ blocking the event loop with sync operations > `fs[.]readFileSync` in a request handler. one request pauses all others. 22/ no pagination on list endpoints > fetch all 50,000 records to display 20. works fine in dev with 5 test rows. 23/ missing Content-Type headers on API responses > clients parse JSON as text. debugging nightmare across different clients. 24/ no error boundary in React > one uncaught error in a child component crashes the entire app. 25/ inconsistent API response shapes > some endpoints return `{data: {}}`. others return the object directly. good luck building a client.
- 06
@KentonVarda ·
One point of confusion I'm seeing: Lots of people assume you're supposed to run the AI agent harness itself inside a sandbox, and wonder how to do that with Dynamic Workers. The harness does *not* need to be in the sandbox. It can be a regular old Worker (probably a Durable Object, probably using Cloudflare Agents SDK[0]). Remember that an LLM can't manipulate the world at all unless you give it tools. So if you are careful about what tools you give it, it is inherently sandboxed. What we are proposing here is that you basically give the agent two tools: One to explore the APIs it has available to it (returning TypeScript type definitions), and one to execute code against those APIs (input is JavaScript). The latter tool runs the code in a Dynamic Isolate. You can't quite just run Claude Code or Codex in there, since they aren't designed to run in Workers, at least today. But @southpolesteve managed to get OpenCode (a similar harness) running 100% in Workers[1]. It's also not as hard as you might think to write your own harness -- I've done it. That said, if your agent's task specifically involves using a bunch of Linux programs, it may still be best to use containers for that. For instance, if your agent is doing software engineering -- checking out a git repo, running a compiler, etc. -- it may be impractical to make that all work in Workers. Try our Sandbox SDK[2] for that. But if your agent is planning a family vacation, it probably doesn't need to run rustc. It probably just needs to interact with a bunch of APIs. And that's where Dynamic Workers shine. https://t.co/i6Gz8xz9BZ [0] https://t.co/IiGLvkrHnA [1] https://t.co/cuZkcinSFk [2] https://t.co/DAlLnPKdW2
- 07
- 08
- 09
@justinstorre ·
I am experimenting with something I call "Typescript Ultra Strict". Basically, typescript with no nulls, no classes, no undefineds, no switch statements, and no vars + the addition of match macros. Basically forcing AI to write functional AI code through compilation errors that is more deterministic and testable. Back in 2008 Chrome built the V8 Javascript engine and the entire world built edge compute on top of this amazing primitive. However, Javascript had it's short comings so we made Typescript, but Typescript still was "too friendly", mainly to appeal to a human audience. We no longer have humans writing code, so why not give the AI something less clunky and more clanky 😉 UX - write .tsus files - add a one-line plugin to webpack, Vite, esbuild, or Bun Features include: - Option/Result runtime, with boundary helpers that turn the outside world's nulls and throws into Option and Result - match macros - good error messages, so an agent can fix its own errors in a loop
- 10
@mattpocockuk ·
Here's a skill you can run once to set up deep modules in any TypeScript codebase: - Each 'package' lives at src/packages/<name> (name/path is totally customizable) - From outside the package, you can only import from <name>/index.ts - Tests for the package live at <name>/tests, and can only import from index.ts - No circular dependencies between packages - Puts a context pointer inside AGENTS.md so the agent knows about it (no skills needed) - Works with frontend or backend code (even Effect code!) - Enforced by dependency-cruiser This means you can hide stuff inside modules, with only a single test seam exposed. Clear seams, deterministically enforced: no more shit tests. Awaiting a merge. Should I ship it? https://t.co/6VGvNb6tMl
- 11
- 12
@kmdrfx ·
"Please fix Markdown tables!" Okay: text-only, wrapping, columnar selection, proper border conjunctions, fill full width, in opencode beta now. "What took so long?" Here's a writeup: OpenTUI uses yoga layout and has elements called Renderables. Boxes with borders, plain text, code with tree-sitter backed highlighting and other primitives. Organised in a tree structure resembling somewhat of a DOM. Approaching a table naively, given the primitives are there, one would think to just stack box and text elements the right way in a flex-box layout to visually represent a table. Boxes support borders. Problem solved. This is what an LLM would one-shot in a working state, given OpenTUI's API surface. Ignoring the fact that just using box local borders don't handle border conjunctions properly. Benchmarking something like that quickly shows that instantiating an average table takes >70ms and incremental updates become expensive. Hugely due to yoga-layout via wasm having a painful price on yoga API calls. The whole ordeal becomes memory hungry, because a Text element handles more than just plain text. A simple 4x6 table needs a Box and Text per cell, ending up with 48 heavy nodes that yoga must lay out. "But that's just OpenTUI being slow" - you might say. Yes, but no. Yoga should be integrated in the zig native binary core of OpenTUI. It is on the roadmap to do so, which will speed up render passes by 2-5x. Yoga-layout has an open PR to support CSS Grids, which would greatly ease building something like a table. We will use that for fully laid out tables when it gets there. Below the typescript core level Renderables, there are lower level primitives like TextBuffers and TextBufferViews, bound via FFI and completely handled in Zig. I was stuck expecting a table primitive to handle a full layout like a table in the browser does. For Markdown all we need is a text-only table. So we had to come up with a better idea, something that is feasible now. A table layout is pretty straight forward. No need to have yoga deal with that. Using TextBufferViews for cells directly gives lower level control and eliminates some overhead that Boxes and Text renderables have. A simple native method to draw a grid with proper conjunctions is a nice library method. It will surely be used for other cases, so that's what we added. Using this simplified approach we were able to bring down initial instantiation to <1ms, more than 70x improvement. With a far smaller memory footprint. Given all the low level primitives are known and implementing a text-only table like this is possible, Codex was of great help to carve out the PoC, setup the benchmarks and tests. That's only a fraction of what was needed though. The table needs options to span the full available width, render different border styles, show/hide borders, padding, selection etc. So many iterations later OpenTUI now has a text-only, performant and relatively cheap TextTable that we can leverage to render Markdown tables in a streaming/incremental manner. Efficiently and properly.
Watch video
- 13
- 14
@sentient_agency ·
Say goodbye to black-box AI coding agents. Someone just built Claude Code's open twin and published every line of it. MiniCode is a terminal coding assistant with the same agent loop, tool model, and TUI architecture built to be understood, not just used. The gap vs Claude Code is only two things: price and team size. Everything architectural is replicated: → model → tool → model loop running until task is done → review-before-write with unified diff before any file changes land → dynamic MCP over stdio connects any server, auto-registers tools → local skills via SKILL.md same pattern Claude Code uses → reject with guidance push corrective instructions back mid-loop → run_command with single-string invocations and auto arg splitting → explicit background shell commands surfaced as lightweight shell tasks Three implementations. One ecosystem. TypeScript is the reference. Rust stores conversation history inside the working directory so project context moves with the codebase. Python version is shipping soon. The entire project structure is documented with an architecture guide that walks you through every module and why each decision was made. This is the fastest way to go from "I use AI coding agents" to "I understand how AI coding agents work." MIT License. 100% Opensource
- 15
@dan_note ·
New package: Volt ⚡ — frontend build tool for Elixir. Dev server with HMR, code splitting, Tailwind CSS v4, TypeScript. Vue SFC support included. No Node.js required. Part of a new ecosystem alongside QuickBEAM, oxc_ex, and npm_ex. The stack: • OXC — Rust JS toolchain (same engine behind Vite 8's Rolldown), as a NIF • Vize — Vue SFC compiler, Vapor IR, SSR, CSS Modules, @import bundling — all via Rust NIFs (LightningCSS inside) • Oxide — Tailwind v4 class scanning (Rust NIF) • QuickBEAM — JS runtime on the BEAM In a Phoenix project, replaces esbuild wrapper + tailwind CLI + node_modules: 𝚌𝚘𝚗𝚏𝚒𝚐 :𝚟𝚘𝚕𝚝, 𝚎𝚗𝚝𝚛𝚢: "𝚊𝚜𝚜𝚎𝚝𝚜/𝚓𝚜/𝚊𝚙𝚙.𝚝𝚜", 𝚝𝚊𝚛𝚐𝚎𝚝: :𝚎𝚜𝟸𝟶𝟸𝟶, 𝚎𝚡𝚝𝚎𝚛𝚗𝚊𝚕: ~𝚠(𝚙𝚑𝚘𝚎𝚗𝚒𝚡 𝚙𝚑𝚘𝚎𝚗𝚒𝚡_𝚑𝚝𝚖𝚕 𝚙𝚑𝚘𝚎𝚗𝚒𝚡_𝚕𝚒𝚟𝚎_𝚟𝚒𝚎𝚠), 𝚝𝚊𝚒𝚕𝚠𝚒𝚗𝚍: [𝚌𝚜𝚜: "𝚊𝚜𝚜𝚎𝚝𝚜/𝚌𝚜𝚜/𝚊𝚙𝚙.𝚌𝚜𝚜", 𝚜𝚘𝚞𝚛𝚌𝚎𝚜: [...]] Early research preview — expect rough edges, missing features, and API changes. More coming soon. https://t.co/zRQzquc1IN
- 16
@melvynx ·
Why you should NOT use Supabase: 1. SDK Trap - not TypeScript by default, type-gen is bad, easy to make mistakes 2. Security with the SDK is terrible - need to set up a lot of things to have something work 3. Vendor lock-in with the Auth, don't have your keys 4. Pricing way more expensive than a $8/month db + better-auth 5. Better alternative for all tools they provide
Watch video
- 17
@cramforce ·
Test your SKILL.md Now that code is free, you can just test things. Here is Chat SDK's chat-skill.test.ts https://t.co/7HlenkDeNY - Does the inline TypeScript compile? - Do the mentioned paths references into node_modules/ exist when you pack the repo with npm? - Does it list all built-in adapters that exist in the repo? - Does it list all community adapters listed in the docs? - Etc.
- 18
- 19
- 20
@freeCodeCamp ·
Did you know – you can get end-to-end type safety in full-stack TypeScript apps without schema files or code generation. In this guide, @itsTarun24 shows you how to use tRPC and Hono to build APIs where the backend and frontend share types automatically. You'll learn when to use each tool and how they improve reliability, catch errors at compile time, and speed up development. https://t.co/jPqlzN44oH
- 21
@gsd_foundation ·
A whole plague of bugs and second-cousin bugs have been fixed and prevented from surfacing in the future for GSD-2 in v2.44.0. Updates and responses to issues and PRs slowed down over the past 48 hours while deep work was done behind the scenes to rebuild one of the core parts of the GSD-2 system. Here's what happened and why it matters. The problem we solved GSD tracks your project's progress – milestones, slices, tasks, what's done, what's next. Until now, all of that state lived in markdown files. The AI had to read, parse, and rewrite those files to track its own progress. Think: regex-matching checkbox states across multiple files, toggling - [ ] to - [x], and hoping the formatting stayed parseable. This was the single biggest source of bugs. The AI is brilliant at writing code and plans – it's unreliable at mechanical bookkeeping. When a checkbox toggle went wrong silently, five different state markers would disagree, and a cascade of reconciliation systems (doctor, stuck detection, self-heal, recovery) would fire trying to fix things. We had ~2,500 lines of code just for reconciliation. What v2.44.0 changes We replaced the entire system. State transitions are now atomic SQLite transactions driven by structured tool calls. The AI says "complete task T01" via a typed tool call → TypeScript validates → writes to DB in a single transaction → renders the markdown as a view. If anything fails, it rolls back cleanly. Two PRs made this happen: PR #2141 – Tool-driven completionsReplaced markdown mutation for task/slice completion with gsd_complete_task and gsd_slice_complete tool calls. Rewrote deriveState() from a 50-200ms filesystem scan to a <1ms SQL query. Removed ~800 lines of dead reconciliation code from doctor. Added crash recovery, rogue file detection (catches when the AI tries to bypass tools and write files directly), and undo commands. PR #2280 – Tool-driven planningThe last major component using markdown as source of truth. Added 5 planning tools (gsd_plan_milestone, gsd_plan_slice, gsd_plan_task, gsd_replan_slice, gsd_reassess_roadmap). The 12-variant regex cascade in the roadmap parser is now legacy code used only for migration. Structural enforcement means the AI physically cannot delete completed work during replanning — TypeScript rejects it before it hits the DB. What this means for you • Fewer mysterious state bugs (no more "why does GSD think this task isn't done?") • Faster state resolution (DB queries instead of filesystem scans) • Safer replanning (completed work is structurally protected, not just prompt-instructed) • Better crash recovery (DB transactions mean no more half-written state) • The ~2,500 lines of reconciliation code that existed to patch over markdown unreliability are being systematically removed Existing projects auto-migrate on first access. No manual steps needed. This was a big one. Back to regular PR velocity now. Update with: `npm i -g gsd-pi@latest`
- 22
- 23
@GithubProjects ·
This is a TypeScript library implementing the OAuth 2.1 provider side with PKCE, wrapping Cloudflare Workers to automatically handle token management and authorization for API endpoints. - Acts as a wrapper around Worker code to add authorization - All token management handled automatically, no secrets stored - Agnostic to user authentication and UI framework choices - Supports dynamic client registration via RFC-7591 endpoint Explore it here: https://t.co/Khb9rSWTto
- 24
@mehulmpt ·
Nub by @colinhacks is a big deal and a long time coming. Bun made running TypeScript cool locally, without worrying about transpiling or fighting with your own code. Today in 2026, `tsx` package, and other tooling combined with pnpm, a faster laptop, and a little patience and ecosystem knowledge, allows you to get the stability of Node with the experience you'd want from a runtime like Bun. That bun <> node gap closed a little today with Nub, which I spent some time reading about and playing with. Made me remember the 2021-2022ish broken esbuild local setup systems we used to have to run the code locally. We have come a long way from that. Talking about that in a video today
- 25
@the_smart_ape ·
🚨BREAKING: Claude Code just got fully leaked on GitHub. 512,000+ lines of TypeScript. here's what you need to know: the stack → TypeScript strict mode, Bun runtime, React + Ink for terminal UI → ~40 agent tools, ~50 slash commands, ~140 UI components → GrowthBook for A/B testing and feature flags internally tons of unreleased stuff gated behind internal flags: → KAIROS: a proactive agent mode. SleepTool (agent sleeps and wakes up), PushNotificationTool (sends you push notifs), SubscribePRTool (watches GitHub PRs via webhooks), SendUserFileTool. basically Claude that works while you sleep. → COORDINATOR_MODE: full multi-agent orchestration. TeamCreateTool, TeamDeleteTool, SendMessageTool. agents spawning and managing other agents in teams. → VOICE_MODE (codename "amber quartz"): voice input/output, requires OAuth to claude's voice_stream endpoint. not available with API keys. → ULTRAPLAN: remote multi-agent planning that runs on Opus with a 30-minute timeout. offloads heavy exploration to cloud instances. → WEB_BROWSER_TOOL: a built-in browser tool, currently feature-gated. → x402: this one is wild. a full crypto wallet built into Claude Code for HTTP 402 payments. USDC on Base. /x402 setup generates a wallet, set spend limits per request or per session. Claude can autonomously pay for API calls with crypto. ant-only tools (Anthropic employees) → REPLTool and SuggestBackgroundPRTool are gated behind USER_TYPE === 'ant'. internal dogfooding tools that regular users never see. there's a companion/tamagotchi system with species, hats, eyes, and rarity tiers (common → legendary). a seeded RNG generates your buddy based on your profile. they built a virtual pet into a coding CLI.
- 26
@GithubProjects ·
This is the monorepo behind the TypeScript website, containing the playground, sandbox, and documentation tooling. - Uses pnpm workspaces with node 20+ and watchman for file watching. - All packages support `pnpm build`, `pnpm test`, and debug logging via the `debug` package. - Deployment is automatic: pushes to the `v2` branch deploy to production. - Changesets manage version bumps for public packages like `@typescript/twoslash` and `@typescript/sandbox`.
- 27
- 28
- 29
@webmaster ·
Profound's SDK code mode MCP server flipped my negative opinion on MCP What I don't like about MCP is the excessive tool calls, context bloat and LLMs struggling with tool call code due to limited training data Cloudflare and Anthropic recently wrote about their experiments with using MCP to execute code. The idea was that LLMs are great at writing code, so give them a typed SDK and let them write it Anthropic test results using Google Drive and Salesforce examples: - Native MCP: 150k tokens - Code Mode MCP: 2k tokens Cloudflare code mode test results with Cloudflare API in a 200k context: - Raw OpenAPI Spec: ~2M tokens, 977% context - Native MCP (full schemas): 2,594 tools, 1.17M tokens, 585% - Native MCP (req params only): 2,594 tools, 244k tokens, 122% - Code Mode: 2 tools, 1,069 tokens, 0.5% Massive reduction in context use! Profound follows the same approach with 2 tools: - search_docs: Searches documentation to find methods, params and examples - execute: Runs TypeScript to interact with the Profound API Since MCP discovery and configuration is built into most harnesses, agents can discover the MCP tools, reason, determine the optimal query, and learn the SDK in real time I've found that this works better than managing personal docs and scripts because you're leveraging all the things that already exist for SDKs: docs, examples, and types See the example MCP server response from Profound when prompting the LLM with "optimize my content for AEO using Profound API". The search_docs tool will return methods the LLM can use to write TypeScript I've been able to delete agent skills, reduce context, and improve task execution by simply using the MCP. I now want this for all APIs and SDKs!
- 30
@realBigBrainAI ·
12 parallel agents fixed 3,528 TypeScript errors in half an hour, which cost a full 5-hour credit window on Claude Code.
Watch video
- 31
@0xlelouch_ ·
90% of frontend engineering interviews in 2026 come down to these 7 points: 1) Debugging in the browser Repro the bug, read stack traces + network, isolate a minimal case, ship a fix without breaking perf. 2) State + data flow Local vs server state, cache invalidation, optimistic updates, race conditions, and why a stale closure bit you. 3) Performance Core Web Vitals, bundle size, code-splitting, memoization tradeoffs, and how you’d prove the win with a profile. 4) TypeScript in anger Narrowing, generics, discriminated unions, and when to stop fighting the type system and refactor. 5) HTTP + auth basics CORS, cookies vs tokens, CSRF, refresh flows, and why a 401 loop happens behind a reverse proxy. 6) Testing strategy Unit vs integration vs e2e, what to mock, flaky test causes, and how to test async UI without sleeps. 7) Frontend system design Component boundaries, routing, error/loading states, observability, and deploy/rollback with CI + feature flags
- 32
- 33
- 34
- 35
@RoundtableSpace ·
THE FUTURE OF TEXT LAYOUT IS NOT CSS. SOMEONE BUILT A TEXT MEASUREMENT ALGORITHM IN PURE TYPESCRIPT THAT LAYS OUT ENTIRE WEB PAGES WITHOUT CSS, DOM, OR REFLOW. 19.3 MILLION VIEWS IN 2 DAYS. THE FRONT-END WORLD HASN'T SEEN ANYTHING LIKE THIS IN YEARS.
Watch video
- 36
@seveibar ·
whirlwind day of optimizations first I wrote a typescript autorouter that I thought was pretty fast then I got chatgpt pro to rewrite it in rust/WASM and that was 40x faster! (darn, bye js?) then I asked chatgpt pro to look at the Rust code and make the Typescript code as fast as the Rust code, and now the Typescript is 25% faster So now I'm around 50x where I started, and the only downside is now I can't read any of the code lol
- 37
@dan_note ·
QuickBEAM v0.7.1–0.8 updates N-API addon support 𝚀𝚞𝚒𝚌𝚔𝙱𝙴𝙰𝙼.𝚕𝚘𝚊𝚍_𝚊𝚍𝚍𝚘𝚗(𝚛𝚝, "𝚌𝚛𝚌𝟹𝟸.𝚗𝚘𝚍𝚎", 𝚊𝚜: "𝚌𝚛𝚌𝟹𝟸") {:𝚘𝚔, 𝟿𝟶𝟽_𝟶𝟼𝟶_𝟾𝟽𝟶} = 𝚀𝚞𝚒𝚌𝚔𝙱𝙴𝙰𝙼.𝚎𝚟𝚊𝚕(𝚛𝚝, ~𝚜[𝚌𝚛𝚌𝟹𝟸.𝚌𝚛𝚌𝟹𝟸("𝚑𝚎𝚕𝚕𝚘")]) Load native .node addons (napi-rs, plain C) into a BEAM runtime. Tested with node-rs/bcrypt, argon2, crc32, sqlite-napi. Full N-API surface: constructors, typed arrays, async work, threadsafe functions. New Beam APIs 𝙱𝚎𝚊𝚖.𝚗𝚊𝚗𝚘𝚜𝚎𝚌𝚘𝚗𝚍𝚜(), 𝙱𝚎𝚊𝚖.𝚞𝚗𝚒𝚚𝚞𝚎𝙸𝚗𝚝𝚎𝚐𝚎𝚛(), 𝙱𝚎𝚊𝚖.𝚖𝚊𝚔𝚎𝚁𝚎𝚏(), 𝙱𝚎𝚊𝚖.𝚒𝚗𝚜𝚙𝚎𝚌𝚝() TypeScript in Context now works — auto-transforms .ts/.tsx and bundles imports, matching Runtime behavior. https://t.co/I8w6NReRQ1
- 38
- 39
@ATechAjay ·
A frontend PR should not rely on "works on my machine" in 2026. My baseline confidence stack: → TypeScript catches bad assumptions before runtime → ESLint catches consistency issues and common footguns → Storybook makes component states reviewable in isolation → Vitest catches isolated logic → MSW makes network states predictable in local development and tests → Chromatic flags unintended visual changes → Playwright covers critical browser journeys → axe catches common accessibility violations → Lighthouse CI watches for performance regressions → Snyk flags risky dependencies → CodeRabbit adds review context before humans spend time on the PR → Bug0 provides managed QA when a team needs an engineer to author and maintain high-value E2E coverage → GitHub Actions makes the checks a merge requirement → Vercel preview deployments let reviewers use the real change → Sentry tells you what escaped anyway Different tools. Different jobs. The mistake is expecting one layer, usually unit tests or review... to carry all of the risk. The goal is not a huge checklist. It is enough independent signals to merge with confidence.
- 40
@DionysianAgent ·
new codecli update - Session Memory - Live Context Compaction - Improved Tool Calling and Sub-Agents - Fixed TUI and bugs we're going to be sprinting codecli over the next period of time while we finish up the web platform and especially the build and dev environment we've been cooking the goal is to make codecli market competitive beyond everything else, better than opencode, better than claude code, better than all of them (you can run claude code from within code cli for an even better harness than claude code btw) then once codecli is where we want it to be we will begin the migration over to rust, where we'll return back to the eigencode naming so that codecli is our typescript code cli and eigencode remains our rust cli the reason we switched from eigencode to codecli to begin with was mainly because rust doesn't have the graphics and tui libraries that we needed and building them from scratch was too much of a waste of time for us at that point but soon we'll port it all over once things are more settled anyway enjoy
- 41
- 42
- 43
- 44
- 45
@ThePracticalDev ·
TypeScript-specific ADK resources make up less than 5% of search volume vs Python. This dev fills the gap with a full multi-agent scaffolding guide using Google's TypeScript ADK, MCP, and Gemini CLI from single agents to A2A server integration. { author: @tanaikech + @GoogleDevExpert } https://t.co/fEk7Ug7dgb
- 46
@ibuildthecloud ·
So I'm writing a coding agent based on WANIX from from @progrium I have to say this is the first time I've been happy the JavaScript echo system has been rewritten in rust. I think I can get a pretty awesome TypeScript coding agent to run fully in the browser, yet still in a fairly native way. Pretty cool, fully develop a web page with an agent, get live preview, and then you theoretically could publish to the web (it's just a collection of files in opfs)
- 47
@buildwithhassan ·
claude code shipped its full TypeScript source again via .js.map in the npm package (v2.1.88) second time this packaging footgun happened and this is a terminal agent people run with --dangerously-skip-permissions / auto-accept sourcemaps = architecture + security assumptions exposed
- 48
- 49
- 50
Best Tweets by Topic