DEV Community: withNext.NET

JsxCore hits 1.0, and its author is bringing C# to Astro (AstroSharp)

withNext.NET — Thu, 06 Aug 2026 10:29:29 +0000

This article was originally published on our engineering blog, WithNext.NET. It's reposted here with the canonical link pointing back to the original.

A while back I wrote about JsxCore — a view engine that lets you write ASP.NET Core views in JSX/TSX and render them with React or Preact, with no Node.js required. At the time it was "about to ship." Well, it just did: JsxCore is now 1.0.0. And its author, David Whitney, is already pushing the same idea further — into Astro, with a proof of concept called AstroSharp. This is the follow-up.

JsxCore 1.0.0 is out

On August 4, 2026, David Whitney announced "JsxCore 1.0.0 is out." In short, everything from the earlier write-up is now a stable release. You write a .tsx view, return it from a controller, and pick server rendering, hydration, or both — per response. View-model types are generated from your C#, and installing is still just dotnet add package JsxCore. The project had a few dozen stars when I first covered it; it's now around 200, so interest is clearly building.

It targets ASP.NET Core MVC, Web API, and Minimal API, runs on the .NET SDK alone, and keeps the "vite-like DX" goal: automatic TypeScript transpilation, bundler-free module resolution in the browser, and hot reload that surfaces TS errors as an overlay.

The next move — AstroSharp

Here's the part I find genuinely interesting. JsxCore brings C# to the React/TSX world. AstroSharp aims to do the same thing for Astro: write your Astro content in .razor (C#), while the tooling underneath is powered by .NET.

The key design choice is that the entry point stays npm, but the inside is .NET. From a front-end developer's perspective, you install a normal npm package. During development, the Astro plugin spawns a .NET sidecar process and uses Roslyn for a static, hot-reloading dev experience. A .NET runtime is needed at build time, but the front-end workflow — the one that starts with npm install — is left intact.

A minimal Astro component in AstroSharp reads like Razor: C# in the frontmatter, markup below.

@{
    var name = "World";
}
<h1>Hello @name</h1>

