Please. I beg you to buy a 2GB of transfer cell plan from a cheap carrier and try your sites via tethering. If you can only load your SPA a couple of times before your line gets disconnected, you've fucked up your design. I had plans with 35GB of transfer and the modern web meant I was having to restart my plan every single week. Some of us live in Internet deserts where there is no hope of getting a wired connection…
I don't think I've ever seen a site that would use up 2GB of data being loaded "a couple of times". What sort of site would do that?
Test your product on a crappy laptop
141–150 of 321 posts
Re: Test your product on a crappy laptop
#142Even more than crappy laptop, please please test your application on bad/degraded networks. So many apps completely glitch and breakdown in bad network environments.
I've used toxiproxy [1] to imitate various network problems (slowness, lost packets, dropping connections, etc). It works pretty well, and is even amenable to running during functional / integration tests. [1]: https://github.com/shopify/toxiproxy
Re: Test your product on a crappy laptop
#143There are three kinds of web developers: - Those who don't care about performance, as long as it loads within a few seconds on their own beefed up system on the LAN. This article is for them, and we can only hope they will listen. - Those who care about performance, and work for people who care. They are already doing great work (or are about to), producing those rare low-friction, high-speed, content-is-king sites w…
Explain Gmail.
Re: Test your product on a crappy laptop
#144However, there maybe another darkside of the story. Almost a decades back I talked a game dev, asking him why the game that they released demands such high hardware requirements. The two reasons that he offered was: 1) It costs money to produce & maintain content such as Level of Detail assets to enable support for low end devices, and 2) People cannot afford good computer usually also cannot afford to pay for the ga…
Then Roblox and Minecraft came along and showed everyone there was a large audience of kids on crap PCs and Chomebooks who will also play games and have parents who will spend for them.
(Btw, i developed medical dicom viewer for large CT and MRI data, on a 10yrs old dell Laptop. The viewer was always fast on customer machines. If it would not work on my machine, i tunded the Software until it does ;) )
Re: Test your product on a crappy laptop
#145I go one step further, all software I make is developed on Raspberry 2 (2W, JavaSE server) and 4 (7W, C/OpenGL client). That way I don't have to worry about missing any performance beat! Since energy prices are guaranteed to increase forever, I'm surprised this is not default behaviour.
Re: Test your product on a crappy laptop
#146Earlier quoted context omitted.
And as a dev, I make none of those decisions.
Also as a dev, I don’t really care. It’s not my money on the line, it’s the companies. If the site sucks and users don’t like it, the company loses profits and they will be forced to change. The only thing I take a stand on is when the product is actively harmful and immoral. Just being shit or slow is not my problem.
Re: Test your product on a crappy laptop
#147Most things are painful on one of those. Be the exception
Re: Test your product on a crappy laptop
#148However, there maybe another darkside of the story. Almost a decades back I talked a game dev, asking him why the game that they released demands such high hardware requirements. The two reasons that he offered was: 1) It costs money to produce & maintain content such as Level of Detail assets to enable support for low end devices, and 2) People cannot afford good computer usually also cannot afford to pay for the ga…
Re: Test your product on a crappy laptop
#149Re: Test your product on a crappy laptop
#150Even more than crappy laptop, please please test your application on bad/degraded networks. So many apps completely glitch and breakdown in bad network environments.
This. 2 rules: - Always indicate that your application is performing a network action (like showing a spinner, disable forms/buttons while submitting, etc) - Always catch errors (including timeouts) and give some form of feedback to the user when something went wrong. Try letting your local development backend return a 500, timeout or a 4xx error every now and then, and check if your frontend handles this in a gracef…
The worst offender I hit regularly is Google Meet. I use ADSL most of the day because it works just fine for most I do. Which is either local or ssh or looking up technical resources on the net. Even Google Meet works fine (I don't use a cam). Until I share my screen, which contains nothing but text in full screen. Then Google Meet will forever freeze the shared picture after a couple of minutes without anybody telling so. It's ridiculous that they cannot handle this reasonably, you don't need 30 fps to share a screen of slowly changing text. It's completely user hostile that there is no message for either the sharer or any participant that sharing has frozen and will never recover. This is paid usage of Google Meet.