[HN Gopher] A Response to "Have Single-Page Apps Ruined the Web?...
___________________________________________________________________
A Response to "Have Single-Page Apps Ruined the Web?" (2021)
Author : tie-in
Score : 24 points
Date : 2024-04-25 20:42 UTC (2 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| coffeeindex wrote:
| HTMX is one of those things that I love the idea of, but I
| haven't yet used it in a way that I really enjoy. Go's HTML
| templating made it fairly good but it still didn't feel great to
| use.
| martinbaun wrote:
| You're the first one I heard who says Go's templating is fairly
| good.
|
| Can you tell me why you think so? I love Go, but their
| templating is not my favorite.
| yawaramin wrote:
| There is some truth to this. Imho the next level of htmx is
| unlocked when you componentize everything like a React
| app...but with nested routes corresponding to nested components
| like a Remix app...and using an HTML generation DSL embedded
| directly in your language, so HTML becomes a first-class
| citizen of your language's constructs, rather than a templated
| afterthought. I have a demo of this:
| https://github.com/yawaramin/dream-html/tree/todoapp/app
| martinbaun wrote:
| Using HTMX is a whole new way of thinking compared to the
| "modern" javascript framework-style.
|
| I love it, but it takes some time to get used to.
| marius_k wrote:
| Wait, isn't it the old way of thinking? That browser is a
| medium rather than a compute node. (I like both old and new
| ways)
| martinbaun wrote:
| Good point Marius.
|
| It is a new way to think compared to the "modern js
| framework" craze over the last 10 years.
|
| But, you're right, it is the "old" way of using the
| browser/html with sprinkles of new interactivity.
|
| Didn't even think about that.
| usrusr wrote:
| How does all the "executed once on the first request" and video
| keeps running work in htmx? Is it an SPA, from the browser's
| perspective, just an SPA that follows the MPA model, in its
| interactions with the server, basically applying a diff to the
| SPA state? Not saying that's a bad thing, just trying to
| understand. Could be an awesome migration path to get some SPA
| benefits into an existing MPA.
| recursivedoubts wrote:
| in plain htmx, you can target an area that doesn't disrupt a
| playing video (e.g. the comments box appending to the comments)
| or you can use a morphing algorithm that disrupts the DOM less.
|
| i have my own morphing algorithm (and a corresponding htmx
| plugin that allows you to use it) called idiomorph:
|
| https://github.com/bigskysoftware/idiomorph/
|
| i've also been working with the chrome team to get a feature
| added they are calling "atomic moves":
|
| https://github.com/whatwg/dom/issues/1255
|
| this would allow us to move elements around in the DOM without
| losing things like play state or focus or whatever
|
| very excited for this last idea, I think it will be a huge boon
| for the web in general, not just for htmx
| robertoandred wrote:
| That all sounds a lot more complicated than just continuing
| to use react
| recursivedoubts wrote:
| sure, it depends
|
| the first option isn't bad once you get the htmx mental
| model, but preserving video elements is on the edge of what
| htmx is a good fit for
|
| otoh, when it's a good fit you can simplify your app a lot:
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| recursivedoubts wrote:
| i'm the author and I think this article holds up pretty well,
| particularly the "Javascript: The Resistance" part
|
| one thing that I didn't note in that section regarding edge
| computing is that if the data store isn't edge, then putting
| compute on the edge doesn't help that much, which vercel has
| started to admit
| (https://twitter.com/t3dotgg/status/1781881405397442947).
|
| i'll state my position again: htmx makes hypermedia a more
| competitive approach for many web applications, but it isn't
| right for everything. i'm not puritanical about approaches and
| agree strongly w/ Rich's take on "transitional apps" where you
| use the right tool for the given job.
|
| where i'd probably disagree w/ Rich is where the line is: i think
| w/ things like htmx (or unpoly or hotwire or datastar, etc.) the
| total space of problems that can be effectively addressed with
| hypermedia expands significantly
| SahAssar wrote:
| I really dislike the discourse around htmx. I think the closest
| words I can use to describe it is glib, insincere and reductive
| (and yes I get that it's supposed to be meme:y).
|
| It pretends to not be a JS library/framework while it is. It
| tilts at windmills that are badly structured/built apps.
|
| I agree that most webapps are built on too large libraries. I
| agree that the dependency chains are crazy. etc. etc.
|
| But the solution proposed by htmx is IMO bad and the self-
| righteous tone is even worse.
| yawaramin wrote:
| Just curious, do you also really dislike when Wendy's social
| media account cracks jokes about other fast food chains?
| SahAssar wrote:
| I don't care about wendy's, I have only seen it in passing
| but it does not seem to say it has the platonic truths of
| food.
| recursivedoubts wrote:
| i understand people who dislike the htmx meme-driven vibe
| and there are certainly times when i go over the line (i'm
| a one man shop trying to compete w/ libraries from
| Facebook/Vercel & Google) but i try to be balanced about
| when hypermedia is and when it is not a good approach:
|
| https://htmx.org/essays/when-to-use-hypermedia/
| SahAssar wrote:
| I don't mind memes, I often like them. One part I dislike
| is that you seem to say you are _apart_ from js libraries
| /frameworks when you are _a part_ of them.
|
| Seems to me like htmx tries really hard to market as
| "just hypermedia" and it's not. Besides things like 'hx-
| ws' or 'hx-on' we've already talked about the normal
| cases where you _need_ custom scripting like normal
| error-handling.
|
| Just hypermedia (as both the UI and API) has been around
| for 3+ decades. htmx isn't that and should not claim to
| be that.
| recursivedoubts wrote:
| htmx is hypermedia oriented in that, when it makes
| network exchanges, those are in terms of hypermedia,
| which differentiates it from most js libraries. Not all,
| there is unpoly, Hotwire, etc as well.
|
| Sse and web sockets are extensions. Hx-on is to address
| the fact that standard on* attributes can only handle
| fixed events, but I agree it is wandering away from the
| core hypermedia functionality of htmx. I was on the fence
| on adding it, but relented when we found a good mechanism
| for supporting it (xpath) and some long time users
| expressed that they wanted to avoid needing something
| like alpine for the simple scripting use cases of their
| apps.
|
| Htmx also fires a lot of events and I don't make a secret
| of the fact that scripting is part of fieldings
| description of the web and perfectly acceptable in a
| hypermedia driven application:
|
| https://hypermedia.systems/client-side-scripting/
| tmnvix wrote:
| I enjoy the somewhat irreverent takes. They seem appropriate
| when directed at the often entirely inappropriate use of some
| modern frontend frameworks.
|
| I've worked with some newish developers that know of no other
| way than to bring in a frontend framework for the simplest of
| things. E.g. adding a carousel (don't ask) to an existing site
| that has no need for a build step and the first thing they want
| to do is bring in node and react.
| a_wild_dandan wrote:
| Controversial prediction: the web/applications will largely
| calcify around TypeScript/React/Node.js/Electron.
|
| Reasons:
|
| 1. It's...already happening. (See: job listings, big web
| platforms, popular desktop apps.)
|
| 2. Deploying one unified codebase on the web, mobile, and all
| major desktops is a phenomenal value. Nobody cares that HN people
| hate the lack of native controls, slower performance, memory
| usage, whatever. Good enough is good enough.
|
| 3. Vastly less friction hiring from the world's largest dev pool
| and onboarding them to codebases written with familiar tech.
|
| 4. TypeScript's system blow away most other type systems, and
| sharing them between front/backends is a big deal.
|
| 5. Node.js can do nearly anything, is fast (enough), and pulls
| tools from the largest community of packages on Earth.
|
| 6. UI frameworks often heft around piles of heavy abstractions.
| Nobody wants to learn yet another awkward, shitty programming
| language that you invented with your templating system. Or the
| heap of classes needed to do basic things "properly." React
| avoids this junk and stays simple -- write everything in pure
| TypeScript (no templates!), declaratively, with a minimal lib.
| KISS.
|
| To save time replying to common misconceptions: No, JSX is not
| templating; Yes, tech/tool competitor ABC exists --
| TS/Node/React's momentum will slowly kill it; If you like
| kitchen-sink frameworks, plenty of extremely
| popular/polished/active ones exist for making SPAs, MPAs, and
| mixtures between using React; Yes, programming problem space XYZ
| won't adopt this stack due to particular constraints, you're
| missing the point;
|
| There, hopefully I pissed off everyone with my overly snarky and
| opinionated position. I deserve the hate. (I'm still right, tho.)
___________________________________________________________________
(page generated 2024-04-25 23:01 UTC)