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.
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.
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`.
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.
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.
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.
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.
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?
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...
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
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.
38 comments
[ 2.9 ms ] story [ 75.4 ms ] threadHN 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`.
On a related topic, I hate the term isomorphic. It's just JavaScript.
Go ahead, disable javascript and visit any of the example websites.
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.
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.
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?
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.
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...