
Gatsby – A Static Site Generator for React - the_duke
https://github.com/gatsbyjs/gatsby
======
xrstf
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, DOMContentLoaded @ 22.07s (includes
Disqus)

For caching purposes, it might make sense to split the bundle.js into a app.js
and content.js and only update the content.js on re-deployments. Not sure if
this is just on the author's blog or on every site built with Gatsby.

~~~
dmix
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-facebook-
groups/](https://bricolage.io/tools-administer-facebook-groups/)

~~~
maerek
That's not progressive enhancement, it's lazy loading.

Progressive enhancement would be making all of the content visible and
accessible, then adding functionality on top after the base page load is
complete. If JS is required to simply view the text on a page, you're doing it
wrong.

~~~
morgante
GP clearly stated that JavaScript is _not_ required to view the text on the
page.

------
cjjuice
Over-engineering at it's finest.

React is great for some applications, IMO this is not one of them. To me it
just over complicates things for minimal gain.

~~~
peternicky
Did you even read the docs for this project? In my opinion, this pulls
together different tools that improve developer experience dramatically. For
me personally, hot reloading is quite useful.

~~~
juandazapata
Hot reloading is not exclusive to react. Live reloading has been around for
about a decade and is compatible with everything that renders to a web
browser.

~~~
morgante
> Live reloading has been around for about a decade and is compatible with
> everything that renders to a web browser.

I have not seen any evidence of that being true.

To be clear, React reloading doesn't reload the whole bundle. Only the
specific module modified is updated and re-executed.

It's a major improvement over normal reloading techniques which typically
either reload the whole page or the whole bundle.

~~~
spdustin
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 tree you
want to replace and grafting on its replacement is, really, showboating,
especially when you're talking about replacing 90% of the DOM tree (rough
estimate of content vs. "chrome" as a percentage of the DOM tree) in one shot.

~~~
morgante
> 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 instantly makes development very different. As I'm scrolling through
the site, I notice that a pixel in the footer is off by a little bit. So I
tweak the relevant CSS and it instantly updates in front of me.

With a traditional static setup, I have to reload the whole page and wait for
it to re-render. It's a difference of a few ms vs a second or more.

You're also incorrectly assuming that tweaks would require reloading 90% of
the DOM tree which is fundamentally wrong. I can decompose a static site into
many small components and each one can be reloaded individually. Not to
mention that if I make a CSS tweak it doesn't require reloading the DOM at
all.

Honestly, I have no vested interest in convincing you that hot module
reloading is helpful for even the simplest of sites. Feel free to not use it.
All I know is that having used both I will never go back.

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

~~~
savolai
It will if you have to first alt-tab to the browser, click F5, then alt-tab
back to editor to make further changes.

------
tptacek
Can someone make a case for React on static blog sites? How is this a net win
versus plain 'ol HTML?

For fancy marketing sites I get it immediately, I guess.

~~~
the_duke
The same reason why anybody is using React instead of full site reloads.

Only do a small (api) data request per page, faster page transitions, a more
interactive experience.

Just think of the site generator as a static api backend for the the JS
frontend.

~~~
jamra
Why not just have HTML generated at some earlier time? It's faster, can be
cached, and does the same thing.

I'm a little confused about no page transitions. I don't know why that is a
problem that needs solving. Also hot reloading.

~~~
enraged_camel
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 consider. I just don't think it's a matter of "this isn't a
problem that needs solving."

~~~
virtualwhys
> 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 web page where the browser only needs to handle
a small fragment of html after initial page load, which typically makes for
blazing fast page transitions, indistinguishable from SPA transitions.

I get the benefit of offloading work to the client when scalability is an
issue, but for a static blog site? Not so much, I'd say using React in this
case is less about the user experience and more about the developer's.

~~~
escapee
> 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.

------
spdustin
It's clever. It's well done. I'm not the audience, though. I love React for,
you know, "Reactive UI", the "V" of an "MVC" app, but when creating the site's
content store (the "static API backend") is a "build" time event, I don't feel
that there is anything to "react" to.

~~~
wtetzner
Well, I suspect user interaction is what it would react to.

~~~
spdustin
That's the browser's job. It's the default controller.

The model isn't changing state. The controller is translating the same static
content over and over. Browsers already do that in "reacting" to user's event
inputs, e.g. onclick.

~~~
atoko
Consider a site with a tabbed navigation bar. With the router you can develop
each target page as it's own component and use the url to navigate between
them.

~~~
spdustin
I can appreciate the concept, but Hugo/Jekyll/Middleman can let you author the
original "component" pages and automatically generate a nice, simple <nav>
element with an unordered list (or ordered list, if it's more semantically
correct) of <a> elements. Plus wrap those tab-page components in your site-
wide layout "chrome". You could even progressively enhance the site so that
the browser uses idle time post-DOMReady to preload linked pages via
XMLHttpRequest, so that they can be pre-cached and ready to load when the user
clicks the link. No second load required to load the chrome of the site and
then load the routed page resource if someone deep-links.

My point isn't that React is bad (I really, really dig React for those
"reactive" views connected to a model representing dynamic data), but that
we're effectively over-engineering an ancient use case — a CMS where content
is defined statically _at build time_ — that good ol' HTML does exceedingly
well with no complicated tooling and (if marked up and styled sanely, with
progressive enhancement where appropriate) no browser compatibility concerns.

