9 ms·
Gatsby – A Static Site Generator for React
- the_duke 10y agoJust 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 10y agoWhy would you need to generate JSON files?
- the_duke 10y agoTo make individual pages loadable and consumable by a JS frontend like React or Angular, with meta-data like site title, author, etc.
- tptacek 10y agoCan 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 10y agoThe 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 10y agoWhy 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 10y agoIt 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."
- spdustin 10y agoI 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.
- virtualwhys 10y ago> 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.
- jamra 10y agoI 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.
- wesleytodd 10y agoI 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.
- biscarch 10y agoHaving 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 https://github.com/nfl/react-helmet
- spdustin 10y ago...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.
- biscarch 10y agoRight, 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.
- thinkingkong 10y agoIf its a static site why do you need react?
- tomelders 10y agoI 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.
- rattray 10y agoSome 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 10y agoWhat 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?
- rattray 10y agoPresumably 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.
- fooey 10y agoThink 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.
- 10y ago
- xrstf 10y agoI'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 10y agoAs 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 10y agoThat'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.
- 10y ago
- snake_case 10y agoI 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
- desireco42 10y agoI 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.
- spdustin 10y agoIt'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 10y agoWell, I suspect user interaction is what it would react to.
- spdustin 10y agoThat'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 10y agoConsider 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 10y agoI 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.
- nilved 10y agoI am so tired of JavaScript. Please stop writing it.
- cjjuice 10y agoOver-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 10y agoDid 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 10y agoHot 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.
- peternicky 10y agoNot sure what your point is since I never claimed react invented hot reloading.
- morgante 10y ago> 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.
- gedy 10y agoWebpack 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-webpack.html http://webpack.github.io/docs/hot-module-replacement-with-we...
- 10y ago
- andreypopp 10y agoAnother 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 10y agoAs someone who is also building a React-based SSG, what do you believe makes sitegen's design superior to other React SSG's?
- shocks 10y agoWill Google index a site built with this?
- rattray 10y agoYes, it generates static HTML pages that work with JavaScript disabled.
- geraldbauer 10y agoLove 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
- eschutte2 10y agoUsed 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.
- ajsharp 10y agoUsing 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 10y agoThe difference being that React is like an industrial factory where HTML is more like building a gokart from a kit. It's just tooling
- greenspot 10y agoOver-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.
- MoOx_ 10y agoI 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/