Live data from Hacker News

Test your product on a crappy laptop

css-tricks.com

261–270 of 321 posts

Re: Test your product on a crappy laptop

#261

Earlier quoted context omitted.

Even a low-end modern system only takes you so far back in time. Keep in mind that hardware improves roughly on line with Moore's Law. The gradation from low-end to mid-market might only be a few years of development. The 10-year-old system is probably going to be much worse than a current low-end buy.

Try it first. Moore’s law hasn’t been kind to x86 laptops, and the tricks used to speed things up are missing from low end celeron processors and binned SSDs. The cheap hardware and poor touchpads add to the charm. I would bet that the 10 year old Lenovo would be surprisingly better than the shitty 2021 device.

CPU clock speeds haven't increased.

There's been SSDs, increased cache, increased memory speed, and more cores.

You might want to go back a bit more than 10 years, but yes, even a reasonably high-grade older system in my experience really dogs out on the current Web.

Re: Test your product on a crappy laptop

#263
post #207

Crappy phones, too! At one of my previous jobs there was a "device lab" where they had all sorts of phones and laptops for anyone in the company to come in and use and test things on. They had various generations of iPhones and iPads, high end and low end Android phones, some Windows laptops and an old MacBook. The room was open to all and freely accessible by anyone. I saw UX, dev, QA, product managers, and even the…

We had that too and our QA team made good use of it.

Re: Test your product on a crappy laptop

#264
post #77

I just put the throttling on in the network tab of Firefox/chrome developer tools. Plenty realistic

That throttles the internet bandwidth, not CPU, memory, disk reads/writes or any other constraints that lower-priced hardware will have.

It’s true but as an approximation it’s pretty good no?

Re: Test your product on a crappy laptop

#265

Earlier quoted context omitted.

Unpopular opinion: Most web developers don't have a grasp of computer science or assembly, and act like computing resources are free. OTOH, obsessing about performance to the exclusion of usability is equally insane. Nuance, knowledge, and metrics are what's needed.

Idk how CS or Assembly plays into this. I’m a webdev. Self taught. Your points about metrics and nuance are accurate but I fail to see how those are related to CS as a whole. If stuff is legitimately slow, we should make it faster. Doesn’t need to be more complicated than that imo.

I don't think assembly has any relevance, and the thing with CS that's relevant is almost entirely with complexity theory. This sounds fancy, but it basically boils down to recognizing O(n^2) vs O(n) vs O(n log n), which in practice can be reduced to "use the right datastructure" and "use the right query".

Re: Test your product on a crappy laptop

#266

> British soldiers in World War I were equipped with a Brodie helmet, a steel hat designed to protect its wearer from overhead blasts and shrapnel while conducting trench warfare. After its deployment, field hospitals saw an uptick in soldiers with severe head injuries. > Because of the rise in injuries, British command considered going back to the drawing board with the helmet’s design. Fortunately, a statistician p…

old tech blog about improving youtube page weight -- it paradoxically worsened their long tail stats

once they sliced it geographically, they found that the increase was all in places like siberia where previously the site was unusable

https://blog.chriszacharias.com/page-weight-matters

Re: Test your product on a crappy laptop

#267

Even 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 can't find a source, but I heard that Google used to purposely slow down their corporate network on some days to force all teams to dogfood test their software on slow networks. Or maybe they just offered an alternate slow Wi-Fi network to make testing easier, not forcing everyone to use a slow network.

But forcing managers to use a slow network would be an effective way to get them to prioritize performance. If using a slow network is a choice, they wouldn't.

Re: Test your product on a crappy laptop

#268
post #143
post #73

Earlier quoted context omitted.

Explain Gmail.

I don't understand this comment. Google clearly cares about the performance of that product, since it's the fastest webmail I've used by a long shot. Or maybe you care more about performance than almost everyone, and use Mutt or something else which can be configured to be faster with a few days' worth of effort.

It used to be fast. Now it's so slow it has a loading screen.

Re: Test your product on a crappy laptop

#269

Earlier quoted context omitted.

Absolutely trivial to demonstrate to be false. I can use websites to videoconferencing. Streaming considered video and audio comes with non trivial loads. I can use websites to compress images, to compute tabulated data on various Excel clones, remotely control devices or play games. This isn't 1995 and we're way past indulging user lazy choices which have us a decade of internet explorer nightmares. Web is much more…

> I can use websites to videoconferencing. > I can use websites to compress images, to compute tabulated data on various Excel clones, remotely control devices or play games. You sure can, but you probably shouldn't. These use cases are much better served by native apps. Shoehorning hypertext documents with macros into being applications will never come close to writing proper applications, in terms of both UX and pe…

What you talking about? App delivery trough browser is what enabled the low cost zero friction startup world you see today, and we're all better for it.

Re: Test your product on a crappy laptop

#270
post #265

Earlier quoted context omitted.

Idk how CS or Assembly plays into this. I’m a webdev. Self taught. Your points about metrics and nuance are accurate but I fail to see how those are related to CS as a whole. If stuff is legitimately slow, we should make it faster. Doesn’t need to be more complicated than that imo.

I don't think assembly has any relevance, and the thing with CS that's relevant is almost entirely with complexity theory. This sounds fancy, but it basically boils down to recognizing O(n^2) vs O(n) vs O(n log n), which in practice can be reduced to "use the right datastructure" and "use the right query".

Frankly, I think far more performance problems nowadays lie in things like insane SVG/CSS animations for every possible loading spinner than in developers not knowing their O notations.
Post reply on HN