------
andreypopp
Another one which is also based on React I've been working on recently:
[http://andreypopp.github.io/sitegen/](http://andreypopp.github.io/sitegen/)

Supports pagination and progressive content loading, I believe its design is
superior to other React based static site generators.

~~~
biscarch
As someone who is also building a React-based SSG, what do you believe makes
sitegen's design superior to other React SSG's?

------
the_duke
Just discovered this project.

Since I recently wanted to build a new static site, I tried to hack an
existing SSG into generating JSON files to support something like React.
Wasn't exactly painless.

So I'm happy about Gatsby.

~~~
cool_penguins
Why would you need to generate JSON files?

~~~
the_duke
To make individual pages loadable and consumable by a JS frontend like React
or Angular, with meta-data like site title, author, etc.

------
geraldbauer
Love the Great Gatsby. For last week's Vienna React.js meetup I've put
together a talk titled "Build (Web)Sites w/ the Great Gatsby (and React.js)".
Find the all-in-one-page source ->
[https://github.com/geraldb/talks/blob/master/gatsby.md](https://github.com/geraldb/talks/blob/master/gatsby.md)
and the HTML slides ->
[http://slideshow-s9.github.io/demos/gatsby.html](http://slideshow-s9.github.io/demos/gatsby.html)
Cheers.

PS: You can find the Gatsby Stay Static Sample Site @
[http://staystatic.github.io/sites/gatsby](http://staystatic.github.io/sites/gatsby)
and sources ->
[https://github.com/staystatic/gatsby](https://github.com/staystatic/gatsby)

------
snake_case
I created a very basic react static site generator called rovr [0]. It was an
experiment I started about a year ago to learn more about react... and I also
wanted to create something similar to how Jekyll works. You can mix html,
markdown, and react components to create pages and layouts.

Anyway, I don't plan on supporting it... just an experiment. I should probably
update the readme to state that.

While developing rovr, I was also learning ES6 at the same time. If you have
any opinions on the code, please let me know!

I have checked out Gatsby before though, and it looks like a great project
with many more features than rovr. Although I'm happy with Jekyll, I may try
this out again in the future.

[0]:
[https://github.com/jakedeichert/rovr](https://github.com/jakedeichert/rovr)

------
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.

------
ajsharp
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.

~~~
atokocardona
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

------
eschutte2
Used this recently for a client's static site. In our case, we had an existing
React codebase for the app part of the site, so using React for the static
site gave us a consistent way to get composition of components and also
allowed us to reuse a header widget from the app on the static site in a very
clean way.

One thing I wish was easier was disabling the whole react-router part and just
outputting standalone pages.

------
MoOx_
I would recommand you taking a look to Phenomic, an alternative to Gatby.
There is an entry on Phenomic FAQ that try to list majors differences between
Phenomic and Gatsby
[https://phenomic.io/docs/faq/gatsby/](https://phenomic.io/docs/faq/gatsby/)
(not reviewed by Gatsby author yet even if I poked him - he is probably busy).

Here are some key points I would like to highlight:

\- like gatsby, Phenomic generate HTML for all pages (so works without JS)

\- unlike gatsby, Phenomic does not put all content of the website in the JS
client side bundle (content is loaded on demand only, which is a must have for
moderate and big websites)

\- offline support can be enabled with a single boolean flag to save all
content of the website (make sense for docs) but you have plenty of options in
case you want something more flexible (like cache when viewed)
[https://phenomic.io/docs/advanced/offline-
browsing/](https://phenomic.io/docs/advanced/offline-browsing/)

\- we will offer soon a built-in search probably via algolia, but I will try
to offer alternatives (note that it can already be setup pretty easily - some
of our users already did this with just a few lines of code)

\- a plugin system is coming soon so you can tweak the content consumed by
phenomic

\- themes will be a thing

\- in case you have some questions before making your choices, here is a link
to our gitter chat
[https://gitter.im/MoOx/phenomic](https://gitter.im/MoOx/phenomic)

Phenomic is not meant to be a closed/magic box: you have full control over any
step of the build process. And you also have full control over your webpack
and babel config etc. We offer flexibility for built-in options via JSON or
CLI args (we use yargs and an additional custom layer to validates all options
and values so you make any mistakes).

Btw, Phenomic offers by default best practices with eslint/stylelint and uses
under the hood AVA for its tests.

Just take a quick look to [https://phenomic.io/](https://phenomic.io/) and the
showcased sites [https://phenomic.io/showcase/](https://phenomic.io/showcase/)

------
thinkingkong
If its a static site why do you need react?

~~~
rattray
Some people prefer it as a templating tool (myself included).

React also enables some of the features of the tool. For example, hot
reloading the contents of the page while writing/developing, which may make
for a smoother experience.

If this isn't to your taste or doesn't fit your requirements, I'm sure the OP
and author of the tool would not be offended if you continued to use Jekyll et
al.

~~~
juandazapata
What is so special about hot reloading? Live Reload has been around for about
a decade and it's compatible with everything that renders to a web browser. Am
I missing something here?

~~~
fooey
Think about something like a modal dialog that takes multiple clicks from a
fresh page to get into. Hot reloading lets you dev on that dialog code without
having to go through all the intermediate steps each time you save.

~~~
juandazapata
That feature must be super useful for a static website generator.

------
desireco42
I don't really see the point, unless you are using it to prototype react app,
in which case it would make sense.

I did find some really interesting services when I was looking through the
reference list, Syncano in particular.

I will stick to Middleman, I can always use React there.

------
shocks
Will Google index a site built with this?

~~~
rattray
Yes, it generates static HTML pages that work with JavaScript disabled.

