47 replies

1. Bob Monsour 8 min later

   @zachleat @slightlyoff Wrote about this here: https://infrequently.org/2024/01/performance-inequality-gap-2024/ and did a talk on it, video here: https://cfe.dev/sessions/jamdev2024-market-for-lemons/

   1. Marijke Luttekes 39 min later

      @bobmonsour @zachleat @slightlyoff "Since at least 2015, building JavaScript-first websites has been a predictably terrible idea"

      I might need this printed on a T-shirt.

      1. Alex Russell 49 min later

         @mahryekuh @bobmonsour @zachleat @phae made shirts as a fundraiser for @owa:

         https://www.bonfire.com/anti-javascript-javascript-club/

         1. Eloy 1 hr later

            @slightlyoff @mahryekuh @bobmonsour @zachleat @phae @owa Meh, JS is fine, just keep it to reasonable size and prefer CSS alternatives

            1. Marijke Luttekes 1 hr later

               @eloy @slightlyoff @bobmonsour @zachleat @phae @owa I'm with Eloy. The right tool for the job, instead of JS for everything. 🔨

               1. Alex Russell 2 hr later

                  @mahryekuh @eloy @bobmonsour @zachleat @phae @owa That's literally what the anti-js-js-club stands for

                  1. Zach Leatherman 2 hr later

                     @slightlyoff @mahryekuh @eloy @bobmonsour @phae @owa two javascripts is a double negative and now I’m confused

                     1. Brian LeRoux 💚 2 hr later

                        @zachleat @slightlyoff @mahryekuh @eloy @bobmonsour @phae @owa JS is like violence. If it isn't working you need more of it. Wait.

                        1. Marijke Luttekes 2 hr later

                           @brianleroux @zachleat @slightlyoff @eloy @bobmonsour @phae @owa Instructions unclear, added onclick to a div.

                  2. Eloy 2 hr later

                     @slightlyoff @mahryekuh @bobmonsour @zachleat @phae @owa Oh, right. Thanks for cleaning that up :P

            2. Ubergeek 23 hr later

               @eloy @slightlyoff @mahryekuh @bobmonsour @zachleat @phae @owa Exactly. Use JS only for when CSS isn't able to do what you are trying to do.

               Corollary: If CSS isn't doing something you're trying to do, you should think long and hard about why you're doing it, and if it's really a good idea...

               1. Marijke Luttekes 23 hr later

                  @ubergeek @eloy @slightlyoff @bobmonsour @zachleat @phae @owa Progressive enhancement FTW.

      2. enoch_exe_inc 3 hr later

         @mahryekuh @bobmonsour @zachleat @slightlyoff Not least of which it has been terrible for privacy.

   2. Private reply 6 hr later
2. Melanie 13 min later

   @zachleat surely it depends. An app used internally at a large corporation should not have to worry about worse-case fast. Heavy duty apps can do heavy duty lifting on networks created for that purpose.

   Any public website absolutely should be worst-case fast though.

   I don’t know where webdevs work or why we seem so incapable of this nuance. It can be both. It depends.

   1. Alex Russell 25 min later

      @a11yMel @zachleat IDK, I'm suffering through a lot of "apps used internally at large corporations" right now, and they're not OK. Not even on beefy machines, and I know for a fact that many folks in the org have worse/more-taxed machines

      1. Melanie 1 hr later

         @slightlyoff @zachleat fair enough 🤷‍♀️

         1. Cory 1 hr later

            @a11yMel @slightlyoff @zachleat one of the ecommerce shops I worked at the past had a *glacially* slow public-facing set of web properties and fought the dev team trying to improve them, but internal apps were significantly faster. Sigh.

   2. soaproot 33 min later

      @a11yMel @zachleat Perhaps that statement about internal corporate apps is true if there is no remote work, no satellite offices in areas with less-good Internet, and corporate users are always on recently upgraded machines which prioritize speed over battery life or portability. But none of these assumptions is especially true of most corporations, especially these days.

3. Liam Bigelow 16 min later

   @zachleat performance ceiling vs performance floor can be another good phrasing

   1. Zach Leatherman 35 min later

      @bglw I love that 🏆

      1. Liam Bigelow 2 hr later

         @zachleat ✨ yes hello my site is fast ✨

4. Private reply 37 min later
   1. Private reply 39 min later
      1. Private reply 46 min later
5. Marijke Luttekes 41 min later

   @zachleat If only developers would share some of their love for bulky framework and divs with subjects like performant websites and accessibility 😒

6. benschwarz 1 hr later

   @zachleat testing the full spectrum of slow device / slow network to ‘fastest possible’ has been a mainstay in messaging from me @calibre

   However, there are still a lot of teams out there who intentionally hide worst case scenarios because it’s so bad and represents too much work to improve.

   They’re so busy with the best case, that poor experiences don’t get a look in, which is totally counterintuitive because if you make a page fast for a slow phone, it’ll FLY everywhere else.

   1. Zach Leatherman 1 hr later

      @benschwarz @calibre well said!

7. Cluster Fcku 1 hr later

   @zachleat same for "best case safe": as long as you follow the law, the procedures & regulations, the schedules, the training, common sense, reasonableness, all patches, all updates, all guidelines, and take personal responsibility for any of the holes, live in a bubble where you can afford all that money and time, it will all be safe!

8. Eric Portis 1 hr later

   @zachleat another fun thing to measure would be performance consistency/variability: the ratio of best-case to worst-case.

   1. Eric Portis 1 hr later

      @zachleat although I expect that would be highly correlated with worst case…

9. groxx 2 hr later

   @zachleat worst-case fast also gets you an *unbelievably amazing* experience on the best-case stuff.

   I love using low end hardware to build things. You find out what hurts your end result FAR earlier, when you're more easily able to fix it. And then the final result absolutely screams on decent machines, and that's an amazing feeling.

   1. Zach Leatherman 22 hr later

      @groxx well said!

10. 4everpushingaboulder 2 hr later

    @zachleat app dev has blamed performance on network, database, IO, cpu for years, while writing heavy code optimized for their test lab instead of production.

    Cloud based, microcoded, API, shared service enterprise buss were supposed to be the fix to keep us dumb infrastructure folks from being in the way.

    Always told people it’s just 4th grade math. 8 bits per byte. Do the math.

11. Dan Herbert 2 hr later

    @zachleat It's the classic "works on my machine" mentality. Lots of devs have good devices & fast internet and often never consider (for a variety of reasons) the diversity of clients they're going to serve.

12. Tushar Chauhan 2 hr later

    @zachleat What about static sites that are built as apps? Stuff like gatsby or astro?

    1. Zach Leatherman 22 hr later

       @tchauhan React has shown itself to be pretty slow! That said, there is a spectrum of React tooling. I’d rate Astro > Gatsby > Next.js for fast outputs of React stuff

13. Jeff Grigg 2 hr later

    @zachleat

    As I was explaining to our local water and sewer utility, …

    I'm paying my monthly bill from a small city in Argentina. I don't want or need a full-screen video of local water features to play before you allow me to access and pay my (typically less than $100) monthly bill! And some of your local customers, like my parents, are *still on dial-up*. With *OLD* computers. Like "should be recycled" computers that Barely Work!!!

    1. Jeff Grigg 2 hr later

       @zachleat

       Now as to why I would be paying local mid-Texas utilities from South America, or Ireland, or across the date line in New Zealand, …

       Well, I have my reasons.
       (And they're none of the water company's business.)

14. Jared White (ResistanceNet ✊) 3 hr later

    @zachleat Funny about that year mentioned in @slightlyoff's article, 2015.

    I was told in 2015 by a “CTO” that I should ditch my Ruby on Rails skills, learn how to write JSON APIs in Node, and build all my UIs in AngularJS going forward. This was the future!

    He may have been broadly right about the popularity of Node, but the rest of that mindset turned out to be a minefield of antipatterns. While today I'm no particular fan of Rails, it's wild how SSR (plus SSG) is all the rage once again.

    1. McNeely 4 hr later

       @jaredwhite @zachleat @slightlyoff AngularJS certainly was a web technology 🫠

       1. Jared White (ResistanceNet ✊) 5 hr later

          @McNeely @zachleat @slightlyoff It certainly was…written in JavaScript. Yup. 😂

15. 💡𝚂𝗆𝖺𝗋𝗍𝗆𝖺𝗇 𝙰𝗉𝗉𝗌📱 6 hr later

    @zachleat
    This post boosted by someone with a fast dev machine but still running Android Marshmallow on their phone ;-)

16. Russell Garner 12 hr later

    @zachleat we lack the vocabulary (and metrics) to make meaningful statements about our software's efficiency.

    By rights, Elixir should be running away with things based on Phoenix's performance alone, but we're not hiring for efficiency. We're hiring for popularity and/or groupthink.

17. Mark Stosberg 14 hr later

    @zachleat Twitter and WhatsApp both grew quickly early on because they worked on lowend phones. Twitter’s original text-only 140 character limit was strategically intentionally aligned with what SMS could do.

    WhatsApp ran as a Java app on non-Android, non-iOS phones.

    1. Dec [{()}] 3 days later

       @markstos @zachleat
       Twitter's initial character limit was 140 so that you could use it over SMS if you didn't have a smart phone.
       They even had a vanity SMS shortcode in some countries.

18. Sascha Presnac 🙄🤦‍♂️ 14 hr later

    @zachleat I am so with this 🙏