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

471–480 of 530 posts

Re: Please just try HTMX

#471

Post by yawaramin »

catapart wrote: post #443
yawaramin wrote: post #380

Earlier quoted context omitted.

> it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much It's for server-rendered content that can be used to build a frontend app. I know because I've done it several times. > I would also have to write custom JS for the functions I would try to invoke with htmx The difference is with invokers you would have to re-implement everything from scratch and…

lol. oh boy! everything from scratch! must reimplement the whole library even though I don't package server responses for injection. glad you're enjoying your framework, friend!

Thanks. I love it when people make incorrect claims, I reply with corrections, and get condescending comments in return.

Re: Please just try HTMX

#472

Post by azangru »

mexicocitinluez wrote: post #464
azangru wrote: post #462

Earlier quoted context omitted.

I am deeply baffled by this kind of response. Firstly, because this site happily handles the amount of traffic that puts many hobbyist sites that happen to get on its front page into a hug of death; so its developers must have done something right on the backend that is probably above the web programming 101 level. But secondly, because this was precisely my point. One does not need a super popular front-end framewor…

> I am deeply baffled by this kind of response. No you're not. You're just trying to respond with something witty. It's a message board with 1% of the functionality most sites people are building with frameworks. > Firstly, because this site happily handles the amount of traffic that puts many hobbyist sites that happen to get on its front page into a hug of death; Lol are you really implying it's hard to scale a mes…

> Lol are you really implying it's hard to scale a message board?

I am implying that it is beyond the "3 pages from W3Schools", as you put it.

> A. Message. Board.

Yes. A fast, reliable, accessible message board that I and many others thoroughly enjoy. An awesome product.

Again, I have never suggested that its ui is complex. In fact, it's glorious how simple it is. This is the point that those htmx people make: use simple tools for simple UIs; and also, try to make your UIs simple.

Re: Please just try HTMX

#473

Post by azangru »

mexicocitinluez wrote: post #465
azangru wrote: post #463

Earlier quoted context omitted.

> It's A MESSAGE BOARD. A. MESSAGE. BOARD. Have you seen how many blog or portfolio sites people build with react? Sometimes even adding nextjs into the mix? Blogs!

So? That doesn't change the fact that HN is a dirt simple message board anybody could build.

> That doesn't change the fact that HN is a dirt simple message board anybody could build.

What is this an objection to? If you follow this thread upwards, where was it suggested that we should be talking about things so complex that nobody, or only very few, could build? The whole pitch of htmx is that it is proposed for building things that anybody could build. The article in the title assumes that the target audience isn't building Google Docs, Figma, video editors, or CAD tools.

Re: Please just try HTMX

#474

Post by moggers123 »

What's the grug brain method of "live updating list with a search bar". I tried htmx sse but it turned out to be not that great. I was hoping I could model it as a single request/response cycle like a traditional page post, with the astericks that the single response is actually a stream of responses. Clicking search or whatever again "just" axes the old request and sends another one with the updated parameters. Perhaps the form being dirty would actually be what axes the stream.

Re: Please just try HTMX

#475

Post by jimbokun »

marcus_holmes wrote: post #382
azangru wrote: post #306

Earlier quoted context omitted.

> One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second. The Hacker News website runs on Lisp. How many jobs do you see on the market that ask for Lisp? And yet, for what it is, this site is amazing! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.

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.

Re: Please just try HTMX

#477

Post by littlecranky67 »

yawaramin wrote: post #470
littlecranky67 wrote: post #429

Earlier quoted context omitted.

I can tell you, it is neither styled, nor does it work on Firefox (as in, properly works). And the mobile UX is horrible.

Perhaps Firefox should focus on shipping a good native datepicker instead of trying to put AI in the browser.

True, but completely unrelated to the original thread and issue at hand.

Re: Please just try HTMX

#478

Post by weiliddat »

ceuk wrote: post #459
weiliddat wrote: post #305

Earlier quoted context omitted.

Here's a real-time-ish planning poker written in Go + Htmx in ~500 LoC App (can take a few seconds to spin up if dormant): https://estimate.work/ Source: https://github.com/weiliddat/estimate-work

I mean I built a pretty featureful P2P planning poker app using React and it's around 1300 lines of typescript. More, but I don't think it's a mind-blowing difference and I wasn't playing code golf when I wrote it. I wouldn't have used redux if I was! https://github.com/ceuk/planning-poker

Oh cool, very interesting approach!

Did a quick test, since before this I also used some very ad-heavy p2p solution, and I see similar issues there. Not sure if you're looking for feedback, but these were all issues I considered before settling on a server-based HTMX long-interrupted-polling approach, which if you think about having server + client + realtime-ish features in the context of "just htmx" + tiny LoC is pretty cool (well I think it's pretty cool :D)

In the WebRTC p2p approach, without some sort of sync protocol that validates the state of data:

- the host must be online / already there to join a room; the host leaving the room means everyone gets kicked!

- if you rejoin a room and don't receive updates, you get a partial view of the data

- if you have data connectivity issues, you get a partial view of the data

- you must have a WebRTC capable browser and Internet connection

Re: Please just try HTMX

#479

Post by mexicocitinluez »

endofreach wrote: post #469
mexicocitinluez wrote: post #449

Earlier quoted context omitted.

lol JSX isn't a language. There aren't "JSX" jobs. I feel like only a backend developer trying to score "gotcha" points could make this argument and be confident about it.

> backend developer You mean a real developer?

The real developer who doesn't know that JSX isn't a language? lol Sure.

Re: Please just try HTMX

#480

Post by s2l »

moregrist wrote: post #330
azangru wrote: post #162

Earlier quoted context omitted.

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

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?

Even though I prefer htmx, another emerging gravity is what LLMs are good at. LLM-based coding/debugging/planning is a thing and going to stay, and if there are less code-bases to train LLMs, any new language/framework will be at disadvantage.
Post reply on HN