In the past few years we have moved to front-end development of most projects to reactive frameworks or UI tool kits such as ReactJS, Angular, Vue, Svelte, SolidJS among others. While decoupling front end with backend frameworks has bettered performance and improved scalability, it has its own drawbacks.

One of the biggest challenges has been the steep learning curve associated with some of the frameworks. However once mastered developers seem to become more productive and hence able to deliver better.

Also this is helping us take the microservices path, and hence ensure code reusability, and cost gains.

However, this approach is not the best fit to every project. Every app we write doesn't need vast scalability or performance gains that the decoupled approach offers.

Also decent JS talent is expensive which is making our bids less competitive in a very competitive market.

Most of our backend development happens in Pythonic frameworks such as Django, Flask and Fast API. We have a decent Python team which has real world experience of building software for many verticals.

The team is reduced today to writing APIs using Django Rest Framework or pure play Python.

Why did the Reactive Frameworks emerge?

A decade back, we were all happy using Jquery to do web magic. It solved a major problem which was inter browser compatibility. With Internet Explorer dying a natural death, and with Firefox and Chrome becoming the industry standards, the need of just a DOM manipulator was reduced.

Emergence of front end JS frameworks such as Angular, React, Vue among a host of others changed the game. One they used components to build parts of the UI experience increasing ability to reuse components to build a rich UI system. They also targeted the virtual DOM which increased performance.

Most importantly they could take advantage of the rich and diverse JS tool ecosystem which has changed the way you build and deploy front end code. Also with Javascript moving to ES6 standards which have more modern programming concepts. This in turn has attracted more developers to the ecosystem.

However Javascript still remains a fairly terse language compared to Python or Ruby. This is a personal opinion and not to attract any language trolls or fanatics. In addition, programming polyglots are rare in our industry, though most developers claim themselves to be one. Most developers once they reach proficiency in one language, find getting out of their comfort zones difficult. Again, there are exceptions.

How does HTMX and Turbo Hotwire change equations?

Well it does reduce your dependence on Javascript quite a lot if you are already familiar with or proficient with backend frameworks.

They give you access to Ajax, Server Side Events, CSS Transformations, even sockets and data binding basically by manipulating attributes.

Overall reduction of JS code in a project reduces considerably. There’s at least one public presentation of how it has reduced the overall code base by 67% without any compromise in performance compared to a React web application.

I am yet to try Hotwire, but first few days on a new project with HTMX has been very rewarding. Early estimates are a saving of at least 50% in terms of actual code in the project. Right now, the time projected to close the project remains the same to accommodate the learning. And the learning is not steep, compared to any of the reactive frameworks.

We are yet to hear about any major projects abandoning React or Angular and using one of these technologies except for work done by Basecamp with Hotwire.

But I see no reason why HTMX or Hotwire or other Hyper script powered approaches will not be preferred over a Decoupled approach of maintaining two distinct pieces of code unless you are targeting a million plus users.

Our estimates are that we can reduce development time by 30-40% by the next project by relying on HTMX and a sprinkle of vanilla JS, and raise the bar in performance too.

Will this create a dent in Reactive JS frameworks?

No. I don’t think the traction for them will disappear. Considerable amount of money has been invested globally by customers and developers in skills and technology to power these projects. Also the world is moving to edge computing, and JS bundles running from edge servers or CDNs promise a lot. In addition serverless computing is getting cheaper, and could become mainstream in a couple of years.

But a lot of development work is actually building internal tools for enterprises big and small. This is the sweet spot which HTMX will fit in perfectly. My experience so far, which is less than a dozen hours, is good enough to validate that the technology is good enough for Single Page Applications. I still need to figure out the best approach for building a PWA using what’s available.

Low maintenance.

Python projects are comparatively low maintenance compared to work in other languages. Syntactically it’s easier to maintain Python code. Except for a sprinkling of JS code mostly to hook up APIs with Full Calendar our JS code base is less than 100 lines so far in the current project. It might have been 1500 lines of JS/JSX/React code otherwise.

So if your next project is not intended to be the next big thing, or is a prototype for the next big thing, then look at HTMX or Turbo Hotwire. A few hours of learning curve, and you would be writing code.

References

There's a nice youtube channel with a number ofuseful videos on HTMX by bugbuytes.

There's an ebookon hooking up Hotwire and Django with a companion website. I have not read it. But the content looks promising.

The official HTMX webite

The official Hotwire website

A Youtube video of of a presentation from David Gulliot on how they reduced 67% of code base by replacing React with HTMX presented in Django Eurocon.

The article is authored by S Ramdas, who is the founder-CEO of Netzary Infodynamics