Awesome! I've been following John O'Nolan's project since it was announced on Kickstarter. I even started writing my own version which is up on GitHub[1]. Just signed up and I'm looking forward to the future of this project. Just incase anyone else is looking for the source code, it's here: https://github.com/tryghost
It's tricky to argue labels. To me (right or wrong) platform suggests support, active development, community, backing, a reason to believe that development will continue and something you can build on. Of course, you can call platform whatever you like though.
Ghost has many (all?) of the above, and that's relatively rare in any ecosystem (PHP, Ruby, Python, whatever) for a young project. If this project can continue building momentum, then it would truly be unique in general and certainly in the JS ecosystem.
ETA: When I say tricky throwing around labels, I mean one thing can mean one thing to me and something else to you. I guess semantics would be the short word for that.
There's a link to the GitHub repository which I believe is all that is currently available. You can clone the repo (or download an archive of it) and install the platform from that.
Nice! I see it's using nodejs/express. Great to have another large nodejs webapp out there publicly -- I wonder if there's any generally useful tech inside Ghost.
> I wonder if there's any generally useful tech inside Ghost
One of the nicest things about it (aside from the use of node and express, which is very nice IMHO) is that it's open source so you can start looking through the code to find out.
What would you say is the biggest difference compared to Svbtle and Medium?
From a first glimpse:
Plus:
- Good design, simple to use, friendly colors.
- MIT license.
- Well done support forum.
Minus:
- Features should be more clear.
- I might be mean but when I read "Just a blogging platform", I automatically read "Just a(nother) blogging platform."
- Better replace the laptop+wodden table+moleskine+coffee stock image with something better. Everyone is using that stuff right now. If you want to be different, better look different.
- Why the name "Ghost"? Maybe it has some meaning?
- Git Link way too hidden.
"What would you say is the biggest difference compared to Svbtle and Medium?"
Svbtle and Medium are hosted (and as a result, controlled-by) a 3rd party. You host Ghost yourself, giving you complete control over the platform. I think a better comparison would be probably be to Wordpress.
If you're choosing between Ghost and Medium, and would like something that is hosted, I recently released Silvrback (https://www.silvrback.com). It has the simplicity of Medium, while giving you control over your own brand.
Ugg. I really like where you were going with that, but you lost me at this: "People shouldn't spend any time configuring a server for a blog."
Maybe some people shouldn't be spending any time configuring a server for a blog, but I have been increasingly working to take back control of my data and it's related services. That means I want to be able to install things on a server of my choosing. This also means FOSS wherever I can possibly put it. I would even happily pay for the FOSS, but the thing I hate the most about medium, svbtle, and the others, is that I can't use the platform where I want to and I don't see gpl/mit anywhere.
I understand that your intention is the hosted segment, but I really think you could gain a lot more traction by going to a one time price, FOSing the code, and still offering a paid hosting service for those that want it.
Maybe it's just because the older I get the more I am aligning with RMS.
Yeah, you're right. There's always going to be a group of people that want to configure everything themselves and setup their own servers. I'm not really targeting this group with silvrback. Open source ghost would be the best route for you.
However, there are a number of people looking for hosted solutions so they don't have to waste any time with config issues. This is where Silvrback comes in. Also, Silvrback should really only be compared to the hosted version of Ghost (which isn't out yet). Comparing it to open source isn't really possible.
"Comparing it to open source isn't really possible."
I don't really understand this line of reasoning. You are running code on your servers, are you not? Your code is either closed or open. (closed) How is comparing it to open source not possible?
Just not possible in the sense that a hosted solution has the expectation that everything is managed for you. An open-source solution requires you to do the work of setting it up, configuring, handling traffic spikes, backups, etc...
I see your intention now, but you are using the words in the wrong context with the wrong definition. There are plenty of hosted open source products that require little to no setup.
I'm speculating wildly here, but maybe because the blogging platform becomes invisible, like a ghost. A similar approach to LaTeX for word processing. And also perhaps because of the writing theme, as in ghost writing.
It's awesome that it has an ORM - but ever since I have started using Octopress, which is based on Jekyll, is the more I realize that we don't need a DB for 'just blogging'.
Plain, old, generated HTML works perfectly. Plus it is very easy to host.
If this is something you guys can implement, I would suggest looking at it.
Your hosting will be MUCH simpler, cheaper, more profitable (even though you say you are running a non-profit), general footprint will be smaller, and pages will load quicker.
That's just my $0.02.
I love what I see here, but I can't bring myself to going back to a db-powered blog from Octopress.
The day you guys implement something similar, you will have 1 more user though!
Either way....awesome execution and congrats on everything you guys have done. Love it so far.
> is the more I realize that we don't need a DB for 'just blogging'.
That works for you and me (we're using jekyll here) but not for people that want timed releases and an online editor. Comments will need some sort of database as well, so you'll have to rely on disqus or similar if you're running a static blog.
Because you need to write somewhere. Now, you can write to the filesystem if you really really want to, but only if there is a writable FS somewhere - so e.g. not on heroku - but in any case writing to the FS and then serving that document is a whole can of worms.
Actually what I want ideally is the admin interface to be a Node app. For drafts use sqlite. For scheduling use sqlite. When I hit publish I want it to generate static assets.
The blog itself I don't need to be served by the Node app, Apache or Nginx can do that fine.
Well, scheduling and static generation require a cron job that writes the static asset at the predefined time. It all gets complicated from here. You can write the static asset when it's first accessed for example and from there on serve the static file, but that requires a database/storage as well, so you're basically back to square one.
I'd not restrict myself to sqlite here either, but that's a minor nitpick.
Why does it require a database? Ghost has a Markdown editor and presumable stores posts in the database as markdown, just write the markdown to the file system instead of a database? I'm really not seeing any requirement for a database here.
Well, yes, you can write to the filesystem, that's why I'm saying "database/storage". See, heroku for example does not provide you with a writable filesystem and it's also easier to share a database over a couple of hosts than a filesystem. Also, if you want to schedule, you'll need to store the scheduling information somewhere. You can add it to the file itself, just as jekyll does but then you'll have to open all docs just to see if they need scheduling. Or you write a schedule-file, but by the time you're doing that you're effectively building a database. Why not go and use a "real" database adapter and use sqlite for all basic setups since basically, sqlite is a specially formatted file with a library providing useful abstractions on top.
I do suspect that Xylakant may be right elsewhere in this thread when she points out that it's not possible on Heroku, but I'm not sure.
Anyway, I would love to see Ghost use a pile of static Markdown files rather than a database for posts. Then, in a couple of years, when I want to use something else, I can take my pile of Markdown files and move along.
I'm a half-way house person when it comes to CMSes and databases. I don't think raw content needs to go in the database, it can happily live on the file system (assuming a sane permissions regime) and you can delegate version management to git.
However I feel metadata and other structured data belongs in the database for the usual reason: to support unforeseen future queries. That is, to make plugins and widgets easier to develop and better performing (vs, for example, iterating over every post or every comment to perform some calculation).
One problem I have with static HTML basic CMSes for non-personal publishers is that it can be a pain to migrate markup or templates if not rendered client-side.
If you've got thousands of pages, publishing a HTML change could require re-building of all static pages, which means it can be painful maintain once you get to a certain scale.
SO many reasons, many of which boil down into the following sentiment:
- Wordpress has become a over-convoluted behemoth, with a needlessly complex structure that is not overly extensible. It is a pain to develop for/with/around.
I think everyone can appreciate the very tangible effect that Wordpress has had on the web. However, it is currently in the rather painful throws of a transition from blogging platform to CMS, and has been for quite some time.
There are number of other reasons:
- You want to avoid PHP.
- You don't need most of the feature bloat that comes along with Wordpress.
I love php. I also love developing Wordpress themes and plugins. I'm not sure you're making a convincing argument.
Then again, Markdown would be neat to work with, but in the end I'd just rather use html if I need to markup something. And I do like trying new things.
I develop with PHP regularly and absolutely love the strides the community has been making with Composer, the PSRs & frameworks like Laravel.
I have also built tooling, plugins & themes for wordpress. I personally found it to be a frustrating experience: like I had been lobbed back to the days of PHP 4 when I thought all the PHP haters might have had a point (I wish to be emphatic - I don't think this anymore).
From a development perspective:
- The "loop" is bad design - with no regard for separation of concerns and maintainability.
- The lack of namespacing means you have to go through a dance, working around Wordpress's idiosyncratic structure, in order to build around Wordpress effectively.
- I personally don't think much of their documentation.
You say "SO many reasons", but at best you have 4, of which only one seems to hold any weight. Avoiding PHP is not something the average blogger would care about, bloat = features and most normal people like features, trying something different is woolly at best, which leaves wanting to use markdown. Do that many people really want to use markdown?
Are you 100% sure this isn't just an anti thing like anti MS, anti facebook, and now anti wordpress?
Wordpress is incredibly bloated. If you've ever tried to make a semi-large blog with it you'll know exactly what I mean. This is literally just a setup and run blog.
Wordpress used to be that but it's turned into a huge CMS that's trying to do 2000 things at once. Jack of all trades and master of none if you will.
Not really no. I mean you can but Wordpress's admin page feels like you are fighting just to post something. Wordpress is no longer really targeted at people that want to get a blog up and running and just that.
That's what ghost is. It's a blogging system without all the added bloat and horrible API's to go with it.
Looking for those good reasons, which thus far no one has out lined. So far we just have a dislike of being feature rich, or in other words the usual generic throwaway of "bloatware". And some waffle about "setup", which is also an ill-defined throw away.
And, really, is it not clear Im implying that there is a lack of good reason, and that this all sounds like a knee jerk hate thing?
Really, so far, there is no positive reason to use this except some people like the idea of something with less features.
Seriously, what is so good about this? Remember I started by asking what the "So many reasons" are, and so far people are simply saying that its not WP, which was one of the 4 given already.
Hardly a ringing endorsement. Right now, use WP. In the future you might want the extra features, right?
There's an old saying about good design being when you have nothing more to take away, rather than nothing more to add.
Wordpress is a fine product. I've used it in the past. It's complete overkill for what I want to do with it. They want to become a CMS - that's fine, but I wouldn't run a simple blog on Wordpress any more than I'd run it on Joomla or *Nuke or Drupal.
I want a space to write that supports markdown, looks decent, isn't PHP (an objectively terrible language that I have no desire to seriously learn), and is light enough to run on my microserver.
> And, really, is it not clear Im implying that there is a lack of good reason, and that this all sounds like a knee jerk hate thing?
Yes, of course it was clear. Since my post wasn't, I'll state it more clearly: I found it highly amusing that when trying to think of companies that no-one would have a reason to dislike, you chose Microsoft and Facebook.
Simply using their products would provide a few pages to start with :-)
I usually would agree with you, but I think the web has changed since wordpress was created. If nothing else, there is room for usability improvements.
For someone who has never used wordpress before, it can be hard to get started. Understanding the difference between a tag and a catagory. navigating the menu. Compare it to tumblr. Tumblr has a much better user experience.
You mention that bloggers won't care about platform choice, feature bloat or trying something new. Fair enough. Something bloggers would care about is blogging.
Ghost is a simple, focused, blogging platform which is entirely focused on this purpose. As a victim of it's own success, this is not something Wordpress can reasonably claim to be any longer.
Wordpress is a full blown CMS, a title which comes with it's own set of advantages and disadvantages.
I would argue that there is room in the market for both the "Jack-of-all-trades" approach, and the focused, "bare-bones", approach.
Furthermore - my comment was initially in response to an assertion that there were no reasons to be excited about Ghost. I would suggest that, even if they are not reasons you care about, this is untrue.
At the end of the day it comes down to a personal choice of tools. I need a screwdriver; sure, I could use my pen-knife (which also has a torch, bread knife & tweezers), but it might be slower / more fiddly; or I could use a screwdriver.
The OP did not say there were no reasons. The OP merely asked why should he/she use it.
You claimed "SO many reasons", which implies lots and lots of reasons, especially with "SO" in capitals, but you you only listed 4, most of which IMHO were weak, and really only there to puff up the main reason which is that you don't like WP. In fact, in this new tact of yours, you just go on to criticism WP.
But, all you can say to sell this product is that is has less features than WP, and, well, its not WP. But WP works, and works well. So, unless one has a huge problem with WP, which millions of users seem not to have, I'm still don't see much of an answer to the OP's original question, "why should I use this and not WP?"
And of course its personal choice. There are already many alternatives already out there to WP. Most of them as light as this product is, there for already filling the gap for something bare bones. Yet, people make that personal choice to use WP, in their millions.
One big reason people would go for feature rich WP is future proofing. Would be a bit of a mare to use this, then discover you needed more features in the future and have to ditch it for WP, or similar. On top of that the massive user base gives rise to a massive amount of support knowledge. Always a comfort.
Finally, I have to say, if a hacker type in the web business wants something bare bones, what one earth is one doing with blogging software at all? Surely bare bones would be straight HTML with a sniff of CSS? Don't even need a database, and let evil google do the searching. In is most basic form, blogs are just blocks of text linked up. Im pretty sure most people here could rattle up a serviceable blog site in less than a day. I know I could, and I'm crap.
You know, well done to the people who did the work and what not, but Im not seeing any massive positive reason to use it over WP. In fact, in some ways I see it as a risk. What if I want to expand in the future, and this simply cant have the same level of support information. Which is a shame.
I don't believe that is a bad reason for trying something. Committing resources to using ghost in a mission critical environment would be demonstrably silly - however being well informed of the tools available to you and their suitability to purpose is just good sense.
I don't disagree. I think the greater point here is that many people are irrationally choosing to switch to Ghost because "it's better" without really know why it is better. "Because it's not PHP" is the most irrational response I've ever read....
Good marketing showing how to solve problems most perceive they have...
I regret putting that in my original comment because I believe people take that to mean that I am PHP "hating" (I don't know what that even means). I set the record straight in another comment here: https://news.ycombinator.com/item?id=6547794 .
I use PHP extensively and think it has come a hell of a long way over the last couple of years. My meaning with the orignal point of "avoiding PHP" was more in the spirit of platform considerations.
You may, for whatever reason, not want to include PHP as part of your system architecture. By being written in JS, Ghost offers an alternative in terms of platform (where something like Drupal, or Dropplets would not).
The problem I have is why on earth is this an important feature set?
> You may, for whatever reason, not want to include PHP as part of your system architecture.
But why? why? why? Why it does it matter if it's called PHP or JavaScript or GabeSpeek (made up). As long it works and it's maintainable, why on earth does this make any rational person's (not saying you specifically) list of features?
Operating in a larger infrastructure where various components are set in stone and/or not available to them? In a shared hosting esque environment (granted they almost all have PHP by default) it is not impossible to imagine a situation such as this.
The problem I have is why on earth is this an important feature set?
> You may, for whatever reason, not want to include PHP as part of your system architecture.
But why? why? why? Why it does it matter if it's called PHP or JavaScript or GabeSpeek (made up). As long it works and it's maintainable, why on earth does this make any rational person's (not saying you specifically) list of features?
Sure anyone and their pet hamster could develop for Ghost and get what they want out of it, however, clients know Wordpress, non-technical account manager type people know Wordpress, inane managers know Wordpress, developers know Wordpress, people that draw pretty pictures in Photoshop and call it design know Wordpress and even my Dad knows Wordpress. I have not heard any of them want to 'avoid PHP' (they only know it is Wordpress in most cases), they don't complain about 'feature bloat' (they don't have the full admin login, just author rights), they are happy with WYSIWYG (and haven't a clue what Markdown is) and finally, they want something they know rather than something completely different!!!
So it is down to network effects. Everyone knows Wordpress and the famous five minute install.
I feel like Wordpress has too much bloat. It's a full featured CMS now and all I want to do personally is have an organized blog that I can post on. Right now Jekyll is what I've been using which works pretty well, but because ghost is not just a static site, it can do a bit more.
One thing that I can see right away that I like is working with themes. Other comments point out the WP bloat. I don't care about bloat as long as the software is easy to install and generally stays out of my way after that (the bloat stays hidden) but one area Wordpress can get to be a bit messy looking is the themes.
If Ghost is easy to theme and the templates easier to read / build / maintain then that's a big plus for me. I may not want to touch any code on the thing, but I would certainly want to do work on the templates.
i hacked up a view posts by category and a template swap by hostURL in a few hours but the code is really abstracted. it will probably make sense later when all the features are implemented though.
good:
- easy to install
- love the editor
- love the admin
- templates are handlebars and easy
i've been following this for ~6 months now and am stoked to use it. congrats on your release. can we please have a CMS style feature were we can edit some static pages to go into our blogs! PLZ!
Hey ... I've been playing with Ghost now for a few hours and wondering if you've gotten any new templates set up, or have tips for template tweaking? I'm a newcomer to bourbon and sass ..
i recommend just copything the casper folder and renaming it. (content/themes/casper)
make your own stylesheet and comment theirs out (it, styles, everything). theirs is screen.css.
you can comment out the ghost included {{body_class}} and {{ghost_foot}} by changing them to {{!body_class}} and {{!ghost_foot}}
after that its just 3 files, default.hbs which is a global template (so its like the html head body tags), and then they insert the body at {{body}}
the body comes from index.hbs or post.hbs, which will be index.hbs: 6 article summaries in a list with a page at the bottom. and post.hbs which will just show 1 post.
the data in the post and index hbs files (handlebars templates) has stuff like {{eachpost}} {{post}} which is all you really have to keep out of those files
Looking at the client side code makes me wonder why people would ever use Backbone. It's so abstracted, mixes DOM manipulation into views. I should re-write it with Angular! :)
I can't take anyone seriously who uses fonts to display icons (it doesn't work when you turn off foreign fonts!)
Sadly, nowadays thats pretty much everyone. If you want me to care about you (apparently/marketwise you don't), then get your design right. Tip: Design is not looking pretty. Design is this question: Does it work?
I think the case for supporting retina screens + very fast load times far outweighs the amount of users that turn off foreign fonts (it baffles me why you would)
There are some very good reasons why you'd want icons in a font. For example, font rendering is well supported by all browsers and very configurable through CSS, and if the default font size is increased for accessibility reasons the icons can also scale.
Is disabling fonts the new disabling Javascript and/or HTML emails? Something done by overly paranoid uber-nerd types and completely ignored by 99% of typical users.
I feel this is a lot like how people used to object to websites that required JavaScript because they had it switched off... If you're going to use the web at all, you're probably going to need to change your setup so icon fonts work, because it's only going to get more common.
Because I don't want foreign fonts. They are usually either just bad (e.g. worse than my OS font) or render badly.
> It's an edge case, 0.0000001%, ....
You are not downwards compatible. It's an edge case because you make it one by deciding on web "standards" by thoughtlessly applying these short-sighted idioms.
It's a tradeoff, just like not supporting users on IE9- or with JS disabled.
Using sprites instead of fonts to support users with foreign fonts disabled means degrading the product for some other users. Building a polyfill means not spending the time improving something else.
Why do you consider "support everyone" to be obviously better than "build a better product for a subset of users"?
I feel like the undending debates around this issue (most often regarding JS) exist because some people on HN look at it through a business angle where #2 can make complete sense, while some others look at it through a Web ideals angle where anything but #1 is heresy.
Edit: To be fair, the Web ideals remark doesn't seem to apply to you. You rather seem to consider than being pretty is way less important than supporting more people. But why? Being pretty has been increasingly important this past decade, and especially so regarding blogs where being pretty is one of the few differentiators.
> Why do you consider "support everyone" to be obviously better than "build a better product for a subset of users"?
Blogs are my newspapers, thats why. For me accessibility and downwards compatability outweigh the "product" a lot. I have a low-end smart phone for which most "products" are ununsable. Why do people throw away expensive hardware that woks perfectly fine? Because the modern software doesn't run on it.
That is a product that meets my demands: I can read on any device, using multiple clients. I could read this page with a dual-core as well as with a gameboy. Serve TTF font's, maybe I rather use bitmap fonts? Doesn't matter.
I could read that blog using Mosaic, lynx, w3m... kindle displays...
It also works fine for braille terminals.
I guess I am more interested in powerful systems than the pityful products of the App-bubble. After all I am a programmer.
It's great to see how Kickstarter helped also "stabilize" the development of Open Source software (another example is Django Migrations project [0] which has been discussed here a couple of times already). It helped Ghost provide something on a much higher and usable level than most other Open Source projects did, which should have positive impact on the user/community adoption. I'm speaking here about collaboration with Digital Ocean, Rackspace and Envato, as well as the marketing campaign by Kickstarter before this release. DOcean, RackSpace and Envato alone will generate pretty high traffic and build up the community, especially if Envato (with Tutsplus/Nettuts) starts doing something similar as for Laravel [1][2][3], and provide free developer introduction to the platform.
Glad to see this, hope it will keep up the expectations.
I think it's the idea in general, not the specific platform. Joey Hess was able to successfully run his own crowdfunding campaign with custom written software.
I really like the idea of having images for popular hosting providers like Digital Ocean and Rackspace; this should lower the entry level difficulty tremendously.
I wish Discourse would do something similar, as I believe it would spread the adoption very quickly.
After briefly looking over documentation, it seems that Ghost doesn't support post types like links, asides, images, etc. Or did I overlook something? If else, future implementation?
Very, very interesting. There are a lot of to be announced in there, especially pricing. But as this is opensource I thank the creators of this and will hope to contribute.
Is the registering on ghost.org for hosting a blog on that page, or to obtain the prepackaged zip files the README at github talks about? In other words, to host ghost myself, do I need to register at ghost.org or do I have to clone the github repo?
Eventually you'll be able to their hosted service, but for now when you register you just get access to a source download for self-hosting and access to their forums.
Browsed the code a little bit and my overall impressions are the while the code quality is good, it's a shame that it seems to be tightly coupled to doing a database as the backend. I was hoping to fork Ghost, or even better just provide a plugin for it, that uses static file creation instead of a db backend but looking at the code this looks like it's going to be a bit of work to do. I'll probably still do it but it would have been nice if the db stuff had been abstracted a little further out
I completely agree, if you decide to do it and need any help PM me. With something lightweight like this it would definitely be a lot better with a simple file system instead of a whole database that you need to set up and deal with. I have done something similar before in PHP, but the Ghost front end is really nice.
The difference between 'CMS' and 'publishing tool' is semantic. Ghost is connected to a database, allows you to create content and manage assets, and if you read through the discussions in their forum it's clear many people are already excited to use Ghost not just to blog, but to create websites.
That's not to say they will become Wordpress, but just to point out that content management is in fact part of what Ghost is created to do.
Been watching Ghost for a while and ever since I saw it get so much funding I thought to myself; with those pledged features I could do this alone, better, faster. Since then I have been sidetracked with a closed source somewhat-overlapping project but now that Ghost is out I plan to steal some ideas people actually like from it and continue building my own platform. Kinda makes me chuckle in that they got payed to do this and yet their feature set is still so underdeveloped, for a blogging platform of all things.
I think now that you've made your point I may abstract models to the point where the database can be either MariaDB or a bunch of JSON files/SQLite. Its tricky because I build databases for performance and scalability over flexibility.
To give you an idea of what I mean, Wordpress makes me cringe in the way they handle their tags, categories etc. and the sheer amount of SQL queries and joins for a simple front page. I make at most 2 queries for the front page (excluding sidebar, which would be cached), the user session authentication and the articles. I make no queries if I can help it ( Caching in node.js is so fun ). Categories are always in memory, along with user roles, settings etc.
It's really quite glorious having a readily available memory store. I'm getting around ~500 queries per second to my front page in apachebench, which would normally have about 7-10 queries to the database.
Honestly, a better Wordpress is something that the majority of people with a reasonable understanding of web development and database design (or hey, with a NoSQL store, maybe not even that! /troll) could do in a weekend. However, as you've said, we all have other things to do, but more importantly, it's the free upgrades and transfer of liability that make Wordpress enticing. I'm sure there are plenty of developers out there (myself included) that are happy to say "there's a bug in Wordpress that we'll need to patch" vs. "there's a bug in my code that we'll need to patch".
The WordPress community is rivaled by none and that makes it a hard option to pass up on a budget.
edit: This isn't to say I prefer WordPress over something like Ghost. What I do prefer is something stable with a healthy community. I wish Ghost as well as others like it the best of luck in getting there.
A community has to start somewhere. Ghost is a brand new platform but I'd be surprised if a strong, active community didn't grow relatively quickly. It's gained 800 stars on GitHub in the space of about 3 hours.
In my experience running two rather massive WordPress installs the vast majority of one's bugs will not be found in WordPress, but in ones extensions of it. The liability argument applies well to UI/UX, however.
That is simply not true. You could not write a whole CMS with plugin-api, template system, image manipulation, user roles, auto-installer (and auto updater of plug-ins and entire install), comments system, image galleries, media manager as well as a administration backend (that mind you not only needs to work, but also needs to be designed visually) as well as a high quality default theme.
Where do you guys get off saying such things? It's a completely absurd statement. Of course you can't do that.
You're right. I wasn't really thinking about building my own platform; more thinking about building a CMS that did what I needed it to do. The plugin API would take some work, but a templating system, image manipulation, user roles, auto-installer, comment system, and media manager are all very easy to implement, if not provided to you for free by PHP or an existing library (ImageMagick, for example).
It's what many people with a reasonable understanding of web development and limited experience of writing a CMS think.
It's a well-trodden rite of passage for many web developers to end up writing a CMS or three from scratch (which are always limited, clunky, and unmaintainable) - until they get sick of getting caught out by edge cases on things like multiple editors in race conditions, CSRF on forms, scheduled revisions, password reset flows, user synchronisation, localisation etc.
That may be a great learning experience for a developer but expensive for businesses that end up having to migrate and re-platform after a year or two. It's really hard (and dull) to create a good CMS, and even then the considerations go beyond technical as this is a piece of business infrastructure. Why do you think Wordpress has so little competition even though it's a large and valuable market?
I agree, you guys are right. Was in a kind of shitty mood when I wrote that and now I'm kicking myself for coming off like the egotistical bitter dick that I know I am. :p. HN deserves less Reddit type smugness.
The whole Ghost thing I should have mentioned is IMO a pretty sweet concept and not at all a bad followthrough. Their marketplace, partnerships, capital etc. make them a much better contender than my team could be.
You laugh at them, but they actually have a product out and it's good enough that you plan to steal features/ideas rather than work out your own from scratch?
I find it odd that you feel put off by the single choice of database, while also arguing that users shouldn't mind being tied to databases in general. Surely using SQLite when your setup is better suited to PostgreSQL is a less harmful trade-off than the case where files would have been better suited to your system/requirements.
I suppose. I have never understood an aversion to databases in general (though I do understand the general concept that the filesystem is, in a sense, a perfectly fine database for many purposes).
If you're a dev, forking Ghost and replacing the DB with something else isn't an insurmountable task.
Your prep work in isolating the database work may even be something the Ghost people themselves would be interested in merging, as it's just good design to do so (if they hadn't already).
Ghost is super cool and I love the UI, but I also find that having a persistent database limits some of the portability. And, depending on what's in the database, it might mean that developers can't use their favorite tools (like Sublime Text, etc.) to author content, develop and design templates, etc.
This is a bit of a shameless plug, but I figure it's relevant to this topic. I just put up blog post introducing my new project, Grow (http://about.grow.io/blog/all-i-want-to-do-is-build-a-web-si...). Grow overlaps with Ghost in some ways, but attempts to be a full-fledged, modern file-based CMS and is not designed just for blogs alone. I've been following all the replies in this thread to get a better idea on what people are looking for, and I think I've nailed it.
Basically, the way I've architected Grow is the whole system is file-based: content is stored in Markdown or YAML files, templates are stored as Jinja2 templates, separate from the content.
When you start up a Grow server for development, essentially what amounts to a super lightweight in-memory index is created from the file structure, and that allows your site to be generated (including pages that leverage complicated queries or access content through taxonomies).
This design keeps everything incredibly portable (zero-configuration development AND zero-configuration deployment) – which is one of the values that I hold to be very important. Anyway, the project is still super young (and my blog post is light on technical details, but I'm working on it), so I'm interested in getting any early feedback.
I would recommend splitting out the monolithic Gruntfile.js into individual config and task files. It makes it easier to read, in my opinion. I've put together an example here: https://github.com/badsyntax/gruntfile
Hmm, isn't this name caught by trademark law in the UK? Ghost is almost certainly a trademark of Symantec; wouldn't this fall into the same trademark category?
I don't think anyone is invulnerable to this. The only (partial) salvation is to be aware of it, take it with a (big) grain of salt, and try to overcome it with factual reasoning when making decisions.
> "Oh, he says he was in charge of WordPress interface design for two years. Using WordPress causes me pain. I expect this product to be painful."
Sadly, this is too common of a fallacy in judgment, and one that seems most non-fallacious on its face. But whether we want to admit it or not, sometimes output and achievements are highly impacted -- even dependent -- on the organization and institution than the individual. So someone highly successful at Apple retail, for example, may flounder at JCPenney's (http://dealbook.nytimes.com/2012/11/12/a-dose-of-realism-for...).
So it goes both ways. It's wrong to argue that someone who was great at once place will necessarily be great at another. And conversely, someone who's work turned out awful at one place (either by poor management or design-by-committee), may flourish in different circumstances
"Oh, he says he was in charge of WordPress interface design for two years. Using WordPress causes me pain. I expect this product to be painful."
Wait, what?
WordPress' backend may be a mess, but it's CMS interface is the only one I've ever trained a non-technical person on that they liked or seemed to be able to use right away. I worked at a marketing/dev shop for years and have probably trained 40-ish non-techy clients (usually small marketing teams of 3-4) on customized CMS installs. WordPress' dashboard was by far the best when it came to power/usability ratio.
A lot of people feel their data is exceptional, and so meta data is where I see "custom" hurt content creation the most: Whereas WordPress has a neatly rolled meta data extensions into "Custom Fields" many CMS degrade into a morass of form fields.
People should be wary of custom built CMS UIs, not only because most people have learned a UI like WordPress or Tumblr.
WP owes most of it's success to the UI, it is the very reason it became so popular. It continues to this day to sooth and empower end users, so much so that the actual users often think they are developers, that is what you call a successful interface. WP lead the way with UI more so than any platform, much like Apple, they realize the importance of UX.
If you think the UI is painful that I don't have a lot of faith in your ability to objectively judge interfaces especially in the context of history.
What are the best practices for deploying a node.js app from git on Ubuntu behind nginx? I'm sure someone has a blog post on that but "Ghost" makes it a bit difficult to google for.
In case anyone's looking, this PPA[1] seems to come recommended and has an up-to-date node.
Which in this case would make things a little more difficult cause Ghost uses SQLite and Dokku can't deploy apps which use it because of default Node.js Heroku buildpack which prohibits SQLite usage. You can patch a buildpack though.
For example in my fork of Dokku I replaced Heroku buildpacks with plain Dockerfiles to define both a stack and a runtime dependencies — https://github.com/andreypopp/upaas
How are you liking it? It's very handy for launching apps, for sure, but I'm wondering how you can configure services (e.g. how do I set up redis persistence or nginx directives or postgres backups?).
Basically Nginx is used as a reverse proxy to serve requests from a pool of Node.js processes, each with its own internal port. So you would set up the Node.js app to run internally on ports 8080, 8081, 8082, and 8083 for example. (If you have a quad core server this assures that under extreme load each processor can be fully utilized by one single-thread Node.js process). Then Nginx serves requests on port 80 by fetching the response from one of those four internal ports in round robbin fashion.
If one of the processes crashes due to a bug or you want to specifically restart it so that a new code update takes effect in production then Nginx will automatically remove it from the pool while it is down and then add it back when it comes back online. When you are pushing out code updates you can cycle each process one at a time to do a zero downtime deploy.
The other cool thing that you can do with Nginx reverse proxies is use the proxy_cache as a robust cache layer to almost completely remove stress from your blog under high load.
Honestly for a basic personal blog this technique probably isn't really necessary. You could just run it through Forever on port 80 with no Nginx and forget it, but if you expect tons of traffic, or if you want high 99% uptime, or if you just want to have some fun configuring a server then the technique I explained above is how you do it. It takes some fiddling to get Nginx configured properly and that tutorial I linked actually leaves out some details of the upstream server configuration but its pretty easy to figure out from the Nginx documentation.
271 comments
[ 3.3 ms ] story [ 267 ms ] thread[1] - https://github.com/joeblau/bl0g
"We have successfully created the world's first fully functioning blogging platform built entirely with JavaScript."
Really? The world's first entirely JavaScript blogging platform? Google turns up plenty, albeit not quite as polished.
Ghost has many (all?) of the above, and that's relatively rare in any ecosystem (PHP, Ruby, Python, whatever) for a young project. If this project can continue building momentum, then it would truly be unique in general and certainly in the JS ecosystem.
ETA: When I say tricky throwing around labels, I mean one thing can mean one thing to me and something else to you. I guess semantics would be the short word for that.
http://www.kickstarter.com/projects/johnonolan/ghost-just-a-...
One of the nicest things about it (aside from the use of node and express, which is very nice IMHO) is that it's open source so you can start looking through the code to find out.
From a first glimpse:
Plus: - Good design, simple to use, friendly colors. - MIT license. - Well done support forum.
Minus: - Features should be more clear. - I might be mean but when I read "Just a blogging platform", I automatically read "Just a(nother) blogging platform." - Better replace the laptop+wodden table+moleskine+coffee stock image with something better. Everyone is using that stuff right now. If you want to be different, better look different. - Why the name "Ghost"? Maybe it has some meaning? - Git Link way too hidden.
Good job!
Svbtle and Medium are hosted (and as a result, controlled-by) a 3rd party. You host Ghost yourself, giving you complete control over the platform. I think a better comparison would be probably be to Wordpress.
I'd like to hear a comparison (though happy to throw wordpress in the consideration pool too)
Maybe some people shouldn't be spending any time configuring a server for a blog, but I have been increasingly working to take back control of my data and it's related services. That means I want to be able to install things on a server of my choosing. This also means FOSS wherever I can possibly put it. I would even happily pay for the FOSS, but the thing I hate the most about medium, svbtle, and the others, is that I can't use the platform where I want to and I don't see gpl/mit anywhere.
I understand that your intention is the hosted segment, but I really think you could gain a lot more traction by going to a one time price, FOSing the code, and still offering a paid hosting service for those that want it.
Maybe it's just because the older I get the more I am aligning with RMS.
However, there are a number of people looking for hosted solutions so they don't have to waste any time with config issues. This is where Silvrback comes in. Also, Silvrback should really only be compared to the hosted version of Ghost (which isn't out yet). Comparing it to open source isn't really possible.
I don't really understand this line of reasoning. You are running code on your servers, are you not? Your code is either closed or open. (closed) How is comparing it to open source not possible?
I would have expected you to use something like TinyMCE. Markdown is like coding for non-programmers.
I'm speculating wildly here, but maybe because the blogging platform becomes invisible, like a ghost. A similar approach to LaTeX for word processing. And also perhaps because of the writing theme, as in ghost writing.
(BLO)Ghost?
Are the posts stored in a db or are they generated HTML?
Plain, old, generated HTML works perfectly. Plus it is very easy to host.
If this is something you guys can implement, I would suggest looking at it.
Your hosting will be MUCH simpler, cheaper, more profitable (even though you say you are running a non-profit), general footprint will be smaller, and pages will load quicker.
That's just my $0.02.
I love what I see here, but I can't bring myself to going back to a db-powered blog from Octopress.
The day you guys implement something similar, you will have 1 more user though!
Either way....awesome execution and congrats on everything you guys have done. Love it so far.
That works for you and me (we're using jekyll here) but not for people that want timed releases and an online editor. Comments will need some sort of database as well, so you'll have to rely on disqus or similar if you're running a static blog.
Comments (outside of Disqus), timed-releases and online editor. Interesting. I can see that.
The blog itself I don't need to be served by the Node app, Apache or Nginx can do that fine.
Well, scheduling and static generation require a cron job that writes the static asset at the predefined time. It all gets complicated from here. You can write the static asset when it's first accessed for example and from there on serve the static file, but that requires a database/storage as well, so you're basically back to square one.
I'd not restrict myself to sqlite here either, but that's a minor nitpick.
I do suspect that Xylakant may be right elsewhere in this thread when she points out that it's not possible on Heroku, but I'm not sure.
Anyway, I would love to see Ghost use a pile of static Markdown files rather than a database for posts. Then, in a couple of years, when I want to use something else, I can take my pile of Markdown files and move along.
However I feel metadata and other structured data belongs in the database for the usual reason: to support unforeseen future queries. That is, to make plugins and widgets easier to develop and better performing (vs, for example, iterating over every post or every comment to perform some calculation).
If you've got thousands of pages, publishing a HTML change could require re-building of all static pages, which means it can be painful maintain once you get to a certain scale.
- Wordpress has become a over-convoluted behemoth, with a needlessly complex structure that is not overly extensible. It is a pain to develop for/with/around.
I think everyone can appreciate the very tangible effect that Wordpress has had on the web. However, it is currently in the rather painful throws of a transition from blogging platform to CMS, and has been for quite some time.
There are number of other reasons:
- You want to avoid PHP.
- You don't need most of the feature bloat that comes along with Wordpress.
- You want to use Markdown.
- You want to try something different.
Then again, Markdown would be neat to work with, but in the end I'd just rather use html if I need to markup something. And I do like trying new things.
I have also built tooling, plugins & themes for wordpress. I personally found it to be a frustrating experience: like I had been lobbed back to the days of PHP 4 when I thought all the PHP haters might have had a point (I wish to be emphatic - I don't think this anymore).
From a development perspective:
- The "loop" is bad design - with no regard for separation of concerns and maintainability.
- The lack of namespacing means you have to go through a dance, working around Wordpress's idiosyncratic structure, in order to build around Wordpress effectively.
- I personally don't think much of their documentation.
You say "SO many reasons", but at best you have 4, of which only one seems to hold any weight. Avoiding PHP is not something the average blogger would care about, bloat = features and most normal people like features, trying something different is woolly at best, which leaves wanting to use markdown. Do that many people really want to use markdown?
Are you 100% sure this isn't just an anti thing like anti MS, anti facebook, and now anti wordpress?
Wordpress used to be that but it's turned into a huge CMS that's trying to do 2000 things at once. Jack of all trades and master of none if you will.
Wordpress isn't? Unless things have changed you install it and start adding blog posts.
That's what ghost is. It's a blogging system without all the added bloat and horrible API's to go with it.
???
Is the current iteration of wordpress different from this workflow? Is Ghost different?What do you mean by "setup and run"? The work setup is extremely elastic. WP is setup and run. So is a particle accelerator, as is a fridge.
You mean being anti things that you have very good reasons for being anti? I suppose it is like that.
And, really, is it not clear Im implying that there is a lack of good reason, and that this all sounds like a knee jerk hate thing?
Really, so far, there is no positive reason to use this except some people like the idea of something with less features.
Seriously, what is so good about this? Remember I started by asking what the "So many reasons" are, and so far people are simply saying that its not WP, which was one of the 4 given already.
Hardly a ringing endorsement. Right now, use WP. In the future you might want the extra features, right?
Wordpress is a fine product. I've used it in the past. It's complete overkill for what I want to do with it. They want to become a CMS - that's fine, but I wouldn't run a simple blog on Wordpress any more than I'd run it on Joomla or *Nuke or Drupal.
I want a space to write that supports markdown, looks decent, isn't PHP (an objectively terrible language that I have no desire to seriously learn), and is light enough to run on my microserver.
Yes, of course it was clear. Since my post wasn't, I'll state it more clearly: I found it highly amusing that when trying to think of companies that no-one would have a reason to dislike, you chose Microsoft and Facebook.
Simply using their products would provide a few pages to start with :-)
You couldn't possible be claiming that the Wordpress interface is the pinnacle of UX research and advancements. Its fine. Just fine.
You mention that bloggers won't care about platform choice, feature bloat or trying something new. Fair enough. Something bloggers would care about is blogging.
Ghost is a simple, focused, blogging platform which is entirely focused on this purpose. As a victim of it's own success, this is not something Wordpress can reasonably claim to be any longer.
Wordpress is a full blown CMS, a title which comes with it's own set of advantages and disadvantages.
I would argue that there is room in the market for both the "Jack-of-all-trades" approach, and the focused, "bare-bones", approach.
Furthermore - my comment was initially in response to an assertion that there were no reasons to be excited about Ghost. I would suggest that, even if they are not reasons you care about, this is untrue.
At the end of the day it comes down to a personal choice of tools. I need a screwdriver; sure, I could use my pen-knife (which also has a torch, bread knife & tweezers), but it might be slower / more fiddly; or I could use a screwdriver.
Wordpress isn't the right tool for me anymore.
You claimed "SO many reasons", which implies lots and lots of reasons, especially with "SO" in capitals, but you you only listed 4, most of which IMHO were weak, and really only there to puff up the main reason which is that you don't like WP. In fact, in this new tact of yours, you just go on to criticism WP.
But, all you can say to sell this product is that is has less features than WP, and, well, its not WP. But WP works, and works well. So, unless one has a huge problem with WP, which millions of users seem not to have, I'm still don't see much of an answer to the OP's original question, "why should I use this and not WP?"
And of course its personal choice. There are already many alternatives already out there to WP. Most of them as light as this product is, there for already filling the gap for something bare bones. Yet, people make that personal choice to use WP, in their millions.
One big reason people would go for feature rich WP is future proofing. Would be a bit of a mare to use this, then discover you needed more features in the future and have to ditch it for WP, or similar. On top of that the massive user base gives rise to a massive amount of support knowledge. Always a comfort.
Finally, I have to say, if a hacker type in the web business wants something bare bones, what one earth is one doing with blogging software at all? Surely bare bones would be straight HTML with a sniff of CSS? Don't even need a database, and let evil google do the searching. In is most basic form, blogs are just blocks of text linked up. Im pretty sure most people here could rattle up a serviceable blog site in less than a day. I know I could, and I'm crap.
You know, well done to the people who did the work and what not, but Im not seeing any massive positive reason to use it over WP. In fact, in some ways I see it as a risk. What if I want to expand in the future, and this simply cant have the same level of support information. Which is a shame.
Good marketing showing how to solve problems most perceive they have...
I use PHP extensively and think it has come a hell of a long way over the last couple of years. My meaning with the orignal point of "avoiding PHP" was more in the spirit of platform considerations.
You may, for whatever reason, not want to include PHP as part of your system architecture. By being written in JS, Ghost offers an alternative in terms of platform (where something like Drupal, or Dropplets would not).
The problem I have is why on earth is this an important feature set?
> You may, for whatever reason, not want to include PHP as part of your system architecture.
But why? why? why? Why it does it matter if it's called PHP or JavaScript or GabeSpeek (made up). As long it works and it's maintainable, why on earth does this make any rational person's (not saying you specifically) list of features?
The problem I have is why on earth is this an important feature set?
> You may, for whatever reason, not want to include PHP as part of your system architecture.
But why? why? why? Why it does it matter if it's called PHP or JavaScript or GabeSpeek (made up). As long it works and it's maintainable, why on earth does this make any rational person's (not saying you specifically) list of features?
So it is down to network effects. Everyone knows Wordpress and the famous five minute install.
If Ghost is easy to theme and the templates easier to read / build / maintain then that's a big plus for me. I may not want to touch any code on the thing, but I would certainly want to do work on the templates.
Edit: http://www.ghost.org/features/
Looks like markdown+looks stylish. Not sure what else.
things i've noticed so far (.3.0):
- no dash yet
- no view posts by category feature
- no list top 10 most recent posts
- kind of confusing or redundant mvc abstraction
i hacked up a view posts by category and a template swap by hostURL in a few hours but the code is really abstracted. it will probably make sense later when all the features are implemented though.
good:
- easy to install
- love the editor
- love the admin
- templates are handlebars and easy
i've been following this for ~6 months now and am stoked to use it. congrats on your release. can we please have a CMS style feature were we can edit some static pages to go into our blogs! PLZ!
i recommend just copything the casper folder and renaming it. (content/themes/casper)
make your own stylesheet and comment theirs out (it, styles, everything). theirs is screen.css.
you can comment out the ghost included {{body_class}} and {{ghost_foot}} by changing them to {{!body_class}} and {{!ghost_foot}}
after that its just 3 files, default.hbs which is a global template (so its like the html head body tags), and then they insert the body at {{body}}
the body comes from index.hbs or post.hbs, which will be index.hbs: 6 article summaries in a list with a page at the bottom. and post.hbs which will just show 1 post.
the data in the post and index hbs files (handlebars templates) has stuff like {{eachpost}} {{post}} which is all you really have to keep out of those files
Sadly, nowadays thats pretty much everyone. If you want me to care about you (apparently/marketwise you don't), then get your design right. Tip: Design is not looking pretty. Design is this question: Does it work?
Turn off foreign fonts (?) maybe 0.001% of web users do that.
Fonts to display icons reduce HTTP overhead and scale, looking great on retina screens.
There are some very good reasons why you'd want icons in a font. For example, font rendering is well supported by all browsers and very configurable through CSS, and if the default font size is increased for accessibility reasons the icons can also scale.
> Why would you turn off foreign fonts?
Because I don't want foreign fonts. They are usually either just bad (e.g. worse than my OS font) or render badly.
> It's an edge case, 0.0000001%, ....
You are not downwards compatible. It's an edge case because you make it one by deciding on web "standards" by thoughtlessly applying these short-sighted idioms.
Using sprites instead of fonts to support users with foreign fonts disabled means degrading the product for some other users. Building a polyfill means not spending the time improving something else.
Why do you consider "support everyone" to be obviously better than "build a better product for a subset of users"?
I feel like the undending debates around this issue (most often regarding JS) exist because some people on HN look at it through a business angle where #2 can make complete sense, while some others look at it through a Web ideals angle where anything but #1 is heresy.
Edit: To be fair, the Web ideals remark doesn't seem to apply to you. You rather seem to consider than being pretty is way less important than supporting more people. But why? Being pretty has been increasingly important this past decade, and especially so regarding blogs where being pretty is one of the few differentiators.
Blogs are my newspapers, thats why. For me accessibility and downwards compatability outweigh the "product" a lot. I have a low-end smart phone for which most "products" are ununsable. Why do people throw away expensive hardware that woks perfectly fine? Because the modern software doesn't run on it.
Take for example the opposite: http://blog.fefe.de
That is a product that meets my demands: I can read on any device, using multiple clients. I could read this page with a dual-core as well as with a gameboy. Serve TTF font's, maybe I rather use bitmap fonts? Doesn't matter.
I could read that blog using Mosaic, lynx, w3m... kindle displays... It also works fine for braille terminals.
I guess I am more interested in powerful systems than the pityful products of the App-bubble. After all I am a programmer.
Glad to see this, hope it will keep up the expectations.
[0] http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
[1] http://laravel.com/
[2] http://net.tutsplus.com/tag/laravel/
[3] https://tutsplus.com/course/laravel-essentials/
https://campaign.joeyh.name/
Thanks for the Git-Annex link - didn't know he ran a campaign on his own after doing it on Kickstarter.
Where is the proof of this? Any hard data on customer account numbers or growth?
There are lots of solid VPS providers out there. I don't see why Digital Ocean gets so much hype.
[1] http://trends.netcraft.com/www.digitalocean.com
Maybe you can try looking into one profile.
But it is /not a CMS/. It's a blogging platform, and it set out to not become what Wordpress has turned into (a CMS).
That's not to say they will become Wordpress, but just to point out that content management is in fact part of what Ghost is created to do.
Fine for a default though. As long as you can switch it later.
I think now that you've made your point I may abstract models to the point where the database can be either MariaDB or a bunch of JSON files/SQLite. Its tricky because I build databases for performance and scalability over flexibility.
To give you an idea of what I mean, Wordpress makes me cringe in the way they handle their tags, categories etc. and the sheer amount of SQL queries and joins for a simple front page. I make at most 2 queries for the front page (excluding sidebar, which would be cached), the user session authentication and the articles. I make no queries if I can help it ( Caching in node.js is so fun ). Categories are always in memory, along with user roles, settings etc.
It's really quite glorious having a readily available memory store. I'm getting around ~500 queries per second to my front page in apachebench, which would normally have about 7-10 queries to the database.
The WordPress community is rivaled by none and that makes it a hard option to pass up on a budget.
edit: This isn't to say I prefer WordPress over something like Ghost. What I do prefer is something stable with a healthy community. I wish Ghost as well as others like it the best of luck in getting there.
Where do you guys get off saying such things? It's a completely absurd statement. Of course you can't do that.
It's a well-trodden rite of passage for many web developers to end up writing a CMS or three from scratch (which are always limited, clunky, and unmaintainable) - until they get sick of getting caught out by edge cases on things like multiple editors in race conditions, CSRF on forms, scheduled revisions, password reset flows, user synchronisation, localisation etc.
That may be a great learning experience for a developer but expensive for businesses that end up having to migrate and re-platform after a year or two. It's really hard (and dull) to create a good CMS, and even then the considerations go beyond technical as this is a piece of business infrastructure. Why do you think Wordpress has so little competition even though it's a large and valuable market?
The whole Ghost thing I should have mentioned is IMO a pretty sweet concept and not at all a bad followthrough. Their marketplace, partnerships, capital etc. make them a much better contender than my team could be.
My gripe is that it appears tied to SQLite, and I can't use Postgres. Oh well, wasn't planning on using it anyway.
So in theory putting in the correct connection config should allow you to use Postgres.
I just like Postgres, that's all.
[1] https://github.com/TryGhost/Ghost/blob/master/package.json
[2] http://www.howtoinstallghost.com/how-to-install-ghost-on-her...
Your prep work in isolating the database work may even be something the Ghost people themselves would be interested in merging, as it's just good design to do so (if they hadn't already).
This is a bit of a shameless plug, but I figure it's relevant to this topic. I just put up blog post introducing my new project, Grow (http://about.grow.io/blog/all-i-want-to-do-is-build-a-web-si...). Grow overlaps with Ghost in some ways, but attempts to be a full-fledged, modern file-based CMS and is not designed just for blogs alone. I've been following all the replies in this thread to get a better idea on what people are looking for, and I think I've nailed it.
Basically, the way I've architected Grow is the whole system is file-based: content is stored in Markdown or YAML files, templates are stored as Jinja2 templates, separate from the content.
When you start up a Grow server for development, essentially what amounts to a super lightweight in-memory index is created from the file structure, and that allows your site to be generated (including pages that leverage complicated queries or access content through taxonomies).
This design keeps everything incredibly portable (zero-configuration development AND zero-configuration deployment) – which is one of the values that I hold to be very important. Anyway, the project is still super young (and my blog post is light on technical details, but I'm working on it), so I'm interested in getting any early feedback.
the db is sqlite by default, and its stored in content/ with your themes and other stuff (?)
so you just backup your content directory ;d
* "Oh, a New Zealand accent. One of us! I hope this is really awesome and I want to try this out already."
* "Oh, he says he was in charge of WordPress interface design for two years. Using WordPress causes me pain. I expect this product to be painful."
Sadly, this is too common of a fallacy in judgment, and one that seems most non-fallacious on its face. But whether we want to admit it or not, sometimes output and achievements are highly impacted -- even dependent -- on the organization and institution than the individual. So someone highly successful at Apple retail, for example, may flounder at JCPenney's (http://dealbook.nytimes.com/2012/11/12/a-dose-of-realism-for...).
So it goes both ways. It's wrong to argue that someone who was great at once place will necessarily be great at another. And conversely, someone who's work turned out awful at one place (either by poor management or design-by-committee), may flourish in different circumstances
Wait, what?
WordPress' backend may be a mess, but it's CMS interface is the only one I've ever trained a non-technical person on that they liked or seemed to be able to use right away. I worked at a marketing/dev shop for years and have probably trained 40-ish non-techy clients (usually small marketing teams of 3-4) on customized CMS installs. WordPress' dashboard was by far the best when it came to power/usability ratio.
People should be wary of custom built CMS UIs, not only because most people have learned a UI like WordPress or Tumblr.
If you think the UI is painful that I don't have a lot of faith in your ability to objectively judge interfaces especially in the context of history.
In case anyone's looking, this PPA[1] seems to come recommended and has an up-to-date node.
[1] https://launchpad.net/~chris-lea/+archive/node.js/
For example in my fork of Dokku I replaced Heroku buildpacks with plain Dockerfiles to define both a stack and a runtime dependencies — https://github.com/andreypopp/upaas
http://blog.argteam.com/coding/hardening-node-js-for-product...
Basically Nginx is used as a reverse proxy to serve requests from a pool of Node.js processes, each with its own internal port. So you would set up the Node.js app to run internally on ports 8080, 8081, 8082, and 8083 for example. (If you have a quad core server this assures that under extreme load each processor can be fully utilized by one single-thread Node.js process). Then Nginx serves requests on port 80 by fetching the response from one of those four internal ports in round robbin fashion.
If one of the processes crashes due to a bug or you want to specifically restart it so that a new code update takes effect in production then Nginx will automatically remove it from the pool while it is down and then add it back when it comes back online. When you are pushing out code updates you can cycle each process one at a time to do a zero downtime deploy.
The other cool thing that you can do with Nginx reverse proxies is use the proxy_cache as a robust cache layer to almost completely remove stress from your blog under high load.
Honestly for a basic personal blog this technique probably isn't really necessary. You could just run it through Forever on port 80 with no Nginx and forget it, but if you expect tons of traffic, or if you want high 99% uptime, or if you just want to have some fun configuring a server then the technique I explained above is how you do it. It takes some fiddling to get Nginx configured properly and that tutorial I linked actually leaves out some details of the upstream server configuration but its pretty easy to figure out from the Nginx documentation.
[1] http://0v.org/installing-ghost-on-ubuntu-nginx-and-mysql/