Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering for Slow Internet

brr.fyi

Post reply on HN
Print view View original

261–270 of 406 posts

Re: Engineering for Slow Internet

#261

Post by mike_hearn »

Sesse__ wrote: post #237
mike_hearn wrote: post #162

Earlier quoted context omitted.

Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most…

> CSS is a very inefficient way to represent styling logic which is why web devs write dialects like sass that are more compact, but browsers don't adopt it. I don't know exactly which features you are referring to, but you may have noticed that CSS has adopted native nesting, very similarly to Sass, but few sites actually use it. Functions and mixins are similar compactness/convenience topics being worked on by the…

I hadn't noticed and I guess this is part of the problem. Sorry this post turned into a bit of a rant but I wrote it now.

When it was decided that HTML shouldn't be versioned anymore it became impossible for anyone who isn't a full time and very conscientious web dev to keep up. Versions are a signal, they say "pay attention please, here is a nice blog post telling you the most important things you need to know". If once a year there was a new version of HTML I could take the time to spend thirty minutes reading what's new and feel like I'm at least aware of what I should learn next. But I'm not a full time web dev, the web platform changes constantly, sometimes changes appear and then get rolled back, and everyone has long since plastered over the core with transpilers and other layers anyway. Additionally there doesn't seem to be any concept of deprecating stuff, so it all just piles up like a mound of high school homework that never shrinks.

