Hacker News Reader

Comment by StillBored | Hacker News Reader

Please, since someone from wikipedia is probably reading this: Keep the JavaScript to a minimum. The plans aren't clear to me, but given what sites like reddit/etc have done during their "updates" the new UI's are terrible on anything that isn't a top of the line device with a screaming fast internet connection. Wikipedia (and a few other "older" sites) is such a pleasure to use as is, don't ruin it.

AKA round-tripping 1000 times sucks on high latency connections, and my little atom based tablets/a53 based phones/etc choke on those sites and its absolutely miserable trying to use them.

So, put some effort into measuring the before/after and making sure that the download/render times remain in the same ballpark on older devices/connections.

View on HN

PSA: old.reddit.com is so much better in these regards. I use it on my phone too, with some custom css to make things bigger.

There is also i.reddit.com.

I only use old.reddit.com on phone and pc as it is much faster and much more intuitive , reddit has gone to hell in my opinion

I'm already resigned to the fact that once old.reddit.com goes away I'm not going to be spending any more time on Reddit. Maybe that'll be a good thing.

"reddit is fun" on Android is a great app for it. Staying away from reddit more is good for you, too.

"infinity" is also a great alternative for android.

Infinity looks great.

Relay was my favorite while I was on Android. On iOS now, Narwhal is my go-to.

old.reddit exclusively on the web, via 'Old Reddit Redirect' extension on Firefox.

I continue to be surprised that this still works, and wonder how long that'll last. It's pretty clear by this point that they're willing to try every dark UI pattern that they can think of to boost some silly engagement metrics. Community and long-term growth be damned.

I'm writing a custom skin (CSS) to turn New Reddit into Old Reddit for when they inevitably, sadly, turn off old.reddit.com

Is all of the data even available? Posts don't show the author name on the front page and many comments are hidden under links on the new UX from the comment page.

the base reddit api is pretty good - just tack a .json onto any url for an example

Have any work in progress examples?

i.reddit.com still works great to browse text-based posts on my Kindle e-reader, of all devices.

New reddit feels like they hired 6 junior React developers and put a gun to their head telling them to rewrite the website in React in 6 months or else.

It's unbelievably slow.

Funny yet accurate! I wonder what's causing them from sunsetting old.reddit...usage? An individual?

I will never use new.reddit, I tried to once but it's such a poorer UX

Making UXs for desktop that share design elements with touchscreens will always be a mess.

It's my biggest fear for the future of macOS development given the recent announcement of Big Sur and ARM.

I don’t think they are in a sense, as far as I know they have no plans of removing it.

That being said, using it once and then saying never again is kind of, not good. I’ve been on Reddit for almost a decade and while using the new design for the first time or even the first week was, painful I’ve fully embraced it now and can’t stand the old one.

I don’t find it painfully slow at all. In fact I find it faster overall when taking New features into account.

And the only way I can use Facebook - mbasic.facebook.com

The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like that will sometimes jump around and resize for no apparent reason.

Making wikipedia noticeably js-heavy would definitely ruin the experience.

The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters.

The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially.

If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached.

If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.

On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck.

Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds.

Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.

This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem.

I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript.

In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.

In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy.

While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.

True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded.

So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it?

My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX.

That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.

I agree fully with you! My point was not that the bundle size matters the most, but rather than everything matters. What matters most depends on your user-base of course. Expensive, professional tools that only works on Mac: fine with high requirements and bandwidth requirements. Free service whos goal is to spread knowledge everywhere in the world: need to think about cheapest devices on the worst networks.

1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.

It's not even an issue with adding JS, they could build it entirely in React and not have it crawl along like new Reddit does. The issue is 'redesigns' which real purpose is to add extra layers of user engagement, ads and tracking.

Indeed.

Most of the times, these dynamic things on web pages and elsewhere mispredict what I actually want.

No Google, I did not want to zoom in on the map that you automatically did for me. Rather I unzoomed back and you automatically zoomed back in.

No scroll bars, I don't want you to disappear or even thin down automatically.

I personally don't like infinite scrolling as a solution either as it messes up scroll bar operation.

And I want strictly none of the above if when clicking 'back', you don't take me to the exact same view I was on before, without the elements of page jumping for a few seconds.

No my laptop and phone, I do not want you to wake up when I disconnect power, and especially so when I had just put you to sleep!

Glad that Wikipedia is planning to show and hide the side panel on user instruction/click. Please keep it that way.

For sure; wikipedia is one of those sites that don't need any JS for their base functionality, and it will benefit greatly from it. They need to keep accessibility in the forefront for this redesign, and honestly, accessibility is easy if you just stick to the basics.

They can embellish things with JS, but that has to be optional. Things like the article summary popup when you hover over a link. That can be deferred and left out completely.

They have the opportunity to do great things with design and typography for clarity, I hope they take it.

And for the love of god, don't add anything that will require a cookie pop up.

Reply on news.ycombinator.com