Hi, Hydro creator here. Thank you Nick for checking out Hydro and creating this video! Thank you everyone who tried Hydro, I'm grateful for the support you gave by starring the repo and testing the features. I really appreciate that. I appreciate also all the comments, positive ones and the criticism - both are needed!
This is certainly a step in the right direction. Blazor and other technologies have become way too complex for very little benefits, but, for some reason, only programmers with 15+ years of experience seems to understand that. Sometimes I see new devs in my company getting very excited with a tech or a concept that existed 10 or 12 years ago. "This is running in the server? WOW!" Just the other day I made a PoC in 30 minutes using WebForms and they were speechless 😅
THANK YOU.... i thought i was taking crazy pills because i was think "oh, we back to webforms... wonder why we dumped that trash, can't really remember..."
It's a cool idea, but late in time. Blazor 8 give us a lot of choice on how to create components and its render modes. I think that WASM is evolving in an effective way and it's the way to go.
Competition is always good, and I genuinely wish the creator luck! That said, as a business owner & architect looking for a solid production-ready platform that will be supported for years going forward, Blazor still seems like the more obvious choice. I'm not seeing any compelling reasons for me to switch, not yet anyway. If nothing else, maybe this will force MS to address any major limitations in Blazor, and that's a good thing. :)
"as a business owner & architect looking for a solid production-ready platform that will be supported for years going forward" -- as one of those myself, I'm just sticking with React/Angular and plain old javascript/typescript with .NET on the server. This whole wacky circus tent that is Blazor and WASM seems like a nice way for dotnet devs to pad their resumés and waste time in scrum meetings coming up with convoluted DI systems when all they need to write is a couple of divs on a Contact Us page.
@@thefattysplace Fair points. I got burned on XNA / Managed DirectX and Silverlight. But... *everybody* who went down the Flash/Silverlight path got burned. The Mobile / Desktop shared space is always going to be volatile. Xamarin had a bit of a smell to it, and it's why I won't touch Maui. WebAssembly has been around for a while now (2017 looks like?) and has been adopted by all the major browsers. Once you actually build something in Blazor WASM you realize this thing has legs. It really is .NET and C# in the browser, like virtually no javascript is needed. A tiny bit of JSRuntime business here and there to achieve some hacky stuff, but I can see that getting resolved. I don't see WASM going away, but who knows for sure... I've got a lot of time and money invested into it.
@@thefattysplace I got burned on Silverlight, but *everybody* who did the Flash / Silverlight thing did. .NET and C# have been around now for over 20 years (I started v1.0 circa 2002). The real beauty of Blazor is in the SPA / WASM paradigm. WASM has been around for about 7 years now. It's here to stay.
I'm not sure how I feel about Hydro (reminds me of WebForms), but I generally agree that alternatives are a good thing. ...so long as we don't get to JavaScript levels of "framework of the week".
you can now do blazor SSR without signalR and return html sections (RazorComponentResult) from api controller (RazorComponentResult(new{ whatever you need to pass to it})). modern touch of server rendered site
Hydro makes it easier to work with temporary local state, for example a form in a draft state that contains fields dependent on each other, that can interact with each other before the data is saved
Honestly this year I started a new MVC project with Dotnet 8.0 and it works beautifully. Heck I even use JQuery for some light interactivity. Managed to get 850k in funding for the business idea. Don't feel discouraged about "SPA's being the next thing"... yes they're cool but ultimately choose which tools feel right for you and just ship features man
exactly this, I've always disliked the Cshtml and prefer blazor over it, but man an alternative to MAUI would be so helpful, either I'm writing blazor hybrid or avalonia, never ever again will I go through the maui BS
I don't think that MAUI itself is bad. The tooling is the real difficulty for me, when developing on windows (mainly because debugging on ios while being paired to a mac is slow).
Someone recently made a library called Htmxor that integrates htmx with Blazor SSR. There's a talk about it on the dotnet youtube channel. Still seems to be in beta though.
The problem a company I talked to was having is slow initial load times. Didn’t they fix this with a static site that gets updated when the new wasm is finished compiling?
@Talk378 The problem with Blazor Server is that it uses SignalR for interactivity. The problem with SSR is that the website is not interactive. I want my website bo be interactive all the time and i don't want it to use websockets (SignalR). So this is the reasons why i prefer Blazor Webassembly Standalone project rather than Blazor App (with all the complexities from switching render modes). I really like Blazor WASM but here are some points to consider before using it: - huge bundle size (~ 10MB) - slow initial time - no support for DOM manipulations (canva etc.) - bad performance (slower benchmarks than other frameworks) - small amout of js libraries ported to Blazor - Blazor community is still very small
@@bartlomiejuminski WebAssembly = long loading issue. Blazor Server = connection interruption problem SignalR. That's why I chose the third way: htmx with blazor SSR. Works quickly and is easy to write.
@@bartlomiejuminski With all those negatives I'm surprised that anyone would use Blazor. I build PWAs on the side (offline first) for personal use and my most complex app is 100kB total. The underlying code that makes it all work is 15kB total. Why would I force a user to download 10 MB just to use my site? That would kill my cheap phone.
For the sake of competition and growing ideas, please make more videos on it. Blazor is still preferred for now, but, competition is needed. I like the fact it at least makes it as easy as Blazor to write code. So I'm excited for that. And, to be honest, Blazor needs competition to keep it fresh. I love Steve's work, but what has been done in .NET 8 and the missing templates we have, is really making people furious and is complicated for people... Maybe hydro can deliver new takes on stuff, and we they can all steal from each other ;)
I've been excited about Blazor since it came out but haven't had a business case to use it so my knowledge of it isn't too deep, but the existence of Hydro made me question some of the things I thought I knew about it. I went to read the blog post to find out what the reasons were for building it. The idea that having a WASM version of .NET is overkill seems a bit silly to me since you can specify a CDN for that and it will be cached so it should slow down page loads at most once, and I recall that the assembly file was just a few MB, so it's hardly expensive. The SignalR re-connection issue I thought was mostly solved by a feature added in, I think, .NET Core 3.1. The load balancing and connection exhaustion issues might be the only concerns I had left. Anyway, for cases where a push model isn't needed, this AJAX-centered approach seems like a great idea.
I was, in the beginning, but I realized quickly that it was hard to manage temporary local state, for example a form in a draft state that contains fields dependent on each other, that can interact with each other before the data is saved
@@krzysztofjeske yeah if transactions require a lot of "local interactions" than having an heavier client may be beneficial and it's not gonna play out great with HATEOS since you have a state machine model spread between client and server but it's really good otherwise.
We have blazor static rendering with enhanced forms or we could just user static rendering and HMTX. This seem to need more bolier plate for the same effect. I can't think of any reason why I would want to use hydro instead of the static rendering options.
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#.
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#.
@@sulmarpl Could you show some examples? Last I tried it used minimal api and you lost strongly typed models when returning components. I fail to see the benefit of this compared to using razor pages with partial views and viewcomponents.
I went through WinForms and then WPF but wanted a better way of making good UI, went to MAUI which I found hard and weird to use and not so different from WPF, then skipped Uno but tried Avalonia (because of the good reception online) but the support for intellisense and various components just felt so clunky to me, at some point I noticed Blazor and liked it but I wanted to make regular Desktop applications, didn't want to use Avalonia so I decided to go with Blazor Hybrid in MAUI but MAUI does not support linux for some reason so I finally found Photino, which seems like barely anyone knows of it. I have yet to see how well it works for me And then there's this one that's new yet again
I recently found it too, it seemed really interesting. I developed something similar for myself however the blazor support of photino seems really cool.
I gave Blazor a try but it was too difficult especially in VS dealing with the random LSP issues. I’ve found Svelte to be a much better alternative. Svelte components are structured very similar to blazor and everything just works. It’s the easiest framework to whip up front ends in imho
wow, really interesting. I've been into Blazor for a couple years now. I do have some pain points around SignalR/socket disconnect issues, but overall it's a good dev experience. My WASM experience has not been great, but that's a side issue, really. It's great to see something like this being done. I'm not sure I want to pivot my effort into this, but I do like that this has a simple "feel" to it.
Socket connection and re-hydration issues should be a lot better in .NET9. If you follow Daniel Roth's talks in the community standups, he talks extensively about the massive changes being made under the hood to make Blazor9 a lot better. It makes me think that Blazor8 was released as an MVP, and was probably rushed out for the November deadline. They've fixed the interactivity paradox; socket rehydration; and, they re-written the Razor compilation paths from scratch, to make Hot Reload work a lot better with Blazor. As well as lots of other small changes that read like a laundry list of low-priority work items that didn't make it into .NET8.
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#. I just have one question that was not answered by this video: Nick included Alpine.js in the head of the Layout, that means there are definitely some client-side capabilities, i.e. interactive changes that do not require HTTP calls to the server. I would like to see how that would work.
I can see this being really powerful as a de-coupled front-end to OrchardCore. It's a bit of a pain to use Blazor as a de-coupled front-end, but because this uses Razor Pages, it would fit right in with the OrchardCore ethos.
If I got this right the updates to the page are all computed on the server. That is: send AJAX request to server, render new, compute diff, send diff back as HTTP response, apply diff - right? That causes many requests, NW traffic and compute time at the server. It is similar to Blazor rendermode InteractiveServer. That is not a good idea for general purpose.
As a former Perl programmer ("There's more than one way to do it!") I'm all in favor of reinventing the wheel, because we might just get a better wheel.
I love the fact that this is an alternative to what Microsoft provides. I think we need fresh ideas. I'd love to see how it will evolve. Right now, I don't see much benefit of using it over Blazor. Blazor will most likely be more efficient with the SignalR as a transport.
I'm just a month or two in on a project with blazor (first bigger project doing with it) and I encountered lots of things that I find really annoying with it. This looks more like what I had hoped blazor would be like. I'll definitely give it a try and check if it's worth compared to just using something like React
Interesting one, might give it a go for a project, I dislike the slow download of webassembly on first visit in blazor and server-side for high traffic web applications might get expensive
Kinda funny nick's been producing content against the same courses they are just launching in dometrain LOL EDIT (coming back after watching): I liked most of the showcase. It really feels like some of the stuff should've always been like that in blazor. What doesn't sell, imho, is the whole Subscribe/Dispatch/DispatchGlobal thing. Idk it feels like reinventing the wheel to just do events and event handlers, and the syntax reminds me of MAUI (which is not a good thing). Nevertheless the fact that the whole thing is just done with ajax and doesn't have the problem of the signalR connection or the wasm download delay feels like the step Microsoft should've always gone with.
Many people say that's it's like a old WebForms, BUT IT DOESN'T. SSR in react works like that, where it get just html element from server with content. And i think it's future of frontend because it's simple as it is. In my opinio it must be in blazor as alternative to SignalR
I have to say that Blazor hasn't caught fire like the industry thought it should - I remember Silverlight and that caught the imagination of all C# developers, but Blazor just hasn't ignited yet....and now a competitor.....
Hi Nick thank for your demo, did you try to make it can interact with external component like: calendar, date picker ... cause in the real application we really need them .
I don't see the reason for this approach. I am still going back and forth to the server for all state changes. Like others have pointed out, this is WebFirms all over again. Why would I take this over Blazor WASM?
I would love some alternative like cshtml in the desktop/mobile UI field, microsoft stickyness with the weird XAML is absolutely terrifying, and Comet appears to be stale...
@@yperman1 Naturally I'm talking about a native (in the sense of using the native elements of the system OR using another approach that is not embedding/consuming an entire browser in the app, like skia) alternative, the hybrid (at least of what I know) still uses a browser to do it's biddings.
@@diadetediotedio6918 yes it uses webview2. But it works perfectly I have created a few apps and it is very good. Everything is going to work throuhg a browser and the reason the cross platform thing. browsers work everywhere.
Seems great. But not sure why i would use this over blazor? If I'm not messing around with what's going on behind, why does it matter if its running on JavaScript or wasm? That's an actual question.
I want to see an example of you updating the page from an event received by the server. These events you showed are nice, but they are triggered from the front-end. Can you have the events triggered from the backend? Since its http, I am guessing... no way
Do you think, Asp team can introduce a similar thing to a blazer server so it optionally doesn't depend on signal R? Or signal R is cobbled to the implementation
What is the difference between the method you showed us to store the property data at 11:02 and the already existing component state that we have for long in .NET ?
I like that it uses plain requests, because it's better for scaling; It does have the performance compromise of multiple connection opens that Blazor doesn't have, but with requests, as long as the state isn't tracked server-side it doesn't matter what server responds, which opens doors to horizontal scaling and blue-green updates I hate it's syntax tho, ugly af
Never loved Blazor because of that lots of complexity we have in project. I wish there were something like NiceGUI, Dash, Flet and etc in Python, but in pure C# or F#.
It's interesting and competition is good but long running established frameworks have ran into issues after Microsoft released their own version, I might look into it on some hobby project but I hope the best for the developers
I never used blazor before (therefore I can be totally wrong here) but this Hydro looks very like the Angular approach to me… In the video I cannot understand if all those HTTP calls on the Add button are handled by the client or the server. If it’s on the server, it’s a bit of a bummer for me wasting bandwidth and processing for something the client could handle itself.
Nice video Please make a video showing viewmodel with multiple nested objects using lists in a form and using one form submit. Can't remember if you have made a video about htmx it would be great to get your opinion on blazer vs htmx and hydro.
I'm not sure why we get stuck in the loop of returning HTML. It seems that when you do that you get yourself stuck where your business logic gets stuck in the GUI section.
Definitely won’t use cshtml voluntarily again, such a big mess to do so little. For me, Blazer has a much better way to express components and pages and use them together.
@nick chapsas I would love a comparison between hydro and DotVVM. Thr former uses Ajax and the latter backbone.js, but both have 2way data binding without the signalR dependency.
lol 😅.. what if the counter is in db and u need to update it, r u going to increment it locally? Then what? This is just an example.. it is either an api or ajax that connect to the server to update the data Server is the source of truth
@@abdusuf523 What if it's *not*? The point is this framework and blazor have no choice but to rerender from the server, whereas javascript can do both.
@@catalystcorp But Blazor still offers WASM that would not need to render on any server. But at the end Blazor integrates great with JavaScript thats why everything that needs to be done on the client is either done with WASM or JavaScript in my blazor projects
Nick included Alpine.js in the head of the Layout, that means there are definitely some client-side capabilities, i.e. interactive changes that do not require HTTP calls to the server.
Hmm, reminds me of Webforms and update panels? I've created my own version of this 20 years ago, ultimately migrated to KnockoutJS followed by Angular. This is interesting but in my opinion not sustainable. I'm all for new frameworks and for someone to surprise me and prove me wrong!
reminds me of a laravel library, livewire. I didn't like it at all, since the people using it hardcoded it and it was a hard dependecy for everything. They were too lazy to use it only in the presentation layer, actually, they had no presentation layer lol
I don't totally dismiss Blazor, or this - but it is just amazing to me how much crazy stuff .NET developers will do just so they don't have to learn some JavaScript or a framework like React, Vue, or even Angular. Maybe I just still have some latent trauma from the years of the "Ajax Toolkit".
That's like saying c or c++ is to avoid having to learn Assembly. The whole point of Blazor WASM is you effectively get the entire .NET Framework and C# in the browser. If you're not a .NET developer yourself, the benefits aren't immediately obvious.
@@keyser456 It's not at all like saying that. I have been a .NET developer, and continue to be, since version 1.0. (I was also a C, and C++ developer). I wrote web apps with PERL on Apache before old school ASP. I think frameworks like React, Angular, Vue, etc. are really overused in enterprise environments. I think just server-side MVC/Razor is a better choice in about 85% of the cases. BUT, if you are trying to do a SPA type experience, the other end of the spectrum, your programming language of choice is the least of your worries. Abstracting yourself away from the DOM, from the browser, is going to give you issues. The DOM updates thing and state management is a pretty hard problem to keep it performant. And there are 100s of brilliant developers on the browser side struggling with this stuff - and making progress (reactive, signals, redux, etc.) and then I see stuff like the next iteration of "INotifyPropertyChanged" like Nick showed here and I just groan. Web Assembly in the browser is nearly abandoned. (Server-side, it's hot). I can see uses for Blazor (and this stuff) to add *some* interactivity to otherwise server-rendered LOB apps. I'm not dismissing it. I'm just skeptical.
Ah yes, people assume that other people are just stupid and don't want to learn. The same logic SQL fanatics use for why others use ORMs or MongoDB. It's not about learning. It's about simplifying our workflows and being more productive. I use Vue and I am sick of the build process being slow and breaking every once in a while so i have to debug my tools instead of my apps. I am sick of the node build proccess and it's overly large dependency eco system. Also with blazor server i just give an IQueryable to DataGrids and it just works with sorting paging and filtering. Datagrids used be the most time consuming thing to build and now with blazor it is trivial. With server blazor I don't have to write API code or the JS to consume it and i get the responsive feeling of a SPA.
This is NOT a Blazor alternative or competitor. You're comparing apples with oranges. If you built what you built with Blazor, there won't be any XHR call to the backend. And that's the beauty of an SPA.
I know it might sound kinda stupid, but I just want something like React but for Blazor, both pure Blazor and whatever this is look very irritating to write, I just can't bring myself to it
what kind of action? each action produces events that you can listen and modify before it's being sent rendered or whatever. But I implemented one where I was changing urls, simply get element, set attribute with new url, htmx.process and trigger htmx.trigger if that was your intention
![ละลาย (LALALYE) - DAOU PITTAYA ต้าห์อู๋ พิทยา [OFFICIAL MV]](http://i.ytimg.com/vi/wo6r9TgausI/mqdefault.jpg)
Hi, Hydro creator here. Thank you Nick for checking out Hydro and creating this video! Thank you everyone who tried Hydro, I'm grateful for the support you gave by starring the repo and testing the features. I really appreciate that. I appreciate also all the comments, positive ones and the criticism - both are needed!
Thank you for your awesome work!
I think it's something very interesting for quick and dirty applications like internal tools or concept prototypes.
Interesting project, keep up the good work! It's always good to have alternatives
@@xybersurfer Thanks! Could you say something more about the composability issue in Blazor? What's the main cause of it?
This is certainly a step in the right direction. Blazor and other technologies have become way too complex for very little benefits, but, for some reason, only programmers with 15+ years of experience seems to understand that.
Sometimes I see new devs in my company getting very excited with a tech or a concept that existed 10 or 12 years ago.
"This is running in the server? WOW!"
Just the other day I made a PoC in 30 minutes using WebForms and they were speechless 😅
lmao we're full circle back to webforms and update panels
Yeeeeah! :)
20 years later, I still have nightmares with webforms.
THANK YOU.... i thought i was taking crazy pills because i was think "oh, we back to webforms... wonder why we dumped that trash, can't really remember..."
Thanks for triggering PTSD
Yep
It's a cool idea, but late in time. Blazor 8 give us a lot of choice on how to create components and its render modes. I think that WASM is evolving in an effective way and it's the way to go.
idk, at this point i think i'll stick to blazor
Same here!
I prefer htmx 😊
I"ll stick to Silverlight ;-)
I'll stick to WinForms that is run on virtual machine which is then rendered on a page, but thanks!
@@markovcd Interesting. What framework are you referring to?
Competition is always good, and I genuinely wish the creator luck! That said, as a business owner & architect looking for a solid production-ready platform that will be supported for years going forward, Blazor still seems like the more obvious choice. I'm not seeing any compelling reasons for me to switch, not yet anyway. If nothing else, maybe this will force MS to address any major limitations in Blazor, and that's a good thing. :)
"as a business owner & architect looking for a solid production-ready platform that will be supported for years going forward" -- as one of those myself, I'm just sticking with React/Angular and plain old javascript/typescript with .NET on the server. This whole wacky circus tent that is Blazor and WASM seems like a nice way for dotnet devs to pad their resumés and waste time in scrum meetings coming up with convoluted DI systems when all they need to write is a couple of divs on a Contact Us page.
Whilst I agree, production ready and being around for years isn't really Microsoft's thing though is it! Sliverlight, Maui seem like good examples!
Blazor completely changes everything with every new .net version. I wouldn't call it stable. We have so many different blazors right now, it's a mess.
@@thefattysplace Fair points. I got burned on XNA / Managed DirectX and Silverlight. But... *everybody* who went down the Flash/Silverlight path got burned. The Mobile / Desktop shared space is always going to be volatile. Xamarin had a bit of a smell to it, and it's why I won't touch Maui. WebAssembly has been around for a while now (2017 looks like?) and has been adopted by all the major browsers. Once you actually build something in Blazor WASM you realize this thing has legs. It really is .NET and C# in the browser, like virtually no javascript is needed. A tiny bit of JSRuntime business here and there to achieve some hacky stuff, but I can see that getting resolved. I don't see WASM going away, but who knows for sure... I've got a lot of time and money invested into it.
@@thefattysplace I got burned on Silverlight, but *everybody* who did the Flash / Silverlight thing did. .NET and C# have been around now for over 20 years (I started v1.0 circa 2002). The real beauty of Blazor is in the SPA / WASM paradigm. WASM has been around for about 7 years now. It's here to stay.
I'm not sure how I feel about Hydro (reminds me of WebForms), but I generally agree that alternatives are a good thing. ...so long as we don't get to JavaScript levels of "framework of the week".
I was wondering if we are not getting back to webform era. Same thoughts as you.
The history of development paradigms is a spiral. What is old will one day be new again.
Hm, htmx with mvc/razor pages seems simpler
you can now do blazor SSR without signalR and return html sections (RazorComponentResult) from api controller (RazorComponentResult(new{ whatever you need to pass to it})). modern touch of server rendered site
It is
I've been enjoying this combination, too. Let servers serve html and decorate the front end a little to handle interactivity
Hydro makes it easier to work with temporary local state, for example a form in a draft state that contains fields dependent on each other, that can interact with each other before the data is saved
Honestly this year I started a new MVC project with Dotnet 8.0 and it works beautifully. Heck I even use JQuery for some light interactivity. Managed to get 850k in funding for the business idea. Don't feel discouraged about "SPA's being the next thing"... yes they're cool but ultimately choose which tools feel right for you and just ship features man
Im getting pretty sick of youtube videos not putting the name of the subject in the title
He should have spent his time creating an alternative to Maui.
exactly this, I've always disliked the Cshtml and prefer blazor over it, but man an alternative to MAUI would be so helpful, either I'm writing blazor hybrid or avalonia, never ever again will I go through the maui BS
I don't think that MAUI itself is bad. The tooling is the real difficulty for me, when developing on windows (mainly because debugging on ios while being paired to a mac is slow).
How do you feel about AvaloniaUI?
There's already AvaloniaUI and Uno Platform...
Microsoft needs to add more developers to support MAUI
Another good alternative is to use Htmx with Blazor SSR with a per-component route. There is no library for this, but it does similar behavior
Someone recently made a library called Htmxor that integrates htmx with Blazor SSR. There's a talk about it on the dotnet youtube channel. Still seems to be in beta though.
I'm currently using htmx with blazor SSR and it works great.
Htmxor is trying to achieve it so separate endpoints wouldn't need be created
There is a library. Check out Htmxor.
"there's no library for this" what type of library are you looking for?
Blazor hasn't even caught fire after all these years and now there is a competitor!!!
Blazor WASM is my favorite version of Blazor. Just a SPA website without any unnecessary complexity being added.
Word
The problem a company I talked to was having is slow initial load times. Didn’t they fix this with a static site that gets updated when the new wasm is finished compiling?
@Talk378 The problem with Blazor Server is that it uses SignalR for interactivity. The problem with SSR is that the website is not interactive. I want my website bo be interactive all the time and i don't want it to use websockets (SignalR). So this is the reasons why i prefer Blazor Webassembly Standalone project rather than Blazor App (with all the complexities from switching render modes). I really like Blazor WASM but here are some points to consider before using it:
- huge bundle size (~ 10MB) - slow initial time
- no support for DOM manipulations (canva etc.)
- bad performance (slower benchmarks than other frameworks)
- small amout of js libraries ported to Blazor
- Blazor community is still very small
@@bartlomiejuminski WebAssembly = long loading issue. Blazor Server = connection interruption problem SignalR. That's why I chose the third way: htmx with blazor SSR. Works quickly and is easy to write.
@@bartlomiejuminski With all those negatives I'm surprised that anyone would use Blazor. I build PWAs on the side (offline first) for personal use and my most complex app is 100kB total. The underlying code that makes it all work is 15kB total. Why would I force a user to download 10 MB just to use my site? That would kill my cheap phone.
For the sake of competition and growing ideas, please make more videos on it. Blazor is still preferred for now, but, competition is needed. I like the fact it at least makes it as easy as Blazor to write code. So I'm excited for that. And, to be honest, Blazor needs competition to keep it fresh. I love Steve's work, but what has been done in .NET 8 and the missing templates we have, is really making people furious and is complicated for people...
Maybe hydro can deliver new takes on stuff, and we they can all steal from each other ;)
I've been excited about Blazor since it came out but haven't had a business case to use it so my knowledge of it isn't too deep, but the existence of Hydro made me question some of the things I thought I knew about it. I went to read the blog post to find out what the reasons were for building it. The idea that having a WASM version of .NET is overkill seems a bit silly to me since you can specify a CDN for that and it will be cached so it should slow down page loads at most once, and I recall that the assembly file was just a few MB, so it's hardly expensive. The SignalR re-connection issue I thought was mostly solved by a feature added in, I think, .NET Core 3.1. The load balancing and connection exhaustion issues might be the only concerns I had left. Anyway, for cases where a push model isn't needed, this AJAX-centered approach seems like a great idea.
Hail Hydro!
Ward is it you?
Hi why are you not looking into HTMX + C#?
I was, in the beginning, but I realized quickly that it was hard to manage temporary local state, for example a form in a draft state that contains fields dependent on each other, that can interact with each other before the data is saved
@@krzysztofjeske yeah if transactions require a lot of "local interactions" than having an heavier client may be beneficial and it's not gonna play out great with HATEOS since you have a state machine model spread between client and server but it's really good otherwise.
Hmm good project, but a bit clunky compared to blazor. It sends the whole HTML as response, Blazor doesn't do that and is more efficient
Geez... if you squint, it is effectively web forms with ajax!
This is my current hell, waiting on my manager to greenlight the migration to Blazor
UpdatePanels into Razor pages 😹
Trauma!
Nick Chapsas, This is awesome! I subscribed because I want to see more!
This seems like a great option to migrate gradually from regular RazorPages
this looks great, especially for people who were mainly server side, perhaps this will give them the confidence to try a bit more front end stuff
It helps to add some reactivity to existing big non-blazer applications.
I played around with Hydro, if you are stuck with Razor Pages its a great alternative to Blazor. I like the fact it does not use Signalr.
We have blazor static rendering with enhanced forms or we could just user static rendering and HMTX. This seem to need more bolier plate for the same effect. I can't think of any reason why I would want to use hydro instead of the static rendering options.
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#.
Why not just use htmx with razor pages ?
I use htmx with Blazor Component. Better than Razor Pages.
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#.
@@sulmarpl In what way is it better?
@@PelFox I don't have to create the entire page. I expose the blazor component as an endpoint. Fast and convenient. You have to try ;-)
@@sulmarpl Could you show some examples? Last I tried it used minimal api and you lost strongly typed models when returning components. I fail to see the benefit of this compared to using razor pages with partial views and viewcomponents.
I went through WinForms and then WPF but wanted a better way of making good UI, went to MAUI which I found hard and weird to use and not so different from WPF, then skipped Uno but tried Avalonia (because of the good reception online) but the support for intellisense and various components just felt so clunky to me, at some point I noticed Blazor and liked it but I wanted to make regular Desktop applications, didn't want to use Avalonia so I decided to go with Blazor Hybrid in MAUI but MAUI does not support linux for some reason so I finally found Photino, which seems like barely anyone knows of it. I have yet to see how well it works for me
And then there's this one that's new yet again
I recently found it too, it seemed really interesting. I developed something similar for myself however the blazor support of photino seems really cool.
I had forgotten Photino! I was very interested when CODE Magazine first published it. The Blazor package for it looks appealing.
@@juffma Yeah true, I think for blazor I had to copy stuff that an example app showed, because the project templates didn't reflect it
Never heard of Photino, but gonna check it out now!! 👍
I've been looking at open source alternatives to wisej and Photino looks promising.
Developer should add the ViewState to hold the state. 😂
I gave Blazor a try but it was too difficult especially in VS dealing with the random LSP issues. I’ve found Svelte to be a much better alternative. Svelte components are structured very similar to blazor and everything just works. It’s the easiest framework to whip up front ends in imho
wow, really interesting. I've been into Blazor for a couple years now. I do have some pain points around SignalR/socket disconnect issues, but overall it's a good dev experience. My WASM experience has not been great, but that's a side issue, really. It's great to see something like this being done. I'm not sure I want to pivot my effort into this, but I do like that this has a simple "feel" to it.
Socket connection and re-hydration issues should be a lot better in .NET9. If you follow Daniel Roth's talks in the community standups, he talks extensively about the massive changes being made under the hood to make Blazor9 a lot better. It makes me think that Blazor8 was released as an MVP, and was probably rushed out for the November deadline. They've fixed the interactivity paradox; socket rehydration; and, they re-written the Razor compilation paths from scratch, to make Hot Reload work a lot better with Blazor. As well as lots of other small changes that read like a laundry list of low-priority work items that didn't make it into .NET8.
Nice, reminds me of HTMX, I will give this a try. Blazor isn't the best, people are coping it's lackluster at best.
Finally something like "hot wire" and "live wire" for dotnet 🍺
I think this is a better version of HTMX with Blazor static SSR - you can make reusable components, integrate objects from .NET DI container into them, and do a lot of cool stuff on the server with C#.
I just have one question that was not answered by this video: Nick included Alpine.js in the head of the Layout, that means there are definitely some client-side capabilities, i.e. interactive changes that do not require HTTP calls to the server. I would like to see how that would work.
I can see this being really powerful as a de-coupled front-end to OrchardCore. It's a bit of a pain to use Blazor as a de-coupled front-end, but because this uses Razor Pages, it would fit right in with the OrchardCore ethos.
If I got this right the updates to the page are all computed on the server. That is: send AJAX request to server, render new, compute diff, send diff back as HTTP response, apply diff - right? That causes many requests, NW traffic and compute time at the server. It is similar to Blazor rendermode InteractiveServer. That is not a good idea for general purpose.
There is no diff, it's UpdatePanels into Razor pages... it just re-render the component in the server and send the HTML back to the client
I'm in love with Hydro. Awesome.
*This sounds like the old "Update Panel" from Webforms! Oh, I see @MAMW93 has already noted this!*
Webforms like Winforms, forever alive ;-)
NO
This gives the same vibes as Livewire Components for Laravel, which is cool!
As a former Perl programmer ("There's more than one way to do it!") I'm all in favor of reinventing the wheel, because we might just get a better wheel.
I love the fact that this is an alternative to what Microsoft provides. I think we need fresh ideas. I'd love to see how it will evolve. Right now, I don't see much benefit of using it over Blazor. Blazor will most likely be more efficient with the SignalR as a transport.
Latency becomes problem number one here.
I'm just a month or two in on a project with blazor (first bigger project doing with it) and I encountered lots of things that I find really annoying with it. This looks more like what I had hoped blazor would be like. I'll definitely give it a try and check if it's worth compared to just using something like React
Blazor hadn't gotten that popular and there is an alternative already 😀
really hope c# doesnt turn into javascript that has 200 new web frameworks every single day lol
Pretty sure C# was doing it before it was popular with NuGet, just before it was considered a web-first language.
Interesting one, might give it a go for a project, I dislike the slow download of webassembly on first visit in blazor and server-side for high traffic web applications might get expensive
It would be interesting to see how this compares to htmx and razor pages.
Kinda looks a bit like htmlx where the server is doing the rendering and sending HTML fragments that the client side js uses to update the dom.
So why would we want this vs Blazor again?
Kinda funny nick's been producing content against the same courses they are just launching in dometrain LOL
EDIT (coming back after watching):
I liked most of the showcase. It really feels like some of the stuff should've always been like that in blazor.
What doesn't sell, imho, is the whole Subscribe/Dispatch/DispatchGlobal thing. Idk it feels like reinventing the wheel to just do events and event handlers, and the syntax reminds me of MAUI (which is not a good thing). Nevertheless the fact that the whole thing is just done with ajax and doesn't have the problem of the signalR connection or the wasm download delay feels like the step Microsoft should've always gone with.
Many people say that's it's like a old WebForms, BUT IT DOESN'T. SSR in react works like that, where it get just html element from server with content. And i think it's future of frontend because it's simple as it is. In my opinio it must be in blazor as alternative to SignalR
I have to say that Blazor hasn't caught fire like the industry thought it should - I remember Silverlight and that caught the imagination of all C# developers, but Blazor just hasn't ignited yet....and now a competitor.....
Poor man's Laravel Livewire.
I think this is more a replacement for aspnet mvc. Not match for blazor
Hi Nick thank for your demo, did you try to make it can interact with external component like: calendar, date picker ... cause in the real application we really need them .
Blazor doesn't seem like it wants to know what it wants to be.
I don't see the reason for this approach. I am still going back and forth to the server for all state changes. Like others have pointed out, this is WebFirms all over again. Why would I take this over Blazor WASM?
I don't like that you had to add external script tags to the project. Is that required or just an example for this video?
I would love some alternative like cshtml in the desktop/mobile UI field, microsoft stickyness with the weird XAML is absolutely terrifying, and Comet appears to be stale...
There is. Its called MAUI hybrid using blazor html css and c#. No need for XAML.
@@yperman1
Naturally I'm talking about a native (in the sense of using the native elements of the system OR using another approach that is not embedding/consuming an entire browser in the app, like skia) alternative, the hybrid (at least of what I know) still uses a browser to do it's biddings.
@@diadetediotedio6918 yes it uses webview2. But it works perfectly I have created a few apps and it is very good. Everything is going to work throuhg a browser and the reason the cross platform thing. browsers work everywhere.
@@diadetediotedio6918 Webview not a browser. Blazor hybrid > Blazor XAML (PERSONAL POINT OF VIEW)
Yeah, really like the Blazor Mobile bindings. You can try it out
IMMA FIRIN' MA BLAZOR!!!
I used AJAX when it first arrived, and it was beautiful and easy.
Sticking with Blazor...
Seems great. But not sure why i would use this over blazor? If I'm not messing around with what's going on behind, why does it matter if its running on JavaScript or wasm? That's an actual question.
Is it truely an alternative if none of the big component libraries adopt it?
this. no matter how cool or not, rarely there is a time or chance these days to pursue anything but established productivity
It's only 5 months old, give it some time :)
I'll check it out, but I would also like to do a shoutout for DotVVM which super mature (IMHO more than Blazor) and tested in the field.
I want to see an example of you updating the page from an event received by the server. These events you showed are nice, but they are triggered from the front-end. Can you have the events triggered from the backend? Since its http, I am guessing... no way
Do you think, Asp team can introduce a similar thing to a blazer server so it optionally doesn't depend on signal R? Or signal R is cobbled to the implementation
This use similar approach to Livewire, which has some sync problems on slow networks, specially when you have big forms with many dynamic lists.
Then he reinvented the wheel
not bad idea, but I just hate to know that every action will do http call
What is the difference between the method you showed us to store the property data at 11:02 and the already existing component state that we have for long in .NET ?
Thanks Nick, good information. HTMX is another great alternative.
BLAZOR all the way for me
Feels a bit like WebForms.
Don’t hate me, but I really liked WebForms.
I like that it uses plain requests, because it's better for scaling; It does have the performance compromise of multiple connection opens that Blazor doesn't have, but with requests, as long as the state isn't tracked server-side it doesn't matter what server responds, which opens doors to horizontal scaling and blue-green updates
I hate it's syntax tho, ugly af
Never loved Blazor because of that lots of complexity we have in project. I wish there were something like NiceGUI, Dash, Flet and etc in Python, but in pure C# or F#.
It's interesting and competition is good but long running established frameworks have ran into issues after Microsoft released their own version, I might look into it on some hobby project but I hope the best for the developers
I never used blazor before (therefore I can be totally wrong here) but this Hydro looks very like the Angular approach to me… In the video I cannot understand if all those HTTP calls on the Add button are handled by the client or the server. If it’s on the server, it’s a bit of a bummer for me wasting bandwidth and processing for something the client could handle itself.
So this is basicly more like HTMX with C#
I hope something comes out with jsx but C#. I don’t use blazor but i would stick to it then using this.
Not sure the value of Hyrdo. Is it just to remove the server required support for Signal R?
Nice video
Please make a video showing viewmodel with multiple nested objects using lists in a form and using one form submit.
Can't remember if you have made a video about htmx it would be great to get your opinion on blazer vs htmx and hydro.
I'm not sure why we get stuck in the loop of returning HTML. It seems that when you do that you get yourself stuck where your business logic gets stuck in the GUI section.
Adding a hole massive dependency bc of what? I would rather spend time using the tools that are given by blazor
This hardly can fight support of MS in blazor but it's interesting
Definitely won’t use cshtml voluntarily again, such a big mess to do so little. For me, Blazer has a much better way to express components and pages and use them together.
You do not need SignalR any longer
My only reason for using Blazor is WASM. This didn't appear to do that. The data binding is neat though.
@nick chapsas
I would love a comparison between hydro and DotVVM. Thr former uses Ajax and the latter backbone.js, but both have 2way data binding without the signalR dependency.
Why go to the server for every increment of counter
So sick
lol 😅.. what if the counter is in db and u need to update it, r u going to increment it locally? Then what?
This is just an example.. it is either an api or ajax that connect to the server to update the data
Server is the source of truth
@@abdusuf523 What if it's *not*? The point is this framework and blazor have no choice but to rerender from the server, whereas javascript can do both.
@@catalystcorp But Blazor still offers WASM that would not need to render on any server. But at the end Blazor integrates great with JavaScript thats why everything that needs to be done on the client is either done with WASM or JavaScript in my blazor projects
Nick included Alpine.js in the head of the Layout, that means there are definitely some client-side capabilities, i.e. interactive changes that do not require HTTP calls to the server.
This is a giant "meh" from me
Hmm, reminds me of Webforms and update panels?
I've created my own version of this 20 years ago, ultimately migrated to KnockoutJS followed by Angular. This is interesting but in my opinion not sustainable. I'm all for new frameworks and for someone to surprise me and prove me wrong!
reminds me of a laravel library, livewire. I didn't like it at all, since the people using it hardcoded it and it was a hard dependecy for everything. They were too lazy to use it only in the presentation layer, actually, they had no presentation layer lol
It seems to me that writting React in C# syntax ...
So you cached counter for all the clients. Id rather have a client side component and cache it in the browser
I don't totally dismiss Blazor, or this - but it is just amazing to me how much crazy stuff .NET developers will do just so they don't have to learn some JavaScript or a framework like React, Vue, or even Angular. Maybe I just still have some latent trauma from the years of the "Ajax Toolkit".
Yeah, Crazy stuff to avoid js & react crazy stuff and other mfe shit
That's like saying c or c++ is to avoid having to learn Assembly. The whole point of Blazor WASM is you effectively get the entire .NET Framework and C# in the browser. If you're not a .NET developer yourself, the benefits aren't immediately obvious.
@@keyser456 It's not at all like saying that. I have been a .NET developer, and continue to be, since version 1.0. (I was also a C, and C++ developer). I wrote web apps with PERL on Apache before old school ASP. I think frameworks like React, Angular, Vue, etc. are really overused in enterprise environments. I think just server-side MVC/Razor is a better choice in about 85% of the cases. BUT, if you are trying to do a SPA type experience, the other end of the spectrum, your programming language of choice is the least of your worries. Abstracting yourself away from the DOM, from the browser, is going to give you issues. The DOM updates thing and state management is a pretty hard problem to keep it performant. And there are 100s of brilliant developers on the browser side struggling with this stuff - and making progress (reactive, signals, redux, etc.) and then I see stuff like the next iteration of "INotifyPropertyChanged" like Nick showed here and I just groan. Web Assembly in the browser is nearly abandoned. (Server-side, it's hot). I can see uses for Blazor (and this stuff) to add *some* interactivity to otherwise server-rendered LOB apps. I'm not dismissing it. I'm just skeptical.
Ah yes, people assume that other people are just stupid and don't want to learn. The same logic SQL fanatics use for why others use ORMs or MongoDB. It's not about learning. It's about simplifying our workflows and being more productive. I use Vue and I am sick of the build process being slow and breaking every once in a while so i have to debug my tools instead of my apps. I am sick of the node build proccess and it's overly large dependency eco system. Also with blazor server i just give an IQueryable to DataGrids and it just works with sorting paging and filtering. Datagrids used be the most time consuming thing to build and now with blazor it is trivial. With server blazor I don't have to write API code or the JS to consume it and i get the responsive feeling of a SPA.
I have latent trauma from the years of the "React framework"
It uses AJAX. Blazor with WASM is an attempt to get rid of JS completely, isn't it?
It would be better if we could get the element reference and use System.Reactive to listen events
This is NOT a Blazor alternative or competitor. You're comparing apples with oranges. If you built what you built with Blazor, there won't be any XHR call to the backend. And that's the beauty of an SPA.
I know it might sound kinda stupid, but I just want something like React but for Blazor, both pure Blazor and whatever this is look very irritating to write, I just can't bring myself to it
everyone suggesting htmx, have you tried changing a htmx action url client side?
what kind of action? each action produces events that you can listen and modify before it's being sent rendered or whatever. But I implemented one where I was changing urls, simply get element, set attribute with new url, htmx.process and trigger htmx.trigger if that was your intention
Why are we changing url's client side? Can you give a concrete example?