Maybe HTMX Is Bad...

preview_player
Показать описание
Recorded live on twitch, GET IN

### Article

### My Stream

### Best Way To Support Me
Become a backend engineer. Its my favorite site

This is also the best way to support me is to support yourself becoming a better backend engineer.

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Рекомендации по теме
Комментарии
Автор

The proposal to reimplement htmx in React is just cursed, no matter what mental acrobatics you perform to rationalize it

YaroslavFedevych
Автор

9:27 "it (React) is effectively a virus that spreads through your entire web app" ... LEGEND

albertoarmando
Автор

This framework does not support my strong requirement of "Shoot myself in the foot." Therefore, I hate it.

JChen
Автор

Author: *has issues with HTMX*
*issues with HTMX don't quite make sense*
*reveals they're trying to use HTMX and React at the same time for some reason*
Well there's your problem!

TricksterRad
Автор

"This Hammer is a bad Screwdriver"

DirkFedermann
Автор

I don't know why you would ever mix HTMX and React. They are two completely different approaches to frontend.

The-Funk
Автор

This article is React brain trying to understand something but ultimately not liking it because React brain

Kwazzaaap
Автор

If this person just inherited this project and this was how it was written and there was no time to rewrite it fully into one land or another, and they were trying to make the best of it, this article might mean something. But really this just comes down to, I tried to wedge a square that I called a banana into a triangle that I called a squirrel and it didn't make a good lizard. I really would not want to hire this person for work.

martingardnerii
Автор

HTMLX + React: That really feels like trying to marry a submarine with an air plane. Even a rowing boat would be better to transport bananas between continents.

I would love to have a chat with the project manager who thought this can possibly be a good idea. Especially when they propose time lines and budgets.

michaelutech
Автор

The first few paragraphs are solved by the very simple principle of "replace the content, not the parent". I can't think of many situations where these problems wouldn't be fixed by just changing children, as the parent is usually the one holding state (like a form element, or any Alpine.js component)

dpgwalter
Автор

9:36 and the question is: is this an Htmx problem? Is this a React problem? Or is this a 'you' problem for trying to use both at the same time?

rikschaaf
Автор

Someone doesn't understand the internet HTMX is how the internet started and adds a sprinkle of magic to make it easier. Takes me back to the days before jQuery and ASP, PHP, etc.

daninmanchester
Автор

This article is basically: “I somehow don’t realize everything has quirks, limits, and use cases so I’m pretending only htmx does.”

JohnSmith-opls
Автор

This guy didn't get the memo that htmx + SSR saves you from writing a single line of react

sczoot
Автор

I really like HTMX, but I found in practice Alpine JS with Alpine AJAX is really what I wanted, and what I think most devs coming from a frontend framework want. Alpine to me is the silver bullet. No build step. Declarative component behavior, including dynamic css binding or client side form validate to cut down on server trips. Can inject HTML fragments from the server while maintaining client state like dropdown menus or whatever.

I highly recommend Alpine JS. Also, I always loved Vue’s syntax so Alpine’s adoption of it is like a perfect storm for me.

cherry-ep
Автор

React is fine. HTMX is fine. Svelte is fine. Astro is fine. NextJS is fine. Laravel is fine. Remix is fine.. etc. this cultish for and against anything is super stupid.

If you're Senior / Staff, you know what to do. Pick the right tech, you know what you're doing. If your mid or jr. pick a popular framework or just use PHP and the raw DOM--whatever you can get the most support on, and focus on building something. One thing I do recommend is for mid/jrs is just use a monolith and SQL.

mrgerbeck
Автор

JavaScript kiddies never learned anything outside of a framework and can't comprehend htmx

gardnmi
Автор

Mixing htmx and React, then crying that htmx fucks up React ... looks kinda dumb. Hate this frontend bloat. Recently did htmx with a rust backend using sailfish as the renderer. That's insanely fast and a really small "frontend".

oefzdegoeggl
Автор

We used web components to build our widgets - the self-contained styling really helped us to avoid conflicting the CSS rules that customers might have on their sites.

flipperiflop
Автор

I see this as a JavaScript issue in general. It is similar to the issues had back in the day with LISP and Smalltalk, where a half-dozen expert practitioners are guaranteed to come up with a dozen personal moon languages. On the one hand, it is super cool that you can malloc up an amazing DSL quickly, on the other hand you end up with isolated silos of capability which can't be intersected because they are based on entirely different core abstractions. Almost always there are caching and other optimization strategies required to make the abstractions viable, which bakes the differences into the system and makes crossing the streams almost impossible.

I don't know what the solution is, because we have also evolved such a sprawling browser ecosystem, so that you almost require some sort of core system to help make focussing decisions for you, just to get some forward momentum going.

ScottHess
welcome to shbcf.ru