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.
Htmx is part of the GitHub Accelerator
261–270 of 520 posts
Re: Htmx is part of the GitHub Accelerator
#262Earlier 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…
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
#263It'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…
Re: Htmx is part of the GitHub Accelerator
#264Re: Htmx is part of the GitHub Accelerator
#265Earlier 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-…
Sorry, poetic diversion.
Re: Htmx is part of the GitHub Accelerator
#266Earlier 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!
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
#267I 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…
God hear your words
Re: Htmx is part of the GitHub Accelerator
#268hi 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
Re: Htmx is part of the GitHub Accelerator
#269Earlier 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.
Re: Htmx is part of the GitHub Accelerator
#270In 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.