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

51–60 of 73 posts

Re: Gatsby – A Static Site Generator for React

#51

Post by juandazapata »

morgante wrote: post #41
juandazapata wrote: post #27

Earlier quoted context omitted.

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.

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

Re: Gatsby – A Static Site Generator for React

#52

Post by spdustin »

atoko wrote: post #45
spdustin wrote: post #39

Earlier quoted context omitted.

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 element with an unordered list (or ordered list, if it's more semantically correct) of 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.

Re: Gatsby – A Static Site Generator for React

#53

Post by spdustin »

morgante wrote: post #41
juandazapata wrote: post #27

Earlier quoted context omitted.

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.

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.

Re: Gatsby – A Static Site Generator for React

#54

Post by spdustin »

biscarch wrote: post #47
tptacek wrote: post #5

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.

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.

Re: Gatsby – A Static Site Generator for React

#55

Post by spdustin »

atoko wrote: post #45
spdustin wrote: post #39

Earlier quoted context omitted.

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.

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.

Re: Gatsby – A Static Site Generator for React

#56

Post by morgante »

spdustin wrote: post #53
morgante wrote: post #41

Earlier quoted context omitted.

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

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

Re: Gatsby – A Static Site Generator for React

#57

Post by savolai »

rattray wrote: post #22
rattray wrote: post #21

Earlier quoted context omitted.

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 peli…

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.

Re: Gatsby – A Static Site Generator for React

#58

Post by jamra »

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…

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.

Re: Gatsby – A Static Site Generator for React

#59

Post by dmix »

maerek wrote: post #34
dmix wrote: post #24

Earlier quoted context omitted.

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…

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.

Is that not a rewording of what I just said?

Re: Gatsby – A Static Site Generator for React

#60

Post by armandososa »

juandazapata wrote: post #27
peternicky wrote: post #20

Earlier quoted context omitted.

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.

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