PHP/Laminas dev here, this was an excellent webinar. Really neat to see how htmx can make the choice of backend almost immaterial - this video is 95% as useful to me in PHP as it is to your main audience in Python. Just used our first sprinkling of htmx in our software, and we are already thinking of exciting ways to make more use of it.
This is the best intro video to Htmx. I am a Laravel and PhpStorm user and it works just great here too! Thank you both for the awseome intro! I just made search on one of my sites dynamic. It's been quite a bit of fun not having to write a single line of JS and not mess with Json and reactive libs.
I spent that last 18 months evaluating many different possibilities to upgrade the UI of a software (Java backend). I decided to go with HTMX from the first sight. I think I fell in love again and this time seems to last.
in my opinion HTMX is a smaller, more perfect and easier to use version of the technologies we have already used in the past. and it's a great little tool that shows how the technologies we will use in the future should be. why I praise it so much, because it's so good :D
Just discovered htmx, must say I love the idea. First thought is however: Which UI widget library is good for this? Most current decent UI libs are for React. Any suggestions?
Awesome webinar! Thanks you! HTMX looks like a breakthrough to eliminate the huge complexity of web app development. Especially for the small apps that I need all the time for internal tooling. Life changing. Would the example code from the webinar be shared somewhere?
Hi, thanks for watching the webinar, and I agree that Carson has really hit a nerve at this particular moment. My demo code is a garbage dump. I tried to make it do auto reload on changes, and tried to get the static/FastAPI/Django to share a common code base and run in the same ASGI server. It's not in good enough shape to upload. My goal though is a really good demo that can be run with `pipx run htmx_demos`
Htmx is awesome, but one downside I see, is that one binds the backend to the presentation, whereas with just JSON getting exchanged, how it's presented visually is more cleanly separated from the backend
Ehm... If you're using MVC (like most mature frameworks are) I see no problem for the Backend to serve presentation/HTML. It was actually meant to be that way when frameworks like Rails, Django, Laravel etc. were made and it works perfectly well. Much better than for SSRendering react or similar.
The separation of concerns argument for the heavyweight front ends is based on an illusion. If you consider what the back has to know about the front; users, authorisations, interface contracts, business rules, etc. There really is no separation, just overhead. The back is quite capable of doing the separation via its templates and rendering engines..
Very interesting concept! One tiny piece of advice to the interviewer is maybe to give the other person some more time to finish their thought 😅 the constant short-cutting / interruption is a little bit off-putting.
htmx is part of the rise of "low code" - it makes things work quickly (less code) without having to know what's going on in the background - it's a type of assembler, isn't it?
10:55 "javascript frameworks are encouraging server-side rendering"… I'm surprised: wouldn't it be a win for big companies to send just data fragment and offload the HTML rendering on the client side? Where can I find a presentation of the rationale for server-side rendering?
A few years ago it was all client side rendering, but now the trend has gone back to server side because it provides faster loading times for slower devices. Better user experience means more time on the website, which means more money
@@eddierandom6074 The reason you are struggling to understand is because no one talks about what situations make one better than the other. Server side rendering is important when SEO or potentially when you want to make sure that the user’s device is not the limiting factor of how your site runs. Client side rendering is important when you want the user to have an “app like” experience. Maybe you want the user’s device to maintain a certain level of interactivity even when their connection drops for a few minutes at a time. This should not be a CSR vs SSR discussion, it should be an explanation of when each different tool in your toolbox is appropriate. Also, many of the big JS frameworks that are pushing that they are “ssr” now are server side rendering the initial page load but then they re-render(hydrate) the page again and from that point forward they are a CSR app unless the user reloads the page. This initial ssr is important for SEO heavy sites like Ecommerce site but may have little to no impact for some dashboard or app you are creating and it comes with a lot of mental overhead. I hope that answers your question of “why”.. :)
Finally, something that communicated my frustrations with how creating UIs nowadays are so complex. HTMX is the way!
PHP/Laminas dev here, this was an excellent webinar. Really neat to see how htmx can make the choice of backend almost immaterial - this video is 95% as useful to me in PHP as it is to your main audience in Python. Just used our first sprinkling of htmx in our software, and we are already thinking of exciting ways to make more use of it.
This is the best intro video to Htmx. I am a Laravel and PhpStorm user and it works just great here too!
Thank you both for the awseome intro!
I just made search on one of my sites dynamic. It's been quite a bit of fun not having to write a single line of JS and not mess with Json and reactive libs.
htmx is the answer to handling uncomplex stuff just as easy as i thought it should work when I started web developing more than 20 years ago. :-)
I spent that last 18 months evaluating many different possibilities to upgrade the UI of a software (Java backend). I decided to go with HTMX from the first sight. I think I fell in love again and this time seems to last.
in my opinion HTMX is a smaller, more perfect and easier to use version of the technologies we have already used in the past. and it's a great little tool that shows how the technologies we will use in the future should be. why I praise it so much, because it's so good :D
I feel so excited about htmx, finally i can get rid of js from my project and focus just on python.
@Paul, Carson very interactive and informative webinar, not a second to look anywhere else :-)
Very cool webinar - had it on my lwatching list for weeks, not I finally made it. Thanks a lot!
[PT-BR] Sou programador backend e odeio JS. Ainda estou no começo do vídeo e já estou emocionado com as possibilidades. Obrigado!
starts at 13:00
Thanks for htmx. It's great.
This is killer. Planning a quick demo app with it soon.
Just discovered htmx, must say I love the idea. First thought is however: Which UI widget library is good for this? Most current decent UI libs are for React. Any suggestions?
Awesome webinar! Thanks you!
HTMX looks like a breakthrough to eliminate the huge complexity of web app development. Especially for the small apps that I need all the time for internal tooling. Life changing.
Would the example code from the webinar be shared somewhere?
Hi, thanks for watching the webinar, and I agree that Carson has really hit a nerve at this particular moment.
My demo code is a garbage dump. I tried to make it do auto reload on changes, and tried to get the static/FastAPI/Django to share a common code base and run in the same ASGI server. It's not in good enough shape to upload.
My goal though is a really good demo that can be run with `pipx run htmx_demos`
@@paulweveritt if you could share it it will be really helpful for me, follow alone with the code an the video it will be a hit
@@jorgeav527-xyz Hi the material is here github.com/pauleveritt/fastapi_webinar
Just learned python and golang. Two languages viable to combine with htmx with a SQLite db from Turso makes a really fast stack.
Carson Gross, what about security issues (for examples OWASP) like XSS?
Htmx is awesome, but one downside I see, is that one binds the backend to the presentation, whereas with just JSON getting exchanged, how it's presented visually is more cleanly separated from the backend
Ehm... If you're using MVC (like most mature frameworks are) I see no problem for the Backend to serve presentation/HTML. It was actually meant to be that way when frameworks like Rails, Django, Laravel etc. were made and it works perfectly well. Much better than for SSRendering react or similar.
The separation of concerns argument for the heavyweight front ends is based on an illusion. If you consider what the back has to know about the front; users, authorisations, interface contracts, business rules, etc. There really is no separation, just overhead. The back is quite capable of doing the separation via its templates and rendering engines..
I'm starting a new project and I'd like to use htmx. But I need something to fill in the gaps. Maybe plain JS to handle oauth code sign ins.
awesome demo. would you have the demo live somewhere ?
I don't have the live demo available but the code is here github.com/pauleveritt/fastapi_webinar
Very interesting concept! One tiny piece of advice to the interviewer is maybe to give the other person some more time to finish their thought 😅 the constant short-cutting / interruption is a little bit off-putting.
with htmx i could create reactive web page with Django templates. 🎉 without jQuery
htmx is part of the rise of "low code" - it makes things work quickly (less code) without having to know what's going on in the background - it's a type of assembler, isn't it?
Hey it’s grug!
10:55 "javascript frameworks are encouraging server-side rendering"… I'm surprised: wouldn't it be a win for big companies to send just data fragment and offload the HTML rendering on the client side? Where can I find a presentation of the rationale for server-side rendering?
A few years ago it was all client side rendering, but now the trend has gone back to server side because it provides faster loading times for slower devices. Better user experience means more time on the website, which means more money
@@eddierandom6074 The reason you are struggling to understand is because no one talks about what situations make one better than the other. Server side rendering is important when SEO or potentially when you want to make sure that the user’s device is not the limiting factor of how your site runs. Client side rendering is important when you want the user to have an “app like” experience. Maybe you want the user’s device to maintain a certain level of interactivity even when their connection drops for a few minutes at a time. This should not be a CSR vs SSR discussion, it should be an explanation of when each different tool in your toolbox is appropriate. Also, many of the big JS frameworks that are pushing that they are “ssr” now are server side rendering the initial page load but then they re-render(hydrate) the page again and from that point forward they are a CSR app unless the user reloads the page. This initial ssr is important for SEO heavy sites like Ecommerce site but may have little to no impact for some dashboard or app you are creating and it comes with a lot of mental overhead. I hope that answers your question of “why”..
:)
Delete should return 204 MO CONTENT