4 ms·

Damn, why does everything have to be so complex to make a UI

chii 3y ago
this is actually less complex than the "standard" react frontend frameworks to produce a UI imho. This is basically the good old days of server side rendering, and html fragments, and you'd used to use jquery to just wholesale replace portions of the dom with the returned value from the server via an ajax request.
- nsonha 3y ago
  it's always less complex when you look at a toy example. Then you get more complex requirements that make the html templates unmanagable or even impossible in html. Then you have to drop some javascript anyway, then more and more of them. Then you wonder why cling on to the futile effort of "programming" in html anyway.
  - jiggawatts 3y ago
    There have been many cycles of doing "everything on the server", then "everything on the client", and back again. Right now, it's swinging back to the doing everything on the server. First it was mainframes, then PCs, then Citrix, then laptops, HTML, client-side rendering, server-side rendering, etc... Server-side rendering has a huge advantage though: it needs one less "layer". With client-side rendering you have code in the browser, code on the server, and code in the database. You need defined protocols between every layer. With three layers and two hops, that's effectively 5 things you need to develop. With HTML-based development, the client side code basically doesn't exist any more. You don't need to send the browser JSON via an API to be decoded and converted to HTML. You just send the HTML as-is. Just write the web server and the database, connect them, and you're done. That's 3 things you need to develop. I've watched developer after developer start trivial web pages -- not even really apps -- with stacks like Angular and get bogged down in the complexity of things like client-side authentication protocols, multi-API security, making sure JSON APIs don't leak information inadvertently, having to batch queries with GraphQL, and on, and on, and on... None of that is necessary with HTML being generated by the server.
  - norwalkbear 3y ago
    This is where I am after trying htmx out. Trying to get good user feedback during the automatic inflight ajax seems impossible. Complex multi target ui is nastier than just using vue/react.
    - recursivedoubts 3y ago
      https://htmx.org/docs/#indicators https://htmx.org/docs/#indicators https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-content/
      - norwalkbear 3y ago
        As you can see on the examples, multi component update requires target expansion or event triggers which means custom js. In the end complex ui gives me worse code than reactive js. I have to think alot harder about page or htmx dom scope with htmx.
        recursivedoubts 3y ago
        for sure if you have a super complicated UI but often you don't https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ i'd de-escalate the whole thing by turning it from an "either/or" into a "sometimes/as well" htmx & hypermedia is a tool, nothing more
        nsonha 3y ago
        > but often you don't who are you to say so?

chii 3y ago

this is actually less complex than the "standard" react frontend frameworks to produce a UI imho. This is basically the good old days of server side rendering, and html fragments, and you'd used to use jquery to just wholesale replace portions of the dom with the returned value from the server via an ajax request.

nsonha 3y ago
it's always less complex when you look at a toy example. Then you get more complex requirements that make the html templates unmanagable or even impossible in html. Then you have to drop some javascript anyway, then more and more of them. Then you wonder why cling on to the futile effort of "programming" in html anyway.
- jiggawatts 3y ago
  There have been many cycles of doing "everything on the server", then "everything on the client", and back again. Right now, it's swinging back to the doing everything on the server. First it was mainframes, then PCs, then Citrix, then laptops, HTML, client-side rendering, server-side rendering, etc... Server-side rendering has a huge advantage though: it needs one less "layer". With client-side rendering you have code in the browser, code on the server, and code in the database. You need defined protocols between every layer. With three layers and two hops, that's effectively 5 things you need to develop. With HTML-based development, the client side code basically doesn't exist any more. You don't need to send the browser JSON via an API to be decoded and converted to HTML. You just send the HTML as-is. Just write the web server and the database, connect them, and you're done. That's 3 things you need to develop. I've watched developer after developer start trivial web pages -- not even really apps -- with stacks like Angular and get bogged down in the complexity of things like client-side authentication protocols, multi-API security, making sure JSON APIs don't leak information inadvertently, having to batch queries with GraphQL, and on, and on, and on... None of that is necessary with HTML being generated by the server.
- norwalkbear 3y ago
  This is where I am after trying htmx out. Trying to get good user feedback during the automatic inflight ajax seems impossible. Complex multi target ui is nastier than just using vue/react.
  - recursivedoubts 3y ago
    https://htmx.org/docs/#indicators https://htmx.org/docs/#indicators https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-content/
    - norwalkbear 3y ago
      As you can see on the examples, multi component update requires target expansion or event triggers which means custom js. In the end complex ui gives me worse code than reactive js. I have to think alot harder about page or htmx dom scope with htmx.
      - recursivedoubts 3y ago
        for sure if you have a super complicated UI but often you don't https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ i'd de-escalate the whole thing by turning it from an "either/or" into a "sometimes/as well" htmx & hypermedia is a tool, nothing more
        nsonha 3y ago
        > but often you don't who are you to say so?