DEV Community: Pavel

Microsoft Just Dropped TypeScript 7: Why a Native Go Rewrite Changes Everything

Pavel — Sat, 25 Jul 2026 13:31:37 +0000

Introduction

If you’ve ever worked on a large-scale TypeScript codebase, you know the exact pain: your local build takes over a minute, your editor spins for 12 seconds just to display red squigglies, and Node.js throws JavaScript heap out of memory.

That era is officially over.

Microsoft has just released TypeScript 7.0 — and it comes with a staggering 10x performance boost. But this isn't just an incremental update with a few micro-optimizations. Microsoft completely rewrote the TypeScript compiler and language server natively in Go.

Here is a breakdown of why Microsoft made this drastic shift, how the new architecture works under the hood, and what it means for your daily development workflow.

Why Rewrite a Self-Hosted Compiler in Go?

For the last decade, TypeScript was famous for being self-hosted — written in TypeScript and executed via JavaScript on Node.js. While this made dogfooding easy for the core team, JavaScript was ultimately designed for browser UIs, not heavy compute-intensive compiler workloads.

As Anders Hejlsberg (Technical Fellow at Microsoft) pointed out:

JavaScript runtime limitations mean single-threaded execution and high memory overhead. For massive codebases like Visual Studio Code (1.3M+ LOC), type checking became a major bottleneck.

Why Go instead of Rust or C#?

While Rust is currently dominating JS tooling (SWC, Biome, Turbopack), Microsoft chose Go for three core reasons:

Garbage Collection & Memory Model: Allows managing large ASTs without fighting borrow-checker complexities during a 1:1 port.
First-Class Concurrency: Shared-memory multithreading in Go makes scaling across CPU cores seamless.
Structural Parity: Go’s code structure closely aligns with TypeScript/JavaScript, allowing the team to port the logic file-by-file while preserving 99.99% semantic compatibility.

Benchmark: Visual Studio Code (1.3 Million Lines of Code)

Where does the speed come from?

~50% comes from native binary execution vs V8 JIT overhead.
50% comes from Shared Memory Concurrency.

In TS 7, parsing, binding, emitting, and type-checking happen concurrently across all available CPU cores.

Instant Editor Experience & Language Server Protocol (LSP)

Command-line builds are great for CI/CD, but local IDE responsiveness is where developers feel the difference every second.

TypeScript 7 introduces a native Go-based Language Server Protocol (LSP):

Instant Diagnostics: Errors and red squigglies appear almost immediately upon typing.
Sub-Second Language Server Restarts: Restarting the language server across 8,000 files drops from 10–12 seconds down to under 2 seconds.
50% Reduced Memory Overhead: Eliminates V8 heap bloat during long coding sessions.

Caveats & Upgrade Compatibility

Because TypeScript 7 is a strict structural port rather than a syntax overhaul, upgrading is virtually seamless for 95% of projects:

# Install TypeScript 7 in your project
npm install -D typescript

What about Frameworks (Vue, Svelte, Astro)?

If your workflow relies heavily on the legacy Programmatic Compiler API (used by tools like Volar, Svelte, or Astro), you should stick with TypeScript 6.0 for now.

TypeScript 7.0 and 6.0 can run side-by-side. Microsoft is currently developing a new cross-process native Compiler API scheduled to land in TypeScript 7.1.

Final Thoughts: Is It Time to Upgrade?

TypeScript 7 isn't just a version bump; it's the biggest architectural leap in the language's 14-year history. Slighting build times from 1 minute down to 4 seconds directly impacts developer iteration loops and CI/CD costs.

Have you tested TypeScript 7 on your codebase yet? What speedups are you seeing on your CI pipelines? Let’s discuss in the comments below! 👇

Want more deep dives on web architecture, full-stack development, and tech breakdowns?
Join my Telegram channel — I share daily engineering insights, architecture breakdowns, and pet project logs!

8 Years and 13,000 Apps Later: Why Meta’s New UI Library (Astryx) Changes the Game

Pavel — Tue, 21 Jul 2026 04:33:07 +0000

Introduction

Meta just dropped a bombshell on the frontend ecosystem: Astryx. It’s an open-source (MIT licensed) UI component library built on top of StyleX and React.

