3 ms·
While it might feel great to shit on the state of client-side JS error handling, doing so is pretty silly. Most well-written sites give some sort of indication
by wonnage 15y ago
While it might feel great to shit on the state of client-side JS error handling, doing so is pretty silly. Most well-written sites give some sort of indication when your connection flakes out. Gmail is a good example. This isn't something you can just slap a global spinner together and fix.
- JoshTriplett 15y agoTrue, but every site has to actually think of that case and reimplement the logic themselves, and they'll almost certainly do a worse job of it than the browser.
- ebiester 15y agoOh, the "leave it to the browser" crowd made their share of mistakes. Does anyone remember LiveJournal? Go to the next 20 posts, then back just to make sure you didn't have one or two lost? If I had a nickel for every poorly-implemented paging technique I've seen, I'd have enough to pay someone to write an open source infinite scroll library. Oh, and how many people remember writing responses in a text editor and copying it over to the browser window, so that the back button didn't eat your entire post on a forum when something went wonky with the connection? I don't remember Twitter or Facebook ever losing a submission. Maybe I don't use them enough, but asynchronous submit is a great step forward, and I prefer infinite scroll to many of the paging implementations I have lived with over the years.
- tommorris 15y agoIt's not so much about which is better: it's about the fact that we need consistency. At least with "leave it to the browser", there is some consistency and users can learn to live with that consistency (e.g. by writing longer posts in a text editor and copy-pasting). When everyone does it ever so slightly differently, you are lulled into a false sense of security. I don't mind software sucking, so long as it sucks in a generally consistent way.
- deleted 15y ago[deleted]