The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years )

The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM.

In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )

Alan Kay in 1997:

> I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with computers, I'm not sure. [Laughter] In fact, we can see what's happend to the Internet now, is that it is gradually getting—There are two wars going on. There's a set of browser wars which are 100 percent irrelevant. They're basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here. You don't need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don't need anything more complex than something like X Windows. Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable. This is one of these mistakes that has been recapitulated every generation. It's just simply not the way to do it.

And yet in the nearly thirty years since he said that, the browser has come to dominate how people interact with UIs. Both in terms of sheer popularity (not only do we have complex applications on the web, but we also package complex applications with browsers as desktop applications) as well as influence (SwiftUI, Flutter, and Jetpack Compose all borrow heavily from frameworks developed primarily for the web).

I think a lot of this has to do with the idea that Kay is criticising here: HTML as a mechanism for building applications has been so successful because it needs to be interpreted by a browser. That provides a tremendous level of sandboxing that makes it a lot easier to trust whatever website you're loading than the application you're installing. It also provides a grab-bag of useful controls and elements, while still being completely flexible with creating new ones without needing to resort to OOP inheritance chains or raw graphics drawing APIs. This is all to say nothing of accessibility, which is practically built into the browser.

> Full Browser window size cancas ... and draw everything yourself

This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) and many sites were an 800x600 image using the <area> tag for hitpoints.

Even Flutter has a DOM target because painting to a full <canvas> violates at the very least the operating system's text rendering, scrolling, and accessibility.

I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me.

e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways ) Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.

Flutter sadly deprecated the DOM renderer: https://docs.flutter.dev/platform-integration/web/renderers

I would be so happy with inline-rendered, unblockable ads, always slightly different input/gesture handling and no accessibility!

Bye bye ad blocks?

Did your friend get genetic sequencing done on his tumor. There are some recent promising results for braf mutated gbm

No, they can't reach the tumor surgically. Thanks for the info though.

Avalonia

Last time i looked Kestrel already uses most of the techniques above ( sans an IOUring backend for Socket ) Almost all allocations are pooled, and zero copy as well. Header parsing is even done with System.Runtime.Intrinsics using SIMD where possible.

The higher level ASP.NET Core stack is also quite efficient and optimized.

BUT: as soon as you gove above the basic middleware pipeline its tends to get bloated and slow. ASP.NET COre MVC is particulary bad.

System.Text.Json is also quite nice, and often is allocation free.

We bascially just us the middleware pipeline and nothing else, and can get millions of requests per second on basic hardware.

This is absolutely true, there is a lot of performance work invested at all layers or features that benefit from improvements in runtime itself.

As you noted, the problems happen later in the handling pipeline. There are also choices that ASP.NET Core has to make as an extremely general-purpose web framework like that.

System.Text.Json is pretty good for a default serializer, but it's far from how fast json serialization can be done in .NET too.

Both of these end up reallocating and transcoding data, and STJ also might take a hit if deserialized classes/structs have converters in them as it can disable a fast-path.

My idea here is that a new implementation can benefit from the hindsight of strength/weaknesses of asp.net core and how its design influences the implementation choices of the user (and whether they end up being optimal or not).

It would also not be constrained by backwards compatibility or certain organizational restrictions - for example you do not need to explicitly use out-of-box QuicConnection and QuicStream that rely on mquic and opt to statically link to parts of the stack implemented in Rust, or bring over more logic to C# instead. There is a certain conventional way you are expected to approach this in dotnet/* repositories, and it might be a bit restrictive in achieving end goals of such a design.

It would be able to approach the problem as a library that expects a more advanced user, closer to how e.g. Axum or back in the day actix-web did (and by advanced I mean effective usage of (ref) structs and generics, not that it would need boilerplate).

p.s.: does this organization with millions of RPS have a name?

Isn't HttpListener still windows only ? I Remember the times we used it and it relied on http.sys on windows...

Or did they port it during NET/NET Core. As Kestrel has been the recommendation from NET Core 1.0 onwards.

It appears to use Socket (which is POSIX socket's send/recv and epoll/kqueue based) and SslStream. Can't say much about HttpListener itself, but the first two are used by Kestrel (and everything else). There is Http.sys integration for Windows though.

https://github.com/dotnet/runtime/blob/ac663e44b907618c631ed...

Httplistener has two implementations. Managed (cross platform) and http.sys (windows only).

It’s “ok”. You can’t do things like re use contexts but it’s perfectly fine for throwing small backends together when you don’t want to force users to install asp runtime. I did a minimal web api around it to make life easier going between it and kestrel.

If kestrel was nugettable without the asp runtime it would be a dream but it requires a lot of that aspcore infra so it is what it is.

It is actually possible, to seperate those things, but it's tricky. Our current product can run in several modes, one with a web ui and api and one without. If running without there is no trace of the ASP.NET Core Pipeline ( and Kestrel is also not running )

We're using ASP.NET Core Minimal APIS for both API and UI (if configured to run in that mode )

Yeah we have a similar product, where we spin up multiple web servers. Code looks something like this:

        var builder = WebApplication.CreateBuilder([]);

        builder.WebHost.UseUrls($"http://127.0.0.1:0");

        builder.Services.AddSingleton(...);

        var app = builder.Build();

        app.Map...

        await app.StartAsync(cancellationToken);

We run multiple of these at a time and have no problems.

Dammit you were first to ask that question :-) I also don't see the difference.

Reading the docs and samples...

What are the advantages compared to e.g ASP.NET Core Minimal Api ?

(or for example FastEndpoints) ?

FastEndpoints is nice but they don't seem to plan on supporting NativeAOT anytime soon https://github.com/FastEndpoints/FastEndpoints/issues/565#is....

It's really weird to watch all that from the other side of the pond. In my country for example, all politicians have immunity but our parliament can revoke it for anyone using a majority ruling... ( having more than two political parties helps )

Every company i have advised jumped on the microservice bandwagon some time ago.... Here is what I tell them:

1. Microservices are a great tool... IF you have a genuine need for them 2. Decoupling in and on itself with services it not a goal 3. Developers who are bad at writing proper modular code in a monolithic setting will not magically write better code in a Microservice environment.. Rather it will get even worse since APIS ( be it GRPC, Restful or whatever ) are even harder to design 4. Most developers have NO clue about consistency or how to achieve certrain gurantees in a microservice setting ( Fun fact: My first question to developers in that area is: Define your notion of consistency, before be get to the fun stuff like RAFT or PAXOS) 5. You don't have the problems where microservices shine ( e.g banks with a few thounsands RPS ) 6. Your communication overhead will dramatically increase 7. Application A that does not genuinly need microservices will be much cheaper as a monolith with proper code seperation

Right now we have generation of developers and managers who don'T know any better, and just do what everybody else seems to be doing: Microservices and Scrum ... and then wonder why their costs explode.