Middleman has a little known WYSIWYG blog editor extension that focuses on easy content creation and editing. It is a paid extension but it does address the points raised in the article http://middleman-blog-editor.awardwinningfjords.com
Static site generators focus on the wrong thing
11–20 of 100 posts
Re: Static site generators focus on the wrong thing
#12This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…
You can get the best of both by using a dynamic site CMS, and then hooking it up to Amazon Cloudfront to cache your html. The only challenge then is page cache expiration. You can set that by either using the http headers for Cache-Control or setting page rules in Cloudfront's admin.
Such a setup will scale like crazy and skip "compilation" steps
Re: Static site generators focus on the wrong thing
#13This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…
> "live pages" equals "lots of hits to the database"
Is it common for people to set up a database backed website without caching? The framework I'm most familiar with, Django, will cache the results of database queries, so if, say, an article on the site becomes popular the database is hit once, and thousands of views are served from the cache.
Edit: Jweb_Guru, thanks for that clarification.
Re: Static site generators focus on the wrong thing
#14Medium is NOT a blogging platform, contrary to popular belief. Blogging is owning your content, and when you write for Mediium, make no mistake, it belongs to Medium. Although, I just switched over from Wordpress to Jekyll, and I find it there to be a lot less friction for publishing. I talked more about the new and exciting workflow of Jekyll at http://rmorabia.com/redesign I really don't agree with the author here.…
I invite you to glance over the Medium Terms of Service. "You own the rights to the content you post on Medium."
Re: Static site generators focus on the wrong thing
#15This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…
I agree with what you are saying, and I think this is perhaps the most important tradeoff that many CMS designs do not deal with properly.
This is particularly true of the current plethora of 'static site generators', many of which are not really improvements in any aspect.
If you build a static site, you can concentrate on making sure a rebuild is quick; if you build a dynamic site, you can concentrate on making sure the data structure is robust to scaling.
You might never be without these problems, but you can minimise them to the extent that they are no longer costing your users excessively.
It's not that we need to go back and forth: either solution could work perfectly fine for all but the heaviest sites.
Re: Static site generators focus on the wrong thing
#16The activity most likely to lead to more blogging is "more writing". Its easy to blame the CMS/Blogging tool/SSG, etc., but really - those who write, will.
Re: Static site generators focus on the wrong thing
#17Sure, but they're not called static blog generators, they're static site generators. They are specifically for people who want static sites, not specifically people who want frictionless blogging.
I believe most static site generators are "blog oriented". And a blog is still a website.
Re: Static site generators focus on the wrong thing
#18It's hard to either agree or disagree with the author here...because it depends on what your definition of "blogger" is.
For most of the technically-inclined, the bottleneck is the writing process. The friction in the commandline-compile-and-push stage seems to me like a minor concern...because if it took you 20min. to 20 hours to write the post, what difference does it make that it then takes 1 or even 10 minutes to push the post to S3?
And consider one of the benefits of most static blogging implementations, in which the writer can choose his/her text-editor of choice, which is especially useful if you are using Markdown? Another useful feature is that with all of the blog posts hosted as flat files, you can easily grep/replace across an entire folder or even all of your posts, in a way that is significantly more difficult in a database-backed site, in which you have to destructure the schema.
What kind of idiot blogger would put something in a bunch of posts only to later decide to grep/replace it all?...well, it could be something as simple as someone wanting to add affiliate links to all their existing URL references to Amazon pages? Or it doesn't have to be a replace function...sometimes I want to use grep to find terms/concepts I've blogged about before (most search utilities on dynamic blogs do not support regex).
My main blog is a self-hosted WordPress site. I'm OK with it but I find that there's a lot of friction to just build out a post. This is my workflow:
1. Draft and write a post in Sublime Text and Markdown
2. Convert to HTML (self-hosted Wordpress does not yet have a Markdown editor, and I'm loathe to install a plugin)
3. Paste HTML into WordPress body
4. Hit Publish
Simple enough, but it's almost never the case that my text is perfect...and so now I have to either go back to the original Markdown file and restart the steps, or edit the WordPress textbox which means that my canonical version of the text now exists on WordPress.
And did I mention that WP is dog slow on shared hosting? I've setup caching, which has allowed my site to stand up to the Reddit and HN front pages, but when I'm editing/adding content, it can take 5 to 10 seconds to move between the admin pages.
All of this friction means that I rarely update my own blog, even though I have dozens of draft posts in my Dropbox in Markdown format...most of that is because I just don't finish those drafts, but some of that negligence is because the thought of logging into WordPress and going through the process of simply publishing is enough to put me off.
On the other hand, I use Tumblr on a very regular basis, even though it's simply to post photos and captions. Yes, part of my ease here is because I'm just posting photos, but Tumblr's relative speed makes it a service I want to post photos to...And of course, the tradeoff is now Tumblr owns all of my content and I have an even harder time mass-managing it.
So it's all tradeoffs...the OP is right, but not right for many of the kinds of people who have the expertise to build and deploy a static site.
Re: Static site generators focus on the wrong thing
#19If your jekyll generation time is getting too large, you can limit the number of posts it generates like this:
jekyll --limit_posts 3
http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....
Re: Static site generators focus on the wrong thing
#20This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…
I'm working on a new version of Gus[0] that will be able to figure out only what needs to be rebuilt and rebuild it.
Another feature for the (not to distant?) future will be generating a TF-IDF index in javascript so that a client-side search functionality could be introduced.
I also find Gus to have a pretty low bar to publishing. I write in markdown/textile/reStructuredText, build, and rsync. Granted I haven't used many other static generators (the ones I did look at didn't seem to have the features I wanted like tag or date indexes, plus it was one of my first python projects).