Hacker News new | comments | show | ask | jobs | submit login
Gatsby – A Static Site Generator for React (github.com)
129 points by the_duke on July 20, 2016 | hide | past | web | favorite | 69 comments



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.


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/


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.


GP clearly stated that JavaScript is not required to view the text on the page.


Is that not a rewording of what I just said?


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


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.


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/


The value added as I perceive it by gatsby is instant page changes on link click. Is it possible to make phenomic preload at least some of the pages, as I really don't see what benefit it can provide otherwise?


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.


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.


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.


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


Webpack hot module does this for any framework, and afaik is what react reloading is built on:

http://webpack.github.io/docs/hot-module-replacement-with-we...


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.


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


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


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


Not sure what your point is since I never claimed react invented hot reloading.


Hot reloading != live reloading. With hot reloading all your local state is saved after the code changes.


Yes, I read the docs on the project.

How hard is it to hit cmd-R? Or install a browser extension that reloads every n seconds? Do we really need to add complexity for this?

If it works for you, go for it! Call me lazy, but unless I can see a substantial, measurable increase to either the user or my experience without tradeoffs, I am not going to invest the time.


Looking at your last sentence, I don't think you've developed a real project using hot reloading.

When you're debugging an action that is behind several other steps (eg: scroll, click something, fill something, click something), hot reloading feels amazing compared to reloading and performing those steps over and over again (or emulating them by changing the code or pre-filling forms and having to cleanup after).

It might not be impressive in terms of absolute time saved, but I know that for me the "wow this feels amazing" feeling of it makes me much more motivated, focused and productive.


I completely agree. One of those projects where the author was so focused in the `what` instead of the `why`. This kind of projects is why the JS community has bad fame among seasoned developers.


How extensive is your experience with building static sites? Mine is limited; perhaps there's more to it than meets the eye.


I'll also say that being able to type in markdown and watch the html page change as I do sounds really nice, and I personally much prefer templating with React to tools like jinja, handlebars, etc. The fact that this generates a site that runs like butter with js and works just fine without it is probably the killer feature for me, however.

I'm also curious how the code complexity for this compares to tools like pelican, Jekyll, etc.


I envisioned something like this some years ago. What's the excuse of the browser for not preloading page content with JS to minimize loading times, in a progressive enhancement fashion? What's wrong with wanting a less frustrating UX if you're not sacrificing basic functionality when running without JS? This is beautiful, keep going. Hope to use this myself.


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.


I think it is more about how you structure your components for development. React provides a nice modular approach using composition, which is just enjoyable to write. With static html files you need to come up with a good composition approach, forcing you to make decisions on how you want to do that.

Secondly, it also allows you to progressively enhance the static site easily if you want to in the future.


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.


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.


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


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


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


I agree with you. Plus, if you use Cloudflare, your server may not even take the burden of the request. They will do the caching of static content for you.


I dunno...

Reloading 10K of (likely cached in memory and compressed by server) HTML to load a new page of HTML when a user clicks a link, with a browser that respects caching headers and so doesn't bother reloading content supporting images/UI element sprite sheets/CSS/JavaScript is never the wrong thing to do with "static" sites. In many cases, it's the most right.


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.


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

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


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


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.


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


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.


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.


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.


Also: in your case, the model (pages in your site, content in the tabs) isn't changing, the view is, and the built-in capabilities of the browser as the "controller" are sufficient for a static model.

Reacting to a user event doesn't mean it's a "reactive UI", every UI is a reactive one by that definition.


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.


Why would you need to generate JSON files?


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


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 and the HTML slides -> 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 and sources -> https://github.com/staystatic/gatsby


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


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.


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


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.


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/ (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/

- 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

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/ and the showcased sites https://phenomic.io/showcase/


If its a static site why do you need react?


I have the same question. Not in a "pffft, why do you need that" kind of way, but in a "Hmmm, what aren't I seeing here" kind of way.


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.


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?


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.


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


Presumably it's faster, but I haven't seen a comparison so I can't say.

In interactive contexts, it probably helps to keep the application in a single state while reloading, but I don't believe that applies here.


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.


Will Google index a site built with this?


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


[flagged]


Please ignore rather than insult things you are uninterested in.


Would you please kind sir elaborate why you feel like this?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: