1. 14
  1.  

  2. 18

    Some people want the novelty, the certainty, the feeling of ‘community’ that results in everyone making the same decision regardless of technical soundness. Frameworks are for them, because they trust in the collective institution of Everyone Else to back them up when there’s a problem.

    Others are closer to technical DIY types, who want the increased responsibility, and autonomy that frameworkless-ness brings to the table.

    Two other dynamics worth discussing:

    • the huge number of novice users: these create the demand for magic frameworks. They’re typically devs who have 1-3 years experience but lack the understanding to realize a framework will not fix their lack of understanding. Though they don’t know a lot, they collectively wield the attention of a chunk of industry that is hellbent on ‘relevance.’

    • social incentives to create frameworks: conference talks, Github stars, Twitter followers (eInternet Points).

    The only real way to fix this is to prevent juniors from influencing industry as much as they do. So long as we regard HN as a bastion of technical knowledge, this will not change.

    1. 6

      It’s stunningly rare to work on a software problem that is well-understood.

      Being able to churn out a working prototype in a week (and have users) is a huge boon to understanding the problem-space. Magic frameworks are really, really good at helping you do that.

      1. 2

        Of course!

        But how often are they discarded when past the prototyping phase?