Hacker News Readers as Progressive Web Apps | Hacker News Reader

Hacker News Readers as Progressive Web Apps

hnpwa.com

275 pointstbassetto70 comments

It's great that these examples have been collected in one place, but it's an incredible leap to call this a spiritual successor to TodoMVC.

Fundamentally, every implementation is different at a UI level. They all have different designs, some have custom fonts. Some go directly to the Firebase source, whilst others go via an intermediate API. The scores that are being listed are affected by too many variables beyond the UI library for them to mean anything at all.

In addition, a spiritual successor to TodoMVC is going to have to reflect actual upcoming patterns in user interfaces. Things like shared element transitions, sound effects, perhaps some 3D effects, and numerous other things. Most HN clones don't even allow write operations, even TodoMVC has that.

Not only that, but they are also served differently.

For example, the React example has an "F" grade for static caching, whereas some other examples have "A". Doesn't sound like something a JavaScript library can influence.

Why is it that way? Because these are just sample projects from different people created at different points in time, served on different hosts, but suddenly brought under a single umbrella as if it was an organized project from the beginning.

There are big differences in build systems, e.g. some examples are optimized by hand to inline critical CSS at the build level, others aren't. There's nothing that prevents applying the same strategies to all examples, but the fact is some example authors had time to do it, and others didn't. Wouldn't it make sense to at least use the same build system for Preact and React examples?

I appreciate the effort by Addy and other folks from Google to highlight performance issues in web apps, but as it stands right now I consider the website to be rather misleading.

Exactly. They are not comparing apples to apples.

Firebase API has gotten slower over the years. That affects Interactive time and lighthouse score. Preact HN uses their own servers, and React HN uses the Firebase API.

Also, some passes site is progressively enhanced check because some elements are rendered without JS. Which results in higher score.

Preact HN loads offline but without content. Lighthouse assumes that app works offline, but in reality app is useless without actual stories.

