5 ms·

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 yo

by 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).
    - nawgz 6y ago
      This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client. It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?
      - jiofih 6y ago
        You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that. We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.

by nawgz 6y ago

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).
  - nawgz 6y ago
    This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client. It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?
    - jiofih 6y ago
      You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that. We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.