Live data from Hacker News

Tell HN: Thank you for not redesigning Hacker News

news.ycombinator.com

271–280 of 398 posts

Re: Tell HN: Thank you for not redesigning Hacker News

#271
post #268
post #81

Earlier quoted context omitted.

The tap targets are minuscule and close to each other.

The trick is to keep your karma below 500. xD

Thanks! As someone who lurks here much, much more than commenting, I wasn't aware that the interface would change over 500 karma.

This does put the discussion in a different light (not to mention helps avoids me making comments that don't apply to more karmarific users).

Re: Tell HN: Thank you for not redesigning Hacker News

#272

I love hearing stories about people choosing to forego large frontend frameworks, or even not using JS altogether. Is there a community or name for this? If not, I'm going to call it #neverscript. I find the web works far better, more often, for me when SPAs and JS aren't used. There's something about minimalistic sites that's very appealing to me. I know it doesn't work for all sites, but a lot of the web could be i…

When you're not using frameworks/libraries, it's typically referred to as vanilla js. Probably the name stuck thanks to this amazing satire of a js library. http://vanilla-js.com/. This was basically around the time browsers got good enough that jQuery was no longer needed. It essentially emphasized that all the showcase features of popular 'must-have' js libraries were now a standard part of modern browsers.

Re: Tell HN: Thank you for not redesigning Hacker News

#273
post #86

Earlier quoted context omitted.

People seem to be confusing web 2.0/bootstrap style design (see: Reddit's bad redesign) with the frameworks here but the component based approach combined with webpack/compilation steps, which are very much mainstreaming, are fundamentally different than top heavy JS frameworks I spent most of the last decade using. I dont think people have really seen what server-side rendering (ala Next.js/Nuxt.js), decoupled compo…

I think you and the parent commenter are coming at this from fundamentally different perspectives. The parent commenter remembers a time when websites were server-rendered by default. The server would send down HTML, along with a small amount of CSS and JavaScript to style it and add interactivity. You didn't need an elaborate chain of compilers and bundlers and frameworks and chunkers to make sure you didn't ship se…

This is more than just wrapping stuff in cards and making the font 2x, it's about the abilities of what websites can achieve. The design is a part of that but it's also influenced by what you can do differently than a pure HTML + a bit of jquery site.

I basically rebuild past era bootstrap style Rails HTML views with some jquery into modern Vue components for a living on a B2B app.

I'm very familiar with the old way and how much better a proper modern replace could be. I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed.

Page render times to first action are about 10x faster on average (no joke) and our users use 1000's of objects on a single HTML form. I'd love to see someone try rendering that pure SSR framework with partials in a performant way and usable way.

This type of interaction extends well outside of my business/B3B domain as well. I'm quite excited for the future of web development after a decade of fearing more JS everywhere (which I was contributing too).

Another great HN style site is Basketball Reference, I personally love these information dense designs but it's not very scalable with tons of information, elements, and what it could really achieve if it was a desktop application or fully flexibly UI wise.

https://www.basketball-reference.com/teams/TOR/2019.html

This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc. On the site currently it looks great on the surface but once you engage with any JS-y stuff or imagine what's possible if it was a desktop app, and the previous tools would be extremely limited in scope.

You can do this very powerful stuff now without clogging up performance and load times. That's a big deal. We've been dealing with slow clunky JS components forever now and it can be way better.

Re: Tell HN: Thank you for not redesigning Hacker News

#274
Thanks. This is nice. Useful.

Could be a bit more flexible on some regions of discussion, but take that as a quibble, and recognition to many personas here. (You are good people, I do not imply otherwise)

Those personas combine in what I find to be lucid, and high value.

And the full thanks go to those who recognize that and work to nurture it all along.

Re: Tell HN: Thank you for not redesigning Hacker News

#275
post #260

Earlier quoted context omitted.

So just to clarify, this behavior seems to be by design. In that case it does seem the original comment is objectively wrong if the code is readable and maintainable and accomplishes the desired behavior.

As parent comments mention, sending back the whole-page response when you vote on a comment is a great idea if you have JavaScript disabled or aren't logged in. But it'd be a quick performance win if it didn't do that when you were logged in with JavaScript enabled. The actual JavaScript part of this is actually already implemented -- that's why the page doesn't refresh when you upvote my comment -- so you'd just nee…

Exactly, and it even adds up quickly for a single user in common cases like voting on a bunch of comments while reading a thread.

If someone loads this thread right now, the initial page load is 61KB (gzipped). If they read down the thread and vote on 30 comments while they're doing it, they transfer an additional 480KB (16KB/vote [1]). There's no reason that they should be receiving 8x more data by voting on a relatively low number of comments (~10% of the thread) than they did when loading the entire page originally. It also has to re-generate the page an extra 30 times unnecessarily - a repeatedly voting user becomes like a heavy multiplier to your traffic.

[1]: Also, I just noticed that the responses back from voting actually aren't the full page, they're truncated. It seems like maybe the response size is capped at 16KB gzipped? That implies that there's already some kind of special handling for the voting responses.

Re: Tell HN: Thank you for not redesigning Hacker News

#276

Earlier quoted context omitted.

I still can't use the redesigned Reddit, I not even sure that I would, if I could. It's still way to slow to be something I'd use on a regular basis. If they kill of the old.reddit.com, I don't think I'd continue to visit Reddit. Imgur for instance isn't a site that I visit daily or even weekly any more. I really enjoyed the site, but after a redesign it just stopped being enjoyable. It's way to slow, to much Javascr…

Other than poor performance, the thing I'm most upset about is how each subreddit has lost its personality, and the fact they've closed the source. Being open is what made Reddit special, considering who founded it, it should never have gone closed source.

> Other than poor performance, the thing I'm most upset about is how each subreddit has lost its personality

What makes you say this?

Re: Tell HN: Thank you for not redesigning Hacker News

#277

Earlier quoted context omitted.

In lower internet speeds Facebook loads a lite version which is super fast (loads better than HN for me) and has most of the basic functionalities.

For anyone curious, http://mbasic.facebook.com/ is one of the least data-intensive way to access facebook.

it also lets you access your messages from a phone

Re: Tell HN: Thank you for not redesigning Hacker News

#278
post #273

Earlier quoted context omitted.

I think you and the parent commenter are coming at this from fundamentally different perspectives. The parent commenter remembers a time when websites were server-rendered by default. The server would send down HTML, along with a small amount of CSS and JavaScript to style it and add interactivity. You didn't need an elaborate chain of compilers and bundlers and frameworks and chunkers to make sure you didn't ship se…

This is more than just wrapping stuff in cards and making the font 2x, it's about the abilities of what websites can achieve. The design is a part of that but it's also influenced by what you can do differently than a pure HTML + a bit of jquery site. I basically rebuild past era bootstrap style Rails HTML views with some jquery into modern Vue components for a living on a B2B app. I'm very familiar with the old way…

> The design is a part of that but it's also influenced by what you can do differently than a pure HTML + a bit of jquery site.

> I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed.

> This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc.

I guarantee that it is possible to write any of these features in traditional HTML, CSS, and JavaScript without relying on today's frameworks or build infrastructure. I know this because even the most advanced build pipeline in the world must eventually compile down to traditional HTML, CSS, and JavaScript; that's all browsers run, no matter how many layers you add to try to abstract yourself away from it. I also know this because websites existed that had these features prior to React becoming popular.

> We've been dealing with slow clunky JS components forever now

That's the thing -- there was a time before slow, clunky JS components. (They used to be slow, clunky Flash components :P)

Re: Tell HN: Thank you for not redesigning Hacker News

#279
post #81

Earlier quoted context omitted.

The tap targets are minuscule and close to each other.

Related question: what is the easiest way to increase the tap zone of a HTML element using CSS? Aside: I have noticed Safari auto-inceases the touch zone for inputs and elements with ontouch/onclick events (I noticed because I had to fix an issue caused by this!)

For the thread collapsing functionality I think the long press/touch could mitigate the need for pinch zooming. Just hold your thumb on the comment long enough and bang, it's gone. For me this is the most commonly performed interaction with the site.
Post reply on HN