Item — HN Reader

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 connection, it's not stable, and it's so painful to sink precious packets into pointless web-app-react-crap roundtrips.

I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly. In deficit of time travel, if people could just learn to open web tools and use its throttling tool: turn it to 3g, and see if their webapp is resilient. Please!

16 comments

"I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly."

No need to invent time travel, just let them have a working retreat somewhere with only bad mobile connection for a few days.

Amen to this. And give them a mobile cell plan with 1GB of data per month.

I've seen some web sites with 250MB payloads on the home page due to ads and pre-loading videos.

I work with parolees who get free government cell phones and then burn through the 3GB/mo of data within three days. Then they can't apply for jobs, get bus times, rent a bike, top up their subway card, get directions.

"But all the cheap front-end talent is in thick client frameworks, telemetry indicates most revenue conversions are from users on 5G, our MVP works for 80% of our target user base, and all we need to do is make back our VC's investment plus enough to cash out on our IPO exit strategy, plus other reasons not to care" — self-identified serial entrepreneur, probably

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.

Yeah and then give them thousands upon thousands of paying customers with these constraints worth caring about

This is probably a deliberate decision on the part of the government. A lot of the justice system is designed to keep people in prison.

Just put them on a train during work hours! We have really good coverage here but there's congestion and frequent random dropouts, and a lot of apps just don't plan for that at all.

There's no need for retreat. Chrome DevTools have "simulate slow connection" button.

Yeah - and do they use it? Does it help experiencing them the joy of wanting just a little text information, but having to load loads of other stuff first and your connection timing out? I am afraid to get the full experience, they actually need to have a bad connection.

My first education was in industrial design, there designers usually have pride in avoiding needless complexity and material waste.

Even if I do web services I try to do so with as little moving parts as needed and with huge reliance on trusted and standardized solutions. If see any addition of complexity as a cost that needs to be weighed against the benefits you hope it brings you will automatically end up with a lean and fast application.

A little time with embedded hardware will teach you a few things too.

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.

>> Another often missed opportunity is building SPAs as offline-first.

You are going to get so many blank stares at many shops building web apps when suggesting things like this. This kind of consideration doesn't even enter into the minds of many developers in 2024. Few of the available resources in 2024 address it that well for developers coming up in the industry.

Back in the early-2000s, I recall these kinds of things being an active discussion point even with work placement students. Now that focus seems to have shifted to developer experience with less consideration on the user. Should developer experience ever weigh higher than user experience?

>Should developer experience ever weigh higher than user experience?

Developer experience is user experience. However, in a normative sense, I operate such that Developer suffering is preferable to user suffering to get any arbitrary task done.

The irony for me is that I got into React because I thought that we could finally move to an offline-first SPA application. Current trends seem to go the opposite.

SPAs and "engineering for slow internet" usually don't belong together. The giant bundles usually guarantee slow first paint, and the incremental rendering/loading usually guarantees a lot of network chatter that randomly breaks the page when one of the requests times out. Most web applications are fundamentally online. For these, consider what inspires more confidence when you're in a train on a hotspot: an old school HTML forms page (like HN), or a page with a lot of React grey placeholders and loading spinners scattered throughout? I guess my point is that while you can take a lot of careful time and work to make an SPA work offline-first, as a pattern it tends to encourage the bloat and flakiness that makes things bad on slow internet.

London internet (and English internet in general) is just so bad.

Having lived in lots of countries (mainly developing) it’s embarrassing how bad our internet is in comparison

Oh, London is notorious for having... questionable internet speeds in certain areas. It's good if you live in a new build flat/work in a recently constructed office building or you own your own home in a place OpenReach have gotten to yet, but if you live in an apartment building/work in an office building more than 5 or so years old?

Yeah, there's a decent chance you'll be stuck with crappy internet as a result. I still remember quite a few of my employers getting frustrated that fibre internet wasn't available for the building they were renting office space in, despite them running a tech company that really needed a good internet connection.

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 do, and there is almost no online resources that you can base your projects on if you’re a Google/GPT programmer. Part of this is because of the ocean of terrible JS resources online, but a big part of it is also that the organisations which work like this aren’t sharing. We have 0 public resources for the way we work as an example, because why would we hand that info to our competition?

HTTP/2 push is super dead: https://evertpot.com/http-2-push-is-dead/

Very sad. I use http/2 push on my website to push the CSS if there’s no same-origin referrer. It saves a full roundtrip which can be pretty significant on high latency connections. The html+css is less than 14kb so it can all be sent on the first roundtrip as it’s generally within TCP’s initial congestion window of about 10*1400.

The only other alternative is to send the CSS inline, but that doesn’t work as well for caching for future page loads.

