u/davidwhitney

GitHub - davidwhitney/JsxCore: Native support for JSX and TSX as a server and client rendered view engine for ASP.NET Core. Bringing the modern web to ASP.NET.

GitHub - davidwhitney/JsxCore: Native support for JSX and TSX as a server and client rendered view engine for ASP.NET Core. Bringing the modern web to ASP.NET.

JsxCore brings native JSX support (React, Preact) to ASP.NET MVC and Minimal API as an ASP.NET view engine.

Another in a series of "can we converge modern web dev into the .NET ecosystem" projects that I'm working on.

So, Blazor is cool - but it's absolutely swimming against the current of the entire rest of the web development ecosystem. As it turns out, functional reactive programming is a pretty nice model for rich client applications and because of that React has totally dominated the space for a decade. There are probably more "React only" developers than most other programming languages have users.

This puts us in a weird spot in the .NET ecosystem - all the cool stuff in modern web is happening elsewhere, in a framework that's native to Node. This project is my attempt to pull the two ecosystems together so you can write idiomatic .NET in what I believe to be the best server side framework in the world, and use the same modern tooling that everyone else has for your UI.

Highlights:

- Doesn't require node! At all! (there's a home rolled NPM client to deal with dependencies from NPM so you can build your projects entirely with only dotnet in your path)
- Supports HMR, ESM, and a bunch of other goodies
- Shells out to esbuild for production style processing
- As a side-effect of using the native TypeScript compilers, adds native, toolchain free TypeScript first class support to your MVC apps - just import a TypeScript file as a module and it just works
- Generates TypeScript side type definitions for viewmodels you return to your views
- Generally just works as a drop in replacement for Razor views (.cshtml) in your apps
- Supports server side rendering with client side hydration via the JINT library

And before the "why not Blazor!" folks ask - because I think React (and the bundled Preact) is a pretty awesome way to build UI that doesn't force you over a compatibility WASM bridge which introduces a bunch of friction for front end devs.

I imagine this tool will be well suited for teams where there are split frontend and backend job roles working in the same app, that want to avoid the abject pain and misery of setting up a backend, a frontend, configuring reverse proxies to join em up etc etc that making ANCM and React play nicely together previously required.

github.com
u/davidwhitney — 4 days ago

Bringing C# to Astro with AstroSharp

I've been working on a few interesting projects meant to bridge the gap between modern web development and the .NET ecosystem.

Many of you might have heard of Astro - a static site generator predominantly for the TypeScript ecosystem. Astro is awesome, it's probably the best implementation of a static site generator out there and it gives you all the modern conveniences of bundles, minification and live dev server experience during build.

So why not C#?

This project is (perhaps somewhat confusingly) an npm package that allows you to build a regular Astro project using C# and Razor. It's not a reimplementation of Astro - it's still Astros routing, and web stuff, but it extends Astros regular support for React, .astro files et al to also include Razor components and Razor pages.

Razor comes with a defacto front matter (the code block at the start of the file), can mix-and-match with Astro .astro files and React server rendered components, and allows you to use anything that can execute on the server during build time.

Want more? You can also write the coded parts of your astro site as regular .cs files - so your data loaders can be written in C#, and when your Astro site is npm run build built it just works.

Under the hood, obviously this relies on .NET being in the path of the machine, and the NPM package publishes an Astro plugin that boots up a sidecar process that communicates with astro over JSON-RPC at dev and build time. It's pretty cool and seemless - uses Roslyn in memory to do hot module reloads once the sidecar is already up by silently generating C# projects in a .astrosharp file and compiling with no real perceptible difference in performance (10ms page renders or so).

There's experimental support for WASM for client rendered stuff (though I'd probably not recommend it unless the app you're building is non-trivial on the client because you buy about 1.2mb of framework stuff like a Blazor site), and slightly less experimental support for the server-side functions that Astro has introduced - again using WASM hosted inside node. This bit... seems to work... but I've not used it in anger because all the Astro projects I have are pure build-time-static generated.

First releases are here on GitHub: https://github.com/davidwhitney/astrosharp and NPM.

u/davidwhitney — 4 days ago