We have a load of dashboards for all our internal services. These are being successfully converted to pure htmx. We are seeing that we can move quicker. The JS devs are moving to backend which gives us so much more bandwidth to get important features added. It's awesome imo.
@@illegalsmirf JS on the backend? No way that will ever happen! We use Java and Python. We're trying to use the same template language so we can share between the two. Not there yet, but we will.
I think this is where you are wrong. It's like doing a 'hello world' and then concluding that it's not scalable. I have been on various React projects and found them overengineered and hard to maintain. I recently switched to HTMX, and it's like night and day. Functionalities are shipped to production 60% faster and cheaper using HTMX compared to React. The code is easier to read and maintain, and new joiners to the project pick up the application code base much more quickly. I have dropped React and most single-page applications (SPAs) from my development stack unless they are required. So, right now, it's 90% HTMX and 10% React, after five years of React development.
@@IllarionYolgin 10% of our projects are dedicated to animation-related initiatives, specifically involving online video and graphic editing. To ensure swift updates to HTML nodes, we employ React for these components. Apart from that, the majority of our work relies on HTMX.
htmx isn't just about simple projects, and its main benefit isn't that you can get started with it faster. Its purpose is to change how/where state is managed because react is arguably a mess of a way to do things. htmx clients are stateless frontends, and are backend agnostic. It also doesn't use a virtual dom. It's good, clean engineering, which is a lot more than I can say for some libraries.
@@grimonce The next beautiful thing comming is a php-like templating language that supports all this (and more) without actually using HTML. Which will become a fully fledged server-side deveoper solution. Then you only need JS to sprinlkle over the top and... wait a minute.... someone has to invent jQuery now.
@@tonianzlovar7590 That's not the idea, htmx is about don't worry how you do the things in the server, youre free to use Lisp, PHP, Golang, Rust, Python, NodeJS. Do you understand? Htmx it's not PHP.
i heard that retoric in the past "oh don't use that because it's not for enterprise applications", "it's not going to scale", "etc" me "that sounds like a skill issue"
There's never been an enterprise web application in production that didn't use react. The internet didn't start until 2013. Php doesn't exist. Ajax doesn't exist. Request/ Response cycle? What's that? Oh is that the thing that connects your json api to the frontend?
IMO It’s not convenient to work this way without separation of logics and UI, components is a better way (even in php) since you can connect everything from everywhere otherwise it’s not very modular, you wouldn’t want to create an html file for every template part, you don’t want it to be accessible from outside. also the html file is already populated leading to problem with SEO so ax he said for working quick and dirty it might be good but it’s dirty, again, my opinion…
HTMX is absolutely great. It makes HTML how it should have been developed during the last 15 years. And for someone who is developing websites since 1996 the functionality of HTMX is a godsent. The web was never so poorly performing and unreliable since the dawn of the fat JS-clients. This geek BS needs to end asap and HTMX is paving the way into a healthy again world wide web.
@@illegalsmirfit is. But the essential difference with modern SPA frameworks and HTMX is the architecture how applications are developed with those technologies. With htmx, the frontend no longer is this huge monolith application with it's own state management and all that. Instead, it simply focuses on the presentation and the backend handles the business logic & application state and provides the frontend with html fragments to be displayed to the end user.
@@diegoronkkomaki6858 Except when your application has massive state, and putting the management of that state on the backend leads to insane scalability problems because you want your backend to be as stateless as possible so you can reduce your http "chattiness", hence reducing your app complexity, and your server infrastructure costs. From a programming maintenance perspective, by pushing state onto the server, you now have 2 layers with tight coupling with 1 living in the browser and the other living in your server. When you have a team of 5 people working on that they are gonna make mistakes, lots of them, and before you know it you will have a spaghetti mess of bits and bobs glued by 20 round trips to render a single user dialog. Now you might be thinking that wont possible happen to you. You are very smart after all, you are better than all those thousands of programmers. But once its time to implement that feature, and that feature requires the user to update the screen with almost every click, you will inevitably need to put a bit of temporary state in the client side to avoid the thing to just stopping into a crawl under load with the user experiencing a 400ms lag in between clicks. And then you will see that your pretty little server side state can be no more, and you will make one concession, then another, and then another, and you will be fighting against the tide. Trust me, I've been there, I'm talking from experience, I was the guy that made that mistake. Htmx has its place, but its not for application development where one page fundamentally depends on what happened in another page or in another section of your page. Htmx is best used for website development were the good old "each page is a completely new thing" is actually applicable. This whole wave of Server Side Rendering and pushing the state back to the server is a huge step backwards. Personally I think its a mistake for most sites that need any heavy user interactivity.
This take directly contradicts a lot of what the HTMX page he's viewing says. If you actually take the time to read over their "book," they do not at all say you shouldnt use JS (or client side scripting in general). Instead, they put limits on what you should use scripting for. I'd also challenge people to try using it before you assume it can't do what React does. Their example implements custom menus/toolbar, infinite scrolling, active search, form validation, etc, all with minimal scripting (but not none). They even point out when you should and shouldn't use it. But I think this whole SPA hype has caused people to miss out on how powerful hypermedia can be. Their book is not a long read and definitely worth it for at least getting a different perspective on things.
I think that frontend developers sometimes view themselves as a priest cast, and feel threatened by simple frameworks that ‘anyone’ can use. HyperCard also threatened full-time developers back in the day.
we do, and we were! not threatened any more. CMS won that round and it's looking like AI will take the next one. backend think *they're* priest cast, what with god mode and all that, but luckily they're priest cast so we're good there
@@flygonfiasco9751 You can return JSON if you want, just change the header for that, but if you're using using HTMX mainly for return json, so you dont understand the concept of hypermedia, so this guys Doesn't have idea what he is doing.
@flygonfiasco9751 yes external api’s might use json but ideally your htmx app will access said external api’s from yr server !! and pipe html to yr htmx client - not json..
oh dear did so well till the end, this scales incredibly well. I started in 92 after 5 years of BBS have been through all the frameworks and I mean all, settled on vue for the last 8 years or so with too many journeys into react and angular, toyed with svelte. Now I am back with a java stack, zero build time (modern java compiles as you write) high performance, serverless, monolith, dist architecture, fast deploy times and when I need a bit more I can sprinkle a little javascript. That's old school full stack and it's disruptive!
Wow, you had frameworks. I started with 4k of RAM and a 5Meg hard drive. We used 8 inch floppy drives and 110 baud modems. My first C compiler (BDS C) didn't even have I/O statements. We had to program those in assembly language doing in and out from ports a byte at a time. CP/M was our operating system. We used a language called Boomer++ .... 🤑
BBS! oh my goodness, bet you were a phone phreak as well. you know, none of those BBS people turned out to be normal, or even sane. they enjoy crashing expensive cars and then they drive around in the crashed expensive car. they're completely nocturnal. the ones i know, anyway
The main issue here imo is that you took a JSON end point to test a library that is supposed to work with endpoints that can feed html, which is basically like judging a fish by its ability to climb a tree. So your html looks bloated and you had to import 2 other dependencies since your html is not supposed to parse the JSON. Then you extrapolated to say that is was not good for big teams, and I don't really understand how you came to that conclusion based on your previous analysis. You said nothing negative about htmx and then suddenly it is good only for small projects ?
@@makerjr.1249 For an htmx project, you need control over the API you are communicating with. Else, you just made one of the stupidest technological choice that is possible to make. And yes, for a project fully in htmx, you server would ideally render html all the time. Calls to external API would be converted to html by the internal API.
@@makerjr.1249 > Unless you mean now we need to start creating our html server side pretty much all the time Well, people did exactly this back in the days when React was not a thing and it worked like a charm Html in the first place was designed for server -> client communication, not client side rendering in SP applications
@@bionic_batman as an old school web developer I wouldn't just say "it worked like a charm" - definitely there are performance/scale issues when we are generating megabytes of HTML tags on the server side. But honestly, begin able to work with both content formats is nice because you can weigh the pros and cons and choose which one better fits every use case.
@@bionic_batman yea that definitely shows the age and experience level of those commenting against htmx. Servers are called "servers" in part because they literally served HTML documents to web browsers.
For me web dev it’s just a fun hot mess. We add something simple html+css+js then someone decide to add complexity for no reason. Angular React or other are way to over kill for 99.9% of website. HTMX is just way to return to the root of web dev.
I think the idea that HTMX is good for simplicity is a key idea - more of the internet should be simple things. Less large clients where they aren't necessary, more hypermedia when it can do the job. Some tasks, like google maps, are actually an application and not a document. That kind of thing is where fully featured client frameworks and libraries actually belong.
HTMX can do more than what is in the Docs. Recomendation that covers React, Angular (still used just as much), Vue, etc... bloat would be HTMX + AlpineJs + Astro + JS. HTMX + AlpinJs will cover most needs. Tables, cards, modals, forms, etc... Astro + JS can cover the rest. Basically routing, odd auth cases, when an endpoint still sends JSON, etc... - You can even dump your old bloat project inside of Astro and slowly move it out with time
The more I learn about HTMX, the more interesting it becomes, it's really intuitive. It really seems like something new, instead of those bloated frameworks.
I have a very large app (PHP) and I could see myself using it *in conjunction with* Svelte web components (implemented via my library, svelte-retag). So, your Svelte components essentially _are_ “just HTML” (a separate abstraction) which can load/mount elegantly with HTMX. So, you still get your own backend (PHP, Go, Python, etc), some dynamic functionality where needed with HTMX and then a nice component-based design system with more intricate interactivity (where needed) with a front-end framework like Svelte. Not mutually exclusive! So, right tool for the job. Large vs. small scale doesn’t really categorize it properly. It just depends on what you want to do. It’s just a tiny little 10kb tool and depends on the job you need.
Wasn't this..THE recommended way to add function to DOM from like wayyyyyy back? I am more surprised it took this long for anyone to make a library for it.....
It’s astonishing how far you can get with htmx before needing a framework. It does have edges though. If you need something that is highly reactive and stateful, then a framework is more fit for purpose and maintainable imo.
@@RealDevastatia sure, but for a production quality hypermedia system?with actual customers and >1 team members? You would have an unmaintainable dumpster fire of bespoke state management and bloated third party script imports in no time.
The intro is kind of misleading, htmx is javascript, you don't need to write it yourself but it is and needs javascript. Don't expects htmx to work with js disabled.
Well, aCkShUaLly, you could use the hx-boost attribute and try to handle anchors and forms for browsers with js disabled. But yeah, most of the stuff won't work if the browser does not execute js.
My amount of facepalm is infinite when I hear, don't use javascript, use our javascript lib with its own language that will be dead in 2 years. Please kill me. This guy was clearly not there in "the good old days". I was. It sucked. But yeah, js influencers got to find "the next paradigm" in every single new lib that gets out.
@@RememberingGames HTMX is like a return to jQuery, you have to manage element identifiers and spread your behavior logic all around your markup. But it's less clear than jQuery because you can't read the procedural steps, you have to scour your markup to see the behaviors. I am so confused why HTMX is getting so much good press.
@@spaceynbsame. i would prefer jQuerys syntax any day over this. Besides it makes request to the server for every interaction. Imagine writing a search functionality with htmx after the data is already loaded to filter through users
In fact HTMX is a lightweight JavaScript library that extends HTML through attributes, allowing you to achieve dynamic behaviors without writing much JavaScript
HTMX is only a JS Library can be integrated with any new or existing website or web app. It will be later a React / Vue / Etc dependency or extension . No more or less
I wish people would just stop saying that no js is needed. HTMX is a js lib at the end of the day. It would be interesting if it becomes part of the html5 spec. 😅
what would be awesome, is if the functionality of htmx was included in the html standard. It would totally simplify the making of modern websites, only needing backend programming knowledge, html and css.
looks like you've never worked on a big project before. using css selectors for rendering data works only in small applications. plus unless you want to send a request to the server, you still have to write your own javascript. A simple example of this is having to filter a user, after the users have already been fetched.
@phoneywheeze9959 Fetch again but include the filter query this time with that request to the server! :-) It's geared to thin clients not fat and so is a different architecture.
Do you have your VSCode setup(extensions and themes) anywhere online? Theme looks really nice. Then that got me thinking what other cool stuff do you have installed.
Yea the benefit of HTMX is that the amount of dependencies can be cut, build times can be cut all because you're not using a heavy js framework to do everything. I found a JS library called Reef.js that basically only provides signals and stores. That + web components + HTMX gives me everything I need and I don't even use the shadowDOM. Easy reactive development that can be component based like react if you choose. Added a html function for parsing html literals like how it is in Lit.
Thanks for going through HTMX though I kinda feel like considering React modern is weird. It’s popular but that would mean jQuery would be modern just because 70+ percent of all websites use it. I would consider modern to be HTMX, Svelte, Astro (Angular 17+), etc
I am somehiw missing cross-file templating. If I have say a custom partial address form, I would like to re-use it in multiple places. Sure, I can use php or Java ir whatever generates HTML in the backend to do this, but us there a htmx-way of doing that? From your example: if I wanted to reuse the name + email line, could I make it a universally available template?
It sounds like you're asking if you can make us HTMX for components. That's not exactly what it's for, you can use JS web components to get that reusability if you'd prefer not to use a backend server in a different language
You _CANNOT_ use React or Angular without _WRITING_ JS. You _CAN_ use HTMX without _WRITING_ JS. But, with HTMX you still _CAN_ write JS if you need to but generally for last mile stuff, not state.
When they said "you can do a lot of stuff without javascript" they don't mean "you don't need a browser with javascript enabled", but instead they mean "you don't need to write a lot of javascript or any javascript".
I think this adds again a couple of complexity and it does add javascript under the hood ofc, but another framework?. So if I would have to take the bite and use something less then a framwork for the frontend I'd rather go with alpine.js. Even Vue would be still the first choice for me as it is simple and scales great for larger projects but as always depends on the project.
I do not see the benefit of this over a framework. Maybe small projects, but there is so much that goes into larger projects than this. The biggest complaint I have heard from people in this chat is that frontend frameworks get to messy as things get bigger. From my experience every single framework or library suffers from this if it is not architected correctly. HTMX will suffer the same if thought is not put into how the project is structured. There is a reason we moved away from SSR and pure html for websites and applications. I can see use cases for HTMX but not the way people want it to be.
We moved away of that because we needed more interactive ui so SPA’s were created but the complexity involved increased a ton, now with htmx you can achieve a complex ui but without increasing the complexity of the code base.
My favorite is AlpineJS - it's similar, but much more poverful and has convenient API. Imho, HTMX is good for beginners, it can't handle complex cases where we need component state.
@@sopa-gq5h I prefire to use Hotwired Turbo instead, because it's not so low-level as HTMX, because HTMX and AlpineJS has similar level of abstraction and it will confuse developer: what I should use for this case HTMX or Alpine?
The official HTMX book (or guide) actually used AlpineJS in an example. I think the combination of the two allows for a very powerful yet minimal framework for building modern apps.
htmx doesn't remove javascript, htmx is a javascript library itself. What htmx does is reverse today's principle of doing everything in javascript, and html is just constructed dinamically. And the other thing is switching your server to return html instead of json. You go back to the pure form of html with improvements
Yeah, all these "web developers" want to write web applications without learning the language of the browser. Not to mention separation of concerns. You should see the genius design that is Laravel Livewire, another of these "magic tools": to uncheck a checkbox, it makes a request to the server!
That's SPA thinking right there. Web servers are very capable of handling tremendous amounts of load when their back-ends are built with something sensible (compiled languages are great here) that doesn't gorge on RAM. It's also relatively trivial resource-wise to generate HTML UIs on the server side, and many backend technologies have elegant and well optimised templating systems (go templates, c# razor etc). Give it a try sometime - even going all the way old-school with full page refreshes can be way snappier than so many of the overly complex framework-bloated "modern" apps around now. HTMX strikes a great balance - allowing the server side to efficiently crunch UI updates, while not having to refresh the entire page.
I do love the concept and I think htmx solves some problems with state and ownership that are cool, but I feel like I get a cleaner front with a high dependency on the back. In some sense is great, but think is moves the concern into places they might not work well. I'm a fullstack wannabe so this might not affect me, but front people now depends on the back to make front work. I'm not sure how that will work. Headless backend now has to have knowledge about the front development? Apart from that, I think is quite magical and I like it, more so the part where the server keep state and client just operate the site and receive plain html as a result. I think I have to get more into hateoas as that might be a cool strategy to build interactivity.
I am a fullstack wannabe myself (although I prefer back end, I can do both to degree). But there is literally no need for "front" people with htmx, since 90-99% of the front's logic is passed to the back. On my little projet I have a bit of js on the front, to get the users timezone for example, as well as for creating sortable lists. You could probably do a whole application with just an index.html page that contains the htmx import and an hx-get to the first page of your app. So everyone can just work on the backend.
@@alanonym8972 But CSS crunchers are there for a reason. Back people concerns is logic, performance, security... and yep, back people can do visual design at some degree, but the hole point is to separate those things and let everybody do what they are good with.
@@SRG-Learn-Code You can perfectly have CSS crunchers (whatever this is) if you want to. Just send your html to the front end and have your CSS here, no problem. Nobody is born with innate CSS talent and terrible security skills. All of this is learned, and people should always be able to adapt, at least to some degree. All people that do front end have at least some programming skills to handle the mess that are front end frameworks, so none of them should struggle just because the html is now generated on the back end and not on the front end. At the end of the day, It is still html + css, you just replace JS/TS by whatever the back end language is. Of course sometimes the back end is a convoluted mess, but the places where the answer is sent to the user should be separated from the convoluted mess anyway. Good separation of concerns does not requires http requests
@@alanonym8972 I don't disagree, but figmabois (another invented name for front people, more incoming) are a delicate branch of developers. I've tried to help frontychans to install nvm, docker, wsl... to make their experience better when confronted with backend tasks or just to have dev enviroment coherent with the rest of the team. It's a nightmare. HTMX seems like a great tools for backdudes which is great because I lean that way, but I can see the struggle coming for both parties, as fronties will have to peak into the dark void of back dev and backchads will have to touch peasant front code. I believe in the end this would be for the better and many fullstackers will be born. To be honest, I think most of webs out there are overengineered because you have multiple teams, HTMX could solve this having just one versatile team.
🎯 Key Takeaways for quick navigation: 00:00 🌐 *HTMX is a front-end framework/library that enables building web applications with minimal or zero JavaScript.* 01:25 📚 *HTMX is lightweight (14 KB minified and gzipped), dependency-free, extendable, and supports Internet Explorer 11.* 03:47 🔄 *The speaker compares the evolution of front-end development from vanilla HTML to jQuery, Angular, React, and introduces HTMX as a simplified approach.* 05:10 🛠️ *To use HTMX, one can include the script tag directly in HTML, avoiding npm installation or bundling with tools like webpack.* 06:49 🕹️ *The video demonstrates building a simple HTMX application with a button that fetches data from an API, replacing content dynamically.* 10:14 🔄 *HTMX templates use mustache syntax to render data, allowing for dynamic content rendering similar to React's map function.* 11:49 🚀 *HTMX offers features like animations, progress bars, and UI components without writing JavaScript, making it suitable for lightweight applications.* 12:31 📚 *While HTMX is praised for simplicity and ease of learning, the speaker suggests it may be more suitable for smaller applications and quick integrations, not larger, complex projects.* Made with HARPA AI
I get the impression that htmx will limit client interactivity..for example, what if i want to auto hide header when scrolling down? This is a very common use case...
"HTMX is a new front-end framework ... it's not exactly a front-end framework it's more of like a library." You lost me here. Yes it's a library, and calling it a framework to appeal to devs who think they need a framework dictating their JS paradigms is doing it a disservice.
HTMX is good for only very simply and small prototyping for backend developers. You won't be able to create modern, interactive apps using HTMX like RUclips, Figma, Google Docs, spreadsheet ... pretty much any modern web app is way too complex for htmx.
You're not using HTMX the way it was intended. I challenge you to name a task you need accomplished that you can do with React or Angular that cannot be done in HTMX AND is not some esoteric and framework specific feature. Just state the desired goal and tell me why HTMX can't do it.
The main body of the video was fine. But down voted as the title is click bait - there's no one who doesn't want you to know htmx Irish striving to conceal anything about it. As well, the final opinion has no evidence to back it other than a small test in this video. Author is entitled to his opinion but it's just that.
when you say HTMLX is just for small projects, youre saying basicly that the fundamentals of any React framework are only for small projects? did you see? Htmx its about architecture, the way how render the HTML and send the requests, its the fundamental of any SPA framework. So stop to say stupid things as SPA fan boy that don't understand the DOM and the javascript low level.
Yeah I don't see what is so grea there. The HTML looks like shit with all those attributes. If you going to be making all those round trips, might as well just put ALL the logic on the server and ship a complete rendered page. This seems like it is mixing the frontend/backend domain more which will require MORE coordination from frontend/backend teams.
I think that's really how you're supposed to use it. You make a request to the server, it renders some HTML snippet which is shipped down to the browser and swapped into the DOM. This is just AJAX defrosted for a new audience.
@@robadobdob which is my point. Why bother with it as oppose to making a whole round trip with an entire page/payload? The server cost (resources) is negligible snippet vs whole page and you don't have to do weird state management to make sure your partials match up in a logical way aka state management.
The main problem of HTMX in my opinion: It doenst work on mobile devices. So, most of the awesome new applications, like phones, cars, smartwatches, TVs, or any intelligent device, are out of reach. If you wan to do a really big project, then you need at least an app. But for most projects I think it is still totally worth it.
You mean for offline support? There's nothing about htmx that inherently doesn't work on mobile. If it supports HTML and js, it supports HTMX. For offline, it's more complex but most websites aren't meant for offline use and you can still set it up as a pwa using caching (the same solution you'd have to use if you were using a framework)
Again just another new stuff to know about while it give nothing to improve the development real world application, l will suggest new developers stick to the bases then go on from their use what help you improve your work not what is called new frameworks or some nonsense that give you nothing to improve your work just complexity layer no profit in return
Pretty stupid video title. But way more annoying: The video does not show reactive conditional DOM changes, which is the only interesting thing nowadays: if input is valid show this, otherwise show that. So in a way the video fits the title.
Sorry but this is a terrible introduction to HTMX. The core philosophy behind the library is to move back to the true intentions of Hypermedia, where the content and context are encoded in a Hypermedia-enabled response, i.e. HTML. Fetching JSON and then rendering it in client-side templates is literally the opposite of what this library is intended for. A cursory read of the book you admitted to not bothering reading would have told you as much.
You generate HTML/X in your REST-API, so ideally you will have not even a file just call "/welcome" on your API an "navigate" the user from there. Of course you need a RESTful service.
lol so at the end he's saying if you have a big project you NEED to use SPA??? hahahaha i'm dying laughing at his ignorance Rename your channel to "CoderNoob", junior.
We have a load of dashboards for all our internal services. These are being successfully converted to pure htmx. We are seeing that we can move quicker. The JS devs are moving to backend which gives us so much more bandwidth to get important features added. It's awesome imo.
ROFL JS on the backend. What circus do you work for?
@@illegalsmirf he didn't said that they have js on the backend though, you can switch to other language easily if you are experienced developer.
@@illegalsmirf JS on the backend? No way that will ever happen! We use Java and Python. We're trying to use the same template language so we can share between the two. Not there yet, but we will.
Java and Python? The most arcane and the most accessible - what a combo 🙂@@KangoV
@@illegalsmirf What's wrong with NodeJS? Netflix and PayPal use it lol
I think this is where you are wrong. It's like doing a 'hello world' and then concluding that it's not scalable. I have been on various React projects and found them overengineered and hard to maintain. I recently switched to HTMX, and it's like night and day. Functionalities are shipped to production 60% faster and cheaper using HTMX compared to React. The code is easier to read and maintain, and new joiners to the project pick up the application code base much more quickly. I have dropped React and most single-page applications (SPAs) from my development stack unless they are required. So, right now, it's 90% HTMX and 10% React, after five years of React development.
How do I create click events with htmx?😊
@@ivan.jeremic hx- trigger="click"
Can you share why you still use react in 10% of your projects? In what cases does react is better?
My thoughts exactly!
@@IllarionYolgin 10% of our projects are dedicated to animation-related initiatives, specifically involving online video and graphic editing. To ensure swift updates to HTML nodes, we employ React for these components. Apart from that, the majority of our work relies on HTMX.
htmx isn't just about simple projects, and its main benefit isn't that you can get started with it faster. Its purpose is to change how/where state is managed because react is arguably a mess of a way to do things. htmx clients are stateless frontends, and are backend agnostic. It also doesn't use a virtual dom. It's good, clean engineering, which is a lot more than I can say for some libraries.
Well we've gone a full circle?
@@grimonce The next beautiful thing comming is a php-like templating language that supports all this (and more) without actually using HTML. Which will become a fully fledged server-side deveoper solution. Then you only need JS to sprinlkle over the top and... wait a minute.... someone has to invent jQuery now.
@@tonianzlovar7590 That's not the idea, htmx is about don't worry how you do the things in the server, youre free to use Lisp, PHP, Golang, Rust, Python, NodeJS. Do you understand? Htmx it's not PHP.
I wish people would stop saying HTMX is only good for small projects. It really shows how twisted web development has become in the last 10 years.
Hi can you give a bit glace on it
i heard that retoric in the past "oh don't use that because it's not for enterprise applications", "it's not going to scale", "etc"
me "that sounds like a skill issue"
There's never been an enterprise web application in production that didn't use react. The internet didn't start until 2013. Php doesn't exist. Ajax doesn't exist. Request/ Response cycle? What's that? Oh is that the thing that connects your json api to the frontend?
IMO It’s not convenient to work this way without separation of logics and UI, components is a better way (even in php) since you can connect everything from everywhere otherwise it’s not very modular, you wouldn’t want to create an html file for every template part, you don’t want it to be accessible from outside.
also the html file is already populated leading to problem with SEO so ax he said for working quick and dirty it might be good but it’s dirty, again, my opinion…
Im building a SaaS web app in HTMX and the experience has been amazing. HTMX + Tailwind + Python + Vercel + Firebase. Nothing else needed. Fk React.
HTMX is absolutely great. It makes HTML how it should have been developed during the last 15 years. And for someone who is developing websites since 1996 the functionality of HTMX is a godsent. The web was never so poorly performing and unreliable since the dawn of the fat JS-clients. This geek BS needs to end asap and HTMX is paving the way into a healthy again world wide web.
But HTMX is JavaScript, right?
@@illegalsmirfit is. But the essential difference with modern SPA frameworks and HTMX is the architecture how applications are developed with those technologies. With htmx, the frontend no longer is this huge monolith application with it's own state management and all that. Instead, it simply focuses on the presentation and the backend handles the business logic & application state and provides the frontend with html fragments to be displayed to the end user.
@@illegalsmirfinteracting with the dom is js biggest strenght but people making everything in it
@@diegoronkkomaki6858 Except when your application has massive state, and putting the management of that state on the backend leads to insane scalability problems because you want your backend to be as stateless as possible so you can reduce your http "chattiness", hence reducing your app complexity, and your server infrastructure costs.
From a programming maintenance perspective, by pushing state onto the server, you now have 2 layers with tight coupling with 1 living in the browser and the other living in your server. When you have a team of 5 people working on that they are gonna make mistakes, lots of them, and before you know it you will have a spaghetti mess of bits and bobs glued by 20 round trips to render a single user dialog.
Now you might be thinking that wont possible happen to you. You are very smart after all, you are better than all those thousands of programmers. But once its time to implement that feature, and that feature requires the user to update the screen with almost every click, you will inevitably need to put a bit of temporary state in the client side to avoid the thing to just stopping into a crawl under load with the user experiencing a 400ms lag in between clicks. And then you will see that your pretty little server side state can be no more, and you will make one concession, then another, and then another, and you will be fighting against the tide. Trust me, I've been there, I'm talking from experience, I was the guy that made that mistake.
Htmx has its place, but its not for application development where one page fundamentally depends on what happened in another page or in another section of your page. Htmx is best used for website development were the good old "each page is a completely new thing" is actually applicable.
This whole wave of Server Side Rendering and pushing the state back to the server is a huge step backwards. Personally I think its a mistake for most sites that need any heavy user interactivity.
@@diegoronkkomaki6858 so jQuery and PHP combo is great again?
Not all of us are react lovers... 💩
exactly, some of us vue.js lovers
@@games4us132web dev brain
I'm glad you tried HTMX but it's not intended to use JSON data or to be rendered client side. The HTML should be rendered server side.
That is semi true. There are valid use cases where you can render stuff on the client and htmx actually helps you with that.
Yeah I also didn't get the use of json and using mustache in the client
Htmx itself is a javascript library with helper functions for common use case.
obviously there's still JS involved. What else would it be? magic mystical fairy dust?
@@ryanleemartin7758 Right like no is saying JS is bad and should be obsolete. The nemesis is React and they know it! lol
I think you might arrive at a different conclusion if you didn't try to turn HTMX into a client side renderer like React.
"we all love working with react" ahahahahha good one
This take directly contradicts a lot of what the HTMX page he's viewing says. If you actually take the time to read over their "book," they do not at all say you shouldnt use JS (or client side scripting in general). Instead, they put limits on what you should use scripting for. I'd also challenge people to try using it before you assume it can't do what React does. Their example implements custom menus/toolbar, infinite scrolling, active search, form validation, etc, all with minimal scripting (but not none). They even point out when you should and shouldn't use it. But I think this whole SPA hype has caused people to miss out on how powerful hypermedia can be. Their book is not a long read and definitely worth it for at least getting a different perspective on things.
I think that frontend developers sometimes view themselves as a priest cast, and feel threatened by simple frameworks that ‘anyone’ can use. HyperCard also threatened full-time developers back in the day.
we do, and we were! not threatened any more. CMS won that round and it's looking like AI will take the next one. backend think *they're* priest cast, what with god mode and all that, but luckily they're priest cast so we're good there
Problem #1, you're requesting json with htmx... That defeats the purpose entirely.
@CodeOne can you elaborate on why you chose JSON instead of HTML for the transport?
Great point but there will still be third party apis that will return json and so it’s still a valid use case
@@flygonfiasco9751 right, but that's not the primary use case.
@@flygonfiasco9751 You can return JSON if you want, just change the header for that, but if you're using using HTMX mainly for return json, so you dont understand the concept of hypermedia, so this guys Doesn't have idea what he is doing.
@flygonfiasco9751 yes external api’s might use json
but
ideally your htmx app will access said external api’s from yr server !!
and pipe html to yr htmx client - not json..
oh dear did so well till the end, this scales incredibly well. I started in 92 after 5 years of BBS have been through all the frameworks and I mean all, settled on vue for the last 8 years or so with too many journeys into react and angular, toyed with svelte.
Now I am back with a java stack, zero build time (modern java compiles as you write) high performance, serverless, monolith, dist architecture, fast deploy times and when I need a bit more I can sprinkle a little javascript.
That's old school full stack and it's disruptive!
Wow, you had frameworks. I started with 4k of RAM and a 5Meg hard drive. We used 8 inch floppy drives and 110 baud modems. My first C compiler (BDS C) didn't even have I/O statements. We had to program those in assembly language doing in and out from ports a byte at a time. CP/M was our operating system. We used a language called Boomer++ .... 🤑
BBS! oh my goodness, bet you were a phone phreak as well. you know, none of those BBS people turned out to be normal, or even sane. they enjoy crashing expensive cars and then they drive around in the crashed expensive car. they're completely nocturnal. the ones i know, anyway
For an actual programmer, nothing is hard to do in vanilla JavaScript and DOM.
Bruh! Real talk! If I'm honest, my favorite flavor is chocolate, but when it comes to web dev, vanilla all the way! 😋🍦
only noobs speak like that dude.
Facts im come full circle. Server as the source of truth, with pure js on top of htmx
switched from VUE Nuxt what I realy loved to HTMX. It's simple a lot less work to work with HTMX. And building very complex projects with it
The main issue here imo is that you took a JSON end point to test a library that is supposed to work with endpoints that can feed html, which is basically like judging a fish by its ability to climb a tree. So your html looks bloated and you had to import 2 other dependencies since your html is not supposed to parse the JSON.
Then you extrapolated to say that is was not good for big teams, and I don't really understand how you came to that conclusion based on your previous analysis. You said nothing negative about htmx and then suddenly it is good only for small projects ?
External APIs responses are usually in json. Unless you mean now we need to start creating our html server side pretty much all the time
@@makerjr.1249 For an htmx project, you need control over the API you are communicating with. Else, you just made one of the stupidest technological choice that is possible to make.
And yes, for a project fully in htmx, you server would ideally render html all the time. Calls to external API would be converted to html by the internal API.
@@makerjr.1249
> Unless you mean now we need to start creating our html server side pretty much all the time
Well, people did exactly this back in the days when React was not a thing and it worked like a charm
Html in the first place was designed for server -> client communication, not client side rendering in SP applications
@@bionic_batman as an old school web developer I wouldn't just say "it worked like a charm" - definitely there are performance/scale issues when we are generating megabytes of HTML tags on the server side. But honestly, begin able to work with both content formats is nice because you can weigh the pros and cons and choose which one better fits every use case.
@@bionic_batman yea that definitely shows the age and experience level of those commenting against htmx. Servers are called "servers" in part because they literally served HTML documents to web browsers.
For me web dev it’s just a fun hot mess. We add something simple html+css+js then someone decide to add complexity for no reason. Angular React or other are way to over kill for 99.9% of website. HTMX is just way to return to the root of web dev.
web devs like to make their development complicated for whatever reason
I think the idea that HTMX is good for simplicity is a key idea - more of the internet should be simple things. Less large clients where they aren't necessary, more hypermedia when it can do the job.
Some tasks, like google maps, are actually an application and not a document. That kind of thing is where fully featured client frameworks and libraries actually belong.
HTMX can do more than what is in the Docs.
Recomendation that covers React, Angular (still used just as much), Vue, etc... bloat would be HTMX + AlpineJs + Astro + JS.
HTMX + AlpinJs will cover most needs. Tables, cards, modals, forms, etc...
Astro + JS can cover the rest. Basically routing, odd auth cases, when an endpoint still sends JSON, etc...
- You can even dump your old bloat project inside of Astro and slowly move it out with time
The more I learn about HTMX, the more interesting it becomes, it's really intuitive. It really seems like something new, instead of those bloated frameworks.
I have a very large app (PHP) and I could see myself using it *in conjunction with* Svelte web components (implemented via my library, svelte-retag). So, your Svelte components essentially _are_ “just HTML” (a separate abstraction) which can load/mount elegantly with HTMX. So, you still get your own backend (PHP, Go, Python, etc), some dynamic functionality where needed with HTMX and then a nice component-based design system with more intricate interactivity (where needed) with a front-end framework like Svelte. Not mutually exclusive!
So, right tool for the job. Large vs. small scale doesn’t really categorize it properly. It just depends on what you want to do. It’s just a tiny little 10kb tool and depends on the job you need.
Wasn't this..THE recommended way to add function to DOM from like wayyyyyy back? I am more surprised it took this long for anyone to make a library for it.....
well, htmx is the successor of another older library called Intercooler, from same author. I think it use jquery behind the scenes.
It’s astonishing how far you can get with htmx before needing a framework.
It does have edges though. If you need something that is highly reactive and stateful, then a framework is more fit for purpose and maintainable imo.
It's even more astonishing how far you can get with HTML, CSS, and JavaScript without ever needing a framework.
@@RealDevastatia sure, but for a production quality hypermedia system?with actual customers and >1 team members?
You would have an unmaintainable dumpster fire of bespoke state management and bloated third party script imports in no time.
@@JT-mr3db how does HTMX lose with teams > 1? That's an absurd statement.
@@jayhargis2352 I agree completely! however I didn't actually say that about HTMX if you bothered to read the comment I was responding to.
The intro is kind of misleading, htmx is javascript, you don't need to write it yourself but it is and needs javascript. Don't expects htmx to work with js disabled.
Well, aCkShUaLly, you could use the hx-boost attribute and try to handle anchors and forms for browsers with js disabled. But yeah, most of the stuff won't work if the browser does not execute js.
@@oriolmartinez4127 I'm going to snip that 'aCkShUaLly,'
My amount of facepalm is infinite when I hear, don't use javascript, use our javascript lib with its own language that will be dead in 2 years. Please kill me.
This guy was clearly not there in "the good old days". I was. It sucked.
But yeah, js influencers got to find "the next paradigm" in every single new lib that gets out.
@@RememberingGames HTMX is like a return to jQuery, you have to manage element identifiers and spread your behavior logic all around your markup. But it's less clear than jQuery because you can't read the procedural steps, you have to scour your markup to see the behaviors. I am so confused why HTMX is getting so much good press.
@@spaceynbsame. i would prefer jQuerys syntax any day over this. Besides it makes request to the server for every interaction. Imagine writing a search functionality with htmx after the data is already loaded to filter through users
Great video to get familiar with HTMX, much appreciated!
Since when was angular way of littering tag with spam attributes "good"? Also concerns vue and svelte
Try AlpineJS + Alpine components is just pass function to x-data="component()"
In fact HTMX is a lightweight JavaScript library that extends HTML through attributes, allowing you to achieve dynamic behaviors without writing much JavaScript
HTMX is only a JS Library can be integrated with any new or existing website or web app.
It will be later a React / Vue / Etc dependency or extension .
No more or less
You forgot Backbone.js between jQuery and Angular.js.
What was the part "they" don't want us to know? That's not in this video.
Thank you for allowing me to NOT* waste my time watching this video. 🙏🙏
hi, what are you using as a server / backend to handle the request?
Anything would work. node.js, Go, django, php. Whatever you're familiar with, as long it can return HTML from requests.
in the past, creating a fully dynamic ui (on a server) was very difficult, and HTMX was developed for that
Php is exactly for that purpose. It returns dynamic html page for ages. Htmx + php is even better.
I wish people would just stop saying that no js is needed. HTMX is a js lib at the end of the day. It would be interesting if it becomes part of the html5 spec. 😅
what would be awesome, is if the functionality of htmx was included in the html standard. It would totally simplify the making of modern websites, only needing backend programming knowledge, html and css.
That could be awesome. I'd love to see it. Perhaps HTMX will influence the next version of the spec.
@@ryanleemartin7758 HTML is the slowest spec to change 😑
looks like you've never worked on a big project before.
using css selectors for rendering data works only in small applications. plus unless you want to send a request to the server, you still have to write your own javascript. A simple example of this is having to filter a user, after the users have already been fetched.
@phoneywheeze9959 Fetch again but include the filter query this time with that request to the server! :-) It's geared to thin clients not fat and so is a different architecture.
Just perfect vanilla javascript and use whatever library or framework your company demands. Done.
for my sake the separation of HTML, JS, CSS is best because we can defined different logic in it's own isolation and combine together.
Do you have your VSCode setup(extensions and themes) anywhere online? Theme looks really nice. Then that got me thinking what other cool stuff do you have installed.
then what's the difference between JSX? I still prefer View and Business Process should be separated.
We are going back to SPA next year
This remembers me of Macromedia Coldfusion... Great tool, but without wide adoption, it will end up on the good ideas cemetery.
We are in the age of needless and continuous innnovation. None of this is neeeded, the old html & javascript way was just fine!
HTMX won't by itself eliminate JS. For client side only interactivity, you need something like Alpine, Mithril, Lit, etc.
Yea the benefit of HTMX is that the amount of dependencies can be cut, build times can be cut all because you're not using a heavy js framework to do everything. I found a JS library called Reef.js that basically only provides signals and stores. That + web components + HTMX gives me everything I need and I don't even use the shadowDOM. Easy reactive development that can be component based like react if you choose. Added a html function for parsing html literals like how it is in Lit.
a video on htmx vs alpineJS
(small correction: eliminate writing JS instead of JS)
it is not just html, it is using ajax so it is javascript in the backend
This looks to me to be easily a complimentary framework, not necessarily to remove all JS in the client.
htmx isn’t a new server-components
it’s a way to avoid managing state on the client
how do i do a [ ].reduce with this? how do i .map something?
Thanks for going through HTMX though I kinda feel like considering React modern is weird. It’s popular but that would mean jQuery would be modern just because 70+ percent of all websites use it. I would consider modern to be HTMX, Svelte, Astro (Angular 17+), etc
I am somehiw missing cross-file templating. If I have say a custom partial address form, I would like to re-use it in multiple places. Sure, I can use php or Java ir whatever generates HTML in the backend to do this, but us there a htmx-way of doing that?
From your example: if I wanted to reuse the name + email line, could I make it a universally available template?
you can in simple .js but in html, variables are passed between pages via the URL. i.e. ?v= in the address of this page
It sounds like you're asking if you can make us HTMX for components. That's not exactly what it's for, you can use JS web components to get that reusability if you'd prefer not to use a backend server in a different language
You start off by stating no JS required, Then you go on to say its just 14K zipped? What the hell! 14k zipped is a lot of javascript!
Not to mention that small size doesn't mean efficient. Look at Alpine JS.
You _CANNOT_ use React or Angular without _WRITING_ JS. You _CAN_ use HTMX without _WRITING_ JS. But, with HTMX you still _CAN_ write JS if you need to but generally for last mile stuff, not state.
When they said "you can do a lot of stuff without javascript" they don't mean "you don't need a browser with javascript enabled", but instead they mean "you don't need to write a lot of javascript or any javascript".
can it handle map and marker on it with leaflet
Those are the bits where you'd write some JS.
I think this adds again a couple of complexity and it does add javascript under the hood ofc, but another framework?. So if I would have to take the bite and use something less then a framwork for the frontend I'd rather go with alpine.js. Even Vue would be still the first choice for me as it is simple and scales great for larger projects but as always depends on the project.
I'm not sure how useful this will be. It just feels like there are more libraries to study....
I do not see the benefit of this over a framework. Maybe small projects, but there is so much that goes into larger projects than this. The biggest complaint I have heard from people in this chat is that frontend frameworks get to messy as things get bigger. From my experience every single framework or library suffers from this if it is not architected correctly. HTMX will suffer the same if thought is not put into how the project is structured. There is a reason we moved away from SSR and pure html for websites and applications. I can see use cases for HTMX but not the way people want it to be.
We moved away of that because we needed more interactive ui so SPA’s were created but the complexity involved increased a ton, now with htmx you can achieve a complex ui but without increasing the complexity of the code base.
My favorite is AlpineJS - it's similar, but much more poverful and has convenient API. Imho, HTMX is good for beginners, it can't handle complex cases where we need component state.
HTMX and AlpineJS work very well together though, even the creator of HTMX recommends Alpine
@@sopa-gq5h I prefire to use Hotwired Turbo instead, because it's not so low-level as HTMX, because HTMX and AlpineJS has similar level of abstraction and it will confuse developer: what I should use for this case HTMX or Alpine?
The official HTMX book (or guide) actually used AlpineJS in an example. I think the combination of the two allows for a very powerful yet minimal framework for building modern apps.
Frontend JS frameworks are a mess and overcomplicate things. This is a breadth of fresh air.
Spent hours trying to get vite to serve my tailwind, ended up just using the cdn instead 😂😂
htmx doesn't remove javascript, htmx is a javascript library itself. What htmx does is reverse today's principle of doing everything in javascript, and html is just constructed dinamically. And the other thing is switching your server to return html instead of json. You go back to the pure form of html with improvements
"No need for JavaScript", but you have to learn another non-popular/non-mainstream language: hyperscript.
Why is it considered better than JS/TS?
Yeah, all these "web developers" want to write web applications without learning the language of the browser. Not to mention separation of concerns. You should see the genius design that is Laravel Livewire, another of these "magic tools": to uncheck a checkbox, it makes a request to the server!
Correct 100%
Dude 1 HTMX isn't new at all, or not very new it's already a few years old...and 2 wtf with the silly clickbait title, what are you, buzzfeed 2013?
Htmx is not a good fit if u wanna have a desktop app experience on your web.. but that is like 5% of web pages... It does scale
Wouldn't this overload the backed for things the frontend would do much faster and effortless?
That's SPA thinking right there. Web servers are very capable of handling tremendous amounts of load when their back-ends are built with something sensible (compiled languages are great here) that doesn't gorge on RAM. It's also relatively trivial resource-wise to generate HTML UIs on the server side, and many backend technologies have elegant and well optimised templating systems (go templates, c# razor etc). Give it a try sometime - even going all the way old-school with full page refreshes can be way snappier than so many of the overly complex framework-bloated "modern" apps around now. HTMX strikes a great balance - allowing the server side to efficiently crunch UI updates, while not having to refresh the entire page.
Delete html, js and css. Implement one language that takes care everything. This will be far more efficient
So basically HTMX is similar to Turbo.js?. I don't see any difference
I do love the concept and I think htmx solves some problems with state and ownership that are cool, but I feel like I get a cleaner front with a high dependency on the back. In some sense is great, but think is moves the concern into places they might not work well. I'm a fullstack wannabe so this might not affect me, but front people now depends on the back to make front work.
I'm not sure how that will work. Headless backend now has to have knowledge about the front development?
Apart from that, I think is quite magical and I like it, more so the part where the server keep state and client just operate the site and receive plain html as a result. I think I have to get more into hateoas as that might be a cool strategy to build interactivity.
I am a fullstack wannabe myself (although I prefer back end, I can do both to degree).
But there is literally no need for "front" people with htmx, since 90-99% of the front's logic is passed to the back. On my little projet I have a bit of js on the front, to get the users timezone for example, as well as for creating sortable lists. You could probably do a whole application with just an index.html page that contains the htmx import and an hx-get to the first page of your app. So everyone can just work on the backend.
@@alanonym8972 But CSS crunchers are there for a reason. Back people concerns is logic, performance, security... and yep, back people can do visual design at some degree, but the hole point is to separate those things and let everybody do what they are good with.
@@SRG-Learn-Code
You can perfectly have CSS crunchers (whatever this is) if you want to. Just send your html to the front end and have your CSS here, no problem.
Nobody is born with innate CSS talent and terrible security skills. All of this is learned, and people should always be able to adapt, at least to some degree. All people that do front end have at least some programming skills to handle the mess that are front end frameworks, so none of them should struggle just because the html is now generated on the back end and not on the front end.
At the end of the day, It is still html + css, you just replace JS/TS by whatever the back end language is.
Of course sometimes the back end is a convoluted mess, but the places where the answer is sent to the user should be separated from the convoluted mess anyway. Good separation of concerns does not requires http requests
@@alanonym8972 I don't disagree, but figmabois (another invented name for front people, more incoming) are a delicate branch of developers. I've tried to help frontychans to install nvm, docker, wsl... to make their experience better when confronted with backend tasks or just to have dev enviroment coherent with the rest of the team. It's a nightmare.
HTMX seems like a great tools for backdudes which is great because I lean that way, but I can see the struggle coming for both parties, as fronties will have to peak into the dark void of back dev and backchads will have to touch peasant front code.
I believe in the end this would be for the better and many fullstackers will be born.
To be honest, I think most of webs out there are overengineered because you have multiple teams, HTMX could solve this having just one versatile team.
@@alanonym8972 Why dont you adapt to svelte then instead of separating visual ui parts into two completely different resources?
🎯 Key Takeaways for quick navigation:
00:00 🌐 *HTMX is a front-end framework/library that enables building web applications with minimal or zero JavaScript.*
01:25 📚 *HTMX is lightweight (14 KB minified and gzipped), dependency-free, extendable, and supports Internet Explorer 11.*
03:47 🔄 *The speaker compares the evolution of front-end development from vanilla HTML to jQuery, Angular, React, and introduces HTMX as a simplified approach.*
05:10 🛠️ *To use HTMX, one can include the script tag directly in HTML, avoiding npm installation or bundling with tools like webpack.*
06:49 🕹️ *The video demonstrates building a simple HTMX application with a button that fetches data from an API, replacing content dynamically.*
10:14 🔄 *HTMX templates use mustache syntax to render data, allowing for dynamic content rendering similar to React's map function.*
11:49 🚀 *HTMX offers features like animations, progress bars, and UI components without writing JavaScript, making it suitable for lightweight applications.*
12:31 📚 *While HTMX is praised for simplicity and ease of learning, the speaker suggests it may be more suitable for smaller applications and quick integrations, not larger, complex projects.*
Made with HARPA AI
Htmx is from 2013, hardly new. SPAs never should have existed.
Why do you repeatedly say HTMX can do xyz without using JS.. when HTMX is a javascript library!
Because i don't write JS myself
I still don't understand why htmx is good
Because you are a good JS guy
None of the large frameworks have been good for web dev. None.
WTF is htmO ?
"small book" well, it looks like you didn't see pictures of it 😂
It sounds like a bad idea to me.
HTMX is everything but new....
Embedding logic into the presentation layer is just about the dumbest thing I can think of
Oh man this guy going 100 miles a hour a big run on sentence 😂
I listened half-way through the video and LITERALLY NOTHING related to your title.
Not a framework and it's not really new either
React is not the best tool its just popular and hyped.
I get the impression that htmx will limit client interactivity..for example, what if i want to auto hide header when scrolling down? This is a very common use case...
Use CSS for that? See animation property for that.
HTMX as gender neutral HTML? 😂
Based 😂
Figjam bro? FIGJAM?? Nooooooooooo
So what they don't want us to know ? Clicked the bait and ?
"HTMX is a new front-end framework ... it's not exactly a front-end framework it's more of like a library." You lost me here. Yes it's a library, and calling it a framework to appeal to devs who think they need a framework dictating their JS paradigms is doing it a disservice.
HTMX is good for only very simply and small prototyping for backend developers. You won't be able to create modern, interactive apps using HTMX like RUclips, Figma, Google Docs, spreadsheet ... pretty much any modern web app is way too complex for htmx.
You're not using HTMX the way it was intended. I challenge you to name a task you need accomplished that you can do with React or Angular that cannot be done in HTMX AND is not some esoteric and framework specific feature. Just state the desired goal and tell me why HTMX can't do it.
The main body of the video was fine. But down voted as the title is click bait - there's no one who doesn't want you to know htmx Irish striving to conceal anything about it. As well, the final opinion has no evidence to back it other than a small test in this video. Author is entitled to his opinion but it's just that.
when you say HTMLX is just for small projects, youre saying basicly that the fundamentals of any React framework are only for small projects? did you see? Htmx its about architecture, the way how render the HTML and send the requests, its the fundamental of any SPA framework. So stop to say stupid things as SPA fan boy that don't understand the DOM and the javascript low level.
U can't get ride of js lol
when you read it's doc and how to use youiy will notice you can red of 90% of js needed for frontend
Yeah I don't see what is so grea there. The HTML looks like shit with all those attributes. If you going to be making all those round trips, might as well just put ALL the logic on the server and ship a complete rendered page. This seems like it is mixing the frontend/backend domain more which will require MORE coordination from frontend/backend teams.
I think that's really how you're supposed to use it. You make a request to the server, it renders some HTML snippet which is shipped down to the browser and swapped into the DOM. This is just AJAX defrosted for a new audience.
@@robadobdob which is my point. Why bother with it as oppose to making a whole round trip with an entire page/payload? The server cost (resources) is negligible snippet vs whole page and you don't have to do weird state management to make sure your partials match up in a logical way aka state management.
Meh😕
skill issue
The main problem of HTMX in my opinion: It doenst work on mobile devices. So, most of the awesome new applications, like phones, cars, smartwatches, TVs, or any intelligent device, are out of reach. If you wan to do a really big project, then you need at least an app. But for most projects I think it is still totally worth it.
You mean for offline support? There's nothing about htmx that inherently doesn't work on mobile. If it supports HTML and js, it supports HTMX. For offline, it's more complex but most websites aren't meant for offline use and you can still set it up as a pwa using caching (the same solution you'd have to use if you were using a framework)
Again just another new stuff to know about while it give nothing to improve the development real world application, l will suggest new developers stick to the bases then go on from their use what help you improve your work not what is called new frameworks or some nonsense that give you nothing to improve your work just complexity layer no profit in return
Pretty stupid video title. But way more annoying: The video does not show reactive conditional DOM changes, which is the only interesting thing nowadays: if input is valid show this, otherwise show that. So in a way the video fits the title.
Sorry but this is a terrible introduction to HTMX. The core philosophy behind the library is to move back to the true intentions of Hypermedia, where the content and context are encoded in a Hypermedia-enabled response, i.e. HTML. Fetching JSON and then rendering it in client-side templates is literally the opposite of what this library is intended for. A cursory read of the book you admitted to not bothering reading would have told you as much.
My only concern with HTMX is the length of files, dude I can’t think doing it with huge products
You generate HTML/X in your REST-API, so ideally you will have not even a file just call "/welcome" on your API an "navigate" the user from there. Of course you need a RESTful service.
I hate the title of this video. why would anyone not want you to know any of its content?
lol so at the end he's saying if you have a big project you NEED to use SPA???
hahahaha
i'm dying laughing at his ignorance
Rename your channel to "CoderNoob", junior.