htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

    htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

HTMX's platform is a resource for web developers, offering insights into building dynamic web applications with HTML, CSS, and JavaScript. Through articles, tutorials, and demos, HTMX offers insights into progressive enhancement techniques, AJAX-driven UIs, and server-side rendering. Readers can learn about using HTMX to add interactivity to their web applications, improve user experience, and simplify frontend development without relying heavily on JavaScript frameworks.

htmx

The post discusses an alternative approach to writing code that goes against some of the principles of Clean Code. The author argues that it's possible to write successful software using 'dirty' coding practices, such as using larger functions, focusing on integration tests over unit tests, and minimizing the number of classes and interfaces. These practices, according to the author, can lead to more maintainable and understandable code in certain contexts, and they provide a different perspective for developers, especially those who are new to the field.

> htmx ~ Codin' Dirty

# I Prefer Integration Tests to Unit Tests

“clean” code is always a good plan, but no plan survives first contact with the enemy (errr…user).

One of the many, don’t try this at home scenarios.
Leave dirty code to the bosses.

There are, in fact, scenarios where clean code and other good practices just don’t cut it. I won’t mention any without going against some NDAs I have, but some more sophisticated algorithms, where speed matters, suffer from lack of proper optimization when good practices are involved. Of course, code like that should be very well tested at the very least. It’s always about finding the right balance.

Preferring integration tests to unit tests sounds pretty reasonable to me
Unit tests often fall short at detecting real issues in the code
99% of the time it’s just false positive cause the structure of the code change and you just have to adapt the tests