Live data from Hacker News

Htmx is part of the GitHub Accelerator

htmx.org

261–270 of 520 posts

Re: Htmx is part of the GitHub Accelerator

#261
post #5

This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ Solution 3 gave me a good laugh though.

Not to mention there is no mention of error handling.

You just return an HTML fragment that describes the error with a header that says where to put it. The htmx JS API has events for errors too, if you want to do client-side handling.

Re: Htmx is part of the GitHub Accelerator

#262

Earlier quoted context omitted.

React is very diverse community, who are these react bros? I went to a series of JavaScript conferences and React is extremely diverse.

I was recounting the past. I'm sure it is "diverse" ( whatever that means ) now because it became kind of a industry standard for front-ends. Good to see diversity all around, I just wish there also would be diversity of thought and it comes to building web pages. But I guess that would lead to people admitting ~80% of all the stuff they build does not require React or equivalent js frameworks and that would be both…

> ( whatever that means )

I inferred that the intent was to say that not all people using React fit into one category.

> ~80% of all the stuff they build does not require React or equivalent js frameworks

I'm well aware of this for some portion of the things I build, but I don't agree that these frameworks are generally unnecessary or not preferable. It's also hard to say when something "requires" these tools or not. Arguably you could say nothing requires them these days.

I like to build with all kinds of tools though, and React and Vue are for example are often more helpful than harmful to my development experience. I'm speaking as someone who has been building things for the internet for around 20 years, so I remember life without these tools.

> that would be both an ego and economic/résumé problem

Maybe. I think this might be more true in roles that are closer to entry level, though.

edit:

From your previous comment,

> fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks

This is a good point. It's still a thing and will probably never go away, regardless of which frameworks we have. I think it stems from people fundamentally misunderstanding our core web technologies and not realizing how easy it is to do what they're doing without React or Next or Nuxt or what have you.

In many cases I've worked with people who wanted to do the most trivial things in their UIs and they worked tirelessly and earnestly to implement it with React or Vue, but it was something that already exists in the Web API or HTML elements. Basic stuff like reinventing checkboxes. Or reinventing the button element by styling an anchor and altering its behaviour with JavaScript to submit a form. So many younger people have started their careers in web development on frameworks, and they genuinely don't understand how the fundamentals work.

Re: Htmx is part of the GitHub Accelerator

#263

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…

>The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline. Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make s…

Are you programming on a phone?

Re: Htmx is part of the GitHub Accelerator

#265

Earlier quoted context omitted.

I'm not sure JS being slow was the reason. It's rather lack of trust that JS can and should be used for such things, and the difficulty of mixing client and server logic together. You kinda want to simplify things and relegate JS simply the role of detecting an event and delegating it to the server for processing and injecting the result back. But JS, from the moment it was introduced, was quite capable of carrying o…

In that time frame I was building very complex applications (semantic graph editors, decision support software for sales teams with 10,000 salespeople, etc.) in frameworks like GWT (Java compilers to Javascript) this wasn't long after the firstversion of Google Docs came out. Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-…

Entropy creeps into everything, unstoppably, masked under the pretense of a sequence of individually logical choices. To recover from this we will have to take a few steps back before we can make more steps forward. But we keep pushing and pushing, until either the tower we're building collapses, or us and what we do simply gradually become more and more complicated, with smaller and smaller gains that we focus on more and more, until it's all indistinguishable from background cosmic noise. Fermi paradox resolved.

Sorry, poetic diversion.

Re: Htmx is part of the GitHub Accelerator

#266
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…

This was a time when people were shouting "separation of concerns" without really understanding what that meant. Mixing the html/css/js required to make up one discreet UI concern? Heresy! Requiring at least three files to describe a discreet UI concern? TheOneTrueWay!

I remember the issue to be also that managing UI state on the server side was a load issue that many places didn’t want to deal with (e.g. Wicket, etc). The vibe at the time JS client apps came out in my circles was "thank God we can get rid of this UI stuff."

That’s still an issue I have with HTMX, but I understand for simple use cases it’s fine. I’d rather use HTMX than JQuery that’s for sure.

Re: Htmx is part of the GitHub Accelerator

#267

I started with Perl in ‘96 and have lived through what feels like everything — PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, and NextJS. Htmx feels like a divergence from the trend, and is worth thinking about. Htmx asks us a good question: “does the complexity of your work reside essentially on the server or essentially on the client?” The complexity for the vast majority of websites r…

> Wouldn’t it make sense to remove React from the stack?

God hear your words

Re: Htmx is part of the GitHub Accelerator

#268

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…

I've enjoyed using htmx and created a simple library in golang to help out. Here is an example app https://github.com/pyrossh/gromer/tree/master/_example

Legend. Well done for supporting, and for putting your money where your mouth is and laying down some code.

Re: Htmx is part of the GitHub Accelerator

#269

Earlier quoted context omitted.

This is a great project, and reminds me a lot of where folks saw hypertext going many years ago. I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client genera…

Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.

This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?

Re: Htmx is part of the GitHub Accelerator

#270
For first-time-devs, configuring + understandings development environments is usually 10 times more daunting than "learning to code". With respect to Typescript, NPM, Webpack, React, transpiling, sourcemaps, broken IDE probably makes webdevnewbies quit before actual code syntax.

In my dream world, HTMX could become part of the HTML6 spec, and beginners could spend more time dipping their toes in the water testing their .html files in Chrome before they face getting gobsmacked by the greater JS ecosystem.

Post reply on HN