It's one of the reasons I've come to really dislike CSS and HTML in general (no offense to your work, it's not the browser implementations that are painful). Every time I try to work out how to get a particular effect it turns out that there's now five different alternatives, and because HTML isn't versioned and web pages / search results aren't strongly dated, it can be tough to even figure out what the modern way to do it is at all. Dev tools just make you even more confused because you start typing what you think you remember and now discover there are a dozen properties with very similar names, none of which seem to have any effect. Mistakes don't yield errors, it just silently does either nothing or the wrong thing. Everything turns into trial-and-error, plus fixing mobile always seems to break desktop or vice-versa for reasons that are hard to understand.

Oh and then there's magic like Tailwind. Gah.

I've been writing HTML since before CSS existed, but feel like CSS has become basically non-discoverable by this point. It's understandable why neither Jetpack Compose nor SwiftUI decided to adopt it, even whilst being heavily inspired by React. The CSS dialect in JavaFX I find much easier to understand than web CSS, partly because it's smaller and partly because it doesn't try to handle layout. The way it interacts with components is also more logical.

Re: Engineering for Slow Internet

#262

Post by walterbell »

meindnoch wrote: post #183
walterbell wrote: post #57

IETF draft proposal to extend HTTP for efficient state synchronization, which could improve UX on slow networks, https://news.ycombinator.com/item?id=40480016 The Braid Protocol allows multiple synchronization algorithms to interoperate over a common network protocol, which any synchronizer's network messages can be translated into.. The current Braid specification extends HTTP with two dimensions of synchronization:…

Yes, please! Even more layers of needlessly complex crap will definitely improve things!

> needlessly complex

The optional Braid extension can _reduce_ complexity for offline-first apps, e.g. relative to WebDAV, https://news.ycombinator.com/item?id=40482610

  You might be surprised at just how elegantly HTTP extends into a full-featured synchronization protocol. A key to this elegance is the Merge-Type: this is the abstraction that allows a single synchronization algorithm to merge across multiple data types.

  As an application programmer, you will specify both the data types of your variables (e.g. int, string, bool) and also the merge-types (e.g. "this merges as a bank account balance, or a LWW unique ID, or a collaborative text field"). This is all the application programmer needs to specify. The rest of the synchronization algorithm gets automated by middleware libraries that the programmer can just use and rely upon, like his compiler, and web browser.

  I'd encourage you to check out the Braid spec, and notice how much we can do with how little. This is because HTTP already has almost everything we need. Compare this with the WebDAV spec, for instance, which tries to define versioning on top of HTTP, and you'll see how monstrous the result becomes. Example here:
https://news.ycombinator.com/item?id=40481003

Re: Engineering for Slow Internet

#263

Post by mayormcmatt »

This topic resonates with me, because I'm currently building a horrible marketing static page with images and videos that top 150MB, prior to optimization. It causes me psychic pain to think about pushing that over the wire to people that might have data caps. Not my call, though...

Re: Engineering for Slow Internet

#264

Post by klabb3 »

pnt12 wrote: post #185
klabb3 wrote: post #166

Earlier quoted context omitted.

Grump take: More complex technology will not fix a business-social problem. In fact, you have to go out of your way to make things this shitty. It’s not hard to build things with few round trips and less bloat, it’s much easier. The bloat is there for completely different reasons. Sometimes the bloat is unnoticeable on juicy machines and fast internet close to the DC. You can simulate that easily, but it requires the…

> Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win. As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.

> But if this gets improved at the transport layer, seems like a win.

What do you mean? TCP and HTTP is already designed for slow links with packet loss, it’s old reliable tech from before modern connectivity. You just have to not pull in thousands of modules in the npm dep tree and add 50 microservice bloatware, ads and client side “telemetry”. You set your cache-control headers and etags, and for large downloads you’ll want range requests. Perhaps some lightweight client side retry logic in case of PWAs. In extreme cases like Antarctica maybe you’d tune some tcp kernel params on the client to reduce RTTs under packet loss. There is nothing major missing from the standard decades old toolbox.

Of course it’s not optimal, the web isn’t perfect for offline hybrid apps. But for standard things like reading the news, sending email, chatting, you’ll be fine.

Re: Engineering for Slow Internet

#265

Post by djtango »

don-code wrote: post #202
djtango wrote: post #64

Earlier quoted context omitted.

Yes - name and shame. Slack is INFURIATING on intermittent connectivity. That is simply not good enough for a product who's primary value is communication. Anyone who has tried to use Slack: - in the countryside with patchy connection - abroad - in China - on the London Underground Can attest to how poor and buggy Slack is on bad internet. These aren't weird edgecases - London is a major tech hub. Remote workers and…

Slack additionally decides to hard-reload itself, seemingly without reason. I work on the road (from a train / parking lot / etc) for five or six hours per week. My T-Mobile plan is grandfathered in, so I can't "upgrade" to a plan that allows full-speed tethering without considerably impacting my monthly bill. Realistically, I hit around 1.5Mbps down. When Slack reloads itself, I have to stop _everything else_ that I…

I feel your pain - one minute you're reading some messages or a note and the next you're locked out of slack with faded screens and infinite spinnies.

Apparently we must be very niche amongst their user base because these kinds of fixes hasn't made it onto their roadmap in years

Re: Engineering for Slow Internet

#268

Post by finack »

mattgreenrocks wrote: post #252
finack wrote: post #63

Earlier quoted context omitted.

[flagged]

The beautiful thing about engineering is that the skill differential is apparent all the way from conception to implementation. But our industry is allergic to actually calling out actual skill issues that impact end users.

[flagged]

Re: Engineering for Slow Internet

#269

Post by beeandapenguin »

This is why we need more incremental rendering[1] (or "streaming"). This pattern become somewhat of a lost art in the era of SPAs — it's been possible since HTTP/1.1 via chunked transfer encoding, allowing servers to start sending a response without knowing the total length.

With this technique, the server can break down a page load into smaller chunks of UI, and progressively stream smaller parts of the UI to the client as they become available. No more waiting for the entire page to load in, especially in poor network conditions as the author experienced from Anartica.

[1]: https://www.patterns.dev/react/streaming-ssr

Re: Engineering for Slow Internet

#270

Post by analyte123 »

rpastuszak wrote: post #171
padolsey wrote: post #43

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.

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.
Post reply on HN