2 ms·

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

by 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.
    - nawgz 6y ago
      I think my biggest complaint about what you've written here is that you just shunt these "complexities" you wield against SPA to the back-end and then gloss over them. I strongly disagree that "formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string" - business logic is always the most expensive code to inject. This means you're either, again, not really making full-blown applications, or they're exceedingly simple. Postgres can craft nice JSON output straight from the horse's mouth. Can't say the same for HTML. > Yes, an irony of my life is The code looks great. Congrats on finding a development path that suits your tastes.
      - jiofih 6y ago
        Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).

by nawgz 6y ago

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.
  - nawgz 6y ago
    I think my biggest complaint about what you've written here is that you just shunt these "complexities" you wield against SPA to the back-end and then gloss over them. I strongly disagree that "formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string" - business logic is always the most expensive code to inject. This means you're either, again, not really making full-blown applications, or they're exceedingly simple. Postgres can craft nice JSON output straight from the horse's mouth. Can't say the same for HTML. > Yes, an irony of my life is The code looks great. Congrats on finding a development path that suits your tastes.
    - jiofih 6y ago
      Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).