Live data from Hacker News

Introducing Ghost 2.0

blog.ghost.org

81–90 of 111 posts

Re: Introducing Ghost 2.0

#81

Earlier quoted context omitted.

That is what I am moving to. I currently use their hosting but plan on moving to a DigitalOcean box soon.

I remember when they launched with a $5/month hosting plan, then when they raised it to $10. Just looked at the pricing page and the minimum is now $36/month (or $29/month billed yearly). That's some serious sticker shock. Is it that much better than say, Squarespace?

The thing is, it doesn't matter if it is that much better than Squarespace or WordPress, that's just way too much money for a personal blog, even before the conversion to AUD I'd have to face.

Re: Introducing Ghost 2.0

#82

Heyo, John from Ghost here. Thanks for the kind words so far about 2.0 — it’s been a hectic few months! Earlier this year I talked about how we were shifting focus from simplicity to power - https://blog.ghost.org/5/ - and this is the first big release since that move. Whereas early versions were extremely opinionated and rigid, we’re now starting to bake in more flexibility and configurability to allow for a more di…

Hell yeah, John. I've absolutely loved watching you and your team grow over the years. Congrats and best of luck moving forward :) New stuff looks excellent.

Re: Introducing Ghost 2.0

#83
post #8

Earlier quoted context omitted.

> New features require building a routing map for all possible URLs on boot, which is a dramatically heavy operation. We were eventually forced to forgo our traditional ORM layer entirely to get any degree of performance (insert: shock/awe) - Related: It turns out SQLite3 has a query limit of 999 SQL variables, so we had to implement a recursive query strategy for SQLite only. Wild. Out of pure technical curiosity, h…

We're loading all public-facing resources - so posts, tags, authors and importantly the relations between them - in as few queries as possible, using fairly typical where...in queries in order to build the relations. SQLite uses variables for in queries, and so sites with a lot of content triggered the "more than 999 variables" error. Solvable, of course, but quite an interesting limitation to discover!

I discovered a similar limit with postgresql, mainly due to the protocol sending the query length as a 16-bit number, limiting the total length to ~65k characters. In that case it was far better to create a temporary table and JOIN that rather than using an " IN (..)" clause anyway, so that's another option if SQLite supports it.

Re: Introducing Ghost 2.0

#84

I’m amazed no-one has mentioned the lack of a built-in commenting feature. The makers of Ghost are here appreciating the benefits of comments but sadly they haven’t made there way to Ghost yet. I’d love to move to Ghost from Wordpress but commenting is essential. And no. 3rd party Garbage like Disqus isn’t a viable option.

My current favorite solution for comments is Discourse — they actually have a great plugin for WordPress that replaces the default WP comments. Maybe overkill for some, but really nice when building a real community (ongoing discussion rather than drive-by commenting) is a priority. I could see this being a similarly nice solution for Ghost! Though simpler native commenting support would be cool too.

Re: Introducing Ghost 2.0

#85

I would love to see an official static site mode for Ghost (and Wordpress). That way we can get both a nice authoring experience and the low cost/security of S3 hosting.

This is the first thing I googled after I saw this update.

Re: Introducing Ghost 2.0

#86
post #67
post #48

Earlier quoted context omitted.

This is always the first thing I look for in the new version announcements for big blogging platforms. Would be amazing if I didn't need to know a completely separate technology and/or hack together bridges/site "staticizers" in order to have a quite basic functionality (the site be 100% static when no back-end dynamic interaction is needed). That said, there are third party plugins for WordPress that do this. Don't…

Check out Publii, then (Open Source too). It's quite similar to WordPress in a lot of ways, but it's a desktop app that uploads static files. https://github.com/GetPublii/Publii

Thanks for posting this recommendation, I've been looking for a static blogging tool like this.

Re: Introducing Ghost 2.0

#87

I’m amazed no-one has mentioned the lack of a built-in commenting feature. The makers of Ghost are here appreciating the benefits of comments but sadly they haven’t made there way to Ghost yet. I’d love to move to Ghost from Wordpress but commenting is essential. And no. 3rd party Garbage like Disqus isn’t a viable option.

A lot of blogs do just this... use Hacker News, Reddit or Twitter as their comments. Comments on blogs have become less relevant as time goes on. That being said, there are some decent Open Source Disqus clones out there you could probably use!

Blog comments are visible and open to anyone reading the blog post. And the blog author can always see them and reply to them instead of chasing discourse across the internet.

Reddit and HN topics become read-only after some time, so I'm not sure how they can replace blog comments.

Twitter for comments, I don't understand. I guess you link to your canonical tweet and people reply to it? I find threaded conversation on Twitter to be just about unbearable.

Re: Introducing Ghost 2.0

#88
post #8

Earlier quoted context omitted.

> New features require building a routing map for all possible URLs on boot, which is a dramatically heavy operation. We were eventually forced to forgo our traditional ORM layer entirely to get any degree of performance (insert: shock/awe) - Related: It turns out SQLite3 has a query limit of 999 SQL variables, so we had to implement a recursive query strategy for SQLite only. Wild. Out of pure technical curiosity, h…

We're loading all public-facing resources - so posts, tags, authors and importantly the relations between them - in as few queries as possible, using fairly typical where...in queries in order to build the relations. SQLite uses variables for in queries, and so sites with a lot of content triggered the "more than 999 variables" error. Solvable, of course, but quite an interesting limitation to discover!

This sounds like an interesting usecase for a graph database, is that something you have considered?

Re: Introducing Ghost 2.0

#89
post #8

Earlier quoted context omitted.

> New features require building a routing map for all possible URLs on boot, which is a dramatically heavy operation. We were eventually forced to forgo our traditional ORM layer entirely to get any degree of performance (insert: shock/awe) - Related: It turns out SQLite3 has a query limit of 999 SQL variables, so we had to implement a recursive query strategy for SQLite only. Wild. Out of pure technical curiosity, h…

We're loading all public-facing resources - so posts, tags, authors and importantly the relations between them - in as few queries as possible, using fairly typical where...in queries in order to build the relations. SQLite uses variables for in queries, and so sites with a lot of content triggered the "more than 999 variables" error. Solvable, of course, but quite an interesting limitation to discover!

I haven't check the code, but as few queries as possible is not always the best approach. I bet you guys spent a lot of time on the problem, but still very curious how you landed with this decision.

For the relation data, you should check out Hexastore [0] (essentially graph storage). It takes up much more space, but you can follow any paths of relationship and you can do it step by step instead of loading everything at once.

[0] http://www.vldb.org/pvldb/1/1453965.pdf

Re: Introducing Ghost 2.0

#90
post #83
post #8

Earlier quoted context omitted.

We're loading all public-facing resources - so posts, tags, authors and importantly the relations between them - in as few queries as possible, using fairly typical where...in queries in order to build the relations. SQLite uses variables for in queries, and so sites with a lot of content triggered the "more than 999 variables" error. Solvable, of course, but quite an interesting limitation to discover!

I discovered a similar limit with postgresql, mainly due to the protocol sending the query length as a 16-bit number, limiting the total length to ~65k characters. In that case it was far better to create a temporary table and JOIN that rather than using an " IN (..)" clause anyway, so that's another option if SQLite supports it.

There's no 16bit number limiting query length in PG, the limit is 1GB and has been for a LONG time. But it's indeed often a good idea to use a temp table for some of such cases.
Post reply on HN