4 ms·

This thing preserves your sanity!

by murkt 5y ago

throw_m239339 5y ago
I'm waiting for anyone to demonstrate me how this method isn't 3 step backward in 2022.
- murkt 5y ago
  It is three step backwards. And one step to the side. Which is what I needed, and many others too.
  - throw_m239339 5y ago
    Ok, you mean this thing isn't worth my attention as a front-end developer? Carry on.
    - murkt 5y ago
      Yes, this is not for a front-end developer, this is for all the other people who don’t want to be front-end developers and don’t want to spend months every year to keep up with JS churn. Since we began using this approach, we can be full-stack developers again. One person can easily implement both parts, which is so much faster.
    - recursivedoubts 5y ago
      :) I think it's worth at least taking a look at the core idea is to use hypermedia, rather than an RPC-style architecture, and that is, at the least, an interesting alternative approach to consider when creating front end code
    - Induane 5y ago
      It definitely is worth looking into. By reducing complexity around the interactivity portions of an application and all of the dom manipulation, it frees frontend developers to focus more on the aesthetic portion and the user experience itself.
  - arbenpurben 5y ago
    Damnit, I hate it when other people are more eloquent and on the money than me.
    - murkt 5y ago
      By far the biggest downside of this approach for me is that I found out about it in 2020 instead of 2013, when htmx predecessor was created (intercooler).
      - mkl95 5y ago
        The hype around reactive technologies in the mid to late 2010s looks kinda funny now considering how much unwarranted hot garbage companies have built with it. But hindsight is 20/20. Someone may be building a beautiful language that will kill JS in the 2020s, and in 2026 we'll all be wondering why weren't using it in in early 2022.
        sorry_outta_gas 5y ago
        TBH I think one of the real drivers was just being able to share an API with mobile apps, as 'mobile app for everything' dies down so will SPAs for everything under the sun
- arbenpurben 5y ago
  I mean this sincerely: can you demonstrate how using React et al for 95% of web apps (not talking about highly interactive stuff, offline-first or other special cases) was at all a step forward for web apps, OTHER than eliminating full page refreshes and thereby improving UX? Nevermind developer experience, although that is more subjective of course. The "decoupling" and "single JSON-based REST API for all clients", etc. arguments are nice in theory but impractical in reality. By all means have a JSON-based API for exactly that - application programming interfaces, not human-consumable interfaces. I would argue the development, deployment & maintainability complexity of those SPAs can not be justified for most web apps, if you are able to offer the essentially the same UX benefits with an HDA approach.
  - southerntofu 5y ago
    I love the idea of a SPA without full page refresh. But from experience, the UX of that is terrible! 99% of SPAs i've tried prevented me from using history navigation from my browser, and simply failed in unobvious way when the network wasn't reachable (yeah just keep on spinning without ever loading anything or timing out). When doing a "full page refresh" my browser has good UX for displaying errors and retrying requests, potentially resending <form> data. SPAs don't have any of that.SPAs is a cool pattern but as long as it is not supported by the HTML/CSS specs (and therefore the browser natively) it will remain terrible from a UX perspective.

This thing preserves your sanity!

by murkt 5y ago

This thing preserves your sanity!

throw_m239339 5y ago

I'm waiting for anyone to demonstrate me how this method isn't 3 step backward in 2022.

murkt 5y ago
It is three step backwards. And one step to the side. Which is what I needed, and many others too.
- throw_m239339 5y ago
  Ok, you mean this thing isn't worth my attention as a front-end developer? Carry on.
  - murkt 5y ago
    Yes, this is not for a front-end developer, this is for all the other people who don’t want to be front-end developers and don’t want to spend months every year to keep up with JS churn. Since we began using this approach, we can be full-stack developers again. One person can easily implement both parts, which is so much faster.
  - recursivedoubts 5y ago
    :) I think it's worth at least taking a look at the core idea is to use hypermedia, rather than an RPC-style architecture, and that is, at the least, an interesting alternative approach to consider when creating front end code
  - Induane 5y ago
    It definitely is worth looking into. By reducing complexity around the interactivity portions of an application and all of the dom manipulation, it frees frontend developers to focus more on the aesthetic portion and the user experience itself.
- arbenpurben 5y ago
  Damnit, I hate it when other people are more eloquent and on the money than me.
  - murkt 5y ago
    By far the biggest downside of this approach for me is that I found out about it in 2020 instead of 2013, when htmx predecessor was created (intercooler).
    - mkl95 5y ago
      The hype around reactive technologies in the mid to late 2010s looks kinda funny now considering how much unwarranted hot garbage companies have built with it. But hindsight is 20/20. Someone may be building a beautiful language that will kill JS in the 2020s, and in 2026 we'll all be wondering why weren't using it in in early 2022.
      - sorry_outta_gas 5y ago
        TBH I think one of the real drivers was just being able to share an API with mobile apps, as 'mobile app for everything' dies down so will SPAs for everything under the sun
arbenpurben 5y ago
I mean this sincerely: can you demonstrate how using React et al for 95% of web apps (not talking about highly interactive stuff, offline-first or other special cases) was at all a step forward for web apps, OTHER than eliminating full page refreshes and thereby improving UX? Nevermind developer experience, although that is more subjective of course. The "decoupling" and "single JSON-based REST API for all clients", etc. arguments are nice in theory but impractical in reality. By all means have a JSON-based API for exactly that - application programming interfaces, not human-consumable interfaces. I would argue the development, deployment & maintainability complexity of those SPAs can not be justified for most web apps, if you are able to offer the essentially the same UX benefits with an HDA approach.
- southerntofu 5y ago
  I love the idea of a SPA without full page refresh. But from experience, the UX of that is terrible! 99% of SPAs i've tried prevented me from using history navigation from my browser, and simply failed in unobvious way when the network wasn't reachable (yeah just keep on spinning without ever loading anything or timing out). When doing a "full page refresh" my browser has good UX for displaying errors and retrying requests, potentially resending <form> data. SPAs don't have any of that.SPAs is a cool pattern but as long as it is not supported by the HTML/CSS specs (and therefore the browser natively) it will remain terrible from a UX perspective.