The Future of HTMX

[@2funk2bpunk]

Wait.. html was designed for printers? Seriously? There is no mention of printers on the wikipedia page, and printing html files is always a pain in the butt.

[@l10nbit]

It wasnt designed for printers. I was there. It was designed from a paradigm that was based on printed media, but only because we were still all thinking that way.

[@tkemaladze]

it was a joke... relax

[@2funk2bpunk]

@@l10nbit ah okay i think i understand now. thanks!

[@N1rOx]

@@l10nbit wait, so you're a printer?

[@hentype]

No, but html was designed to look like physical documents. You know, like printed documents on papers but sent and viewed on your computer screen instead. That's why the basic tags you first learn are the basic template with a and then basic text formats like and .

[@nitsanbh]

0:10 WebAssembly is bad? Sometimes Theo thinks the world ends at the horizon of frontend dev. Yeah, the rust project aiming to render UI on a canvas was a failure. But what about running FFMPEG in client side? Or any custom string/image manipulation C++ libs, that already exist, and are able to run 50x times faster than crappy js impl in a web worker?

[@vinialves12362]

Ah finally! I was looking for someone raging in the comments.

[@MamoonSyed]

WebAssembly’s problem is that most people are making crud apps that have no benefits from being cross-compiled, and fundamentally most people have no idea how to write that kind of code. Theo is a front-end guy so it would very seldom make sense for him to use WA, but there are plenty of use cases for it that are actually compelling. We’re just talking about it in the wrong spheres, in my opinion.

[@_sjoe]

I was blindsided by this take, considering many of his sponsors have successfully used WebAssembly. You can find engineering blogs about it from SingleStore, Turso, Prisma, and more. WebAssembly is revolutionary and has enabled amazing things on (and off) the modern web...I really don't understand where he's coming from here.

[@_albertlol]

Yeah, what did you expect from the ultimate JS fanboy? If it's not React adjacent, it might as well not exist in his universe. WebAssembly could revolutionize the entire in-browser experience, and he’d still ask if it works with his latest JavaScript framework of the week.

[@moho472]

​@@MamoonSyedYou said it the best. I'm a firmware dev, and I don't know much about Web Development like JS, TS, React, etc. However, Webassembly has me interested in learning it, because I have the prerequisites. Different strokes for different folks.

[@otnima]

I've been creating websites for 15 years, with modern with technologies I lose so much time fighting with the tools rather working on implementation. It has it use cases but for a simple website I feel it's overkill. The day we have native html/js components with slots, scoped css and reactivity that aren't a complete nightmare is going to a glorious day

[@nelakendra2296]

What part of that are we missing? I already feel like the native HTML web components do all of that and more cleanly than many of the frameworks. I've honestly been simplifying my code bases and just going native HTML/JS. It's faster, cleaner, it's very easy to understand the code and what's happening, and of course no massive mess of dependencies.

[@MadsterV]

the heavy lifting React does today is coordinating the updates to the tree for performance and enabling modularity. You'll always be building tools on top of tools. That's just how IT works.

[@otnima]

@ It's admittedly been a while since I've given web components a go but last tried they were a real pain to create vs the simplicity of the syntax of something like svelte and had aweful compatibility, maybe I should give them another try.

[@otnima]

@ Sure it's always been a case to some degree, but there's a huge difference in complexity in adding a jquery script to your head and you're done vs installing node + npm/nvm/pnpm/bun + installing and maintaining package versions and getting everything to play nice together.

[@ET_AYY_LMAO]

10:00 JSON wasnt really invented as such but was always a language feature in JS, the object notation scheme. Prior to JSON parsers people would use eval() to parse JSON. Its not that you couldnt do dynamic stuff prior to ajax, it was just a hack, you would add script tags to the DOM and then you would load a new script, this technique was called JSONP later, but it was used for a decade before that name. Honestly I think that "react made it easier" is a very controversial take, frontend has become super complex and abstract compared to using just JS and HTML. Sometimes its for the better, but honestly most react projects I have seen have been unmaintainable junk, almost worse than jquery in terms of readability. I think modern webdev adds too much complexity, every static website these days is some kind of react+next.js monster SPA that loads like 100x more code than it loads actual content for the end user, to be frank, react+next.js has turned the internet into ASS, all the SPAs make competitors to google and bing a pipe dream because of the cost and complexity involved in indexing these "apps" that should just have been like 5 html files.

[@ericjbowman1708]

Hear, hear. As a RESTafarian since the 90's, I'm getting a huge kick out of the new trend towards "server rendering" because that's exactly what we were saying all along. Lists of identical blank buttons suck. Don't hit me with "it's code-on-demand", an optional constraint, when you don't know how to properly identify resources -- a core constraint, easily met with a LINK not a scripted button! This paradigm shift nerfed accessibility to users of assistive technologies. Please stop!

[@ericjbowman1708]

45:00 In XForms, bind a control to and no scripting required for this example. Make the new content permanent by submitting the form. Leave it to the XForms engine to make a PATCH request to update one element, or in the case of multiple edits, PUT the entire form. Twenty years later, it's still a control bound to an element in an HTML document... a self-describing interface, with self-descriptive HTTP messaging. If I want it to look different, I edit the CSS. The js used to implement spellcheck may be a bit different or call a different library, maybe not, but the results are long-term-stable and maintainable.

[@MadsterV]

