Recorded live on twitch, GET IN / theprimeagen MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord Have something for me to read or react to?: / theprimeagenreact
As a backend developer, this gives me enough interactivity that I can create usable HTML pages. I needed a UI for a backend and was dreading trying to figure out how to tap into the React ecosystem. HTMX paired with a bit of Hyperscript, has enabled me to go further. If you're on the fence, check it out!
The problem is that even if you're more on the backend side of things once you know React/Vue (which doesn't take much time if you don't buy into some meta framework nonsense functionalities) it's not overwhelming at all and is easier cleaner and more versatile than those solutions, and it really starts to shine when you actually have "complex" needs and can benefit from those frameworks' large ecosystem rather than having to write them yourself or use vanilla JS.
@@heroe1486 100% if that's the goal, choosing some other tech might be more viable. For me specifically, I don't see myself switching to frontend React development, and HTMX is a stopgap solution that allows me to get a UI working reasonably well while not spending a lot of time onboarding. Another big plus is that I don't need to add any more tools to my development stack. Thanks for bringing up those points tho!
dude, react can be very simple, the problem is that lots of frontend developers want to make things complicated to alleviate their insecurity with backend developers, because backend developers have this talks of "we have to make a system that has to deliver 1 billion messages per hour" and they only were saying "look, it spins and its centered" so they felt bad and then started all this overcomplicated rendering strategies. React is simple, and is simpler when you don't use JSX, there is a js library that simplifies a lot the generation of virtual DOM from JavaScript itself that you don't need babble or any compilation step, tags become function calls like hello world becomes p("hello", span("world"))
@@sadboisibit This is the path I would like to explore. In the meantime, how do you integrate security (user authenticated) into the HTTP background calls made by HTMx?
I build many applications using this pattern from 97 to 05 on internet explorer 4 before AJAX was a thing. simply by avoiding the full page reload by requesting new html to put in any container on the page. It was a much simpler way to build applications and the technological limitations kept feature creep in check. nice to see the pendulum goes full circle 25 years later.
and it's even simpler now with fetch, DOMParser, and querySelect,etc being first class features to the point that HTMX is overkill even for it's own contact form example. The complication is SPA sickness has many running stacks incapable of serving simple fragments so they would need to just spit back the entire page which will offend the silliness of API design dogma.
I've been using htmx/alpine/astro combo and it's great, very simple mental model and allows for some advanced patterns that other frameworks still can't do.
@@fennecbesixdouze1794client side interactivity isn't handled by htmx, it integrates with alpine to give these features. This lets you blend spa/mpa to achieve some awesome patterns and use cases. It makes tons of sense and is very cool combo.
I would say it's more mature, but that it's more "batteries included" and is more of a framework while htmx is more of a library, which is why it often gets paired with alpine.js. Both are fantastic tools to have in your toolbox though.
This is the most "junior" theprimeagen I've ever seen and I really appreciate that. I think he is approaching a subject in which he does not have a lot of experience in a profesional way
JSON is not the best option in a lot of cases, but you'd be shocked just how fast most implementations are, and depending on context it can be smaller than a straightforward binary, eg where you're doing a lot of optional fields and normally but not always small numbers. I wouldn't expect it to be used over UDP, since if you're putting the work in to get that working then manually parsing the data is probably simpler, but i wouldn't expect a huge difference either way.
I was curious about React, but I had to get off that project after several months of pain. React on a simple web form probably wouldn't be so bad, but this project was creating an feature rich GUI editor that had to over up some specialized content/layout widgets. I feel like you really know what the hell you're doing when your working with React. The project also uses Redux, so you have to understand how to interact with that. I've been somewhat tempted to study alternatives, but I'm retiring soon and it not worth my time really get too much in the weeds with that and get my hands dirty. But, sometimes somethings sounds good until you start to try and use it. I've not heard of HTMX and I'm curious.
To me, there are several distinct scopes of application state: View state, session state (while not logged in), login session state, and global state. Imo, having view state (things like what tabs and/or dialogs a user has open, which elements are highlighted, what's currently being hovered by the mouse, what dropdowns are open, the positions of the various scrollbars, all that kind of thing) stored in client side storage just makes sense. There can easily be quite a bit of this kind of view state that the server should definitely not know or care about and that the user perfectly well expects to go away if they open the page in a different browser or open it on a different machine but which definitely should exist and be saved in client side storage and be taken into account when some or all of the view needs to be repainted for whatever reason. (I could be convinced, maybe, that database data in the view should be updated from the server whenever a part of a view that is displaying it is redrawn, but there are a lot of things that are needed when the view is redrawn that absolutely should be stored on the client and shouldn't need to come from the server.) I like the way htmx can set the value of a css and/or dom attribute of a target html tag to the result of a crud call. That's cool. But I need some way to two-way bind css and/or dom tag attributes to client side storage variables, and then update those based on crud calls.
Is htmx a good choice for an app that edits a db table? That app displays a db table in a html table where each row can be edited or deleted. I think if we use htmx, then the server will needs to talk to the browser in htmx (not html), right?
[18:20] There is this ancient story about two realms and the afterlife. There was this developer who died, and angel took his soul to this special place where a single server was sending data and UI elements expressed with HTML to multiple clients. There were no issues with the availability and the team maintaining it looked happy. The developer asked "wow, what's that place?" - it's heaven, angel responded. Next the angel (named Metaprog) transferred the developer to a similar place with the same application and the same hardware. But, instead sending everything to a client as hypermedia, the back-end was transferring pure data as JSON, and there were multiple API endpoints provided by multiple micro-services. On the client side there was also a separate application taking all that data and rendering it. The team of the exact same size was working day and night, without having any minute to eat or to sleep. "That looks similar, but everyone is so unhappy" - developer observed. "Well, this is a micro-service RPC hell" - Metaprog explained.
2:00 Technology fit - a sign of a good tech is one that explains it's "WHY"s, but the sign of a first class tool is one that would explain any simpler approaches before insisting on itself. There has never been a first class frontend library/framework because of this.
@windows99 depends, I would not do it, how fast do you need the website to be? And can you not just make it faster on front-end with async lazy loading or cache ... who are you catering for and why ?
I was wondering, where do you gather articles from? medium? edit: I saw you road some from reddit and personal blogs, but I mean in general, How do you find them?
It would be really powerful if it can somehow support json. With jquery i made my own event delegations, for a select element that automatically retrieves its elements from the server. But it uses a map function defined as a global, a small javascript, but it could be ommited if the data from the server comes with the right format. Maybe adding attributes like "data-json-prop" to add to the inner text or edit a value, would be enough? Im not sure, ill try to make my own implementation of a generic post request but with json. Json is really useful for table information, last time i tried to generate an entire table, it lagged so much with html from the server.
@@P8860 react is beautiful and it's been here for 10 years already, prob won't go anywhere, but i truly feel sorry for ppl who decided that writing ugly html is better.
The modern problem spans with the issue with 3D imho ... 3d has a huge potential market but load times for 3d renders need to vastly improve, if you could get the server to render it cache it and send it then maybe finally becomes viable 🤔
According to wikipedia, hypermedia is a "nonlinear medium of information that includes graphics, audio, video, plain text and hyperlinks". I think of this a lot like a wikipedia article: text and images mixed with links which take you to other pages with text and images. I'm having trouble seeing how they are using the term in this article.
The problem is that everyone is calling his blog a "webapp" because there is a fancy animation when you switch pages. If the distinction is Google sheets vs Gmail then yes, that's what the article says
I feel like much of the hype around htmx is based on the fact people hate js, i used it 3 years ago in a simple project and it wasn't as robust as a full frontend framework
I think it's good for simple apps and when your team is mostly backend engineers. Complex ui interaction are easier to implement by having client state. Also developing server endpoint to serve html does have a lot of issues when evolving the ui compared to json. Things like elements, classes, and dom structures need to be in updated on the endpoints too. Also sometimes you may not need certain features from the start, but if happen the case you run out of luck in a self limiting framework
HTMX can do JSON too and can have state, GitHub follows the same approach and has scaled really well by keeping things simple. If your app isn't an interactive game or something like Google Maps, docs or sheets, and is just a bunch of rectangles inside rectangles, you are likely not competent enough that you call such basic apps as complex and are likely overcomplicating basic stuff. HTMX is more than enough for simple things like email and chat clients and probably should be the defacto one for anything to do with forms.
backend engineers just love to reinvent the wheel on frontend, because they claim to know frontend better, without doing anything harder than not styled input form in it, it's so easy, right?(why then they are so scared to learn frontend stack i wonder). So just wait they'll soon understand why frontend frameworks were invented 15 years ago, and tons of articles will appear we are dropping htmx, it's a nightmare, how to scale it, like it was many times before with other stuff.
Wondering if they could extend HTMX to support GraphQL in addition to hypermedia? Hypermedia is awesome for long-lived apps where the owners of the server are different from those building the clients. But hypermedia typically requires backend development for the needs identified by front-end developers which can turn tasks that an individual could work on independently into a team task that requires communication and subsequent delays which adds friction and extends time to market; not ideal for those who are building clients for their own servers. Hypermedia is also very chatty which doesn’t work well for lower bandwidth devices like mobile phones whereas GraphQL requests can be one and done. It was seem to me that with some creative architecture HTMX could be extended to support GraphQL as well as hypermedia? 🤷
"Hypermedia is also very chatty which doesn’t work well for lower bandwidth devices" I was wondering about that. It seems that HTMX necessitates a lot of communication with the back end that wouldn't otherwise be necessary with an SPA that only fetches a big pile of data to populate the model layer and then handles the whole view layer with JS. I get that SPAs are bloated resource hogs, but it seems that HTMX fixes that at the expense of more bandwidth and higher frequency of requests, no? Or maybe the lack of a JS bundle evens it out?
Rails' Hotwire (TurboFrames) does not have the "limitation" of HTMX in regards to "updating many different dynamic areas". It's the exact same concept. Dno why HTMX can't implement it better ;P
At 7:15 you say you don't like colocation of related elements on the screen. I'd argue they almost always should be. Why? Because when you click a button you don't expect something halfway across the screen to change. It's really that simple.
what I'm doing with my life is eating beans with some carolina reaper cheddar mixed in and washing it down with string cheese and water while I watch this video.
Till devs don't understand that tech used to market and sell to you some stuff. All these RU-vidrs will be not considered "influencers" like in other niches
HTMX is cool if you want to render your content server-side, however, that in itself blurs the backend and frontend in an in my opinion undesirable way by adding an extra layer, and can easily produce unpredictable results.
@@bacon-SG This is probably one of the best questions to ask. My gut tells me that most of the time it will be more cost effective and clean to build your main web site in htmx and then design clean public JSON endpoints separately depending on what is needed. Too often whatever public api that is available is a real pain to work with when the endpoints have wonky designs made to fit the front end and not 3rd party devs.
@@Kalasklister1337 I feel like maintaining two different apis with the same business logic it's a source of bugs. Like implementing one thing in an API and forget or implement differently in the other.
It's sad that hypermedia is a strange thing to put on job listing vs react, when hypermedia is the web and react circumvents it to render an app over the web. Sounds backwards to me. I mean I get it, but it is sad when web developers only know react and not the the web.
Well I don't know react specifically but have written enough code in similar frameworks Oh and i know "the web"... htmx is much better than react for pretty much everything....
I think you misunderstood the first quote. JSON is an example of a format specific for your application. You need to program your client to understand the specific json you send from the backend, whereas HTML is universally understood by any browser
I love how people complaints about a react, but still react get the job done. We often forget that regular users don't care about what technology we use.
Please stop with this nonsensical argument, if they don't care ... devs care. And what makes you more happy and productive would obviously affect the code you ship and thus affect users, being because it's less bug prone, you deliver faster or whatever. Unless your users don't care about that but at that point you could just become an HTML developer, hardcode everything and call it a day.
So looking at the HTMX docs, it looks like it could be easy to integrate into most frameworks, and use it most, only using something like React where its absolutely necessary. Like who wouldn't want to replace a function that uses useX, useY, useMutation, AxiosError, mutationFn, several lines of code again, OnSuccess await etc etc, with ... something simple? Never understood why React developers accept this monstrosity, when rxjs has simple subscribe with clean syntax and grammar.
software engineering is all about the latest trend(s). Just like fashion where certain clothes/styles come into fashion and then are out of fashion and then come back into fashion. Software engineering is exactly like that.
Nope. It's similar. When you serve HTML you usually use templates (a simple, HTML-based DSL that HTML/CSS designer can understand, a simple string after rendering). You just don't have to create and maintain 2 applications.
There nothing more complex in the backend. It's basically still the same logic, just need to be presented differently. If the BE person still unable to template UI, then FE people can just helps template it.
You'd be surprised by the inappropriate uses of json in games. I've been working on modding a game that uses json for virtually everything. Minecraft, I'm pretty sure, also stores loads of info as json. Pretty sure stardew does too. Not to say that's a good thing. From what I can tell it's horribly inefficient. Thankfully none of them transfer that over udp far as I can tell.
I'm not saying it's better or whatever, but I'm really hoping that Blazor gets traction. I just want to write C# everywhere. I hope everyone understands.
It sounds like this would be good if you are working on something with a lot of complexity, like a bloated react site. Sounds like you could side step some frustration there. I'm not sure if it makes sense to introduce this to a new project or a simple one. I might be wrong
Define a "new project".. what are you building? 🤔 From my perspective anything that takes less than 1-2 months to develop is just a demo and not a real project...
its like tailwind of js, and i dont like tailwind. its not easy if you are trying to do modern css, limited. same way htmx is limited, reminds me of a js library i wrote when i was a junior, years and years ago while jquery was new. it sounds like the solution you are looking for but then when you wanna do something different its pretty limited. for example i used to be obsessed with making html + css only sites, without any js. i would generate bunch of css and html server-side to make it work. this also reminds me of inline js as attribute days, changing `outerHTML` and stuff. old days. now i just compile everything into a single index.html file with a vite plugin
This is my very first time hearing "HTMX". For those who know something about it, why is it called "HTMX" (Hyper Text Markup X(?)) instead of "HMML" (Hyper Media Markup Language) or "HML" (Hyper Media Language)?
@@h0ph1p13 what edge case? i worked with turbo and built everything i need, but seeing htmx overhead make me doubt that it can help build something similar
Multiple comments here start with something like "haha, try that on a big project". Well, IMHO some developers are like communist regimes in that matter: they are heroically fighting problems they've just created by using overly complex frameworks and architectures to express simple things. So, in such cases maybe it would be worth asking yourselves: would my app still be a "big project" without that turbo-advanced framework I just decided to use?
