I really dig the Hotwire approach (thanks!) and it’s similar to what we’ve been doing with links and forms on our own for 10+ years.
Curious on if you have seen others setting up a boilerplates or recipes using ASP.NET for the backend?
I have started a bit here and I have even gotten some simple WebSocket stuff to work:
Outside of the .NET stuff there is also a working webpack.config.js in there that might interest others who are adding Tailwind CSS.
I renamed the repo (old links still work) and updated to .NET 6 and Razor Pages and worked through the setup a bit more…
Also add a demo site: https://hotwired.azurewebsites.net/
Planning to add more examples onward!
I’ve been using .net and hotwire for about a year now, and I quite like them together. I stumbled into your repo a while back. It’s great to have a place with some examples, good job! Let me know if you need any help with more examples down the road. Have you done any work on a NuGet package yet? I think it would be great for making the barrier of entry lower.
Feel free to add issues to your GitHub repository. I’d love to help. There’s a project I have planned that a Hotwired ASP.NET Nuget package would be perfect for!
@krebil @colinkiama There’s not that much in that class library yet but maybe if more gets added on that level I could look into creating a package…
I’ve added some more samples and changed the setup a bit. View Components seem like a great fit to combine with Streams. See this new example: Player list page
I also stumbled over another package/project here: NuGet Gallery | HotwireTurbo 1.0.0
I think I prefer mine for now 
@krompaco I think the package you linked here has some good ideas. A TurbostreamResult and tagHelpers are both really good features for a package. I would be hesitant to use something like that in production unless it got way more usage or I was a contributor. I’m always afraid that they will lose stop being worked on in the near future.
Glad to see that there is someone using ASP.Net Core here!
HotwireTurbo 1.0.0 NuGet doesn’t work with NET 6. I opened issue but it seems project is dead.
However code and implementation is quite OK. I have to compare it with yours.
As for web socket: I would stick with SignalR. AFAIK using raw web sockets could be tricky.
I am glad to cooperate in making it into active project. Do you prefer discuss it here or on GitHub?
@AdamLuczynski Yes, agree on SignalR. I just found out about this sample: GitHub - scottiemc7/hotwire-aspnet-demo-chat: A port of the Hotwire Rails Chat Demo to asp.net core.
Should be easier to work with than the socket lab I have now. Maybe there is some other reference as well?
I think it’s better to discuss in deeper details on GH!
While browsing I found Hotwire.dev · Issue #1 · khalidabuhakmeh/turbolinks.net · GitHub and there seems to be another person willing to work on it.
I’ll put a link to this thread on the GitHub issue, that way he can come in and see all the good references. And join the conversation if he wants
I’ve collected a bunch of the helpers that I often add to my projects in case anyone is interested. I’ll probably make it into a NuGet package for my own benefit in a few days.
Let me know if you spot anything that’s missing.
I did some work to use dotnet 8 Preview 6 and Blazor SSR instead of Razor Pages 
Will polish further closer to the release but already feels good.
The Blazor component model is very nice and support to render components to strings comes in handy with Turbo streams.
That’s super cool.
HtmlRenderer in v8 is gonna make streams a lot easier to use
Updated to work with .NET 8 Preview 7 which is the last preview release, next up will be release candidate.
I’ve updated my package (GitHub - krebil/Hotwired-dot-net). I added some opt-in middleware for turbo frame requests. This will strip all the html (except for the turbo-frame itself and whatever turbo-streams may be present) to reduce the payload size before sending the response.
I think this can simplify my workflow so that my views can always render whole pages and then this can pick out the important parts whenever a frame requests a view. Sometimes I’ve had pretty big views which has tempted me to make frame specific endpoints, this alleviates that somewhat.