But this isn't just another weekend project. Meta has been quietly refining Astryx internally for 8 years across 13,000 applications. With over 150 accessible, production-ready components out of the box, it’s a heavyweight contender. But do we really need another UI library?

As a full-stack developer, I’ve wrestled with UI libraries enough to know that the answer might actually be yes.

The "Two Bad Options" Dilemma

For years, when starting a new project, we’ve essentially been forced into a trade-off between two flawed extremes:

The "Locked-In" Approach (e.g., Material UI): You adopt a massive design system. It works great, but customizing it is a nightmare. Before you know it, your unique SaaS looks exactly like a Google product.

The "Copy-Paste" Approach (e.g., Shadcn): You copy the component code directly into your project. You have total control over the styling, but now you own the code. As your project grows, components diverge (style drift), and applying upstream accessibility or bug fixes becomes a massive, manual headache.

The Solution: Astryx's Token-Level Control

Astryx claims to eliminate this trade-off.

The core philosophy is simple: The system controls the behavior, accessibility, and quality, while you control the look via themes. Instead of rewriting component code, you customize at the token level using TypeScript/JavaScript. You define your base colors, typography scales, border radii, and motion speeds, and Astryx auto-generates the necessary tokens.

Why Astryx Stands Out (The Killer Features)

Beyond the flexible theming, a few things make Astryx incredibly interesting for modern workflows:

Production-Ready for SSR: It works flawlessly with Next.js and server-side rendering, statically generating the CSS and JS you need.
The "Tailwind Bridge": If you love Tailwind, Astryx maps its design tokens to Tailwind utility classes. You get the strict brand consistency of a rigid theme with the utility-first developer experience of Tailwind.
Built for AI Agents: This blew my mind. Astryx includes a CLI specifically designed not for humans, but for AI. It fetches component documentation and feeds it directly into the context of your LLM (like GPT-4), helping AI generate accurate, best-practice Astryx code.

My Takeaway as a Full-Stack Developer

I was able to integrate it into my project with ease, as it is friendly to the AI UI framework. I plan to migrate part of the project to it, as I want to try out the integration with StyleX.

Astryx feels like a mature, battle-tested tool that respects developer time without sacrificing design flexibility. It prevents "style drift" while keeping maintenance low. If you're starting a new React or Next.js project, it is 100% worth a test drive.

What do you think about Astryx? Are you sticking with Shadcn or giving Meta's approach a try? Let’s discuss in the comments!

👇 Want more insights on full-stack development, mobile/web architecture, and my journey building pet projects in public? Join my Telegram channel: https://t.me/paveldevv — I share code snippets, architectural breakdowns, and honest stories about when things go wrong (and how to fix them).

AI Isn't Magic. It's Just Math (And Here is How It Works)

Pavel — Thu, 16 Jul 2026 09:38:28 +0000

In 2026, the tech industry's capital expenditure on Artificial Intelligence is estimated to hit around one trillion dollars. It is a new global infrastructure used by billions of people every single day.

But for most of us, typing a prompt into a Large Language Model (LLM) feels like consulting a magic crystal ball. You ask a question, wait a split second, and a perfectly written answer appears on your screen.

Here is the problem: treating AI like magic is dangerous.

When we don't understand how it works, we get frustrated when it makes silly mistakes, or worse, we blindly trust it when it confidently lies to us. If you are building full-stack applications or simply trying to navigate the modern web, treating AI as a "black box" means you are entirely at the mercy of the machine.

But there is a solution: once you peek under the hood, you realize there is no magic at all. It is just data, massive matrices, and an unbelievable amount of computing power.

Let me explain:

1. From Words to Numbers

Computers do not understand the meaning of the word "apple," the concept of "love," or the nuances of classic literature. They only understand numbers.

When you type a sentence, the AI does not read it like a human. Instead, it shatters your text into tiny puzzle pieces called tokens. A token can be a whole word, a syllable, or even just a single letter. Because the model only speaks math, every single token is instantly converted into a massive column of numbers known as an embedding (or vector).

Picture this: Imagine a massive 3D map where words with similar meanings are placed geometrically close to one another. That is how the AI understands context. It calculates the mathematical distance between concepts. To ensure the model knows the correct order of the words, it also adds "positional embeddings," allowing it to understand that "the dog bit the man" is very different from "the man bit the dog."

