Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gatsby – A Static Site Generator for React

github.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Gatsby – A Static Site Generator for React

#61

Post by dredmorbius »

dmix wrote: post #24
xrstf wrote: post #9

I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content. Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms With JS: 27 requests, 518 KB transferred, DOMContentLo…

As long as the top of the article content (headline + first few paragraphs) loads immediately I don't care if it loads 700kb afterwards for other interactive content. 'Progressive enhancement' should be the primary goal; size reduction is just one means to achieving that but not always required. From testing out one of the example blogs and this doesn't seem to be a UX issue: https://bricolage.io/tools-administer-fac…

You might not. A capped-bandwidth or pay-by-the-byte mobile user might.

Re: Gatsby – A Static Site Generator for React

#62

Post by escapee »

virtualwhys wrote: post #43
enraged_camel wrote: post #10

Earlier quoted context omitted.

It comes down to user experience. There's a categorical difference between having to do regular transitions and full-page reloads, and no page transitions and hot reloading. The latter is more overhead from an initial bandwidth and processing perspective, but results in zero-latency interactions, which can be important. Is a JS framework the best way to achieve that? Maybe, maybe not. There are many factors to consid…

> It comes down to user experience Indeed, it does. My experience visiting SPAs is frankly one of annoyance. Somehow, with 32GB of memory, dual SSDs and an i7 extreme processor, the browser grinds to a crawl with at least 1 CPU core maxed out for however long it takes for the extraneous (to me) transition/effect to complete. As a side effect the CPU fan kicks in for my auditory pleasure. Compare that to a traditional…

> My experience visiting SPAs is frankly one of annoyance.

I will echo this. SPAs can be great when done well, but my experience with them as a user suggests they're easy to do poorly.

Re: Gatsby – A Static Site Generator for React

#63

Post by biscarch »

spdustin wrote: post #54
biscarch wrote: post #47

Earlier quoted context omitted.

Having React on a static blog makes it easier to share component libraries that you've built up on other projects (perhaps SPAs) with said static blog. It also allows the use of React's ecosystem, such as react-helmet[0], which makes it easier to change the meta tags and title on the page when rendering. [0]: https://github.com/nfl/react-helmet

...which can be done with YAML frontmatter on a markdown file in other static site generator, simply referencing the frontmatter in the layout partial that you have wrapping every page anyway.

Right, except support for that has to be built into the static site generator you're using. In the React case, the user can choose how they want to do it without the SSG author caring at all. I will also say that in the case of frontmatter, react-helment is a far more powerful solution which allows defining at any point in the tree, not just a layout partial.

In addition, the React way allows you a full language to handle import/export for "templates" instead of relying on a hampered template language/partials implementation.

The key here isn't the specific instance of frontmatter, it's having the flexibility to use everything one might use to build a SPA to target static sites. This re-use of existing solutions and skills is important.

Re: Gatsby – A Static Site Generator for React

#65

Post by kup0 »

xrstf wrote: post #9

I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content. Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms With JS: 27 requests, 518 KB transferred, DOMContentLo…

What this tells me is that the only important part of the site (the content) is 20KB in size, and that the other 498KB is mostly for developer convenience?

How is this a good tradeoff? A 25x increase in page size justifies what kind of benefit?

For efficiency's sake in general, not to mention for a drastic reduction in data usage for mobile users or users with slow connections, I don't see why so much extra cruft is necessary.

Re: Gatsby – A Static Site Generator for React

#66

Post by atokocardona »

ajsharp wrote: post #64

Using a javascript framework to generate a static HTML site is like building an entire car so you can extract just the chassis from it. Eagerly awaiting attacks on the car simile. Go.

The difference being that React is like an industrial factory where HTML is more like building a gokart from a kit.

It's just tooling

Re: Gatsby – A Static Site Generator for React

#67

Post by dimal »

kup0 wrote: post #65
xrstf wrote: post #9

I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content. Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms With JS: 27 requests, 518 KB transferred, DOMContentLo…

What this tells me is that the only important part of the site (the content) is 20KB in size, and that the other 498KB is mostly for developer convenience? How is this a good tradeoff? A 25x increase in page size justifies what kind of benefit? For efficiency's sake in general, not to mention for a drastic reduction in data usage for mobile users or users with slow connections, I don't see why so much extra cruft is…

When I click around the site, page loads are instantaneous. Very nice user experience.

Re: Gatsby – A Static Site Generator for React

#68

Post by juandazapata »

morgante wrote: post #56
spdustin wrote: post #53

Earlier quoted context omitted.

What you're calling a module is, in a static site, a page or (maybe) a partial. Livereloading the HTML isn't an expensive operation, and while one might argue that, by shipping the whole page HTML, you're using a chainsaw when a scalpel would suffice, I would argue back: Chainsaws make short work of (DOM) trees when you're tearing it down wholesale and delivering a new one, but delicately carving out the part of the…

> What you're calling a module is, in a static site, a page or (maybe) a partial. Maybe that's how you develop sites. I would decompose even a simple blog into at least half a dozen different components. First of all, I'm not making abstract arguments. I have direct experience with developing a static site using Jekyll vs. React. React with HMR is infinitely more pleasurable and faster. Being able to update the site…

Your local development machine takes one second or more to reload a static html page? Oh wow.

Re: Gatsby – A Static Site Generator for React

#69

Post by greenspot »

Over-engineering at its best.

React is great but so wrong for an SSG and instantaneous loading of next pages is great but...

- Preloading all blog posts does not scale and is not wanted; a post is read and only a tiny tiny part clicks on the next or other posts

- More important is that the initial or clicked post loads rapidly, but it doesn't, it's slow and when looking on all the other million SSGed blogs which load in milliseconds, no thanks

I looked deep into Gatsy once I was choosing a SSG but until the end I couldn't understand the architectural decisions made. Yes it feels fancy but doesn't match the use case at all.

Re: Gatsby – A Static Site Generator for React

#70

Post by MoOx_ »

dimal wrote: post #67
kup0 wrote: post #65

Earlier quoted context omitted.

What this tells me is that the only important part of the site (the content) is 20KB in size, and that the other 498KB is mostly for developer convenience? How is this a good tradeoff? A 25x increase in page size justifies what kind of benefit? For efficiency's sake in general, not to mention for a drastic reduction in data usage for mobile users or users with slow connections, I don't see why so much extra cruft is…

When I click around the site, page loads are instantaneous. Very nice user experience.

You can provide the same user experience without adding all the site content in a unique bundle. Take a look to http://phenomic.io/
Post reply on HN