4 ms·

> you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you

> you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it

ryanbrunner 3y ago
Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.
Xeamek 3y ago
>most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does
- endisneigh 3y ago
  Yes which is why you should generally stick with what you know until you have an actual problem that needs solving… SPA, MPA, who cares. Ship.
  - Xeamek 3y ago
    That's not how anything in the world works though
    - endisneigh 3y ago
      Most professions do work like that, actually.
      - ryanbrunner 3y ago
        - Hammer, screwdriver, who cares, fix it. - Scalpel, forceps, who cares, do surgery. - Reinforced concrete, 2x4s, who cares, build a bridge. No, pretty much every profession that uses tools cares about using the correct tools for the job.
        endisneigh 3y ago
        Yea, tools and processes they’ve decided on decades ago. You don’t see these people writing blog posts about new tools and wasting time evaluating them yearly like in tech. If there’s an actual issue like there was with deaths in the medical profession due to not washing hands, then they evaluate.
        Xeamek 3y ago
        ...except those field are literally a thousands years old, while software industry is about 70? Them being more mature doesn't change the fact that processes and tools are crucial
        endisneigh 3y ago
        No one is disagreeing with that.
        ryanbrunner 3y ago
        1. There probably is quite a bit of discussion about tool selection in some fields. Surgical innovations didn't end with the invention of the scalpel. I'm sure there's lots of discussion about the appropriate use cases for robotic vs laprascopic vs traditional surgery, we just don't see them because we're on a tech forum and not where medical doctors discuss tools. I can say for a fact that I've seen more written about the merits of various screwdriver heads than I would have thought possible. 2. Software development is a little unique as an industry since it's not all that common that the users of the tools are also the people who make the tools. There's naturally going to be a lot of discussion about tools if you're both the maker and the user of them. 3. Us not having a standard for which tool to use is a reason to have these discussions, not a reason to say "pick whatever, it doesn't matter". The reason that those people don't write blog posts and have discussions about the merits of a hammer vs. a screwdriver is precisely because they're so well established - if both were a couple of years old, absolutely people in construction would be discussing whether to use nails or screws for an application.
deleted 3y ago
[deleted]
christophilus 3y ago
It also depends on your definition of simple. The architectural model of Preact is simple. You change state, your application renders correctly. The architectural model of an MPA with interactivity sprinkled in seems as simple, but quickly becomes more complex over time, and has ultimately not been as simple in my experience.
- ryanbrunner 3y ago
  Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and is essentially a "put backend stuff here" slot) MPA frameworks tend to present themselves as complete and batteries included. If you're using Rails, you can build a complete application without thinking about a single other library than what Rails ships with. Neither approach is correct, but comparing them is like saying that HTML is so much simpler than C++ so everyone should use HTML.
  - christophilus 3y ago
    But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is unrelated to rendering. Angular is an example of what you describe, and it’s not for me.
    - ryanbrunner 3y ago
      Sure, that's fine, I'm just saying they're not really directly comparable. A batteries included framework is an entirely different beast than a view library.

ryanbrunner 3y ago

Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.

Xeamek 3y ago

>most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does

endisneigh 3y ago
Yes which is why you should generally stick with what you know until you have an actual problem that needs solving… SPA, MPA, who cares. Ship.
- Xeamek 3y ago
  That's not how anything in the world works though
  - endisneigh 3y ago
    Most professions do work like that, actually.
    - ryanbrunner 3y ago
      - Hammer, screwdriver, who cares, fix it. - Scalpel, forceps, who cares, do surgery. - Reinforced concrete, 2x4s, who cares, build a bridge. No, pretty much every profession that uses tools cares about using the correct tools for the job.
      - endisneigh 3y ago
        Yea, tools and processes they’ve decided on decades ago. You don’t see these people writing blog posts about new tools and wasting time evaluating them yearly like in tech. If there’s an actual issue like there was with deaths in the medical profession due to not washing hands, then they evaluate.
        Xeamek 3y ago
        ...except those field are literally a thousands years old, while software industry is about 70? Them being more mature doesn't change the fact that processes and tools are crucial
        endisneigh 3y ago
        No one is disagreeing with that.
        ryanbrunner 3y ago
        1. There probably is quite a bit of discussion about tool selection in some fields. Surgical innovations didn't end with the invention of the scalpel. I'm sure there's lots of discussion about the appropriate use cases for robotic vs laprascopic vs traditional surgery, we just don't see them because we're on a tech forum and not where medical doctors discuss tools. I can say for a fact that I've seen more written about the merits of various screwdriver heads than I would have thought possible. 2. Software development is a little unique as an industry since it's not all that common that the users of the tools are also the people who make the tools. There's naturally going to be a lot of discussion about tools if you're both the maker and the user of them. 3. Us not having a standard for which tool to use is a reason to have these discussions, not a reason to say "pick whatever, it doesn't matter". The reason that those people don't write blog posts and have discussions about the merits of a hammer vs. a screwdriver is precisely because they're so well established - if both were a couple of years old, absolutely people in construction would be discussing whether to use nails or screws for an application.

deleted 3y ago

[deleted]

christophilus 3y ago

It also depends on your definition of simple. The architectural model of Preact is simple. You change state, your application renders correctly. The architectural model of an MPA with interactivity sprinkled in seems as simple, but quickly becomes more complex over time, and has ultimately not been as simple in my experience.

ryanbrunner 3y ago
Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and is essentially a "put backend stuff here" slot) MPA frameworks tend to present themselves as complete and batteries included. If you're using Rails, you can build a complete application without thinking about a single other library than what Rails ships with. Neither approach is correct, but comparing them is like saying that HTML is so much simpler than C++ so everyone should use HTML.
- christophilus 3y ago
  But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is unrelated to rendering. Angular is an example of what you describe, and it’s not for me.
  - ryanbrunner 3y ago
    Sure, that's fine, I'm just saying they're not really directly comparable. A batteries included framework is an entirely different beast than a view library.