Gatsby – Static Site Generator with React and Webpack | Hacker News Reader

Gatsby – Static Site Generator with React and Webpack

github.com

88 pointscsbartus38 comments

What are we pulling in such heavy machinery for a text-only site? It's things like this that make people think it's OK to have a blog that isn't accessible without JS which includes so screen readers.

This one is actually Universal ("Isomorphic" if you want), check https://www.reindex.io/ for example.

Interesting. I had expected it to be like bloger that just greets you with a white screen; I didn't see his example blog earlier.

relevant: http://prog21.dadgum.com/130.html

Serious question: Why do screen readers not evolve to run js and build a DOM? (I agree blogs should be accessible to text only UAs)

An even better question: Do screen readers NOT do this? I would be very surprised if they don't. Surely by now screen readers would be based on one of the popular browsers.

Screen readers definitely support Javascript: http://webaim.org/projects/screenreadersurvey5/#javascript

HN had a pretty good convo about accessibility a few years ago where some screen reader dependent community members dispelled the myth once and for all, for me. We tend to talk about screen readers here like they're just `curl example.com | say`.

I've been using http://gohugo.io which has the same live reload feature and is really fast and easy to work with.

The docs page delivered 270kb of compressed and minified JavaScript (1MB uncompressed) but sadly didn't seem to show anything with JavaScript disabled. I thought all the hot new React apps were isomorphic nowadays.

Isomorphic does not mean works without JavaScript. Actually you need JavaScript turned on for isomorphic to work.

On a related topic, I hate the term isomorphic. It's just JavaScript.

You don't need JavaScript if the server can generate all the pages and the links are valid.

It also contains all his blogposts (the bundle.js file). Not good on the long term

Requiring JS to read pages of a static website is nonsensical.

Which is why this tool compiles the pages into static HTML before serving them to the client.

Go ahead, disable javascript and visit any of the example websites.

uh. This just means you end up with inverted PHP. Instead of PHP, where you have a Perl-ish language generating HTML, you now have JS generating HTML. You lose 100% of the benefit of React, which is the virtual DOM. You can literally use any template language you want and achieve identical results here.

I'm not quite sure what your point is.

You say that the only use of react is the virtual DOM, so is it just that React is a poor choice as a template engine? I'm not personally convinced, but that's a bit of personal preference I suppose. The modularization and composability of components is definitely nice, and not all template engines do this well. I could certainly see how you may disagree with me though.

Is it that they aren't doing anything revolutionary? That's certainly true. It's relatively trivial to make a static site generator that uses React, and there's plenty of static site generators out there that use other engines. I think using webpack to bundle everything up is pretty nice though.

Either way, my point wasn't that this project is particularly amazing, or useful, just that it works with JavaScript disabled.

> just that it works with JavaScript disabled

My point is, the whole point of React is to use JavaScript. Otherwise it just becomes yet another template language. Which every static site generator already has.

It's also easy to screw up React and end up with JS on the client side. Because that's the selling point of React (or isomorphic, to be exact)... JS freely travels between backend and frontend without the developer really caring much.

Genuine question, not passive aggression. Why do static site generators always revolve around blogs?

Blogs are around, sure, but they're a bit old-hat now, right? There are other ways to arrange content. I've got my own single-file Python static site generator, which could handle a blog, I guess, but it would seem odd to crown that one application. Is it historical, from Jekyll? Or is blogging the overwhelming use-case for static sites?

While I can only speculate, I would imagine that blogs or blog-like sites are not only the majority use case for static site generators, they also make for a simple and relatable example for demonstrating the capabilities of the generator.

Great question, I'm not sure why media sites aren't all statically generated, would be much more economical if nothing else. Ads can still be dynamically loaded on the client, but content that never changes; why is that in a database?

When you've got multiple authors of varying technical skill, it's probably significantly easier to give them a nice web server backend to interact with than it is to try and teach them how to use the generator.

The backend is irrelevant to the interface the author uses.

But if the author needs to add content, they need to use the generator, if they're using an interface, they're no longer on a static site.

The interface could simply re-generate the static files on save. Movable Type works like this by default.

No, they're in an admin application, which has no reason to be the same "thing" as the site you're authoring.

This is what I'm talking about, people are so engrained in the way things currently work that can't see obvious things like this. It's code, you can do whatever you want.

I think making a desktop application using electron as the basis, and embedding one of the SSGs would be interesting. Are you aware of anything like that?

Closest thing I can think of is Microsoft's WebMatrix.

We're working on an open-source CMS for static site generators at netlify. It's still in beta, but we just opened up the repo here:

https://github.com/netlify/netlify-cms

Since netlify can already run the build of a static site whenever there's a push to git, all the CMS needs to do is manage the content in the Git repository in a user friendly way.

There's absolutely no reason non-technical users shouldn't be able to content just because the end result is not using a database...

It probably has to do with two things: who's building it; and that blogs are both generally non-dynamic and updated frequently.

Gatsby author here: Blogs are basically the TODO app of the static site generator world. They're a simple well-understood pattern that let's someone easily evaluate a new framework.

FYI: I've put together a showcase for static sites [1] at Planet Jekyll. If you browse the listing (a static site itself ;-) you will find project sites, online books, and much more (than just blogs). [1] http://planetjekyll.github.io/showcase

Mind sharing the link for your static site generator?

Thanks for the interest, but it is just a kind of personal hack thing. Just feed pages through markdown and jinja templates.

I do find this annoying -- I use pelican but I'm trying to force it into a non-bloggy layout. You can do it, but it's always pushing a little against default behaviour.

Because "river of content" is still the dominant way of consuming content on the web (Facebook, Twitter), and "blog" is the most popular shorthand for this concept for static sites.

what static site generators out there exists that is easy to setup on a ubuntu server?

It's not like any of them only run on one platform or another.

I'd assume all of them, no? Personally, I prefer Middleman, but of course Jekyll is probably the most popular choice.

Reply on news.ycombinator.com