Gatsby – A Static Site Generator for React
github.com
github.com
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.
From testing out one of the example blogs and this doesn't seem to be a UX issue:
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.
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.
For fancy marketing sites I get it immediately, I guess.
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.
I'm a little confused about no page transitions. I don't know why that is a problem that needs solving. Also hot reloading.
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."
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.
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.
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.
Secondly, it also allows you to progressively enhance the static site easily if you want to in the future.
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.
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.
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.
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.
Reacting to a user event doesn't mean it's a "reactive UI", every UI is a reactive one by that definition.
Supports pagination and progressive content loading, I believe its design is superior to other React based static site generators.
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.
PS: You can find the Gatsby Stay Static Sample Site @ http://staystatic.github.io/sites/gatsby and sources -> https://github.com/staystatic/gatsby
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.
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.
Eagerly awaiting attacks on the car simile. Go.
It's just tooling
One thing I wish was easier was disabling the whole react-router part and just outputting standalone pages.
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/
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.
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 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.
React is great for some applications, IMO this is not one of them. To me it just over complicates things for minimal gain.
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.
http://webpack.github.io/docs/hot-module-replacement-with-we...
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.
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.
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.
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'm also curious how the code complexity for this compares to tools like pelican, Jekyll, etc.