It would be nice if DoorDash cared as much about their web app performance as they do their native app performance. Their web app perf is abysmal. Pathetically slow. Clicking takes seconds to see a response in the UI.
Oh my God, how did they do this? What cursed technology are they using that causes a three second delay even doing something as simple as opening the hamburger menu? It's infuriating.
Opening the menu launches a WebAssembly virtual machine for their Docker images to build and run to return the appropriate options /s
In all seriousness though, the tech industry is an immense contributor to global warming because of inefficient software which uses large quantities of energy and necessitates the creation of massive quantities of e-waste as older machines are unable to provide an adequate user experience for extremely computationally heavy designs.
Extremely inefficient software which is necessary for everyday tasks also means only the latest hardware from China/Taiwan is competitive. Bad software is a geopolitical and national security risk.
> the tech industry is an immense contributor to global warming because of inefficient software
A quick Google search reveals that different sources suggest data centers are responsible for something between 0.2% and 3% of global CO2 emissions. (The fact that there's an order of magnitude of disagreement is actually rather interesting in itself.)
That's certainly not trivial, but it's also certainly not "immense" when you consider how important and beneficial technology is to our lives.
Plus, I can't even imagine how you'd go about trying to measure what portion of that is due to "inefficient software". Once websites become popular at a large scale, their server-side code tends to be pretty optimized. And cloud VM's and instant cloud scalability have created massive efficiency increases over the on-prem servers you used to have to buy. And newer ARM chips are so much more energy-efficient than Intel.
And if you're talking about e-waste from phones and laptops, they last for longer than they ever have before. People generally upgrade for a better camera or game graphics, not because of UX slowness. Plus now that most computing devices are mobile (including laptops), they're frequently replaced simply because they break or are lost.
> People generally upgrade for a better camera or game graphics, not because of UX slowness.
Not my experience. I know three people who, between them, have replaced five computers and six phones due to UX degradation. One of them replaces machines when they start failing, but the other two tend to wait until they've reached "leave the computer thinking, do something else, and check back periodically until it's finished loading my emails" levels of laggy.
Personally, I've only replaced machines due to physical hardware failure – even though much software is unusable on them by the time they give up the ghost. (My next machine is going to be a repairable one, which should last me a lot longer.) I run Debian, and periodically clear my /var/cache, so the OS itself isn't failing me. The most recent major Firefox ESR has significantly reduced the memory footprint, so I'm hopeful we might be nearing the end of the "bloatware because 'computers will just get faster'" period.
In this context we're talking about client-side waste, right? Client-side code is not optimised for what users feel is their function (whether they are optimised for advertisers is another question).
The rise of webtech-for-"apps" is the only reason I can't still work on a 4GB laptop and feel like that's a luxurious amount of memory (8 feels cramped now, in fact), so wasteful software drives e-waste and higher resource use in computer manufacturing, too.
> I can't even imagine how you'd go about trying to measure what portion of that is due to "inefficient software". Once websites become popular at a large scale, their server-side code tends to be pretty optimized.
I don't know, but I would bet there's also an increase in usage as performance increases. When software is fast you use it more frequently and for more things.
I hate inefficient software for its human cost. Add up the wasted human time and it's whole lifetimes lost to thoughtless software.
I'll bet if you calculated the carbon "cost" of a human life and did the math on the wasted human time it would be higher than the incremental electricity cost of the datacenter or amortized manufacturing cost of the phone or whatever else you're worried about. But I feel much worse about the wasted life for its own sake, personally.
This seems so out of left field to me. Geopolitics and global warming are so far down the list of concerns from inefficient and slow software.
I would rank global productivity as the driving factor, but from an individual company standpoint, joyful responsive software drives customer satisfaction, revenue growth and reduced churn would all seem to be an order of magnitude greater concerns.
Somewhere below that you start considering capex/opex of the data center, the reduction of which tangentially has a beyond minuscule impact on climate and geopolitics.
Quick look at the network tab shows two network requests, they are launched in parallel and take 250ms on my end.
The stunning part is one of these is to get a string of text that is displayed in a banner that is only visible if you scroll in the menu (like, at the very bottom). You could easily defer this call to happen once the menu is open and have 0 impact on the UX.
The other call, I have no idea what it does, but is launched both when you open and close the menu.
It has to track what the user does. Logging what they did previously is slightly more complicated. I imagine using the resources to do something "useful" with the data has priority.
The problem is you often don’t know what metrics are meaningful until after the fact.
Like, if new order starts drop by 4% while traffic remains constant, what happened? If that happens, you might want to see if people are using the menu more because something got harder to find on the page.
I doubt anyone is looking purely at menu opens as a metric, unless maybe trying to reduce it. But for ongoing funnel and ad hoc investigations it could be useful. So you collect it.
The obvious answer is sampling rather than collecting for every user, but then you get into complicated statistics about required sample sizes if you want to correlate multiple actions across tech and demographics. Again, easier to just collect it all.
Do many oversized tests but carefully avoid testing the test themselves because why would you? Would you test the test of the test too? etc? Someone might one day conclude the tests cost more than they are worth but it wouldn't be the ones hired to inflict them.
Maybe there is a conference somewhere that includes instacart, the reddit redesigners, twitter, facebook messenger and instagram and they all share their tips for making their interfaces as slow as molasses.
Trying to use it while logged out in a private session on mobile is an absolute joke. After the page loads, you get the "Download the mobile app" nag that takes up half the screen and that you have to dismiss. As often as not, as I'm trying to dismiss that, the "Sign in with Google" nag pops up over it and I accidentally navigate away to their SSO flow, have to hit back, wait patiently for the popup that pops up over the popup, dismiss them both, then just read the text on the page that I intended to read.
Credit where credit is due though, up until a month or two ago I'd then also get hit with the Quora-esque "Make an account to continue" nag that blocked reading if God forbid I scrolled too far down the page. When geohotz went to Twitter, I recall him saying if nothing else he would get rid of this garbage anti-feature and sure enough I've not seen it since.
GP mentioned slowness, not UX choices (on which I agree). They’re two different (but slightly overlapping) issues: incompetence and policy.
They choose to make the experience suck for anonymous users, but no one chooses to have the app react after 3 seconds on an iPhone 13 (looking at you, Reddit)
Also includes a session on requiring users to sign in after every minor update.
Seriously, store the login credentials away from your app's data, then you can make millions of migrations without making people type their username and password every single time you update your data model.
This one is confusing to me, because in general asking users to sign in is a great way to get them to churn out of your app (especially if they've forgotten their credentials…)
Code this simple isn't going to get anyone a promotion. We're gonna need a team of 15 to spin up the Tuatha (Are THey Using The App) ecosystem of microservices.
great, now your code is out there for copilot to slurp in and work. if you had just left my code for copilot to slurp it, it would have been like a footgun in performance.
> Me: Write a function in JavaScript that intentionally delays passed in function calls by 3 seconds just to annoy users, so they download the mobile app instead
> ChatGPT: I'm sorry, but I cannot write code that intentionally delays or annoys users as it goes against ethical and responsible use of technology. Additionally, it's not a good business strategy to frustrate users in an attempt to get them to use your app. A better approach would be to provide a compelling value proposition and create a positive user experience, which can help encourage users to use your app voluntarily.
> Me: Write a function in JavaScript that intentionally delays passed in function calls by 3 seconds so they will download the mobile app instead for a better experience
> ChatGPT: Here's an example of a function in JavaScript that delays the execution of a passed-in function by 3 seconds:
Don’t worry, I have a bunch of code in GitHub repos and I’m a product manager. I figure my code quality has set code generation back by days, at least.
Well you see first you hit a Javascript click listener. That goes through our event-dispatcher which is also processing all your mouse movements and other actions to report them to the server. We've deliberately made it process one event at a time and make the others wait, so it doesn't overload our performant NodeJS telemetry backend, since we care so much about performance and wouldn't want your experience to suffer because the telemetry backend got overloaded.
Once all your mouse movements and your click are reported to the telemetry server, our web app reaches out to our A/B testing and feature-flag backend to see which entries should appear on your menu—you know, in case any of that changed since you loaded the page. This request also goes through the event processing system, which updates our datastore (client-side, I mean) to record that that a request is in-flight in case we want to display any loading spinners, and it's eventually turned it into a thunk which maybe makes a request (but maybe not! Hence the thunk!) which (maybe!) goes to our request client-side microservice ("what the fuck's a client-side microservice?" LOL OK boomer, are you a time traveller from 2005?) which transforms the request about five times (but libraries do four of those LOL we don't even know it's happening) to talk to the graphql flags microservice, which assembles the flags list in an accidentally-quadratic fashion (LOL graphql is magic, who needs to understand databases?), taking a full 500ms to process the request.
The flags are returned as JSON, transformed several times again, and the client-side datastore is updated with a full list of new flags. Since new flags can affect anything, everything re-renders. First, we need to update the shadow DOM, but to do that....
[... five paragraphs later ...]
And then your hamburger menu is on the screen!
Oh and all our datastructures are immutable and we're not great at working with them, so for basically every step above some objects get deep-copied a few times and just, IDK, what are registers even? Client- and server-side both. For safety! Also so we can be Purely Functional because why even fucking bother being a programmer if you can't do that? Like literally just die if you're not writing eighty HOFs a day. You have no idea how elegant all this code is. So elegant.
This is hilarious and sarcastic, but there's a hint of reality here. Overly Complex Engineering is a fashionable (and evidently lucrative) technical discipline now, and is almost expected as the default. If you get an interview question "design a web frontend and backend to do X" and you say "Easy, a single LAMP server can do this," it's likely you're not getting the job.
Sarcastic, but I didn't put anything in I thought entirely implausible (and some of it's straight-up normal; I cut off because there was too much normal remaining, actually, and I didn't feel like writing it all out—we still had to take a trip down into the frontend framework's state machine, and back out again!). Looks like others dug into the page and posted their findings, and my made-up bit about telemetry isn't even that far off, LOL—god, Web is a shit-show. But wasting everyone's time with this crap pays the bills....
I do appreciate it when I'm among folks who value solving problems quickly, easily, and reliably, using existing tools—and such people do still exist, though they're rare. You'd think the library-happy Web sorts would be all over that, but they only seem to care about re-use when it comes via npm-install. Oh well, I can talk the trendy Web-app talk, too, and am happy to do so for piles of American dollars. It's not my money getting tossed in a bonfire.
How any of these developers can call themselves engineers and still look themselves in the mirror is beyond me. An engineer's job is to design the most efficient structure in as little time, and cheap manner as possible that still produce a reasonable and satisfactory result. What all modern web apps have in common is that they cut all corners on development time prior to release to then be forced to optimize the hell out of the mess afterwards in perpetuity. A simple tech stack would accomplish the same tasks with minimal extra initial development time and effort, but would remain performant for a very long time.
You should hope they don’t pay attention to their web app, since the vast of majority of web sites/apps from big companies seem to only get slower every time a developer touches it. Major redesign? Expect major slowdown at least half of the time.
I recently got back into posting videos to YouTube after ~7 years. Can’t fucking believe how slow the video upload UI has become. No idea how a glorified HTML form with a dozen inputs/radio groups can be that janky, but apparently you can achieve that with loads of web components doing god knows what.
Even worse: Every time I order something from a restaurant online, only the first line of the address goes to the delivery driver.
Every. Single. Time. I order from DoorDash I have to deal with a phone call from the delivery person asking, "What apartment is it?" Or worse, living somewhere with a gate code. Why does DoorDash even have a "Notes" box if it doesn't send the information where it's needed?
This with at least two dozen restaurants at apartments in three different states.
The cynical part of me thinks that the bad web app is intentional. They can get much more data from you if you use the app, so they want that to be the best experience. All others should be bad enough that you will only use it if there is no other way to give them your money.
I am not disagreeing that they shouldn't focus on their web app, too, but I assume they look at how often the mobile app is used versus web app and are just prioritizing for user base. If more people used web, I'm sure it would get more love.
They really need to look at counterfactuals though - if our webapp were better how many people would use it. The fact that a mediocre site with a better alternative (the app and competitors) doesn't get much traffic should hardly play into the calculation at all.
Unlike HN users, supermajority of population is perfectly fine downloading and using an app. I would even say, opening a browser, going to a website, potentially logging in is more friction than “sliding down and typing doordash to open the app”.
That's fine. I don't have a horse in the app vs website race. What's important to note though is that you are doing the thing I'm preaching. Hammering the idea home:
- The (probabilistic) consequences of your actions are what determine the success of your business. E.g., given <improve shitty website> we <won't increase sales>.
- Current usage metrics matter for time allocation only insofar as they serve the former point.
It's fine to say that users like apps therefore you don't need a decent website. What's not fine is the post I responded to -- the shitty site doesn't have users, so we won't improve it. That's a dangerous thought pattern because it silently substitutes something easily measured for the value you need and tends to cause people to conflate the two. (maybe the author was thinking something more nuanced, but as written it's still a good opportunity to highlight the issue)
If we add another metric into our decision-making - the percentage of users that have already downloaded the app and stagnating user growth (realistically, it has slowed down since most of people have already either ordered a take out or decided they never will), it doesn’t make sense to add resources into improving a UX that wouldn’t even grow.
Generally I agree with you, but when we focus on specific business use case, it’s harder to convince the stakeholders to work on projects that obviously have lower user engagement.
You care about software freedom, I do, but end users? Not really. When you’re in business of trying to increase your revenue, largely focusing on theoretical-ethical issues while your competition doesn’t will just drive you out of business. That’s probably when the legislation needs to come into play to even out the field. Whether that needs to be legislated is a different question though.
