Hacker News Reader

Comment by notadoc | Hacker News Reader

Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages.

I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RAM, and consuming CPU as if it were a midrange video game.

View on HN

Whether JavaScript is a good fit for a news site and whether news sites should be single page apps are two separate questions. It's possible to build a server rendered React app without requiring any client JavaScript execution at all.

News sites are also more complex than you would assume. I went from building products at Facebook to a large news site. What shocked me was the surface area of the user facing products. There were so many little one-off pieces of functionality and randomly integrated services. Tools like React and Relay make it much easier to manage this complexity and promote code reuse.

> It's possible to build a server rendered React app

What's the advantage of server rendered React app over server rendered anything e.g. php jsp etc?

You can make use of the JavaScript ecosystem. React is a nice was to structure code. There are a tonne of modules available on npm, etc. If and when you do want to build client elements you can reuse parts of your code.

That said, I'm not aware of anyone doing this at scale. I know the BBC were considering it. My company will be using it to product AMP pages from our JS stack.

Being done at scale here: https://www.nfl.com/super-bowl Plans to release solution across ecosystem by August Based on open-source universal app here: https://github.com/nfl/react-wildcat

Documentation and infrastructure setup for this project aren't great at the moment, but will get a facelift shortly.

There is a lot of technology for technology sake to be found in American web sites.

My favorite counter example is sankei news site. http://www.sankei.com/

All their pages end in .html.

Do view source and vast majority if byte is used for actual text content, rather than javascript and markups.

Mobile friendly too, but you wouldn't know it because they disabled responsive view unless it's visited from an actual phone. No premature mobile view with hamburger kicking in when viewing it on desktop.

Comparison of View source between two sites is quite amusing.

view-source:http://www.sankei.com/smp/

view-source:https://mobile.nytimes.com/

> but you wouldn't know it because they disabled responsive view unless it's visited from an actual phone. No premature mobile view with hamburger kicking in when viewing it on desktop

Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.

I can assure you it's not a bug. Many Asian sites have fixed width on desktop. They do not make their sites with 4-5 different media query break points.

Personally I prefer this because information is always in the same place regardless of browser size. I don't have to worry about it moving around or hiding.

Fine--misfeature. Bug in the spec. Having to squint and scroll sideways and zoom is awful user-facing behavior.

GitHub is bugged, by your criteria.

Yup! GitHub's wrong too. We have media queries for a reason--because user agent sniffing and "mobile sites" leads to incorrect results. This is one.

> All their pages end in .html.

Do you not understand how URL rewriting works?

100k webpages were never a thing for the amount of content that we are able to serve these days. Consider http://www.dailymail.co.uk/ as an example. The HTML document alone is 795K. Website such as this would immensely benefit from progressive loading.

There's 90kb worth of actual text. 1:9 text content to HTML ratio.

For NY Times, it's about 1:10.

Sankei.com, it's about 1:4.

If anywhere is the place to find others who miss the days of small HTML pages with CSS, especially for reading, HN is that place. :)

Seems like it's all you ever see here lately. I really should avoid reading HN comments on new web technologies.

I wish there were some way to avoid being subject to resume driven development when I'm on the internet. Alas, it's not to be, because instead of taking a step back and asking "do we need this" we get webdevs asking "how can I force fit the latest shiny bauble into my professional CV." And we end up with react graphQL node AWS kubernetes docker rube goldberg machines pumping tens of millions of bytes of data and billions of bytes of markup and JavaScript through Kafka all to serve up news text.

Everybody's job looks easy when you don't have the full list of requirements and a deadline in front of you. What looks like resume-padding may in fact be the best way to fulfill a requirement you didn't know they had.

After reading my ceremonial 1000th testimony about how HN user prefers sites with less CSS I'm about done with it though. We get it! Engineers are proud of how little they care for white space and colors! Can we talk about something else in the top comments of any page about website design?

> how HN user prefers sites with less CSS

That's not what people here are saying, though. Indeed, even your parent comment said how he misses a small HTML pages with CSS. Most engineers would be totally fine with HTML and a modest payload of nice, modern CSS styling, a perhaps a small bit of non-required progressively enhancing JS.

Our problem is with huge JS frameworks used in sites that aren't actual web applications (e.g., Gmail), but rather web sites (like news sites). And I say this as someone who has primarily made my living the past 5 years as a "frontend engineer" (ie, JS programmer). JS frameworks can be wonderful for actual web applications, but they're way overkill for documents online for reading (and also make the experience worse for the reader).

Oh, and we also hate of dozens/hundreds of kb of unneeded font downloads.

Also, for the record, I'm a big fan of (appropriate use of) white space and color. I definitely come down heavily on the side of bettermotherfuckingwebsite.com (vs motherfuckingwebsite.com).

Reply on news.ycombinator.com