5 ms·

You know what also uses the streaming parser? Standard server-rendered pages. The idea that SPAs are faster because “they just download the content” is rarely

by jiofih 6y ago

You know what also uses the streaming parser? Standard server-rendered pages. The idea that SPAs are faster because “they just download the content” is rarely true, HTML compresses well and the content will take the same space in either. The real bottlenecks are in re-executing huge amounts of JS per page (don’t have huge amounts of JS?) and page transitions (being worked on).

recursivedoubts 6y ago
Absolutely. The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.
- nawgz 6y ago
  Sure, but what's your use case? Strict data table where everything is a string or number? Great. Full fledged application where your table rows are actually selectable items that modify app state and cause rerenders elsewhere? Surely a slight performance hit in the table is worth the smoothness of an application. For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.
  - recursivedoubts 6y ago
    > For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. That is trivially implementable in pure HTML interactions. If you were making a 3D game or something, sure... but that's just normal web navigation.
    - nawgz 6y ago
      >trivially implementable Care to do it here for me then? Basically, you are proposing what? That I have a server that renders this table, pre-populated with onClick handlers that magically know what function to call to tell my browser state that it should focus a specific workflow? Or are you suggesting that I reload the entire application to use "pure HTML interactions"? I really want to understand - how are you making this construct both not fragile to iterate on AND not require a page reload or server round-trip after the user clicks on a Table row.
      - recursivedoubts 6y ago
        You would have rows in one table, those rows would be annotated with two annotations: hx-get="/workflow/<workflow id>" where <workflow id> is the ID for the given workflow. This would issue a GET request to, er, get the details for the given row, in partial html format. And also hx-target="#other-table" This would tell htmx to take the received content and put that into the other table on the screen, by id. Since this target is the same for all rows in the table, it could be moved to a parent element, where it would be inherited from. Finally, you could also use hx-push-url="true" If you wanted to push the URL into the navigation bar, creating a history element for the navigation, and which would allow users to copy a URL to a particular spot in the two-level navigation, and enable back button support. https://htmx.org/attributes/hx-get/ https://htmx.org/attributes/hx-get/ https://htmx.org/attributes/hx-target/ https://htmx.org/attributes/hx-target/ https://htmx.org/attributes/hx-push-url/ https://htmx.org/attributes/hx-push-url/
        nawgz 6y ago
        Thank you for the tutorial. It is quite a nice library, to be sure, and the freedom to work outside of the JS ecosystem, instead writing your servers however you please, seems ncie. However, I feel you are talking right past me to show me your library & dislike of JS. From my last message: > how are you making this [...] not require a page reload or server round-trip after the user clicks on a Table row The whole appeal of SPAs is they take perhaps 2s longer to start up than your normal webpage, and then you get lots of instant interactions. The example above is one of them. Your model requires server round-trips for every interaction. I get it - you don't like JavaScript. I find your model quite nice and graceful for non-application purposes. It's certainly a brilliant way to render some types of data. But for fully interactive applications where your user would want to have context menus showing applicable actions; good feedback on app / loading state; and avoid server latency on any type of event; I feel like SPAs are far superior. I also feel like you have removed yourself from writing JS flavored HTML, but the solution of server-siding it introduces two problems. One is that you still need to hydrate and format that HTML somehow; I again think you can go a long way with templates, but if you're just using React on the back-end it seems ridiculous. Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results, which puts your server infra under far more pressure at less load to my eyes. Final gripe: that interaction is not "pure HTML", you are using a JS library...
  - mattmanser 6y ago
    You don't have to use a SPA to achieve that. With a couple of lines of JavaScript, you can insert snippets of html into a webpage that were rendered on the server. And remove them with one line. Your entire use case is achievable with server-side partial rendering and a few lines of native js.
    - nawgz 6y ago
      So your proposition is that instead of downloading a client bundle that knows all of these actions, my server: * renders a Table for me * my thin client injects that into the page * my onClick handlers for the Table are going to do what? Make an API call to the server so it can render the focused Graph section of the page now? Or is it supposed to hook gracefully into some client state that is a part of the aforementioned thin client? Either way it sounds like instead of having one async stage at application load (which can be optimized with multiple techniques), you are proposing that each user action has to wait for a server to receive the request, render HTML, return it to the client, and either refresh the page or inject the server-rendered HTML. I fail to see why this is better than an SPA. Especially given that there's context menus and workflow actions everywhere.
      - manigandham 6y ago
        Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.
        nawgz 6y ago
        >Anything that actually changes the data requires a server roundtrip I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful. Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so the user can begin editing another piece of data without waiting for latency-bound UI, etc.. Finally, "simpler" is a hard sell. Simpler for who? Someone who is writing a simple HTML data table page? Yes. For someone who is building a collaborative graph editor? Give me a break. This is my point this whole comment thread - the anti-SPA crowd here sometimes hates JS and browsers so much they are willing to completely sacrifice user performance inside application use-cases because they find the idea of an SPA unappealing. It's pretty absurd, facile really, to claim "it's faster AND simpler".
  - manigandham 6y ago
    I don't see why having an interactive table requires a SPA. No need to throw away everything for a single component on a page.
redwall_hp 6y ago
If the majority of users only view the one page they land on, throwing a load of JS at them to make subsequent page loads faster is only slowing down their experience. It's also pointless for users who aren't the lowest common denominator, since opening links in new tabs also defeats the whole premise. That's how I'm browsing HN right now: middle-clicking several links on the front page, so I don't lose my place, opening the links and then comment pages in new tabs.
- vorpalhex 6y ago
  > since opening links in new tabs also defeats the whole premise You should still have assets cached and not have to refetch them, but on most SPAs you are still having to get that pages content dynamically so in theory you're reducing load time. Of course, you could just reduce the entire bundle size to be reasonable, statically render everything and save a whole bunch of complexity, but that wouldn't be very Web 4.0 of us.

