We have multiple internal web apps for our internal services. All are being converted to HTMX. We're moving quicker, with better support as devs know all of the code. This is where HTMX is going to excel. React will still be used for the very complex web apps. We've estimated that HTMX gets us 90% there. That last 10% is what you would need for a public facing all singing, all dancing UX experience (and I'm talking polished). But mix in HyperScript and maybe you don't need React at all.
Pretty please stay away of Hyperscript (it is a beautiful toy!!!) and use vanilla JS. Learn some tricks from gnat/surreal for locality of behavior, but stick to code any one can understand without learning another library.
Strong doubt the "devs know all of the code" with a magical hybrid render engine, since it's basically NextJS but tricks you into thinking hybrid render is not a complete clusterfruck.
Yeah my immediate thought was that those 10% can probably be built with very little vanilla JS: write a custom 100 to 300 lines library that does precisely what you need to do and call it a day. Or use a very lightweight existing library that fits your needs. I also don't really follow Theo on the whole "alternative to React for back-end devs". I started with front-end, I like front-end development. I like great UX, sleek UIs, not bothering the server with things that have no business in the server... HTMX allows me to spend more time thinking about this, as I'm not dedicating most of my time writing code just to render stuff, handle navigation, log users in and out... I can dedicate a lot more time to those 10 remaining %. If we factor in modern CSS, I end up needing very little Javascript, but it's some pretty meaningful and important Javascript, which feels great.
Im finishing my bachelors in november and I have months of experience with HTMX none the less python fastapi, node express graphql, and some php. I can show my projects w htmx. Open to discuss a job opportunity as a junior mid? Im in France but can work any timezone.
I wouldn't say I'm betting on htmx, but I do hope it takes off. But I'm just one old-school dev who started Web in 1995 and has never really embraced JS. In my mind it's more of a necessary annoyance than something I want to deal with, and discovering htmx as a way of moving back to a more HATEOAS world has me excited
@@KangoV Hi mate - I am considering doing a POC of this at work to get them interested in alternatives to all-in React - any insights, thoughts or knowledge you can share please for production internal apps? (dashboards and some data input mainly)
It would be great if the HTML-standard itself would finally add PUT/PATCH/DELETE support for forms! This has been in the "if someone took it up"-stage for decades. And if htmx would become just a polyfill for what a modern browser can already do.
@@emiliod90 Take the time to understand the HTMX way of doing things, a lot of times you may be tempted to resort to javascript to solve some less clear cut case, and you can totally do that with the HTMX js API and events, but a lot of the time there's ways to avoid js altogether.
tbh theo's takes on client side stuff are solid (js), but he's unwilling to consider when writing your own backend is a worthwhile effort, because he's sponsored by people who make their money when dev's dont write their own backends
Working on internal tools makes you appreciate htmx a lot. I literally write a cli app with go first, make an http server and paths reusing the same functions, add a little bit of html and css and i have a fully functional internal tool
The good thing is that HTMX is just another JS library like knockout or lodash. Use it where you can get its benefit but continue to use Angular, React, Vue, Solid, etc. where you need to use something more sophisticated! Most of the enterprise apps I have built in the last 10 years have a pretty rich set of app configuration screens. Most of those are perfect for the simplicity of HTMX. Reducing the implementation cost and reducing maintainability cost of those screens will help sell them to the PM. Your users will thank you. Your users will also thank you for the decision to use a richer framework for the heart of the app. It is not one size fits all. Use the tool that best fits the functional and non-functional requirements being implemented. HTMX is just one more tool in the dev's tool belt to please the customer and the PM. BTW, I use SolidJS as my goto UI framework as well - still with just CSR for my simple apps in retirement. I love it. And HTMX supplements it well.
i had the misfortune of not just shipping relay, but forking it and maintaining a fork to integrate graphql subscriptions back in “relay classic” days before subscriptions were implemented anywhere. we built our graphql server on the reference graphql 0.2.0 package and it was ROUGH
Not really, a difference between the 2. Everything that is simple in programming, in reality it's a third party that's do all the complex things and expose to another simple primitives to work with
It's interesting to note that the JS signals proposal was a "subtle" namespace for the parts which aren't that straightforward. It does note that these aren't intended for everyday use, but complexity has to go somewhere and you hope that the right abstractions are in place to conquer it.
I think the problem is conflating being explicit with being simple. And conflating simple parts with a simple engine. Sometimes, it is better to build something that is complex under the hood but won't grow much more complex or hard to use. If simple explicit parts were always superior to complex, abstracted parts, we'd use nested if statements for everything. The other issue I have with this is that more often than not, what we call simple is not that simple in the grand scheme of things. It might be the most simple way to do what React does and create SPAs, but HTMX just allows you to create SPAs without doing what React does. You can't do much simpler than NOT HAVING TO DO THE THING.
As someone who doesn't need the interactivity of full react, I just need to send a colleague a basic Django web app with a bit of interactivity. htmx has saved me probably hundreds of hours. (Both in terms of how much JS I need to learn (because it's not none, some JS is needed for complex use cases) and not needing to learn a bunch of JS frameworks) I think the future however is something like the BETH stack, where htmx becomes another piece of a larger tech stack, and not a wholely separate thing all the time like in can be.
@@xali2008 Have the browser recognize hx style attributes natively without having to go through a javascript layer, just seems like a logical step forward in both performance and ease of use. Suddenly 80% of what modern frameworks are trying to do is there by default without some crazy new API you have to learn. It just fits in so naturally.
Rich Hickey articulated very well the gut feelings that many senior devs have. The difficulties that complexity brings in to the project. That there is incidental complexity you should avoid and inherent complexity you have to deal with. Easy solutions are bright and shiny. You can go fast at the beginning. But they tend to have a lot of incidental complexity that pulls you down in the long run.
@@fnumatic5558 Exactly, the concepts of “inherent” and “incidental” complexity are things we should have vocabulary for and be thinking about. It’s kind of funny to me how loose we can get with language in software-land when we literally wrote specs about what the word “should” means.
@@fnumatic5558 Totally, I had been in the industry for almost 20 years when I saw it, and it finally clicked. For example, I was finally able to articulate why I disliked ORMs. Sure you get started easily enough, but they just brought a lot of accidental complexity. I think EF (when I used it last), because you mutate objects directly, keeps a complete copy of all loaded state to compare against the "domain objects" to determine what to write. And when it doesn't do what you need (it didn't handle orphan removals in aggregates), the s*** hits the fan.
@@Kane0123 I think the term is originated from KISS (Keep It Simple Stupid) philosophy, that it's about don't do weird mojos to the final users can't see the complexity, but keep simple for the maintainers and other devs.
This video was great. As someone fully focused on react and next, knowing I can rely on you to get a view on the outside status of other frameworks is refreshing.
Its so weird to see some people say that React is so easy to use in a project which is huge in scales, yet whenever I encounter a React application which has been in development for a really long time its always a mess and is just awful to change things inside it, or debug it.
Of course htmx is taking off in popularity. The problem with react and others is that it's built on a false premise: that JavaScript is good. Js is the problem child that everyone is pretending it's fine, building ever more complex frameworks to hide the problems and adding new ones on there. Web apps are 2 parts: display and comms, stuff when you start to hide the comms bit because you want it to look like it's all js client side code, you will end up with convoluted and often badly performing apps. Htmx is honest about being the comms party only, handing off display to the browser via dom manipulation and that means it does it really well, really simply to understand, and fits in with the model of browser based HTML.
This. Things like NextJS and SvelteKit putting JS into the backend just seems crazy to me. I'm very biased, but dynamically typed languages shouldn't be in the backend (and Typescript doesn't add the safety some might think it does). JS also isn't performant in the backend - even compared to Java, so why extend it there? Front-end frameworks were created to maximise the potential of JS in the browser. Moving them further and further to the backend just seems counter-intuitive to me.
Exactly. JS is fundamentally a shitty DSL born out of a need for annoying pop-up ads on Netscape Navigator. And React was developed by a massive social media conglomerate whose fundamental goal was to justify employing an army of front-end devs; so *of course* they came up with the most convoluted solution humanly possible. JS is an objectively bad language (which is why TypeScript got traction, because it's putting lipstick on that pig), and most people/companies don't have the resources of Facebook to deal with React's absurd complexity.
By the way: HTMX likely pairs _quite nicely_ with web components (custom elements), particularly if you’re using the shadow DOM (since I’ve seen some weirdness with it tampering with the light DOM inside of the elements). Anyway, that said: There are ways to roll your favorite frameworks as custom elements too (shameless plug: mine is svelte-retag). So in a way you can get the best of both worlds. Plus, there are solutions coming out like Enhance WASM coming out with the goal to make it super easy to SSR web components in PHP, Java, Ruby, Go, etc… thanks to web assembly. Pretty interesting stuff going on right now.
Web Components are driven entirely by javascript (the worst kind, aka OOP) and the whole point of HTMX is not to write javascript. What gives? This combo has as much sense as two-way XML/HTML transformer. Sure you can write it, but for what purpose?
@@darylbarnes9413htmx works fine with webcomponents. 1. Define a custom element (eg 2. add the relevant script tag to the html 3. htmx calls return html fragments that use the custom element
I'm FULLY in the Go net/http or Gin + HTMX camp (possibly a fanboy), but the new React and current Solid DO seem cool for frontend devs who want to do things that require a backend!
The cool thing about htmx is that if you want to add some cool interactivity you can just pop a bit of react in there no problem, your whole app doesn't need to be in react, only what needs something like react. :)
Think most underestimate AlpineJS. That library, compared to React is a so much nicer to use when it come to creating interactivity on the client-site. It's true that the HTMX site points out the limitations that where mentioned in this video. But it also says that you can use a scripting language on the client-side. The site advocated for vanilla JS AlpineJS and Hyperscript. HTMX is not anti-JS like people keep saying. It wants to put the emphasis less on the scripting langue. So instead of using some JS framework to build the whole thing use a little bit of scripting here and there to better the user experience.
Exactly. For parts that need more interactivity than htmx can provide out of the box, we can use alpine, hyperscript, stymulus, or even vanilla JS. Also, if the page or component is too complex, nothing prevents of using React for that part. HTMX can send and listen to events and therefore communicate with these libraries pretty easily.
People mention Alpine all the time. I used Alpine and it's all fun and games, until you really need to control complex cases of nested components and the order they render. Even worse when you mix them with template engines(because you write everything in a fkin string) or htmx(because they offer solutions to the same problems and now you have to decide which you pick, and then sometimes only one of them can solve your problem and you will have to code a bridge between your htmx and alpine stuff). People should be more honest. NextJS, Vue, Solid and Svelte (maybe angular too) are the only way to build a cohesive AND complete solution to ANYTHING that requires harmony between client AND server. If you want to make it all serversided or all clientsided then we can have a discussion, but honestly, that feels like a huge downgrade.
@@upsxace I agree that this "mix" between htmx and alpine is not resolved yet. Like you said, for more complex cases you'll have challenges. Not the end of the world, but you'll need to build some code to fill this gap. It might not scale well depending on the project. I just disagree with the affirmation "the only way" and that htmx approach is fundamentally a downgrade. For a few complex components you can add react/vue/etc only to handle them. And if your project has many complex cases, you might drop htmx/alpine and go all-in with react/vue. But having additional alternatives is not a bad thing. People can choose what they like and learn from it. Big players will feel they need to improve to continue relevant. Specially if these alternatives are very different in their approach.
@@user-mahaka2002 it's just so much easier to code everything in react/svelte/anything after you learn it, so to me it still feels like a huge downgrade
@@upsxace perhaps it's also related to the background of each dev. For people more focused in the backend, htmx looks like a holy grail 😂, that they can use to build nice stuff without going too deep into the js world. Skill issue? Sometimes yeah. But not always. Perhaps some of them just don't like the idea of the full SPA approach for everything. While people who is highly specialized in JS often don't see advantage of investing time to try htmx. Also, I worked on projects with specialized large teams (back and front), where product departments were constantly requiring complex highly interactive stuff. Honestly, I don't see how htmx could be adopted in such environments. Probably that's not even the goal of the library. But I also worked on mid size products (e.g.: ecommerce) where HTMX could shine and the separation of back and front was not really helping that much. There is also a considerable number of startups or solo entrepreneurs that could build/evolve their stuff successfully for a long time with HTMX/Turbo/Unpoly/Alpine before the need to reestructure it as an SPA. In summary, I just think there's space for everyone, also love React and Vue 😊
I think a lot of people are just butthurt because HTMX is showing them that React is a mountain of overkill for most projects, and they've all been wasting their time for no reason because they bought into the idiocracy of "Facebook uses react...yeah, it's got components".
18:20 I appreciate you calling out this gap in htmx, as an interested user of htmx, because that gap is precisely what I’ve been thinking web components are good for. Back end devs will have to do a little front end work to use that, but with frameworks like Svelte 5 being fairly approachable, I think it’s not so bad.
Great video! The article also slaps. Yeah, if you're building an app that requires greater interactivity on the front end, even Carson Gross himself acknowledges you'll need to use an additional library (or write you're own TS/JS) to achieve that. Web components? Alpine.js? Perhaps even Carson's own (completely batshoot crazy) _hyperscript? Something.
HTMX is the best idea that we've ever had. An idea so brilliantly simple that any actual implementation, any actual specific API, become far less important than the idea itself.
Any thoughts on utilising Hyperscript with HTMX to bridge that last gap you showed for HTMX? I've shipped Intercooler, HTMX and React to prod - funnily enough, some people seem to struggle more with understanding HTMX vs Next (and by extension, React + supporting libraries) which is simply nuts to me.
Switched to Django + Htmx + Hyperscript... 2 years ago.... Never go back to anything else. I can't create Google sheet for sure... But I can create any other SPA out here.
Loved the principles that were highlighted, if you want to get a good handle on the difference between ease and simplicity I found Rich Hickey "simple made easy" very informative.
the horse I'm betting on is HTMX, and is because it's got laser eyes! In all seriousness, the simplicity is nice. Even though it comes with a cost, even the trade off is quite clear from the get go
solid.js or Lit can be used to create custom-elements(native browser-based web component) which can be used to create widgets(which render on browser side). Then that those widget + HTMx can be used along old-age server-side templates like FTL(Java) or Jinja(Python) or TPL(Php) for server side partial rendering. And the state can be managed totally on server side with Some Redux Like or Some State Machine library. So that way Widgets are loaded & render on client-side + Layout logic and Routing or State Management remains on the server side.
The Svelte/React example on simplicity vs. ease-of-use I think directly correlates to what I feel is better about Next vs HTMX. HTMX is definitely simpler, but is not as easy to use, especially when you want to implement that [one thing] (insert any number of "one things") that it doesn't handle well. Next is very easy to use, and things like Vercel make it easier. Most of the things Next/Vercel can't do are things even a Go/HTMX app shouldn't do---and should instead punt to a queue or kubernetes cluster. Except maybe websockets, but if that's a requirement you can simply throw a Dockerfile on your Next app and toss it into GCP or AWS instead of Vercel. I want something _like_ HTMX to be the future of web dev, but I think it currently falls short of the realities of the needs of most modern web applications.
I wonder, why i see discussions about react, solid, svelte, htmx and not about vue, it's fast, and would become faster and smaller soon, because vue core team is working under removing virtual doom, has huge and wonderful ecosystem and can be used for almost every kind of software, why vue isn't solution in this war, you may just combine htmx for server-side rendering and vue for client-side moments, or take nuxt/astro/vitepress, why react with its endless compromises or solid with its small ecosystem and community, according to the benchmarks vue is not critically slower than solid. Maybe I just not fully understand why?
“react is simpler than svelte”. Every time you write react, you need tons of wrappers for basic things, such as fetch, or using native web apis, because of how virtual dom works. It ends up in a bloated projects with millions of dependencies, that conflict with each other, and you don’t control your codebase. At the same time, you could adopt any JS library or web api feature with svelte, in a clean composable way.
The simplest framework is the one you know already. I use React for years now and even though Svelte is less verbose in some things and does have some things built in that React doesn't (transition primitives and built in more complete state management for example), I cannot be productive with it as much as I can with React because I already have so much more knowledge and experience with React. simple/complex and DX are extremely subjective. And the thing you mentioned about wrappers is not true as a general statement. It all depends. Why would you need a wrapper for fetch to use it inside a React project? That's just a statement that's not correct. You can just use fetch inside a React project without wrapping it into something special. I do agree that fetch does require a wrapper, but that's because fetch is a horrible API to use barebones so wrapping it up into something nicer is mandatory regardless of the tech stack. I do agree that some other vanilla JS things are harder to use because you have to make them work with React and its way of doing things.
@rand0mtv660 not in the case of Svelte vs React, years of experience of React and it took me a week in Svelte forming the opinion that Svelte is much simpler
@@oidualx I'd still say it's quite subjective. And I'd say a week for such a big change isn't enough to form a proper opinion. Build a real application in both, then do comparisons. Some things don't pop up until you actually build something realistic. I still think Svelte is extremely cool though, but as everything else in programming it's not a silver bullet that will solve all your problems.
@@rand0mtv660 I've transitioned our internal dashboard from react/next to svelte and its like night and day. It might just be my desired way of writing code matching their patterns, but it's an incredibly simple meta framework
Where HTMX starts to really shine is when your backend app that drives it all isn't written in JS. Suddenly a whole pile of translation layers to and from JSON are no longer needed, and this greatly simplifies the whole architecture. Where it really blows React out of the water is when your application needs to manage state that is shared between multiple users. No amount of frontend framework magic will let you do that without dealing with a gigantic mess.
@@konstantinpaul8301 yep ikr - and it handles reconnects and ping heartbeats automatically too There is also an excellent SSE extension that makes realtime updates dead simple without even needing web sockets - wrote some simple multiplayer turn based games to try that out, and its super easy Zig frameworks on the backend support both web sockets + SSE, so doing a whole app in something other than JS is a true joy
Is Solid really that much about "simplicity over ease-of-use"? From personal experience - it's easy to use indeed, quite minimalistic code, very good set of out-of-the-box tools, "look, it just works"... but then it appears that for that to work, you are required to follow a vast set of very special rules. You are not allowed to do even most trivial of trivial things: - Don't do props destructuring - because it will obviously break reactive values - To define a default value for a prop - use a special helper - To split the "rest" props - use a special helper - Don't pass event handlers directly to nodes - wrap _everything_ in an extra function call - Don't use async even handlers - because... I don't even know why, but Solid's special eslint rule complains about that. So you have to wrap it into extra func, and define an async IIFE inside it. And so on. Altogether, this really turns codebase into some kind of "magic" (not "magical"). You have to consantly write some pretty arcane code, which in terms of plain JS doesn't make any sense. Write code not for yourself, but for the framework. Am I getting smth wrong about it? Because for me that didn't feel like "simplicity".
i'd argue those fall under 'ease-of-use' - the underlying primitives of signals/effects/suspense/data apis are still simpler, but the authoring experience has some rules you have to go by (and so does react, not that you brought it up) also i've never experienced that async event handler problem, i've got plenty of them that work fine and haven't been able to reproduce it in the playground
This is the same way Vue 3 works, using the defineProps and toRefs helper for props. It's just a thing with these fine grained reactive systems. I do agree it is not perfect, but It was much more explicit then when I had to use Svelte. Still I prefer using mergeProps rather than rerendering the whole component every time, like React does.
@@brendonovich Do you use Solid plugin for eslint? Because, in practice async handlers seem to work just fine, indeed - but eslint doesn't like them for some reason. "This tracked scope should not be async. Solid's reactivity only tracks synchronously" is what I'm getting. And it's not like one rule specially for async handlers - it's a part of huge "solid/reactivity" rule, whuch includes everything at once. So it's not even an option to disable it.
@@brendonovich React does bring its own rules too, for sure. It's just they seem much more reasonable to me. Basically, React just wants you to: 1) not call conditionally things explicitly starting with "use" 2) don't do side-effects directly in component's body. That's it. The rest is just a normal JS. Unlike in Solid, where I'm not allowed to use a native language syntax.
Theo, I'd love you to do a deep dive video over RSC and the weird JSON protocol it uses to "render" components.... I thought RSC were always just doing SSR into HTML on the server, but I recently learned this isn't the case.
I LOVE the idea of "simplicity vs ease of use", only got to 7:10, so maybe this will be covered, but the thing that frustrates me a bit about the "New React architecture"/RSC+Server Actions is that it's 100% ease of use, sacrificing a lot of simplicity... which isn't a bad thing, just a trade off that has advantages and disadvantages~
@@diadetediotedio6918 Because the goal of React isn't "to be easy for newcomers", if anything React used to be squarely on the "simplicity"-side. We went from React being a framework I felt I could write myself (and thus understand pretty well) to React being this magical land. Generally I am equal parts excited about these new developments, and concerned that they are a bit losing focus on the big picture (next.js' difficulties adopting the page transition API is a beatiful example of that, as making the server/client boundary 'magical' and in certain ways 'messy' means that ensuring network requests happen before the transition starts is difficult).
This reminds of jQuery when it came out and it still does it's job on the most Websites. Why do you really need to reinvent the Wheel? I mean, I am lucky enough with vue, no need to touch Svlete, React or Solid. Know one thing, but know all it's details until the core bone. For the main Goal from all of them - to build a SPA / MPA - they do it all, but you don't need to use all of them. Customer doesn't care how you build it as long it does work and they won't pay you more because you took the time expensive route.
Hey Theo, Perhaps as a huge RSC enthusiast you would be interested in responding to the fair criticism in the article "How Next.js Breaks React Fundamentals" on Ondrej Felisek's blog?
7 месяцев назад+1
I am surprised planetscale is still mentioned since it's no longer offering a free tier.
8:00 it will still be a compile step, but not for the same reason as Svelte 4. Runes look like functions, but they do not have any implementations and need to be used in .svelte or .svelte.js/ts files. At the end they are Signal primitive like you pointed, but that compiler step allow devs to use the variable instead of the .value proxy. No need for "variable.value", simply use "variable" and the compiler will change it accordingly
Yes, it's because they want to solve many different things for many different people. It's the trade-off of a more general approach. But the nice thing about linux is that there are many options to choose from, so you can use arch btw! if you want to
@@seyyedkhandon Bro what is your point then? You can complain about software all you want but at the end of the day the solution is simple: just don't use it
Can something like HTMX + (parts of solidjs) framework be used to fill in that remaining gap that HTMX cannot solve? I feels like try to solve with HTMX, but if you need more reactivity, just go to SolidJS.
Custom vanilla JS or alpine.js. What kind of reactivity are we talking about ? I feel like people underestimate the kind of thing you can do with modern CSS and HTML (, , popover, has()...) some event listeners and a couple observables and proxies.
@@52ljog I was definitely thinking something like Alpine, but it breaks Content Security Policy. They have a separate CSP build, but it loses its flexibility.
I think we should adopt htmx and just creatre more plugins for it in case we want more reactivity, no one is saying they want a pure htmx world but a lesser js controlled one
At 19:10 You list some cases where you need react to build a canvas app or figma. So no one should be using React except unless you are making figma/excalidraw? I feel that chart comparing htmx to React is misleading, since it misrepresents how many projects need React, or even what % of features in an project need React, since you can use them both.
As a non frontend dev, I think react, ect all have their places, but I think the simplicity of htmx is hopefully going to drive it forward. The ease of making a web app performant using go is a quicker and better experience for me than trying to use something like react.
The way Solid signal works you always have to pass in the component you want to react, pass it value as props doesn't work, since it's not waterfall reaction to the component children.
I'm wondering if htmx is using CSS for all animations, that would make it one of the few frameworks for client side rendering which can leverage 2d and 3d acceleration from your GPU.
It can also use view transitions that are not supported by every major browsers yet, but it generally uses pure CSS. If I understand correctly, HTMX does not deal with the animation per se, it just handles timing the DOM changes so that animations and transitions can fully complete.
Seeing HTMX got me thinking about XHTML back when Theo was still in diapers and the "web" was still trying to figure out what the next move was for HTML. HTML4->HTML5 won. That's probably why I am not interested in any of the JS server/client frameworks: They are overly complex, not that fast, and have a short lifespan. I'm sure some Ruby devs feel attacked by this, too.
I think (agree) all three approaches have their place. However, I think HTMX leans to much into the "easy" vs the "simple" side of things. So for this kind of approach, I'd rather use good ol' jQuery. I haven't used HTMX yet, but I imagine debugging and refactoring must be a nightmare with it.
"HTMX Crash Course" by Traversy Media on RUclips was the real kickstarter for me. After that: "HTMX The Practical Guide" by Maximilian Schwarzmüller, highly recommended.
I don't know exactly at which moment react was broad accepted since hooks, I know that people will hate me but the reality is that the hooks just make a react an unfinished framework thanks to an unfinished feature, all these useState useMemo and so makes react pretty difficult from other frameworks, yes when they implemented was fun because if you domain it you will have a big improvement of performance but very difficult to maintain across your team. Now with the new compiler this seems to be addressed partially, but now, better frameworks already have them by default as svelte and vue EVEN angular is starting to be better than react again. Which for me only demonstrates how Meta was interested on React (not to much to be honest) So I think react fanboys can start using better alternatives than maintaining the thought that react is still the best. At least in new developments.
bruh, you barely have to use hooks other than useState, useEffect and useRef(in case you work with very specific stuff). The performance optimizations that you need from useMemo and useCallback, most of the time you just don't need, and lets not pretend that its hard to use useMemo and useCallback, because its not(its literally just a fcking array of what to pay attention for, and a function that returns a boolean that decides if it should rerender or not). I have no idea how people actually think react is difficult at all. Feels like people just didn't take the time to learn how its cycle actually works
As usual there is no "single right solution". Depends on development model and what one wants to achieve with it. As a real world example, working e.g. at a purely Java shop with lots of backend engineers and customers that are mostly averse to having to maintain a NodeJS image in their repos and infras, all the x.js frameworks that have a server side are automatically disqualified, which in turn means that technologies like e.g. RSC are out of the question. In other words YMMV.
"you would have to adopt React* these days I don't see any reason to adopt React other than job requirements There's more than enough alternatives, and htmx plays nice with all of them
Agree. Don't forget that HTMX makes it so much easier to SEO your page too. Even following WCAG gets much easier with HTML/HTMX. But yeah, you can't build a Figma clone. I think we don't need those clones anymore anyway because we have AI who do such things for us.
@@rizulbhardwaj2675 i didn't look for it but i think i know which video he is talking about, it sounds like one prime reacted to, i will ping you if i felt like looking for it
I do not understand why browsers do not support updating parts of a website natively. Htmx functionality appears to be very clear cut with a small but effective scope. Should be standard of Html protocol and would make everyones life much easier. JS could go back to it’s strengths of fancy UI where needed.
Still not clear on what htmx can not do that React can. I think if you think you cannot do something in Htmx that you can do in React and vice-cersa, thats a "skill" issue. For example if you never dealt with backend more than just prisma/trpc/drizzle etc. then htmx might sound odd/hard/strange. If you never dealt with frontend more than just a date function or something then React is strange. So it means you do not know the other tool/workflow, and that's fine. But it is not a React or htmx "shortcoming". Which, in my opinion, is what the closing statement of this article says. Even if there is something that the other can not do, then that's a specific corner case for your project.
For example, HTMX cannot filter a table on the client. That's why they have Hyperscript as a companion library. HTMX can filter it on the server, but that would need a lot of roundtrips.
That's a lot of words to mull over something that Phoenix has already solved years ago. As usual, JS-folks are (re-)discovering things years later because they are too busy arguing over framework-tierlists and what the best build-tool is.
How you record your videos? Your videos are too good in quality. I am trying to set the OBS settings but now getting the perfect results. I am using Macbook Air M1
OBS should work just fine, and for camera, the other guy is right. It "looks good" because thebackground is blurred, you need a proper lens to get that. However, if you are just starting YT, just use your phone's main camera. It's more than fine until you actually start making money. If you really want to actually buy something, it should be a microphone.
@@Qrzychu92 "If you really want to actually buy something, it should be a microphone." - very good point. Most people are willing to overlook crappy video quality, but bad audio is much harder to endure.
I'm using the latest version of OBS I tried every setting to better the screen recording but nothing makes the quality better. The colors are not like what they are in the actual environment
And if you want microphone do not get the Shure everyone gets because you will then have to eat it on screen for good sound. Search RUclips for advice for 'hidden' mic setups.
Saying vue 2 is entirely different to vue 3 is wrong i think. It still supported 99.9% of all of vue 2 when upgrading to vue 3. Ive used all the major frameworks in production and i can say vue was by far the easiest to upgrade.
@@konstantinpaul8301 it was rhetorical... 🤣 I will never do that. Mobile is not HTML, and now I have a desktop version... so not to soon. In 5 years we see who was right, because my backend still will be support anything, and some people just HTML, depending on some framework doing HTML header magic stuff 😂...
HTMX is not at the backend. Even if the code for it is on the server side it doesn't necessary mean it is the backend because wait for it... YOUR SERVER SERVES YOUR FRONTEND! 🤣
Htmx is cool but it doesn't work for every application. Like making a video editor or live video chat or a midi synth or midi sampler, using PWA offline. But I think custom elements are actually a better fit for these advanced client html5 apis. I think Lit is a better match because its very lean, with these apis you need a really lean library. But for most web applications I think htmx is the answer, for some things that work in an offline PWA though react is still a better choice than htmx.
React will remain king, but Htmx will carve out a decent niche for itself. I could see Solid stealing mindshare from Vue, Svelte and anyone left still writing Angular.
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
Go mentioned in the first 20seconds.
lets go, go mentioned LETS GO
why 😭
GO MENTIONED
LETS GO
As it should be ❤
We have multiple internal web apps for our internal services. All are being converted to HTMX. We're moving quicker, with better support as devs know all of the code. This is where HTMX is going to excel. React will still be used for the very complex web apps. We've estimated that HTMX gets us 90% there. That last 10% is what you would need for a public facing all singing, all dancing UX experience (and I'm talking polished). But mix in HyperScript and maybe you don't need React at all.
Vanila JS library come to the rescue.
Pretty please stay away of Hyperscript (it is a beautiful toy!!!) and use vanilla JS. Learn some tricks from gnat/surreal for locality of behavior, but stick to code any one can understand without learning another library.
Strong doubt the "devs know all of the code" with a magical hybrid render engine, since it's basically NextJS but tricks you into thinking hybrid render is not a complete clusterfruck.
Yeah my immediate thought was that those 10% can probably be built with very little vanilla JS: write a custom 100 to 300 lines library that does precisely what you need to do and call it a day. Or use a very lightweight existing library that fits your needs.
I also don't really follow Theo on the whole "alternative to React for back-end devs". I started with front-end, I like front-end development. I like great UX, sleek UIs, not bothering the server with things that have no business in the server... HTMX allows me to spend more time thinking about this, as I'm not dedicating most of my time writing code just to render stuff, handle navigation, log users in and out... I can dedicate a lot more time to those 10 remaining %. If we factor in modern CSS, I end up needing very little Javascript, but it's some pretty meaningful and important Javascript, which feels great.
Im finishing my bachelors in november and I have months of experience with HTMX none the less python fastapi, node express graphql, and some php. I can show my projects w htmx. Open to discuss a job opportunity as a junior mid? Im in France but can work any timezone.
I wouldn't say I'm betting on htmx, but I do hope it takes off. But I'm just one old-school dev who started Web in 1995 and has never really embraced JS. In my mind it's more of a necessary annoyance than something I want to deal with, and discovering htmx as a way of moving back to a more HATEOAS world has me excited
We're replacing all our internal service dashboards with HTMX. Way more productive.
@@KangoV Hi mate - I am considering doing a POC of this at work to get them interested in alternatives to all-in React - any insights, thoughts or knowledge you can share please for production internal apps? (dashboards and some data input mainly)
It would be great if the HTML-standard itself would finally add PUT/PATCH/DELETE support for forms! This has been in the "if someone took it up"-stage for decades. And if htmx would become just a polyfill for what a modern browser can already do.
Do HTMX work for client-side only things?
@@emiliod90 Take the time to understand the HTMX way of doing things, a lot of times you may be tempted to resort to javascript to solve some less clear cut case, and you can totally do that with the HTMX js API and events, but a lot of the time there's ways to avoid js altogether.
as a backend dev, the HtmX helped me too much to develop the first production version of my projects for the clients without any bad experience
Client side interactivity with HTMX is simple - just ship the webserver in WASM
spring.js
Combine htmx with tailwind, and get a perfect cryptic code, fully consisting of a magic template strings.
@@jerondiovis6128 what are the choices though
you joke but the official htmx examples pages use a mocked client-side server
Can use alpinejs
tbh theo's takes on client side stuff are solid (js), but he's unwilling to consider when writing your own backend is a worthwhile effort, because he's sponsored by people who make their money when dev's dont write their own backends
Nah... He's actually pretty fair/accurate, and definitely not unwilling to consider things.
Working on internal tools makes you appreciate htmx a lot. I literally write a cli app with go first, make an http server and paths reusing the same functions, add a little bit of html and css and i have a fully functional internal tool
The good thing is that HTMX is just another JS library like knockout or lodash. Use it where you can get its benefit but continue to use Angular, React, Vue, Solid, etc. where you need to use something more sophisticated!
Most of the enterprise apps I have built in the last 10 years have a pretty rich set of app configuration screens. Most of those are perfect for the simplicity of HTMX. Reducing the implementation cost and reducing maintainability cost of those screens will help sell them to the PM. Your users will thank you.
Your users will also thank you for the decision to use a richer framework for the heart of the app.
It is not one size fits all. Use the tool that best fits the functional and non-functional requirements being implemented.
HTMX is just one more tool in the dev's tool belt to please the customer and the PM.
BTW, I use SolidJS as my goto UI framework as well - still with just CSR for my simple apps in retirement. I love it. And HTMX supplements it well.
i had the misfortune of not just shipping relay, but forking it and maintaining a fork to integrate graphql subscriptions back in “relay classic” days before subscriptions were implemented anywhere. we built our graphql server on the reference graphql 0.2.0 package and it was ROUGH
"Chasm" is pronounced "kazm".
8:37 there's a difference between simplicity vs hidden complexity
It's simplicity vs ease of use. People very often misuse these terms.
Not really, a difference between the 2. Everything that is simple in programming, in reality it's a third party that's do all the complex things and expose to another simple primitives to work with
It's interesting to note that the JS signals proposal was a "subtle" namespace for the parts which aren't that straightforward. It does note that these aren't intended for everyday use, but complexity has to go somewhere and you hope that the right abstractions are in place to conquer it.
I think the problem is conflating being explicit with being simple. And conflating simple parts with a simple engine. Sometimes, it is better to build something that is complex under the hood but won't grow much more complex or hard to use. If simple explicit parts were always superior to complex, abstracted parts, we'd use nested if statements for everything.
The other issue I have with this is that more often than not, what we call simple is not that simple in the grand scheme of things. It might be the most simple way to do what React does and create SPAs, but HTMX just allows you to create SPAs without doing what React does. You can't do much simpler than NOT HAVING TO DO THE THING.
After falling into the Next.js trap, I've switched to Go with HTMX and Alpine.js. Not looking back. Having fun again.
Alpine needs more love. Its as great as htmx.
You mean Next.js with the app router, pages router, or both?
@@rod6722 To be honest, everything. Layers of leaking abstractions, TS, framework overhead, vendor lock-in, just everything.
As someone who doesn't need the interactivity of full react, I just need to send a colleague a basic Django web app with a bit of interactivity. htmx has saved me probably hundreds of hours. (Both in terms of how much JS I need to learn (because it's not none, some JS is needed for complex use cases) and not needing to learn a bunch of JS frameworks)
I think the future however is something like the BETH stack, where htmx becomes another piece of a larger tech stack, and not a wholely separate thing all the time like in can be.
Praying every day HTMX gets native browser support, imagine the frameworks you could build then.
Honestly if signals are considered, so should be native partial page updates.
Do you mean querySelector and fetch?
@@xali2008 Have the browser recognize hx style attributes natively without having to go through a javascript layer, just seems like a logical step forward in both performance and ease of use. Suddenly 80% of what modern frameworks are trying to do is there by default without some crazy new API you have to learn. It just fits in so naturally.
@@xali2008 No, I mean being able to define them through hypermedia without deriving them from first principles.
Yeah I am sure the browser vendors are hopping to implement another quirky html template engine of the week.
Just getting to the "simplicity over ease of use" part. Rich Hickey has an entire talk on that topic, "Simple made easy".
"Simple Made Easy" - Rich Hickey (2011)
ruclips.net/video/SxdOUGdseq4/видео.html
Was about to comment this lol. His talks are seriously good.
Rich Hickey articulated very well the gut feelings that many senior devs have. The difficulties that complexity brings in to the project. That there is incidental complexity you should avoid and inherent complexity you have to deal with.
Easy solutions are bright and shiny. You can go fast at the beginning. But they tend to have a lot of incidental complexity that pulls you down in the long run.
@@fnumatic5558 Exactly, the concepts of “inherent” and “incidental” complexity are things we should have vocabulary for and be thinking about.
It’s kind of funny to me how loose we can get with language in software-land when we literally wrote specs about what the word “should” means.
@@fnumatic5558 Totally, I had been in the industry for almost 20 years when I saw it, and it finally clicked. For example, I was finally able to articulate why I disliked ORMs. Sure you get started easily enough, but they just brought a lot of accidental complexity. I think EF (when I used it last), because you mutate objects directly, keeps a complete copy of all loaded state to compare against the "domain objects" to determine what to write. And when it doesn't do what you need (it didn't handle orphan removals in aggregates), the s*** hits the fan.
I feel like "clear" is a better term than "simple"
I like this generally.
@@Kane0123 I think the term is originated from KISS (Keep It Simple Stupid) philosophy, that it's about don't do weird mojos to the final users can't see the complexity, but keep simple for the maintainers and other devs.
This video was great. As someone fully focused on react and next, knowing I can rely on you to get a view on the outside status of other frameworks is refreshing.
Its so weird to see some people say that React is so easy to use in a project which is huge in scales, yet whenever I encounter a React application which has been in development for a really long time its always a mess and is just awful to change things inside it, or debug it.
Of course htmx is taking off in popularity. The problem with react and others is that it's built on a false premise: that JavaScript is good.
Js is the problem child that everyone is pretending it's fine, building ever more complex frameworks to hide the problems and adding new ones on there. Web apps are 2 parts: display and comms, stuff when you start to hide the comms bit because you want it to look like it's all js client side code, you will end up with convoluted and often badly performing apps.
Htmx is honest about being the comms party only, handing off display to the browser via dom manipulation and that means it does it really well, really simply to understand, and fits in with the model of browser based HTML.
This.
Things like NextJS and SvelteKit putting JS into the backend just seems crazy to me. I'm very biased, but dynamically typed languages shouldn't be in the backend (and Typescript doesn't add the safety some might think it does). JS also isn't performant in the backend - even compared to Java, so why extend it there?
Front-end frameworks were created to maximise the potential of JS in the browser. Moving them further and further to the backend just seems counter-intuitive to me.
Exactly. JS is fundamentally a shitty DSL born out of a need for annoying pop-up ads on Netscape Navigator. And React was developed by a massive social media conglomerate whose fundamental goal was to justify employing an army of front-end devs; so *of course* they came up with the most convoluted solution humanly possible. JS is an objectively bad language (which is why TypeScript got traction, because it's putting lipstick on that pig), and most people/companies don't have the resources of Facebook to deal with React's absurd complexity.
u can complement the missing parts of htmx writing a plugin for it by yourself, which is very simple to do.
By the way: HTMX likely pairs _quite nicely_ with web components (custom elements), particularly if you’re using the shadow DOM (since I’ve seen some weirdness with it tampering with the light DOM inside of the elements). Anyway, that said: There are ways to roll your favorite frameworks as custom elements too (shameless plug: mine is svelte-retag). So in a way you can get the best of both worlds.
Plus, there are solutions coming out like Enhance WASM coming out with the goal to make it super easy to SSR web components in PHP, Java, Ruby, Go, etc… thanks to web assembly. Pretty interesting stuff going on right now.
Web Components are driven entirely by javascript (the worst kind, aka OOP) and the whole point of HTMX is not to write javascript. What gives?
This combo has as much sense as two-way XML/HTML transformer. Sure you can write it, but for what purpose?
@@ra2enjoyer708 Not quite true. There is Declarative Shadow DOM now for Web Components generated server side.
I thought HTMX doesn’t work with Web Components? Especially in the Shadow DOM. Have you actually tried it?
@@darylbarnes9413htmx works fine with webcomponents.
1. Define a custom element (eg
2. add the relevant script tag to the html
3. htmx calls return html fragments that use the custom element
I'm FULLY in the Go net/http or Gin + HTMX camp (possibly a fanboy), but the new React and current Solid DO seem cool for frontend devs who want to do things that require a backend!
Not really a war. It's using the right tool for the job. I suppose React has its place.... sometimes.
The cool thing about htmx is that if you want to add some cool interactivity you can just pop a bit of react in there no problem, your whole app doesn't need to be in react, only what needs something like react. :)
How do you accomplish this?
Htmx wiki tells you how @@zeph8620
Htmx is just a library, you add it and use it
Most of the time for the interactivity that you are lacking in HTMX can be solved with plain old javascript
@@cockerswilde Very true, it also makes you dependant on way less stuff C:
Think most underestimate AlpineJS. That library, compared to React is a so much nicer to use when it come to creating interactivity on the client-site. It's true that the HTMX site points out the limitations that where mentioned in this video. But it also says that you can use a scripting language on the client-side. The site advocated for vanilla JS AlpineJS and Hyperscript. HTMX is not anti-JS like people keep saying. It wants to put the emphasis less on the scripting langue. So instead of using some JS framework to build the whole thing use a little bit of scripting here and there to better the user experience.
Exactly. For parts that need more interactivity than htmx can provide out of the box, we can use alpine, hyperscript, stymulus, or even vanilla JS. Also, if the page or component is too complex, nothing prevents of using React for that part. HTMX can send and listen to events and therefore communicate with these libraries pretty easily.
People mention Alpine all the time. I used Alpine and it's all fun and games, until you really need to control complex cases of nested components and the order they render. Even worse when you mix them with template engines(because you write everything in a fkin string) or htmx(because they offer solutions to the same problems and now you have to decide which you pick, and then sometimes only one of them can solve your problem and you will have to code a bridge between your htmx and alpine stuff). People should be more honest. NextJS, Vue, Solid and Svelte (maybe angular too) are the only way to build a cohesive AND complete solution to ANYTHING that requires harmony between client AND server. If you want to make it all serversided or all clientsided then we can have a discussion, but honestly, that feels like a huge downgrade.
@@upsxace I agree that this "mix" between htmx and alpine is not resolved yet.
Like you said, for more complex cases you'll have challenges. Not the end of the world, but you'll need to build some code to fill this gap. It might not scale well depending on the project.
I just disagree with the affirmation "the only way" and that htmx approach is fundamentally a downgrade.
For a few complex components you can add react/vue/etc only to handle them. And if your project has many complex cases, you might drop htmx/alpine and go all-in with react/vue.
But having additional alternatives is not a bad thing. People can choose what they like and learn from it.
Big players will feel they need to improve to continue relevant. Specially if these alternatives are very different in their approach.
@@user-mahaka2002 it's just so much easier to code everything in react/svelte/anything after you learn it, so to me it still feels like a huge downgrade
@@upsxace perhaps it's also related to the background of each dev. For people more focused in the backend, htmx looks like a holy grail 😂, that they can use to build nice stuff without going too deep into the js world. Skill issue? Sometimes yeah. But not always. Perhaps some of them just don't like the idea of the full SPA approach for everything.
While people who is highly specialized in JS often don't see advantage of investing time to try htmx.
Also, I worked on projects with specialized large teams (back and front), where product departments were constantly requiring complex highly interactive stuff. Honestly, I don't see how htmx could be adopted in such environments. Probably that's not even the goal of the library.
But I also worked on mid size products (e.g.: ecommerce) where HTMX could shine and the separation of back and front was not really helping that much.
There is also a considerable number of startups or solo entrepreneurs that could build/evolve their stuff successfully for a long time with HTMX/Turbo/Unpoly/Alpine before the need to reestructure it as an SPA.
In summary, I just think there's space for everyone, also love React and Vue 😊
I think a lot of people are just butthurt because HTMX is showing them that React is a mountain of overkill for most projects, and they've all been wasting their time for no reason because they bought into the idiocracy of "Facebook uses react...yeah, it's got components".
HTMX + Alpine + Your SSR backend of choice is a dream come true for backend focused developers like me.
18:20 I appreciate you calling out this gap in htmx, as an interested user of htmx, because that gap is precisely what I’ve been thinking web components are good for. Back end devs will have to do a little front end work to use that, but with frameworks like Svelte 5 being fairly approachable, I think it’s not so bad.
Great video! The article also slaps.
Yeah, if you're building an app that requires greater interactivity on the front end, even Carson Gross himself acknowledges you'll need to use an additional library (or write you're own TS/JS) to achieve that. Web components? Alpine.js? Perhaps even Carson's own (completely batshoot crazy) _hyperscript? Something.
HTMX is the best idea that we've ever had. An idea so brilliantly simple that any actual implementation, any actual specific API, become far less important than the idea itself.
"simplicity over ease of use" - this sounds like Lisp and Scheme will celebrate a comeback ☺
I would bet on Prolog
@@konstantinpaul8301 looking at the comments of students of mine who have to learn prolog, I would not bet on prolog.
Any thoughts on utilising Hyperscript with HTMX to bridge that last gap you showed for HTMX? I've shipped Intercooler, HTMX and React to prod - funnily enough, some people seem to struggle more with understanding HTMX vs Next (and by extension, React + supporting libraries) which is simply nuts to me.
Switched to Django + Htmx + Hyperscript... 2 years ago.... Never go back to anything else.
I can't create Google sheet for sure... But I can create any other SPA out here.
@15:42
Oh boi... this gives me the feeling of the old days XML-Script and other xml-based scripting languages, creeeeepy
React is good for simple apps and complex apps. Htmx is the one pretending there is a problem while the serious world ignores it.
Honestly after using React from almost day 1, I don't understand why we want all this complexity.
Where's the love for Solid in the title 🙁
I'm from Brazil and I I study Software Engineering at a university. There's no better way to start the day than with Teo's new video.
Brazil mentioned
BRAZIL MENTIONED 🇧🇷
🇧🇷🇧🇷🇧🇷🇧🇷
7:36 Note that Svelte runes change that. Reactivity is explicit but still comparatively easy.
let count = $state(0);
Loved the principles that were highlighted, if you want to get a good handle on the difference between ease and simplicity I found Rich Hickey "simple made easy" very informative.
the horse I'm betting on is HTMX, and is because it's got laser eyes!
In all seriousness, the simplicity is nice. Even though it comes with a cost, even the trade off is quite clear from the get go
solid.js or Lit can be used to create custom-elements(native browser-based web component) which can be used to create widgets(which render on browser side). Then that those widget + HTMx can be used along old-age server-side templates like FTL(Java) or Jinja(Python) or TPL(Php) for server side partial rendering. And the state can be managed totally on server side with Some Redux Like or Some State Machine library. So that way Widgets are loaded & render on client-side + Layout logic and Routing or State Management remains on the server side.
The Svelte/React example on simplicity vs. ease-of-use I think directly correlates to what I feel is better about Next vs HTMX. HTMX is definitely simpler, but is not as easy to use, especially when you want to implement that [one thing] (insert any number of "one things") that it doesn't handle well. Next is very easy to use, and things like Vercel make it easier.
Most of the things Next/Vercel can't do are things even a Go/HTMX app shouldn't do---and should instead punt to a queue or kubernetes cluster. Except maybe websockets, but if that's a requirement you can simply throw a Dockerfile on your Next app and toss it into GCP or AWS instead of Vercel.
I want something _like_ HTMX to be the future of web dev, but I think it currently falls short of the realities of the needs of most modern web applications.
I wonder, why i see discussions about react, solid, svelte, htmx and not about vue, it's fast, and would become faster and smaller soon, because vue core team is working under removing virtual doom, has huge and wonderful ecosystem and can be used for almost every kind of software, why vue isn't solution in this war, you may just combine htmx for server-side rendering and vue for client-side moments, or take nuxt/astro/vitepress, why react with its endless compromises or solid with its small ecosystem and community, according to the benchmarks vue is not critically slower than solid. Maybe I just not fully understand why?
“react is simpler than svelte”.
Every time you write react, you need tons of wrappers for basic things, such as fetch, or using native web apis, because of how virtual dom works. It ends up in a bloated projects with millions of dependencies, that conflict with each other, and you don’t control your codebase. At the same time, you could adopt any JS library or web api feature with svelte, in a clean composable way.
The simplest framework is the one you know already. I use React for years now and even though Svelte is less verbose in some things and does have some things built in that React doesn't (transition primitives and built in more complete state management for example), I cannot be productive with it as much as I can with React because I already have so much more knowledge and experience with React. simple/complex and DX are extremely subjective.
And the thing you mentioned about wrappers is not true as a general statement. It all depends. Why would you need a wrapper for fetch to use it inside a React project? That's just a statement that's not correct. You can just use fetch inside a React project without wrapping it into something special. I do agree that fetch does require a wrapper, but that's because fetch is a horrible API to use barebones so wrapping it up into something nicer is mandatory regardless of the tech stack.
I do agree that some other vanilla JS things are harder to use because you have to make them work with React and its way of doing things.
it is simpler since svelte hides a lot of its complexity from you, unlike react
@rand0mtv660 not in the case of Svelte vs React, years of experience of React and it took me a week in Svelte forming the opinion that Svelte is much simpler
@@oidualx I'd still say it's quite subjective. And I'd say a week for such a big change isn't enough to form a proper opinion. Build a real application in both, then do comparisons. Some things don't pop up until you actually build something realistic.
I still think Svelte is extremely cool though, but as everything else in programming it's not a silver bullet that will solve all your problems.
@@rand0mtv660 I've transitioned our internal dashboard from react/next to svelte and its like night and day. It might just be my desired way of writing code matching their patterns, but it's an incredibly simple meta framework
Where HTMX starts to really shine is when your backend app that drives it all isn't written in JS. Suddenly a whole pile of translation layers to and from JSON are no longer needed, and this greatly simplifies the whole architecture.
Where it really blows React out of the water is when your application needs to manage state that is shared between multiple users. No amount of frontend framework magic will let you do that without dealing with a gigantic mess.
Btw websockets are supported/integrated in HTMX via an extension (script)
@@konstantinpaul8301 yep ikr - and it handles reconnects and ping heartbeats automatically too
There is also an excellent SSE extension that makes realtime updates dead simple without even needing web sockets - wrote some simple multiplayer turn based games to try that out, and its super easy
Zig frameworks on the backend support both web sockets + SSE, so doing a whole app in something other than JS is a true joy
I can't believe how far Ryan and solid have gone. (I worked with him in my early career, in 2014)
I'm betting my near future on HTMX, F#, Tailwind, and Alpine
Betting on Htmx + Hyperscript.
Is Solid really that much about "simplicity over ease-of-use"?
From personal experience - it's easy to use indeed, quite minimalistic code, very good set of out-of-the-box tools, "look, it just works"... but then it appears that for that to work, you are required to follow a vast set of very special rules.
You are not allowed to do even most trivial of trivial things:
- Don't do props destructuring - because it will obviously break reactive values
- To define a default value for a prop - use a special helper
- To split the "rest" props - use a special helper
- Don't pass event handlers directly to nodes - wrap _everything_ in an extra function call
- Don't use async even handlers - because... I don't even know why, but Solid's special eslint rule complains about that. So you have to wrap it into extra func, and define an async IIFE inside it.
And so on. Altogether, this really turns codebase into some kind of "magic" (not "magical"). You have to consantly write some pretty arcane code, which in terms of plain JS doesn't make any sense. Write code not for yourself, but for the framework.
Am I getting smth wrong about it? Because for me that didn't feel like "simplicity".
i'd argue those fall under 'ease-of-use' - the underlying primitives of signals/effects/suspense/data apis are still simpler, but the authoring experience has some rules you have to go by (and so does react, not that you brought it up)
also i've never experienced that async event handler problem, i've got plenty of them that work fine and haven't been able to reproduce it in the playground
This is the same way Vue 3 works, using the defineProps and toRefs helper for props.
It's just a thing with these fine grained reactive systems.
I do agree it is not perfect, but It was much more explicit then when I had to use Svelte.
Still I prefer using mergeProps rather than rerendering the whole component every time, like React does.
@@brendonovich Do you use Solid plugin for eslint?
Because, in practice async handlers seem to work just fine, indeed - but eslint doesn't like them for some reason. "This tracked scope should not be async. Solid's reactivity only tracks synchronously" is what I'm getting.
And it's not like one rule specially for async handlers - it's a part of huge "solid/reactivity" rule, whuch includes everything at once. So it's not even an option to disable it.
@@brendonovich React does bring its own rules too, for sure. It's just they seem much more reasonable to me.
Basically, React just wants you to:
1) not call conditionally things explicitly starting with "use"
2) don't do side-effects directly in component's body.
That's it. The rest is just a normal JS.
Unlike in Solid, where I'm not allowed to use a native language syntax.
Just use React, the performance diff is not worth the hassle you mentioned.
I’m good with Vue. It’s good for POCs, scales up well and has good performance.
another video of him just reading an article
Great video! But careful to not pull a muscle with those thumbnails man, have a great weekend!
Theo, I'd love you to do a deep dive video over RSC and the weird JSON protocol it uses to "render" components.... I thought RSC were always just doing SSR into HTML on the server, but I recently learned this isn't the case.
In the OG days...? React has 5% marketshare in 2024 while Jquery is like 90% in 2024. React is still a niche topic.
I LOVE the idea of "simplicity vs ease of use", only got to 7:10, so maybe this will be covered, but the thing that frustrates me a bit about the "New React architecture"/RSC+Server Actions is that it's 100% ease of use, sacrificing a lot of simplicity... which isn't a bad thing, just a trade off that has advantages and disadvantages~
Then why it frustrates you if you understand the tradeoffs?
@@diadetediotedio6918 Because the goal of React isn't "to be easy for newcomers", if anything React used to be squarely on the "simplicity"-side. We went from React being a framework I felt I could write myself (and thus understand pretty well) to React being this magical land. Generally I am equal parts excited about these new developments, and concerned that they are a bit losing focus on the big picture (next.js' difficulties adopting the page transition API is a beatiful example of that, as making the server/client boundary 'magical' and in certain ways 'messy' means that ensuring network requests happen before the transition starts is difficult).
This reminds of jQuery when it came out and it still does it's job on the most Websites. Why do you really need to reinvent the Wheel? I mean, I am lucky enough with vue, no need to touch Svlete, React or Solid. Know one thing, but know all it's details until the core bone. For the main Goal from all of them - to build a SPA / MPA - they do it all, but you don't need to use all of them. Customer doesn't care how you build it as long it does work and they won't pay you more because you took the time expensive route.
Hey Theo, Perhaps as a huge RSC enthusiast you would be interested in responding to the fair criticism in the article "How Next.js Breaks React Fundamentals" on Ondrej Felisek's blog?
I am surprised planetscale is still mentioned since it's no longer offering a free tier.
8:00 it will still be a compile step, but not for the same reason as Svelte 4. Runes look like functions, but they do not have any implementations and need to be used in .svelte or .svelte.js/ts files. At the end they are Signal primitive like you pointed, but that compiler step allow devs to use the variable instead of the .value proxy. No need for "variable.value", simply use "variable" and the compiler will change it accordingly
Enjoyable to watch interesting content mixed with honest praise!
Frontend got bloated these past years, lots of solutions for problems which didnt exist in the first place. it became like linux distros!
Yes, it's because they want to solve many different things for many different people. It's the trade-off of a more general approach. But the nice thing about linux is that there are many options to choose from, so you can use arch btw! if you want to
@@spicybaguette7706 You missed the point!
@@seyyedkhandon Bro what is your point then? You can complain about software all you want but at the end of the day the solution is simple: just don't use it
Can something like HTMX + (parts of solidjs) framework be used to fill in that remaining gap that HTMX cannot solve? I feels like try to solve with HTMX, but if you need more reactivity, just go to SolidJS.
Custom vanilla JS or alpine.js. What kind of reactivity are we talking about ? I feel like people underestimate the kind of thing you can do with modern CSS and HTML (, , popover, has()...) some event listeners and a couple observables and proxies.
@@52ljog I was definitely thinking something like Alpine, but it breaks Content Security Policy. They have a separate CSP build, but it loses its flexibility.
I think we should adopt htmx and just creatre more plugins for it in case we want more reactivity, no one is saying they want a pure htmx world but a lesser js controlled one
At 19:10 You list some cases where you need react to build a canvas app or figma.
So no one should be using React except unless you are making figma/excalidraw?
I feel that chart comparing htmx to React is misleading, since it misrepresents how many projects need React, or even what % of features in an project need React, since you can use them both.
As a non frontend dev, I think react, ect all have their places, but I think the simplicity of htmx is hopefully going to drive it forward. The ease of making a web app performant using go is a quicker and better experience for me than trying to use something like react.
The way Solid signal works you always have to pass in the component you want to react, pass it value as props doesn't work, since it's not waterfall reaction to the component children.
Tauri app optionally uses simple React(you will be benifit from React features) for UI. React is still shining there too.
and also solid-js, nothing special for me
I'm wondering if htmx is using CSS for all animations, that would make it one of the few frameworks for client side rendering which can leverage 2d and 3d acceleration from your GPU.
It can also use view transitions that are not supported by every major browsers yet, but it generally uses pure CSS. If I understand correctly, HTMX does not deal with the animation per se, it just handles timing the DOM changes so that animations and transitions can fully complete.
Seeing HTMX got me thinking about XHTML back when Theo was still in diapers and the "web" was still trying to figure out what the next move was for HTML. HTML4->HTML5 won. That's probably why I am not interested in any of the JS server/client frameworks: They are overly complex, not that fast, and have a short lifespan. I'm sure some Ruby devs feel attacked by this, too.
18:00 as a backend dev i would just write a bit of js that updates the page. VanillaJs without react.
7:43 "let count = 0" somehow needs a compiler because it's not using JavaScript as JavaScript. My head is about to explode
@Theo why is your arc browser logo some platinum color? How did you make it look like that?
I think (agree) all three approaches have their place. However, I think HTMX leans to much into the "easy" vs the "simple" side of things. So for this kind of approach, I'd rather use good ol' jQuery. I haven't used HTMX yet, but I imagine debugging and refactoring must be a nightmare with it.
React - thesis, HTMX - antithesis, Svelte is synthesis - its solve
What would be a great tutorial for HTMX to get started with it?
"HTMX Crash Course" by Traversy Media on RUclips was the real kickstarter for me. After that: "HTMX The Practical Guide" by Maximilian Schwarzmüller, highly recommended.
I don't know exactly at which moment react was broad accepted since hooks, I know that people will hate me but the reality is that the hooks just make a react an unfinished framework thanks to an unfinished feature, all these useState useMemo and so makes react pretty difficult from other frameworks, yes when they implemented was fun because if you domain it you will have a big improvement of performance but very difficult to maintain across your team. Now with the new compiler this seems to be addressed partially, but now, better frameworks already have them by default as svelte and vue EVEN angular is starting to be better than react again. Which for me only demonstrates how Meta was interested on React (not to much to be honest) So I think react fanboys can start using better alternatives than maintaining the thought that react is still the best. At least in new developments.
bruh, you barely have to use hooks other than useState, useEffect and useRef(in case you work with very specific stuff). The performance optimizations that you need from useMemo and useCallback, most of the time you just don't need, and lets not pretend that its hard to use useMemo and useCallback, because its not(its literally just a fcking array of what to pay attention for, and a function that returns a boolean that decides if it should rerender or not). I have no idea how people actually think react is difficult at all. Feels like people just didn't take the time to learn how its cycle actually works
As usual there is no "single right solution". Depends on development model and what one wants to achieve with it. As a real world example, working e.g. at a purely Java shop with lots of backend engineers and customers that are mostly averse to having to maintain a NodeJS image in their repos and infras, all the x.js frameworks that have a server side are automatically disqualified, which in turn means that technologies like e.g. RSC are out of the question.
In other words YMMV.
HTMX. WASM. Throw all the other junk client bloatware overboard.
HTMX for Ajax, but is there are some similar libraries for animation things?
"you would have to adopt React* these days I don't see any reason to adopt React other than job requirements
There's more than enough alternatives, and htmx plays nice with all of them
Yeah honestly, I think out of all frontend solutions, React is the most bloated and least intuitive.
@@CodecrafterArtemis the video talks about Solid using JSX as if that's a good thing. JSX is awful!
Agree. Don't forget that HTMX makes it so much easier to SEO your page too. Even following WCAG gets much easier with HTML/HTMX.
But yeah, you can't build a Figma clone. I think we don't need those clones anymore anyway because we have AI who do such things for us.
We shipped Relay and regretted it!
I maintain an app using relay. The person who added it interned at Meta
11:37 you didn't link your video in the description !
did u find it ? I don't think its uploaded
@@rizulbhardwaj2675 i didn't look for it but i think i know which video he is talking about, it sounds like one prime reacted to, i will ping you if i felt like looking for it
I do not understand why browsers do not support updating parts of a website natively. Htmx functionality appears to be very clear cut with a small but effective scope. Should be standard of Html protocol and would make everyones life much easier. JS could go back to it’s strengths of fancy UI where needed.
For the htmx fanatics: ca we see a live production full scale app done with it. Haters say it's only good for PoC and demo of hipsters on yt
ruclips.net/video/3GObi93tjZI/видео.html
Still not clear on what htmx can not do that React can. I think if you think you cannot do something in Htmx that you can do in React and vice-cersa, thats a "skill" issue.
For example if you never dealt with backend more than just prisma/trpc/drizzle etc. then htmx might sound odd/hard/strange.
If you never dealt with frontend more than just a date function or something then React is strange.
So it means you do not know the other tool/workflow, and that's fine. But it is not a React or htmx "shortcoming". Which, in my opinion, is what the closing statement of this article says.
Even if there is something that the other can not do, then that's a specific corner case for your project.
For example, HTMX cannot filter a table on the client. That's why they have Hyperscript as a companion library. HTMX can filter it on the server, but that would need a lot of roundtrips.
That's a lot of words to mull over something that Phoenix has already solved years ago. As usual, JS-folks are (re-)discovering things years later because they are too busy arguing over framework-tierlists and what the best build-tool is.
How you record your videos? Your videos are too good in quality. I am trying to set the OBS settings but now getting the perfect results. I am using Macbook Air M1
It just looks like he's using a proper camera, i.e. a mirrorless or DSLR. Anything made in the past 5-7 years will do the job just fine.
OBS should work just fine, and for camera, the other guy is right. It "looks good" because thebackground is blurred, you need a proper lens to get that.
However, if you are just starting YT, just use your phone's main camera. It's more than fine until you actually start making money. If you really want to actually buy something, it should be a microphone.
@@Qrzychu92 "If you really want to actually buy something, it should be a microphone." - very good point. Most people are willing to overlook crappy video quality, but bad audio is much harder to endure.
I'm using the latest version of OBS I tried every setting to better the screen recording but nothing makes the quality better. The colors are not like what they are in the actual environment
And if you want microphone do not get the Shure everyone gets because you will then have to eat it on screen for good sound. Search RUclips for advice for 'hidden' mic setups.
The videos he talked about are not in the description.
Meanwhile SvelteKit is just enjoying itself in the stands
Saying vue 2 is entirely different to vue 3 is wrong i think. It still supported 99.9% of all of vue 2 when upgrading to vue 3. Ive used all the major frameworks in production and i can say vue was by far the easiest to upgrade.
If one hasn’t seen a hydration error is one even using ssr?
"Crossing the network gap" - Doesn't it go exactly in the direction of being magical?
As much as React is "just" JS.... REST is just HTTP
If I have a SAP and a mobile APP, using the same backend HTTP/API... I will need to have two backends?
Just chnge your API response to suitable HTML
@@konstantinpaul8301 it was rhetorical... 🤣 I will never do that. Mobile is not HTML, and now I have a desktop version... so not to soon. In 5 years we see who was right, because my backend still will be support anything, and some people just HTML, depending on some framework doing HTML header magic stuff 😂...
What, fastest i've gotten notified Abt a new vid
truthfully there are 225k stars in react repo meanwhile htmx got 35k
so either i got something wrong or the artcile got mistake 🙃
HTMX is not at the backend. Even if the code for it is on the server side it doesn't necessary mean it is the backend because wait for it...
YOUR SERVER SERVES YOUR FRONTEND! 🤣
Htmx is frontend js. It just connects your backend code to the browser easily. It's more a comms+utility lib than anything else.
The point is, it doesn't make sense to code anything in HTMX if you can't code the backend. It was pretty simple to understand what he meant.
Htmx is cool but it doesn't work for every application. Like making a video editor or live video chat or a midi synth or midi sampler, using PWA offline. But I think custom elements are actually a better fit for these advanced client html5 apis. I think Lit is a better match because its very lean, with these apis you need a really lean library. But for most web applications I think htmx is the answer, for some things that work in an offline PWA though react is still a better choice than htmx.
But given the choice I would choose Lit rather than react or htmx.
Can you please use Dark Reader?
Could the HTMX + AlpineJS combo get me 100% into React territory?
React will remain king, but Htmx will carve out a decent niche for itself. I could see Solid stealing mindshare from Vue, Svelte and anyone left still writing Angular.