2. The Core Engine: How It "Thinks"

Once your words are turned into numbers, they enter the core of the AI: the Transformer architecture (a breakthrough from 2017).

The secret is: This architecture relies heavily on an "Attention Mechanism." Think of this as a massive discrete math problem—a complex, weighted graph where every word evaluates its relationship with every other word in your prompt. This algorithm calculates the most logical semantic path, deciding which words to focus on and which to ignore. This is how the model knows the difference between a "bow" you tie on a present, and a "bow" you use to shoot an arrow.

Finally, the network spits out logits—raw probability scores for every possible next token in its dictionary. We then use limiters like Temperature (to add randomness) or Top-K to force the model to only select the most mathematically probable next word.

Tokenization -> Transformer/Attention Mechanism -> Output Logits -> Final Generated Word." width="800" height="447">

3. The Million-Dollar Guessing Game

How does an AI actually learn? It doesn't search for the meaning of life. It simply plays a massive, high-speed guessing game.

During its training phase, the AI is fed terabytes of human text. Its only job is to guess the next word in a sentence. When it guesses wrong, a mathematical formula called the Loss Function calculates exactly how far off it was. The model then updates its internal weights to minimize that error in the future.

Pay attention to this: Formally, this optimization uses gradient descent, and the math looks something like this:

$W_{n e w} = W_{o l d} - α \frac{\partial L}{\partial W}$

After doing this billions of times, the model becomes a world-class predictor. In the final stage (Post-Training), humans step in to tweak the model, teaching it to be safe, polite, and helpful rather than just blurting out random internet text.

4. Why Do They Lie?

You have probably seen an AI confidently invent a fake fact (a hallucination). Even advanced models like Gemini 3.1 Pro or DeepSeek still hallucinate a small percentage of the time.

Look at it this way: Models are designed to predict the most plausible continuation of a text. They are not checking facts against a hardcoded database. During their training, they are heavily rewarded for providing an answer and implicitly punished for staying silent. For a pure language model, it is always mathematically safer to guess than to say, "I don't know."

5. The Infrastructure Hell

And that's not all: All of this rapid-fire guessing requires an insane amount of physical hardware.

If you are used to building apps where the client-side interface and the backend logic are neatly separated into different folders, scaling an LLM takes that distributed mindset to the extreme. Massive modern models (weighing terabytes) cannot fit onto a single graphics card. Their digital brains must be split across massive clusters of GPUs.

Today, the biggest bottleneck isn't processing speed; it is Memory Bandwidth—the physical speed of delivering data from the memory chips to the compute cores. To keep costs down and answers fast, engineers are constantly using optimization tricks to compress these models without losing their smarts.

Conclusion

We are living through a technological shift comparable to the invention of the internet. But it is crucial to remember that AI is not a thinking agent. It is a mathematical mirror reflecting human language back at us.

By understanding the mechanics under the hood—the vectors, the probabilities, and the high-load server farms—you stop seeing AI as magic. You start seeing it for what it truly is: the most powerful calculator humanity has ever built.

The Next.js Black Box: What Actually Happens Between Your React Code and the Browser

Pavel — Mon, 13 Jul 2026 14:58:30 +0000

Most developers think Next.js simply converts React components into HTML strings and sends them to the browser.

Then you open the "View Source" of your production App Router application, expecting clean HTML. Instead, you are greeted by thousands of lines of cryptic, unreadable JavaScript looking like this: self.__next_f.push([1, "M1:{\"id\":\"...\"}"]).

If you have ever wondered what this payload is, why it exists, and how Next.js actually compiles your codebase, you are in the right place.

Let’s open the black box and break down the modern Next.js compilation and rendering pipeline.

Phase 1: The Graph Split (AST Analysis)

The magic starts during the build step. Modern Next.js doesn't treat your application as a single tree of components. It uses an Abstract Syntax Tree (AST) analysis to split your codebase into two distinct dependency graphs:

The Server Component Graph

The Client Component Graph

