6 ms·

A Response to "Have Single-Page Apps Ruined the Web?" (2021)

34 points by tie-in 2y ago

deleted 2y ago
[deleted]
coffeeindex 2y ago
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 2y ago
  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 2y ago
  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 https://github.com/yawaramin/dream-html/tree/todoapp/app
martinbaun 2y ago
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 2y ago
  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 2y ago
    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.
- euroderf 2y ago
  Having managed to avoid front-end JS networks completely, am I in a good position to absorb htmx without prejudice or cognitive rewiring ?
  - martinbaun 2y ago
    Without prejudice I am not sure. It depends on you. But, HTMX fits very well together with the traditional server-side rendered websites and probably you wont need to do much cognitive rewiring
  - recursivedoubts 2y ago
    check our free online book out: https://hypermedia.systems https://hypermedia.systems see if it makes sense or not
    - martinbaun 2y ago
      cool! I like to sprinkle a little alpinejs in whenever I need some client-side things.
- likeclockwork 2y ago
  No, it's old. HTMX is just intercooler.js which has been getting shilled here by the author for the last twelve years and no one wanted anything to do with it then and many want nothing to do with it now.
  - martinbaun 2y ago
    You're right that it is intercooler.js 2.0, but that doesn't mean it sucks or is not useful. Many times 3 lines of simple to understand htmx code will be equivalent 200 lines of VueJS code - and with a lot less bugs. It is insanely productive.
  - recursivedoubts 2y ago
    https://star-history.com/#bigskysoftware/htmx&Date https://star-history.com/#bigskysoftware/htmx&Date ¯\_(ツ)_/¯
    - martinbaun 2y ago
      cool, didn't know that. And yeah, it's really exploding with htmx.
deleted 2y ago
[deleted]
usrusr 2y ago
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 2y ago
  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/ 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 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 2y ago
    That all sounds a lot more complicated than just continuing to use react
    - recursivedoubts 2y ago
      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/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
    - yawaramin 2y ago
      They are complicated in different ways. With htmx, you plan and prepare partial page updates yourself and htmx swaps them in for you. With React, you get to maintain the entire npm toolchain that your app depends on, including fun things like 'React 19 will no longer patch the fetch() function, so you have to handle double-fetch manually'.
SahAssar 2y ago
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 2y ago
  Just curious, do you also really dislike when Wendy's social media account cracks jokes about other fast food chains?
  - SahAssar 2y ago
    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 2y ago
      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/ https://htmx.org/essays/when-to-use-hypermedia/
      - SahAssar 2y ago
        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 2y ago
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 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
a_wild_dandan 2y ago
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.)
- eYrKEC2 2y ago
  I'm liking the standardization in web. I think it's possible that you'll see something in web like you see with C/C++. D is better than C++, but it isn't compelling enough to jump. You need a very compelling set of features to leave the very comfortable, though dangerous, home of C/C++ for the domain that it excels in. With web, you'll need compelling features to leave the comfortable home of Typescript + React.
  - Tommah 2y ago
    You're right about D, but Rust is drawing some people away from C and C++. Something may emerge that will do the same on the JS front-end. In fact, I'd say that the TypeScript/React combo is more susceptible to being replaced than C and C++ are. There are many large C/C++ codebases that represent many man-years of work and won't be rewritten or thrown away any time soon. JS front-ends don't have that kind of longevity. Think about how many web startups just fizzle out, and their code just goes away.
llmblockchain 2y ago
I built a fairly large SaaS app using HTMX and Alpine. It has worked wonderfully. HTMX really shines in a few areas for me. 1. Async loading of things (ex: render a dashboard and THEN load the chart data) to prevent blocking page loads. 2. Lazy loading of things (ex: Instead of rendering a modal for every row in a table, fetch and display the modal when the row edit button is clicked). 3. HX-Boost is nice. I have always been a fan of Turbolinks (classic) and preventing full page loads and allow permanent page elements. Boost makes it possible out of the box. 4. It leaves wiggle room for progressive enhancement. For example, if you are lazily loading a modal but JS is disabled, you could open a separate page for the modal/form instead of lazily fetching and displaying in-page. It's more work, but at least it's _possible_. Alpine on the other hand is nice for different things. I mainly use Alpine for things like handling a dropdown, slideout, animating things, etc. All of this is done without writing any JavaScript. I am able to stay in my HTML templates or backend (in Golang) without ever touching JavaScript. I also adopted Tailwind for the same reason. I essentially write the CSS in the HTML (with classes) and let tailwind compile and generate the CSS for me... no more unused CSS. No more CSS clashes, naming conventions, etc. It's a great workflow. edit: I just wanted to say I use HTMX with the head-support plugin bundled together. @recursivedoubts, hoping for 2.0 soon to come with support built in :)
anothername12 2y ago
I would like to shitcan our front end team, and replace the app with a stupid-simple MPA with some sprinklings of HTMX that even a “backend” dev won’t have too much trouble with, but I can’t - we’re in too deep at this point. We had a 2 two-week sprints where they couldn’t decide on a date selector and had to build our own. Then there’s this huge GraphQL monstrosity we have to support the front end - but it’s better than REST, I think?? Ah I could rant..

