Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

511–520 of 530 posts

Re: Please just try HTMX

#511

Post by adamzwasserman »

g947o wrote: post #495
adamzwasserman wrote: post #289

Earlier quoted context omitted.

Check out DecisionMe.com. 100 percent wizard pattern, htmx based nav and validation.

Eh.. this does not contradict the previous point? Unless we can see the backend code and do some comparison with a reference implementation, it does not disprove "far more difficult to express". "can be done with htmx" != "easy/easier to do with htmx"

True, but it is not my code to that with. so... If I ever open source one of my backends I will try and remember to flag it in a reply here.

Re: Please just try HTMX

#512

Post by marcus_holmes »

jimbokun wrote: post #475
marcus_holmes wrote: post #382

Earlier quoted context omitted.

This is all true. But then, if you ran HN and needed to hire new devs, you could find them extremely easily just by posting on your own site. HN is a well-known project that people would want to work on because it looks great on their resume and gives kudos when talking to other devs. In other words, HN does not have the problem that you are going to have if you use an unpopular language for your project. If you choo…

No, you will find strong candidates who love Lisp and want to quit their job slinging Java to work on your Lisp project.

Yeah, maybe. Though finding them is still harder than just using Java in the first place.

Re: Please just try HTMX

#514

Post by shkkmo »

catapart wrote: post #122
shkkmo wrote: post #49

Earlier quoted context omitted.

The standard invoker commands deal with the display of already loaded page content in the DOM. HTMX deals with loading content into the DOM, not managing display of the DOM. They serve two different roles and together should handle the majority of javascript framework use cases. Web Components does cover some of the same use case as HTMX, but is intended for when a server is returning data rather than HTML. It is bot…

> A prefilled list is never an acceptable solution for a search box. Yes it is. When the query is more expensive than the entire dataset included in some other query, a static list built from previously queried content is the more performant search, even if you want to classify it as a filter. I, as a user, am still searching through this list of unknown nodes even if you, the program, are just filtering what your no…

I can't quite follow your comment.

If you have a predetermined number of things that can be "searched" for, that is a filter box, not a search box. Even if you want to stretch the semantics and call it a search box, it is still a solution that only works for a very small subset of the search box problem space. Your criticism that this semanically stret hed snall subset wasn't explicitly excluded is just silly.

Re: Please just try HTMX

#515

Post by delifue »

azangru wrote: post #442
moregrist wrote: post #330

Earlier quoted context omitted.

I think the number of job postings is pretty related to factors that I do consider valid when selecting a piece of technology (eg: language, framework, etc): - How easy is it to hire people with experience in this? - Relatedly, how easy will it be for the org to maintain this software after I (or the original team) leaves?

> How easy is it to hire people with experience in this? When NoRedInk switched to Elm, Richard Feldman, who was asked about whether this impacted their hiring experience in any negative way, said that on the contrary, hiring had never been better, because although the pool of candidates grew smaller, their quality (either prior experience of working with type-safe functional programming languages, or enthusiasm for…

I head that Jane Street use OCaml and said similar thing. Although there are few OCaml developers they are overall better so hiring is easier

Re: Please just try HTMX

#516

Post by firemelt »

perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

what state management do you use? for the react

Re: Please just try HTMX

#517

Post by JCattheATM »

CooCooCaCha wrote: post #85
mikepurvis wrote: post #69

Earlier quoted context omitted.

To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward. I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show m…

What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it. React is easy for small websites so why would I use a separate framework when I can use one framework for everything?

Because React is bloat, especially for something trivial where it isn't needed.

Use the right tool for the job, instead of using the one tool you are comfortable with for everything.

Re: Please just try HTMX

#519

Post by nymanjon »

adamzwasserman wrote: post #250
johnfn wrote: post #227

Earlier quoted context omitted.

I would be happy to discuss more. I am genuinely curious (though I do hold a pretty strong belief that React is a good abstraction). When you say that the DOM is the authority on state, I’m not sure if that addresses my concern. Let’s revisit my example of the button. Image I look at the DOM and see that it’s in a “Submitted” state, and I think that’s a bug. How can I determine how it got into this buggy state? The D…

The debugging question has a direct answer: when you capture User State from the DOM (via manifest) and send it to pure functions on the backend, you get a perfect event source pattern. Not only can I can tell you exactly who and what triggered any piece of HTML being sent to screen, I can rewind and replay it like a tape recorder. The broader philosophical difference: I don't treat "state" as one thing. User State (…

This exactly. React is spaghetti code with the reducers. Using API end points to fetch HTML makes it super simple to see what is going on.

Re: Please just try HTMX

#520

Post by nymanjon »

athrowaway3z wrote: post #36

I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit. With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot. Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.

There's also htmz-be, nomini.js. Depending on your complexity needs.
Post reply on HN