Website

[addyosmani]

Maybe we should have one 🍭

• Link to try out
• Link to WebPageTest result
• Link to Lighthouse report?
• Link to repo
• Link to framework (their PWA page if they have one)

[housseindjirdeh]

Wouldn't mind taking this on :), any other specifics you would like for the site? Simple 1-pager using a SSG? Also any design/colour preferences?

[addyosmani]

Oh that's super kind @housseindjirdeh :)

Some ideas to get this rolling 🚗

• 1 pager similar to todomvc.com. A static site generator sounds fine. Jekyll?
• Maybe use the current logo (hosted in the repo). Happy to defer to you for some suggestions on a color scheme that has good balance on color contrast. I like the ideas in this and this color schemes over on Dribbble.
• Brought to you by footer similar to todomvc. This time I think we should feature each app author in the avatars section down there too - wdyt?

Some ideas that are more open:

• Should we include screenshots of each app on the one pager or keep it clean and just show the implem name?
• Should we include a logo for each implem (e.g Angular, Vue, React etc) or again keep it simple?

[housseindjirdeh]

Sweet, Jekyll sounds good! I like the idea of having app authors in the bottom, so will give that a shot.

Hmmm I already pictured having a screenshot for each app so will try that and see how it turns out. The same for the logos. Will give you updates during the week as I work on it with screenshots.

Do you think we should have a separate repo for the site?

[addyosmani]

Let's do same repo. Site can live in a subdirectory and builds can push to gh-pages?

[housseindjirdeh]

Thanks mate, here's what I'm envisioning (still lots to do: this is really rough)

There's obviously a lot more to add but just wanted to give you a sense of how I'm picturing things. Will hopefully get a PR up by the end of the week.

Oh and I haven't gotten around to it yet but I think we should have a introduction paragraph before we show each of the implementations similar to todomvc 🤔

[addyosmani]

Thanks mate, here's what I'm envisioning (still lots to do: this is really rough)

I like it!

Oh and I haven't gotten around to it yet but I think we should have a introduction paragraph before we show each of the implementations similar to todomvc

👍

How would you feel about us also listing (maybe with some callout styling) the TTI and Lighthouse numbers for each implementation next to them?

[housseindjirdeh]

Nice yeah I was going for a simple list style for the stats of each implementation but I like the idea of callout/icon styling. Will try to incorporate that styling

[addyosmani]

Thanks! You're a hero. Super keen to see what you come up with :)

[sindresorhus]

I'm excited to see it too. 🌈

---

How would you feel about us also listing (maybe with some callout styling) the TTI and Lighthouse numbers for each implementation next to them?

Any way we can link to the Lighthouse report or at least a static version of it? The Lighthouse score by itself is not that interesting as you don't really know what the last 10 of 90/100 means.

[housseindjirdeh]

@sindresorhus thank you :)

Agreed, we can save Lighthouse results as HTML so I think we should be able to save and link to them for each implementation 👍

[addyosmani]

Great idea.

WebPageTest should now support linking out to a version of the report generated when using the /easy setting. Clicking the result in WPT should take us to the report we can link to.

[housseindjirdeh]

@addyosmani Yes that's definitely easier, but if I'm not mistaken we still have the bug where it doesn't pick up HTTPS correct?

Also WPT only generates reports for mobile and not browser. Running 3G on /easy will most probably dock some points in Performance for a few of the apps. I guess we could run LTE using the advanced setting and generate reports for mobile that way, but maybe we'll still have minor performance hits since its mobile? 🤔

That's why I considered exporting reports manually to HTML, but WPT links will definitely be easier.

[housseindjirdeh]

http://hnpwa.surge.sh/

Let me know what you folks think :)

1. I decided to use Tachyons, and this let me not write any styles manually whatsoever. I think this will definitely help if anybody else works on this site as they can just refer to the docs to see what the classes do (the documentation is awesome). Please let me know if you would prefer that I used something else however.

