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.<p>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.<p>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.
All of the apps fail this test:<p>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).<p>Expected: Scroll position is restored.<p>Actual: Scroll position is not restored (most of them), back is broken (Svelte), scroll is some random place (Polymer).
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).
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.<p>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.
This is fantastic. todoMVC always lacked many features of standard apps, such as making an async request.<p>I wonder how fast a standard server side, non-JS version compares.
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.<p>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.<p>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].<p>[1] <a href="https://github.com/tastejs/hacker-news-pwas/issues/36" rel="nofollow">https://github.com/tastejs/hacker-news-pwas/issues/36</a>
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.
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.