I’m being a little more prescriptive than descriptive, & that’s probably why my categorization is…
I’m being a little more prescriptive than descriptive, & that’s probably why my categorization is simplistic. But, it’s not totally accurate that I’ve broken the situation into only two categories. I see four:
- technical (i.e., electron is actually the best tool for the job)
- tactical (i.e., we have an existing web app & we need to ship a native version on monday)
- political (i.e., the boss likes electron)
- information-flow (i.e., half our team is only familiar with web stack, or nobody on our team knows that there’s a better tool for the job)
I’ve made some attempts to argue that #1 is quite rare. I’m not convinced that a situation where electron is really the best technical fit exists, though I’d love to be proved wrong on this — it would bring it, in my mind, from the category of technologies that are equally bad at everything to the much more interesting category of technologies that can do everything but are much better at one particular domain than all others. In practice, all four tend to interact to some extent, so you get qualified successes like “this is the best tech (#1) that our team is comfortable with (#2 & #4), aside from this other thing that corporate won’t let us use (#3)”.
Small-computing situations (like personal projects) are a different beast entirely. In small computing, concerns like curiosity, masochism, competitiveness, playfulness, perversity, and showing off can easily individually override technical and tactical concerns, and in fact many technical and tactical concerns can be ignored or inverted. But, once you have customers, the kinds of intrinsic motivators that drive personal projects should never override the responsibility to the customer. In practice they do all the time, because we don’t do a very good job of separating hobby programming habits done in our free time from professional habits that make sense when there are higher stakes.