[HN Gopher] Why Gumroad Didn't Choose Htmx
___________________________________________________________________
Why Gumroad Didn't Choose Htmx
Author : rmason
Score : 235 points
Date : 2024-10-03 18:45 UTC (4 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| smallerfish wrote:
| > For instance, implementing a drag-and-drop interface for our
| workflow builder proved to be a significant challenge with htmx,
| requiring workarounds that felt clunky compared to the smooth
| experience we could achieve with React libraries.
|
| HTMX is better if you have a frontend bundle that does just
| enough but no more. Hook into the htmx.onLoad event and then look
| for markup with attributes in the content being loaded (for
| example, columns, cards, tasks, etc) to attach to. You can then,
| for example, bind sortable.js onto the rendered markup, and then
| wire sortable events to state updates via HTMX. Really pretty
| straightforward. They even have an example of exactly this in the
| docs: https://htmx.org/docs/#3rd-party
| gen220 wrote:
| Yeah, I've been using HTMX with UIKit components. Having a
| modern, stateful, and dynamic website is definitely not
| incompatible with HTMX.
| zackerydev wrote:
| This is a wonderful advertisement for the things that HTMX is
| good for and the thing it isn't.
|
| It's obviously tongue-and-cheek but I think it makes the case
| well!
| tptacek wrote:
| Why is this tongue-and-cheek? Doing this sincerely is a huge
| confidence builder.
| ensignavenger wrote:
| What makes you think it was tongue-in-cheek? It sounds quite
| genuine to me?
| nasretdinov wrote:
| Perhaps because of pages like this one:
| https://htmx.org/essays/htmx-sucks/ (note the URL)
| ensignavenger wrote:
| Different authors and very different tones, but yeah, that
| essay was tongue-in-cheek, so I guess I could see why you
| might think that at first. I thought it might be, when I
| saw the title, but then I read it and realized quickly it
| was sincere.
| recursivedoubts wrote:
| :) this isn't tongue-in-cheek it was a real experience
|
| the htmx sucks essay was definitely tongue-in-cheek though
| (although many of the criticisms were legitimate, and even
| agree with this one, such as the lack of a component
| ecosystem!)
| bumbledraven wrote:
| Kudos to htmx.org for hosting this essay.
| dannyobrien wrote:
| I really do value services/tools that explain why you shouldn't
| use it, as well as why you should.
| jamal-kumar wrote:
| It's really humble and honest of them to put something like
| this up but in the end at least they have something to point to
| now if people pick it up and get mad that it doesn't meet their
| needs
| recursivedoubts wrote:
| we also have this essay to help people decide when htmx (or
| hypermedia more broadly) might be a good fit:
|
| https://htmx.org/essays/when-to-use-hypermedia/
|
| and then this tongue in cheek essay (many of the criticisms
| are legitimate):
|
| https://htmx.org/essays/htmx-sucks/
|
| We also have a mug for people who don't like htmx:
|
| https://swag.htmx.org/products/htmx-sucks-mug
| svat wrote:
| Yeah it's linked from https://htmx.org/essays/ under "On The
| Other Hand..."
| nasretdinov wrote:
| I like how they compare server-side validation with React's
| client-side (only?) one.
|
| Wasn't able to relate to other puns all that much unfortunately.
| rozap wrote:
| Yea this piece is often left out and is kinda the most
| important. A single set of validation, on the server is
| required. There are tons of reasonable solutions with different
| tradeoffs for how you run that validation on the client. But
| two duplicate sets of validation or client only validation are
| two very, very dark paths.
| nsonha wrote:
| Comparing it with React is a low bar, since a lot of people are
| unhappy with React.
|
| Arguments like "React is popular, AI knows it", or "React is
| popular, lots of component have been written in it" seem weak.
|
| A proper antithesis for htmlx should compares it with SPA.
| simonw wrote:
| HTMX can be used as a tool for building SPAs, so I don't think
| it makes sense to compare it with SPA.
|
| What's an SPA if not a single web page where clicking on things
| causes that UI to update in-place in different ways?
| mardifoufs wrote:
| And a lot of people are happy with react. Not sure what your
| point is. I mean of course people using a more niche framework
| will usually be more happy about it, because early adopters
| usually choose to use the technology.
|
| Like, it's rare to come across htmx (or svelte, or solid) in a
| corporate job for now, which means that almost all of their
| users like said frameworks enough to use and talk about them in
| their free time
|
| For react that's just not the case, because it's _everywhere_.
| If I was forced to use Vue, I wouldn 't like it. But I'm not so
| I don't use it enough to criticize it a lot.
|
| If anything I've seen more people dislike angular or vue when
| they _had_ to work in a project that used those frameworks, and
| didn 't have a say in that choice. But that's _also_ just an
| anecdote obviously
| croes wrote:
| [dupe] https://news.ycombinator.com/item?id=41727315
| nop_slide wrote:
| Gumroad dude seems to have some shaky reasoning for migrating at
| all, sounds to me a migration just for the sake of it.
|
| https://news.ycombinator.com/item?id=41669615
| mardifoufs wrote:
| I mean, he clarified his reasoning and it made sense. Why do
| you think that moving away from RoR involves shaky reasoning
| here?
| recursivedoubts wrote:
| My comment from the other thread:
|
| The CEO of gumroad mentioned on twitter that he had tried out
| htmx for a project but decided to go with NextJS instead. I asked
| him if he was willing to write up his experience and he
| graciously agreed to do so. I have been looking for a thoughtful
| negative experience with htmx to host on the htmx website and I
| am very thankful he was willing to put in the work to produce
| one.
| kunley wrote:
| Very useful explanation, because at first it seemed unusual to
| see it on htmx.org, but well, different projects have different
| needs.
| ensignavenger wrote:
| HTMX has posted links to negative articles before, but I am
| not aware of any as thoughtful as this one. So it wasn't all
| that surprising for me that they would share this. That they
| went out of their way to solicit it is extraordinary, though!
| hencq wrote:
| Your attitude to call out where htmx might not be the best
| solution, makes me respect the project even more. It's
| refreshing to see this compared to lots of other projects that
| always seem to claim to be the best solution for everything.
|
| I'm curious in particular about the call out around drag-and-
| drop. Is that something you agree with? Is drag and drop
| difficult with htmx and if so, is that something you plan on
| tackling?
| recursivedoubts wrote:
| There is an htmx demo on drag-and-drop (in the reorder sense)
| using Sortable.js here:
|
| https://htmx.org/examples/sortable/
|
| Like most of the examples on the htmx site it is pretty bare
| bones (we keep it that way to focus on the concepts) but it's
| a reasonable demonstration of the integration. Whether that
| is good enough of course depends on your use case
|
| If you want an integrated and polished ecosystem that's
| something htmx isn't going to provide: it's a library focused
| (mainly) on one thing: generalizing hypermedia controls. So,
| when you want client side functionality like this, you are
| going to have to glue things together a bit. I completely
| understand the desire of having an integrated ecosystem to
| avoid doing that.
| hencq wrote:
| Thanks! That actually seems very smooth. Trying out htmx
| has been high on my list for a while when I finally get
| time to do a little personal side project. Real life keeps
| getting in the way, but this is a good nudge. The appealing
| thing about htmx to me is that it seems like it should be
| very easy to keep everything in your head.
| DevX101 wrote:
| I've never seen a project highlight a negative use case in
| detail. This is a first.
| giraffe_lady wrote:
| It's not quite the same but SQLite has a page where they
| clearly present its limitations and how to identify the
| situations where you should choose something else.
|
| https://www.sqlite.org/whentouse.html
| recursivedoubts wrote:
| We have a similar essay up on when to use
| htmx/hypermedia:
|
| https://htmx.org/essays/when-to-use-hypermedia/
|
| I think it's a good idea for any software project to have
| something like this so that people know when it's a good
| fit and when it isn't.
| x0x0 wrote:
| I've used hotwire a bunch, and with minor differences, I
| think the list of things that htmx is not good for is spot
| on.
|
| I don't think I'm explaining this well, but maybe this will
| help someone: Hotwire / htmx are about server-side rendering
| and making that work more smoothly with the client. eg fewer
| page navigations, more rapid update of the client, etc. But
| it's still, through and through, server render with server
| state.
|
| It works well as long as the server is always the source of
| truth. The things that it isn't good at, such as drag and
| drop or complex, multi-state forms on the client side, are
| basically because you temporarily have a split source of
| truth: the client is the source of truth with complex state.
|
| That said, my strong suggestion would be to use Hotwire or
| htmx for 95% of your project even if the main interaction
| loop is done in react. Your app will still likely have tons
| of crud around user management, settings / config,
| onboarding, etc. You can make all that work more nicely.
|
| edit: in case it wasn't clear: for the things that are in the
| hotwire/htmx wheelhouse, the tech works really well. It's a
| fantastic improvement.
| rikthevik wrote:
| > 95% of your project even if the main interaction loop is
| done in react
|
| The trick is to be very honest with yourself (and team)
| about how much complex front-end UI the application
| actually _requires_. Using React where it isn't necessary
| is very expensive in the long run. The older I get, the
| more the grug brained developer makes sense.
| Freedom2 wrote:
| Agreed. Too often you'll see HN's claim that PHP / Java /
| MySQL are the best choices for everything, where often times
| they are blind to specific problems and use-cases that other
| developers are trying to solve.
| ksec wrote:
| >Too often you'll see HN's claim that PHP / Java / MySQL
| are the best choices for everything.
|
| Either this is missing /s or this is trolling, right?
| freedomben wrote:
| Indeed. Even if hn were a monolith and all had the same
| opinion, it certainly would not be a pro PHP, Java and
| MySQL position.
| laserlight wrote:
| > other thread
|
| https://news.ycombinator.com/item?id=41727315
| dakiol wrote:
| Is it just me or the article smells like AI-generated?
| wild_egg wrote:
| You can see the evolution of the article in the PR on GitHub.
| Seems genuine.
| rmbyrro wrote:
| Your AI smell sensors need more training data to reduce
| hallucinations.
| tuyiown wrote:
| This is a great initiative. Too much people with little
| experience with non trivial web are vocal about htmx, and it's
| not a good thing for the projet.
| n3storm wrote:
| thank you so much, I am a user since intercooler.
| recursivedoubts wrote:
| based, thank you
| pseudosavant wrote:
| Much respect for showing where htmx might not be as suitable as
| other tools. In my mind htmx is more a replacement for jQuery
| than React. htmx and jQuery both augment documents with
| interaction. React tries to be the entire document. Different
| tools for different jobs.
| ksec wrote:
| >The CEO of gumroad mentioned on twitter...
|
| He also mentioned Rails in itself is a technical debt. And when
| asked about it all he said was React is so much better. As if
| you cant use React with Rails.
|
| As for the article, I dont see it as a negative experience for
| HTMX. As soon as he mentions drag and drop, real time
| collaboration, I will go on to say may be even toying with HTMX
| was wrong in the first place?
|
| I am also not sure what the screenshot was trying to show.
|
| But all of that, I think it is a great pieces to be on HTMX
| website.
| nine_k wrote:
| I would say React is (so much) better because it's
| functional, immutable, one-way, almost declarative. In
| comparison, stuff like ActiveRecord is very imperative,
| shared-mutable-state thing. For React-based code you usually
| take a language with a rich static type system (TS); Rails
| with its design-by-contract struggled to provide type
| signatures, last time I checked.
|
| One of them is much easier to reason about than the other,
| even though the other is enviably compact.
| freedomben wrote:
| React is a client-side library. Rails is a server-side
| framework. I don't see how you can even really compare
| these apples and oranges.
|
| Personally, I think rails and react go together very well.
| For apps that need rich client-side functionality, I will
| do a react spa with a back end in elixir/ Phoenix (which is
| very similar to rails).
|
| For apps that don't, just doing server-side rendering is
| plenty sufficient and is my preference.
| nine_k wrote:
| I'm only comparing development experience and, so to say,
| the conceptual environment.
|
| Verily, Rails can be a pretty good and compact way to
| serve backend APIs for a React-based frontend. But the
| API boundary is the "narrow waist", its relative
| neutrality allows to switch backend and frontend
| implementations easily, or even mixing them. I've seen a
| React frontend seamlessly consuming APIs served by Python
| and Rust services, and it's hardly possible to spot which
| endpoint is served by what in the frontend code.
|
| Unlike on the frontend, FP approaches on the backend are
| not (as) widespread. Established imperative frameworks
| (Django, Rails, Spring Boot, etc) are still the huge
| majority.
| simonw wrote:
| "For example, when building complex forms with dynamic validation
| and conditional fields, we found ourselves writing convoluted
| server-side logic to handle what would be straightforward client-
| side operations in React."
|
| Anakin Padme meme: "You still implement validation on the server-
| side as well, right.... right?"
| mplewis wrote:
| Yes. But you do it once at submission, not once per page.
| pier25 wrote:
| What's the difference?
|
| You can split the validation in multiple functions/modules
| which you can then use both at submission or per step/page.
|
| Also, it seems you're implying having two validation systems
| (on the client and server) is actually good?
| yarg wrote:
| Yes?
|
| You want to validate on the client side because it reduces
| latency and improves responsiveness.
|
| You want to validate on the server side because you cannot
| trust the fucking client.
| code_biologist wrote:
| Validating in multiple places doesn't mean 2x the code. You
| can validate on both the client and the server using the
| same code. One of the charms of server-side JS.
| skydhash wrote:
| If your web form is more complex than a paper form, maybe
| rethink the former? I can not think of a form that can be
| implemented easily in react, but is difficult in Htmx other
| than wishing to plug in a React-like global application state
| and having the job 90% done as libraries.
| codazoda wrote:
| I just looked at this iPhone alarm clock on Gum Road, which I
| also read about on HN. The page describing the clock is
| janky. Slowly scroll down the page (with a track pad) and it
| will jump up and down erratically as you get past the "Add to
| Cart" button. Hover your mouse in one vertical position on
| the page and it will turn the header on and off over and over
| again.
|
| https://fatiharslan.gumroad.com/l/dieter-rams-inspired-
| vinta...
|
| Maybe I'm a Luddite but I just get the feeling that we've
| gone very wrong in our over-engineering.
| fsndz wrote:
| I will start using htmx as soon as there is a 20K MRR startup
| built only with it.
| jonathan-adly wrote:
| My startup using htmx was there - and it was acquired
| successfully.
|
| They migrated pretty quick to react after the acquisition due
| to team dynamics (offshore big teams - seeped into JS heavy
| client, thin server culture). htmx was a struggle there as
| well.
|
| It worked amazing for us as a small team where everyone was
| full stack and I always build using htmx-first now. But, it is
| a struggle for folks who have been working in React-like
| patterns for 5+ years and never experienced the bless of MVC
| apps.
| WD-42 wrote:
| Kinda wild that there is an entire generation of web devs for
| whom server side rendering is actually the new, strange
| thing.
| fsndz wrote:
| convenient. I would have liked taking a look at your apps
| built only using htmx
| learnedbytes wrote:
| The difference between a 20k MRR startup and lower will almost
| certainly not be because of HMTX.
| fsndz wrote:
| this is true in theory but not in practice. just read the
| article, they came up to the same conclusion. if you want to
| offer a slick UX (a key element to convince users to pay
| these days) htmx won't cut it.
| shortrounddev2 wrote:
| I literally only ever hear about htmx from YC. I still don't know
| what the point of it is, it seems like one of those opinionated
| programmer things like "I don't use a framework" or "you don't
| need javascript to make my site work"
| ensignavenger wrote:
| HTMX is getting a lot of attention from other communities to,
| another one I am part of is the Django community, which talks
| about it a lot.
| thruway516 wrote:
| It's for python programmers who think front-end is an
| unavoidable evil but wish to avoid it anyway.
| nasretdinov wrote:
| Why just Python? I feel excluded as a Go dev
| thruway516 wrote:
| To front-end devs you all look the same
| sergiotapia wrote:
| it's kind of the elm for javascript. vocal enthusiastic fans
| but no real usage beyond that miniscule enclave.
| gumbul wrote:
| The uncle who wrote the tool is probably a friend of the
| moderators here. He thinks that changing the texts in the
| element with a few xhr functions is a great success. I've seen
| very few guys as weird as this guy.
| ketzo wrote:
| > AI and Tooling Support: It's worth noting that AI tools are
| intimately familiar with Next.js and not so much with htmx
|
| This is stated as a very matter-of-fact downside, but this is a
| pretty crazy portent for the future of dev tools / libraries /
| frameworks / languages.
|
| Predictions:
|
| - LLMs will further amplify the existing winner-take-all, first-
| mover nature of dev tools
|
| - LLMs will encourage usage of open-source tools because they
| will be so much more useful with more/better training data
| ryanchants wrote:
| I was considering this other day. AI tools are stuck at a
| particular point in time. And even training them on newer
| stuff, there's only so much information to train on. I've been
| exploring this being a _good_ thing. In software we spend so
| much time chasing the latest tooling, language features,
| frameworks, etc. Maybe it'll be a positive that it all
| stagnates a bit and we just use the tools we have to get work
| done instead of creating new hammers every 6 months.
| treyd wrote:
| The problem is that for most domains our hammers are still
| pretty bad.
| mattgreenrocks wrote:
| Agree. A lot of the most popular libraries/frameworks are
| not necessarily the best. Removing more fitness checks will
| only worsen this problem.
| davidhaymond wrote:
| I had written a comment addressing this as well but you beat me
| to it. In a way it is similar to the effect StackOverflow had
| on popular libraries, but amplified. Even without
| StackOverflow, a library can do well if it has good
| documentation. I'm not sure if the same holds true with LLMs.
| diggan wrote:
| My prediction is that it'll be like this for a while, but as
| soon as tooling becomes better and the context of current APIs
| + local files gets better taken into consideration, this
| "advantage" will disappear.
| ClassAndBurn wrote:
| This will not be true for future frameworks, though it is
| likely true for current ones.
|
| Future frameworks will be designed for AI and enablement. There
| will be a reversal in convention-over-configuration. Explicit
| referencing and configuration allow models to make fewer
| assumptions with less training.
|
| All current models are trained on good and bad examples of
| existing frameworks. This is why asking an LLM to "code like
| John Carmack" produces better code.. Future frameworks can
| quickly build out example documentation and provide it within
| the framework for AI tools to reference directly.
| riffraff wrote:
| I don't think convention over configuration causes LLMs any
| problems, GitHub copilot generates code matching rails
| conventions quite easily for example.
| freeone3000 wrote:
| Because there's enough rails code in the training data to
| determine the proper conventions :) if you're making
| something new without this glut of data, it's going to be
| much more difficult for a coding assistant to match a
| convention it's never seem before.
| skydhash wrote:
| The thing is, with some elbow grease, you can write a
| great plugin for your preferred editor. No need for
| dubious LLMs results, especially when the difficult part,
| code intellisense, is already solved with LSP. If you're
| a shop that has invested in a framework, it would be
| cheaper and more productive.
| jimbokun wrote:
| But the new frameworks will never have anywhere near the
| amount of training data as established frameworks.
| jimbokun wrote:
| And:
|
| - developers will be incapable of writing or debugging code for
| development stacks or project types without LLMs trained on
| lots of matching examples
| spankalee wrote:
| I'm not too worried about this, and I think Gumroad's concern
| is likely overblown. I can't tell from their comment whether
| they actually experienced AI being bad at HTMX, or if they
| transitioned to talking about other resources.
|
| LLMs are often wildly good at being universal translators. So
| if they pick up general patterns and concepts in popular
| frameworks, and enough syntax of more niche frameworks, IME,
| they do a pretty great job of generating good niche framework
| code.
|
| Similar to how they can talk like a pirate about things things
| pirates never said in their training data.
| rmbyrro wrote:
| In my experience, ChatGPT and Github Copilot are
| significantly worse at htmx compared to mainstream tech. They
| hallucinate A LOT more.
| ffsm8 wrote:
| > they do a pretty great job of generating good niche
| framework code.
|
| If you mean plausible looking code, yes - totally!
|
| If you mean actually usable code: nope. Its always riddled
| with imaginary library calls that don't exist.
| alexpetros wrote:
| > LLMs will further amplify the existing winner-take-all,
| first-mover nature of dev tools
|
| This will be true _for people who rely on LLMs to code_ , which
| I strongly suggest is not a great long-term bet for a software
| engineering career.
| jimmaswell wrote:
| I still think it's a perfectly fine productivity multiplier
| to use as long as you still understand what you're doing.
| alexpetros wrote:
| There's a very clear skill ceiling on the kind of code for
| which LLMs can serve as a productivity multiplier.
| MetaWhirledPeas wrote:
| Yes. And no matter how good LLMs get at coding there will
| always be a crowd intentionally doing it themselves,
| especially in the open source arena, if only just to keep the
| joy alive.
| SrslyJosh wrote:
| If your devs can't work without something writing their code
| for them, why are you hiring them?
| tom85 wrote:
| Maybe they are just faster with AI.
| Shawnecy wrote:
| I don't think it's so split between they can and can't. It's
| probably more about how it impacts velocity.
| cheema33 wrote:
| > If your devs can't work without something writing their
| code for them, why are you hiring them?
|
| I am currently in the process of hiring a backend engineer.
| Anybody who does not use AI to aid development work gets an
| automatic disqualification. In my experience, a good engineer
| using AI tools will run circles around a good engineer not
| using AI tools.
| johannes1234321 wrote:
| It's not about "being able" it is about being efficient.
| There are many cases where current AI can provide boilerplate
| and good examples for doing something specific, which eases
| things a lot.
|
| There is a lot, of course, one can't take 1:1 into the final
| product, but it helps to find the right libraries, helps to
| find patterns, the right parts/functions to use where
| verification in the applicable documentation or source is a
| lot simpler than finding it in the docs to begin with.
|
| Using it as a tool, while not a source of truth can be good.
|
| And don't get me started about writing all the boilerplate
| which sometimes is needed, which is too complex for a simple
| editor shortcut, but too tedious for me as a human. That I
| review and fix a lot faster than create by hand.
| wwarner wrote:
| respectfully disagree. i think that the value of llm
| suggestions are driving us toward a kind of standardization
| that is really good. we'll all be java programmers soon!
| WD-42 wrote:
| Here is what I don't understand about this post: if they knew
| they needed complex ux with realtime collaboration, why did they
| even reach for HTMX to start with? The author could have spent an
| hour going through the HTMX docs and would realize it's not a
| good fit instead of wasting who knows how much time actually
| implementing it.
|
| This reeks of ad-hoc vibe-driven development.
| jokethrowaway wrote:
| I use Htmx to add little functionality to static pages and it
| works great.
|
| I used it recently to build a small crud admin page and I soon
| reached the limits of the technology; in the ends I rewrote it in
| solid.js - because next.js / react are pretty slow and employ the
| wrong abstractions.
|
| I think htmx for static + solid.js for interactive is a great
| combination - albeit I dream of a framework which will excel at
| both.
| recursivedoubts wrote:
| https://data-star.dev combines ideas of htmx & solid (signals)
| and might be of interest to you
| hermanradtke wrote:
| I don't understand why the screenshot of the view on the right
| could not be created with htmx (or any UI framework/library).
| mattrighetti wrote:
| > I thought htmx could be a good solution to keep our front-end
| super light.
|
| It seems htmx stopped working as soon as you gave up on the
| _super light_ frontend part :)
|
| You started using third party libraries to render complex UI/UX
| and state management.
|
| Also, I'd like to point out that saying "it was easier to do X in
| React" is not really fair if you did that using third-party
| libraries. It's just that somebody did it for you so that you
| didn't have to.
|
| I sympathise a lot with what's written in the post actually but
| in this case I think that htmx was not a good solution from the
| start if you knew you needed to manage complex states and
| rendering.
| WD-42 wrote:
| Exactly. I'm a big htmx fan, but I think this post displays
| some serious lack of technical awareness from the author. More
| like they wanted to try out HTMX based on vibes as opposed to
| its actual strengths and weaknesses which would be apparent to
| anyone with even a cursory knowledge of the web platform and
| the docs on htmx.org
| chuckadams wrote:
| It sounds to me like they shared a learning experience.
| appendix-rock wrote:
| Yeah, without having the foresight to know that Hacker News
| would come after them with very disingenuous
| interpretations of what they've shared, because HN
| commenters are so used to spending all their days having
| internet arguments that they take everyone as a personal
| attack.
|
| Nothing in this post indicates that the author doesn't know
| any of what all these people in the peanut gallery are
| snarkily lecturing about, FFS. Working in the open must be
| so difficult.
| d0mine wrote:
| htmx vs. javascript reminds me behave (BDD) vs pytest tests:
| Gherkin language looks nice in simple cases, and it can be in
| principle extended for more complex cases, but pure python
| (pytest) becomes the more convenient the more complicated tests
| become (when it is necessary to manage several levels of
| abstractions.
| mikeocool wrote:
| It's kind of a nice compliment to all of the "we converted our
| react app to htmx and everything is so much better" articles
| written by people who probably shouldn't have used react to
| begin with.
| ensignavenger wrote:
| I love that HTMX is posting this (and other similar things) on
| their site. It seems like there were a lot of legitimate reasons
| why HTMX alone was not a great fit.
|
| I am not a frontend specialist, but I do find it interesting, but
| here are some of my thoughts on the points made:
|
| 1) Don't they have to validate forms on the backend anyway? What
| made it so difficult to get their backend system to communicate
| back up to the frontend? There are absolutly great reasons in
| many cases to do form validation on both the frontend and
| backend, so in those cases you would want more than just HTMX,
| but I am a little confused at the phrasing of this issue?
|
| 2) HTMX alone may sort of push apps in this direction. In some
| cases that is a good thing, but apparantly they decided they need
| to do somthing different for their customers. I hope it was a
| good decision for them. I do think HTMX could be used effectively
| to make a site much less CRUDy, but I can't really argue with
| their results in this specific case.
|
| 3) This is an interesting argument. I would love to know more
| about how this team using AI tooling and has become so dependent
| on it that this was a major issue for them. It also brings up an
| interesting question for the future- if AI dev tools become a
| major thing, will it raise the bar too high for new
| frameworks/programming languages to get enough tooling an
| integration for adoption? Not particularly relevant to Gumroads
| decision making process, but an interesting line of thought.
|
| 4) A common complaint with HTMX. I think some projects just
| require more than just HTMX provides. Maybe future HTMX plugins
| will fill in this gap though?
|
| 5) Certainly a legit issue. One reason I like Django (and even
| Python) is because of its deep community of integrations and add-
| ons.
|
| Perhaps they would have better luck with something more full
| featured like https://unpoly.com/ would fit their needs better
| than HTMX, while still being similar to the concept?
| sergiotapia wrote:
| I completely agree with the author that AI has problems with more
| niche language/frameworks.
|
| when I prompt for rails stuff, things work right out of the box,
| and it makes great suggestions. (although this may no longer be
| the case for rails 8 - solidqueue/cache/etc are out that are
| totally new!)
|
| when I prompt for elixir/phoenix stuff, I usually have to paste
| in documentation or it hallucinates features or worse, suggests
| very dated ways of doing things that no longer apply or even
| work!
|
| react/next has so much volume of data that the AI must be cracked
| on it fr.
| arrowsmith wrote:
| Which AI are you using for Elixir/Phoenix? I find that ChatGPT
| is as you describe for Elixir, but Claude writes Elixir very
| well.
| sergiotapia wrote:
| I only use claude sonnet 3.5 for code, it was the last leap
| before ai llms become useful for coding for me. it's all
| butter moving forward!
| joshstrange wrote:
| There is never a "one size fits all" and I get frustrated with
| people that say "SPA for every project" as much as those who say
| "SPA is always wrong". Picking the right tool for the right job
| is incredibly important and, as this post mentions, finding
| something that will scale with your project is important.
| andyjohnson0 wrote:
| > "HTMX is a different syntax for inline JS."
|
| I'm not a web developer [1], and I get that htmx uses JavaScript
| behind the scenes, but this quote seems like someone was missing
| the point. htmx encourages a different approach to architecting
| and building an app. Or am I the one who's not understanding?
|
| The comment about hiring and AI-support being better with React
| is imo just another depressing reminder of how much of a
| monoculture we have at the front-end - and imo a bloated and
| over-complex one at that.
|
| [1] I have read the htmx book though
| dartos wrote:
| His 3rd point scares me.
|
| Imagine a world where companies pay to have their framework's be
| over represented in a models training set and selling contracts
| off the back of that.
|
| Like SEO but baked into developer tooling.
| onehair wrote:
| I don't know man, I personally wouldn't use htmx nor tailwind,
| but the arguments against them as mentioned in the article felt
| too superficial. A note to the author, please don't post
| screenshots that have 78.9% whitespace on them. (especially when
| you have a the word UX in a close-by paragraph)
| meerab wrote:
| "The development process felt natural with Next.js" - the author
|
| What part of this ReactJS syntax you find natural? Familiar Yes,
| Natural NO. useEffect(() => { const timer
| = setInterval(() => { setCount((prevCount) => prevCount
| + 1); }, 1000); return () =>
| clearInterval(timer); }, []);
| maicro wrote:
| Off-topic except that it's about gumroad - does anyone know of a
| proper abuse submission address or form for gumroad?
|
| I've received two spam emails from them in the past week, where a
| seller "sold" me something for $0, with a cryptocurrency scam in
| the item description - so I received an email from a legit
| gumroad address, but with attacker-provided content (text only in
| the email at least).
|
| I submitted one through their form, but it's a Google Forms page
| configured to only allow a single response, so I could only
| submit once. I also forwarded one to "abuse@gumroad.com", but no
| clue if that's a real destination or the best place for it...
|
| Gmail flagged both of these as Spam, so while I'm not really
| concerned about my own security here, I figure gumroad themselves
| would at least like to know about this so they can limit the
| (spam list) reputation hit...
| righthand wrote:
| NextJS while solves a lot of problems is one of the most
| irritating frameworks I've worked with from their odd required
| directory structure to their weird router shift, to the
| shoehorning of server side api controllers and rendering. Not to
| mention the specific requirements to host on Vercel.com and it's
| intentionally misleading design to get you to host there.
|
| HTMX is a breath of fresh air where 10 other framework aspects
| aren't in my way. Gumroad from reading this didn't even try to
| design using the htmx methodology.
| exabrial wrote:
| >Scalability Concerns: As our project grew in complexity, we
| found htmx struggling to keep up with our needs
|
| A Haiku on the above, oft-repeated, sexy-problem-to-have:
|
| Everyone says this,
|
| but nobody has benchmarks,
|
| because its not real
|
| You are not Google,
|
| but make believe problems,
|
| Are the most fun ones!
| SrslyJosh wrote:
| > UX Limitations: htmx ended up pushing our app towards a
| Rails/CRUD approach, which led to a really poor (or at least,
| boring and generic) user experience by default.
|
| Good websites behave in predictable ways. If I can tell your
| website is using fucktons of javascript, I'm probably not
| enjoying using it. (And calling it an "app" is a bit of a red
| flag for bad UX to me.)
| burnished wrote:
| Thoughtful critique about a project posted to the project page?
| Beautiful, loved it, well done everyone involved.
| PaulHoule wrote:
| I have a system I'm working on that is all HTMX but I am thinking
| about options.
|
| The system is a document management tool which can be configured
| to be a lot of different things like an image sorter or an RSS
| reader or an information extraction tool. The key design point is
| that it has to be easily configurable.
|
| I worked on a similar system at a startup that used an SPA and
| boy was it a bear because changing anything involved making both
| front end and back end changes. We had to change directions all
| the time to keep up with our customers and the monolithic SPA
| sure slowed us down.
|
| My current back end has a query builder that can generate queries
| with a complex structure as is supported by OWL DL, like
| (Temp > 95 AND Temp < 100) or (IS warm)
|
| but with HTMX I can best use URL query parameters like
| ?temp:gt=95&temp:lt=100
|
| that are all ANDed. I am thinking about making little applets
| with svelte that could do what HTMX can't.
| jmull wrote:
| OK, hats off to htmx for posting/hosting this.
|
| Now, it's a bit of a safe bet to write off anyone willingly or
| willfully using react, but still, actually hosting this took some
| real flair.
|
| IDK, I'm a svelte(kit) man myself, but I don't know that dev-dom
| really deserves something that makes as much sense as that. htmx
| is so far from the worst idea out there.
| greenie_beans wrote:
| does anybody else think that parts of this was written by ai?
| especially the end.
| rossdavidh wrote:
| Funny, almost everything he said about htmx made me think, "this
| htmx sounds interesting, I should check it out".
| hakunin wrote:
| Having read the article, the team just seems more experienced
| with frontend than backend dev. As somewhat an old school dev,
| I've been noticing these small fears and misunderstandings in the
| way FE devs think. Honestly, I believe it only takes a minor
| adjustment in thinking to understand how this stuff works, but I
| get it -- many people at this point have never seen regular
| client/server approach in their entire careers. That said, I get
| the value of off-the-shelf React components, and ease of finding
| docs/help, so wouldn't discount that anyway.
___________________________________________________________________
(page generated 2024-10-03 23:00 UTC)