Rendering goes through the sidecar for SSR (HTML produced by C#), and there's an experimental, opt-in WASM path for server-less rendering as well. Both are early — this is a work-in-progress PoC at the time of writing — but the direction is clear.

What developers are saying

The reaction has been warm, especially from people who were shopping around for exactly this kind of tool. One developer put it this way after seeing AstroSharp:

"Nice, I needed something like that. I was evaluating Blazor SSR and HTMX, but I think this is actually what I wanted."

That captures the niche well. It's not "C# for everything" — it's C# where you already wanted server-side power, without giving up the front-end ecosystem you like.

What's actually happening here

Step back and there's a consistent theme across David Whitney's work. Rather than asking front-end developers to abandon their stack for a C#-only model, he's meeting each front-end culture where it is and delivering the feel of C# into it — JSX/TSX with JsxCore, and now Astro with AstroSharp. Whether AstroSharp graduates from PoC to production is an open question, but the pattern — npm on the outside, .NET on the inside — is a pragmatic way to bring .NET's strengths to teams that live in the JavaScript world.

FAQ

Is JsxCore production-ready now that it's 1.0?
It's a stable 1.0.0 release and supports MVC, Web API, and Minimal API with just dotnet add package JsxCore. That said, it's still young, so a sensible path is to adopt it on a small surface first and grow as you gain confidence.

Do I need Node.js for either JsxCore or AstroSharp?
JsxCore needs only the .NET SDK — no Node.js. AstroSharp is different: its entry point is a normal npm package, and it uses a .NET sidecar during development plus a .NET runtime at build time.

Is AstroSharp ready to use?
Not yet. It's an early proof of concept at the time of writing, and the SSR WASM path in particular is experimental.

Sources: JsxCore on GitHub · original announcement threads by @david_whitney.

Originally published at WithNext.NET, where we write about .NET / C# modernization, performance, and AI.

G#: a modern .NET language with Go, Kotlin, and Swift ergonomics

withNext.NET — Wed, 05 Aug 2026 04:49:47 +0000

This article was originally published on our engineering blog, WithNext.NET. It's reposted here with the canonical link pointing back to the original.

"I want modern, concise syntax — but I don't want to give up the .NET runtime or ecosystem." A new language called G# goes after both. Built by David Obando and announced at its 0.3 release in July 2026, G# brings the feel of Go, Kotlin, and Swift while compiling directly to managed .NET assemblies with full interop. Microsoft's David Fowler shared it as "a new .NET programming language," and it drew a lot of attention. This post tours what G# is, how it reads, and how it connects to .NET.

What is G#?

G# is a language that compiles directly to managed .NET assemblies. It borrows modern design — Go's package layout, Kotlin/Swift null-safety — while letting you use the CLR runtime, BCL, NuGet, MSBuild, Portable PDB, and C# interop as-is. The author frames the goal like this: "C# is excellent, but it's also large and carries decades of history. G# starts from a different constraint: keep the language surface small and predictable."

Modern, concise syntax

package / import / func, plus ${...} string interpolation. If you've used Go or Kotlin, it reads almost without explanation.

package Hello
import System

func greet(name string) string {
    return "Hello, ${name}!"
}

Console.WriteLine(greet("world"))

A data class auto-synthesizes structural equality, with-copy, and deconstruction — the spirit of C# records, in fewer keystrokes.

data class Person(Name string, Age int32)

let alice = Person("Alice", 30)
let older = alice with { Age = 31 }
let (n, a) = older

Console.WriteLine(alice == Person("Alice", 30))  // True

Nullability is part of the type system. G# uses nil rather than null; a plain T can't hold nil, only T? can. You unwrap safely with if let.

func Greet(name string?) {
    if let n = name {
        Console.WriteLine("hi ${n}")
    } else {
        Console.WriteLine("hi stranger")
    }
}

Structured concurrency and explicit numerics

async/await run over Task and Task[T] — note that generics use brackets []. The standout is the scope { ... } block, which enforces structured concurrency by automatically joining any child tasks started inside it. Numeric types carry their width in the name (int32, uint64, float64), so the size of a value is explicit in the source.

async func compute(n int32) int32 {
    await Task.Delay(5)
    return n * 2
}

scope {
    runAll().Wait()
}

.NET interoperability

What makes G# practical is interop: you can call any .NET type — BCL, NuGet packages, your own code — and LINQ, properties, for-in over IEnumerable[T], and P/Invoke all work. Existing test assets work too; the screenshot below is a G# test using xUnit's @Fact / @Theory / @InlineData. It's a new language, but it lives inside the .NET ecosystem.

Tooling and getting started

The toolchain is complete: the gsc CLI compiler (emitting managed PE + Portable PDB), the gsi REPL/script runner, a C#-to-G# migrator cs2gs, a VS Code extension, and an LSP language server. Getting started takes three commands — all you need is the .NET SDK.

dotnet new install Gsharp.Templates
dotnet new gsharp-console -n HelloG
cd HelloG

Rewrite the generated Program.gs to exercise data classes and structural equality:

package HelloG
import System

data class Person(Name string, Age int32)

func describe(p Person) string {
    return "${p.Name} (${p.Age})"
}

let alice = Person("Alice", 30)
let older = alice with { Age = 31 }

Console.WriteLine(describe(alice))
Console.WriteLine(describe(older))
Console.WriteLine(alice == Person("Alice", 30))

dotnet build && dotnet run

You should see:

Alice (30)
Alice (31)
True

The with-copy and structural equality just work.

What it means for .NET developers

G# fits teams that want React/Go/Kotlin-style modern syntax but real CLR interop, folks learning or teaching .NET without starting from C#, and anyone who likes Go's packages or Kotlin/Swift null-safety on the CLR. It isn't a C# replacement — think of it as another language option on .NET, one you can mix with existing C# code.

That said, G# is pre-1.0 (v0.3). The 0.3 base is an implementation milestone, not a long-term compatibility guarantee; some interop is emit-only, and cs2gs coverage is still expanding. Start with small experiments and learning, and keep up with updates.

What the community is saying

The signal boost came from Microsoft Distinguished Engineer David Fowler (ASP.NET Core, and much of the .NET stack). A short post — but coming from a central figure in the .NET community, it put G# on a lot of radars.

// Detect dark theme var iframe = document.getElementById('tweet-2075421408688222607-328'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2075421408688222607&theme=dark" }

FAQ

Is G# a replacement for C#?
No — it's another language option on .NET. It compiles to managed assemblies and interops with C#, so you can mix it with existing code. It suits teams who prefer a smaller, more predictable syntax or Go/Kotlin/Swift-style design.

Can I use existing .NET libraries (NuGet, BCL)?
Yes — BCL, NuGet packages, and your own code are all callable, with LINQ, bracket generics [], for-in, and P/Invoke. It sits on MSBuild and Portable PDB, so dotnet build/run and debugging work as usual.

Is it production-ready?
It's pre-1.0 (v0.3), so there's no long-term compatibility guarantee yet. Some interop is emit-only and the migrator is still growing. Start with validation, learning, and small experiments.

References

Originally published on WithNext.NET, where we write about .NET modernization, performance, and applied AI.

JsxCore: write React/TSX views in ASP.NET Core, with no Node.js

withNext.NET — Tue, 04 Aug 2026 17:52:48 +0000

This article was originally published on our engineering blog, WithNext.NET. It's reposted here with the canonical link pointing back to the original.

You want React and TypeScript on the front end, but pulling a whole Node.js + npm + bundler toolchain into a .NET project feels heavy. That trade-off has been a quiet pain for a lot of ASP.NET Core developers. JsxCore, an about-to-ship library by UK developer David Whitney, rethinks it: it's a view engine that lets you write ASP.NET Core views in JSX/TSX and render them with React or Preact — and its headline feature is that it runs on the .NET SDK alone, with no Node.js required.

This post walks through what JsxCore solves, how you write it, and what it means for .NET teams, based on the project's GitHub repository.

🆕 Follow-up: JsxCore has since shipped 1.0.0, and its author is now bringing C# to Astro with a PoC called AstroSharp — read the follow-up.

What is JsxCore?

JsxCore aims to bring a "vite-like developer experience to the .NET ecosystem." You write your views as .tsx files and return them from a controller or a Minimal API. Each view can render on the server (for the first paint and SEO), in the browser (for interactivity), or both. TypeScript is transpiled automatically, and the browser resolves the module graph without a bundler. It's MIT-licensed and targets .NET 8, 9, and 10.

Both React and Preact are supported (Preact ships built-in; React via restoration). Because JsxCore registers as an ASP.NET Core IViewEngine, it also plays nicely with classic MVC and return View(). In other words, you get "the feel of React" and "the conventions of ASP.NET Core" in a single project.

Getting started

You add one NuGet package. No Node.js install — the .NET SDK is all you need.

dotnet add package JsxCore

With a Minimal API, you register JsxCore and return a view. Build the model in C# and hand it to a .tsx view:

using JsxCore.Hosting;
using JsxCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.AddJsxCore();
var app = builder.Build();

app.UseJsxCore();
app.MapGet("/", () => Results.Extensions.Jsx("Home/Index", new { name = "World" }));
app.Run();

// Views/Home/Index.tsx
export default function Index({ model }: { model: { name: string } }) {
    return <h1>Hello {model.name}</h1>;
}

In a real editor, the C# Program.cs and the .tsx view sit side by side. Notice the .tsx line import type { IndexModel } from "dotnet:SampleApp.React" — your C# model type is pulled straight into TypeScript through the dotnet: scheme.

C# Program.cs and Index.tsx. The dotnet: import brings C# types into the TSX side (source: JsxCore repository).

How it works — calling C# straight from a view

The key idea is that server rendering runs inside the .NET process. Because there's no separate Node.js process in the middle, a view can call your C# services synchronously, with no bridge overhead. You don't have to round-trip through an API to fetch data; the view can reach straight into your application logic.

The screenshot below is the sample app's ".NET globals" tab. The total stock value, the server time, and a low-stock list are all read from a C# service while the page renders. The front-end component has a direct line into the .NET world.

C# services are called during rendering to draw the stock value and server time (source: JsxCore repository).

On top of that, JsxCore generates TypeScript type definitions from your C# view models. That prevents the server/client "drift" where types silently diverge, and your .tsx gets written against generated, type-safe models. TypeScript and esbuild are handled with zero configuration, so you don't lose time wiring up the toolchain.

Developer experience — comfortable without Node.js

The DX details are where JsxCore shines. You can install and use npm packages without Node.js installed. TypeScript type errors show up instantly on hot reload, surfaced as a browser overlay right on the page. In the example below, Index.tsx(15,7) reports TS2322 (string is not assignable to number) — the feedback loop is fast.

Hot reload surfaces TypeScript compilation errors as a browser overlay (source: JsxCore repository).

The render mode is configurable — AddJsxCore(options => options.DefaultRenderMode = RenderMode.ServerAndClient) gives you a "server + client" mode that paints fast on the server and then hydrates for interactivity. React's useState, hooks, and ESM import all work as usual, so the learning curve for React developers is small.

What it means for .NET teams

JsxCore is a strong fit when your backend is .NET and you want the feel of React/TypeScript on the front end. You get first-paint server rendering for SEO and post-click interactivity from a single component model, and you can reach C# assets without an API hop or serialization. Keeping your React skills while dropping the Node.js runtime and a separate build pipeline is a real maintenance win.

That said, JsxCore is a young project (a few dozen GitHub stars at the time of writing), and its API and rendering behavior may still move. Before adopting it in production, try your own use cases (auth, streaming, large pages) against the sample app and make sure you can keep up with updates. Unlike Blazor, which is "all C#," JsxCore is about bringing React/TSX skills and assets into .NET — so pick it based on your team's skill set.

What the community is saying

The heads-up came from the author himself: server and client rendering, hooks, ESM imports, direct binding to C#, and transparent TypeScript type generation for server-side code — "it's really cool, coming soon," with follow-ups about native React support for ASP.NET Core MVC aimed at people used to Next.js.

// Detect dark theme var iframe = document.getElementById('tweet-2082220178062950894-590'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2082220178062950894&theme=dark" }

The reaction reflects real enthusiasm for full-stack C#. Developer Luke Parker riffed on it — half-joking that he'd "decided to rewrite opencode in C#" — a sign that "C# all the way to the front end" is genuinely moving people.

// Detect dark theme var iframe = document.getElementById('tweet-2084462147384557583-778'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2084462147384557583&theme=dark" }

FAQ

Do I need Node.js to use JsxCore?
No. You only need the .NET SDK; JsxCore handles TypeScript compilation, esbuild, and even fetching npm packages. There's no Node.js runtime to provision in dev or prod.

Can I use React and Preact?
Both. Preact ships built-in and React is available via restoration. Standard React idioms — useState, hooks, ESM imports — work as-is.

How is this different from Blazor?
Blazor writes UI in C# and Razor — an "all-C#" approach. JsxCore instead brings JSX/TSX and React/Preact into ASP.NET Core, so you can reuse existing React/TypeScript knowledge and code. Choose based on your team's skills and what you want from the front end.

References

Originally published on WithNext.NET, where we write about .NET modernization, performance, and applied AI.

TensorSharp: a pure C# / .NET GGUF inference engine that takes on llama.cpp

withNext.NET — Tue, 04 Aug 2026 05:20:54 +0000

This article was originally published on our engineering blog, WithNext.NET. It's reposted here with the canonical link pointing back to the original.

On the local-LLM community r/LocalLLaMA, a .NET inference engine called TensorSharp drew attention by publishing benchmarks against llama.cpp. Most inference engines are built on C/C++ or Python, so a project that implements the core of LLM inference in pure C# / .NET is worth a close look — especially if .NET is your home turf and you'd like to pull AI inference into that stack.

This post summarizes what TensorSharp actually does and how it compares to llama.cpp, based on the author's Reddit post and GitHub repository. The numbers below are the author's own measurements, and I add a .NET-developer perspective on top.

What is TensorSharp?

TensorSharp is a native .NET inference engine for models in the GGUF format. It's developed by zhongkaifu and released under the BSD-3-Clause license. It ships with a console app, a web-based chatbot UI, and Ollama- / OpenAI-compatible HTTP APIs so you can call it from your own programs. It runs on Windows, macOS, and Linux, and can use the GPU.

The important part: this is not just a C# wrapper around llama.cpp. The author states the engine was implemented bottom-up, and when running on the CPU backend it is 100% pure C#. On top of that it implements CUDA, MLX, and GGML backends — the GGML backend is referenced as an external project, with several fused operations layered on top. Supported backends span Metal (macOS), CUDA (NVIDIA), Vulkan (general GPU), and CPU, all with CPU fallback.

Model coverage is broad, too: Gemma 3 / 4, Qwen 3 / 3.5 / 3.6, GPT-OSS, Nemotron-H, Mistral 3, and even multimodal models such as DiffusionGemma and Qwen-Image-Edit. It handles image, video, and audio input, PDF documents, tool calling, thinking mode, and structured output. Notably, quantizations like Q4_K_M, Q8_0, MXFP4, and IQ2_XXS are computed directly, without a dequantization step.

Benchmarks against llama.cpp

The author's benchmarks compare TensorSharp and llama.cpp on the same backend, reporting the geometric mean of the speed ratio per scenario. Above 1.00× means TensorSharp is faster; decode and prefill are throughput, while TTFT is the latency to the first token. Measurements cover both CUDA and Vulkan across several models.

TensorSharp vs. llama.cpp benchmarks (source: Reddit r/LocalLLaMA / the project author)

The results vary by model and backend. Prefill and TTFT favor TensorSharp in many cases — for example, Gemma 4 E4B on CUDA shows prefill at 1.28× and TTFT at 1.27×. Decode, on the other hand, hovers around 1.0, and on Qwen 3.6 35B-A3B (Vulkan) it drops to 0.87×, below llama.cpp. On Qwen 3.6 27B dense, prefill / TTFT fall under 1.0 instead. In other words, it is not uniformly faster. The author describes the overall result as "on par with llama.cpp," and that cautious framing matches what the numbers show.

What's genuinely notable is that a pure .NET implementation reaches this level at all. Inference engines are a dense mix of matrix math and memory management — historically the exclusive domain of C/C++. Seeing C# land in the same range says something about the maturity of .NET's runtime performance and ecosystem.

Optimizations it brings in

TensorSharp actively borrows recent inference optimizations. The author says they adapted paged KV cache and continuous batching from vLLM, an SSD-based cache for MoE models from oMLX, and GGUF quantization from llama.cpp. The KV cache supports prefix sharing via block hashing and an iteration-level scheduler, and continuous batching is on by default.

For Qwen 3.6 and Gemma 4 it supports speculative decoding via MTP / NextN, and tensor parallelism follows Megatron-LM's column/row parallel patterns, extending toward multiple GPUs and multi-node TCP clustering. Multi-GPU support came up in the Reddit comments; the author replied that PRs for both single-node multi-GPU and multi-node are in progress and under active development. It's fair to read this area as still evolving.

What it means for .NET teams

When teams bring local LLMs into production, the common shape is a Python-side model server that the application calls over HTTP. That works, but it doubles the runtime and adds deployment and operational surface. A credible option where the inference engine itself runs on .NET invites you to revisit that architecture. Because TensorSharp exposes Ollama- / OpenAI-compatible APIs, you can often swap it in without rewriting much of your existing client code.

That said, production adoption calls for a level head. The benchmarks scatter across models and backends, and multi-GPU support is still in development. The sound approach is to measure with your own target models and hardware, compare against llama.cpp or your current setup, and decide from there.

Wrap-up

TensorSharp implements GGUF inference in pure .NET and, in the author's benchmarks, reaches the same range as llama.cpp. Prefill and TTFT lead in many cases, while decode ties or trails — it isn't a blanket win. Even so, the fact that completing LLM inference in C# alone is now within practical reach is significant, and it's worth watching for any team that wants to fold AI into a .NET stack.

If you'd like the fuller Japanese write-up with additional context, it lives on the original post: TensorSharp — a pure C# GGUF inference engine that takes on llama.cpp | WithNext.NET.

Sources

We write about .NET / C# modernization, performance, and applied AI at WithNext.NET.