IMHO something slightly more complex than this example (more client side stat) will require using something like React/Vue/Svelte. But there's no need to rewrite the whole FE. Just create a component that performs the rich client side interaction and use HTMX for the rest of your app. Win-Win.
Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.
IMHO this approach is better for most apps. Remix is bending the curve here. They make it extremely easy to progressively enhance a small part of your UI with all the power of React.
That said, using React on the server side and forcing you to run JS on the server is not my cup of tea...
The difference in programming model IS THE advantage of HTMX. Changing from react to preact is a perf optimization.
If you are doing the SPA thing correctly you must duplicate business logic (data validation). Also when your API just sends "dumb data" (JSON) to the client, you are forced to make changes to the backend and frontend in lockstep.
The programming model is totally different when working with HTMX. The server returns HTML instead of a JSON API which is the usual solution when building apps with React/Preact and similar.
I've been using this for years. Is really good and the best feature is that diagrams don't look like crap by default, which is not the case for most code to diagram tools out there. Looking at your Plant UML.
Ember's templates allows the framework to determine which portions of the DOM will never change, and so only needing to analyze the portions that might.
<div class="container"> <-- this won't change
<h1>Hello World</h1> <-- this won't change
<div>{{name}} <-- this might change </div>
</div>
#16 is one of the biggest pains we had to deal with but I think we now have a good solution for now.
We use brunch.io a node.js build tool. It handles concatenation and minification of CoffeeScript, Stylus and Handlebar templates for us but it can work with almost any front end technology out there. A cool thing is that we can use require within out CoffeeScript files and that allows us to better organize code into modules.
Brunch even provides file watching capability so when we save a stylus or CoffeeScript file it will update the browser without a reload.
In our setup we compile everything to our django static folder so when we collectstatic, files get uploaded to s3.
One thing that was a bit a tricky and something that we have to make better is cache expiration of files. For now we are appending static files with a few characters from the current commit hash (app.css?e2232 something like that), while this is pretty effective we've found some cache systems that ignore it. The next step is to rename files before uploading to s3 (app-e2232.css).
I agree that this might be a bit too complicated for most apps but in our case (getblimp.com) we have a pretty heavy JS app and we really need to take advantage of all the "better" front end tools available.
I will be willing to contribute to FOSS project to solve this issues once and for all on the django/python side. BTW I think that file watching is better than compiling on every reload during development. In our experience (many js files) request on the development side took seconds and became very frustrating.
After reading two scoops I started a new Django project and my first one using CBVs and I couldn't be happier. It now seems like django has two modes classical everything manual (FBVs) and the new some magic included mode (CBVs). You just have to choose.
I agree with you on: "I tend to hate about most "Methodologies" is when they're not flexible to the realties of your team".
That's why we made Blimp in such a way that if you don't want to use the methodology you don't have to and you'll get a very nice task management app. But if you learn the simple process and use it, the app will become smarter and it will help you more, if you need that.
The more you use the process, the smarter Blimp gets.
Just updated the blog post with an answer to "Why move from Trello to Blimp?" to summarize: Blimp understands the process your team is using so it can extract meaningful data from it. Head back to the blog post to read all of it.
My blog (elweb.co) has been on the HN home page a few times. I use Wordpress with WP Super Cache, hosted on cheapest available shared plan from Dreamhost with no problems.