ฝัง
- เผยแพร่เมื่อ 17 ส.ค. 2023
- 🐦Twitter: / typecraft_dev
If you're unfamiliar with HTMX, then you're not alone. HTMX is a web development library that allows you to create complex, high-performance websites. In this video, we'll give you a brief introduction to HTMX and how it can help you in your web development career.
HTMX is amazing and I think it is the future of web development. If you're interested, check out hypermedia.systems - วิทยาศาสตร์และเทคโนโลยี
Thanks nerd!
You mean daddy?
@@albinmiftari1832😢
We have adopted htmx a couple of months ago and can confirm that our productivity skyrocketed. I totally agree with your statement "The client should be dumb". "Modern" frontend frameworks add so much complexity that it hurts. The first time you tell people what a browser is actually capable of *besides* JS is always mindblowing.
Love it. Can’t wait to dove deeper
@@typecraft_dev 🕊
I gotta give HTMX a try. I never realized how much time I wasted doing conditionals in my React code
Can’t wait to build something substantial with it!
now you gonna do it on the server
Didn't you make an Video about HTMX a few months ago...?
yooo lewis sup
What is this clown doing here
Nice video, dude! Hyped about htmx. Would love to see more on it ;)
Thanks!
The funny part is that in order to enhance and achieve the "get back to the roots"-ish behaviour and methods to use html
we used JavaScript to build a little library which helps building simple reactive frontends with backends spitting out raw html as it used to back in the day
As soon as the complexity of the frontend increases we would still need to get back to writing JavaScript in order to granularly adapt results to the frontend
It’s true. But that’s because HTML never added more functionality (for server communication at least) so JS is the easiest way to implement this behavior ironically. BUT this is a far better pattern then the heavy single page apps
Less things to learn on client side and able to try new languages in the backend. Its a win.
This is the best explanation of htmx I have seen, and in under 4 minutes! well done
Hey thanks!
algorithm blessed me with your channel. subscribed. love the quick, to-the-point pace. no more 20 minute videos. thanks nerd!
Thank you!
I like the fireship style of delivery😂
This sounds like kids discovering flare jeans 😉😂 but I’m all happy we’ve finally reached this stage 👍🏻
SPAs are all great for their specific functional niches but world would be a much happier place if server-heavy websites and especially internal-use CRUD apps were built using SSR. Not everything needs to be Figma 😉
Oooo, I’m ready to start exploring this new tool. Thanks for the great explanation!
you got it!
After having my first JS written in 98' I'm so tired of continuous flow of frameworks, but this one looks a pretty new paradigm. Will need to check out ... (or maybe I still stick to plain HTML5, as there is no silver bullet)
I'd love to see htmx become integrated into HTML6.
I really like the way you explain stuff :)) Great vid
Glad you liked it!
Wow! This is the greatest video introduction of what htmx is, it's clear, concise, straight to the point and very fun to watch! referring to your video lol, not htmx :)
Thanks!! I had fun making the video
This video is based on the ebook found here: hypermedia.systems
I bought the hardcover book, I really enjoyed reading it and am happy to support the authors. It will be a real trophy on my shelf
For someone who has very little experience with html/css and javascript, what would you recommend learning, if I'm only interested in learning one framework, svelte or htmx? I'm actually a data scientist and mostly use python, but would like to learn one good framework, but only one. Thanks :3
If you want something more mainstream go with svelte. If htmx is something that speaks to you, feel free to go there too! HTMX is lighter in concepts than svelt/react/etc…
Good lord. I just listened to another TH-cam video on the same and damn near stabbed myself in the eye. I won't say which one, but this is fantastic. Thank you.
Awesome! thank you for this information.
My pleasure!
when u using htmx u will get a lot of requests from client to server and those request can atchive that easy by javascript, problem is if u have alot of traffic that will do problem is servuer from requests i guess
In terms of separation of concerns this is going a step back by coupling frontend and bancked work. But if you are not concern about this and want a full stack approach, this is good
Very interested in learning more about HTMX. I work primarily in Rails so I wonder how it compares to Hotwire and if I should try HTMX with Rails?
omg I think htmx is perfect with rails
btw how htmx can help with GraphQL or OData apis ? and what about UI libraries? Backend developers should send us fullblown components to swap?
You've just convinced me to take HTMX seriously. Liked, subscribed. Thanks!
Welcome aboard!
I’m wondering how fragments of ui split across front and backend is going to make things easier. Global mutable state causes challenges. Global split mutable state seems even harder. At least with json and apis the two were independent. An api that returns ui coupled to a frontend seems to add more tight coupling. At least conceptually.
Not everything is state -_-
With HTMX you have an event-based approach, you don't use state.
It's good old web 1.0 stateless request / response.
get->handler-> db call -> html template -> response.
post-> json->handler->db update->response.
Where's the added global mutable state? I must be missing something.
@danielhalachev4714 you'd have a json api service for those other clients. It's not about eliminating json apis.. It's about simplifying web clients.
Whew you got me PUMPED on it. Hard agree. The client should be UI interactivity only. In my day job I found myself replicating similar principles in a microcosm of our React framework. We went from sending one large chunk of data to the front and having a heavy front-end to many smaller requests based upon user interactivity. Guess which one was snappier! The idea that we can offload all that data handling to the client is a falsehood when you still need data from the back-end anyways.
very nice and clean explanation!
I have given up on JavaScript and have switched fully to HTMX. Its so much easier and overall better.
I don't think anyone is going to use this directly, but I'm excited to see how React and its derivations use this to improve over time.
I use this directly... why the fuck would you use this with react?
@@punkweb "Use this directly" meaning open an html file and start adding your s and stuff with HTMX.
I never said use it WITH React. That said, I realize now that this is a library and not a browser-supported technology, which makes my other statement (how React and its derivations can embrace this tech under the hood) irrelevant. So nvm
@@darkwoodmovies I think you've missed the point. You don't just start using htmx in an html file. You use it with something like django or php where you're already server rendering html.
You set up backend endpoints that return html and use htmx to call them and swap out/in parts of the dom.
@@punkweb Aah I see, hmm interesting. Feels a bit old school but I suppose that's the idea :)
This is definitely the future
I agree!
Always has been
This will definitely be great for making new custom web apps but that doesn’t mean don’t learn JavaScript and your frameworks since many companies or jobs cannot keep up with these new changes quickly
Now if we could get PHP on the front end we would have come full circle.
😂
Great video! htmx is awesome!
Thanks I agree. I’ll have to build something with it
PWA’s.. it was nice knowing you..
Now what to do about offline ? I guess we put the logic in the service worker ? Or maybe it's just not a use case it's trying to solve ?
There is absolutely no difference between the JS libraries and htmx. They all use the same dreaded JavaScript. You only write the frontend differently which i would argue that the react or the standard 'framework' setup is more modular and readable as well as easier to maintain because of good organisation. This just looks like another tailwind css library i have to learn to only get limited functionality
If you're open to having your mind blown, read the hypermedia systems book. The fact that htmx is written in js is a funny little implementation detail. It should have been done directly in the html spec decades ago.
That's like saying there's no difference between a studio apartment and a skyscraper.
Htmx is the future and the past rolled into one
It is my everything
Well explained
If I have my API return HTML doesn't it mean I can no longer use this same API on my mobile/desktop app?
You could have different namespaced endpoints for mobile/desktop apps. You could also use hyperview if you want the same hypermedia paradigm. Also HTMX isn't a one-stop solution, I think the idea is to use the simplest tools for the job, whichever job that may be
@@typecraft_dev Gracias
@typecraft_dev so maintain two sets of apis one so that we can use htmx on a website and then another to handle the same data calls for everything else?
Still waiting to see a live example of this
maybe I can help with that!
HTMX is great but falls short for some tasks. For exampe if I want to hide and show a part of my website. It is overhead to male a roundtrip to the server and load the whole part again and again for each toggle.
Totally but that's where javascript comes in. There's this misconception that if you use htmx then you can't or shouldn't use any javascript at all.
I used to think the same thing. But there is actually little overhead in the server roundtrip, and it keeps things very simple. If you need to update multiple places at the same time, then return a larger portion of the screen that includes both places. Very simple and you will be surprised how fast it works. I have implemented a web site with a SPA-feel using this technique. The site has less than 500 lines of JavaScript and they are mostly used for setting up DataTables components.
I'm techincally a Blerd, my ninja
I'm also excited about htmx, but not creative enough for coming up with content I could show on a website. :P There is already everything made. :P
3:20 i have been saying this for so long!
Me too!
I don't understand the example you gave. Based on the example, the frontend would make a request to "/users/1" and whatever would be returned would be based on what the backend was designed to return. The "hx-target" is just the element ID that you want to put the data that was returned in, right? How is that any different from using fetch(), getting the data, and then putting it into the HTML?
What if you want to change the UI/data in Navbar? Then you need to create a Root state then pass it to the children to update the UI.
In this you do not need to any of that and it will directly apply UI to Navbar
Instead of fetching json data and then parsing it on the client and putting into html
You simply retrieve the already built html.
@@shrin210If you want to change the data in the navbar you just type- document.querySelector(#navBar).innerHTML= (and just put what you want it to look like here).
@@crispi_shots Isn't that what the HTML tag is doing anyway with hx-get (or whatever it's called)? It's clearly a request to the backend/server. The hx-target is just the ID of what you're changing.
If a data API changes then it breaks the front end in a SPA. Your fetching code has to understand the shape of the data it is expected to get back from the endpoint. Either you have full-stack type safety or you have to look up the API documentation. The front end is tightly coupled to the back end. In HTMX, you just fetch the endpoint and display it. Your front end doesn't have to understand anything about the resource on the back end. Since all the buisiness logic is on the back end, you are free to change said logic without breaking the front end. @@eddyk564
so you basically tell that with htmx now backend developer should know how to design html web pages with paddings, margins, flexboxes and so on?
Looking at this now, I wonder about two things: a) why did it take decades to realize, how all this JS BS can be thrown out of web development again and b) when will these attributes get standardized, so that browsers implement them natively and we even get rid of the last bit JS to make this work?
Oh cool, someone has reinvented jQuery again
Looks amazing, guess i'm fullstack now
Hell yeah brother
3:28 Caching, where/howto?
With the html “cache-control” header. Sorry didn’t go into detail on it in this video
Define free, great, smart... I know JS sucks and being abused but I am truly skeptic and not ready to jump on another techwagon. Good luck guys.
I think the great part about htmx is that it isn’t a “tech wagon”. It’s very lightweight and isn’t meant to be used as a framework
Yeaaa now implementing my backend projects in web will be much easier
Hell yeah brother
i though this was fireship until i heard the voice lol
Then in 3-years… how do we reduce the massive number of calls to the server?
Doesn’t that already happen?
@@typecraft_dev not to the fine granularity of UI updates.
after a long time in more than a decade with the mess of react, angulat, vu...... etc... , this HTMLX seems logical
I don’t think this is what the web needs. Can you stream data with it? Will this not open new vectors for XSS attacks?
SPAs are still extremely useful in certain situations (like data streaming, etc...). But for the most part, websites (blogs, stores, etc..) don't need to be SPAs. I'd argue something like htmx is a far easier way to build/maintain those kinds of apps.
Ok u mention data streaming. what i think is nuts is that Steam company uses people's own hardware to store 70Gb games, and this is just normal. I Think that's nuts and I think this is how most pc gamers would do things. What if u want 50-500 games, do they just archive it then redownload b4 they want to play? that seems like a step backwards from disks. lol! I was listening to a programming podcast and apparently it is a very big lift to get games to stream like we do all our video apps. @@typecraft_dev
First of all, avoid the opinions of most JS programmers. Anyone who is not sarcastic will be fundamentally skeptical. They will talk about how HTMX handles JSON, they will say that it is not secure. They will even cite PHP to illustrate that you are using a new templating system. Forget the haters. The thing works, and serves the purpose. The learning curve is small and, unlike other models such as Angular, Vue and React, it requires project planning with another level of maturity.
Just as today, immature programmers make fun of PHP (which brought home the bacon for many developers and therefore deserves its place of respect), in the near future JS will be treated like mullets and fanny packs.
Htmx cant be used for building standalone apps though, as seen with ionic. There are pros and cons with all technologies. It is important to never disregard any specific technology
how is the htmx example not equally coupled to the api response, like the js fetch example is?
Daddy rambled about the good old days, skip to 2:30
sorry, daddy gets carried away
nice framework grandpa
Get off my lawn!
Isn't returning html from the server coupling it was supposed to eliminate? If we decide to change the UI structure, that has to be done in the API, or am I missing something?
Yeh but this is basically exactly what Angular the JS was supposed to be.
Also, what about the WASM? And does the DSL of HTMX limit the expression of logic in the UI?
I like HTMX, especially given the it “just works” for things like SEO: no alternate static site req - which is suspect to begin with if your robots know that they’ve landed on “planet namek”
You think too much in SPA world. When talking about htmx, you shouldn't make a connection to Angular or WASM at all. Because htmx is just an extension to good old server-side rendering: It helps you replace parts of your frontend state, in a very smart manner. But that's about it.
I thought that Elon musk rebranded html .....
😂
why the front should be dumb and we should make everything in the back ?
frontend should be dumb... as I'm learning React 🙄. It probably should be, but there are so many approaches to web dev it's really annoying. Like I've heard u can build sites really fast with Hugo / static site generators... this seems like apple to orange comparison tho. here's some buzzword ideas for your next videos: JSX, XML, AJAX, Wasm, websockets, vue, react when will it end???
I agree its confusing. But from my experience. The best applications have the mantra "the frontend should be dumb". Even the best React apps are made better when complexity is taken out of them. Its just a philosophy for web development. But I think its the right approach. (react is great btw)
Makes thinking of the famous "The Thirty-Million Line Problem" so much bloat and layer these days even in the web.
True
bring back car phones!!!!!!!!!
It’s all I want
I love htmx; I loath modern js frameworks that adds too much overhead. Make the web simple again is great! Love htmx and alpinejs. Simple, elegant and just work!
Agree 100%
golang + htmx
It may be useful ony on simple frontend apps, but why use htmx on simple frontend while you can use already battle tested template engines? Can't see a point of using this.
I've being waiting for years for js frameworks to die.
💞💞😍🥰🥰🥰🥰💕💕💕💕🥰🥰🥰🥰🥰🥰🥰🥰
As a frontend developer, I don't like htmx. I don't see how you could create a large complex app with it.
You write the app on the backed, instead of in the frontend.
@@roelvaneyken211 htmx is for all the javascript haters
What HTMX does it does better, but what it can't do React can. On the web the framework that does it all will always "win".
you call yourself "daddy" ? what a cringe... you have watched too much of fifty shades stuff.
nah u wrong, http obviously mean "hop to the page" lmao