Oh that sucks..How about "yarnish"? It's available on npm, sticks to your roots, and you can play on varnish if you like. Or you can always go the thesaurus route and use fleece, wool, cotton fiber, flaxen thread...
Thanks for sharing! The point here isn't just calculating the reading time based on a WPM metric, it's fetching a remote page, analyzing it to find the main content and then doing the maths, among other stuff taking into account any images.
Seconding that, this is far more useful than another TodoMVC implementation for getting a feel for how an Angular 2 app is put together, with multiple pages, data from an API and at least one component with more complex display logic.
It is a mistake to assume a browser supports javascript.
Angular/meteor/etc do not generate sane output, as throwing up what is essentially an empty body tag (literally so, in some cases) is not only totally unusable outside the one use-case you have planned for, the page being generated is equivalent to a server error.
The correct solution, of course, is to render the page server side (and cache it, if you're sane), and progressively enhance any features such as XHR-style loading. Some comments later in this thread have mentioned that this might be an upcoming feature in the near future, which is great.
Without server-side rendering? That is still no excuse to serve up an empty page. Put some sort of fallback there, or a link to some alternative page. At a minimum, at least have a proper error message about how your site only only works in browsers that support javascript.
> It is a mistake to assume a browser supports javascript.
I really feel at this stage in the battle that that argument is hurting the call for server side rendering. Don't get me wrong, I have been a pusher for PE for many years but it quite clearly is falling on deaf ears these days.
The reason being is that it's very easy for someone to turn around and say "none of our users that we care about turn js off". However it is much harder to ignore the fact that initial page load times with server side rendering are minimal in comparison to the render-via-js frameworks of today.
I believe we need to follow the performance argument.
