Suddenly some accidental transitive dependency that you didn't even know existed and that is not even used by anything can completely change the behavior of your app...
A component with its styling, markup structure, and behavior, is one concern. These components can than be combined and nested in every which way you need, they are very modular.
If you separate concerns into markup, styling, behavior, than this form of component-based reuse is difficult. But it could conceivably be easier to reuse an html template or css class for different features.
Hooks are also a way to separate concerns in a different way than lifecycle methods. Lifecycle methods group code by specific points in a component's life, but then the logic can't be extracted and reused. Hooks on the other hand encapsulate reusable logic that can then be used in different components.
Did it though? I've worked with React for some time, and we simply put all the non-view things into separate modules, or at least separate functions. React is (still) a library, it doesn't prevent anyone from mixing the layers and making spaghetti.
Unfortunately, in capitalism that’s too much to ask, because it would improve everyone’s lives except the ad industry’s.
Perhaps some sites can be excused from this because they really do fall on the app side of the document–app spectrum. Google Maps comes to mind, but Facebook? They’re just bad internet citizens.
I guess the point is not so much that you could do those things, but that it was fairly common during ‘the jQuery days’ to do as the author describes.
You just need to come up with CSS and JS that are not _specific_, but _layered_ instead, which is hard.
Bad:
.one-specific-button-from-the-nav-bar { color: blue; }
<input class="one-specific-button-from-the-nav-bar"/>
<input style="color: blue"/>
nav form button { color: blue; }
Then you have two options:
- Abandon the idea. Do something simpler.
- Come up with a generic CSS rule for it.
For this idea to work, _you have to accept limitations_, which means you cannot design whatever looks you want, or make pixel-perfect layouts, etc. You have to work within some constraints.
On the other hand, I know a lot of very smart folks who like the tailwinds approach, and I do acknowledge the difficultly of naming CSS classes, that the function metaphor breaks down due to the fact that CSS classes have non-encapsulated effects on child elements, etc.
Interesting case to think about.
[1] - https://htmx.org/essays/locality-of-behaviour/#surfacing-beh...
A. Your content is a document. A semantic HTML document, boring, mostly made of text.
B. You can make the document alter parts of itself with JS. You don't mess with appearance here, just change the boring document content.
C. You can make the document look good by applying some styles to semantic HTML tags.
If you respect them, you get both LoB and SoC neatly arranged into meaningful layers.
--
Tailwind-like stuff breaks semantic HTML. Classes like ".flex-7" are about style, not the text. CSS classes should be stuff like ".introduction" or ".cooking-ingredients".
It makes documents otherwise simple to read into a mess. Now there's appearance concerns hidden in between the content. It's bad.
--
All good rules come with great exceptions. In this case, stuff like Google Maps. You can't really represent it as a document. But that's rare on the web.
Somehow, people were convinced to use those "frameworks for rare use cases" to make simple documents, forms, etc.
--
Local <style> tags fall into this category of exceptions. Sometimes you need some extra style for a content that is unusual, but that's the exception. Most websites want to look consistent across all their published content.
/page1, /page1/click1 (bad)
/page1, /page1?htmx=click1 (good)
Then have a common server pattern for how you inspect the request to determine which fragment (or whole page) to respond with.
With this, navigating HTMX code is much nicer because you only have to identify one entry point instead of hopping through the codebase to identify the N different URLs and view functions that support the page.
The development principle still stands, however, and, like all dev principals, has trade offs associated with it.
Can you ctrl-click on an href attribute and go to the definition?
Actually, you can and you should–this is a best practice for building maintainable apps. You shouldn't be hard-coding 'magic string' API paths throughout your views. You should factor them out into variables and then use those same variables for both routes and views.
Many good routing systems have this functionality.
eventsource demo from http://server/demo
on message as string
put it into #div
end
on open
log "connection opened."
end
on close
log "connection closed."
end
on error
log "handle error here..."
end
(DRY was never about code repetition).
Swizec•7mo ago
joshmanders•7mo ago
Ehhh, only seems that way because you're so entrenched in React with minimal htmx experience.
I've used both pretty extensively and they both feel similar in the magic aspect, except htmx is cleaner.
alexvitkov•7mo ago
yawaramin•7mo ago
recursive•7mo ago
pier25•7mo ago
I've had the opposite experience.
Htmx does work for simpler use cases like submitting a login form. Beyond that it gets messy very quickly as you start introducing more backend endpoints for every little interaction. In some stacks you have template fragments[1] which alleviate this problem somewhat but still, htmx doesn't scale for more sophisticated interactivity.
And most projects will still need client-side interactivity. So now your features are a mix of htmx stuff, something client-side (Alpine, Vue, whatever), and probably some HTTP endpoints to interact with the client-side stuff.
You also still need to take care of CSS which htmx completely ignores because it's really just a low level HTML exchange protocol if you will. With Vue, Astro, or Svelte you can encapsulate markup, behavior, and styles in a single file.
And on top of all that, the DX is quite frankly terrible compared to doing frontend with something like Vite with hot module reloading. Most backend servers need to restart and maybe even recompile the whole thing. PHP is the only exception I know of since every request "runs the whole application".
[1] https://htmx.org/essays/template-fragments/
mock-possum•7mo ago
<button @click=${fetch(‘/clicked’)}>
qn9n•7mo ago
zdragnar•7mo ago
mock-possum•7mo ago
PaulHoule•7mo ago
I worked on a system (Themis) for creating ML training sets for big corporations which would basically show a screen that has the user make a judgement and then show them another screen and so forth.
We had to develop this thing at a breakneck pace and if it was successful, I'd have the expectation that we (or the customer) would always be developing new models and new tasks.
As it was this system had a React front end and a "microservice" back end in Scala. Everything was packed up and deployed with Docker. The engineering manager didn't believe me when I said that it took 20 minutes to turn around the smallest change in this system so we timed with it with a stopwatch and we measured 18 minutes. Notably if you want to add a new task you have to change more than one back end process and update the SPA. You had to be a skilled front end and Scala developer to change things yourself and if you're working on a team you are going to have a lot of back and forth which slows things down.
I had a counterproposal (Nemesis) that I've been using for Centaur processes [1] that I develop on my own account which is an old-school site enhanced with HTMX.
A task is implemented in a Python file using the flask API with a class that has a few flask methods for HTTP endpoints and a small number of Jinja2 templates which draw the HTML. [2] Adding a new task is a matter of adding a new class and a new template and deploying it is super-easy, turnaround on a flask server is instantaneous, it's just a few seconds with a production gunicorn server. It takes less programming skill than Themis, a new task can be created by cut-and-paste-and-modify or be vibe coded without risk of breaking other tasks.
Since it doesn't have lots of images, chrome, Javascript, metadata in the <head>, ads, trackers and crap it is crazy fast. On my tablet, going the wrong way on an ADSL connection, over wireless and my phone's hotspot, it feels like using a desktop application. The app has plenty of screens that do visualization with d3.js and other things with Javascript where necessary. If I had a task that required a very complex interaction then I could write an tiny SPA just for that task with React, Svelte or whatever I wanted.
[1] Human processes some tasks, AI processes some tasks, AI gets trained based on human performance
[2] The exact same architecture would work in Java with JAXB
yawaramin•7mo ago
Try making your React example do what the htmx one does. That's when you'll see the complexity start to creep in.
lblume•7mo ago
yawaramin•7mo ago
tshaddox•7mo ago
I don't have strong opinions about this particular React/HTMX example, but I don't love this statement because it seems to be dismissing the possibility that some tools are better than other tools for a particular job.
Swizec•7mo ago
I think these are 2 dimensions. Great engineer + right tool is obviously the best combination. Great engineer + wrong tool can work surprisingly well. I have never seen the other 2 combinations produce elegant results.
But really what I was trying to say is this: We're just smearing complexity around. UI is hard. The component model won for a reason. Use whatever syntax you prefer, they're all fine, but please use composable components of some sort to build your UI.
yawaramin•7mo ago
- https://www.fastht.ml/
- https://github.com/yawaramin/dream-html/tree/todoapp/app
In fact if you look at how htmx is recommended to be used, you realize they specifically are recommending a component-based architecture: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-i...
Swizec•7mo ago
yawaramin•7mo ago
marcosdumay•7mo ago
The previous favorite one used to be "a bad craftsman blames his tools", that people that liked to impose bad tools on others repeated all the time. But that phrase got old.
perching_aix•7mo ago
Does this not scream "just the distribution of outcomes can drastically differ" at you?
Swizec•7mo ago
Yes. My argument is that outcomes depend more on the people than tools.
perching_aix•7mo ago
I tried to model this formally (well, to the extent I can model anything formally), cause this is a fun little exercise in a way, and got that at least as far as my toy model goes, it's a wash, both matter equally (since at the extremes, they will approach each other's distributions, i.e. the distribution of expertise or the distribution of tool choice).
Or to be more specific, what matters more is what you can change more, something I only accounted for in the very end. And I don't think significantly pushing the needle in expertise, especially in a way that persists over time, is realistic. People need time to gain expertise, so those with majority expertise will always be a minority. But improving tooling and doing so with long lasting effects is much more realistic. Hence, good tooling that leads your hand matters more. It raises the bar, and automatically ensures past mistakes aren't repeated without a need for costly rediscovery or specific training.
Swizec•7mo ago
Think of frameworks as "distilled experience". They help the next "generation" go faster because they don't need to make all the same mistakes. This is awesome.
But it is not magic. People will make a mess. Often because they hold the framework wrong and/or miss what it's trying to do for them. Or just don't grok the author's beautiful vision.
However, an experienced practician groks the fundamentals and can quickly adapt to any framework. Because all the frameworks are built on similar fundamentals so it's easy to hold them correctly. You go "Ah, the author believes X, so if we just assume X, it all falls into place and the code looks great".
That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". The thing that doesn't fit may be the current team/experience moreso than the business domain.
At the end of the day more experienced engineers will produce a better solution than less experienced engineers. For a variety of reasons. Good tools can make less experienced engineers ramp up faster.
perching_aix•7mo ago
> That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better".
Agreed, this is always the money shot. I further think that the holy grail for advancements is for them to lead people's hands in a way that is self-justifying. It's a very tall and cruel order, but I think it's absolutely essential. If a solution fails to do this, people eventually turn on it, and adoption reverts or otherwise falls apart. I'm particularly worried about this happening to e.g. Rust, but this can be applied to basically anything.
wvbdmp•7mo ago