HTMX is a true godsend for anyone working with Flask. Prototyping proof of concept webapps is so much more simple with it. I'm tryly blown away. Also, the learning curve is low and the API is straight-forward.
This doesn't get rid of javascript, rather it minimises it use, if you want to create a nifty feature that is not part of the example in the documentation, you will need to roll up your sleeve and implement it yourself. That being said, I will take this over any JS framework we currently have. And I love its simplicity. Been playing with it for some time now.
This is sleeper concept and library for sure. The current state of web development is insane with duplicated concerns and concepts on the backend and frontend. The fact there are so many frameworks on the hamster wheel endlessly rehashing or reimagining the same stuff over and over is telling Breath of fresh air.
if you think this is fresh air is because you are not old enough and you lack experience. I have seen this before, is called HTML, XML. Is going to be yet another fad that people will adopt because people and especially web developers are retarded and eventually after trying to make it work, people will adopt a new thing and will say the same retard thing "bReAth oF fReSH AiiiR"
Just started playing with HTMX yesterday, been developing with Flask for a few years. Really surprised how easy it is to work with, as I've always been turned off of using a JavaScript framework.
Nice overview! For anyone following me, jump to the chapter at 11:06 for actual HTMX - everything up to that is a whirlwind history of the web and how the reasoning behind HTMX was formed.
7:18, I actually hate this "feature" because it is the bane of bookmarks, there're places where it's usage is fine (such as latest news) but everyone seems to have the mistaken notion of "You should never have parameters in the URL or deliver a freshly constructed page for forms", that insane view has made most sites horrendous to use, there was no excuse for that mindset and it should've stopped centuries before it began
was happy to find htmx while attempting to use panel and bokeh to never learn JS but what's even better is reading comments from diehard JS people. It makes my experience on the web so much better lol. Thank you for the video and new things to implement or try to rather.
in an Laravel app i wrote at a certain point, because a colleague didn't want to use any frontend framework for conditional base forms with lots of ramifications, i ended up just making routes that were serving me partial html, dumping them in a target and adding events to certain buttons if needed , to be honest I either end up full page refresh rendering or frontend render, partial re-render can be hard to track for many But i am saying it now, if you are using reactJS your work is going to be a mess any way you put it because of component hell
Particularly I see HTMX as an extension of HTML and JS. I don't mind writing JS at all. I've always worked with HTML+CSS+JS, and HTMX is like this missing piece that was needed to not spoil a project with a js framework.
I feel like this would be a more popular successor to Turbo (used to be Turbolinks). The former library didn't really catch on outside the Ruby on Rails community.
Getting some serious Razor flashbacks here... in the end, at a given complexity of your project, you come to a point where you need full control and go back to Javascript and Json APIs. True separation of frontend and backend.
Very interesting. Does this not introduce a pretty heavy dependency on backend engineers to produce markup APIs, as opposed to standing up a resource endpoint that enables frontend/mobile devs to works independently? I'm unclear on whether this type of architecture is being suggested as a replacement to modern JavaScript frameworks, or something that can live alongside JS frameworks and clean up some percentage of over-engineered components.
I think it can live beside it. It could make certain things much simpler, such as forms. Thinking about "...dependency on backend engineers to produce markup APIs."; I think you could do this: 1. The frontend engineer creates the markup 2. The frontend engineer hands-off the markup to the backend engineer 3. The backend engineer defines the endpoint 4. The backend engineer returns that markup from the endpoint I think gives so many benefits! The frontend engineer can focus on markup and styling. The backup engineer can focus on the endpoints. There's no need to manage expected JSON schema as you're just getting HTM in the repsponse.
I think htmx is a bad match if you have a dedicated frontend and backend dev. Same way React could be a bad match if you're a solo or have very generalist team of devs that implements each feature from backend to frontend, wiring up Graphql or other api for your frontend to consume. It all depends on your organizational structure. No silver bullets.
They come from the backend webserver (written in any language you want), that probably does a database query and then sends the little fragment of HTML
Fascinating stuff! However, if you want more advanced interaction logic (only do this if something else is such and such), HTMX seems to fall short. Am I seeing this vaguely right?
i want to take your htmx and ruin it by adding a json translation middleware layer to your htmx in order to keep using json on my server and have mongo
I hate this 200%. because This reminds me to the very inventions of HTML & XML & JavaScript itself which were in themselves gigantic mistakes because they were exercises of precisely this so-called "pragmatism". There was already a standard called SGML and this pragmatist of Tim Berners-Lee who was also a "pragmatist" and a "contrarian" decided to ignore SGML because "it was too complicated" and he also decided to ignore torff and every other document format that was so much more simple than SGML/HTML/XML and then he invented HTML and HTML when it was invented and right now it was/is a mess because mixes structure, styling. It is supposed to be just about linking pages, so you don't have to download entire documents, but we developers are too "stubborn" and too "contrarians at heart" and we want to use things for what they were not meant to, we want to use water to contain solids. And now we have yet another contrarian at heart that comes to reinvent the wheel. 🤦♂ The same happen with XML, some random dude in Microsoft thought the same and reinvented the wheel because "muh, sgml too complicated" and then they made XML even more complicated than SGML by adding XHTML & XSLT & all the other standards. All the problems that we have is because we are trying to use things for what they were not meant to in the very beginning. HTML was never meant to be dynamic beyond links. Then we added JavaScript, and then JS was never meant to be used for applications and we have been using it. And HTML has already been extended to add web components to do all this stuff. Javascript was made shitty as it was because of the same reason "pragmatism" and is "just for small things because for the large thing we will have Java Applets" so what happen, we dropped the Java Applets and we adopted Javascript in yet another exercise of pragmatism. Every single decision in computer science that has produce mess and maintainability hell has been due to pragmatism at the moment and developers who are too coward to tackle the big problems or are not hired to tackle the big problems, they are hired to "be pragmatic for sake of profit" Seriously a data interface is so much better than a hypermedia interface. we are creatures of habits, what we need is to develop tools to help good habits at coding, and avoid case specific tools like this one because you never know how a website of a company is going to grow and some smart guy in the future will "add" dynamism, rice grain by rice grain to htmx, all over again recreating the same mess. We need a single tool for web development that is good at all the use cases.
esta libreria es un salvavidas a los que desarrollan en frameworks como django y laravel, ahora ya no se tendra que aprender javascript para hacer peticiones AJAX simplemente para cargar algun contenido en el DOM
doesn't htmx raise security concerns compared to something like react? also for someone using tailwind and then adding htmx, if the application got larger this would bloat the code, instead keepings cleaner with a separate be/fe. if tomorrow you don't like your ui, all you have have to do is swap with diff code. Doing that with htmx would take so long. I just prefer the ease of change with a fe separate from the be. I use django btw.
It wouldn't necessarily be a security concern, as long as user input is treated in a safe way. In some ways it can be a lot safer, actually, as more of the data is treated on the back end and then rendered into HTML by the client. As long as endpoints are secured properly, and user input is validated and sanitized (which is always a necessity), there is no actual safety concern. Separating back end from the front end isn't an approach I like, as it tends to require the necessity of creating painful JSON APIs. I can get why some people would prefer this approach, though, but it is important to keep in mind that relying to much on the client (with JS) for stuff that can be achieved by the server can cause some perfomance issues and slow down websites, as browsers are not rlly powerful
With backend templates you can somewhat separate htmx functionality from tailwind class strings. You can still swap your UI--it is somewhat easier because the endpoint just returns new html instead of bundling up your entire 300kb react monolith. You can still have a "separate" fe in the same backend language, just tuck it into a "view" folder or something
This is a clean and simple framework. I believe the popularity of this framework would skyrocket if an attribute like hx-accept="json" could be added to the target tag. This would also make this a true MVC framework.
before using JSON we were using XML, how is that any different to returning HTML? and HTML is not hypermedia, is just the language describing hypermedia.
He states 'this is all the code it took' but what he means is 'this is all the client-side code it took' Now we have to go back to writing server side templates with HTML fragments (such as table rows and cells) and return those on the callback instead of straight JSON. If I want to refactor an existing app this is going to be a pain. And, the payloads are greater. Plus, their examples (see the DjangoCon RU-vid on HTMX) require some pretty fancy JavaScript to do a well designed dropdown box, when React or Vue (for example) have readily available components you can simply plug in. I like the idea, but I still feel like I have a ton of work to do, in both JS and CSS, to build a fully functioning app.
React and Vue still have tons to do to resolve the growing pains of SSR. So far it's trying to either optimize or minimize hydration so that the same JS doesn't have to run twice (once on the server, another on the client) The only promising resolution I've seen so far to reconsider reactive frameworks is Qwik, which abandons Hydration altogether by delaying the loading and execution of JS as much as it can (vs. eagerly loading JS just so the SPA can be interactive again)
11:04, there was a simpler choice, instead of using javascript to invent a new language, use javascript to replace html (mostly), here's an example (I'll leave out implementation details) using dedicated function: ... Please enable JavaScript (or update/change your browser) to construct content with document.write(htmx( "form", { action: "GET" }, [ text = `@$ return getusername(); $@`; htmx( "div", "", "Welcome " + text + "!" ), htmx( "button", { type: "submit", value: "Click Me", onclick= function(self) { self.value = "You Clicked Me!" return false; } ) ])) Notice how instead of slowing down the page further this instead focuses on shifting all server code to strings where it cannot possibly be misinterpreted as html or javascript, it also shifts the construction into javascript where can be dropped in favour of the standard (), {}, etc, it would be simple for the server to just throw a javascript parser at the javascript to start with then go through the strings it found, parse them for @$ & $@ to shove it's own stuff in then shove the final result inside a the needed html and serve that, no overhead required. Additionally by using functions instead of modified html (that is not even valid html5, for shame!) it is much easier to parse the final result since there's only a small amount of html which is unlikely to confuse the parser
@@dejfcold Better than arbitrarily slowing down the page for shit you don't need, I'd prefer going full C or at least Lua instead but that clearly ain't happening, javascript is the next best solution, even if I hate it
Separating the data from the UI is a good thing because for any data, you may represent it many ways. I don't want my server to tell me whether to use a table or a div, just send me the data and I'll handle the rest, thank you.
Last time I checked HTTP (you know, *Hyper Text* Transfer Protocol) has an "Accepts" header, my dude. A web server is given data and serves it up in HTML or JSON. The user can send a request for what it wants! Also, if your framework can't separate concerns between data and views you are doing something wrong.
14:35 "this is all the code it took". I am not so sure, don't you have a backend to implement? And since the response has to be HTML, it should be a server returning HTML. Now you have your UI design exposed both in your HTMX frontend and your backend code. This seems super messy to me.
hypermedia is not html, hypermedia is combining text with format, images, audio, video and other interactions, I think you are confusing both of them. So what you are actually proposing is for a declarative web, more than a procedural web which is what javascript gives us.
This is good, for simple use cases... but it doesn't handle other stuff that the existing frameworks handle. eg. routing, history, templating, front end logic etc. If this become popular, surely people will build plugin and tools to handle those... thereby creating another web framework.. like with React, React Router, Redux, Animation library etc.
Do you need all the above mentioned if what is being sent back to you is pure html? Isn't routing is mimicking actual url? This technology is very new and I am using it with django, and I must say I prefer it over react or vue. And it's pretty fast too.
@@tochimclaren You probably don't need the above for simple project. But as your project specs grow, you will need to implement them... could be in the back end or front end. Either way, you will need to write code for it. For instance, a simple table with column sorting. HTMX doesn't handle that, React neither but you'll probably want to install a plugin or write some code yourself to handle that... or you can do it in the back-end. So my point it, when this becomes popular, people would create plugins for it... so it becomes another framework
For developing in Flask or Django, we don't need HTMX to handle all that as it is already handled by Django or Flask. And these are the thing that backend framework much better than any frontend framework can.
This replaces the need to create json objects to feed the frontend. If adoption grows, and people start using this, except for project specific use cases, djangorestframework might become obsolete. And the need to employ react and vue will drastically reduce. I use both react and vue, and I don't want to anymore, too much js everywhere.
@@mbbxx correct, HTMX doesn't handle table sorting. But stock Django does (basic sorting and filtering). And if you need more complex sorting, filtering, exporting... There's django-tables extension. With existing Django ecosystem + sprinkling of HTMX here and there it covers most of the major use case for full SPA. Granted there will always a need for SPA, but now we will only need to go that route when it's really needed. Hence that's why Django/Flask dev like myself are going head over heals for HTMX.
