The exchange is about Meta’s upcoming ActivityPub-enabled network Threads. Meta is calling for a meeting, his response is priceless!

    • nameless_prole@kbin.social
      link
      fedilink
      arrow-up
      15
      ·
      edit-2
      1 year ago

      Anything good Facebook/Meta has ever or will ever possibly make, immediately becomes garbage due to where it came from.

      Fruit of the poisonous tree.

      • zimzat@kbin.social
        link
        fedilink
        arrow-up
        10
        ·
        1 year ago

        React is incredibly popular because so many companies use it. They are banking on Facebook’s continued support and development, and an assumption that if Facebook is doing it then it must be right. Being rich does not automatically make one right. Having worked at a company that forced React on its developers against their wishes I can unequivocally say it’s bad.

        In any system the right action should be the default action. Query parameters should be parameterized by default, variables in HTML templates should be contextually escaped by default, and so forth. “Don’t make me think”. React is the complete opposite of that: It requires you to constantly think about the render loop (aka “Component Function”), it hides the fact there is an object behind the scenes containing the component state, the documentation is littered with “don’t worry about this feature until after you have a performance problem, then come back here for the solution”, it’s very neat and tidy for tiny example projects but does not scale well as the project grows.

        Using useMemo and useCallback to Save the Past from React Langoliers + Thoughts on React vs Vue vs Everything Else in 2023

        Compare that with a system like Vue or Lit, which is much more intuitive, does the right thing by default, and is easier for existing HTML/CSS/JS developers to grok at a glance.

        • fazalmajid@kbin.social
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          Don’t forget Svelte. That said, traction means more developers trained in any tech stack, that’s why my previous company ditched Vue for React circa 2016, Vue seemed destined for oblivion and irrelevance at the time.

          • zimzat@kbin.social
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            more developers trained in any tech stack

            That is the primary argument my company used to justify forcing React. Do you know how many people we hired for their React experience? One. Everyone else was primarily backend or only had passing experience in React (not subject matter expert / does not know best practices). Meanwhile the rest of the team struggles to work in it (the frontend has become siloed) and very little of it follows best practice.

        • smokinjoe@kbin.social
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          lmao I love that article, thanks for the link!

          Ironically enough, I just got done troubleshooting some insane rendering problems that a useMemo fixed

          I’ve been meaning to scope out Vue and never heard of Lit - thanks for some weekend inspiration

        • zimzat@kbin.social
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          The reactivity of Svelte leaves a lot to be desired. The only difference between a computed property and a mutable property is let x = and $: x =, both of which are declared in the same top-level scope and doesn’t provide much to distinguish them. The lack of reactivity on arrays and objects is a major foot-gun by default. The number of places they say “this looks weird, but don’t worry it’ll soon become second nature” in the docs shows that they acknowledge it’s bad design to create code that is misleading or goes against the grain/standard for what behavior developers should expect (makes it confusing to work with and then use anything else, or vice versa).

          The #await template directive is interesting; I’m not sure I agree it should be handled in the template instead of the script but if combined it would remove some boilerplate loading = true/false and error = 'message' variables from script scope.