34 points by tie-in 2y ago

deleted 2y ago

[deleted]

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 2y ago
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 2y ago
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 https://github.com/yawaramin/dream-html/tree/todoapp/app

martinbaun 2y ago

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 2y ago
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 2y ago
  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.
euroderf 2y ago
Having managed to avoid front-end JS networks completely, am I in a good position to absorb htmx without prejudice or cognitive rewiring ?
- martinbaun 2y ago
  Without prejudice I am not sure. It depends on you. But, HTMX fits very well together with the traditional server-side rendered websites and probably you wont need to do much cognitive rewiring
- recursivedoubts 2y ago
  check our free online book out: https://hypermedia.systems https://hypermedia.systems see if it makes sense or not
  - martinbaun 2y ago
    cool! I like to sprinkle a little alpinejs in whenever I need some client-side things.
likeclockwork 2y ago
No, it's old. HTMX is just intercooler.js which has been getting shilled here by the author for the last twelve years and no one wanted anything to do with it then and many want nothing to do with it now.
- martinbaun 2y ago
  You're right that it is intercooler.js 2.0, but that doesn't mean it sucks or is not useful. Many times 3 lines of simple to understand htmx code will be equivalent 200 lines of VueJS code - and with a lot less bugs. It is insanely productive.
- recursivedoubts 2y ago
  https://star-history.com/#bigskysoftware/htmx&Date https://star-history.com/#bigskysoftware/htmx&Date ¯\_(ツ)_/¯
  - martinbaun 2y ago
    cool, didn't know that. And yeah, it's really exploding with htmx.

deleted 2y ago

[deleted]

usrusr 2y ago

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 2y ago
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/ 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 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 2y ago
  That all sounds a lot more complicated than just continuing to use react
  - recursivedoubts 2y ago
    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/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - yawaramin 2y ago
    They are complicated in different ways. With htmx, you plan and prepare partial page updates yourself and htmx swaps them in for you. With React, you get to maintain the entire npm toolchain that your app depends on, including fun things like 'React 19 will no longer patch the fetch() function, so you have to handle double-fetch manually'.

SahAssar 2y ago

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 2y ago
Just curious, do you also really dislike when Wendy's social media account cracks jokes about other fast food chains?
- SahAssar 2y ago
  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 2y ago
    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/ https://htmx.org/essays/when-to-use-hypermedia/
    - SahAssar 2y ago
      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 2y ago

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 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

a_wild_dandan 2y ago

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.)

eYrKEC2 2y ago
I'm liking the standardization in web. I think it's possible that you'll see something in web like you see with C/C++. D is better than C++, but it isn't compelling enough to jump. You need a very compelling set of features to leave the very comfortable, though dangerous, home of C/C++ for the domain that it excels in. With web, you'll need compelling features to leave the comfortable home of Typescript + React.
- Tommah 2y ago
  You're right about D, but Rust is drawing some people away from C and C++. Something may emerge that will do the same on the JS front-end. In fact, I'd say that the TypeScript/React combo is more susceptible to being replaced than C and C++ are. There are many large C/C++ codebases that represent many man-years of work and won't be rewritten or thrown away any time soon. JS front-ends don't have that kind of longevity. Think about how many web startups just fizzle out, and their code just goes away.

llmblockchain 2y ago

I built a fairly large SaaS app using HTMX and Alpine. It has worked wonderfully. HTMX really shines in a few areas for me. 1. Async loading of things (ex: render a dashboard and THEN load the chart data) to prevent blocking page loads. 2. Lazy loading of things (ex: Instead of rendering a modal for every row in a table, fetch and display the modal when the row edit button is clicked). 3. HX-Boost is nice. I have always been a fan of Turbolinks (classic) and preventing full page loads and allow permanent page elements. Boost makes it possible out of the box. 4. It leaves wiggle room for progressive enhancement. For example, if you are lazily loading a modal but JS is disabled, you could open a separate page for the modal/form instead of lazily fetching and displaying in-page. It's more work, but at least it's _possible_. Alpine on the other hand is nice for different things. I mainly use Alpine for things like handling a dropdown, slideout, animating things, etc. All of this is done without writing any JavaScript. I am able to stay in my HTML templates or backend (in Golang) without ever touching JavaScript. I also adopted Tailwind for the same reason. I essentially write the CSS in the HTML (with classes) and let tailwind compile and generate the CSS for me... no more unused CSS. No more CSS clashes, naming conventions, etc. It's a great workflow. edit: I just wanted to say I use HTMX with the head-support plugin bundled together. @recursivedoubts, hoping for 2.0 soon to come with support built in :)

anothername12 2y ago

I would like to shitcan our front end team, and replace the app with a stupid-simple MPA with some sprinklings of HTMX that even a “backend” dev won’t have too much trouble with, but I can’t - we’re in too deep at this point. We had a 2 two-week sprints where they couldn’t decide on a date selector and had to build our own. Then there’s this huge GraphQL monstrosity we have to support the front end - but it’s better than REST, I think?? Ah I could rant..