I recently started using htmx (https://htmx.org/) in combination with Django and have become a firm believer of sending HTML 'over the wire' instead of JSON structures that then get used client side.
Why do you prefer to send HTML over the wire?
For one it adds a simple set of primitives I need to learn on top of HTML (a basic tech to know), so no large JS frameworks or patterns to learn.
Secondly, it's really fast with regards to development speed, application speed and just getting up to speed in general. A basic MVC framework (such as Django but others also) is all you need in addition to the primitives I talked about above. With modern frameworks such as Vue or React, I need a backend with basically the Model and Controller part and then a different framework for the View part.
The challenge can come if/when your backend needs to start servicing a mobile app, or some other channel that doesn't use HTML.
But again if you know that won't happen, no need to prematurely optimize for it.
It's a totally different ballgame if the app is mostly client-side utility anyway (calculators, etc), but the HTML + a bit of JS handling Service Worker and offline presentation should enable a great offline experience. I haven't seen it done in a large scale, but it should work.
2. Or you expose an API for those mobile clients. You might still be saving more work (but this is subjective and depends on the project).
> Why should only <a> and <form> be able to make HTTP requests?
> Why should only click & submit events trigger them?
> Why should only GET & POST be available?
> Why should you only be able to replace the entire screen?
I love their motivation points, but do you really need 11kb of gzipped js to do this? At that point it's almost like a frontend library itself (mithriljs is only 9.5kb gzipped).
It could certainly be smaller, but to support things like CSS transitions and so forth it takes some code. I've tried to keep the power-to-weight ratio high by creating a rich events model and extensions mechanism to take pressure off the core library. My goal was to keep it under 10k, but I couldn't do it (I may pull SSE and WebSocket support out to try to tuck it under 10k again.)
On the other hand, compare it with the average image on a website, and 11k isn't bad.