Inspired by HTMX and other similar frameworks do the back end first development. These frameworks are good for really simple websites that need just a little bit of spice to make them work a little cleaner. Mine isn't as full featured as HTMX or as extensible and I'm going to clean up the code so it won't be as extensible as it is now. But it is nice because you write your HTML like you would a back end only app and then just add hf-ignore for any forms you don't want the framework to work with. I made the back end super performant so it will feel fast except for any latency. Since many front end developed apps are not optimistic in their API calls it doesn't make sense for them to build in any complexity.
If I had built my app with node or deno I could reuse much of the code and have it work offline too, which was my original plan but I like C# and I like deno more than node but deno isn't quite prime time yet for building apps. But once I write the service worker for it, it should be pretty fast with no latency and will transfer less data. I'm still thinking how I want to do that though. I've actually had the app running fully on the front end with no back end but then I needed to actually deliver something for my wife and just ported it all over to ASP.NET Core. It's been fun playing with all sorts of designs.
Also, mine works with no JS too with just a little bit of work on the back end to make it work for both cases. I really like how it has come out. But if I ever needed some more dynamic front end then one of these frameworks would definitely be nice to use!
Yeah we're seeing a return of interest in this area again. I've talked about this a bit in my SSR series. There is a logical desire to explore. I also work on backend first framework Marko written in JavaScript, which has lead me to appreciate how nice it is to have that unified single HTML feel.
That being said things are really converging. Frontend frameworks are looking how to unify their backend experience and vice versa. While for small things I'd probably go with whatever works, I strongly recommend anyone looking at this space to understand both sides of the equation. Obviously takes frontend not thinking SPAs are everything. But I've seen a lot of talk from the backend side not appreciating the intricacies of preserving client state. Every time we come back around we know a bit more and look at the problem slightly differently.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's my front end framework. I think it is under 2k minified (without being uglified first):
github.com/jon49/MealPlanner/blob/...
Inspired by HTMX and other similar frameworks do the back end first development. These frameworks are good for really simple websites that need just a little bit of spice to make them work a little cleaner. Mine isn't as full featured as HTMX or as extensible and I'm going to clean up the code so it won't be as extensible as it is now. But it is nice because you write your HTML like you would a back end only app and then just add
hf-ignorefor any forms you don't want the framework to work with. I made the back end super performant so it will feel fast except for any latency. Since many front end developed apps are not optimistic in their API calls it doesn't make sense for them to build in any complexity.If I had built my app with node or deno I could reuse much of the code and have it work offline too, which was my original plan but I like C# and I like deno more than node but deno isn't quite prime time yet for building apps. But once I write the service worker for it, it should be pretty fast with no latency and will transfer less data. I'm still thinking how I want to do that though. I've actually had the app running fully on the front end with no back end but then I needed to actually deliver something for my wife and just ported it all over to ASP.NET Core. It's been fun playing with all sorts of designs.
Also, mine works with no JS too with just a little bit of work on the back end to make it work for both cases. I really like how it has come out. But if I ever needed some more dynamic front end then one of these frameworks would definitely be nice to use!
Yeah we're seeing a return of interest in this area again. I've talked about this a bit in my SSR series. There is a logical desire to explore. I also work on backend first framework Marko written in JavaScript, which has lead me to appreciate how nice it is to have that unified single HTML feel.
That being said things are really converging. Frontend frameworks are looking how to unify their backend experience and vice versa. While for small things I'd probably go with whatever works, I strongly recommend anyone looking at this space to understand both sides of the equation. Obviously takes frontend not thinking SPAs are everything. But I've seen a lot of talk from the backend side not appreciating the intricacies of preserving client state. Every time we come back around we know a bit more and look at the problem slightly differently.