@@ericjbowman1708 Backenders want to do everything in the backend (render plain html, make everything a request). Frontenders want to do everything in the frontend (server components, node) Neither takes full advantage of both sides.

[@PraiseYeezus]

"Honestly I think that "react made it easier" is a very controversial take" did you genuinely watch the video...? He said it's easier for large complex projects but adds too much complexity for anything less than that

[@ET_AYY_LMAO]

@@PraiseYeezus No, rewatch the video, either you are referring to a different part than me (he makes the statement multiple times). He says it shouldnt be a controversial take, but honestly it is.

[@fandorm]

You are to young apparently… we did ”ajax” style stuff before ajax. Either use s or script tags did the trick. It wasn’t good looking and it hurt as h..l but it did work. I was doing this end of nineties and beginning of 2000

[@leonkernan]

Was going to say, frames or s was the common answer. 1px images also got a bit of a workout.

[@ET_AYY_LMAO]

Yeah! We also used JSON long before it was called JSON using eval() to parse object notation...

[@hentype]

yep, the eval hell was real and painful 😂

[@gearboxworks]

Theo is a millennial, what da ya expect? But seriously, bringing up frames is really just pendency for the topic of this video. 🤷‍♂️

[@MadsterV]

The point is that this is not how software evolves, and it's relevant because the topic is HTMs' stance on precisely that point.

[@actionscripted]

A big component of raising user expectations as the web evolved was Flash. Interactive graphs, games and dynamic, load-free pages and interactivity along with (sometimes absurd) animation. It could be built with visual tools and could scale up to video streaming, 3D and even standalone apps. It wasn’t accessible and crawlable (well…not fully) and it was absolutely the right thing to leave it in the dust once standard web APIs caught up. But this was how we did things for a long time and it was absolutely a contributing factor to user expectations back when websites were at best framesets with GIFs.

[@theyreMineralsMarie]

But damn was it fun learning and building websites with Actionscript.

[@peet._.]

Feel like this is completely forgotten - especially when I hear things like "before AJAX building a complex web app was basically impossible" ... I mean I've been building single page apps since like 2003, and I'm by no means amongst the first to do so. Flash WAS a ubiquitous web technology - very few people did not have flash installed back then because a lot of big websites used it to make experiences that absolutely were not possible to match even going into the mid-2010's. It was flash that drove user expectations of the web and the creative's that it attracted with its toolset - shame that it was essentially murdered by Adobe, who would rather see the technology die than act toward some kind of open standard based around flash.

[@nikomancer69]

@@peet._. Theo forgot about Flash which is a very un-millennial thing of him to do. That shit was our childhood, man. Also, Java Applets were a thing too, unfortunately!

[@flamakespark]

Kudos to HTMX devs for reviving HATEOAS

[@ericjbowman1708]

If by that you mean by H, the "H Text Markup Language" then I guess so, because the whole thing's missing the yper. Scripted buttons may meet the definition of hypermedia, but when substituted for links they fail to apply the identification of resources constraint, and fail to behave as links in any way let alone which can be overridden by the user agent based on preference (do I want all links underlined). Hypertext links are what made the Web scale World Wide, not scripted buttons.

[@tikabass]

I have to assume that's a sarcastic comment.

[@ericjbowman1708]

@ Not at all. Do assistive technologies work with your output? That's a non-starter for me, and evidence of architectural mismatch.

[@tikabass]

@ericjbowman1708 Oh. Not _your_ comment. I surely meant the original comment by @flamakespark.

[@ericjbowman1708]

@@tikabass my bad

[@Tekay37]

14:40 I don't think it's a straight line for all aspects. There are certainly some aspects (like application performance) that have come down. For example, people don't expect websites or programs to fully load within 1 second or less any more. In some cases we fully accept when it takes ridiculously slow 5-10 seconds for an app or website to get in a state where you can start interacting with it. Programs and websites have become so slow (on average) that many people don't realize how extremely fast their computers actually are because non of that speed is actually used.

[@colin7452]

I think it’s also probably due to the fact that most devs build their apps/websites at home/office on a super fast internet fiber connection with a powerful computer, whereas a lot of users end up using it either on the go on crappy 4G or 3G, on traditional, slow, countryside wifi, and/or on a low-end device. When we build and test the app, we see nothing wrong, because the huge bundle loads fast, but that’s not the reality for a lot of users. We really should make more use of the connection and CPU throttling features when testing.

[@Tekay37]

@colin7452 Yeah, websites are tested mostly on the PC you program on, so you don't experience those loading times while developing. Also, examples are often low and some stuff may even be mocked or disabled during development (e.g. ads). But there's also the widespread sentiment that performance isn't important as long as you develop your features quickly (time to market something something).

[@GarethDavidson]

@colin7452 It's mostly in the request count and cumulative latency. And the being fucking shit of course, which can't be excused.

[@sohomdatta]

4:15 Theo, you are underestimating how popular jQuery is, literally Wikipedia and Amazon use it as of today

[@comradepeter87]

pretty sure even this KZbin page uses it somewhere (since I can totally do `$('video').playbackSpeed = 2;` from the console).

[@coolemur]

Websites HAS jQuery (as legacy). But any developers with common sense don't USE it. If I would see developer using jQuery in 2025 I would instantly assume that developer has low competence in web development and can't keep up with technologies.

