321–330 of 406 posts
Earlier quoted context omitted.
The London Underground not having any connectivity for decades after other metro systems showed only that high connectivity during a commute isn't necessary.
London fails to provide a lot of essentials.
Earlier quoted context omitted.
Having an adblocker (firefox mobile works with uBlock origin) and completely deactivate loading of images and videos can get you quite far with limited connection.
You're 100% right. uBlock Origin can reduce page weight by an astronomical amount.
Mosh and NNCP will help a lot, but you need some good sysadmin to set NNCP as the mail MUA/MTA backend to spool everything efficiently. NNCP it's an expert level skill, but your data will be sent over very unreliable channels: https://nncp.mirrors.quux.org/Use-cases.html Also, relying on propietary OS'es is not recommended. Apple and iOS are disasters to work on remote, isolated places. No wonder no one uses Apple in…
Well, statistically average end-user internet connection in Europe is much faster than in the US. Maybe outside some places like most of western Germany, but these are an exception. Europe has really good bandwidth speeds, overall. I absolutely agree with the rest, though, including the part saying any "serious" software will have such features (and better support in general), and I second the examples you gave.
Earlier quoted context omitted.
This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.
It often is that way, but it's not for technical reasons. They're just poorly written. A lot of apps are written by inexperienced teams under time pressure and that's what you're seeing. Such teams are unlikely to choose plain server-side rendering because it's not the trendy thing to do. But SPAs absolutely can be done well. For simple apps (HN is a good example) you won't get too much benefit, but for more highly i…
A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…
I lived in Shoreditch for 7 years and most of my flats had almost 3G internet speeds. The last one had windows that incidentally acted like a faraday cage. I always test my projects with throttled bandwidth, largely because (just like with a11y) following good practices results in better UX for all users, not just those with poor connectivity. Edit: Another often missed opportunity is building SPAs as offline-first.
Having lived in lots of countries (mainly developing) it’s embarrassing how bad our internet is in comparison
Earlier quoted context omitted.
Yeah, though it doesn’t quite capture all of the experience of working with slower broadband. For example if you have a website that is meant to be used alongside a video call or while watching video, it’s difficult to really simulate all of that “feel”. Using a link that is slow in practice is an invaluable experience.
You can install programs at software level to emulate it as a whole. I remember using one for OSX and it working pretty well.
Earlier quoted context omitted.
We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients like Tauri. You can also deploy very near people if you work “on the edge”. I’m not necessarily disagreeing with your overall point, but modern JS is actually rather good at dealing with slow internet for server-client “applications”. It’s not necessarily easy to…
By far the lightest weight JS framework isn't React, it's no javascript at all . I regularly talk to developers who aren't even aware that this is an option.
So no, "no JS at all" is not "by far the lightest weight" in many cases. This is just uncritically repeating dogma. Even 5K to 20K of JS can significantly increase performance.
Earlier quoted context omitted.
If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.
This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.
I agree a lot of full SPAs are poorly done, but some are do work well. FastMail is an example of a SPA done well.
The reason many SPAs are slower is just latency; traditional template-driven is:
- You send request
- Backend takes time to process that
- Sends all the data in one go.
- Browser renders it.
But full SPA is:
- You send request
- You get a stub template which loads JS.
- You load the JS.
- You parse the JS.
- You send some number of requests to get some JSON data, this can be anything from 1 to 10 depending on how it was written. Sometimes it's even serial (e.g. request 1 needs to complete, then uses some part of that to send request 2, and then that needs to finish).
- Your JS parses that and converts it to HTML.
- It injects that in your DOM.
- Browser renders it.
There are ways to make that faster, but many don't.
Earlier quoted context omitted.
If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.
Yeah, right. GitHub migrated from serving static sites to displaying everything dynamically and it’s basically unusable nowadays. Unbelievably long load times, frustratingly unresponsive, and that’s on my top spec m1 MacBook Pro connected to a router with fiber connection. Let’s not kid ourselves, no matter how many fancy features, splitting, optimizing, whatever you do, JS webapps may be an upgrade for developers, t…
I could put up with the glacial performance if it actually worked in the first place, but apparently adding whiz bang "AI" features is the only thing that matters these days.
The whole thing smacks of a rewrite so someone could get a bonus and/or promotion.