That seems rather disappointing considering the amount of hype the project got with the kickstarter, and then launch, etc.
I've played around with an install and ran a blog on it for a bit, and was never too impressed. The functionality and features all seem simplistic (Which isn't a bad thing in itself), but made me wonder why I had to download what felt like hundreds of packages with npm when I installed it.
Even with all of the features they promised in the kickstarter that have now been cut, I never quite understood why they needed so much funding to create the project.
I hope they are able to do better in the future, if only to have a good alternative to WordPress, and to maybe deliver on things that they have shelved.
Edit: Looks like ghost has 38 direct dependencies in NPM, of which many have their own dependencies, etc.
> Edit: Looks like ghost has 38 direct dependencies in NPM, of which many have their own dependencies, etc.
That's awesome! There's so much bad JavaScript around where someone writes their own case insensitive sort() function, or their own state machine, or scrapes wikipedia for ISO codes or currencies rather than using country-data.
It looks like ghost is working on the parts that actual deliver value to their users and letting common, well maintained projects do the common stuff.
I guess you're implying that all those packages out there aren't as poorly-written as it would be if someone wrote it themselves? Have you actually looked through some of those packages published on npm and depended on by huge projects?
I pick modules with a long maintenance history, frequent releases, lots of contributors, lots of stars, passing tests and great documentation. So do most people in npm - you can tell from module popularity stats.
I've been working on a lot of node stuff and lately I've been noticing how crazy big some of the dependency trees end up becoming. So I just did a quick check on ghost: currently there are 487 total dependencies in the dep tree when you do an `npm install ghost`
To be fair, there is some overlap. For example, "debug", a fairly common package, is included in various parts of the tree 8 times, though there are 3 distinct versions being used.
(Keep in mind these numbers are not including dev dependencies. If we add those in, the tree balloons to over 1,400 dependencies!)
The issue with the node ecosystem is that they (we?) have really taken the mantra of "Do one thing and do it well" to heart. Most of the dependencies you load are tiny and only do one thing.
Whether that's ultimately a good thing, I don't know. Maybe NPM is just too explicit in showing you everything that you installed.
But there's now this shrinkwrap thing now that promises to slim down those huge dependency trees. I haven't played with it too much yet, but smells promising.
Shrinkwrap doesn't slim down the trees, it just makes sure the whole tree is locked to specific version, so your Linux server doesn't end up installing a different version of some package than your Mac does.
You might be thinking of npm 3, where modules are installed at the top of the tree first, and there's only extra copies of a module down the three if something specifically needs a different version of that module.
The issue is that the Node ecosystem embraces not sharing libraries so you end up with n^2 growth in packages for size. There are lots of small Ruby gems, but you can only require one version of a Ruby gem per runtime so it keeps things much smaller.
But also much more fragile. I've spent far too many hours in dependency hell on ruby / java projects when 2 packages required different versions of another package and you have to continually fiddle with versions to get them all working smoothly. I love that NPM packages have their own dependency tree so you're never stuck in that situation.
Automatic dependency resolution a-la Ruby's bundler should be required for any respectable dependency manager. In my experience, the algorithm nearly always automatically finds a successful set of dependencies, and when it doesn't, it is because I really have incompatibility that requires code changes in one dependency or another, and further verification. That isn't "dependency hell", it's just the reality that upgrades to one set of interfaces often require changes in another set that depends on them.
I never have problems with Ruby any more. Unless the gem is using the FFI or something weird it everything almost always works. In fact I've had way more problems with Node than with anything else.
Unlike you (with respect to your opinion), I found it to be absolutely perfect. I am surprised they don't make more revenue.
EDIT> Just to add more information regarding how Ghost stacks up against other free alternatives for Blogging Coders:
Jekyll
I tried Jekyll with skeleton.
Very easy installation onto github, and the fact username.github.com automatically links to your blog is great. The downside is ofcourse you have to install a them for it to be usable, and perhaps for many , having your blog edits in your official github account, may not be perfect.
Medium
I also tried medium but I did not like:
1) The constant modals asking you to log in
2) The fact Medium posts are automatically negatively ranked by HN
Just an FYI, you don't have to use Jekyll with github. The integration seems convenient, but I run it on its own to build my static site (blog) on my own domain.
I'm using my own SSL-encrypted domain while still hosting Jekyll from a GitHub repository (well, actually, a couple of GitHub repositories, one for each subdomain): https://r3bl.me
Setting a custom domain is as easy as adding a CNAME file that contains your domain (so, it'll have "r3bl.me" in my case) and changing CNAME records to point to your GitHub repository (or repositories).
SSL support is kind of hacky, but I successfully implemented it using CloudFlare.
I've recently rolled a few sites using Jekyll and Github pages. I recommend creating a new Github account or Organization (I didn't mess around with those, but it should work the same) if you feel uncomfortable pushing your blog to yourUsername@github.io.
> Edit: Looks like ghost has 38 direct dependencies in NPM, of which many have their own dependencies, etc.
This ended up putting me off. Sure, npm makes it easy to install/upgrade all the deps, but if one of the problems with WordPress is that it's a sprawling maze of potential security holes, this sort of setup really isn't the answer.
Most of the time you probably want 5% of any huge products features, the issue is everyone wants a different set. Often you can find a more focused project that works or roll your own with far less work than you might expect. Especially if you would need a highly customized version of that "huge" project.
They've proven that they've got a crank that takes in money (labour) and puts out money. The question is whether the ratio is good enough or if the right kind of investor can help improve that ratio.
I've played around with an install and ran a blog on it for a bit, and was never too impressed. The functionality and features all seem simplistic (Which isn't a bad thing in itself), but made me wonder why I had to download what felt like hundreds of packages with npm when I installed it.
Even with all of the features they promised in the kickstarter that have now been cut, I never quite understood why they needed so much funding to create the project.
I hope they are able to do better in the future, if only to have a good alternative to WordPress, and to maybe deliver on things that they have shelved.
Edit: Looks like ghost has 38 direct dependencies in NPM, of which many have their own dependencies, etc.