[@raineaeternal]

@@coolemur Either they don't keep up, or they just want to make apps that *work.* A lot of web apps today have random intermittent issues because they have so much complexity, which them leads to unstability. It's not entirely unheard of to just make something available and have it just *work.*

[@very_unique_username]

@@comradepeter87Chrome DevTools support $ as a shorthand for document.querySelector(), it’s not jQuery though

[@hentype]

@@raineaeternal Yep, I started with jquery and would rather use that for a blog that only needed a basic comment section instead of using a whole framework for a couple basic function. JQuery doesn't scale well but in cases where there isn't any scaling needed and you already know how to write the needed script from scratch in a minute it just works best. When making more feature rich and modern projects I'd opt to the ones I already know like react or vue but I'm lucky to have these legacy standards in my skillset as well.

[@robbercarpenter5800]

Again click bait 😩

[@ty.davis3]

It's so frustrating. I looked up the article before watching the video and couldn't find it because it's not even called what it looks like from the thumbnail. The article talks about how HTMX will live on for years, but the thumbnail makes it look like the developers just abandoned the project

[@DerAlbert]

Outlook Web Access, together with XmlHttpRequest was in Year 2000, by Microsoft. Gmail was 2004

[@gearboxworks]

Yeah, but Outlook Web Access sucked. 🤷‍♂️

[@DerAlbert]

@ did not say it was good ;)

[@kizigamer6895]

Does Astro also not solve this comments thing you were saying Astro can help with that complexity

[@threehymns]

I love Astro, but he did mention "introducing a build system" as something that could be avoided with tools jQuery. Personally, I Astro is easily simple enough even with a build system.

[@jwr6796]

I, too, love the idea that I could just leave my car in the driveway for years and all the rust it accumulates will make it drive better.

[@gearboxworks]

No pun intended? 🤔

[@AndrejFidel]

Btw, if you want to drop in a script tag and get superpowers, you can use Vue 😉

[@ET_AYY_LMAO]

imo vue is flawed in other ways than react, but it still ends up putting the webstack on its head, reinventing the wheel. nuxt.js devs think they are hot shit because they finally figured out how to render HTML on the server side ... -ish which then requires a complete rehydration to have any kind of functionality. I wonder how many gigawatt hours of energy is wasted by modern webdevelopment paradigmes every year.

[@gearboxworks]

And all the complexity that comes with it...

[@mattmmilli8287]

Vue stinks. At least with React you are learning pure JS. Not weird Vue only attributes to put on tags and stuff

[@Malix_Labs]

I am very happy with the trending up release of multiple high quality and long videos of yours recently

[@SebastianBenderSkeptic]

I remember when jQuery was a godsend, it saved us from having to deal with all the inconsistent browser implementations. I still use it today. I just dont like how painful it is to debug through all the wrapper functions

[@mcspud]

$.ready() baby

[@DownUpward]

I love to see htmx getting recognition as a viable, low-complexity alternative to React for many use cases!

[@samuelpucat3151]

37:10 You can create polygons in excalidraw by connecting line's starting point with ending point and setting background on it.

[@nightshade427]

you can use htmx and alpinejs (alpinejs is based on vue but takes vue and merges it into the hypermedia itself) or alpinejs and alpineajax (instead of htmx), and go even further to matching client side expectations while still usimg hypermedia based approach

[@Frexuz]

alpine doesnt work if you turn on CSP, we had to move ALL binds from the view to separate js files. even their "CSP-mode" only supports very few things. ZERO expressions (like !-not)

[@akaia_shadowfox]

WASM === bad? Did I just completely miss the point or you're serious about it?

[@_sjoe]

He truly has no idea what he's talking about in this video. Some of his videos are better than others, but this one was a disaster. Not even 10 seconds into the video, he has completely fabricated something (HTML created for printers???) and made a terrible take about something he obviously doesn't understand (WebAssembly). Even many of sponsors (SingleStore, Turso, Prisma, etc.) use WebAssembly...

[@gearboxworks]

@@_sjoe- He is not completely wrong about HTML *originally* being created for printers, if not just a little off base. HTML was originally an application of a much more complex markup language. Any chance you know what that language was? As for WebAssembly, it is a great technology. But it is not a panacea, nor it is a technology that has gained widespread adoption after 8 years in the market. 8 years at web pace is plenty of time for it to have caught fire if it was going to - and there is no guarantee it ever will. IOW, it is a great niche technology, but it is best for a niche. That said, having been doing web dev since 1995, and having built a Chrome plugin using HTMX with a Go backend, I think Theo is mostly spot-on in this video.

[@nikomancer69]

Not sure if you were doing frontend in 2018, but there was a weird moment in Front End land where Web Assembly had a moment in the sun. IT was the hot promising technology. It was unironically billed as the javascript killer. People wrote breathless blogposts about how the fall of Javascript was imminent and how we would be moving towards a beautiful future where we wrote our crud apps in Rust (As everything should be written in Rust). WASM is awesome and opened up a number of valuable use cases on the web. A number of great companies use it prominently in their stack. But if you are comparing it to the community hype, it delivered on none of the things people were really excited about.

[@nextentrepreneur9288]

"the markup language for printers" that's not true, HTML was designed primarily for the web, to display and structure content on web pages.

[@aceman0000099]

I think it was a joke

[@mihirphadnis2]

