Many developers have written about ditching a CMS-like thing for a static site generator for their own personal use. I've done it too, it's great!
Is there anybody who's had a good experience getting less technical partners/colleagues/clients to do the same, possibly with something like the GitHub file editor and continuous deployment?
I think there's a big future for static site generators (that's why I'm building BitBalloon https://www.BitBalloon.com), but the big hurdle for using them for projects for clients is the lack of browser based admin tools.
Stuff like prose.io goes some of the way, but for most users even WordPress requires training, and showing them the raw filesystem is gonna be way to geeky in many cases.
Would love to talk to anyone interested in building a great open source admin panel for a static site generator.
I put together a sort-of static site generator for my own purposes called, originally enough, "sites"[1]. It is really just a front-end for GitHub's open source git-backed wiki system, but it works well.
I've been thinking about leveraging existing open source interfaces for static site generation, creating something between a full cached (Varnish, etc) interface to a dynamic site and generating each page on the fly. So rather than have Wordpress or Drupal or some such thing generate the full site the new post is dumped into the existing static site generator and a site generation pass is triggered.
I'd prefer to retain some dynamic site features like commenting, discussion, and form submission. While there are very successful companies that outsource these features I prefer to have the option to take ownership and control of my content. So I'm envisioning the only dynamic part of the site besides the admin interface is an API to enable these (and more) features. Depending on design and the type of interaction these could trigger a page or site rebuild or update a Javascript framework on the page to reflect the new comment, the successful form posting that updates a calendar, etc.
I wrote a project proposal back in 2010 for something like this. Essentially the key is to turn site updates from being GET-driven to being PUSH-driven.
It could be interesting for deploying small presentation websites for clients. I think editing a file on your computer, using a Markdown editor for example, to change the text for a page, would be more intuitive and practical than editing the text in a web form.
Although I haven't tried getting a nontechnical user to try it, I spent some time doing just that for my personal site (editing an Octopress blog on Github, with a continuous deployment server compiling it), and I didn't like it. The whole setup felt very fragile, it was impossible to write drafts (I would compose drafts as text files on my local machine), and in the end the Github editor simply leaves somethin to be desired when it comes to UX for blog-post-writing.
A better solution would be to have a raw Jekyll blog on github that you can edit directly, no special setup necessary.
An even better solution (imo) is to have a blog set-up with continuous deployment, and let the user edit the content in a nice local text editor via SFTP.
Yes, it’s not really a fair comparison, I also changed the theme to a much simpler one which is a big boost too, but still.
But still nothing. Comparing a page that is 15% the size of the original is ridiculous. I'm left wondering what happens to the page loads on a WordPress site if you reduced the overall size and number of requests.
Rather than adapting the existing Wordpress theme to Pelican I decided it would be better to just start from an existing Pelican theme, the article wasn't meant to be a benchmark.
imho static page generating sites is optimizing at the wrong level. That's what app caching, caching servers and CDNs and such are for. Static page generation like this is ok at a very small level/scale but doesn't scale use wise. You cannot build interesting big dynamic sites with it. So I guess for a blog fine, but, not for me thanks
i don't think speed is the only issue. The steps for testing and toying around a theme in wordpress is always a pain : The personn starts by installing wordpress and a fancy theme on its computer, or on some random server, starts putting content, then wants to migrate all this on some "production" server.
Then, most of time, they end up spending an awful lot of time with the wordpress export/import tools (which is made even worse once you starting using payed plugins). Which sometimes involves looking at random php errors.
Compare that with copy / pasting a bunch of file via ftp, and then you're done.
+1. Security is a big issue too, and much minimized when you're serving static pages. It's not just "for a blog, fine", it's more like, "for a blog, optimal".
I use Pelican for my personal site as well, and to me the big advantage is not performance, but security and easy of hosting. A static site has basically no attack surface, and can be hosted on free or cheap hosts like Github Pages or http://www.nearlyfreespeech.net.
Of course, your concern is valid: I don't think anyone recommends using a static content generator except for sites that consist primarily of static content. Obviously if you want richly dynamic content, a static site generator is not for you. On the other hand, if your site is primarily static, why use a dynamic system that introduces additional overhead?
Static generators are useful for quick, very low maintenance products with limited out-of-box features that are not very extensible. Most people probably want just that - they want to create content and don't give a damn to add fancy new geeky feature on their blogs or whatever. You would hit a wall sooner or later if you do try to do something more. For example, how do you generate pages that return posts per category or date range. How about automatic page of "Popular Posts"? Technically you can but it would be lot of duplication and bit of a mess.
The problem is that while that while static page generation is definitely the best fit for what most people need, it is not the best fit for what they think they need. One of the big reasons WordPress was able to dethrone Movable Type as the #1 blog software was precisely because of its dynamic pages -- that was a big point of attraction for people over MT's static page generation approach. So much so that Movable Type's developers eventually felt the need to graft a half-baked dynamic page system onto their product, just so they could tell people who wanted dynamic pages that they shouldn't rule out MT altogether. (It didn't help in the end, but the fact that they felt they had to do it at all speaks volumes.)
Why do they think they need dynamic pages? The upsides of dynamic pages (no more waiting for pages to rebuild) are right there in their face, while the downsides (your server falling over if you get more than three readers at a time) don't become evident for a while. So to non-technical folks, dynamic pages seems like a no-brainer. They don't learn the downsides until they leap up and bite them.
This mismatch between what people think they want and what they actually really should want based on their needs is sadly quite common in tech products, and explains how a lot of crappy products managed to become more popular than a techie would ever have expected them to be.
Client side JavasScript, all you need is a json document and a lot of heavy lifting on the client. Not a good solution for sites with a lot of content, but for the simpler ones... yeah. You won't get search, but still... For things like `popular posts`, you could probably have a task that queried your analytics data and generated a page. Once tasks are automated, it's not that much of a hassle. CMSs will still have much more to give though.
Pelican (and most other static site generators AFAIK) will automatically generate lists by category/tag as well as by date. "Popular posts" would be a bit trickier, because you can't just bump a counter in a database on every hit. You can get the same info from web server logs, or via an external analytics service, or do without. Not everyone automatically considers a website to be a "product" that requires every bell and whistle. Using a Mini to haul cargo is almost as silly as using a semi for your commute.
For someone writing a personal blog, who wants a minimal attack surface and minimal resource usage per hit on any access pattern (not just the easily cacheable ones), with minimal hassle, Pelican and its friends can suit quite well. I ran Wordpress for years and years. I got tired of hearing about a new zero-day total-compromise exploit forcing me to upgrade every week. I got tired of tweaking Varnish or any other caching solution all the time, and none of them ever getting proper ETag/If-None-Since behavior. If I needed a full-fledged "product" solution I might have moved up to something like Drupal or Django. Instead I moved down to Pelican. Maintaining my 14-year-old blog is just less annoying now.
Wordpress is simple, but not low-maintenance. It's an important distinction. Most programmers, and I think most writers too, don't need an idiot-friendly UI so much as they need something that Just Works and Just Keeps Working.
But many people have to deal with small amounts of data. Consider all the WordPress blogs there are on the Internet that will be set up and used by one person.
Interestingly, his first reason / argument to switch was about having the content locally and being able to use markdown.
I like the idea of storing the content in an version control system. I think it would be great for sites like gwern.com.
But still: if you don't have much content you will get speed and security practicality for free.
I'd have to disagree. For instance at my old job for several years they ran a large news site (10M+ monthly) on Escenic (http://www.vizrt.com/products/vizrt_online_suite/), which is essentially a static site generator - user content pages is all pre-generated. That's a $xxx,000 enterprise product that was used by (at the time) the newspaper arm of Cox to run a few thousand websites.
For me, the site's latency is not the issue. I find myself pulling my hair out trying to make the Wordpress admin area work the way I want it to work. If I can just stay in vim, I am a happy camper. If you force me into some WYSIWYG editor inside of an admin panel, I am going to get frustrated.
I hear ya. I work in VIM and the command line all day too and for a simple blog I can see the frustration with the WYSIWYG editor. That won't fly with a marketing team of a couple inbound marketing experts though.
WordPress does have a Command Line Interface and you can in fact write to a text file and import it as a new blog Post:
You can actually do a ton with it. I don't know how familiar you are with WordPress but with CLI you can upgrade WP core, update/add/activate/deactivate plugins, and much more with it:
People don't use static site generators to simply avoid having to set up caching.
They use them for their simplicity and flexibilty. You can edit the posts anywhere, even when not connected to the net. You can use your favorite text editor to edit them. You don't need to worry about upgrading your blog engine to patch out the latest security vulnerabilities. If you later decide to change markup formats, or templating systems, or change your blog engine entirely, you don't need to decide between importing your content into the new one (which is generally a messy and lossy process) or running an outdated one which you still need to keep security updates on or being exploited; you just leave your old static files alone, and use your new generator or blog engine or whatnot for the new content.
It's obviously not appropriate for every use case; if your data really needs to be dynamic, then it doesn't help. But there are plenty of reasons to use it beyond just efficiency, and even there, it makes getting those efficiency gains a lot easier than a dynamic site does.
Conflicted. On one hand, we have a camp of people who would say "static content" almost always equals garbage content. Documentation aside, who would ever want a static website? I don't see much advantage of having to setup environment, ensure libraries are installed, etc. – every time you want to do a simple change from a computer other than your own. I'll take WordPress over that any day.
Scenario: You just noticed a major typo on your new, statically generated microsite - using Markdown, pelican, etc. ...but the only computer you have access to is running a fresh copy of Windows 8.
Eh. You can do something like set up a github repo with a webhook, such that every time you commit it just triggers a rebuild. Bam, instant web UI. Not the best, but yeah ...
> Documentation aside, who would ever want a static website?
Who would want a non-static website? I look at, say, gwern.net, and think: this is what blogs want to be, if we only took the time to categorize and have a sensible front page. The current "stream of posts" paradigm discourages you from polishing and improving your posts, and makes it hard to find anything older than a week or two.
> I don't see much advantage of having to pre-setup your environment, ensure libraries are as required – every time you want to do a simple change from a computer other than your own?
It's 2013; there's really no excuse for not having an easy way to set up your environment (i.e. pip+virtualenv in this case).
This only works if you are the only author/contributor. The technical expertise required to update a simple page is not within the wheelhouse of the average user.
The article proposes dropping WordPress in favour of Pelican. WordPress is known for its accessibility to the average user, so my argument is simply: How is this making content accessible, easy to update? Insofar of the environment, technical expertise required, WordPress wins hands down.
Nobody (or at least me) is saying that. But static blogs have other benefits, like being lighter on your host or allowing you to create a new post by just editing a text file in your favorite markup language.
Or just plug your USB key in with PuTTY Portable and FileZilla installed on it. If the static site generator tools run on Windows, we could probably make those portable, too.
> Scenario: You just noticed a major typo on your new, statically generated microsite - using Markdown, pelican, etc. ...but the only computer you have access to is running a fresh copy of Windows 8.
Could also be running a fresh HaikuOS version.
If it's flatfile you update via ftp or direct shell access or some magic git recipe. I fail to see how running win8 prevents that. Moreover, if it's a fresh win8 installation you don't have that long random password in your head to log into your wordpress site anyway. Just a scenario.
I feel like my response to this article would have been different if it read: "Ditch WordPress. X combines Pelican, and a kick-ass control panel that installs on any computer in 30 seconds."
I'm not against Pelican, I'm against the idea that this is somehow easier than WordPress. Adding a control panel that allows average people to edit content (Markdown or WYSIWYG, etc.). An installer that takes care of all the necessary required libraries, goes through steps to creating a scaffold, etc.
>Conflicted. On one hand, we have a camp of people who would say "static content" almost always equals garbage content. Documentation aside, who would ever want a static website?
Huh? I'm not even sure what "static" means in your use of the word. Who said that "static content almost always equals garbage content"?
Never ever heard such a thing, and doesn't even make sense.
>Scenario: You just noticed a major typo on your new, statically generated microsite - using Markdown, pelican, etc. ...but the only computer you have access to is running a fresh copy of Windows 8.
You know that you could ssh to the server directly, right? -- and have it set up to rebuild after you change a text file.
Plus it's not like it's any great emergency to correct a typo from Nepal or wherever you are without your laptop.
> You know that you could ssh to the server directly, right? -- and have it set up to rebuild after you change a text file.
All of the replies to my comment are coming from someone with higher than average technical expertise. Say what you will about WordPress, but what is being proposed here is not an accessible experience. It's downright repulsive to someone without the technical requirements to simply publish a blog post.
The (albeit, poorly contextualized) point that I was trying to make is, that you, the guy with the technical expertise can update the website. No one else can.
This square-in-a-round-hole argument is brought to you by ego (NIH, small unmaintained websites, etc.), not a strive to make content easier to publish, easier to maintain.
If the only author in mind is yourself, then ya, it works. Beyond that? As soon as you add another contributor, the complexity of updating the website skyrockets.
I don't even use a site generator. I just edit the html directly via ssh. I use putty from win machines, ssh from nix machines, and connectbot on android (with Hacker'S Keyboard).
Once there, I use nano, it's fine for editing small text files.
the VPS I'm on costs $10/month, but you can get them for $15 a year. Yes, I've had to learn how to use debian from command-line, but I am very, very glad I know how now.
If you want, you can use a sftp-capable text editor, and that works too. I used to use jEdit, but it's not installed everywhere, and it's definitely not installed on my smart phone, so...
Also, for those who complain that the site looks like 1993, that's intended, as it looks fine and loads very fast in mobile, and that's essentially my only target platform.
I have some static sites I build with Nanoc. The source content is mostly HTML with a sprinkling of ERB.
I could do all of it by hand, but using a SSG lets me factor out a lot of repetitive scut work. For example, I have a function that takes a hash and builds the HTML for a collection of references. Doing it by hand would be time consuming and error-prone.
More obviously, when I update my page layouts, it happens across the whole site. I don't have to go around copying and pasting, again introducing more busy work with room for error.
"What about grep and sed?", I hear you ask. By the time I'm building ad hoc build pipelines each time I fiddle with the site, I once again introduce new opportunities for error. Why not just automate the whole pile of wax and be done with it?
About updates to the site layout, I've come to the realization that the site doesn't need to have a uniform look and feel for the whole site, or sections of the site. I came to the understanding that each page can do, can be, what it needs to be. Plain html5 (no css, no js) is enough for my needs, and each page is customized for its own purpose.
I have a crumbs navigation at top, that may go away too. most people (99.9% i think) navigate forward, then use the back key in the browser to go back, so I may get rid of the crumbs someday.
each page on the site is accessible from the whole internet. If Joe the poet links to a page on my site, essentially, my page becomes part of the web experience Joe is building. I want to show respect to Joe, and not suck in his readers into my own site. if people want to get to the root of my site, they already know how to edit the uri down to the domain name.
Just a heads up the link in your profile appears to have a typo in it :)
Confirming your site makes the majority of minimalist themes look bloated! I'm probably just used to things being more central but I think the only issue I had with the site was the extreme left alignment :)
(fixed the link... do'h, my bad...)
there's not much I can do on the margin-left without introducing css. (i leave javascript and css out--makes the site faster).
Please go to the writing section and look at one of the stories and one poem to see if the left alignment still bothers you after. I think e-book readers left align as much.
Thanks for the compliment!
(ultimately, I go for separation of concerns: the server serves content, the browser renders. people can set font size, etc to suit themselves).
I'm in a really similar situation to the author's. I've been using WordPress for quite a long time, among several (usually shared) hostings, only to realize how disgusting it is to move a WordPress website from one place to another. With Pelican I can have the entire source of my website in Dropbox or a pendrive, and edit the articles in Markdown anywhere.
Lately I had been all the cool kids using Octopress, but I don't like Ruby, not to mention its programming environment (installing rvm, for example). Also, Octopress's default theme is a total mess. I love Python, so Pelican is a total win for me.
If your readers make thought out comments you value, then you probaby wouldn't want to not hand those over to third parties. If the comment section is just for people to "feel engaged", but otherwise worthless to you, sure.
> only to realize how disgusting it is to move a WordPress website from one place to another
What? If the domain is staying the same, it's dead simple: move your database and files. If not, it's one step short of dead simple. There are also plugins that handle both cases even more easily if you don't want to move the stuff manually.
I'm curious, what would you need to do an actual find-and-replace on the DB dump for? Are you talking about looking for places in your content where you've hardcoded your old URL?
That's some sweet loading time. Thank you for the tips and pointers in the article, having a go at page load optimizations is what I'm going to do next.
I, too, migrated from Wordpress to Pelican (http://calebmadrigal.com). I love not having all of my content inside of MySQL tables. I also love writing in Markdown in vim instead of the Wordpress editor.
I started hacking that theme too, and then I realized that it may be difficult to merge efforts if I build what I want. I think it would help a lot if Pelican had theme inheritance ( https://github.com/getpelican/pelican/issues/1092 ) and we all reused a common PureCSS base-theme. This is probably an easy issue to tackle for a skilled Python coder.
I really like Pelican. I think a lot of people commenting here are missing the point about why some people would want a static site. It's not really about performance, it's about simplicity. It's trivial to set up a web server to serve static HTML pages. All I needed was Apache, SSH, and rsync. I keep all of my blog posts in ReStructuredText files which are stored in a git repository. When I want to publish, it's as simple as `make rsync_upload` and I'm done. No database, no web interface for managing content. Just plain text and command line tools.
I am having one small issue with Pelican, though. When I change my theme from the default, it uses the new theme's templates but the default theme's stylesheet. As expected, the result is awful. Has anyone else experienced this issue?
the major issue still remains that you're hosting comments externally. when this is the case you could also have whatever free service handle the site entirely.
whats missing for larger adoption of generators is a super simple comment engine that just work and that you can host. there are some but they aint convincing.
1. I try to learn to use Octopress, it should be simpler to set-up than Jekyll as it comes with a theme and a sensible config by default.
2. Sure you can, Adsense is loaded via client-side via javascript so all you have to do is embed the javascript in your templates.
It's a common term for a bicycle without the ability to change gears; a fixed gear (aka fixie). They generally are low maintenance and simple to repair. I think he's making an analogy that static sites are also low maintenance and easy to repair.
They're both hipster status symbols, and purely functional through their simplicity and ease to maintain. Very few moving parts, yet a way to show you appreciation for simplistic design while simultaneously very easy to customize.. It's a pretty good analogy I think.
A fixie is one that runs with a fixed gearing (without a freehub [0]. When the wheels turn the pedals must turn. many hipsters also run them without brakes which requires them to use their legs to slow the bike. these are most commonly seen on velodromes and anywhere with lots of coffee shops.
My sister has an old mountain bike that she only ever rides in first gear. I assume it's first because she told me she leaves it in "whatever the lowest one is." She is the intended market for a fixed-gear bike (or "fixie").
People who advocate the use of static sites are the ones who simply don't have a use for the features of more complex CMSes or blogging platforms. A dynamically-generated site is overkill for their writing in the same way that a mountain bike is overkill for my sister getting to work.
I finally got tired of the pain of hosting my own Wordpress-backed blog a few months back and made the switch to Pelican. Here's a post detailing my overwhelmingly positive experience so far:
82 comments
[ 2.0 ms ] story [ 161 ms ] threadIs there anybody who's had a good experience getting less technical partners/colleagues/clients to do the same, possibly with something like the GitHub file editor and continuous deployment?
Stuff like prose.io goes some of the way, but for most users even WordPress requires training, and showing them the raw filesystem is gonna be way to geeky in many cases.
Would love to talk to anyone interested in building a great open source admin panel for a static site generator.
[1]: https://github.com/peterkeen/sites
I'd prefer to retain some dynamic site features like commenting, discussion, and form submission. While there are very successful companies that outsource these features I prefer to have the option to take ownership and control of my content. So I'm envisioning the only dynamic part of the site besides the admin interface is an API to enable these (and more) features. Depending on design and the type of interaction these could trigger a page or site rebuild or update a Javascript framework on the page to reflect the new comment, the successful form posting that updates a calendar, etc.
I'm working on a Admin/CMS Editor for Harp http://harpjs.com
MIT, Open source of course.
A better solution would be to have a raw Jekyll blog on github that you can edit directly, no special setup necessary.
An even better solution (imo) is to have a blog set-up with continuous deployment, and let the user edit the content in a nice local text editor via SFTP.
And it's much more visual experience and GUI experience than writing in a notepad app and "compiling" the site.
But still nothing. Comparing a page that is 15% the size of the original is ridiculous. I'm left wondering what happens to the page loads on a WordPress site if you reduced the overall size and number of requests.
Then, most of time, they end up spending an awful lot of time with the wordpress export/import tools (which is made even worse once you starting using payed plugins). Which sometimes involves looking at random php errors.
Compare that with copy / pasting a bunch of file via ftp, and then you're done.
and it works for backups too...
And conflating "interesting" with "dynamic" is rather dubious to me as well.
Of course, your concern is valid: I don't think anyone recommends using a static content generator except for sites that consist primarily of static content. Obviously if you want richly dynamic content, a static site generator is not for you. On the other hand, if your site is primarily static, why use a dynamic system that introduces additional overhead?
Why do they think they need dynamic pages? The upsides of dynamic pages (no more waiting for pages to rebuild) are right there in their face, while the downsides (your server falling over if you get more than three readers at a time) don't become evident for a while. So to non-technical folks, dynamic pages seems like a no-brainer. They don't learn the downsides until they leap up and bite them.
This mismatch between what people think they want and what they actually really should want based on their needs is sadly quite common in tech products, and explains how a lot of crappy products managed to become more popular than a techie would ever have expected them to be.
For someone writing a personal blog, who wants a minimal attack surface and minimal resource usage per hit on any access pattern (not just the easily cacheable ones), with minimal hassle, Pelican and its friends can suit quite well. I ran Wordpress for years and years. I got tired of hearing about a new zero-day total-compromise exploit forcing me to upgrade every week. I got tired of tweaking Varnish or any other caching solution all the time, and none of them ever getting proper ETag/If-None-Since behavior. If I needed a full-fledged "product" solution I might have moved up to something like Drupal or Django. Instead I moved down to Pelican. Maintaining my 14-year-old blog is just less annoying now.
Wordpress is simple, but not low-maintenance. It's an important distinction. Most programmers, and I think most writers too, don't need an idiot-friendly UI so much as they need something that Just Works and Just Keeps Working.
Interestingly, his first reason / argument to switch was about having the content locally and being able to use markdown.
I like the idea of storing the content in an version control system. I think it would be great for sites like gwern.com.
But still: if you don't have much content you will get speed and security practicality for free.
WordPress does have a Command Line Interface and you can in fact write to a text file and import it as a new blog Post:
- http://wp-cli.org/commands/post/create/
You can actually do a ton with it. I don't know how familiar you are with WordPress but with CLI you can upgrade WP core, update/add/activate/deactivate plugins, and much more with it:
- http://wp-cli.org/
It's a nice tool for WordPress developers that want to bypass going through the admin panel.
They use them for their simplicity and flexibilty. You can edit the posts anywhere, even when not connected to the net. You can use your favorite text editor to edit them. You don't need to worry about upgrading your blog engine to patch out the latest security vulnerabilities. If you later decide to change markup formats, or templating systems, or change your blog engine entirely, you don't need to decide between importing your content into the new one (which is generally a messy and lossy process) or running an outdated one which you still need to keep security updates on or being exploited; you just leave your old static files alone, and use your new generator or blog engine or whatnot for the new content.
It's obviously not appropriate for every use case; if your data really needs to be dynamic, then it doesn't help. But there are plenty of reasons to use it beyond just efficiency, and even there, it makes getting those efficiency gains a lot easier than a dynamic site does.
Scenario: You just noticed a major typo on your new, statically generated microsite - using Markdown, pelican, etc. ...but the only computer you have access to is running a fresh copy of Windows 8.
Talk about your non-portable website.
https://www.bitballoon.com/blog/2013/12/13/continous-deploym...
The same technique would work for any static site generator.
Who would want a non-static website? I look at, say, gwern.net, and think: this is what blogs want to be, if we only took the time to categorize and have a sensible front page. The current "stream of posts" paradigm discourages you from polishing and improving your posts, and makes it hard to find anything older than a week or two.
> I don't see much advantage of having to pre-setup your environment, ensure libraries are as required – every time you want to do a simple change from a computer other than your own?
It's 2013; there's really no excuse for not having an easy way to set up your environment (i.e. pip+virtualenv in this case).
The article proposes dropping WordPress in favour of Pelican. WordPress is known for its accessibility to the average user, so my argument is simply: How is this making content accessible, easy to update? Insofar of the environment, technical expertise required, WordPress wins hands down.
Then fixing a typo would be only a matter of SSH-ing into your server.
Nobody (or at least me) is saying that. But static blogs have other benefits, like being lighter on your host or allowing you to create a new post by just editing a text file in your favorite markup language.
It's safer than typing credentials in an untrusted computer anyways.
Could also be running a fresh HaikuOS version.
If it's flatfile you update via ftp or direct shell access or some magic git recipe. I fail to see how running win8 prevents that. Moreover, if it's a fresh win8 installation you don't have that long random password in your head to log into your wordpress site anyway. Just a scenario.
I'm not against Pelican, I'm against the idea that this is somehow easier than WordPress. Adding a control panel that allows average people to edit content (Markdown or WYSIWYG, etc.). An installer that takes care of all the necessary required libraries, goes through steps to creating a scaffold, etc.
Then you can compare it to WordPress.
Huh? I'm not even sure what "static" means in your use of the word. Who said that "static content almost always equals garbage content"?
Never ever heard such a thing, and doesn't even make sense.
>Scenario: You just noticed a major typo on your new, statically generated microsite - using Markdown, pelican, etc. ...but the only computer you have access to is running a fresh copy of Windows 8.
You know that you could ssh to the server directly, right? -- and have it set up to rebuild after you change a text file.
Plus it's not like it's any great emergency to correct a typo from Nepal or wherever you are without your laptop.
All of the replies to my comment are coming from someone with higher than average technical expertise. Say what you will about WordPress, but what is being proposed here is not an accessible experience. It's downright repulsive to someone without the technical requirements to simply publish a blog post.
The (albeit, poorly contextualized) point that I was trying to make is, that you, the guy with the technical expertise can update the website. No one else can.
This square-in-a-round-hole argument is brought to you by ego (NIH, small unmaintained websites, etc.), not a strive to make content easier to publish, easier to maintain.
If the only author in mind is yourself, then ya, it works. Beyond that? As soon as you add another contributor, the complexity of updating the website skyrockets.
This is Hacker News. We don't discuss from the point of view of someone who doesn't know these things.
The WordPress and Hacker News audiences are different, too, yet here we are comparing WordPress to a static site generator.
Any compelling reason for me to consider switching, features that Pelican has which Hyde lacks?
Once there, I use nano, it's fine for editing small text files.
the VPS I'm on costs $10/month, but you can get them for $15 a year. Yes, I've had to learn how to use debian from command-line, but I am very, very glad I know how now.
If you want, you can use a sftp-capable text editor, and that works too. I used to use jEdit, but it's not installed everywhere, and it's definitely not installed on my smart phone, so...
Also, for those who complain that the site looks like 1993, that's intended, as it looks fine and loads very fast in mobile, and that's essentially my only target platform.
I could do all of it by hand, but using a SSG lets me factor out a lot of repetitive scut work. For example, I have a function that takes a hash and builds the HTML for a collection of references. Doing it by hand would be time consuming and error-prone.
More obviously, when I update my page layouts, it happens across the whole site. I don't have to go around copying and pasting, again introducing more busy work with room for error.
"What about grep and sed?", I hear you ask. By the time I'm building ad hoc build pipelines each time I fiddle with the site, I once again introduce new opportunities for error. Why not just automate the whole pile of wax and be done with it?
I have a crumbs navigation at top, that may go away too. most people (99.9% i think) navigate forward, then use the back key in the browser to go back, so I may get rid of the crumbs someday.
each page on the site is accessible from the whole internet. If Joe the poet links to a page on my site, essentially, my page becomes part of the web experience Joe is building. I want to show respect to Joe, and not suck in his readers into my own site. if people want to get to the root of my site, they already know how to edit the uri down to the domain name.
(sorry for philisophizing! )
Confirming your site makes the majority of minimalist themes look bloated! I'm probably just used to things being more central but I think the only issue I had with the site was the extreme left alignment :)
Thanks for the compliment!
(ultimately, I go for separation of concerns: the server serves content, the browser renders. people can set font size, etc to suit themselves).
Lately I had been all the cool kids using Octopress, but I don't like Ruby, not to mention its programming environment (installing rvm, for example). Also, Octopress's default theme is a total mess. I love Python, so Pelican is a total win for me.
What? If the domain is staying the same, it's dead simple: move your database and files. If not, it's one step short of dead simple. There are also plugins that handle both cases even more easily if you don't want to move the stuff manually.
You can see that there's virtually no difference from your static blog.
For me the main selling point of Pelican is the Markdown syntax and the ease of running it on any host. I hear some even run it from Dropbox.
On a side note: where can I fork and improve on your theme? :)
It's at https://github.com/razius/razius.com/tree/master/theme , which is a modified version of https://github.com/danclaudiupop/pure . The underlying framework is http://purecss.io , and a lot is possible with it.
I started hacking that theme too, and then I realized that it may be difficult to merge efforts if I build what I want. I think it would help a lot if Pelican had theme inheritance ( https://github.com/getpelican/pelican/issues/1092 ) and we all reused a common PureCSS base-theme. This is probably an easy issue to tackle for a skilled Python coder.
I am having one small issue with Pelican, though. When I change my theme from the default, it uses the new theme's templates but the default theme's stylesheet. As expected, the result is awful. Has anyone else experienced this issue?
whats missing for larger adoption of generators is a super simple comment engine that just work and that you can host. there are some but they aint convincing.
Unless the mess of code under the bonnet of Wordpress is a concern and you want more flexibility in controlling it then I see your decision as sound.
However it is hard to beat Wordpress's extensibility and ease of use for publishing content online.
2. Can you use Adsense with Github Pages?
In the words of Paul Graham - "Static sites are the fixies of the Internet."[0]
[0] https://twitter.com/paulg/status/402205795552489472
A fixie is one that runs with a fixed gearing (without a freehub [0]. When the wheels turn the pedals must turn. many hipsters also run them without brakes which requires them to use their legs to slow the bike. these are most commonly seen on velodromes and anywhere with lots of coffee shops.
[0] http://en.wikipedia.org/wiki/Freehub
People who advocate the use of static sites are the ones who simply don't have a use for the features of more complex CMSes or blogging platforms. A dynamically-generated site is overkill for their writing in the same way that a mountain bike is overkill for my sister getting to work.
http://jimter.net/switching-the-jimternet-from-wordpress-to-...