103 Early Hints is not nearly as useful as it doesn’t actually save a round trip. It only works around long request processing time on the server. Also, most web frameworks will have a very hard time supporting early hints, because it doesn’t fit in the normal request->response cycle, so I doubt it’s going get much adoption.

Also it would be nice to be able to somehow push 30x redirects to avoid more round trips.

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.

It's not always the application itself per se. It's the various / numerour marketing, analytics or (sometimes) ad-serving scripts. These third party vendors aren't often performance minded. They could be. They should be.

I live in a well connected city, but my work only pays for other continent based Virtual Machines so most of my projects end up "fast" but latency bound, it's been an interesting exercise of minimizing pointless roundtrips in a technology that expects you to use them for everyting

Tried multiple VPNs in China and finally rolled my own obfuscation layer for Wireshark. A quick search revealed there are multiple similar projects on GitHub, but I guess the problem is once they get some visibility, they don't work that well anymore. I'm still getting between 1 and 10mbit/s (mostly depending on time of day) and pretty much no connectivity issues.

Wireguard?

Tbh, developers just need to test their site with existing tools or just try leaving the office. My cellular data reception in Germany in a major city sucks in a lot of spots. I experience sites not loading or breaking every single day.

developers shouldn't be given those ultra performant machines. They can have a performant build server :D

>A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet.

Not even that, with outer space travel, we all need to build for very slow internet and long latency. Devs do need to time-travel back to 2005.

I'm sure this is not what you meant but made me lol anyways: sv techbros would sooner plan for "outer space internet" than give a shit about the billions of people with bad internet and/or a phone older than 5 years.

Sounds like what would benefit you is a HTMX approach to the web.

What about plain HTML & CSS for all the websites where this approach is sufficient? Then apply HTMX or any other approach for the few websites that are and need to be dynamic.

It sounds like GP would benefit from satellite internet bypassing the firewall, but I don't know how hard the Chinese government works to crack down on that loophole.

I hear you on frontend-only react. But hopefully the newer React Server Components are helping? They just send HTML over the wire (right?)

The problem isn't in what is being sent over the wire - it's in the request lifecycle.

When it comes to static HTML, the browser will just slowly grind along, showing the user what it is doing. It'll incrementally render the response as it comes in. Can't download CSS or images? No big deal, you can still read text. Timeouts? Not a thing.

Even if your Javascript framework is rendering HTML chunks on the server, it's still essentially hijacking the entire request. You'll have some button in your app, which fires off a request when clicked. But it's now up to the individual developer to properly implement things like progress bars/spinners, timouts, retries, and all the rest the browser normally handles for you.

They never get this right. Often you're stuck with an app which will give absolutely zero feedback on user action, only updating the UI when the response has been received. Request failed? Sorry, gotta F5 that app because you're now stuck in an invalid state!

Yes, server-rendering definitely helps, though I have suspicions about its compiled outputs still being very heavy. There's also a lot of CSS frameworks that have an inline-first paradigm meaning there's no saving for the browser in downloading a single stylesheet. But I'm not sure about that.

Yes, though server side rendering is everything but a new thing in the react world. NextJS, Remix, Astro and many other frameworks and approaches exist (and have done so for at least five years) to make sure pages are small and efficient to load.

The amount of complexity to generate HTML/JS is a little staggering sometimes for the majority of simple use cases.

Using Facebook level architectures for actually pretty basic needs can be like hitting an ant-sized problem with a sledgehammer and wondering why the sledgehammer is so heavy and awkward to swing for little things.

Devs only build for the requirements they are given.

You want performance? Then include it in the requirements and give it the necessary time budget in a project.

Eh, I'm a few miles from NYC and have the misfortune of being a comcast/xfinity customer and my packetloss to my webserver is sometimes so bad it takes a full minute to load pages.

I take that time to clean a little, make a coffee, you know sometimes you gotta take a break and breathe. Life has gotten too fast and too busy and we all need a few reminders to slow down and enjoy the view. Thanks xfinity!

> It all ends up meaning that, even if I get a connection, it's not stable

I feel you, but the experience can actually be very good if you invest a bit of time looking at Shadowsocks/V2Ray and building your own infra.

Chrome dev tools offer a "slow 3G" and a "fast 3G". Slow 3G?

With fresh cache on "slow 3G", my site _works_, but has 5-8 second page loads. Would you have consider that usable/sufficient, or pretty awful?

It depends if you are ok with 1/3 to 2/3rds of your visitors bouncing due to loading times and losing 3 to 5x of convertion rate depending on sources...

Is tor not viable?

Or maybe, just get rid of the firewall. I am all for nimble tech, but enabling the Chinese government is not very high on my to-do list.

Please understand that Chinese government wants to block "outside" web services to Chinese residents, and Chinese residents want to access those services. So if the service itself decides to deny access from China, it's actually helping the Chinese government.

Whether you like it or not, over 15% of the world's population lives in China.