comically HTMX toppled React in JavaScript Rising starts for #1 spot on Frontend Frameworks. Does that mean It has received wider adoption? Probably not...

[@nikomancer69]

There are two kinds of languages, ones people love and ones people use.

[@designgears]

I suspect HTMX is what inspired Livewire, don't know how I have lived without it!

[@MarkAnkcorn]

What's the app that Theo uses to draw these boxes and such? I keep trying to pause and get a glimpse of the menu bar or app switcher, but can't seem to figure it out

[@jonikyronlahti]

Something I really appreciate in a tech stack and something that is not often talked about is: future proofing. At first a project might seem simple and you might think that (e.g.) HTMX is "good enough", but this has bitten me in the ass SO MANY times... All it requires is one little feature that requires a lot of control in the client (e.g. very complex form) and you wish you had futureproofed a little. It is so awkward to tell your client that the project you have been building the last year needs to be rebuild with some different technology if they want some specific feature(s). The price of dev environment/build complexity is well worth it when I know that whatever the client asks, I can build it.

[@nightshade427]

your rails example is outdated, rails has hotwire (htmx like behavior), and turboframes (template fragments for streaming via hotwire)

[@marty0678]

Before HTMX you could return partial templates no problem and swap out sections of the app easily with Django. That's how things work (and still do work) before HTMX. HTMX just makes it easier with less boilerplate.

[@normanlorrain]

The term I like for this is "dynamic range ". I really like technologies that scale down as well as scale up. Right tool for the job.

[@avneet12284]

Hey Theo, you mentioned a video in which you talk about the BE complexity of UploadThing. Any idea which one it is?

[@Dominaer]

Stopped at 0:10. If you think WA was/is bad, I cannot take your other opinions seriously...

[@cim8097]

Cringe thumbnail again, nah I'm good.

[@robrobob]

The video was actually quite good, but I agree with you about the clickbait thumbnail.

[@TheHronar]

You can maintain the behaviors of the previous defaults while iterating on new defaults. Users can continue to use your application'/library/whatever in the way they know how or they can learn the (hopefully) improved way of doing things.

[@TheHronar]

And if you don't want to maintain that backwards compatibility forever, that's what deprecation is for.

[@TheHronar]

A period of those behaviors co-existing before users are forced to adopt a new way is pretty standard and I think works well.

[@nikjs]

i need htmx to automatcally pickup a value from localstorage (the token) and include it in a header in every api call made by htmx on the page. I don't want to have to add excessive amounts of boilerplate in my htmx tags for the same. Any solution? Once we're logged in, we typically need to use the same token for everything moving forward. It should be straightforward to just declare that stuff somewhere up in .

[@Latent33]

With htmx you should ideally be using cookies as they are far more natural for returning your jwt or other auth token and much more secure than localstorage

[@xpamamadeus]

its really impressive how we write framgents in jsp 15 years ago with jquery and ajax same way,and now its in again

[@bartech101]

Theo: "People think I don't like HTMX but I simply think HMTX sucks"

[@skeleton_craftGaming]

Good SQL is fast the issue is that MySQL isn't a good... I do think that htmx could be the next jQuery [if anything can] Im pretty satisfied with raw dogging jQuery

[@defidelity]

Give htmx a trial, you wouldn't need to raw dog json no more

[@michaelweaver4439]

What the hell are you smoking!? HTML was not created for printers - and if that was an attempt at sarcasm - please don’t - you obviously don’t understand sarcasm.

[@gearboxworks]

Then what was HTML first created for? And before you respond, note that HTML was originally designed as an application of a much more complex markup language used for complex document formatting where semantic information needed to be embedded. Maybe you know what the complex market language was called and what its use-cases were? BTW, if you do not know I am sure ChatGPT will be able to tell you, if you are motivated enough to ask it. And no, the markup language was not designed for printers. But it is not a stretch to say it was, and besides, I doubt a millennial like Theo would know the specifics anyway.

[@nikomancer69]

HTML uses print media as its main metaphor (Page of HTML, Web Page, Document Object, etc.). In some cases this is very helpful when the websites you're building are roughly similar to a book or magazine page. For web applications that have lots of interactivity, the metaphor becomes strained. No idea if this is what Theo meant, but I do think it is right to say that it was essentially designed for printers since it was following the printed page paradigm.

[@allyourfuturebelongstochina]

@@nikomancer69no. Tim designed it to share documents to be viewed on a screen.

[@gradycdenton]

I've been using what I call the "GOTHAM" stack - Go, Templ (templating, works great at composing fragments), Tailwind, HTMX, AlpineJS (js in HTML), and Air & Make for Dx (hot reloading and trigger Templ codegen).

[@jimratliff]

The most-brilliant Theo I’ve seen. This perspective on a historical review of web development is insightful well beyond HTMX (as someone reading the title of the video might be expecting).

[@allyourfuturebelongstochina]

It’s full of misinformation. It sucks because he’s teaching people a false history.

[@zandrrlife]

The future is natural language actually.

[@aceman0000099]

Natural language isn't efficient or precise enough. You would end up having to look at a thesaurus because your font size was "huge" when you meant it to be "gargantuan", or you said "fade" when you meant to say "dissipate"

[@abeldropdout]

Can you please be adding the blog links in the description ?

[@hbobenicio]

