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?
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.
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.
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.
@@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.
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.
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.
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 .
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.
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!
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.
@@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.
"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
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
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.
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.
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.
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.
@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).
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
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.
@@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.*
@@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.
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.
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.
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.
@@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!
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.
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
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.
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
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.
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.
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.
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
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).
comically HTMX toppled React in JavaScript Rising starts for #1 spot on Frontend Frameworks. Does that mean It has received wider adoption? Probably not...
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
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.
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...
@@_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.
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.
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.
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
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 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)
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.
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.
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.
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.
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. 🤷♂️
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. 🤷♂️
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.
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.
@@_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.
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 ”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.
@@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.
@@chakritlikitkhajorn8730 > many programmer seems to think their objective is everyone else objective By definition, this is true You are probably mistaking it with subjective
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.)
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
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.
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...
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
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- 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.
@@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.
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
I'll fight you. While you are looking in the opposite direction - comparing the JavaScript-ness of Alpine to jQuery - I'll knock you out with a right cross you won't see coming - comparing HTMX's potential for longevity to that jQuery has had.
@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.
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.
@@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.
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!
I really want to know more about it because the goodness or badness of WASM is entirely dependent on the terms of success. It's a niche tool that opened up a lot of neat and profitable use cases in the web and let devs build some really cool applications. WASM is good. It was heralded as the imminent end of JavaScript by the web dev community some 8 years ago and a soon-to-be pillar of web development. We were promised that the future of web development would be writing things in Rust (this was 2018 which was the era of rewriting in Rust for shits and giggles). WASM delivered on none of that. WASM is bad. I personally think the case that WASM is good is more compelling but if you're super plugged in to the developer influencer community, I think it's easy to see why "WASM bad" also makes a lot of sense.
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
I think the best measure is how many devs are CHOOSING Jquery for NEW sites. If a popular framework like WP uses it and a bunch of nobodies have it as a dependency without knowing it or having a choice, then it is like saying gasoline cars are the most popular because the most people drive them. Most cars don't give you a choice though.
To be honest jQuery is totally fine even today for simple websites, not everything should be a dockerized SPA running react+next, on the contrary probably onl around one out of a hundred websites running next.js really benefits from the complexity. WP is FINE for most usecases, even static HTML files would be fine for a lot of websites that are currently over engineered "SPAs"... Like 99 out of 100 SPAs are just static websites these days... I work at a media outlet and for some reason, what we serve to the end user is a SSR generated site that then redhydrates only to bring some ads into the page, all that complexity the frontend has, just to serve something that would have been a 100% static website just 5 years ago, to be honest I think its an expensive mess, but I work the backend so I dont really care.
But using jQuery on NEW websites was not the point. The point was, websites originally built >25 years ago with jQuery and that are still maintained still work. Now compare that to how many websites that are still being maintained are using MooTools? Sure, most will pick something different today but how many of those frameworks developers CHOOSE to build new websites with today will be able to be maintained 25 years FROM now? It is a safe bet that none of the top web frameworks today will meet that challenge, but we are pretty sure those built with HTMX will.
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.
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.
@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.
@@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.
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.
I strongly disagree with your comments regarding "stability as a feature". I love stability as a feature. When you talk about making a breaking change because you're anticipating most of your users will be future users, it makes sense to take the pain early, make the change and have the future users benefit from breaking stuff early. However, in your example, you are using a single version change "2.0" as an example. What happens when you have multiple versions per year, all with breaking changes that require devs to rewrite significant portions of their application every time? You also have multiple frameworks for different apps and different frontends and backends, each with their own "paradigm shifting, out of box" breaking changes that require significant rewrites. You're not just breaking stuff once, you're breaking stuff ALL THE TIME! This was my experience with the JS ecosystem and one of my biggest pain points. It's not just the time it takes the dev to do the rewrites, it's the opportunity cost to the business of features the dev COULD have been working on instead of rewriting existing features that already work just fine. There is also the salaries business has to pay the dev to do the updates and rewrites that cost businesses real money and add basically zero additional benefit in terms of business outputs. Having stability as a feature means that devs can focus on adding features to the software, fixing bugs, improving UI and UX, ultimately enhancing the value of the software to the business. I love stability as a feature and I wish the JS world would do more of that.
SingleStore for me is pointless. They open source parts but not the whole. This by itself is a show stopper for me and is the exact same reason I will not even touch datomic. I get why they do it $$$. But when it comes to your data you should never be stored in a proprietary format. I'm all for people making money, I'm not for my critical infrastructure being under a commercialized "open source" product. Not to mention 9/10 times mongodb isn't needed for the problems people use it for. It's just used because people are to lazy to actually make their database schema properly (sql and dbms systems are stupid easy)
You seem to have decided that htmx is not a good fit for complex apps. But I would argue that it's actually a great fit because it really simplifies a lot of complexity for the CRUD part of our apps. This would in turn give us a lot more time to work on the complex parts. Webcomponents are not ergonomic to author but there will surely be other solutions that use htmx as a platform and build on top of it to achieve complex interactions. React on the other hand is moving towards more and more complex concepts. I think we're reaching an inflection point where react and the tooling are too complex. This might be because of confusing concepts in the newer versions and Vercel's take over of React. There will definitely be a tool which seamlessly brings in complex interactivity over htmx and everyone would be like why didn't we think about this so long
You mean "Multiplying Viral Complexity?" That MVC? MVC has proven to be an over architecture that has sadly lived on because of the vested interests of the framework developers built around MVC and all their acolytes who have adopted those frameworks but don't get out to see that there are better approaches. #jmtcw
@@t3dotggPerception vs reality. Clearly this commenter is just wrong. Regardless, great video, been using htmx in production for numerous sites for years now. It's so useful when you don't need to go down the React route (even though I really enjoy React)
Im a very picky about who I drop a like for. Im the kind of person that wont even text you a lol unless I literrally lol'd. I gave you a like cause although I knew you were smart already, I didnt know until this point just HOW smart you are. Copping to you pushing REACT because of your own perrogative honestly made me look at you differently. I admire you sir. You earned my like and subscribe
I'm one of the 75% jquery users, but I only use it for $.ajax / $.get / $.post. Though I've been slowly converting to fetch() calls if I remember to, but jquery is so engrained in muscle memory
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?
Ah finally! I was looking for someone raging in the comments.
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.
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.
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.
@@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.
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.
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.
it was a joke... relax
@@l10nbit ah okay i think i understand now. thanks!
@@l10nbit wait, so you're a printer?
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 .
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.
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!
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.
@@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.
"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
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
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.
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.
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.
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.
@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).
@colin7452 It's mostly in the request count and cumulative latency. And the being fucking shit of course, which can't be excused.
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
Was going to say, frames or s was the common answer.
1px images also got a bit of a workout.
Yeah! We also used JSON long before it was called JSON using eval() to parse object notation...
yep, the eval hell was real and painful 😂
Theo is a millennial, what da ya expect?
But seriously, bringing up frames is really just pendency for the topic of this video. 🤷♂️
The point is that this is not how software evolves, and it's relevant because the topic is HTMs' stance on precisely that point.
Outlook Web Access, together with XmlHttpRequest was in Year 2000, by Microsoft. Gmail was 2004
Yeah, but Outlook Web Access sucked. 🤷♂️
@ did not say it was good ;)
4:15 Theo, you are underestimating how popular jQuery is, literally Wikipedia and Amazon use it as of today
pretty sure even this RUclips page uses it somewhere (since I can totally do `$('video').playbackSpeed = 2;` from the console).
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.
@@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.*
@@comradepeter87Chrome DevTools support $ as a shorthand for document.querySelector(), it’s not jQuery though
@@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.
Does Astro also not solve this comments thing you were saying
Astro can help with that complexity
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.
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.
But damn was it fun learning and building websites with Actionscript.
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.
@@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!
I am very happy with the trending up release of multiple high quality and long videos of yours recently
Kudos to HTMX devs for reviving HATEOAS
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.
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
Btw, if you want to drop in a script tag and get superpowers, you can use Vue 😉
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.
And all the complexity that comes with it...
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
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.
No pun intended? 🤔
The future is natural language actually.
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.
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.
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.
@@nikomancer69no. Tim designed it to share documents to be viewed on a screen.
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
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).
It’s full of misinformation. It sucks because he’s teaching people a false history.
comically HTMX toppled React in JavaScript Rising starts for #1 spot on Frontend Frameworks. Does that mean It has received wider adoption? Probably not...
There are two kinds of languages, ones people love and ones people use.
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
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.
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.
And if you don't want to maintain that backwards compatibility forever, that's what deprecation is for.
A period of those behaviors co-existing before users are forced to adopt a new way is pretty standard and I think works well.
its really impressive how we write framgents in jsp 15 years ago with jquery and ajax same way,and now its in again
what would I use with HTMX/HTML to get info from a db like supabase?
Can you please be adding the blog links in the description ?
what if you need to render localized versions of the data? timezone datetime or number formatting with htmx?
HTMX will handle that brilliantly. It can do anything a backend can do, including marshaling client information from the front-end.
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.
Not really. You’d just move the divs around in the HTML file you’re changing. No need to update the backend
Isn't singletore founded by the neondb guy
The best type of Theo video
Should we use react for static blog? As soon as astro makes proper runtime revalidation - no. Until then - yes, nextjs
what would it be like making a zig web app/3d game with htmx, websockets, wasi and wasm?
WASM === bad? Did I just completely miss the point or you're serious about it?
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...
@@_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.
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.
I don't usually agree with Theo, but he's largely correct with this.
Didn't Vue also have petite Vue?
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.
I suspect HTMX is what inspired Livewire, don't know how I have lived without it!
It was possible to do the things you mentioned before AJAX or JSON with script injection. Most people just weren't doing it.
It's clearly a pretty simplified history of web dev. Not even one mention of Flash or Java Applets in there.
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
Some sites might just be importing jQuery like lodash, not necessarily basing their entire rendering on manually using jQuery
I think the Wasm part was a mistake, ig you meant react right ?😅
Anyone knows what app he's using for that blackboard at 11min?
Excalidraw
Excalidraw with dark mode turned on. Give it a shot, it's neat.
Videos like this remind me how old I am...
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
Htmx has more capabilites than blade, more like livewire vs htmx
@@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)
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.
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.
Please make a full video on SingleStore and how to use it in a real life project.
Please please love from Pakistan.
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.
What drawing app is this?
waiting for answer
Excalidraw.
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.
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.
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.
no one wants 3d websites
@@Ligma_Shlong Oh come now, who wouldn't want shopping for a new GPU to be like the final showdown scene from "Hackers" ?
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. 🤷♂️
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. 🤷♂️
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.
Theo: "People think I don't like HTMX but I simply think HMTX sucks"
13:50 source: trust me bro
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.
@@_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.
classic Carson essay
Html for printers? You are thinking about PostScript
Again click bait 😩
"the markup language for printers" that's not true, HTML was designed primarily for the web, to display and structure content on web pages.
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.
@@krumbergify tools can be objectively criticized. This is why they are still being constantly improved
@@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.
@@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.
@@chakritlikitkhajorn8730
> many programmer seems to think their objective is everyone else objective
By definition, this is true
You are probably mistaking it with subjective
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.)
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
Once it gets into the template fragment stuff I'd rather just use React which feels a lot more procedural and less magic
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.
bro ur sponsor vids always good choices , make it easy for us low iq people to stay up to date
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...
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
Who is sending 2gb of json to the frontend?
You should try Unpoly vs htmx
All tech is created for a purpose. I even think that MAUI and Flutter has a future.
37:33 unless you're Google
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
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."
@@gearboxworks And you are assuming that Alpine isn't expected to work for 25 years?
@@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.
@@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.
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
Alpine is the new jQuery, fight me.
I'll fight you.
While you are looking in the opposite direction - comparing the JavaScript-ness of Alpine to jQuery - I'll knock you out with a right cross you won't see coming - comparing HTMX's potential for longevity to that jQuery has had.
Cringe thumbnail again, nah I'm good.
The video was actually quite good, but I agree with you about the clickbait thumbnail.
your rails example is outdated, rails has hotwire (htmx like behavior), and turboframes (template fragments for streaming via hotwire)
2:50 Totally agree with you
@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.
I remember digg pushing it a lot too
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.
@@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.
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!
@@Saitir942 And now Chrome is the new IE!
did you just call wasm bad?!
I really want to know more about it because the goodness or badness of WASM is entirely dependent on the terms of success.
It's a niche tool that opened up a lot of neat and profitable use cases in the web and let devs build some really cool applications. WASM is good.
It was heralded as the imminent end of JavaScript by the web dev community some 8 years ago and a soon-to-be pillar of web development. We were promised that the future of web development would be writing things in Rust (this was 2018 which was the era of rewriting in Rust for shits and giggles). WASM delivered on none of that. WASM is bad.
I personally think the case that WASM is good is more compelling but if you're super plugged in to the developer influencer community, I think it's easy to see why "WASM bad" also makes a lot of sense.
not quite sure if react really made it "less difficult to build complex apps"
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
I think the best measure is how many devs are CHOOSING Jquery for NEW sites. If a popular framework like WP uses it and a bunch of nobodies have it as a dependency without knowing it or having a choice, then it is like saying gasoline cars are the most popular because the most people drive them. Most cars don't give you a choice though.
To be honest jQuery is totally fine even today for simple websites, not everything should be a dockerized SPA running react+next, on the contrary probably onl around one out of a hundred websites running next.js really benefits from the complexity. WP is FINE for most usecases, even static HTML files would be fine for a lot of websites that are currently over engineered "SPAs"... Like 99 out of 100 SPAs are just static websites these days... I work at a media outlet and for some reason, what we serve to the end user is a SSR generated site that then redhydrates only to bring some ads into the page, all that complexity the frontend has, just to serve something that would have been a 100% static website just 5 years ago, to be honest I think its an expensive mess, but I work the backend so I dont really care.
But using jQuery on NEW websites was not the point. The point was, websites originally built >25 years ago with jQuery and that are still maintained still work. Now compare that to how many websites that are still being maintained are using MooTools?
Sure, most will pick something different today but how many of those frameworks developers CHOOSE to build new websites with today will be able to be maintained 25 years FROM now? It is a safe bet that none of the top web frameworks today will meet that challenge, but we are pretty sure those built with HTMX will.
Lol i did lazy load on scroll and pagination in jquery many times
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.
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.
@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.
@@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.
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.
I was never a fan of FoxPro, but Delphi effectively became C#
Htmx is what HTML5 should have been...
Webflow uses jQuery
Hm. But this is the same thing that Rails 8 does. And you've been, I would say, cruel against the Rails approach.
I strongly disagree with your comments regarding "stability as a feature". I love stability as a feature.
When you talk about making a breaking change because you're anticipating most of your users will be future users, it makes sense to take the pain early, make the change and have the future users benefit from breaking stuff early.
However, in your example, you are using a single version change "2.0" as an example. What happens when you have multiple versions per year, all with breaking changes that require devs to rewrite significant portions of their application every time? You also have multiple frameworks for different apps and different frontends and backends, each with their own "paradigm shifting, out of box" breaking changes that require significant rewrites. You're not just breaking stuff once, you're breaking stuff ALL THE TIME!
This was my experience with the JS ecosystem and one of my biggest pain points. It's not just the time it takes the dev to do the rewrites, it's the opportunity cost to the business of features the dev COULD have been working on instead of rewriting existing features that already work just fine. There is also the salaries business has to pay the dev to do the updates and rewrites that cost businesses real money and add basically zero additional benefit in terms of business outputs.
Having stability as a feature means that devs can focus on adding features to the software, fixing bugs, improving UI and UX, ultimately enhancing the value of the software to the business. I love stability as a feature and I wish the JS world would do more of that.
SingleStore for me is pointless. They open source parts but not the whole. This by itself is a show stopper for me and is the exact same reason I will not even touch datomic. I get why they do it $$$. But when it comes to your data you should never be stored in a proprietary format. I'm all for people making money, I'm not for my critical infrastructure being under a commercialized "open source" product. Not to mention 9/10 times mongodb isn't needed for the problems people use it for. It's just used because people are to lazy to actually make their database schema properly (sql and dbms systems are stupid easy)
Imagine debugging htmx
You seem to have decided that htmx is not a good fit for complex apps. But I would argue that it's actually a great fit because it really simplifies a lot of complexity for the CRUD part of our apps. This would in turn give us a lot more time to work on the complex parts. Webcomponents are not ergonomic to author but there will surely be other solutions that use htmx as a platform and build on top of it to achieve complex interactions.
React on the other hand is moving towards more and more complex concepts.
I think we're reaching an inflection point where react and the tooling are too complex. This might be because of confusing concepts in the newer versions and Vercel's take over of React. There will definitely be a tool which seamlessly brings in complex interactivity over htmx and everyone would be like why didn't we think about this so long
Htmx is the perfect for mvc web.
MVC is deprecated, we use Components now
@@Malix_Labs Uh... you are aware they aren't mutually exclusive... right?
@@CottidaeSEAHe means MVVM
@@alex-costantino MVVM is indeed mutually exclusive.
You mean "Multiplying Viral Complexity?" That MVC?
MVC has proven to be an over architecture that has sadly lived on because of the vested interests of the framework developers built around MVC and all their acolytes who have adopted those frameworks but don't get out to see that there are better approaches. #jmtcw
:D
Look like you get sponsorship 1st and then decide to make video
I have over 40 videos recorded already and I record them all live? What are you trying to say here lol
@@t3dotggPerception vs reality. Clearly this commenter is just wrong. Regardless, great video, been using htmx in production for numerous sites for years now. It's so useful when you don't need to go down the React route (even though I really enjoy React)
Looks like you are new here..
I don't usually agree with Theo.... no change today !
Im a very picky about who I drop a like for. Im the kind of person that wont even text you a lol unless I literrally lol'd. I gave you a like cause although I knew you were smart already, I didnt know until this point just HOW smart you are. Copping to you pushing REACT because of your own perrogative honestly made me look at you differently. I admire you sir. You earned my like and subscribe
no
I'm one of the 75% jquery users, but I only use it for $.ajax / $.get / $.post. Though I've been slowly converting to fetch() calls if I remember to, but jquery is so engrained in muscle memory