371–380 of 530 posts
Earlier quoted context omitted.
This is why my most recent website does its server-side rendering on the client. I'm not even being that sarcastic. We stream a subset of the user's data (1 mb at most) in the background and have a WASM client that has the exact same server views. On SPA events, the WASM blob intercepts a lot of requests and can instantly render. Makes a laggy connection feel pretty quick.
>SSR but in the browser We've come full circle.
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
The UI threading model is usually not the problem. The problem usually comes from inappropriately arranging the systems of record such that information needs to be communicated beyond the scope of one computer in order to satisfy a single logical request. Moving information between physical processors tends to be significantly more expensive than local computation over that same information. JSON serialization is a r…
> Information theory doesn't care how clever your loading indicator is. If the information isn't available, we can't do anything meaningful.
Yes we can - we can fix why the information isn't available. If someone said to you "sorry, we don't have the info because the other thread is doing Sleep(5000);" you'd call them an idiot right? You'd go and delete the sleep call to make it faster. Most real problems are harder than that, but there's no fundamental rule saying your database has to be slow. Ping time across your LAN is probably under a millisecond, so where are the other 299 milliseconds going? Is your database doing a full table scan? Is it using spinning rust for frequently accessed data?
Earlier quoted context omitted.
It's not very hard to engineer software with these two constraints at the same time: * Must feel very responsive * Network requests can take up to 500ms end to end
It isn’t, but at the same time, smart hackers were working with highly constrained PC hardware in the 1980s and early 1990s and were cranking surprisingly good performance out of it. Folklore.org has plenty of stories about it, and John Carmack’s early career history is very impressive. We mustn’t forget the demo scene hackers either.
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
Shotout to PowerSync for enabling companies to go in the opposite direction and build offline-first apps. My company is a (production) customer, and we recommend it.
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. Don’t know about that, pretty much everything is hosted on Cloudflare, Azure or S3 these days and all of them have at least one CDN on each continent.
Earlier quoted context omitted.
Canva replaced PowerPoint. Canva is cloud based and PowerPoint is not. There's so many apps that are cloud only so that corporate it no longer has to manage installations and users don't need to ask IT for permission anymore. I think SaaS doesn't really work without the cloud, you could technically do what adobe does but why bother with app distribution and windows' quirks. Cloud based web apps are write once, run an…
I like this example. A lot of people would prefer to use PowerPoint because they can still use their files and templates they made last year even if Microsoft doubles the price of Powerpoint, removes features, discontinues the product, or goes bankrupt.
Earlier quoted context omitted.
I like this example. A lot of people would prefer to use PowerPoint because they can still use their files and templates they made last year even if Microsoft doubles the price of Powerpoint, removes features, discontinues the product, or goes bankrupt.
Difficulty - Microsoft retroactively cancelling lifetime licenses.
Earlier quoted context omitted.
> Users are usually fine seeing many changes on the screen quickly because it gives the impression that stuff is happening on the background This gave me a chuckle because I personally hate things like watching the browser jump through 50+ redirects when logging into a website.
My bad, I mean the interstitial. Like it should stay for at least a second to not make it jarring. People believe computers need to think so you can't make things too fast either. Not the interstitial and not the app either, to the point you sometimes have to deliberately slow down the app, add latency to make people trust it because it "gives the computer time to think"
Earlier quoted context omitted.
I think a lot of the time when people say the network is slow. They really mean their backend is slow. With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU). With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger. No…
> With a fast backend ~1-5ms response times (not even that fast). Even though benchmarks suggest this sort of performance should be trivial, most real-world servers I have interacted with do not reliably managed to process a request, make a roundtrip to the DB, and return a response in <5ms
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
We don't turn faster hardware into faster programs, we turn it into more program. AI isn't going to change that. We'll just get even more program because the optimisation has freed up space for that.
Unfortunately most of the time, the more program isn't for our benefit. I note that by far the heaviest program I use is my web browser. The one thing I don't get to choose what code gets thrust upon me.