As a java dev, I feel that hmtx is just reinventing jsf, which was the way to go until angular/react/spa revolution happened. We've learned from this transition that jsf was really bad because it's stateful to the point it hurts scalability. How hmtx differs from this issue? Does it makes our backends just render html and control front events or is it a full package of stateful problems? Can we continue to stay stateless when using htmx?

[@deatho0ne587]

Love what you are saying about jQuery, yes it is on 75% but what of those are still being maintained, used, and being used by how many users. HTMX is great for what it needs and FrontEnd Frameworks (react, angular, ...)

[@lxn7404]

Something you didn't mention: as a rule of thumb, vulnerabilities grows proportional to complexity

[@Junky1425]

I'm a robotics/AR guy who works mostly there and writes applications for that to move, etc. So I'm a backend guy and i love my backend. I had also a talk with a bit more frontend guy and he said hey use react you can do everything with that, which i need for a web application which I write in my freetime. But as a C#/C/C++ guy i hate JS overall. So I went with the stack: Django (Python) for the backend, with db. And HTML, TailwindCSS, HTMX for the frontend. Yes i have also some vanilla JS in my webpage to do some dynamic stuff but that is chatgpt generated simple code like hide elements with classes and show them again. or create html and insert it to a specific place. For me personally that is more then enough frontend :D And I don't want to dig into Angular/React/Vue and all of that, to make some dynamic things like a search or comment (I do that without HTMX :D and reload the page completely). But currently i was able to do everything which i want to do with HTMX and VanillaJS. So perfect stack for me :D

[@MadsterV]

So with HTMx if I find a layout bug and I need to move some divs around, I have to update the backend? yikes, no go.

[@ankitsanghi]

Not really. You’d just move the divs around in the HTML file you’re changing. No need to update the backend

[@defidelity]

HTMX doesn't determine anything in your backend, it only helps you send requests and determine where the response to that request goes.

[@MadsterV]

yeah I meant UI changes inside the component. The layout comes rendered from the server, doesn't it?

[@AbegazNap]

I don't usually agree with Theo, but he's largely correct with this.

[@bihan1429]

Nobody cares if you agree or not

[@meanguitar]

That's a fair analysis, like I'm working on a browser based DAW so I am not looking at htmx. I'm looking at preact because I want it to be small and fast but be conceptually compatable with react.

[@ReadJohn1421]

As a father shows compassion to his children, so the Lord shows compassion to those who fear him.

[@jasonbatchelor4604]

How much of that "straight line" increase in user expectations is real, and how much is due to marketing hype? I find there's a definite gap between what users actually want or need vs. what marketing people (whose money is tied directly to getting users to pay for things that may or may not yet exist) are pitching.

[@4115steve]

I thought the HTMX sucks video was sarcasm, but I didn't know how to decipher some of technicalities, and your acting was really good. Like I was almost worried that you might be serious LOL

[@virtual5754]

Should we use react for static blog? As soon as astro makes proper runtime revalidation - no. Until then - yes, nextjs

[@JD-yz8cn]

It was possible to do the things you mentioned before AJAX or JSON with script injection. Most people just weren't doing it.

[@nikomancer69]

It's clearly a pretty simplified history of web dev. Not even one mention of Flash or Java Applets in there.

[@gentlemanbirdlake]

what if you need to render localized versions of the data? timezone datetime or number formatting with htmx?

[@gearboxworks]

HTMX will handle that brilliantly. It can do anything a backend can do, including marshaling client information from the front-end.

[@mohammedmaqbol9397]

is that markojs in 0:09 ?

[@alekseykostyuk3806]

There is a solution, which isn't a Framwork - microfrontends. Using just a bit of react to implement those comments section might be ok if it doesn't require learning all the tooling around. Just do not store that state on the client ) btw, take a look to symfony live components.

[@4115steve]

what would it be like making a zig web app/3d game with htmx, websockets, wasi and wasm?

[@antonf.9278]

Once you load wasm you probably won't have get much use out of htmx. The whole point of htmx is to keep complexity down, while wasm is a powerful but complex tool.

[@jeroenvanattenhoven6202]

What drawing app is this?

[@Shekelvin4]

waiting for answer

[@nikomancer69]

Excalidraw.

[@Darbokst]

what would I use with HTMX/HTML to get info from a db like supabase?

[@sobanya_228]

Some sites might just be importing jQuery like lodash, not necessarily basing their entire rendering on manually using jQuery

[@succatash]

Isn't singletore founded by the neondb guy

[@leonkernan]

Videos like this remind me how old I am...

[@SapioiT]

Why do we not simply get alternatives to HTML and CSS, instead of getting more and more frameworks which mostly solve the same things in different ways? Especially since we're rapidly approaching the level of AR (augmented reality), where people are going to expect 3D websites and apps.

[@Ligma_Shlong]

no one wants 3d websites

[@economicist2011]

@@Ligma_Shlong Oh come now, who wouldn't want shopping for a new GPU to be like the final showdown scene from "Hackers" ?

[@gearboxworks]

Well, HTMX is just extension of HTML implementing the "missing parts," with a goal to get HTML to adopt its features so that it can just go away. So, you wish for it and HTMX grants it. 🤷‍♂️

[@gearboxworks]

Well, HTMX is just extension of HTML implementing the "missing parts," with a goal to get HTML to adopt its features so that it can just go away. So, you wish for it and HTMX grants it. 🤷‍♂️

