Hacker News new | ask | show | jobs
by megawatthours 3408 days ago
This claims to improve static websites by adding hot reloading, search, React, the NPM ecosystem, and faster page load.

Search can already be done using Jekyll https://blog.algolia.com/instant-search-blog-documentation-j... (same idea of indexing at build time).

Jekyll can hot reload with jekyll serve.

Anyone who is familiar with React is familiar with HTML and CSS, whereas the opposite is not necessarily true. This means if you are able to use Phenomic, you are able to use Jekyll, but not vice versa.

The NPM ecosystem is useful for authoring templates, not for the end user. If I were writing a Jekyll template I'd probably use webpack and npm, but I don't need that baked into the static site generator itself.

Finally, page load is a really dubious claim, here's some numbers:

On phenomic.io, the HTML for the index page weighs 3K gzipped (measured by copying HTML, removing what can be externalized and cached like styles + scripts, and gzipping index.html)

When using Phemonic to do client-side loading, the JSON for the different pages is from 600B to 2.9K (as seen in network tools when clicking on the links in the top nav).

A page load with phemonic therefore saves you: * 2KB of bandwidth for some pages * a few 302 not modified requests for static resources, which are negligible if you use HTTP/2

On the flip side of the coin, phemonic.js, the script bundle which makes all this magic possible, weighs 132KB, ie 44 times the size of the content the user wants to view.

I can't see the value here.

1 comments

Javascript doesn't affect page load (generally). What Phenomic (and my project Gatsby) speed up is clicking around within a site after the initial page load as we pre-cache subsequent pages so loading those pages is near-instant.
Browsing static pages is near-instant. No need for React to do that.
Sure there's diminishing returns from ~1-2 seconds page change for a DB-backed site (slower ones anyways) to the ~500 millisecond page change for a normal static site generator to the ~50 milliseconds for a React-based one but it's still a significant difference.

But in any case, client-side routing to me is a nice-to-have not the killer feature for Gatsby. Building web sites with the React component model is the killer feature for me.

Another point in favor of this model is because routing is client-side, page changes are consistently fast. In best-case network conditions, normal static sites are very fast but throw the user on a glitchy 3g network and you'll soon see 5-10 second page loads. The same site built with Gatsby will still see instant page changes as page data is precached.
That's a big advantage, but at the same time you're pushing content to a user that they might not want, or ever see, which could be a problem for users on poor quality 3G networks. If bandwidth is at a premium a developer shouldn't waste it.
"Bandwidth" isn't the problem on 3g generally. What does cause UX problems is high latency. Speculatively precaching content is basically the only solution.

FWIW, while I'm in the US so don't really understand developing for very poor networks, the methods I'm describing is exactly what companies in India and other places with poor networks are adopting: https://developers.google.com/web/showcase/2016/flipkart

This is also a good read https://developers.google.com/web/fundamentals/performance/p...