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 .
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.
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.
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
@@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.
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.
@ 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.
@ 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.
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).
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
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).
I feel like htmx together with a really light weight additional js framework could be really powerful. Make everything fundamentaly really sturdy and backed up by a back end and add some front-end shananigans with the additional js framework. (like animations and such). 99% of websites could work really well that way
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
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!
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
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.
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?
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
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)
htmx has similar csp issues, both are augmenting html to do things that aren't currently supported, hopefully similar ideas will make it to html proper, in the meantime if you want really strong security, it's probably best to use vanilla js and stay as small as possible with little to no dependencies
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.
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.
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.
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, ...)
not only outdated, but also wrong with respect to what built-in to rails like 15 years ago. rails had partial template fragments with "rjs", on the same timeframe as intercooler.js. If you jump in now, it's very easy to think "oh, everyone was making jquery spaghetti, then intercooler came out (which was great, but not adopted at eco-system-shifting levels), then htmx (which is theo is excited above) and now people are shifting in this direction.". rails had things built-in to the framework which were on the exact same path and timeline as htmx (rjs, pjax, jquery_ujs, hotwire). Carson and DHH having both been pushing for the same types of pragmatic primarily-serverside/non-spa architectures/libraries/frameworks the entire time
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).
HTMX is great and I take my hat off to Carson Gross - but standardising it into the browser (as in Triptych Project) is so necessary. It's good they're starting small - hopefully the browsers will adopt and run with it. Bravo Carson, and thanks Theo for a great video.
I'm not a front end dev, but I keep front end stack (or possible front end components) in mind within the app engineering process from the back end. Ok that sounds very Prime meme'ish. Anyway. The moral is that complexity in JSON went WAY up. And writing APIs to allow application admins working for our clients to access data became a real problem. The first hint that problems were on the rise from the clients' perspective was developing APIs using JSON of non-fixed depth (NFD). This meant that, for any API call that pulls data in JSON format, keys MAY or MAY NOT be present in the output depending on whether or not they were used for a particular dataset and whether or not they contained data (even if those keys were expected). I personally found this to be a bit nightmarish as this meant to extract data from an API, I would have to create a gazillion checks to see if keys even existed, especially in cases of crappy API documentation. In some cases and on some platforms, ALL keys were on the table for this type of behavior (except some of the 'header' keys that are often static). What this meant for statisticians, DSs and MLEs was (and still is) having to write FAR FAR more code to get reliable, reproducible, and valid data from those APIs. This isn't a good user experience either. I know that the rule with APIs is to be 'stingy' with data access. One really must be this way for the obvious reasons, but holy shit can this become a tangled web. What I fail to see is whether or not writing an API with an NFD JSON file is any more secure than fixed depth JSON where all keys are presented, and if they're empty, the return is simply an empty set (list, dict, whatever).
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.
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 .
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
comically HTMX toppled React in JavaScript Rising starts for #1 spot on Frontend Frameworks. Does that mean It has received wider adoption? Probably not...
HTMX feels like a successor to Beebole PURE, from 15 years ago... updated for a newer tech stack. We used PURE to enable the same functions, just not as simply.
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
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.
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
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.
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
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.
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.
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.
Somehow this history lesson completely leaves out Java and Flash Applications, or Silverlight and whatnot plugins, including the era of weird stuff like GWT and YUI. But that would also explain, why the expectations were actually already higher than it was possible to do things, and what webapps had to compete with.
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.
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.
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.
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.
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.
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
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.)
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
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).
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.
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
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.
re: comment section in a page and "react taking over the entire app", nah man, put an empty div in the static page, and render react into just that div. boom comments section in react without taking over the entire app.
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.
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.
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 .
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.
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 have to assume that's a sarcastic comment.
@ Not at all. Do assistive technologies work with your output? That's a non-starter for me, and evidence of architectural mismatch.
@ericjbowman1708 Oh. Not _your_ comment. I surely meant the original comment by @flamakespark.
@@tikabass my bad
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
@@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.
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.
@ 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.
@ 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.
You just described Vue there at the end..
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).
Again click bait 😩
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
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.
I feel like htmx together with a really light weight additional js framework could be really powerful. Make everything fundamentaly really sturdy and backed up by a back end and add some front-end shananigans with the additional js framework. (like animations and such). 99% of websites could work really well that way
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 ;)
Yeah it's pretty outrageous to say Gmail was the first AJAX app when OWA was literally what resulted in XHR in the browser.
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!
@@nikomancer69 learning ActionScript felt like learning magic.
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
$.ready() baby
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...
Vue stinks. At least with React you are learning pure JS. Not weird Vue only attributes to put on tags and stuff
@@mattmmilli8287 React is “pure JS” and doesn’t have React-specific attributes to put on tags? 😂
Someone has skill issues.
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?
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
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)
htmx has similar csp issues, both are augmenting html to do things that aren't currently supported, hopefully similar ideas will make it to html proper, in the meantime if you want really strong security, it's probably best to use vanilla js and stay as small as possible with little to no dependencies
@@nightshade427 we didn't have any issues related to htmx tbh. Only alpine. 🤷♂️😊
4:15 Theo, you are underestimating how popular jQuery is, literally Wikipedia and Amazon use it as of today
pretty sure even this UA-cam 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.
I love to see htmx getting recognition as a viable, low-complexity alternative to React for many use cases!
37:10 You can create polygons in excalidraw by connecting line's starting point with ending point and setting background on it.
"the markup language for printers" that's not true, HTML was designed primarily for the web, to display and structure content on web pages.
I think it was a joke
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 am very happy with the trending up release of multiple high quality and long videos of yours recently
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.
Thanks a ton for putting this together. Really appreciate it.
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.
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, ...)
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? 🤔
your rails example is outdated, rails has hotwire (htmx like behavior), and turboframes (template fragments for streaming via hotwire)
not only outdated, but also wrong with respect to what built-in to rails like 15 years ago. rails had partial template fragments with "rjs", on the same timeframe as intercooler.js. If you jump in now, it's very easy to think "oh, everyone was making jquery spaghetti, then intercooler came out (which was great, but not adopted at eco-system-shifting levels), then htmx (which is theo is excited above) and now people are shifting in this direction.". rails had things built-in to the framework which were on the exact same path and timeline as htmx (rjs, pjax, jquery_ujs, hotwire). Carson and DHH having both been pushing for the same types of pragmatic primarily-serverside/non-spa architectures/libraries/frameworks the entire time
Yeah and Hotwire is even more comprehensive than HTMX
Hey Theo, you mentioned a video in which you talk about the BE complexity of UploadThing. Any idea which one it is?
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.
I suspect HTMX is what inspired Livewire, don't know how I have lived without it!
HTMX is great and I take my hat off to Carson Gross - but standardising it into the browser (as in Triptych Project) is so necessary. It's good they're starting small - hopefully the browsers will adopt and run with it. Bravo Carson, and thanks Theo for a great video.
I'm not a front end dev, but I keep front end stack (or possible front end components) in mind within the app engineering process from the back end. Ok that sounds very Prime meme'ish. Anyway.
The moral is that complexity in JSON went WAY up. And writing APIs to allow application admins working for our clients to access data became a real problem. The first hint that problems were on the rise from the clients' perspective was developing APIs using JSON of non-fixed depth (NFD).
This meant that, for any API call that pulls data in JSON format, keys MAY or MAY NOT be present in the output depending on whether or not they were used for a particular dataset and whether or not they contained data (even if those keys were expected). I personally found this to be a bit nightmarish as this meant to extract data from an API, I would have to create a gazillion checks to see if keys even existed, especially in cases of crappy API documentation. In some cases and on some platforms, ALL keys were on the table for this type of behavior (except some of the 'header' keys that are often static).
What this meant for statisticians, DSs and MLEs was (and still is) having to write FAR FAR more code to get reliable, reproducible, and valid data from those APIs. This isn't a good user experience either. I know that the rule with APIs is to be 'stingy' with data access. One really must be this way for the obvious reasons, but holy shit can this become a tangled web. What I fail to see is whether or not writing an API with an NFD JSON file is any more secure than fixed depth JSON where all keys are presented, and if they're empty, the return is simply an empty set (list, dict, whatever).
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.
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 .
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
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.
@@nikomancer69 100%. That’s why Java is still huge.
HTMX feels like a successor to Beebole PURE, from 15 years ago... updated for a newer tech stack. We used PURE to enable the same functions, just not as simply.
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
Give htmx a trial, you wouldn't need to raw dog json no more
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.
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
As a father shows compassion to his children, so the Lord shows compassion to those who fear him.
its really impressive how we write framgents in jsp 15 years ago with jquery and ajax same way,and now its in again
Theo: "People think I don't like HTMX but I simply think HMTX sucks"
Can you please be adding the blog links in the description ?
I get it Theo, you need a thumbnail to promote engagement. But do you always need to look like you’ve just been told your family was murdered
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.
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
Excalidraw
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.
is that markojs in 0:09 ?
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
HTMX doesn't determine anything in your backend, it only helps you send requests and determine where the response to that request goes.
yeah I meant UI changes inside the component. The layout comes rendered from the server, doesn't it?
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.
Html for printers? You are thinking about PostScript
what would I use with HTMX/HTML to get info from a db like supabase?
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.
Personally, I'm loving how FastHTML piggy-backs on HTMX for the simplest, most beautiful solution for python-based web apps.
what is the tool that he is using for note taking?
seems to be excalidraw
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.
I'm curious why Theo says you shouldn't use Go for a CRUD app. Seems to me like it is ideal for that.
Somehow this history lesson completely leaves out Java and Flash Applications, or Silverlight and whatnot plugins, including the era of weird stuff like GWT and YUI.
But that would also explain, why the expectations were actually already higher than it was possible to do things, and what webapps had to compete with.
Should we use react for static blog? As soon as astro makes proper runtime revalidation - no. Until then - yes, nextjs
The best type of Theo video
what would it be like making a zig web app/3d game with htmx, websockets, wasi and wasm?
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.
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.
Rust community need to push worker-rs it is awesome. It definitely removed the idea that Wasm is bad from my mind.
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.
if anybody else is wondering what app Theo is using to draw, it seems to be excalidraw
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.
Please make a full video on SingleStore and how to use it in a real life project.
Please please love from Pakistan.
Something you didn't mention: as a rule of thumb, vulnerabilities grows proportional to complexity
Videos like this remind me how old I am...
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.
why would webassembly be bad? i mean the app / server idea about it is, but web assembly itself is pretty dope
Isn't singletore founded by the neondb guy
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.
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
Some sites might just be importing jQuery like lodash, not necessarily basing their entire rendering on manually using jQuery
So, why not just take an Astro? It's just fit all cases from static pages to dynamic. One tool without funky syntax or "reinvent wheel " ideas.
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.
I don't usually agree with Theo, but he's largely correct with this.
Nobody cares if you agree or not
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.)
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.
Hm. But this is the same thing that Rails 8 does. And you've been, I would say, cruel against the Rails approach.
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
I think the Wasm part was a mistake, ig you meant react right ?😅
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).
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.
Can you do a video on React to Next migration?
Once it gets into the template fragment stuff I'd rather just use React which feels a lot more procedural and less magic
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.
My I don’t want to put effort but I want to do pretty things stack currently is: Pico CSS, AlpineJS and HTMX.
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
Cringe thumbnail again, nah I'm good.
The video was actually quite good, but I agree with you about the clickbait thumbnail.
Hm. Yeah... I agree
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.
re: comment section in a page and "react taking over the entire app", nah man, put an empty div in the static page, and render react into just that div. boom comments section in react without taking over the entire app.
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.
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.
Add in webasm representational state sync glue and some real time client session debugging via server side then that would be cool.
Babe I get to choose the movie tonight
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.