[@nikomancer69]

We don't get alternatives to HTML and CSS because, unfortunately, the expectation for the web browser is that everything is backwards compatible and that dark triad of technology (and also kinda sorta web assembly) are the primitives for the web browser. It's akin to asking why we don't get alternatives to machine code and instead just build interpreters that mostly make it easier in different ways.

[@KriLL325783]

Anyone knows what app he's using for that blackboard at 11min?

[@gearboxworks]

Excalidraw

[@nikomancer69]

Excalidraw with dark mode turned on. Give it a shot, it's neat.

[@owenwexler7214]

33:00 prototyping a Go backend for my CRUD app and for the routes I’ve written so far I’ve knocked 20-25ms off response times vs Express. If that translates to prod that’s definitely worth it.

[@zeocamo]

the xml was so bad, that it die in 2005 but no one could stop using it as it was on all the sites. we try any things to replace it, but the only thing that work for all the backends was json

[@arytiwa4351]

I think the Wasm part was a mistake, ig you meant react right ?😅

[@maimee1]

Didn't Vue also have petite Vue?

[@hentype]

I remember that brief time when vue and bulma were being promoted. Tailwind eventually won but it was a fascinating era when I started learning more of these js frameworks outside jquery.

[@hafizmuhammadahmadfareed]

Please make a full video on SingleStore and how to use it in a real life project. Please please love from Pakistan.

[@ivanmaglica264]

Strange, I used XMR in 2004 to update parts of my app, and I never used XML even back then. We used JSON even back then.

[@yuryzhuravlev2312]

HTMX it's illusion, yes it's only a small extra complexity on frontend BUT now you should do all this routing, complex hierarchy of templates on backend. If you need render only part of this template it's not trivial or manage it's properly.

[@LadyEmilyNyx]

I still can't see any niche that this fits into that isn't better served by JS/jQuery. Especially since you still have to write a separate backend.

[@Foolhardy1337]

Hey Theo, how would you compare PHP Laravel Blade to htmx and the graphs you made around 25:00. Where would you lay such tech like Blade? I take it back, you explained nicely near the end, tnx

[@abdelhaktamraoui2562]

Htmx has more capabilites than blade, more like livewire vs htmx

[@Foolhardy1337]

@@abdelhaktamraoui2562 Yeah, I'm thinking to suggest exploring htmx instead of Blade. Saw briefly 1 post about Laravel with htmx, seems like a good solution. Last project I did, we've hit the Blade ceiling proceeded with heavy JS and inevitably converted to multi-page React. Seems like htmx could've saved the React conversion step only if we knew in the beginning (it is a medium sized project/complexity)

[@gearboxworks]

It is not an EITHER/OR, it is an AND. Use Blade as a template to format the HTML that HTMX serves up to the browser. HTMX is simple. 90% of what is does is add PUT, PATCH, and DELETE methods to forms, allow all elements to trigger those methods as well as GET and POST, and allow a developer to specify the target element that gets the HTML that is generated by the response from one of those methods. Basically the "missing features" of HTML. When working in HTMX you almost never write any JS with it, you add behaviors as attributes on HTML elements. If you need to write JS when working with HTMX you use something like AlpineJS instead. So any backend technology will continue to work exactly as it did when serving HTML content without HTMX.

[@FromThePirabay]

@Theo Are u sure that Gmail was the first AJAX app? If i remember correctly it was Outlook and Microsoft build that feature into IE for that app in mind. Also AJAx was not indented to request new HTML but XML.

[@bioburden]

I remember digg pushing it a lot too

[@ErikHazington]

en.m.wikipedia.org/wiki/Ajax_(programming)#History It seems that it was developed by Microsoft's Outlook web team as an ActiveX component for IE5, but Google maps and gmail were the first web services using AJAX cross browser compatible. By the way, first dynamic web apps based on frames already existed before 1999.

[@MarcStober]

@@ErikHazingtonthat’s what I remember too. Google Maps was the killer app of AJAX. I remember being in my office working on VB6 when someone showed me Google maps and we were like, I didn’t know you could do that with a web app! I guess if you worked for a company that used had a particular Exchange server configuration or had early access to Gmail when it was invite-only you might have used AJAX there first.

[@Saitir942]

Yeah, the whole history of ajax is just laughably wrong. People looking back from today don't even recall that chrome didn't even exist when it came into being (2000 vs 2008).Regardless of the shady way it got there, and as problematic as it was, people shouting about standards didn't matter in that period (2000-2008) because there wasn't any practical competition to Internet Explorer. Did it suck and/or stifle innovation. Sure. But reality is what it is. You would have no choice but to throw people off teams if they came out with 'I only write standards compliant code', because as noble as it is, if 70%+ of my user base is using IE, it better damned well work on IE!

[@cantormarcstober]

@@Saitir942 And now Chrome is the new IE!

[@javierrodriguez4218]

13:50 source: trust me bro

[@_albertlol]

His whole point doesn't make sense to me. I would bet that at least 80% of websites still haven't bothered to switch to any of the new hyped web technologies and just stayed on LAMP.

[@nikomancer69]

