Live data from Hacker News

Htmx is part of the GitHub Accelerator

htmx.org

191–200 of 520 posts

Re: Htmx is part of the GitHub Accelerator

#191

Earlier quoted context omitted.

How so? (no snark, genuine) Your frontend makes a request to your server, the expectation is that will respond with html. If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle. O…

Dear god. Have we forgotten about the ACCEPT header? If you get a request with ACCEPT application/json, return json. If you get one with text/html, return html.

Not sure if your “Dear god” is negatively targeted at my comment - I’ll assume it’s a general show of exasperation.

How likely is it every API will adhere to that though?

Re: Htmx is part of the GitHub Accelerator

#192
post #181

Earlier quoted context omitted.

That's fair. I agree - that type of blanket statement is not helpful in the technical realm. I should have kept it at just: HTML should have continued to be expanded into what htmx is doing.

I would have love to see rather than JS evolving to include HTML and CSS, HTML should have evolved to include JS and CSS as more first-class. Being able to write components in a single HTML file would be wonderful.

I've mentioned it here on HN before, but I've been using https://jhuddle.github.io/ponys/ for this and I still think it's pretty great.

Re: Htmx is part of the GitHub Accelerator

#194
post #54

Earlier quoted context omitted.

Many of the ideas and concepts in htmx are things we worked on starting around 2012 at a top tier investment bank. Implementation details differ quite significantly, but the idea of hypermedia driven applications was core to everything we did. We unfortunately weren't able to win hearts and minds around these concepts in the long run, and blog driven development (a.k.a. cargo culting) replaced our efforts. I feel som…

Or your marketing might not have been the best possibly, or people didn't spend enough time with alternative approaches to appreciate their downsides and why hypermedia based solutions could be better. (Just pointing out other possibilities because I don't know if it's a good idea to be hard on oneself when one isn't sure about what went wrong.)

These were internally developed tools, so nothing we really marketed externally but yes we definitely could have done a better job at our marketing within the organization. A lot of the criticism to our approach was typically not so much that the ideas were bad, but that they were "different from how everyone else does it" and by everyone else they typically meant Facebook and Google.

For example, global state management approaches like Redux were more or less incompatible with how we approached state management. We thought it was insane to build apps around the idea of global state stores (and I still do) but Redux became all the rage and eventually won the day. There was a lot of collateral damage as people then tried to shoehorn Redux everywhere. I left around that time, but hear that the cycle have repeated a few times since. Redux (and other tooling) didn't work out as expected so wheels have been invented again over and over. It's the way things go I guess, I don't dwell too much on it.

We probably could've done a better job at communicating why our approach was better, but ultimately we had limited ability to force anyone to use our tooling. There's also a hiring aspect in there. As Redux and other libraries that were "the thing" started to make their way into job descriptions it became harder and harder to convince talent that they should join us, because we didn't have that brand recognition and used in-house tooling. At some point you have to make trade offs and sadly top tier financial institutions aren't necessarily known for leading the pack in terms of innovation. It's kind of sad really.

Anyway I'm not particularly hard on myself or bitter about it at all actually. The self deprecating jab about poor execution should be read as tounge-in-cheek really, I'm very proud of the work we did back then.

Re: Htmx is part of the GitHub Accelerator

#195
post #173

hi there, as many of you know, i am the creator of htmx and I'm happy to answer any questions about it htmx has seen a surge in popularity, triggered by a video by fireship dev ( https://www.youtube.com/watch?v=r-GSGH2RxJs ) and a series of videos by ThePrimeagen, a popular twitch streamer on it hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here: https://htmx.org…

> my favorite after htmx That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?

i definitely think there is room for multiple implementations

unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' (https://unpoly.com/up.layer) which is something that doesn't make sense from htmx's "just extend HTML" perspective

Re: Htmx is part of the GitHub Accelerator

#196
post #65

Earlier quoted context omitted.

no such right exists; that would be like the right to rob with impunity of course clever demagogues and rhetoricians can write such things into legislation, just as they can write legislation that claims you have no right to speak freely, but that just makes the legislation incorrect, like the famous legislation declaring pi to be exactly 3

> no such right exists; that would be like the right to rob with impunity No, it's the same kind of thing as having your records "sealed", to not let a past deed haunt you. Not even sure what kind of logic jumps one has to make to equate something like this to "robbing with inpunity". For starters the punishment to robbing isn't remembrance of your robbing, it's jail time or fine etc. And, fun fact, the aforementione…

while i disagree with what you say, i want to say that i really appreciate you saying something substantial and reasonable, rather than just repeating the vacuous moral-relativist nonsense that is the rest of this thread

(i think your comment would be higher-quality if you also deleted your repetition of that vacuous nonsense, though, because it makes it harder to discuss the substantial issues here; there would be no point in discussing ethical issues at all if moral relativism were correct. you wouldn't have bothered to post a comment at all if you were the nihilist you are posing as)

remember that lashon hara is by definition truthful; the point of the story is not that it is commendable to say everything that is truthful

Re: Htmx is part of the GitHub Accelerator

#197
post #173

Earlier quoted context omitted.

> my favorite after htmx That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?

Same path for me here. In particular, I found unpolys codebase to be of higher quality.

henning is an excellent programmer, I really admire him and his work

Re: Htmx is part of the GitHub Accelerator

#198

It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...". Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course…

Almost all of these projects bring something innovative too. My take: we are missing the "refactor" step from the loop. It probably concerns other areas more than web dev by the way, but I would like to see more projects that not only build on top of the past experiences, but also remove the complexity from the solutions, instead of adding the features to deal with it. Achieve the same result with fewer layers, less code, less "stuff". For what it’s worth, HTMX looks exactly like the latter kind.

Re: Htmx is part of the GitHub Accelerator

#199
post #3

Congratulations! I had a fun time making a little project with Htmx, though ultimately went with something else as I ended up heavily using a openlayers, and map libs are notoriously heavy with clientside javascript and Svelte ended up being a better tool for the job. I plan on using it again for a future Golang project and look forward to following it's development. If you're in need of a simple/medium complex front…

The guy that manages their Twitter account is the creator himself: @recursivedoubts

Re: Htmx is part of the GitHub Accelerator

#200
post #192
post #181

Earlier quoted context omitted.

I would have love to see rather than JS evolving to include HTML and CSS, HTML should have evolved to include JS and CSS as more first-class. Being able to write components in a single HTML file would be wonderful.

I've mentioned it here on HN before, but I've been using https://jhuddle.github.io/ponys/ for this and I still think it's pretty great.

Woah woah woah. This is a game changer.
Post reply on HN