3 ms·

They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the wh

They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).

troad 2y ago
As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs. > But without framework you in the end just create a custom one Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web. * Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.
- jakubmazanec 2y ago
  But we're not talking about SPAs, we're talking about e-commerce websites. > full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons) I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS". > Only if you've only ever written React-style webpages Again, I'm not saying anything about using React specifically. > convoluted web framework Yet another straw man.
  - recursivedoubts 2y ago
    ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API. I wrote an essay about this here: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression: https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison in most real world systems i expect data store access to be the dominant latency issue some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption): https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ but of course it depends on your use case. I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.
    - jakubmazanec 2y ago
      As I said, using HTMX isn't "minimal to no JS". I agree that HTMX can be fast - but that's not what we're talking about. Even in the video of converting a React app to HTMX you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.
      - recursivedoubts 2y ago
        i think it's reasonable to call htmx "minimal JS" in that it is relatively small, dependency free, can be used without a typical javascript build chain (npm, etc.) and frees the end user of writing javascript in many cases the speaker is referring to them not needing to write javascript for a specific feature, which is true, but they do use scripting for some aspects of the application, which is perfectly acceptable in hypermedia-driven applications: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ regardless, the wins are obvious
  - troad 2y ago
    > Full-page reloads are, ceteris paribus, always slower than some JSON payload That must explain why websites are so fast and responsive these days! /s If you're wedded to the idea of dynamic reloads, which - imho - you ought not be, HTMX or Turbo are ways of achieving that without needing to write any JS. HTMX is designed to complete HTML as a hypermedia language, which it does using JS, but it itself does not require any additional JS to use. I'm sure the authors would dearly love it if HTMX's ideas were taken directly into HTML5, and they could scrap the JS library altogether. Its use of JS is an implementation detail borne of necessity. If you're coming from SPAs and can't imagine websites working any other way, I highly recommend reading something like Hypermedia Systems (https://hypermedia.systems/ https://hypermedia.systems/). Come with an open mind, let it be your gateway drug. HTMX builds on a very old tradition of hypermedia, all the way back to Computer Lib/Dream Machines, through systems like HyperCard, to the actual, original definition of RESTfulness (that modern Ajax SPAs generally do not meet). It draws deep from the hacker ethos (you know, that thing that this website is about!). Personally, I don't even think HTMX is all that necessary. What I feel like you're missing is that the overwhelming majority of websites are technically very simple, and their value to their users is in their contents, not in their stack. Did you notice the full page reload when you hit Reply on your comment, here on HN? Were you terribly put out by it? Would HN be an improved website were it full of spinners and Ajax? I would respectfully suggest it would not. It delivers amazing value running as a Lisp program on a machine under someone's desk.
    - jakubmazanec 2y ago
      > This seems like an exceedingly mean-spirited and unconstructive It's not, it's precise. Sorry you wasted time writing all this, because I don't care about hypermedia systems - it's not that it's bad technology, I simply don't want to write yet another awful templating language. But that's just an aside, because once again you're talking about something else. But okay, let's switch to debating HTMX. My point then still stands: you simply need JavaScript. Now instead of this useless arguing, go find/build some big e-commerce website with this hypermedia stuff (or truly with no JavaScript) and then we'll see.
      - recursivedoubts 2y ago

troad 2y ago

As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs. > But without framework you in the end just create a custom one Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web. * Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.

jakubmazanec 2y ago
But we're not talking about SPAs, we're talking about e-commerce websites. > full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons) I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS". > Only if you've only ever written React-style webpages Again, I'm not saying anything about using React specifically. > convoluted web framework Yet another straw man.
- recursivedoubts 2y ago
  ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API. I wrote an essay about this here: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression: https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison in most real world systems i expect data store access to be the dominant latency issue some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption): https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ but of course it depends on your use case. I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.
  - jakubmazanec 2y ago
    As I said, using HTMX isn't "minimal to no JS". I agree that HTMX can be fast - but that's not what we're talking about. Even in the video of converting a React app to HTMX you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.
    - recursivedoubts 2y ago
      i think it's reasonable to call htmx "minimal JS" in that it is relatively small, dependency free, can be used without a typical javascript build chain (npm, etc.) and frees the end user of writing javascript in many cases the speaker is referring to them not needing to write javascript for a specific feature, which is true, but they do use scripting for some aspects of the application, which is perfectly acceptable in hypermedia-driven applications: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ regardless, the wins are obvious
- troad 2y ago
  > Full-page reloads are, ceteris paribus, always slower than some JSON payload That must explain why websites are so fast and responsive these days! /s If you're wedded to the idea of dynamic reloads, which - imho - you ought not be, HTMX or Turbo are ways of achieving that without needing to write any JS. HTMX is designed to complete HTML as a hypermedia language, which it does using JS, but it itself does not require any additional JS to use. I'm sure the authors would dearly love it if HTMX's ideas were taken directly into HTML5, and they could scrap the JS library altogether. Its use of JS is an implementation detail borne of necessity. If you're coming from SPAs and can't imagine websites working any other way, I highly recommend reading something like Hypermedia Systems (https://hypermedia.systems/ https://hypermedia.systems/). Come with an open mind, let it be your gateway drug. HTMX builds on a very old tradition of hypermedia, all the way back to Computer Lib/Dream Machines, through systems like HyperCard, to the actual, original definition of RESTfulness (that modern Ajax SPAs generally do not meet). It draws deep from the hacker ethos (you know, that thing that this website is about!). Personally, I don't even think HTMX is all that necessary. What I feel like you're missing is that the overwhelming majority of websites are technically very simple, and their value to their users is in their contents, not in their stack. Did you notice the full page reload when you hit Reply on your comment, here on HN? Were you terribly put out by it? Would HN be an improved website were it full of spinners and Ajax? I would respectfully suggest it would not. It delivers amazing value running as a Lisp program on a machine under someone's desk.
  - jakubmazanec 2y ago
    > This seems like an exceedingly mean-spirited and unconstructive It's not, it's precise. Sorry you wasted time writing all this, because I don't care about hypermedia systems - it's not that it's bad technology, I simply don't want to write yet another awful templating language. But that's just an aside, because once again you're talking about something else. But okay, let's switch to debating HTMX. My point then still stands: you simply need JavaScript. Now instead of this useless arguing, go find/build some big e-commerce website with this hypermedia stuff (or truly with no JavaScript) and then we'll see.
    - recursivedoubts 2y ago