@@_albertlol I'm not sure what your point is. Of course there will be lots of incumbent tech stacks. That's is normal. But what I think he's getting at is like, in the past, if you wanted to do online chat in a browser, you had IRC. IRC was super simple in terms of UI. Now, when I think of chat in a web browser, I think of Discord or Slack. Discord has a whole lot of stateful stuff going on in its UI. The IRC chats are still there. I still even use them from time to time. But the next company that wants to release something they want to be *the* next big chat app will be competing against Discord in terms of user expectations and will need to make meaningful improvements. That's the complexity arms race. But those meaningful improvements will be easier because the technologies that enabled them proliferate further and become standard patterns and abstractions for building apps. Component architecture in JS front end frameworks is a good example of this. For companies or apps not caught in that complexity arms race, there's not really much need to pay attention to all of this stuff.

[@jmkacz]

Can someone post the tldr?

[@xpertdbx]

classic Carson essay

[@godonholiday]

Not sure about the complexity graph. Apps had gotten or were getting so complex that we needed backbone.js and likes just so we could wrangle the code. So complexity wasn’t low. Less than now sure, but not basic.

[@IAMDean]

The best type of Theo video

[@thegrumpydeveloper]

Got excited about singlestore but drizzle says we can’t use order by and limit together 😅😢wat? Seems like possible by using count or by adding a sort key but still surprising. Would like to see a more deep dive into single store.

[@agentminecraft9986]

Babe I get to choose the movie tonight

[@sprobertson]

Once it gets into the template fragment stuff I'd rather just use React which feels a lot more procedural and less magic

[@AbstruseJoker]

Who is sending 2gb of json to the frontend?

[@Protoscribe]

I think the new generation of coders mostly miss the fundamentals and don't understand how the world of the web actually works. Heck if you are a two decade plus PHP developer (I moved to JS ecosystem in tandem) you'll remember the days of templating with PHP which was using HTML. HTMX is literally just the same with JS. I believe more people will start to enjoy HTMX more and more if they understand the fundaments. I love Sveltekit/Svelte, but I find myself turning more and more to HTMX, heck I even tried unpoly and markojs just to be sure with HTMX for a couple projects...

[@ky3ow]

As a "new generation"(started learning like 4 years ago) yeah, I did miss fundamentals, to the point that I didn't know what pre-rendering react is, even though it's so simple, just generating html at build time I feel this is because bootcamps teach you how to do something with html/css/js/frameworks but does not teach how web works as a platform

[@wrux]

I think it's better to say AlpineJS is the new jQuery. HTMX doesn't handle so many things that jQuery was often used for

[@gearboxworks]

You are talking their analogy too specifically. What Carson Gross meant by being the new jQuery is that, like jQuery, they want HTMX to be workable 25 years into the future and beyond, like jQuery has been. I know this because I've seen presentations given about HTMX on exactly this point. Search for something like "Building the 100 years website with HTMX."

[@wrux]

@@gearboxworks And you are assuming that Alpine isn't expected to work for 25 years?

[@gearboxworks]

@@wrux- No, I am making no such assumption, in either direction. I am addressing why Carson Gross saying they want HTMX to be the new jQuery is related to a concern about longevity and not about its JavaScript-ness, and that was the context of the post that Theo reviewed. And whether AplineJS can be used in 25 years or not is orthogonal to that point as more than one thing can be true.

[@gearboxworks]

@@wrux- Said another way, if you were making your statement without any context, I would agree with you. But since you were making it in context of the video review of a blog post that stated the aspiration for HTMX is for it to have the longevity of jQuery then your statement ignores the context in which you stated it.

[@t3dotgg]

Except that the creator of Alpine has an ego like no other. He constantly drives contributors and community members out for daring to have opinions about it. Oh - and nobody actually uses it lol

[@matthewdolman]

I think you are really missing the mark on your understanding of how widespread the use of jquery is these days. I build integrations for all major frontend frameworks which include react and jquery and the use of jquery is at least 10x of that of react, and we have major uk customers. I'm not saying it's good, just saying it's a fact of life.

[@ImadEddineTerraf-ep8ky]

Can you do a video on React to Next migration?

[@brydetendon3704]

not quite sure if react really made it "less difficult to build complex apps"

[@pokefreak2112]

It popularized component architecture for the frontend which definitely made things more scalable, jsx also cut down on boilerplate and made tooling better. A lot of the good was just misattributed to the vdom and reactive programming which is still a janky mess that keeps being reinvented every other year

[@baddrivers759]

AJAX (in the form of XMLHTTP, which later became XMLHttpRequest) was first created and implemented in Microsoft's Outlook Web Access. Yes, Microsoft invented the concept of AJAX. GMail didn't even exist until 2004 (5 years later). If you are going to quote history (in your great videos), at lease get the history correct (a simple Wikipedia search would help, not that I needed to, as I was there using it in 1999).

[@JLarky]

Html for printers? You are thinking about PostScript

[@defidelity]

Well,at least im sure that 89% of backend devs are pleased with HTMX

[@krumbergify]

Programming languages, frameworks and protocols are just tools. They are only good or bad if you know what you want to achieve, using certain resources in a certain timespan. The human side also plays a huge part. If your team already knows framework X, then X might be the ”best tool for the job” although framework Y might have some technical advantages and would have been the ”best tool” if your team didn’t know either X or Y.

[@Malix_Labs]

@@krumbergify tools can be objectively criticized. This is why they are still being constantly improved

[@krumbergify]

