Why Learn HTMX?? | Prime Reacts
Vložit
- čas přidán 6. 07. 2023
- 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 - Věda a technologie
FireShip just dropped 100 seconds of HTMX and now this. Are we all finally done with JS?
we NEED to add HTMX to official V8 engine to finally forget about js frameworks
@@dungeonmirlfg!
when JS gets overthrown, our pleas shall be known
@@dungeonmir yeah well after that, six months later there's hypermedia frameworks
HTMX Alpine HYPEE
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!
HTMX + Tailwind UI is amazing. I use it for internal applications whenever I can.
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?
Is this HTMX in 1000 seconds ?
yes
I sense this is a coordinated release with fireship!
That ramble about how to get a job and transition into the role you want should be posted as a stand alone shorts (it's at around 16:00) it's so good
Specifically from 13:30-16:15
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.
Yeah it's DHTML again :)
Hear me out here… what if we sent the HTML that we want the visitor to see… to the browser??? Somebody spin up a npm package!
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.
HTMX FE with Bootstrap for the UI and a Go BE is gonna be my go to stack for simple stuff for a while 😂
Exactly my thought
React: Ship more js!
Next: Ship less js!
HTMX: Ship no js!
Whats next? Yew in production?
What's next? Your web footprint is just a single download link to a traditional application.
I kid though, I like the hypermedia concept
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.
Combining htmx with alpine makes less than zero sense. There's nothing htmx does that isn't duplicated by alpine.
@@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.
do you mind sharing those advanced patterns ? =)
@@darkness1130+1. Came here to ask for an example
+2 would like to also see an example
Just want to mention Unpoly to me feels like a more mature version of HTMX. Definitely worth checking out!
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 liked this approach!!! We see a lot of "simple" pages with heavy JS libs, htmx is a great option.
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.
00:56 actually old scenexe did use json, there was sometimes more than 10 seconds input delay (ping)
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.
Great article and video ... only problem I had with it was the Hypermedia vs xxxxx, when really HTMX can be used with other techniques as well.
So it's like Phoenix LiveView and Laravel Livewire but you still have to write apis?? What's the point? I am confused.
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?
Transitioning from front to backend is also known as a "reach around"
- George Hotz
But is it good or bad?
@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 ?
@@windows99 Depends on what ur into
@@mikerollin4073 Women
@windows99 🤣 then go with the simple stuff you'll have more time for what your into
[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.
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?
Our UI is cruddy, does that count as a good fit for HTMX?
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.
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.
I like this nuanced approach to plusses and minuses on why to use a thing...
What immediately comes to my mind right now is: could this be used as a dom based backend in slint?
oh, Contexte reference from other video. I loved that french dudes presentation
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
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 🤔
Seems like a potentially good solution if you make "web sites" but a bad fit for "web applications"
depends... its about what classification of web applications can you not do?
twitter, i could see it being htmx... its just view + forms
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
3 months later, closing in on 200k subs!!
i can only see this as an option if i don't want to use any js framework/library for the project.
No mention of being Blazingly Fast?
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.
In the few times I had to look at React code, I almost gave up my career in technology and became a farmer
I feel sorry for future devs who have to clean up react codebase when companies decide to switch to a different framework/hype of the week.
@@P8860 we have had clean jquery code already, i dont see why we cant do the same with react.
@@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.
So this guy is like Doctor Disrespect but for coding?
i would like to say that dr is prime for gaming...
Glad to know that more people thought that. Almost thought they were the same guy the first time I saw him as Dr also codes.
Maybe like the Donut Operator of programming
html sounds so much like doing JSP or equivalent again :D
I never did JSP. How is that similar in your eyes?
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.
As a nood i still try to figure out if i can use htmx instead of html in my go templates
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?
It would be a mistake to use React (BLOAT!) for 99% of websites instead of something like HTMX
The reach-into-the-backendagen
I can't believe I just watched the two time himself, Dr Disrespect, give me a run down on htmx.
Go with HTML templates and HTMX are such a joy to work with.
How do I get started with your setup? I have Win7 x86.
@@lancemarchetti8673
1. Install Linux
2. Install Go
3. Learn how to use HTML templates and HTMX
4. ???
5. Profit
how tf do you implement a zero-allocation architecture
because it's helpful and on topic
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
Prime how could you forget about vim dap? I'll make sure TJ sees it.
So basically, the promises of XML (anyone remember XHTML), HATEOAS or the data-* attribute? What's old is new again.
Yes, it's HATEOAS. The htmx articles point out that it is the old idea that everyone missed out on.
"ok, just finished the time machine.. when are we now"
"browser request HTML and get innerHTML"
"so 2013"
Laughed out loud at "The name is 103ThousandAgen
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.
Yeah but a language/framework that constrains [visual] design decisions is encroaching on other disciplines.
@@rileypaulsen Then, don't use HTML.
It would be great to see you build a twitter clone using this
You posted this video at the exact same time as Fireship's htmx in 100 seconds🤔
Link to article please
lol, go to the bottom of their essays page with all the memes.
Finally!
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.
hahaha Rust Foundation (TM) keeps on creeping into the agenda!
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....
Just for fun,french names are hard to pronounce, in this case the t is mute, Guillot should sound like gooey, yo !
Actually it's more giyo, gi as in gigachad
133 thousandagen now babyyy 😎😎
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.
well the html can be in template files, as it used to be in the past, and with tailwind then there's no additional CSS layer
@@eduantech What about 2 front ends using the same backend api? To me it feels like going backwards.
@@bacon-SG why make the bad problem even worse lol
@@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.
13:56 : how to get hired
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.
I love how people complaints about a php, but still php get the job done. We often forget that regular users don't care about what technology we use.
@@SimplyDoomSlayer indeed is also true. picke the technology that works for your use case, users don't care.
I love how people complain about work, but still work gets the job done. We often forget that users don't care how much work went into it.
I complain about react and am happily married to svelte, zero regrets
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.
Till devs don't understand that tech used to market and sell to you some stuff. All these CZcamsrs will be not considered "influencers" like in other niches
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.
There's absolutely nothing compelling to me for the adoption of HTMX
as i try it, the more i like it. i felt pretty hesitant at first. its too... simple. then i realize, perhaps i have been too complex
After watching a few of your videos, I can't help but think that you are Charlie Day. Can you confirm or deny that statement?
wow 2 minutes in and I don't understand the article mentioned, it use so many complex words, basically non-english reader can't comprehend
I'm so optimistic for HTMX because i failed to apply Front End JavaScript.
Hypermedia is great, HATEOS is really great, GraphQL killed it.
There is no reason why HATEO*A*S and GraphQl can't coexist even in the same application. So neither needs to kill the other.
100k psychos !
When can we trash html and switch to something that doesn't suck. JS is html's fault.
Htmx just moves whole complexity to the backend. Less hurdles on front, 10x more on the back.
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.
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)?
Because htmx sounds more marketable.
I guess to copy JSX (JavaScript extension) for familarity
Perhaps they want to advertise it as "html eXtended "
Its HyperText1010
Use to be called intercooler 2.0 , but that didn't hit the same.....All about marketing easy remembered names.
Sorry bro leaving 'cause our boi Jeff uploaded too
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.
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?
HTMX is the next big thing
Trust me
have we all collectively forgot about html templating?
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.
@@macctoshfor a matter of fact htmx is mostly just a rebrand of an old similar project from the same author, forgot the name tho
@@macctoshyeah and its retarded
This is not software arts
Its software engineering
@@heroe1486intercoolerjs
You are right, developers are gullible people...
Article by a man with common sense in 2023.
What a shock
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
what about boilerplates and how we organize code? I see a lot of spaghetti in the horizon, sorry i won't eat this now as im in a strict diet
HTML templates are the secret ingredient here
I took the time to try it on some code and it's much cleaner and simplet than Vue.js + api. No spaghetti at all.
@@h0ph1p13 try a big a project then we can talk again, not just hello worlds....
for me, htmx and react etc are just a way of making js + html more limited
what is your real name?
Hey, congratulations on improving your reading to a 6th grade level. _hug_
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...
It really aligns with the KISS method. Why unnecessarily over complicate what should be simple.
hotwired turbo looks more powerful and easier
Aaaand it is until you run into an edge case.. then htmx is mucj easier to figure out and use 🤣
@@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
Already at 106.
js framework, nah
html framework, hell yeah
Colocating data within screen space is a terrible constraint.
🎯 Key Takeaways for quick navigation:
00:00 ⚙️ Hypermedia is efficient for large grain data transfer that's optimized for the web but not optimal for other forms of architectural interaction.
01:24 👨💻 Hypermedia allows your application API to be more aggressively refactored and optimized. It also reduces the need for extensive JavaScript front-end code base.
03:15 💡 For most single-page applications, adopting hypermedia is not an either-or decision. A transitional approach is recommended, using the right tool for the job you are working on.
05:12 💎 Hypermedia works well for CRUD-style web applications and can handle updates in well-defined, nested blocks of the UI.
10:29 🎮 Hypermedia may not be a good fit for applications where UI state is updated extremely frequently, such as online games.
13:45 💼 Sociological factors, such as team familiarity and job market demands, should be considered when choosing to adopt hypermedia.
18:08 🚀 Microservices can be beneficial but their scale and complexity should be managed appropriately.
20:11 🌐 HTMX can be a valuable tool for building simple, internal-use UIs, optimizing time and resource allocation.
Made with HARPA AI 👍 Upvote to improve video surfing
AMP pages😂
You might find bonsai interesting while you're learning OCaml.
meh '__') after looking some example, i'd rather maintain Svelte than that