2. I've included all the app contributors at the footer but please let me know if I missed anyone!

3. For the TTI/Lighthouse numbers beside each implementation, after playing around with the styling I decided to keep things simple. But let me know if you would like it styled differently.

Don't hesitate to let me know if you would like me to change/modify/add anything.

Desktop view:

Mobile view:

[addyosmani]

I really like it. How would you feel about us linking up the scores and numbers to WPT and LH reports so folks can dive into more details if they need to?

[housseindjirdeh]

Awesome I'm glad you like it :)

Ah yes the numbers right now link to Lighthouse + WPT reports but I guess that's not very clear. I'll need to do add something (icon?) to make the links more obvious.

[sindresorhus]

Looks great! :)

---

Ah yes the numbers right now link to Lighthouse + WPT reports but I guess that's not very clear.

Yes. Needs to be clearer. I only noticed because of the comment here. Either an icon or a underline.

[housseindjirdeh]

Added a 'open in new tab' icon to make things clearer.

Appreciate all the help @addyosmani, @sindresorhus <3. Please let me know if there's anything you think I should change!

[addyosmani]

@housseindjirdeh Great. So we've now landed the first version of the site. Thanks so much for all of your help.

There are a few performance related bits left to go, in particular trying to update the WPT runs for the apps once a few more fixes land in Lighthouse. Right now on http://hnpwa.surge.sh/ for example I see that Svelte is getting a 37/100 although I know it's on HTTPS.

@Rich-Harris are there any plans to add in a Web App manifest and support for SW to your HN app? It just occurred to me that you never said your Svelte HN was aiming to be a PWA so if that's not something you're interested in for it we can also drop it from the site. Any thoughts? :)

[cheeaun]

Just wondering, why are the phone mockups (Samsung phone, HTC phone) included as part of the site screenshots? I think would be better if just use a generic phone outline vector?

[addyosmani]

Want to file an issue and we can discuss there? A common phone frame might be useful to consider.

[Rich-Harris]

@addyosmani Yes, I do mean to. @kristoferbaxter remixed the site with H/2 push and a bunch of other goodies that sped it up by a significant amount, which I've been planning to merge into the original example — I'll add a manifest and SW at that point. Here's the issue where I promised myself I'd do it

[addyosmani]

Thanks for the reply, @Rich-Harris! Wow, that @kristoferbaxter is everywhere :)
It would be awesome to see SW and app manifest in there. Latter is usually pretty straight-forward and for SW https://www.npmjs.com/package/sw-precache-webpack-plugin could help automate much of the work there.

[kristoferbaxter]

We all want to make the Web fast! @Rich-Harris let me know if you want some additional changes... I'd be happy to clean things up a bit if helpful.

[Rich-Harris]

Hey all — just to let you know I've updated the Svelte HN, it's now a fully compliant PWA:

• https://hn.svelte.technology/
• https://www.webpagetest.org/result/170503_5V_d258dea5b63fa104d2697d17de5bd8c6/

My insistence on using custom fonts really hurts the initial load time, but it's a little quicker after that. Thanks to @kristoferbaxter for patiently walking me through some of the HTTP2 stuff yesterday!

[Rich-Harris]

One thing I wonder about — is there a case for standardising these apps a bit more? Right now, the front end library is only one small factor — where the app is hosted, how it fetches data, what features it implements, and how it's visually designed all contribute as much if not more to the overall score. But https://hnpwa.surge.sh/ makes it look as though the choice of UI library is the main thing that matters.

The value of TodoMVC was that it was an apples-to-apples comparison. Obviously that's a much harder thing to do with HN PWAs, but if people are going to be making decisions based on comparing these scores, perhaps it's necessary?

[housseindjirdeh]

@Rich-Harris that's a good point, the README does list out specifications for what each implementation must include. However there are no restrictions on where the app must be hosted or which API you use as long as it meets the specification requirements. Do you feel like those specs are decent enough to characterize a complete progressive HN client or do you think there needs to be more specifics?

