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.
I personally prefer sending JSON or CSV over the wire, and keeping all presentation logic on the client side. This allows me to adjust the presentation layer based on what's best for each specific client.
I feel that it empowers me as a Backend developer and makes me productive on both the BE and the FE.
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.
If you structure your backend correctly, it should be trivial to build a JSON API on top of your service layer. Unless you're coupling your http endpoints to your service logic.
I'm a Front End Dev and work with SPAs for the past 2 years. Working an offline-enabled PWA powered by Svelte and Redux. Honestly, I have a hunch that an HTML-based oriented development can still provide a great (measured) offline experience, without needing to rebuild wholesale to SPA.
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.
It's not exactly a lot of work to handle HTML for web apps and have an API for mobile clients or services. For example, if you are using Django, just add DRF with some serializers etc and re-use any common backend logic with both frontends.
Performance is the main one. Particularly on older android devices where script execution is absurdly slow, and network traffic is also often slow, pure HTML is a big win.
HTMX (and HTML over the wire) is giving me some hope for frontend development. React / SPAs have their place and are great technologies, but 98% of the time they are not needed.
I'm curious if you can link me to more information on Taconite? I have been explore the techniques used by "HTML over the wire" and htmx and would like to delve deeper into older systems or technologies that were using these before.
yep and thanks to /u/recursivedoubts for delivering an excellent package. I use htmx then mithril for those pages that really need client side interactivity. and it's refreshing.
> 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).
You can tear out some of the stuff (sse support, web sockets) and shrink it ~2k. Do away with the events mechanism and extension points, knock down the configuration options, drop IE support and probably get it down to around 6 or 7k.
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.