by jiofih 6y ago

recursivedoubts 6y ago

Absolutely. The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.

nawgz 6y ago
Sure, but what's your use case? Strict data table where everything is a string or number? Great. Full fledged application where your table rows are actually selectable items that modify app state and cause rerenders elsewhere? Surely a slight performance hit in the table is worth the smoothness of an application. For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.
- recursivedoubts 6y ago
  > For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow. That is trivially implementable in pure HTML interactions. If you were making a 3D game or something, sure... but that's just normal web navigation.
  - nawgz 6y ago
    >trivially implementable Care to do it here for me then? Basically, you are proposing what? That I have a server that renders this table, pre-populated with onClick handlers that magically know what function to call to tell my browser state that it should focus a specific workflow? Or are you suggesting that I reload the entire application to use "pure HTML interactions"? I really want to understand - how are you making this construct both not fragile to iterate on AND not require a page reload or server round-trip after the user clicks on a Table row.
    - recursivedoubts 6y ago
      You would have rows in one table, those rows would be annotated with two annotations: hx-get="/workflow/<workflow id>" where <workflow id> is the ID for the given workflow. This would issue a GET request to, er, get the details for the given row, in partial html format. And also hx-target="#other-table" This would tell htmx to take the received content and put that into the other table on the screen, by id. Since this target is the same for all rows in the table, it could be moved to a parent element, where it would be inherited from. Finally, you could also use hx-push-url="true" If you wanted to push the URL into the navigation bar, creating a history element for the navigation, and which would allow users to copy a URL to a particular spot in the two-level navigation, and enable back button support. https://htmx.org/attributes/hx-get/ https://htmx.org/attributes/hx-get/ https://htmx.org/attributes/hx-target/ https://htmx.org/attributes/hx-target/ https://htmx.org/attributes/hx-push-url/ https://htmx.org/attributes/hx-push-url/
      - nawgz 6y ago
        Thank you for the tutorial. It is quite a nice library, to be sure, and the freedom to work outside of the JS ecosystem, instead writing your servers however you please, seems ncie. However, I feel you are talking right past me to show me your library & dislike of JS. From my last message: > how are you making this [...] not require a page reload or server round-trip after the user clicks on a Table row The whole appeal of SPAs is they take perhaps 2s longer to start up than your normal webpage, and then you get lots of instant interactions. The example above is one of them. Your model requires server round-trips for every interaction. I get it - you don't like JavaScript. I find your model quite nice and graceful for non-application purposes. It's certainly a brilliant way to render some types of data. But for fully interactive applications where your user would want to have context menus showing applicable actions; good feedback on app / loading state; and avoid server latency on any type of event; I feel like SPAs are far superior. I also feel like you have removed yourself from writing JS flavored HTML, but the solution of server-siding it introduces two problems. One is that you still need to hydrate and format that HTML somehow; I again think you can go a long way with templates, but if you're just using React on the back-end it seems ridiculous. Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results, which puts your server infra under far more pressure at less load to my eyes. Final gripe: that interaction is not "pure HTML", you are using a JS library...
- mattmanser 6y ago
  You don't have to use a SPA to achieve that. With a couple of lines of JavaScript, you can insert snippets of html into a webpage that were rendered on the server. And remove them with one line. Your entire use case is achievable with server-side partial rendering and a few lines of native js.
  - nawgz 6y ago
    So your proposition is that instead of downloading a client bundle that knows all of these actions, my server: * renders a Table for me * my thin client injects that into the page * my onClick handlers for the Table are going to do what? Make an API call to the server so it can render the focused Graph section of the page now? Or is it supposed to hook gracefully into some client state that is a part of the aforementioned thin client? Either way it sounds like instead of having one async stage at application load (which can be optimized with multiple techniques), you are proposing that each user action has to wait for a server to receive the request, render HTML, return it to the client, and either refresh the page or inject the server-rendered HTML. I fail to see why this is better than an SPA. Especially given that there's context menus and workflow actions everywhere.
    - manigandham 6y ago
      Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.
      - nawgz 6y ago
        >Anything that actually changes the data requires a server roundtrip I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful. Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so the user can begin editing another piece of data without waiting for latency-bound UI, etc.. Finally, "simpler" is a hard sell. Simpler for who? Someone who is writing a simple HTML data table page? Yes. For someone who is building a collaborative graph editor? Give me a break. This is my point this whole comment thread - the anti-SPA crowd here sometimes hates JS and browsers so much they are willing to completely sacrifice user performance inside application use-cases because they find the idea of an SPA unappealing. It's pretty absurd, facile really, to claim "it's faster AND simpler".
- manigandham 6y ago
  I don't see why having an interactive table requires a SPA. No need to throw away everything for a single component on a page.

redwall_hp 6y ago

If the majority of users only view the one page they land on, throwing a load of JS at them to make subsequent page loads faster is only slowing down their experience. It's also pointless for users who aren't the lowest common denominator, since opening links in new tabs also defeats the whole premise. That's how I'm browsing HN right now: middle-clicking several links on the front page, so I don't lose my place, opening the links and then comment pages in new tabs.

vorpalhex 6y ago
> since opening links in new tabs also defeats the whole premise You should still have assets cached and not have to refetch them, but on most SPAs you are still having to get that pages content dynamically so in theory you're reducing load time. Of course, you could just reduce the entire bundle size to be reasonable, statically render everything and save a whole bunch of complexity, but that wouldn't be very Web 4.0 of us.