7 ms·

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 sel

by 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...
      - recursivedoubts 6y ago
        The primary advantage of SPAs is the increased interactivity of the UI. Instant navigation is nice, but that's an implementation detail: an SPA could just as easily lazily load that data, and must chew up memory on the client and then deal with synchronization complexity with the back end if it doesn't. It's a trade off, of course. SPAs are a reversion to the classic client-server setup, and there are advantages and disadvantages to both that and the newer web model. One is that you still need to hydrate and format that HTML somehow htmx expects HTML back from the server, there isn't any hydration or client side templating (unless you want that) Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results, Formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string, and both are a round-off error when compared with the expense of connecting to the data store. Final gripe... Yes, an irony of my life is that I had to learn a lot of javascript in order to avoid writing much javascript.
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.

by nawgz 6y ago

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...
    - recursivedoubts 6y ago
      The primary advantage of SPAs is the increased interactivity of the UI. Instant navigation is nice, but that's an implementation detail: an SPA could just as easily lazily load that data, and must chew up memory on the client and then deal with synchronization complexity with the back end if it doesn't. It's a trade off, of course. SPAs are a reversion to the classic client-server setup, and there are advantages and disadvantages to both that and the newer web model. One is that you still need to hydrate and format that HTML somehow htmx expects HTML back from the server, there isn't any hydration or client side templating (unless you want that) Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results, Formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string, and both are a round-off error when compared with the expense of connecting to the data store. Final gripe... Yes, an irony of my life is that I had to learn a lot of javascript in order to avoid writing much javascript.

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.