> Then there’s users begging Google to allow them to use more than 50kb of CSS. Yes, most site’s CSS is bloated. But 50kb is an absurdly small, arbitrary limit.
I think for static articles 50kb should be plenty. The linked page itself uses only 35kb and a third of that is fontawesome. And 32kb of that is actually unused without javascript enabled. So the site only uses 3kb, but 50kb is absurdly small?
A given page may only need a dozen kilobytes of CSS, but the combined amount that covers any possible page might be higher. For example a news article might have a video player, audio player, image carousel, map, data tables, scroll away images, etc.
Normally a page could insert a link for a global CSS document, or have a document corresponding to each feature (video.css, audio.css). AMP doesn't allow this, you have to inline the styles into a single style block in the head of the document.
The only way to do this if you have a site with a long tail of features is to track which elements are rendered and then before flushing the page calculate which styles should be inlined.
AMP's approach is workable, but is at odds with how most sites and frameworks use CSS, and means the web framework and static resource build pipeline have to be redesigned around AMP constraints. And in the worse case, you'll discover than some content combinations happen to trip the 50k limit anyway, and silently fail.
> A given page may only need a dozen kilobytes of CSS
I think you would be challenged to find a single page that needed that much; please give an example if you have one. Most single page articles I have tested use less than 5kb. codepen.com uses like 6 kb on load of a new pen. gmail.com completely loads with 5kb and doesn't load more.
> For example a news article might have a video player, audio player, image carousel, map, data tables, scroll away images, etc.
This is definitely a concern, but 50kb is high enough that you should be able to fit custom css for everything you mentioned. I think 10x what most single pages use is pretty reasonable, and certainly not "an absurdly small, arbitrary limit".
A significant portion of time is spent calculating styles from css so keeping it small is a real bonus to load times.
> AMP's approach is workable, but is at odds with how most sites and frameworks use CSS, and means the web framework and static resource build pipeline have to be redesigned around AMP constraints.
Pretty much every site I have looked at since my first comment besides Github loads less than 50kb (much of which is unused) anyway. If you are really hitting the 50kb limit, you probably need to redesign anyway for desktop so AMP should come mostly for free.
If limiting CSS to 50k per page would prevent news articles from including "a video player, audio player, image carousel, map, data tables, scroll away images, etc." then I wish browser makers would include it as an option so I could apply it as a filter everywhere. I don't want all that stuff to begin with.
The problem is designers and their bosses/clients. They equate design with looks. As a result, they see design as solving the problem of aesthetic. They fail to realize this is a problem which very few people care about on the web. So long as it passes the smell test of credibility, no one cares. (Excluding a handful of cases.)
That‘s true only for (some) tech-literate people. Everyday users will quickly think something looks ugly/old/cluttered when compared to the other apps/sites they use.
I‘m an outlier on this site because I generally like redesigns and all that comes with modern web stuff (white space, rounded corners, flat, light drop shadow, generally clean and option for dark mode).
I find it‘s easy to test. Take a redesign you didn‘t think was necessary and then look at it 3 years later. Design changes over time. It‘s just life.
HN for some reason did age decently because it‘s very spartan and minimal. I like it. Even mobile is fine for reading. Not so much for contributing though.
Edit: Actually, everyday users might not care much either way. UNTIL some other site with similar functionality comes along but looks much more modern. Or if the site is trying to get new users.
"I like" is precisely the mistake I am addressing.
Design is not about what one likes. It is about what helps one solve a problem.
Web designers and their bosses/clients reduce "design" to the creation of the look-and-feel of websites. For them, design is all about how something looks. This is something which is highly subjective.
The flaw in this is that it's not how users think. Users have a job-to-be-done. A good design is one that helps them accomplish that job. A better design is one that helps them accomplish that job better, faster, or easier. A bad design is one which doesn't help them or makes it worse.
Consider a monolingual English speaker using an ATM in China. You will never hear them say, "Well, I can't get my money because I don't understand Chinese. However, this ATM looks so nice I'm going to try to use it again."
It doesn't matter how great that ATM looks if the user cannot accomplish their task.
Yes, aesthetics have a place, but it's a very diminished place of importance. Aesthetics is much less important than most web designers and bosses/clients think.
It's time they get over themselves and start thinking about users.
Early to mid 2000s was the best time in web design. Everything before that was "omg, i can put animated images and color on the web, LETS PUT ALL OF THEM IN THERE!" (aka the Geocities School of Style) and after after that was "OMG iPhone is kewl, lets make everything 20x sized so that people can rub their screens with ease (desktop? what desktop? that is sooo yesterday, and dying, get with the times grampah, today real programmers make web applications in their iPads while drinking latte soda cappuccinos and eating gluten free croissants at plate free coffee shops with hand demoisturized tables)".
I mean, early/mid 2000s design was still bad (especially when people learned about the gradient tool and drop shadow filter), but at least browsers were limited enough to mostly contain the damage.
I tend to agree, there is no reason to change the hn look and feel. If it were a corporate product it would have had a dozen product managers trying to make a name for themselves in redesigning it ad nauseum, just for the sake of change and advancing their own careers. Also see: Wikipedia (more or less), Craigslist, DuckDuckGo (I’ll defend that one), and scant few others. News sites like newspapers and large blogs are particularly egregious imo (but I think much of that is driven by demands for revenue by selling more ads and tracking).
It doesn't have any specialist mobile UX, but it also doesn't have any need for specialized mobile UX. It has pretty nearly the best mobile discussion UX I've seen simply by not trying too hard.
HN works really well on mobile. The only issue is that the voting arrows are a bit small but otherwise it is one of the mobile sites I use with the best UX experience.
The only other way to handle <pre> tags is to wrap these long lines, but i do not see how that is not fundamentally broken considering that the entire purpose of the <pre> tag is to show preformatted text.
I disagree. I browse hn almost exclusively on mobile and I think it is fantastic. Compared to other sites, many of which won’t even load when my connection is shoddy, jump around as they’re loaded, require me to turn off my ad blocker just to render properly, etc., and I’ll take hn’s mobile UX any day. Two examples of terrible “modern” mobile UX are (new) reddit and LinkedIn.
Yea but I'm not asking for a react rewrite I'm asking for fonts and UI elements to not by microscopic or disappear on me when I misclick on the wrong microscopic thing.
I think for static articles 50kb should be plenty. The linked page itself uses only 35kb and a third of that is fontawesome. And 32kb of that is actually unused without javascript enabled. So the site only uses 3kb, but 50kb is absurdly small?
This site (Hacker News) gets by with 2 kb.