4 ms·

For whatever reason, backend devs can be incredibly precious about their tech stack and rightly or wrongly believe that frontend devs make "silly" choices by no

For whatever reason, backend devs can be incredibly precious about their tech stack and rightly or wrongly believe that frontend devs make "silly" choices by not using their preferred stack. It's a form of technical smugness that pervades this site for any frontend JS thread. You rarely see frontend devs criticise backend devs on their tech stack.

Spivak 2y ago
No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set. If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux. Just React << HTMX < React with Friends. It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.
- phist_mcgee 2y ago
  There you go, claiming another silly choice by frontend for using something built in the last 15 years will rot. It's just not true in my experience.
  - Spivak 2y ago
    It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."
- robertoandred 2y ago
  An unmodified frontend will also function the same exact way until the heat death of the universe.
  - Spivak 2y ago
    This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes. If you think rotting sounds too negative how about "maintenance unfriendly."
    - robertoandred 2y ago
      Your argument was about unmodified code, not mine. If you only want minor changes, don’t install new major versions.
      - yawaramin 2y ago
        How does that work in an ecosystem which is constantly releasing new major versions and not backporting security fixes to old majors?

Spivak 2y ago

No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set. If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux. Just React << HTMX < React with Friends. It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.

phist_mcgee 2y ago
There you go, claiming another silly choice by frontend for using something built in the last 15 years will rot. It's just not true in my experience.
- Spivak 2y ago
  It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."
robertoandred 2y ago
An unmodified frontend will also function the same exact way until the heat death of the universe.
- Spivak 2y ago
  This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes. If you think rotting sounds too negative how about "maintenance unfriendly."
  - robertoandred 2y ago
    Your argument was about unmodified code, not mine. If you only want minor changes, don’t install new major versions.
    - yawaramin 2y ago
      How does that work in an ecosystem which is constantly releasing new major versions and not backporting security fixes to old majors?