By default, everything is a Server Component. The compiler walks down the tree until it hits a file with the "use client" directive. This directive acts as a hard boundary. The compiler bundles everything below that boundary into standard JavaScript chunks that the browser will eventually download.

Everything above it stays firmly on the server, ensuring your database credentials and heavy dependencies never leak into the client bundle.

Phase 2: The Serialization Engine (Flight Protocol)

When a user requests a page, Next.js does not immediately generate standard HTML for the Server Components. First, it serializes the executed Server Components into a highly optimized, streamable format called the RSC Payload (using React's internal Flight Protocol).

This brings us back to the self.__next_f.push mystery.

Those cryptic lines are the RSC Payload being streamed inline. Next.js embeds this data directly into the HTML document so that the client-side React runtime can reconstruct the component tree without making a second network request.

Example:

M1:{"id":"./src/Counter.client.js","chunks":["client1"],"name":"Counter","async":true}

J0:["$","div",null,{"className":"main-container","children":[["$","h1",null,{"children":"Hello, React Server Components!"}],

["$","@1",null,{"initialCount":0}]]}]

Let's dive into this mystery language:

1. The Module Definition (M1:)

M Prefix: Stands for Module Metadata. It tells the client that this line does not contain HTML or UI tags, but references a Client Component.
1: A unique identifier for this specific client module within the stream.
id & chunks: Directives for the bundler (e.g., Webpack, Turbopack). It tells the browser exactly which JavaScript file (./src/Counter.client.js) and asset chunk (client1) to fetch from the server.
name: The specific exported component name (Counter) to instantiate.

2. The JSON UI Tree (J0:)

J Prefix: Stands for JSON React Element Tree.
0: Represents the root ID of the tree. The client uses J0 to render the main entry point.
$ Symbol: This is a serialized placeholder for Symbol.for('react.element'). It signals to the React runtime that this array must be parsed as a standard React element.
"div": The HTML tag type.
null: Reserved for the element's key prop (if none is provided).
The Object ({...}): Contains the component's props (className, children, etc.).

3. The Client Component Reference

@1: The @ symbol indicates a Reference Link. This tells React to stop reading raw JSON and instead look up the Module defined earlier under ID 1 (the Counter component).
{"initialCount":0}: These are the props passed from the Server Component down to the Client Component.

Phase 3: Assembly and Partial Prerendering (PPR)

In the latest iterations of Next.js, this pipeline has evolved to support Partial Prerendering (PPR). The compiler orchestrates the rendering using a "Static Shell + Dynamic Holes" model.

Here is how the compiler handles a page request:

The Static Shell: During the build, the compiler pre-renders static UI (headers, footers, and Suspense fallback skeletons) and caches it at the edge.
The Dynamic Holes: When the compiler encounters a dynamic function (like cookies(), headers(), or database calls wrapped in a Suspense boundary), it pauses execution for that subtree.

When a request comes in, the server instantly flushes the cached static HTML shell to the browser, achieving an incredibly low Time to First Byte (TTFB). Meanwhile, it resumes executing the dynamic "holes" in the background and streams the final RSC payload down the open HTTP connection as soon as it resolves.

The Takeaway

Next.js is no longer just a traditional SSR framework. It is a sophisticated compiler that splits your code, serializes Server Components into a custom streaming protocol, and interleaves static and dynamic content on the fly.

Understanding this pipeline is the key to optimizing your app's performance. The next time you see self.__next_f.push, you’ll know exactly what the engine is doing under the hood.

Have you ever run into payload bloat issues with massive RSC payloads on data-heavy pages? How did you solve it? Let's discuss in the comments! 👇

Why are free hosting services great?

Pavel — Fri, 10 Jul 2026 05:24:32 +0000

If you hear "Hugging Face," you probably think of Machine Learning, AI models, and Python. But what if I told you it’s also one of the best hidden gems for hosting your full-stack web applications for free?

When building personal projects or testing heavy architectures, finding a reliable free hosting tier can be a headache. Vercel and Netlify are great for the frontend, but if you have a custom backend or need a specific Dockerized environment, you usually have to pull out your credit card.

Today, I’ll show you how to use Hugging Face Spaces to host your Dockerized application (like a Next.js or Node.js app) completely for free.

Why Hugging Face Spaces?

Hugging Face offers a "Blank Space" option powered by Docker. The free hardware tier gives you:

2 vCPUs
16 GB RAM
50 GB Disk Space

For a pet project or an MVP, this is incredibly generous. Let’s get your app up and running in 4 simple steps.

Step 1: Create a New Space

Go to Hugging Face and create an account if you don't have one.

Click on your profile picture -> New Space.
Name your space (e.g., my-awesome-app).
Choose a License.
In Select the Space SDK, choose Docker and select Blank.
Keep the Space hardware on the Free tier.
Click Create Space.

Step 2: The Golden Rule (Port 7860)

Here is the most important part of this tutorial: Hugging Face Spaces route traffic exclusively to port 7860.

Whatever framework you are using (NestJS, Next.js, Express, etc.), you must expose and run your application on port 7860 inside your container.

Step 3: Write Your Dockerfile

Let’s say you are deploying a Next.js or Node.js application. You need to create a Dockerfile in the root of your repository.

Here is a ready-to-use boilerplate for a Node-based environment:

# Use a lightweight Node.js image
FROM node:18-alpine

# Set the working directory
WORKDIR /app

# Copy package.json and install dependencies
COPY package*.json ./
RUN npm install

# Copy the rest of your application code
COPY . .

# Build your app (if you are using Next.js or TypeScript)
RUN npm run build

# EXPOSE THE HUGGING FACE PORT
EXPOSE 7860

# Start the application on port 7860
# Make sure your server dynamically accepts the PORT env variable or is hardcoded to 7860
ENV PORT=7860
CMD ["npm", "start"]

Step 4: Push Your Code

Hugging Face Spaces act just like Git repositories. You have two options:

Upload your files directly via the browser interface in the "Files" tab.
Clone the repository locally and push your code via Git:

git clone https://huggingface.co/spaces/YOUR_USERNAME/YOUR_SPACE_NAME
cd YOUR_SPACE_NAME
# Add your app files here, including the Dockerfile
git add .
git commit -m "Initial commit: App setup and Dockerfile"
git push

The Result

Once you push the code, Hugging Face will automatically start building your Docker image. You can watch the logs in real-time in the "Logs" tab. Once the build is successful, your app will be live and accessible via a public URL!

Wrapping Up

Using Hugging Face Docker Spaces is a game-changer for deploying full-stack MVPs, testing complex architectures, or just showcasing your portfolio projects without worrying about hosting bills.

Have you ever tried using Hugging Face for non-ML projects? Let me know in the comments below! 👇

DEV Community: Pavel

Microsoft Just Dropped TypeScript 7: Why a Native Go Rewrite Changes Everything

Introduction

Why Rewrite a Self-Hosted Compiler in Go?

Why Go instead of Rust or C#?

Benchmark: Visual Studio Code (1.3 Million Lines of Code)

Where does the speed come from?

Instant Editor Experience & Language Server Protocol (LSP)

Caveats & Upgrade Compatibility

What about Frameworks (Vue, Svelte, Astro)?

Final Thoughts: Is It Time to Upgrade?

8 Years and 13,000 Apps Later: Why Meta’s New UI Library (Astryx) Changes the Game

Introduction

The "Two Bad Options" Dilemma

The Solution: Astryx's Token-Level Control

Why Astryx Stands Out (The Killer Features)

My Takeaway as a Full-Stack Developer

AI Isn't Magic. It's Just Math (And Here is How It Works)

1. From Words to Numbers

2. The Core Engine: How It "Thinks"

3. The Million-Dollar Guessing Game

4. Why Do They Lie?

5. The Infrastructure Hell

Conclusion

The Next.js Black Box: What Actually Happens Between Your React Code and the Browser

Phase 1: The Graph Split (AST Analysis)

Phase 2: The Serialization Engine (Flight Protocol)

1. The Module Definition (M1:)

2. The JSON UI Tree (J0:)

3. The Client Component Reference

Phase 3: Assembly and Partial Prerendering (PPR)

The Takeaway

Why are free hosting services great?

Why Hugging Face Spaces?

Step 1: Create a New Space

Step 2: The Golden Rule (Port 7860)

Step 3: Write Your Dockerfile

Step 4: Push Your Code

The Result

Wrapping Up