One thing I think we can do is put those specifications in the site, I think that might be helpful in case one misses the README. If that's a good idea, I'll open an issue for that.

CC @addyosmani @sindresorhus

[Rich-Harris]

Do you feel like those specs are decent enough to characterize a complete progressive HN client

They're complete enough to characterize a PWA, but not to compare different ways of building those PWAs. If we really wanted to compare the UI libraries used to build them (and I'm making the assumption that that's a goal of this project — correct me if I'm wrong!) then I think we'd need to do something like the following:

• Every app gets hosted the same way, on the same infrastructure
• The back end fetches/stores data the same way
• The front end communicates with the back end in a standard way
• The layout and design (page size, fonts, etc etc) are common to all apps

In other words the only bits that change are a) how you server-render your views, and b) how you implement the shared design on the front end (which could even be enforced with automated tests).

[addyosmani]

One thing I wonder about — is there a case for standardising these apps a bit more?

+1. There's certainly a case for formalizing the requirements further. We intentionally opted to be pretty flexible early on to get more authors on board. Now that the project is further along I think it's worth getting more standardized.

where the app is hosted, how it fetches data, what features it implements, and how it's visually designed all contribute as much if not more to the overall score

We've seen many cases of app hosting being a large contributor to score variance. I hesitated prescribing a specific choice here because I'd personally say App Engine (we'd whitelist/give folks a free account). Open to suggestions. If there's not really push-back on going for a set choice, it's not hard for us to shoot for a provider and encourage getting the other implementations to switch over.

But https://hnpwa.surge.sh/ makes it look as though the choice of UI library is the main thing that matters.

One of the main goals of HNPWA is validating a UI library can successfully hit good performance targets on mobile for a non-trivial app. Anything that introduces more variables to that is something I'm open to us standardizing on.

we'd need to do something like the following:

Every app gets hosted the same way, on the same infrastructure
The back end fetches/stores data the same way
The front end communicates with the back end in a standard way
The layout and design (page size, fonts, etc etc) are common to all apps

I'm down with most of those. Could you clarify what you were thinking around backend data fetching? I would have thought some implementations would want flexibility to try out different things there as long as the final outcome improves perf, but sure you had a reasonable take on what was involved :)

One thing I think we can do is put those specifications in the site, I think that might be helpful in case one misses the README. If that's a good idea, I'll open an issue for that.

Good idea. Perhaps we link to that part of the README or move the specs into a dedicated file or page? It's be great to just have a single place we can send folks for finding out what the requirements are.

[Rich-Harris]

Could you clarify what you were thinking around backend data fetching?

Haven't fleshed this out or thought it through but maybe something like this — in my hypothetical server.js (which implements all my custom server-side rendering logic etc), I do something like this...

const express = require( 'express' );
const store = require( '@tastejs/hnpwa-store' );

const app = express();

app.get( '/:type/:page', ( req, res ) => {
  store.getItems( req.params.type, req.params.page ).then( data => {
    const rendered = listPage.render( data );

    res.writeHead( 200, {
      'Content-Type': 'text/html',
      'Cache-Control': 'no-cache',
      'Content-Length': rendered.length
    });

    res.end( rendered );
  });
});

// ...

...mutatis mutandis for streaming renderers etc. @tastejs/hnpwa-store handles communication with the HN API, caching, getting all the comments for a particular item and collapsing them into a single object, what-have-you.

In other words, almost all the custom implementation is dedicated to the actual rendering.

[kristoferbaxter]

Love these suggestions.

The goal isn't to have the absolute fastest implementation (I hope no one is trying to game the results!), instead it could be rephrased to show that all of these Frameworks can have a fast implementation.

Happy to migrate whenever.

[housseindjirdeh]

Since the website has been up and running for some time now, will close this ticket. Opened a separate issue #105 to discuss how we can standardize our requirements further.