Hacker News new | past | comments | ask | show | jobs | submit login

Has anyone used htmx for a more or less large project?

Everything turns into spaghetti code really quickly.

Separation of API and frontend isn’t just for fun. It’s for making testing bearable.

Finally, mixing data modelling (database) with presentation (html output) in one place (htmx handler) goes out hand really quick too, making testing much harder.

But real coding cowboys from the golden age don’t write tests, right? :-)




Depending on what you mean by large, I have. Testing is just the same as on any server-side MVC application. And I don't get spaghetti, because the structure is provided by the backend framework. Same with the data modelling - there's a model layer in the backend project that can be tested independently of everything else.

I can only guess that you're trying to put all your logic and structure on the front-end, with the backend only serving what the front-end needs ad-hoc? Don't do that. Build a classic MVC app (Django, Rails, ASP.NET MVC), factor your views into small, reusable components, and use HTMX to replace page elements at that level.


I have, using htmx before htmx existed.

Similar concept and functionality. jQuery plugin attach events like "x-post" and other attributes, sends data to server which always returns HTML.

800+ CRUD pages full of business logic, around 2k routes, single PHP server, single MySQL server, serves up to 3k requests per second seasonally, P95 around 50ms.

Team still adding and changing features every 2 weeks, even after years in production. Stack is custom PHP framework, MySQL, custom jQuery plugin that acts similar to htmx.

Onboarding is dead easy. It was made with a no-build frontend stack. Meaning there's no build pipeline to understand and fight against.

I look at React/SPA misuses and self inflicted pain, and feel sorry for them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: