aube was about 30% slower than pnpm in my testing on our hundreds-of-dependencies monorepo, but I'm giving it time and keeping a testing branch around. (hi jdx yes I am that guy.) Honestly this speaks to how good pnpm is more than saying aube can't get there.
I'm still opening pnpm-behavior bug reports against aube daily (boo) but they are getting fixed very quickly (yay). I'm really looking forward to seeing if it's worth rolling out once he catches up with the long tail of subtle behaviors we rely on.
Again, pnpm sets a high bar, so even if aube ends up getting faster, it's not a sure thing.
Working on mrjob was a big part of my first job out of college. Fun to see it get mentioned more than ten years later.
What some commenters don't realize about these bureaucratic IO-heavy expensive tools is that sometimes they are used in order to apply a familiar way of thinking, which has Business Benefits. Sometimes you don't know if your task will take seconds, minutes, hours, days, or weeks on one fast machine with a well-thought-out program, but you really need it to take at most hours, and writing well-thought-out-programs takes time you could spend on other stuff. If you know you can scale the program in advance, it's lower risk to just write it as a Hadoop job and be done with it. Also, it helps to have an "easy" pattern for processing Data That Feels Big Even If It Isn't That Big, Although Yelp's Data Actually Was Big. Such was the case with mrjob stuff at Yelp in 2012. They got a lot of mileage out of it!
The other funny thing about mrjob is that it's a layer on Hadoop Streaming, which is a term for when the Java process actually running the Hadoop worker opens a subprocess to your Python script which accepts input on stdin and writes output on stdout, rather than working on values in memory. A high I/O price to pay for the convenience of writing Python!
Today I'm hacking on automate-terminal, a command line program and Python library that abstracts the various terminal emulator automations (iTerm2, WezTerm, Kitty, tmux) into a single API. Mostly made for use by other tools. https://github.com/irskep/automate-terminal
I'm really excited by this development! Material for MkDocs has raised the quality level of so many projects' docs, my own included, by making good navigation the default. It's by far my favorite system to browse as a reader, and use as a project maintainer.
I hope the new theme allows for more customization than the old Material theme. It was really hard to create a unique brand identity within the constraints of Material; it just wasn't built with customization in mind beyond a color. The "modern" theme looks minimal in a way that gives me some hope for this.
It all depends on whether the number includes network roundtrip or not, which they don't state. I read it as not including a network request, i.e. all CPU and local I/O.
Replying to myself for clarification: I did not read their 500ms number as including waiting for a network. It sounded like that's how long it was taking React Native to load local data and draw the screen. If that's not the case, it's a very different story.
> For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful.
I agree with most of the other comments here, and it sounds like Shopify made sound tradeoffs for their business. I'm sure the people who use Shopify's apps are able to accomplish the tasks they need to.
But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.
I'm still opening pnpm-behavior bug reports against aube daily (boo) but they are getting fixed very quickly (yay). I'm really looking forward to seeing if it's worth rolling out once he catches up with the long tail of subtle behaviors we rely on.
Again, pnpm sets a high bar, so even if aube ends up getting faster, it's not a sure thing.