I'm on the HTMX struggle bus right now
HTML-код
- Опубликовано: 9 сен 2024
- Become a YT Members to get extra perks!
www.youtube.co...
My Products
🏗️ WDC StarterKit: wdcstarterkit.com
📖 ProjectPlannerAI: projectplanner...
🤖 IconGeneratorAI: icongeneratora...
Useful Links
💬 Discord: / discord
🔔 Newsletter: newsletter.web...
📁 GitHub: github.com/web...
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
Love ur consistency man. All this craving for learning new things, Very inspiring.
Really enjoying all this Not-NextJs content. I'm very much into all SSR and Htmx right now. Please keep the Htmx help vids rolling 🙂
I may be jumping the gun as chiming in as I saw it, but when you have that inconsistent state with the server at around 2:45, I’d probably aim to re-render and swap out that whole block underneath "Current List". Like whenever an action that should affect the "Current List" (add or remove an email), you render that whole block on the server then swap it out with HTMX. The ownership from first glance seems to be split between the FE of HTMX and the BE code. Something that revaildatePage in Next just does for us.
Yeah, I think that’ll make the code based more maintainable honestly. To me it felt kind of silly to send back a list of 2000 emails. If the user just adds one more to the list but treating entire sections just block you refresh is probably simpler.
once you want something dynamic in that way, would it be better for Alpine to handle that conditional fallback? You can have Alpine listen (x-on) for a rowsUpdated or rowCountChanged event coming from the HX-Trigger response header or you can do a js trigger via hx-on::after-request="htmx.trigger('#myList', 'myEvent')"
htmx is pretty event oriented.
This makes me more interested or at least intrigued on HTMX but cannot lie, this remind me of PHP + JQuery.
We still have a dead website deployed based on Drupal, custom PHP pages with heavy jQuery. When I feel low, I like to visit it's codebase time to time.
This
Me personally, I’ve opted to using full stack js (remix in my case, can be next for you) plus golang. I feel like the full stack frameworks do UI exceptionally well, but struggle on any real backend work. So I do all the database calling along with all micro service work on the golang end, and all that remix or next does is call the golang endpoint and render. With this setup, everything is super simple. Deploying is super simple because I just use the default bundler config, and I just use sst and it works fine with the default config because ALL my js is doing is talking to my golang backend. React is extremely good for frontend. Golang is extremely good for backend. Use both.
Yeah this makes sense to me. Where I work we use .net core for backend because it's pretty powerful and developers like using it. Frontend just calls API endpoints served by .net core backend and that's it. Backend devs even annotate API endpoints with OpenAPI annotations so on frontend we just run a script that generates a full HTTP client in Typescript with all types coming from backend. I think it's a great developer experience and each team uses the technology they like using. Haven't seen any real drawbacks so far to be honest.
I see your direction and I had considered something like this too. However there are drawbacks, like you can't as easily share your request and response types between TS and Go, and if making a breaking change, you need to co-ordinate deploments between two different services with probably two different release pipelines. It's an extra service itself that you need to monitor and configure your tools (CI, coverage, etc). Also makes integration tests tricky, since you need to spin up your frontend and backend that are now in separate projects and languages.
Not saying the approach doesn't have its advantages, but these considerations just convinced me to leave the API in written in Node in the same project as the React app.
@@oliverhughes169 Very insightful. I think the OpenAPI code-gen thing might fix the type issues, but everything else you said is completely true and valid. I'll still test a big project with this setup to see how it compares just for skill development and experience, but these will 100% be challenges I'll probably face. Smart comment!!
I gotta tell you, I'm in the same boat as you. I have a co-worker talking up htmx for it's simplicity and trashing Next.js and react for its bloat and over complexity. I've been trying htmx, but man, I'm just missing Next. Especially when you said it feels vanilla javascripty, ooooof I felt that. Not trying to head that direction.
You're comparing pure tools with yes, bloated frameworks, the experience never will be the same
@@serge8085 Fair point, but I’m really responding to people who say it’s a better alternative as a blanket statement. I disagree.
@@serge8085 yeah the difference is with bloated frameworks you'll have a job and with pure tools you'll get fired
ruclips.net/video/2rP4vHPbelU/видео.html
Frameworks are objectively bloated and subjectively, with dependencies and all, complicated for the wrong use cases, though. Say a near static single or double page app, you don't strictly need React or Next for that. Blanket statements are generally not true (if HTMX was so much better, why would anyone still bother developing frameworks like Next or React?). At the end of the day they are just tools, and proclaiming that one is overall better than another is like debating that hammers are better than screwdrivers. A hammer can be better suited to drive a nail than a screwdriver, without either class of tool being bad for it.
@@Shr11mp the way to use it is entirely different. I'd never write my applications like the way shown in the video - not maintainable...
When you first start with react it takes a couple of months to be great at it, its the same thing here...
I've been able to write JS for a very responsive/client-friendly social network with 500-1000 lines of code... Its not unmaintainable mess.
If you know Pocketbase, the embedded admin dashboard it deploys is actually pure svelte, and the memory footprint is still really small. Maybe you should look into that instead of HTMX.
And the backend of Pocketbase is Go
@@dominicgerman5908 yes, the front-end is deployed by pocketbase itself which makes it super lean.
@@dominicgerman5908 yes, the front-end is deployed by pocketbase itself which makes it super lean.
Hey Cody. When I first began web development, I was trying to learn react native. I knew virtually nothing and had a problem with my web socket implementation. I reached out to you on discord and you took the time to help me understand my problem further even though you could almost certainly tell I had no idea what I was doing. A few years later, I'm now working at a company developing mobile apps using react-native. I just want to thank you for remaining passionate and helping people like me understand web dev.
Awesome glad I could help in some way!
In your earlier video, you talked about preferring simplicity over complexity (dependencies), and I totally agree. Templ and frameworks like Vue or Svelte need extra IDE dependencies, which always seem to break or miss something. I know Go has a native template package, but Templ feels more natural to us JSX abusers. About your vanilla JS 'rant' these days, HTML and CSS have almost everything we need for native web components. I'm hopeful that once this is fully developed, SSR solutions will get even better. Hell, that's probably the moment I ditch the SPA world all together.
Love it!!!! Love you!
You're the best!
This ecosystem is still new, but the experience I've had with GoLang and GoLang with Templ is definitely what I want for the future. I am willing to start dedicating my time to contribute to the Templ LSP and to improve the plugin for both VsCode and JetBrains' GoLand. I hope more people will see the potential and decide to contribute to open source, making it better and better! This stack "GoLang, Templ, HTMX, and Tailwind"is amazing. My enthusiasm for building full-stack apps has been completely restored.
HTMX is, like, 15 years old lol
@@Ss-zg3yj Templ is less than 2 years old
Great progress report. I’m learning a lot from your experience.
"I kinda miss Next.js" sounds so funny idk why lol. Anyway props to you to see and show us the other side. The grass always looks greener on the other side, as people said. Also you might learn a thing or two on your way, so I would say nothing valuable will be lost.
I really find the balance in using react for frontend with tanstack and using go for apis.
I didn't watch the whole video (again), but about your first struggle and paradigm shift (funny it took only 15 years to shift back): your templates are your HTML, the same way as JS template engines work (don't have a tool name from the top of my head), then you hydrate your template with the data, the same way as you doing by passing JSON to whatever magic handlers JS toolset provides.
In short: you have the same separation of logic, data and presentation, executing on the back and throwing ready to parse HTML to the front.
You should always add vanilla action and method attributes to forms so that they would work even if js is disabled or failed. Also, try htmx multi-swap extension, it makes life easier by allowing to pick and swap multiple fragments from a single response.
I’ll check that out. It sounds like oob swaps but from the other angle
So far, I've found the multi-swap extension to be redundant. I use:
hx-swap="none" hx-select-oob="#id1, #id2, #id3"
Creating an aspnet core project using HTMX and Alpinejs. Keep running into antiForgery errors whenever I submit forms :rip:
there is no free lunch with any tech, btw with the memory issue that you day on railway, have you tried to profile it? or just use pm2-runtime to restart the container when it reaches too much usage
Using fasthtml Python framework made me rethink how I understand htmx, and now I've gotten better at it as a result
HTML/CSS/JQUERY/GO is the new radical stack
You could also return status 302 with a "Location" header to make the client go to another url. That is what i did. So much fun seeing someone explore the same things i am exploring as well. Except I am using Astro to serve my endpoints. But I also want to find some time to learn some Go. It's on my list of things i want to learn. I do think we have a tend where web dev is going back to basics, and I am excited for it. Awesome video.
You can use css to only show some element if your list has no children.
One day I hope it comes back full circle and people would just use jquery again and learn how the plugin system worked.
I have been writing lots of complex stuff in HTMX. Your issue with the login screen is because you are not using a progressive enhancement approach. The form in the login page should be designed to work without JavaScript, which means the backend should return a redirect response after a successful login. Then you simply add hx-boost to the form element so htmx will do the request and follow the redirect accordingly. Without hx-boost and progressive enhancement mentality, you will struggle. I have been there.
Good info, I’ll try those out
The series is great! Awesome to see someone proficient at React taking a stab at HTMX without fanboying
And tbh, without a proper LSP, HTMX feels like Spaghetti code for a proper interactive app.
Rails/Laravel/Phoenix have their own solutions. So ultimately it’s up to Python/Go community to carry the mantle on this. Which might take awhile
Another issue is that you are not using hx-select. Your swaps are too granular. You don't need to have small pieces of UI that you manually replace here and there. Try to have bigger UI components that you can either swap the whole thing or just a piece of it using hx-select. You are still approaching it from a data-driven approach it seems.
I think there is no need to panic when id not found. Overall nice progress 👍🏻. You tha best
Which backend technology do yo suggest to learn as a frontend developer to be a fullstack developer? Python , Go or Nest.js itself ?
Excellent video! I'm super excited by htmx and the idea of trying to simplify the frontend, but it's hard to find content on htmx's pitfalls and without that I can't judge whether or not it's a really good alternative to React. I'm looking for people who have used it in projects seriously enough such that the bad parts become evident. Thank you for posting this!
I think a lot of the struggles come more from "unlearning" certain patterns that you get used to from those frameworks. For me i find htmx to work best when mixed with different model, so as .net dev it is either with MVC razor for older projects, for blazor for newer ones. Generally doing everything in htmx would be / is in fact pain in the butt, buuut again it is for simplicity. HTMX isn't there to swap entire page loads etc, it's to dynamically update elements on html.
I commented back then that I wouldn't like to see HTMX videos, but this is not bad because you talk about it normally without trying to make the tool look good or hype it 👍👍.
If ur using the native go templating library to serve ur trmpates, the file extension can be html. I just make mine .html instead of .tmpl and that solves the intellisense issue mostly
Been using pocketbase as extended framework + astro js and svelte with client islands, man what a beautiful stack, it feels you are not missing anything
htmx would have been a lot more fun and interesting to work in a world where we only had vanilla javascript or jquery. The fact that we don't have to write a lot of javascript would have been way more appealing then. With the all the frameworks present today and more coming in every day it does feel like one needs to change their mental model when using htmx for anything more serious than a todo list. You need to think to all the html you will return with each request rather than just worry about data, so the entire UI becomes dynamic rather than just the data.
I doubt Neovim would solve the issue the "Go to definition" issue you described. I suspect it's an issue with the language server implementation of Templ which would affect all editors.
As someone who hasnt done any traditional server rendered stuff i really struggled with htmx so im glad im not the only one. I tried using it with astro as i gave up with the poor experience of templ but even in JS land its been pretty rough and slow going
I'm just curious-are you moving faster and writing less code with this stack compared to Next.js?
Moving slower right now, but honestly it’s mainly because the tooling around templ and htmx isn’t the best. Like air reloading with the proxy freezes up constantly forcing me to close my browser tab. Go is very verbose compared to node which is a pain
The entire time I've been using this stack, I've been wishing for some multi-language lsp to exist that would have go to definition for htmx tags, same thing for templ templates. But I wouldn't work on it, because I'm lazy and I don't understand it.
I admit I haven't invested much time to learning htmx either, but I also had the impression that it was a step back in term of developer experience compared to a traditional js frontend.
Maybe that goes away with more experience though
This feels like code that I wrote over a decade ago... and the reason why I learned react. That didn't actually feel that simple, what would a medium size app look like? Or am I just stuck in typescript brain and don't get it...
Have you thought or tried using html with python with fastapi and jinja2 for template rendering? I’m curious to try Django next but just want to know if you had any thoughts on it?
Htmx *
I’m not a big python fan to be honest
@@WebDevCody ah I see is there a particular reason or just preference?
I’m using plain react with go. Love go, it’s simplicity and speed. Htmx is definitely not mature for production-level apps. Will you stick to go?
I like go, but ultimately I’m trying to be as productive as possible and I don’t think this stack is it
Hey Cody! I'm loving your newest videos. I wanted to ask, I saw that you are using Railway for hosting your apps. Any advice on how to backup the databases there?
There is a template which you can use to backup your Postgres database to s3 if you want
@@WebDevCody Thanks! Do you mind sharing the link if you have it?
this seems miserable, i guess this is your learning experience for figuring out, devex is worth paying for, be it memory or performance
I'm planning to use react SSR with Rust/Go instead of HTMX. It would increase my speed of development and keep resource usage low once you build out the react app and not use V8/bun.
Maybe that's something that would help make the transition easier?
If you are using SSR React you will be using a lot of resources in V8/bun, because your server running React is where most of your performance will go
@@julianlindner1568 Not if you build the react project and use go/rust as the server to render things in SSR. V8/bun is only used during development.
Neovim user here, temple lsp doesn't work well either in neovim. It's something that has to be addressed in general. The gD or go to Definition or go to reference or what ever does make sense to me that goes to the actual go file and not the temple one, I don't have much of a problem with that, not ideal but meh. But the suggestions that an lsp would be suggesting, are definitely needed and missing.
Try updating your Templ cli and lsp. They fixed this recently in Neovim around June I think. If you still have problems, just bind restarting your Templ LSP (restarts effectively instantly) and it should go to the correct gd.
JSX/TSX feels great with HTMX. You might like it a little better with Hono or Elysia
I believe it
IDK HTMX seems more complex than React to me! Maybe I've developed React brain 🧠
Thanks!
You bet! Thanks for the super comment!
Kinda wonder how easy is it to make reusable components with a templating engine? For example, a button component that has dynamic optional attributes applied or dynamic optional classes applied. Most examples I see just use something like a normal html button element. Wonder how hard is it to create a button component with some base classes applied, but consumers of the button component could optionally apply additional classes as arguments to the button component like you can do in most spa apps?
You can style different buttons and pass in what kind of button you want via properties. Furthermore you can pass in on demand customization that gets appended to class. (With tailwind ofc)
@@Zipp3rZero Is that the spread attributes in templ?
could you try pocketbase (extendable with go) + react to see how the DX and everything go? I like htmx, but building a lot of components that react community already had is a bit too much for me.
What does pocketbase give me? I don’t get it
It's a major step down from nextjs dev experience! It's safe to say htmx is in its infancy
Thanks for the overview. It seems that DX is not that good for making rich UX-friendly frontend 😢
IMHO, it suits the ToDo list like frontend development only.
I think it's fine for basic CRUD apps or internal/admin applications where you don't want to overcomplicate things. I don't see anything more complicated than that being a nice experience to build this way, with this stack.
The more important thing is to know when to reach for something like HTMX and when to reach for something like React (or Next.js).
I appreciate if you tell us honest opinion after all, without looking at other "influencers" about this crap. Because this getting ridiculous and harmful. I feel sorry for newbies getting brainwashed by folks telling them to use HTMX.
Templ seems like JSX just worse.
I’m so much slower using htmx and everything looks like 💩
Lol yeah the dev experience of building web apps in Go takes a hit when coming from Nextjs. Thats why I still use next on frontend and proxy all /api/ to my Go echo backend
This, the proxy ssr is always my go to, if I want to optimize SEO related things
when you proxy like this, do you feel your app takes a hit since now you got two server requests?
Really curious what the real life experience with this pattern is since I like meta frameworks for their frontend conventions but hate their backend system
I think you are using HTMX for the wrong use case. this project seems like a strong case for Next or SPA with an API backend. I see HTMX as any other template language like Jinja or mustache. it is intended for displaying simple stuff which don't need much interactivity. i would actually use this for a landing page that need some dynamic content. Not for this.
same, I'm thinking state management is a HUGE pain. Imagine writing all the dependencies update logic and syncing it with the frontend
Same issues here
next.js till i die
It looks ugly. I know because it's probably a lot of new stuff for me, but that syntax looks harder even if you get used to it
Use AlpineJS
inb4 someone suggests htmx would be perfect if it just had a version of useState, then slowly htmx just becomes another complicated javascript framework
What a nightmare! It’s like buying a 1992 car while having they money for the 2024 version of it. You pay for commodity somehow… either you get the more performant version but with a horrible DX or you use the extra MBs of memory and get a better work flow…
So happy with react… and the extra resources used by it in more than willing to accept. Nowadays, that’s not even that big of a factor
"...still a lot of developers who use vscode"
Its a bug theyre definitely going to fix. Its not like that for me in nvim
Unfortunately there is always a trade-off between stacks
ngl. this specific framework looks awful to dev with
I don't understand why you're doing a network request to validate a password regex. You shouldn't think of HTMX as a tool to completely replace client-side interactivity. If you are mutating state then you should save the state in a DB and use HTMX to replace the new UI resulting from the state change. Use whatever client library you want for interactivity that doesn't mutate state.
You don’t understand why I’m validating a password on the backend?
I warned you, friend! You will end up Grepping substrings of those templates, because even Go is a golden treasure in my opinion, the majority of the community are Neanderthals who loves to work with sticks and stones, and that's why there's not enough people to advance with the dev. Tooling like in JS land
I thought go devs were supposed to be smart? Why are they not making the tooling?
@@WebDevCody They are smart indeed, but you know those cousins who can solve Rubik cube under 5 seconds, but needs you to cut up their chick nuggets into triangles otherwise they don't eat?
@@danielmajer1648 ☠️ 😆
"Do this for me or I'll whine that you're alienating me"
“Make better tooling for this, or others won’t want to use it”
neovim sucks
Geez, now I wonder why this stack isn't really popular 😮💨
best ides where things just work are from jetbrains. Dont know tho if they have an ide for go
They do it’s called GoLand. It’s great! Never used templ with it though
GoLand is excellent
They do -> GoLand