It honestly took me a minute to realize this actually was Carson writing. He does an excellent job of coming out the gate sounding like somebody who is about to tear him a new one, but he's tearing himself a new one while simultaneously backhanding the haters. The layers to this are amazing.
Fun fact: SQL is already 50! And after 50 years, it's still not truly relational! I've read the papers Codd produced about the Relational MODEL (RM) (the origin of SQL and RDBMS) and never once was happy with SQL because it effectively bastardized the RM. Not even in 1990, 2 years before SQL got its primary keys. Codd already talked a out the primary key back in the early 70s mind you. Current SQL and RDBMS' are a travesty /rant
Prime thanks for inspiring me for htmx and go! You sparked my curiosity so I started a side project with htmx + vanilla js + tailwind + go templ for the sake of learning and here we are 9 months later - I ended up deploying it on the internet and I'm so pumped up about it. Even ended up learning aws and some other stuff just so that I could put it out there :) And I plan to continue working on it as this stack is really pleasant to work with.
If you spend any time with the Document Object Model, and you know anything about BDSM, you will realise that the fact that it's acronym is DOM, is not a coincidence. In this case, however, there is no safe word.
I hate hate HATE frameworks that promise "Build Google using a single import", and then they require you to install a package manager to install the dependency manager to install some sort of moon language with 73 dependencies, to push code you have to run in a homebuilt build process that uses md5 hashes rather than timestamps to detect changes, and it only works if you serve it using their custom reverse proxy that needs a Reddit (EDIT: Redis, sigh) cluster for caching. Which, of course, is far too complicated, so here's a Docker script to make it easy. Instead, just MAKE IT EASY by removing things.
@@thewhitefalcon8539 Dammit. I think I got autocorrected, because it was supposed to be Redis. Or I was just ranting, because I have come to hate dependencies.
Calling it old tech isn't the attack some people think it is. Old tech that has survived the test of time is the best tech. That's what you *want* in production. Use your flashy new stuff in personal projects and minor stuff where it doesn't matter if you stumble into some unknown fundamental flaw. In a real production environment you want simple, time tested, boring technology where all the flaws are known (and probably fixed) and there won't be any surprises.
Related to this is the Lindy effect which states that the lifetime of non-perishable things (organizations, books remaining in print, specific technologies being in use, etc.) tends to follow a Pareto distribution. What this means in practice is that at any given time, any given technology is likely to remain in use for about as long as it has already been in use. It's generally a good idea to choose dependencies that have been around for at least as long as you plan on depending on them or you are likely to have to become the maintainer.
I find myself starved for nuanced, unbiased takes in software. The answer to most questions is boring: "it depends". It requires discovery, requirements gathering and a lot of thought, but this binary and click-bait world has devolved us into this monkey-brained "there is only 1 right answer". I wish someone would step forward in this community and be this type of representative.
Software is personal for a lot of people. It's often their livelyhood and their passion. Of course you're going to have a bias in anything people create and foster. That's natural.
I've come across websites who had client-side-only validation. For example, they thought they could apply a limit to my text field or disable the submit button for failing to meet some requirement.
React is probably the JQuery for Gen Z. HTMX may be the JQuery for Gen Alpha. I'd say Angular was JQuery for Millennials, JQuery was the JQuery for Gen X, and Scheme/Lisp the JQuery for Boomers. The Greatest Generation just had to manually punch in opcodes using toggle switches and a big red advance memory button on an IMP to send out a few packets.
I'm a Gen-X'er who legit loves jQuery so much, it makes such intuitive sense to me, I've written dozens, maybe hundreds of userscripts for Tampermonkey on Greasyfork, used by +10,000 of people around the world
Thank you for actually addressing the article's comments. While Theo's take was probably amusing to HTMX fans, I appreciate that you actual expanded on the points referenced by the article.
accepting HTMX into your life means accepting that modern JS is silly, over-complicated nonsense. The proposition being made by HTMX is that UI doesn't (always) need to be that fucking hard. If it doesn't need to be that hard, it forces MANY devs to either admit they invested their time in nonsense or reject the idea.
This channels fans: Typescript and JS aren’t even real programming they’re too easy try rust Also this channels fans: JS IS TOO COMPLICATED MOVE ALL YOUR LOGIC TO HTML
we will not come back to the old era where web ui is ugly, not interesting, that make product that is presented is not interesting, with many more limited interactivity kid. if you want, go do for yourself
The front/back split is bad for our brains. We should have to understand each other for both our health. The user's experience is generated by the flow of the data. The flow of the data is generated by the user and the experience they're having. We are one. Unite us.
16:27 - misrepresents XSS prevention as validation in a way that's likely to be confusing. Validation is a mitigation technique but it is neither necessary nor sufficient to prevent XSS. The nature of XSS is an encoding bug where the attacker tricks the browser into encoding data in a way that results in code execution. Modern JS UI libraries eliminate a huge class of encoding bugs by automatically encoding HTML inner text during binding interpolation. Yes there are some cases that aren't covered and need to be considered more carefully on a case by case basis (like the mentioned HREF) but the whole discussion of front-end vs back end validation is a red herring. The real question is, are you encoding correctly for your data sink.
fun facts. your end users doesnt give a crap what lib, frameworks, a href, ajax,jquery or fetch even beacon u used. faster and smaller is always better
If humans were geeks and all capable of critical thought, Americans would actually understand their constitution and actively protect it. But that isn't what you see, so eh.
@@shining_cross i think you need to check your eyes coz its seem u cant tell the different a web and AAA game. 200kb may considered as heavy not to long ago on 2000. now almost 50mb for a freaking page. load time 1mnt++. flash is rolling on its grave.
@18:19 The argument is simple as companies learn how much time and money they can save, there won't be much of an argument. As for talent pool, you can learn HTMX in an afternoon. Our target audience at this time are decision makers.
You can use HTMX to spit out bootstrap 5 elements like a carousel just fine. Stuff like multi criteria paginated active search tables are a bit of a pain in the ass but you can make a generalization you can reuse pretty easily, it just takes a bit of time to get it right.
This is exactly what I do with the internal tools I build. It's because I use HTMX that I can implement paging in a simple, fast, and reusable way that doesn't require me to bend over backwards with JavaScript in addition to the backend logic.
not, htmx is meh, its complicated if you create complex and many interactivity, you never now until you create those that i said. i can create what you said very simple and fast and manageable in complex and big project and complex many interactivity in sveltekit and golang embed
Look at *really* old documentation and books. As an older developer, I first learned web dev back before frameworks were a thing, and even using jQuery was considered “bleeding edge” HTMX is a refreshing thing to use, because of how simple it is. You don’t need a billion things, and it’s very similar to how things worked 20 years ago. Just better. I would’ve absolutely *loved* to have had HTMX back then, and I absolutely love HTMX today.
Look. ALL front-end dev boils down to nothing more than DOM manipulation, because at the end of the day browsers render HTML. So whatever the simplest means you can use to achieve the dom manipulation you need is, that's the correct solution. Use straight JS until you actually have a need for a library, then use a library until you actually have a need for a framework. Don't just dump React on every project because "It's got components...it's got what plants crave".
@@Cyanide300 The only front-end framework we learned at school was Angular. I just learned Vue/Nuxt on the job as part of my internship, making me think I could learn react quickly. I like htmx more than Angular or Vue because it reduces the number of files I have to update when I want to make a small change on my front end. I worry I’m sending too many requests to the server, so I'm still trying to find the balance there. I'm building a website for my mom that I plan to deploy eventually using htmx and express, which is helping me get a more in-depth understanding of the library. I may also build a cms for it, but I'm unsure if I want to handroll my Authn/authz with htmx.
When I'm concerned about if I'm doing something right, I ask myself a few questions: 1) Does it work? In all the edge cases I can anticipate? This is the most important factor by far. If it doesn't work, it's garbage. 2) Is there a simpler way to do it? We love to over-complicate things. Always push to make things simpler. 3) Does it perform fast enough for my use case? Very rarely in web development is performance actually meaningful. You'll know when there's an exception. 4) Am I going to hate reworking this in a year when the requirements change, and I've forgotten everything I've done to make it work? Readability and maintainability are king. If you work somewhere for more than a couple years, you will be revisiting old things. This is a lesson you can learn only through experience and making mistakes that you learn through refactoring. If you can confidently justify and explain points 1-3, then there's no problem. Any senior worth their salt will be able to look at your code and explain what's good about it and what's not good about it, and they should be able to do so without relying on dogma. The purpose of this article is to let the reader decide whether they agree with long-standing dogma or if they will think for themselves about what is best for their unique situation.
10:07 Might be an unpopular opinion: it's fine to use dependencies when creating an application, but you should try to avoid using dependencies when creating libraries, because any bugs and vulnerabilities in that dependency would then also become bugs and vulnerabilities in your library.
On the other hand, in a normal day job you won't have nearly enough time to continuously work on "non-main-project-stuff" (like UI components for example) and poke them for vulnerabilities. So basically by rolling your own stuff you have almost 100% chance of introducing subtle bugs/vulnerabilities/accessibility issues while by importing an external dependency you at least have some chance to have it patched regularly. Same stuff applies to the backend of course.
That's can be solved by raising the issue (if it matters) to the affected library owners, submit a PR and get it sorted. If the case is that either the library owner is not longer maintaining or don't want to make the change, then you have the choice to move to something else, or write it yourself. That's not to say you should blindly just choose a library on its face, but the point of an ecosystem is that we can share and contribute across our dependents and dependencies. There's nothing to say your library code is any less vulnerable than anyone else's. Unless you of course are a 10x developer.
@@dealloc The issue though is that it would now have to be fixed in 3 places: the library with the bug needs to fix the bug and create a new release version, the library using the vulnerable library needs to update their dependency (check if the change wasn't breaking) and release a new version and the application needs to update the version of the intermediate library. If libraries don't use other libraries, that intermediate step can be skipped.
14:00 I never used HTMX so idk, but why would the backend engineer be responsible for writing the front end UI? Couldn't the front end designer make what they need to make in HTML / CSS and then store those components wherever they need to go to be served by HTMX
Yes, the whole article is a parody. It’s written in the style of “clueless front end dev” You can easily reuse front end components and keep all of that separation of concerns with HTMX, it just looks different than React.
I worked at a startup recently that thought backend engineers should do the frontend as well. These are not full stack engineers. HTMX was going to "save" the day. It did not. Not because HTMX is the problem...it's this weird thinking that UX doesn't matter.
This is why being in cybersecurity was so helpful. You can quite literally find the areas where the engineers are disputing methodologies, frameworks, and access methods.....and feast. Trends and evangelism = hackable by teenagers. Love your drama though. Been an outside observer for years and I can't get enough. No notes there 😂
8:16 They do not do the same thing because the JS snippet doesn't create the button, only the code called by an element somewhere else. Where the actual element is on the page is not readily apparent.
PJax is so good for how old it is and it's so crazy to me that I only learned of it accidentally by digging through an old Ruby project and thought that looks pretty neat, which eventually lead me to HTMX.
I haven't used HTMX, but like the idea of it, but as with everything it's the right tool for the right job. Haters seem to see that there is only one way to do things (which is a sure sign of inexperience).
Htmx only frontend is a great way to ddos yourself. Imagine the stupidity tk communicate with your server to filter and update a data table on your client with the data that you have sent already once. That's just dumb... And these same warriors are complaining about next.js, vercel, and serverless while barely kept maintaining a real fullstack app alive (yea, with real users, not like my gf) for more than 2 years (and not talking about a readthedocs site)...
As someone who uses HTMX EVERYWHERE (except native apps obvs) and I write all my apps in Typescript, the fact HTMX isn’t written in TS is actually a comfort to me. For a lightweight client-side library you absolutely want it to be as minimal and efficient as possible. TS isn’t that. Eliminating the build step and writing the code optimised for how it will be run is IMO the correct way to do a client-side script like this. Also you’re immediately protected from all of the future changes in TS, vanilla JS is always going to work, everywhere (well except in IE11 … which can burn in fire as far as I’m concerned)
I’m primarily a backend engineer for my day job, but I am often complimented on my AMAZING front end skills. My secret: a really good overseas designer who makes Figmas for me, then I implement it.
I usually validate on the front end and back end because validation makes it easy for dumb users to not do something dumb, and validation on the back end makes it harder for a hacker to exploit you with a request. I also do this with permissioning where I'll ensure a request is limited to certain users on the back end, and won't even display the option to interact with the application in a way that I don't permit for dumb users.
This feels less like the author of HTMX engaging in some intellectual exercise where he challenges his own thinking and more like he's just making a straw man argument.
@@brandongregori995I'm not trying to find an argument, but just curious. Can htmx serve REST APIs? What happens if I have multiple types of client (Web, ios, Android, desktop apps) that preferably communicates with the same backend? I'm not educated on htmx. Just asking.
@brandongregori995 It's troubling that you're asking- can people really not think of the drawbacks of having your UI running off websockets and http requests? To spell them out for you, HTMX introduces an additional failure point at every event hook in your application. Yay, an onblur handler can now cause a 500 request error. It introduces latency in areas that had none and requires a web server where you didn't need one. As a fun fact- there's demos on the htmx site that don't actually use htmx and run fake server code on the client. The author is very literally hiding the problems from you
@@Dipj01lol. Htmx is quite literally built for rest APIs - in the truest sense. What you're calling rest api is actually a json api, and is precisely the problem that htmx is addressing. He has many essays on these topics on the htmx site. They'll open your eyes to how far gone js web dev is
idk, these doesn't sound too strawy, i can see someone like Uncle Bob making those. There seems to be an inadequate amount of senior programmers who think that 10 line function is too long and that goto is unsafe. In fact, there is so much of them, that generative NNs refuse to show code with gotos to the minors, which is hilarious.
1:50 "should be purple to me" lmao.. what a nicely trainer hamster you are.. try changing the colors for a day and see how it messes up your visual cortex (no joke) ❤ luv your stuff, finaly someone who shows all those quiche eaters 🤣
Why you don’t want to build your ovn carousel, I think having external solution that fits all creates bloat. Writing your own carousel takes like 30min, and you’ll probably spend the same amount of time configuring external solution, and you won’t have so much bloat, bc you’ll end up with a solution that fits your specyfic case. Also using so much of external plugins makes me feel stupid.
I prefer to work in languages with medium-sized ecosystems that not everyone has adopted, but a core group of smart people has. That way, I can trust that when I install a dependency, it has only probably moved through the hands of a few smart professionals who knew what they were doing.
Not using Typescript makes it worse, cause changes of errors are higher, but JSDoc seems to compansate for most problems. Another benefit of Typescript is that you can write ones and then generate commonjs and esm.
If it breaks, has inconsistent behavior, or restricts you from doing something you may reasonably want to do, then dive in and give constructive criticism. If not, why waste your time lol. You don’t break open your walls to inspect your house wiring to make sure it has proper wire and cable management
I enjoyed very much hearing about the "worse is better" movement or idea(?). The guy is teaching people 2 things: everything has pros/cons AND how to argue about things. Those things are totally lost, depending on which generation the person belongs to.
Is htmx worth trying out? I use ajax techniques and this seems like a logical next step. I hardly choose a js lib or framework, simply for the fact that html hardly ever gets used or any love; developers get to then forget or ignore what html already has to offer. Idk, I do want to try htmx. Attributes right?
If you only use html+js for the frontend, HTMX is definitely for you. With HTML you make boxes, with CSS you style them, with JS you make them functional, with HTMX you replace what's inside of them with data from the server.
@@CristianKirk Holly shit, it is perfect for me. I do not create websites for a living. I just edit my lab website and don't want to spend a lot of time learning some convoluted framework like React.
I am using literally just bootstrap, JS, HTML and PHP (my college campus does not use dockers for website management. They just create a directory with the name of the lab that the user of the lab has rwx permissions).
Maybe this is what people are saying, but non of this actually addresses the fundamental problem of htmx. That it becomes virtually impossible to reason about the possible UI states. In reat, I partition my input state into some set of equivalent classes, e.g. based on the combination of branches taken. That's already pretty difficult. But think about htmx. Here every UI interaction is able to produce a new state of UI. So now you not only have to think about classes of equivalent input state producing your UI, but also about all the possible mutations. You need to recursively walk this graph. Describing the properties of this graph is a lot harder, especially when things start to get messy as they always do. This is the reason why more or less every UI framework native or not of the past 10 years, has embraced some kind of declarative, reactive style. Nowadays the classical retained mode UI with imperative modification is a dying breed and rightly so. Declarative and immediate mode UI is just so much easier. Please don't take us back to the dark days. You can do reactive programming server based, e.g. phoenix live view, Hotwire, etc.
Re: using Java code rather than Grep in an interview. I had a similar question in an interview many years ago and they actually expected me to write code for the answer. I just replied with something like "I'm not sure offhand, but probably something with grep and awk." They kept pressing on me for a code answer and I said "These tools have been around forever, have had many eyes on them, and are built for purpose. Who am I to think I can write something better?" Still got the job.
Tbh, no matter how much we push HTMX it may never reach the versatility of using React/Vue/Angular. Those just fits. Where it makes it really hard for me to choose HTMX for any project. Maybe a really static site, just plain simple sites.
LOL. JSDoc is the thing now?! I have been hating on PHPDoc for 10 years which is pretty much the exact same thing, but the last years the PHP community has almost completely moved away from that. Then comes javascript with their brand new thing that relies on it. That is pretty insane...
It's irrelevant if TS is in the code, you can still use TS, however, you need to transpile it anyway for compatibility - and yes we are ONLY talking about the frontend anyway.. Use TS on your backend (just don't) if you like
I really like JSDoc because it is easy to parse and generate a documentation site. I wrote my own parser for work that builds some JSON then I build a static site. Easy.
re: typescript thing -- I'm currently working with v8 of video.js and a plugin, both of which export types via jsdoc -> typescript d.ts files... it is HORRIBLE, video.js's v7 types made by the community were actually complete and good, but v8 now has `any`s everywhere, various things missing, and all classes are exported as default which prevents me from fixing them with my own d.ts file. There's so many issues I've ran into it's hard to put into a comment. Just really makes me doubt this "jsdoc is just as good" idea.
@ThePrimeTime Why you not brave verified content creator my g ? This creator is not yet verified with Brave Creators. You'll be able to send them contributions once they're verified.
I feel like this article, hilariously, puts many pieces of popular but unbacked opinions in its arguments like the suggestions around React. It becomes more apparent and funny considering the author is the creator of htmx itself.
code duplication argument is not so relevant as you have mostly same data source for same "pages": if you show user page in app and on the website you still need to prepare data and then just throw html or json made from prepared data. and this works perfectly with let's say laravel with if (request()->wantsJson()) return { new UserDataResource($data); } and next just html (or other way around with hx header)
Criticisms of HTMX are like Scheibe’s criticisms of Bach: “it is totally impossible to distinguish the melody. All the parts are alike as regards difficulty, and no single one stands out as principal part.” Well, duh.
The HTMX approach is rife with all the sorts of issues that moden front end dev has worked to address for the last decade and a half. Its an ok idea for simple stuff. It falls down under growing complexity. The over engineering of the front end landscape has led to developer burn out to the point where people are willing to go back to 2005. There is no other kind of software besides web afaik where this kind of server side ad lib authoring, delivery, parsing, and execution of UI and client application paradigm exists. Client application installed locally, data server remotely. Web application browser pages , sites and software is a strange beast. My preference is Angular or vanilla. I just started with Angular back when it came out, appreciate that its fairly straightforward and easy to get the hang of, typescript and 'OOP' ish in the most basic sense, so you have clear structure and separation of concerns. Tried JSX a bit but to me Angular templates are so much more like just writing legible HTML. Never had the time or the opportunity to get too lost in the sea of framework and pipeline madness that came after it. I also do work maintaining large complex legacy enterprise applications built in this 2005 HTML over the wire style, and its an absolute nightmare in terms if maintainability etc.
Not to be that guy, but COBOL programmers average salary in the US is on the low-end, about $82k, depending on what data source you query. Many other languages pay better, sometimes much better. The belief that it's high-paying is an MKUltra style campaign by IBM to convince people to learn COBOL, so the organizations still buying mainframes have programmers to lock in their basement.
It’s because they’ve never actually done anything beyond writing React. They think they know everything when they know nothing! These are the devs that AI will replace!
I dunno, dude, as someone who hates web dev and does as little of it as I can get away with, the claim that it is "inconsequential" is just kinda weird. Like, I've been coding professional for 22 years, and some kid fresh out of college who knows (and cares) about all the different web dev frameworks is probably more useful to a typical dev company than I am, right now - salary adjusted, at least. They can get more useful features in the hands of their customers faster than I can. I write better, more secure, more reliable code in "harder" fields that solves harder problems faster and with fewer bugs... but I don't know how much that's actually worth any more. But yeah, has to be said that all those different web dev frameworks each do their own thing, they're just each uniquely terrible in their own way, and so much of "the discourse" being about which terrible option is best really is exhausting. I'll give you that. But inconsequential? I wish that was true.
@@BittermanAndy web dev is about perception more than actual delivery of usefulness. It looks useful, but it just makes people angry. There are entire businesses I won't work with or shop at because of how bad their site is. MBAs or whoever don't recognize this
18:39 There are no HTMX Job , Actually Alot of companies dont care about UI/UX for their Business Softwares but reliability so i use HTMX , i dont think i am not fist guy used HTMX for real-world SAAS projects and Small side Projects + I got alot of Extra Bonus through HTMX from Boss And Customers
HTMXs source code could benefit massively from typescript and other tooling. It's VERY difficult to reason through things and figure out what the heck stuff is. I say that as someone who contributed a small part. It's very difficult to work with. I think these reasons presented are valid reasons HTMX source is bad. This mostly doesn't relate to whether the tool itself is bad, which I don't think it is. It's just another way. I don't like when people say "it reduces the complexity" since it just moves the complexity...
I don't like to write long lifecycle projects in dynamically typed languages or in a single file, but HTMX is a 5k LoC code base written by one guy. If the author can fit all of this in his head without relying on separation of concerns, then more power to him. People have made great software while doing much worse. It's not great for team sizes more than 1 though.
Nothing against those JavaScript libraries for the right use cases, but they're victim to the dependency problem. There are corporate websites with 5-10 different jquery.js files (other frameworks too) that just wound up that way from employees adding things. it's alot harder for the employees to butcher HTMx that way.
Livewire is horrible, it should be seen as a dark pattern. its like they wanted to write more code in the backend then you would have to write in vuejs on the frontend. Besides that its easy for sure but its a trap
HTMx, making it even easier to generate pages full of identical, unclickable buttons with no URIs or graceful degradation to those of us who depend on assistive technology to use the Web. Big Browser doesn't care, either. The "state of the art" in Web Development is only moving BACKWARDS.
I wrote a CMS for a Forbes 500 company, in 1996, using Live Wire. Now they call it ssjs. Is it just "laravel" mispronounced, or is there a new "Live Wire?"
I'm currently using React for frontend and Golang for backend. It sucks having to keep track of types on two codebases, I'm interested in transitioning to HTMX. I've been researching the best tools and methods for making this switch, I'm not enjoying templ a lot. Could anyone share tips or recommend their preferred tools and practices for templates, JavaScript, and other aspects of using HTMX?
@@sneed1208 I am used to it. I have 4 apps in production and they all have separate codebases for front and backend. I would like to avoid it if possible.
Dear Prime. You don't understand what "DRY" means. I don't fault you, the term is widely misunderstood. But I cringe a little every time you mention it. Please read the section in the "Pragmatic Programmer", that introduced/popularized the term. The quote: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". It has nothing to do with turning boilerplate into abstractions. It's not about repeating code and patterns. It's about having a single source of truth. I'm pretty damn sure you violate DRY _very rarely_ on purpose. When you do so, you do it deliberately and carefully. Examples include caching, redundancy or decentralized knowledge. You know very well these things introduce very hard problems and we only reach for them if they provide a very compelling benefit. Please at least read the article "Orthogonality and the DRY Principle" where the authors clear up these misunderstandings.
"Who would put validation on the frontend?" No, this is wrong, please don't listen to this advice. People trying to fuck with you is a small minority of users, but due to outsized impact you defend against that. But everyone else is just an ordinary user, and you're also working with ordinary devs, and if you do validation on the frontend then your backend teams will be so much happier. Validation on the frontend is immediate ROI. Backend and frontend teams should be sharing as much validation and types as possible, and double-validation is not wasteful and is very common industry practice.
HTMX should go the way of jQuery. That is, it should become an integral part of browsers. It is 2024 guys, AJAX is soon 30 years old. Can't we make that part of the core HTML spec? Pretty please with sprinkles on top?
The only issue I'd have is to have a clear definition of an HTML snippet - clearly many of the endpoints you create in HTMX are not 'really' valid HTML urls (unless I'm missing something). Some sort of extended HTML tag?
oh, and, btw, that "dressing down of HTMX" or whatever article that is linked inside there, is actual garbage and hateful (including transphobic language somewhere at the very end). I don't recommend reading it.
Generation Z's two favourite logical fallacies, are the appeal to popularity, and the appeal to modernity. In other words, the two methods of determining the worth of anything, are to first ask if it is less than five minutes old, and if everyone else likes it. I know that some of you will unironically agree with this, as well.
It honestly took me a minute to realize this actually was Carson writing. He does an excellent job of coming out the gate sounding like somebody who is about to tear him a new one, but he's tearing himself a new one while simultaneously backhanding the haters. The layers to this are amazing.
Yeah the first minute of him reading this made confused, then I completely got It anda also think this IS such a 200iq move lmao
"HTML is over thirty years old now."
The wheel enters the room.
Fun fact: SQL is already 50!
And after 50 years, it's still not truly relational! I've read the papers Codd produced about the Relational MODEL (RM) (the origin of SQL and RDBMS) and never once was happy with SQL because it effectively bastardized the RM. Not even in 1990, 2 years before SQL got its primary keys. Codd already talked a out the primary key back in the early 70s mind you.
Current SQL and RDBMS' are a travesty /rant
Oh look who decided to roll in
Nobody:
Software Engineers: We have to reinvent it!
Prime thanks for inspiring me for htmx and go! You sparked my curiosity so I started a side project with htmx + vanilla js + tailwind + go templ for the sake of learning and here we are 9 months later - I ended up deploying it on the internet and I'm so pumped up about it. Even ended up learning aws and some other stuff just so that I could put it out there :) And I plan to continue working on it as this stack is really pleasant to work with.
If you spend any time with the Document Object Model, and you know anything about BDSM, you will realise that the fact that it's acronym is DOM, is not a coincidence. In this case, however, there is no safe word.
💀
My safe word is !important
@@nahkh1 that's not even HTML
@@laden6675 that's why it's safe
@@nahkh1 Thats css. for HTML
I hate hate HATE frameworks that promise "Build Google using a single import", and then they require you to install a package manager to install the dependency manager to install some sort of moon language with 73 dependencies, to push code you have to run in a homebuilt build process that uses md5 hashes rather than timestamps to detect changes, and it only works if you serve it using their custom reverse proxy that needs a Reddit (EDIT: Redis, sigh) cluster for caching. Which, of course, is far too complicated, so here's a Docker script to make it easy.
Instead, just MAKE IT EASY by removing things.
A reddit cluster lmao
@@thewhitefalcon8539 Dammit. I think I got autocorrected, because it was supposed to be Redis. Or I was just ranting, because I have come to hate dependencies.
why are you bringing Lua into this?
Calling it old tech isn't the attack some people think it is. Old tech that has survived the test of time is the best tech. That's what you *want* in production. Use your flashy new stuff in personal projects and minor stuff where it doesn't matter if you stumble into some unknown fundamental flaw. In a real production environment you want simple, time tested, boring technology where all the flaws are known (and probably fixed) and there won't be any surprises.
Related to this is the Lindy effect which states that the lifetime of non-perishable things (organizations, books remaining in print, specific technologies being in use, etc.) tends to follow a Pareto distribution. What this means in practice is that at any given time, any given technology is likely to remain in use for about as long as it has already been in use.
It's generally a good idea to choose dependencies that have been around for at least as long as you plan on depending on them or you are likely to have to become the maintainer.
COBOL would like to disagree with you
But databases definitely agree with him.
I find myself starved for nuanced, unbiased takes in software. The answer to most questions is boring: "it depends". It requires discovery, requirements gathering and a lot of thought, but this binary and click-bait world has devolved us into this monkey-brained "there is only 1 right answer". I wish someone would step forward in this community and be this type of representative.
upvoted for subtle irony!
That’s what manuals are for. You want someone to read manuals on stream?
You watched none of the video and read none of the article before posting this, huh?
Software is personal for a lot of people. It's often their livelyhood and their passion. Of course you're going to have a bias in anything people create and foster. That's natural.
@@ConernicusRex The comment you are replying to flew right over your head. The reader isn't supposed to take it literally.
Is this a re-upload or am I tripping
no you watched theo vid probably XD
it is
Bro actually thinks Theo’s mustache even comes close to Prime’s 💀
Bro actually thinks Theo’s mustache even comes close to Prime’s 💀
th-cam.com/video/3nSDA0Nd_0I/w-d-xo.html
I've come across websites who had client-side-only validation. For example, they thought they could apply a limit to my text field or disable the submit button for failing to meet some requirement.
JQuery for the gen z
This should be their twitter bio
neat
more like for Gen X or people in love with the 24th letter of the alphabet (elon)
React is probably the JQuery for Gen Z. HTMX may be the JQuery for Gen Alpha. I'd say Angular was JQuery for Millennials, JQuery was the JQuery for Gen X, and Scheme/Lisp the JQuery for Boomers. The Greatest Generation just had to manually punch in opcodes using toggle switches and a big red advance memory button on an IMP to send out a few packets.
I'm a Gen-X'er who legit loves jQuery so much, it makes such intuitive sense to me, I've written dozens, maybe hundreds of userscripts for Tampermonkey on Greasyfork, used by +10,000 of people around the world
HTMX + Templ feels like VueJS
With AlpineJS it works pretty much identically too!
I love Vue, but I hate saying "I love Vue" in person because it's indistinguishable from "I love you"
Then just use Vue, no? 😂
@@LukeCreates You might not want to ship a full stack framework just for basic templating and some interactivity
@@JanJozefo Totally a fair take. I appreciate HTMX, I just get concerned with scope and maintainability with it.
Thank you for actually addressing the article's comments. While Theo's take was probably amusing to HTMX fans, I appreciate that you actual expanded on the points referenced by the article.
accepting HTMX into your life means accepting that modern JS is silly, over-complicated nonsense. The proposition being made by HTMX is that UI doesn't (always) need to be that fucking hard. If it doesn't need to be that hard, it forces MANY devs to either admit they invested their time in nonsense or reject the idea.
This channels fans: Typescript and JS aren’t even real programming they’re too easy try rust
Also this channels fans: JS IS TOO COMPLICATED MOVE ALL YOUR LOGIC TO HTML
@@markbond08 Front-end development is easy, you guys just managed to make it hard. Idiots admire complexity.
@@markbond08 Every one of those rust devs can learn react, we all just know js is a bullshit language. ('b' + 'a' + + 'a' + 'a').toLowerCase()
@@markbond08some of them are really hypocrycite
we will not come back to the old era where web ui is ugly, not interesting, that make product that is presented is not interesting, with many more limited interactivity kid. if you want, go do for yourself
The front/back split is bad for our brains. We should have to understand each other for both our health. The user's experience is generated by the flow of the data. The flow of the data is generated by the user and the experience they're having. We are one. Unite us.
16:27 - misrepresents XSS prevention as validation in a way that's likely to be confusing. Validation is a mitigation technique but it is neither necessary nor sufficient to prevent XSS. The nature of XSS is an encoding bug where the attacker tricks the browser into encoding data in a way that results in code execution. Modern JS UI libraries eliminate a huge class of encoding bugs by automatically encoding HTML inner text during binding interpolation. Yes there are some cases that aren't covered and need to be considered more carefully on a case by case basis (like the mentioned HREF) but the whole discussion of front-end vs back end validation is a red herring. The real question is, are you encoding correctly for your data sink.
If you ampersand encode everything you can’t get XSS’d! 😂
fun facts. your end users doesnt give a crap what lib, frameworks, a href, ajax,jquery or fetch even beacon u used. faster and smaller is always better
If humans were geeks and all capable of critical thought, Americans would actually understand their constitution and actively protect it. But that isn't what you see, so eh.
@@rh906 easy time produced weak people. hard time make strong people
not, cool 3d, high interactivity is better
@@shining_cross i think you need to check your eyes coz its seem u cant tell the different a web and AAA game. 200kb may considered as heavy not to long ago on 2000. now almost 50mb for a freaking page. load time 1mnt++. flash is rolling on its grave.
@18:19 The argument is simple as companies learn how much time and money they can save, there won't be much of an argument. As for talent pool, you can learn HTMX in an afternoon. Our target audience at this time are decision makers.
You can use HTMX to spit out bootstrap 5 elements like a carousel just fine. Stuff like multi criteria paginated active search tables are a bit of a pain in the ass but you can make a generalization you can reuse pretty easily, it just takes a bit of time to get it right.
Huh.. Funny guy above.
This is exactly what I do with the internal tools I build. It's because I use HTMX that I can implement paging in a simple, fast, and reusable way that doesn't require me to bend over backwards with JavaScript in addition to the backend logic.
not, htmx is meh, its complicated if you create complex and many interactivity, you never now until you create those that i said. i can create what you said very simple and fast and manageable in complex and big project and complex many interactivity in sveltekit and golang embed
My only problem with htmx is as a junior its very difficult to tell if I am misusing it because my mentors don't really use it at all
Look at *really* old documentation and books.
As an older developer, I first learned web dev back before frameworks were a thing, and even using jQuery was considered “bleeding edge”
HTMX is a refreshing thing to use, because of how simple it is. You don’t need a billion things, and it’s very similar to how things worked 20 years ago. Just better.
I would’ve absolutely *loved* to have had HTMX back then, and I absolutely love HTMX today.
Look. ALL front-end dev boils down to nothing more than DOM manipulation, because at the end of the day browsers render HTML. So whatever the simplest means you can use to achieve the dom manipulation you need is, that's the correct solution. Use straight JS until you actually have a need for a library, then use a library until you actually have a need for a framework. Don't just dump React on every project because "It's got components...it's got what plants crave".
@@Cyanide300 The only front-end framework we learned at school was Angular. I just learned Vue/Nuxt on the job as part of my internship, making me think I could learn react quickly.
I like htmx more than Angular or Vue because it reduces the number of files I have to update when I want to make a small change on my front end.
I worry I’m sending too many requests to the server, so I'm still trying to find the balance there.
I'm building a website for my mom that I plan to deploy eventually using htmx and express, which is helping me get a more in-depth understanding of the library. I may also build a cms for it, but I'm unsure if I want to handroll my Authn/authz with htmx.
When I'm concerned about if I'm doing something right, I ask myself a few questions:
1) Does it work? In all the edge cases I can anticipate?
This is the most important factor by far. If it doesn't work, it's garbage.
2) Is there a simpler way to do it?
We love to over-complicate things. Always push to make things simpler.
3) Does it perform fast enough for my use case?
Very rarely in web development is performance actually meaningful. You'll know when there's an exception.
4) Am I going to hate reworking this in a year when the requirements change, and I've forgotten everything I've done to make it work?
Readability and maintainability are king. If you work somewhere for more than a couple years, you will be revisiting old things. This is a lesson you can learn only through experience and making mistakes that you learn through refactoring.
If you can confidently justify and explain points 1-3, then there's no problem. Any senior worth their salt will be able to look at your code and explain what's good about it and what's not good about it, and they should be able to do so without relying on dogma. The purpose of this article is to let the reader decide whether they agree with long-standing dogma or if they will think for themselves about what is best for their unique situation.
10:07 Might be an unpopular opinion: it's fine to use dependencies when creating an application, but you should try to avoid using dependencies when creating libraries, because any bugs and vulnerabilities in that dependency would then also become bugs and vulnerabilities in your library.
On the other hand, in a normal day job you won't have nearly enough time to continuously work on "non-main-project-stuff" (like UI components for example) and poke them for vulnerabilities. So basically by rolling your own stuff you have almost 100% chance of introducing subtle bugs/vulnerabilities/accessibility issues while by importing an external dependency you at least have some chance to have it patched regularly.
Same stuff applies to the backend of course.
This is standard best practice for ~30 years now and not at all a hot take.
That's can be solved by raising the issue (if it matters) to the affected library owners, submit a PR and get it sorted. If the case is that either the library owner is not longer maintaining or don't want to make the change, then you have the choice to move to something else, or write it yourself.
That's not to say you should blindly just choose a library on its face, but the point of an ecosystem is that we can share and contribute across our dependents and dependencies. There's nothing to say your library code is any less vulnerable than anyone else's. Unless you of course are a 10x developer.
@@dealloc The issue though is that it would now have to be fixed in 3 places: the library with the bug needs to fix the bug and create a new release version, the library using the vulnerable library needs to update their dependency (check if the change wasn't breaking) and release a new version and the application needs to update the version of the intermediate library. If libraries don't use other libraries, that intermediate step can be skipped.
Applications tend to be a construction of shared components. Whether vendored or not.
14:00 I never used HTMX so idk, but why would the backend engineer be responsible for writing the front end UI? Couldn't the front end designer make what they need to make in HTML / CSS and then store those components wherever they need to go to be served by HTMX
Yes, the whole article is a parody.
It’s written in the style of “clueless front end dev”
You can easily reuse front end components and keep all of that separation of concerns with HTMX, it just looks different than React.
I worked at a startup recently that thought backend engineers should do the frontend as well. These are not full stack engineers. HTMX was going to "save" the day. It did not. Not because HTMX is the problem...it's this weird thinking that UX doesn't matter.
This is why being in cybersecurity was so helpful. You can quite literally find the areas where the engineers are disputing methodologies, frameworks, and access methods.....and feast. Trends and evangelism = hackable by teenagers. Love your drama though. Been an outside observer for years and I can't get enough. No notes there 😂
I think HTMX is a pretty cool guy. Eh makes websties and doesnt afraid of anything.
Arby n the chief reference?!
master chief is also a pretty cool guy
Ancient meme checks out
@@technolungthe 4chan meme actually predates Arby and the Chief season 1 by half a year, so I think 4chan is the actual origin.
8:16 They do not do the same thing because the JS snippet doesn't create the button, only the code called by an element somewhere else. Where the actual element is on the page is not readily apparent.
PJax is so good for how old it is and it's so crazy to me that I only learned of it accidentally by digging through an old Ruby project and thought that looks pretty neat, which eventually lead me to HTMX.
I haven't used HTMX, but like the idea of it, but as with everything it's the right tool for the right job. Haters seem to see that there is only one way to do things (which is a sure sign of inexperience).
Htmx only frontend is a great way to ddos yourself. Imagine the stupidity tk communicate with your server to filter and update a data table on your client with the data that you have sent already once. That's just dumb... And these same warriors are complaining about next.js, vercel, and serverless while barely kept maintaining a real fullstack app alive (yea, with real users, not like my gf) for more than 2 years (and not talking about a readthedocs site)...
As someone who uses HTMX EVERYWHERE (except native apps obvs) and I write all my apps in Typescript, the fact HTMX isn’t written in TS is actually a comfort to me. For a lightweight client-side library you absolutely want it to be as minimal and efficient as possible. TS isn’t that. Eliminating the build step and writing the code optimised for how it will be run is IMO the correct way to do a client-side script like this. Also you’re immediately protected from all of the future changes in TS, vanilla JS is always going to work, everywhere (well
except in IE11 … which can burn in fire as far as I’m concerned)
if IE 7
if IE 8
if IE 9
makes me want to break my computer
What backend do you use in htmx?
I’m primarily a backend engineer for my day job, but I am often complimented on my AMAZING front end skills. My secret: a really good overseas designer who makes Figmas for me, then I implement it.
Where did you find your designer?
@@AlexJaeger716 We worked together remotely during a hackathon in a community we were both involved in (crypto space)
I usually validate on the front end and back end because validation makes it easy for dumb users to not do something dumb, and validation on the back end makes it harder for a hacker to exploit you with a request. I also do this with permissioning where I'll ensure a request is limited to certain users on the back end, and won't even display the option to interact with the application in a way that I don't permit for dumb users.
Wait so it was Carson that ripped off Intercooler???
intercooler.js ripped off HTMX from the past. dirty time traveling library tricks.
This feels less like the author of HTMX engaging in some intellectual exercise where he challenges his own thinking and more like he's just making a straw man argument.
What are the real arguments against htmx then?
@@brandongregori995I'm not trying to find an argument, but just curious. Can htmx serve REST APIs? What happens if I have multiple types of client (Web, ios, Android, desktop apps) that preferably communicates with the same backend?
I'm not educated on htmx. Just asking.
@brandongregori995
It's troubling that you're asking- can people really not think of the drawbacks of having your UI running off websockets and http requests?
To spell them out for you, HTMX introduces an additional failure point at every event hook in your application. Yay, an onblur handler can now cause a 500 request error. It introduces latency in areas that had none and requires a web server where you didn't need one.
As a fun fact- there's demos on the htmx site that don't actually use htmx and run fake server code on the client. The author is very literally hiding the problems from you
@@Dipj01lol. Htmx is quite literally built for rest APIs - in the truest sense. What you're calling rest api is actually a json api, and is precisely the problem that htmx is addressing. He has many essays on these topics on the htmx site. They'll open your eyes to how far gone js web dev is
idk, these doesn't sound too strawy, i can see someone like Uncle Bob making those. There seems to be an inadequate amount of senior programmers who think that 10 line function is too long and that goto is unsafe. In fact, there is so much of them, that generative NNs refuse to show code with gotos to the minors, which is hilarious.
Why am I getting a Déjà vu from this? Somehow it feels like I've watched the entire thing before 😂
it's because we've all imagined having this same conversation with ourselves
You watched theos video lol
It must be the recursion of grep.
Plus I think this is the second time prime and Theo have both read articles sarcastically dunking on HTMX.
You probably watched it live on stream lol
On the components topic: thats like not adopting React because Angular has components and React doesn't back when React came out
Thanks for the react. I didn't get the points of this article when watching the theo react but this one helped me understand the content much better.
1:50 "should be purple to me" lmao.. what a nicely trainer hamster you are.. try changing the colors for a day and see how it messes up your visual cortex (no joke) ❤ luv your stuff, finaly someone who shows all those quiche eaters 🤣
Why you don’t want to build your ovn carousel, I think having external solution that fits all creates bloat. Writing your own carousel takes like 30min, and you’ll probably spend the same amount of time configuring external solution, and you won’t have so much bloat, bc you’ll end up with a solution that fits your specyfic case. Also using so much of external plugins makes me feel stupid.
The only downside that I agree with is that jQuery does the same thing and more. And since jQuery is always a part of my websites, htmx is redundant.
I prefer to work in languages with medium-sized ecosystems that not everyone has adopted, but a core group of smart people has. That way, I can trust that when I install a dependency, it has only probably moved through the hands of a few smart professionals who knew what they were doing.
Not using Typescript makes it worse, cause changes of errors are higher, but JSDoc seems to compansate for most problems. Another benefit of Typescript is that you can write ones and then generate commonjs and esm.
If it breaks, has inconsistent behavior, or restricts you from doing something you may reasonably want to do, then dive in and give constructive criticism. If not, why waste your time lol.
You don’t break open your walls to inspect your house wiring to make sure it has proper wire and cable management
Impressed with that first try compartmentalized, I kept failing with it yesterday
I enjoyed very much hearing about the "worse is better" movement or idea(?). The guy is teaching people 2 things: everything has pros/cons AND how to argue about things. Those things are totally lost, depending on which generation the person belongs to.
Is htmx worth trying out? I use ajax techniques and this seems like a logical next step. I hardly choose a js lib or framework, simply for the fact that html hardly ever gets used or any love; developers get to then forget or ignore what html already has to offer. Idk, I do want to try htmx. Attributes right?
If you only use html+js for the frontend, HTMX is definitely for you. With HTML you make boxes, with CSS you style them, with JS you make them functional, with HTMX you replace what's inside of them with data from the server.
@@CristianKirk ok I see
@@CristianKirk Holly shit, it is perfect for me. I do not create websites for a living. I just edit my lab website and don't want to spend a lot of time learning some convoluted framework like React.
I am using literally just bootstrap, JS, HTML and PHP (my college campus does not use dockers for website management. They just create a directory with the name of the lab that the user of the lab has rwx permissions).
@@vidal9747 and for simple client reactivity you can just use alpinejs
Maybe this is what people are saying, but non of this actually addresses the fundamental problem of htmx.
That it becomes virtually impossible to reason about the possible UI states.
In reat, I partition my input state into some set of equivalent classes, e.g. based on the combination of branches taken. That's already pretty difficult.
But think about htmx. Here every UI interaction is able to produce a new state of UI. So now you not only have to think about classes of equivalent input state producing your UI, but also about all the possible mutations. You need to recursively walk this graph. Describing the properties of this graph is a lot harder, especially when things start to get messy as they always do.
This is the reason why more or less every UI framework native or not of the past 10 years, has embraced some kind of declarative, reactive style. Nowadays the classical retained mode UI with imperative modification is a dying breed and rightly so. Declarative and immediate mode UI is just so much easier. Please don't take us back to the dark days.
You can do reactive programming server based, e.g. phoenix live view, Hotwire, etc.
Re: using Java code rather than Grep in an interview.
I had a similar question in an interview many years ago and they actually expected me to write code for the answer. I just replied with something like "I'm not sure offhand, but probably something with grep and awk."
They kept pressing on me for a code answer and I said "These tools have been around forever, have had many eyes on them, and are built for purpose. Who am I to think I can write something better?"
Still got the job.
power move
you would have won either way
Tbh, no matter how much we push HTMX it may never reach the versatility of using React/Vue/Angular.
Those just fits. Where it makes it really hard for me to choose HTMX for any project. Maybe a really static site, just plain simple sites.
LOL. JSDoc is the thing now?! I have been hating on PHPDoc for 10 years which is pretty much the exact same thing, but the last years the PHP community has almost completely moved away from that. Then comes javascript with their brand new thing that relies on it. That is pretty insane...
Modern modular Typescript - for f.. what? To have TS just to have TS? I don't understand that article at all
It's irrelevant if TS is in the code, you can still use TS, however, you need to transpile it anyway for compatibility - and yes we are ONLY talking about the frontend anyway.. Use TS on your backend (just don't) if you like
I really like JSDoc because it is easy to parse and generate a documentation site. I wrote my own parser for work that builds some JSON then I build a static site. Easy.
re: typescript thing -- I'm currently working with v8 of video.js and a plugin, both of which export types via jsdoc -> typescript d.ts files... it is HORRIBLE, video.js's v7 types made by the community were actually complete and good, but v8 now has `any`s everywhere, various things missing, and all classes are exported as default which prevents me from fixing them with my own d.ts file. There's so many issues I've ran into it's hard to put into a comment. Just really makes me doubt this "jsdoc is just as good" idea.
@ThePrimeTime Why you not brave verified content creator my g ?
This creator is not yet verified with Brave Creators. You'll be able to send them contributions once they're verified.
I feel like this article, hilariously, puts many pieces of popular but unbacked opinions in its arguments like the suggestions around React.
It becomes more apparent and funny considering the author is the creator of htmx itself.
This issue with cobalt isn't cobalt. It is big iron legacy systems and the stakes.
all this and i still cant figure out if htmx is actually real or just a meme.
gonna lean towards meme cuz thats fun
Did Prime adopted a cricket? 😅I kept on pausing the video to see if the cricket was chirping in my house.
Backend mvoes too slow? I will personally fold multiple frontend teams in half when it comes to delivery.
The author of this article is not nearly as clever as they would need to be to take themselves as seriously as they do
Finally, I'm SO waiting for this content since I watched the Theo video.
lol. I've watched it too
16:30 Backend validation because you need your application to work.
Frontend validation because you don't want excess server requests.
code duplication argument is not so relevant as you have mostly same data source for same "pages": if you show user page in app and on the website you still need to prepare data and then just throw html or json made from prepared data. and this works perfectly with let's say laravel with if (request()->wantsJson()) return { new UserDataResource($data); } and next just html (or other way around with hx header)
Sure you can do front-end validation for UX purposes, but delegating data validation to the front-end is wild!
I love using htmx with go..
Do you use templ or or templates?
@@patrickkdev go fiber templ sqlc htmx
Me too
Go(Echo) + htmx + temp + tailwind
Another go + htmx dev here, every line of code I write I love it more.
I don't use templ tho, maybe that will make me love it even more
@@AugustoCabrera I've been wondering if I should use the built-in templates, I did not enjoy templ a lot. Maybe I should give It another chance
Criticisms of HTMX are like Scheibe’s criticisms of Bach: “it is totally impossible to distinguish the melody. All the parts are alike as regards difficulty, and no single one stands out as principal part.” Well, duh.
Our gimmick is we don’t have one
would you consider HTMX to fall into the baroque category, or the classical?
@@y00t00b3r Grug category
The HTMX approach is rife with all the sorts of issues that moden front end dev has worked to address for the last decade and a half. Its an ok idea for simple stuff. It falls down under growing complexity.
The over engineering of the front end landscape has led to developer burn out to the point where people are willing to go back to 2005.
There is no other kind of software besides web afaik where this kind of server side ad lib authoring, delivery, parsing, and execution of UI and client application paradigm exists. Client application installed locally, data server remotely. Web application browser pages , sites and software is a strange beast.
My preference is Angular or vanilla. I just started with Angular back when it came out, appreciate that its fairly straightforward and easy to get the hang of, typescript and 'OOP' ish in the most basic sense, so you have clear structure and separation of concerns. Tried JSX a bit but to me Angular templates are so much more like just writing legible HTML. Never had the time or the opportunity to get too lost in the sea of framework and pipeline madness that came after it.
I also do work maintaining large complex legacy enterprise applications built in this 2005 HTML over the wire style, and its an absolute nightmare in terms if maintainability etc.
Not to be that guy, but COBOL programmers average salary in the US is on the low-end, about $82k, depending on what data source you query. Many other languages pay better, sometimes much better. The belief that it's high-paying is an MKUltra style campaign by IBM to convince people to learn COBOL, so the organizations still buying mainframes have programmers to lock in their basement.
This advertisement sucks
It's web dev. It's entirely inconsequential. Isn't it funny how these debates are always in the easiest software field?
It’s because they’ve never actually done anything beyond writing React. They think they know everything when they know nothing!
These are the devs that AI will replace!
I dunno, dude, as someone who hates web dev and does as little of it as I can get away with, the claim that it is "inconsequential" is just kinda weird. Like, I've been coding professional for 22 years, and some kid fresh out of college who knows (and cares) about all the different web dev frameworks is probably more useful to a typical dev company than I am, right now - salary adjusted, at least. They can get more useful features in the hands of their customers faster than I can. I write better, more secure, more reliable code in "harder" fields that solves harder problems faster and with fewer bugs... but I don't know how much that's actually worth any more.
But yeah, has to be said that all those different web dev frameworks each do their own thing, they're just each uniquely terrible in their own way, and so much of "the discourse" being about which terrible option is best really is exhausting. I'll give you that. But inconsequential? I wish that was true.
@@BittermanAndy web dev is about perception more than actual delivery of usefulness. It looks useful, but it just makes people angry. There are entire businesses I won't work with or shop at because of how bad their site is.
MBAs or whoever don't recognize this
A good interface means I never need to know about the filth that lies beneath.
18:39 There are no HTMX Job , Actually Alot of companies dont care about UI/UX for their Business Softwares but reliability so i use HTMX , i dont think i am not fist guy used HTMX for real-world SAAS projects and Small side Projects
+ I got alot of Extra Bonus through HTMX from Boss And Customers
HTMXs source code could benefit massively from typescript and other tooling.
It's VERY difficult to reason through things and figure out what the heck stuff is. I say that as someone who contributed a small part. It's very difficult to work with.
I think these reasons presented are valid reasons HTMX source is bad. This mostly doesn't relate to whether the tool itself is bad, which I don't think it is. It's just another way. I don't like when people say "it reduces the complexity" since it just moves the complexity...
thought this was not-sarcasting for the first minute and a half lol
I don't like to write long lifecycle projects in dynamically typed languages or in a single file, but HTMX is a 5k LoC code base written by one guy. If the author can fit all of this in his head without relying on separation of concerns, then more power to him. People have made great software while doing much worse. It's not great for team sizes more than 1 though.
Backend engineers make terrible ui - isn’t that why we have designers? I rarely had to design the UI, when I was working on front end, just build it.
The fucking mouse wheel making that scratching noise is driving me crazy
I've had a good experience sprinkling some htmx in a laravel app.
1:50 in the video and all I've got is that so called "JS programmers" cry about making them obsolete
Nothing against those JavaScript libraries for the right use cases, but they're victim to the dependency problem. There are corporate websites with 5-10 different jquery.js files (other frameworks too) that just wound up that way from employees adding things. it's alot harder for the employees to butcher HTMx that way.
That's until you have to make a sliding menu or something and have to install JQuery to power it.
Livewire is horrible, it should be seen as a dark pattern. its like they wanted to write more code in the backend then you would have to write in vuejs on the frontend. Besides that its easy for sure but its a trap
React does not use TypeScript as well :)
HTMx, making it even easier to generate pages full of identical, unclickable buttons with no URIs or graceful degradation to those of us who depend on assistive technology to use the Web. Big Browser doesn't care, either. The "state of the art" in Web Development is only moving BACKWARDS.
I wrote a CMS for a Forbes 500 company, in 1996, using Live Wire. Now they call it ssjs. Is it just "laravel" mispronounced, or is there a new "Live Wire?"
you need
a moderate dosage of self-hatred for past-self
as motivation to push future-self further
you can always do better
What is the name of the hoodie he wears in all his streams? Looks cozy as fuck
22:40 The comments when COBOL is mentioned are hilarious.
28:40 The girl on the left looks like the new Hak5 Threatwire presenter. 😂
Just in time for HTMX 2.0!
wat? I thought it has always been 2.0? 1.x was back in intercooler days. But either way, long time fan, love its simplicity
As a mostly backend developer I think HTMX is great and makes my job far easier and faster
Everything I know about web dev I've learned against my will. IDK how prime can take it.
This one was at least funny however.
6:01 Thaï script ?
I love thaï food , so I guess thaï script is great, right ? 🤪
The post is pretty funny, and sarcastic btw.
I'm currently using React for frontend and Golang for backend. It sucks having to keep track of types on two codebases, I'm interested in transitioning to HTMX. I've been researching the best tools and methods for making this switch, I'm not enjoying templ a lot. Could anyone share tips or recommend their preferred tools and practices for templates, JavaScript, and other aspects of using HTMX?
I also don't enjoy tailwind. I would rather write plain css
If you already know HTML and CSS, you will easily get a hold on HTMX and you're gonna remove all complexities from the front-end. Just give it a try.
Any non-trivial application is going to have a separate codebase for front end and back end, get used to it.
@@sneed1208 I am used to it. I have 4 apps in production and they all have separate codebases for front and backend. I would like to avoid it if possible.
Who would put validations on the frontend? Frontend developers.
Dear Prime. You don't understand what "DRY" means. I don't fault you, the term is widely misunderstood. But I cringe a little every time you mention it. Please read the section in the "Pragmatic Programmer", that introduced/popularized the term.
The quote: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
It has nothing to do with turning boilerplate into abstractions. It's not about repeating code and patterns. It's about having a single source of truth.
I'm pretty damn sure you violate DRY _very rarely_ on purpose. When you do so, you do it deliberately and carefully. Examples include caching, redundancy or decentralized knowledge. You know very well these things introduce very hard problems and we only reach for them if they provide a very compelling benefit.
Please at least read the article "Orthogonality and the DRY Principle" where the authors clear up these misunderstandings.
"Who would put validation on the frontend?" No, this is wrong, please don't listen to this advice. People trying to fuck with you is a small minority of users, but due to outsized impact you defend against that. But everyone else is just an ordinary user, and you're also working with ordinary devs, and if you do validation on the frontend then your backend teams will be so much happier. Validation on the frontend is immediate ROI.
Backend and frontend teams should be sharing as much validation and types as possible, and double-validation is not wasteful and is very common industry practice.
i give it a try for 10 minutes and already give up
This might be the greatest satire ive seen in my life
I just wonder what Oak Ridge wants with a single HTMX dev...
HTMX should go the way of jQuery.
That is, it should become an integral part of browsers. It is 2024 guys, AJAX is soon 30 years old. Can't we make that part of the core HTML spec? Pretty please with sprinkles on top?
The only issue I'd have is to have a clear definition of an HTML snippet - clearly many of the endpoints you create in HTMX are not 'really' valid HTML urls (unless I'm missing something). Some sort of extended HTML tag?
oh, and, btw, that "dressing down of HTMX" or whatever article that is linked inside there, is actual garbage and hateful (including transphobic language somewhere at the very end). I don't recommend reading it.
Generation Z's two favourite logical fallacies, are the appeal to popularity, and the appeal to modernity. In other words, the two methods of determining the worth of anything, are to first ask if it is less than five minutes old, and if everyone else likes it. I know that some of you will unironically agree with this, as well.