I use Firebase API in my web app (https://hn.premii.com/) and scrap YC in my downloadable app (https://hn.premii.com/about/). Both has different actual and perceived performance.

Write operations are not possible with HN clones as there are no YC apis. They should build reddit clone. I have build reddit clone https://reddit.premii.com/ using their official APIs.

All of the apps fail this test:

1. Go to main page. 2. Enter a long comments section. 3. Scroll down. 4. Hit back (back to main page again). 5. Hit forward (back to comments section).

Expected: Scroll position is restored.

Actual: Scroll position is not restored (most of them), back is broken (Svelte), scroll is some random place (Polymer).

Weird. Just tried using the Polymer app in Safari and it worked fine. I'm guessing different browsers handle this case differently.

Edit: Just tried again using Chrome, back + forward consistently took me to the same scroll location.

Edit 2: Ahh, Chrome doesn't restore scroll position correctly if you scroll a bit when you go back to the home page before hitting forward. Safari handles this fine.

What I find interesting is that subtle differences in load time have a great impact on the first impression. Furthermore loading animations seem to have an influence how one perceives performance - for me the non-loading animation pages seemed much faster (although the given latency numbers did not suggest such a big difference).

I felt the opposite. All the examples seemed fast and the differences seemed negligible. I wonder if our internet connections / platforms were different. I was using chrome on a 2015 MBP with ~decentish wifi.

Yeah PWAs (progressive web apps) are really not aimed at us devs with fancy MPBs and good connections. You should probably open devtools and throttle your connection to 3g or worse to get a feel for the problem area they're trying to hit.

Don't forget to throttle the CPU too. Phones can't parse and eval script nearly as fast as a laptop or desktop.

Or just browse on your mobile!

Overall they're pretty quick on my Galaxy S2. A bigger concern is formatting - some adjust for mobile, others do not and the font is displayed in .5 millimetre type. :(

(perhaps I should apply for a testing job!)

Thanks for pointing this out! I had thought they all fit mobile devices just fine but I'm most probably wrong. They should all definitely be fully responsive on mobile, feel free to log an issue on their implementations if you would like to :)

I was an Android dev for 1.5 yrs (after coming from Andorid firmware/middleware background).

In these last 4-5 months that I have been a frontend dev (angular) and have played around with chrome throttling dev tool and questions by product about load time that I realised how life is difficult for web developers and users in emerging markets.

It's not like one doesn't have to think of load time, performance, and bandwidth in Android but, there, things are quite standard to some extend when comes to achieving a decent level of performance.

One thing I have learned, and still learning, and that is avoid jquery (and esp. it's plugins) as much as you can. I mean they can pile up really fast.

Use the network simulator in Chrome or the system Network Link Conditioner and it's much easier to see how much of a difference it makes when the network isn't so good

As others mentioned, throttling your settings will show you that the differences actually aren't that negligible. With the Chrome devtools, throttling network connections to Regular 3G and CPU slowdown to 10X will give you a rough estimate of how mobile devices with flaky connection interact with these applications.

Another thing is that each of these implementations pre-cache most (if not all) of their static resources with a service worker -> and that's why repeat visits on each site is quite fast. Using incognito or clearing the site data and unregistering the service worker and then loading the site as a first-time visit under those throttled conditions will let you easily notice how much faster some of the implementations are then others (for example: Preact and Angular)

No, it was not the connection (75MBit/s), I think - it just took some seconds(!) to load.

Big +1 on loading animations making everything feel much slower.

I have a slow connection and loading animation made me feel it's fast. Whereas no-loading-animation pages seemed like it stopped working for couple of seconds before showing information.

Agree with performance on first time loading. Famous ones: Angular, React, Vue felt slow.

This is my "Hacker News Reader". It converts HN to csv. (Only selected fields of interest to me.) From there it can easily be imported into kdb+. I have more reusable generalized lex techniques for other websites but HN is so simple it can be done via a braindead one-off as below.

Requirements: lex, cc

Usage:

   fetch -4o yc.htm https://news.ycombinator.com
   yc < yc.htm

To compile this I use something like

    flex -Crfa -8 -i yc.l;
    cc -Wall -pipe lex.yy.c -static -o yc;

Save the text below as yc.l then compile as above.

    #define jmp BEGIN
    #define p printf
    #define x yytext
   %s aa bb cc dd ee ff gg hh
   %s ii jj kk ll mm nn oo 
   aa "span class=\"rank\""
   bb "a href=\""
   cc score_........
   dd \>
    /* #include <time.h> */
    /* #include <util.h> */
   %%
   [^\12\40-\176]
   , p("%2c");
    /* rank (dont care) */
   {aa} jmp aa;
    /* <aa>[1-9][^<\.]* p("\n%s,",x);jmp bb; */
   <aa>[1-9][^<\.]* p("\n");jmp bb; 
    /* url */
   <bb>{bb} jmp cc;
   <cc>http[^"]* p("%s,",x);jmp dd; 
    /* title */
   <dd>{dd} jmp ee;
    /* <ee>[^><]* p("%s,",x);jmp ff; */
   <ee>[^><]* p("%s",x);jmp ff;
    /* host (omit) */
    /* points (dont care) */
   <ff>{cc} jmp gg;
   <gg>{dd} jmp hh;
    /* <hh>[1-9][^<> p]* p("%s,",x);jmp ii; */
   <hh>[1-9][^<> p]* p(",");jmp ii; 
    /* user */
   <ii>{bb} jmp jj;
   <jj>http[^"]* p("%s,",x);jmp kk;
    /* time (dont care) */
   <kk>{bb} jmp ll;
    /* <ll>http[^"]* ; */
   <ll>http[^"]* jmp mm;
    /* unix time (dont care) */
    /* <ll>[1-9][^<]* { 
    time_t t0; time_t t1; time_t t2;
    t1=time(&t0);
    t2=parsedate(x,&t1,0);
    p("%d,",t2); 
    jmp mm;
    } */
    /* item */
   <mm>{bb} jmp nn;
    /* <nn>http[^"]* p("%s,",x);jmp oo; */
   <nn>http[^"]* p("%s",x);jmp oo;
    /* comments (dont care) */
   <oo>{dd} jmp oo;
    /* <oo>[1-9d][^ <]* p("%s",x);jmp 0; */
   <oo>[1-9d][^ <]* jmp 0;
   .
   \n
   %%
   main(){ yylex();}
   yywrap(){ p("\n");}

There's an API: https://github.com/HackerNews/API

And I thought using regex for parsing HTML was bad.

It'd be cool to see a version that allowed you to login and vote. Session management and all that entails can be really tricky to implement correctly, and it's a frequently asked question with most frontend frameworks.

I haven't read through each repo's source yet, so take what I'm saying with a grain of salt. Glancing through each repo, only the Angular 2 version has tests. It's pretty easy to write throw away code that works once and you don't have to maintain long-term, so I'd advise caution in adopting patterns from these examples.

Is there a good Android app where you can login and reply to comments?

Materialistic is what I use, considering most of my Web browsing is done through the apps.

It's has login, vote and save(I guess it saves articles locally)

The con is that it has not been updated in a long time.

It's available on fdroid

Yes, there is. I've tried a few of them and HN Materialistic is the superb one: https://play.google.com/store/apps/details?id=io.github.hidr...

I didn't even notice you could log in on that app. Thanks!

Github.com/premii – I'm writing from it.

I use Hews, tried Materialistic but still prefer layout of Hews and I can change font face to Serif.

IIRC access to an authenticated user is not a feature of the API, hence why the custom readers don't support leaving comments. I think the only way to do it is by having a user trust your app with their credentials.

Yeah. I think that's what MiniHack does on iOS, but hell it's well worth it, it's the single best app I've used for HN!

This is fantastic. todoMVC always lacked many features of standard apps, such as making an async request.

I wonder how fast a standard server side, non-JS version compares.

A standard server-side, non-JS version of the Hacker News front page? I feel like that's pretty easy to find.

0.2 to 0.7 seconds for me

How fast are the others for you? 0.7 seconds tell me nothing if you have the newest Razer Blade and a gigabit connection.

Good point. Others are indeed faster - 0.7 to 0.1 once cached (not sure why Chrome doesn't brake it).

I do have 802.11ac on 100mb fiber...

Right, but it should be benchmarked so that all requests originate from the same server so latency and other factors are not a problem.

Yep you're 100% right, that's something we've discussed [1] and definitely something we still need to do [2].

[1] https://github.com/tastejs/hacker-news-pwas/issues/7#issueco... [2] https://github.com/tastejs/hacker-news-pwas/issues/4

Has anyone extensively used Preact? Would like to hear first hand experiences about any performance gains (or anything in general)

Preact is brilliant. I use it instead of React for basically anything that I'm allowed to, for one single reason: it's Component class's "render()" method takes props and state as arguments! Testing becomes nicer, especially when porting an existing React component over, and I find it conceptually much cleaner.

Getting up and running with Preact, TypeScript (or Bublé[0]) and Rollup is pretty simple, and gives an extremely small and very fast bundle, which I just adore.

The big thing, is that by choosing the right tools, I can keep my `ls node_moduels | wc -l` small, and Rollup's tree-shaking takes that even further. With some forethought, one can achieve this with React, too, but I find Preact beautiful to use, and Hyperscript instead of JSX can be a boon for rapidly prototyping an idea for a component instead of setting up yet-another-js-build-system!

[0] https://buble.surge.sh/guide/

Edited to add: I've also used it successfully for some (unfortunately internal, I'd love to show you them) big production systems, where we had a team of 7 developers working on it at the end. Still in use now, and it was a breeze -- and runs extremely fast, UI-wise.

I recently made a complete transition to Preact, and although there were a few twists needed to migrate a previous React project, overall I'm very happy with it. Haven't noticed any performance gains (other than page load time, maybe slightly). Aside from the reduction in app size, what I like is that Preact's code base is small enough to read in an evening and understand it.

Did the Svelte version hijack the back button for anyone else?

The browser back button? Hmmm it seems fine for me, not noticing any weird behaviour.

Nope never mind, navigating within the app works but navigating out back to hnpwa.com doesn't. I'm noticing the same on Chrome desktop and iOS safari.

Opened an issue for it: https://github.com/sveltejs/svelte-hackernews/issues/10

Yes. Firefox on Linux.

Yep, it did for me on mobile safari. How are the same garbage mistakes still happening.

Yup. Polymer version doesn't seem to be showing the right content either.

Thought it may have been because of a different API but looks like the service worker is configured to always return the fastest retrievable data, hence why it's obtaining stale data from the service worker cache.

Issue has been opened for it: https://github.com/Polymer/hn-polymer-2/issues/3

I'd like to see a comparison with old fashioned HTML and CSS.

Try this: http://news.ycombinator.com

When you click on Lighthouse for Vue.js the score is actually significantly worse: 78/100

Why is that showing 93/100 in the list?

Genuinely can't thank everybody for all the feedback. A lot of you mentioned that we're not comparing apples to apples here, and you couldn't be more right. I take full responsibility for this, and I really apologize if the site's design made it look that way.

Each of the implementations were built at a completely different time by different authors and are not representative as official library implementations at all. In no way was it our intent to make it seem like a reference of performance comparison between the different libraries, so again I apologize if it comes across that way.

We do need to standardize each of the apps so that they can actually be compared, but until then we'll need to make sure that things are more transparent. In the next few days we'll add some changes to how we display each of the implementations for this [1].

[1] https://github.com/tastejs/hacker-news-pwas/issues/36

It was kind of meta to click through each one to this same HN story. At least until Polymer, which displays an earlier first page. I suppose it should work that way, but it felt like I'd taken a wrong turn.

Not all of the implementations are using the same API hence why the data isn't displayed the same on each :P

We've discussed standardizing the specifications [1] for each of the apps which covers how they're hosted, how they fetch their data, etc... That's something we still need to do so hopefully sometime soon we'll have each of the apps standardized similarly.

[1] https://github.com/tastejs/hacker-news-pwas/issues/7#issueco...

Scratch that, according to this issue (https://github.com/Polymer/hn-polymer-2/issues/3) it may not be an API issue and is probably because of stale service worker data not being refreshed.

They all look ugly, load slower, and consume more battery than a straight webpage, and they offer no discernible advantage or features.

That's not really the point though - it's a comparison between multiple frameworks using their implementation of a Hacker News clone as a sort of benchmark. More importantly - by looking at the source of each one, you can compare the common patterns and pitfalls of the framework.

I do agree though that these all are not good use cases for the frameworks - a news aggregation site doesn't have enough state or cross-application relationships to warrant the overhead of any of these framework. Especially in comparison to Hacker News - which is so minimalist as it is - adding to it can only really take away.

I especially liked the fact that although I have JavaScript disabled by default in Brave, I didn't notice that at first for React, Preact, Svelte, and Viper because those degrade well.

Where is the elm version?

Would be great to have Elm on there as well! Contributions are open to any Hacker News implementation that meets the specs :)

This is really fascinating and informative. Thank you!

I wish these were ordered by speed.

React is worst.

I'm quite surprised that someone had enough will + time to develop seven implementations of the same thing.

They didn't, they're written by different people.

And again we see that React isn't that great these days.

I hope this changes with v16, which seems an API compatible rewrite of their rendering engine e.

But at least Preact is also API compatible with React, so you can go from the worst to the best.

This isn't some sort of best-practice example application written by the React team, nor has it even been optimised in any meaningful way - it's the same base app started by some rando on the day the Hacker News API was made available [1], and later given the PWA treatment by Addy Osmani.

[1] https://news.ycombinator.com/item?id=8426249

Nice to know, thanks.

Apparently, this site isn't intended to be a contest/perf-comparison. It's supposed to show that solid PWAs are doable with all of these frameworks. Looks like the authors are working on clarifying this: https://github.com/tastejs/hacker-news-pwas/issues/36

> this site isn't intended to be a contest/perf-comparison

It's comparing load time, not performance.

You missed the point, it's not supposed to be 'comparing' anything. See the thread I linked to.

(Also 'performance' is a broad term that encompasses load time. If a page loads faster it performs better).

Reply on news.ycombinator.com