1. 17
  1.  

  2. 15

    halving memory usage is great! but still needing 500M for a chat client? sorry, but that is still nearly an order of magnitude too much.

    also, when they deployed these changes, the web UI broke in one of my browsers and noticeably slowed down. :/

    1. 2

      A note on the “magnitude”: Quassel with a load of channels uses 104MB RES here. Sure, 50 would be nicer, but I wouldn’t say I see a real problem here. Or is 100 still in the same magnitude as 50? ;)

      And yes, I also hate that it uses 500. Especially for people who only use 1 slack server/team, there’s literally no advantage :(

    2. 9

      Additionally, the technology landscape had shifted away from the tools we chose in late 2012 (jQuery, Signals, and direct DOM manipulation) and toward a paradigm of composable interfaces and clean application abstractions.

      I always find statements like this amusing. Composable interfaces and clean application abstractions are what I always heard was what programs were supposed to be. Did people in 2012 not care about writing good programs?

      Are they going to look back in another seven years and say “we shifted away from react, redux, and virtual DOM manipulation toward a paradigm of composable interfaces and clean application abstractions” as the winds shift again? Or will it shift to “we shifted away from X toward performant interfaces and clean application implementations?”

      Just silly.

      1. 5

        Judging by [other] tech companies’ blog posts, there always seems to be enough time to move to $CURRENT_JS_ZEITGEIST_FRAMEWORK versus actually writing clean code to make your choice of libraries/frameworks irrelevant in the long run.

        To their credit, it looks like Slack did the less sexy thing here while also upgrading to the current hotness.

        1. 7

          FWIW, React is 5 years old now. Where I work, we’ve been using it for all of that time and don’t have any plans to switch. Sure, maybe we’d use Preact to save some bytes on the wire sometimes, but it’s still fundamentally the same.

          I’m not saying there will never be a thing that replaces React or that there aren’t people out there using some new hotness. My point is more that React is fundamentally easier to reason about that jQuery DOM manipulation, and until someone offers a real step change, I’d expect a lot of folks to stick with it.

          1. 3

            Related to this, I’m always surprised when a game company is able to switch rendering libraries (OpenGL -> Vulkan) in a few man-weeks but then I remember they usually abstract over it in their framework/engine.

          2. 7

            Did people in 2012 not care about writing good programs?

            No they did not and they don’t now.

            1. 3

              A more accurate way of phrasing it would be “Additionally, as the original team got expanded and replaced, the Slack team had shifted away from the rapid prototyping tools we used in late 2012 and toward a paradigm of composable interfaces and clean application abstractions.” Apparently, they think their company is the whole universe.

              1. 1

                It was a lot more work and discipline to develop and maintain a nicely organized codebase with their old toolsthan with their new tools, partly because composability and clean abstractions weren’t explicit design goals for those tools. React/redux really was a major improvement over previous front-end arrangements.