@@Malix_Labs ”Time” and your current software capital are key here. What timespan are we looking at? Let’s say that you have a messy codebase in C and you prefer to have it in Rust. Rewriting it in Rust would take many years and it would most likely yield a better codebase, but you need to deliver features here and now using a team of people who know C much better than Rust.

[@chakritlikitkhajorn8730]

@@Malix_Labsif you want to criticize anything objectively, you need to have an objective first. And many programmer seems to think their objective is everyone else objective. Like, this language is the most performant (and that is what I passionate about so that’s my objective) therefore, this is the best language. Well, other factor like maintainability matters as well. There are circumstances that performance matters the most but not always. There are times that maintainability matters the most, but not always. Or, I am really productive in this language therefore we all should use this. My teammate struggle? Skill issues. Many programmer seems to criticize every technology without aware that their chosen objective criteria really stem from subjective passion of themselves.

[@Malix_Labs]

​@@chakritlikitkhajorn8730 > many programmer seems to think their objective is everyone else objective By definition, this is true You are probably mistaking it with subjective

[@gearboxworks]

All too often though a team does not throughly evaluate all relevant criteria before making a choice. Chances are that most teams today will get it wrong it is in important for the website to be maintainable for decades unless the sponsor of the project makes that the primary goal of the project (think Jimmy Wales and Wikipedia.)

[@razdingz]

bro ur sponsor vids always good choices , make it easy for us low iq people to stay up to date

[@jurgenkranenburg1309]

jquery is still awesome though when having to write vanilla-ish javascript. I still use it when writing laravel apps without a javascript front end framework

[@devpitch]

All tech is created for a purpose. I even think that MAUI and Flutter has a future.

[@Vladhin]

I disagree on users expectations part. I would say many many users expect to get information from the internet and expect those informations to be accessible - that's it. Single page app? Why? Most used websites in 2024 were google search, youtube, facebook, instagram, whatsapp, x, wikipedia, chatgpt, reddit, amazon - exept for fb, yt and instagram these are not most complex websites and also they don't have to be that complex. Users are not demanding it, the companies do raise the bar for themselves to attract more and more users but it's not an expectation, it's business. Thin users pool is expecting much like professional creators but the rest of us could deal with refreshing - no problem.

[@davidbates3353]

Talking about JQuery and HTMLX makes me I miss MS Access because I think it's great for similar reasons. Okay, please hear me out... Back in the late nineties, I could use MS Access to whip up an application which solved 80% of applications needed in a small/mediumish business. Good database modelling and querying tools, automatic report generation and a flexible UI builder, and you could always go down to VBA if you needed to do something a bit more special. I wish I had a web-equivalent.

[@gearboxworks]

I get your point and agree. OTOH, I do have to contrast the two. I stared as a database developer in 1987 so know a lot about desktop databases. However, HTMX is actually adding simple extensions to HTML by that rights should already have been part of HTML. And the HTMX team are trying to get HTML to adopt them so HTMX won't be need. MSAccess OTOH what an outrageous complex solution that made architectural decisions that resulted in it being an evolutionary dead-end. Also, once you got to the 80% with Access, you really could go no further without basically rewriting your app in VB6 or similar.

[@davidbates3353]

@gearboxworks There ate difference, sure, but there’s a very similar attitude and spirit to them. For certain categories of application (crucial point) it was all you needed. If you were good with VBA there wasn’t much you couldn’t do. All it really needed was version control and live web-enablement.

[@gearboxworks]

@@davidbates3353 - Seems the mists of time have allowed you to romanticize MS Access and forget so many of its limitations, reasons why people stopped using it, and why Microsoft deemphasized it. Besides version control and live web-enablement, no amount of VBA could get around these issues: - A 2GB database limit. - Could not handle much more than 10-20 concurrent users - Often corrupted databases when you pushed it too hard with complex queries and/or a large transaction volumes - Building against SQL Server added significant complexity - No VBA support for interfaces or inheritance (the latter is not a big deal in hindsight, but it was at the time) - Not architected for collaborative development, not for multi-developer projects, and especially not for cross-organization development like how open-source is done today - Deployments were a nightmare, especially updating existing applications. - The forms designer was very limited. - Custom controls were supported though with a myriad of problems: -- Few vendors offered any, and developing them required C expertise -- Compatibility issues across different Access versions and 32-bit vs 64-bit -- Controls needed to be installed on every user's machine -- Dependencies made for complex deployment w/controls needed to be installed on every user's machine - Hard to integrate with enterprise auth and security systems - Very limited options for testing and CI pipelines - And finally, no support on Mac or Linux or mobile. All in all, MSAccess was an evolutionary dead-end, killed by any lack of foresight by its designers. BTW, I ran a mail order retailer in the 90's named VBxtras that sold tools and libraries for Visual Basic, and we used MS Access internally and were VERY aware of the limitations MSAccess had that causes our customers to move away from it in droves.

[@aleksandrpavlov3728]

FoxPro, Delphi, there was a lot of things that were efficient and enjoyable and seemed right, but then died. There were reasons, not all of them good reasons, but there were pieces missing.

[@davidbates3353]

I was never a fan of FoxPro, but Delphi effectively became C#

[@rodemka]

You should try Unpoly vs htmx

[@owenwexler7214]

9:43 ZHUH-SOWWH

[@nm6x]

My I don’t want to put effort but I want to do pretty things stack currently is: Pico CSS, AlpineJS and HTMX.