Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
GitHub is one commit away from being the ultimate blog engine (dockyard.com)
168 points by bcardarella on Nov 14, 2011 | hide | past | favorite | 43 comments


A major feature that Jekyll is missing is commenting. Relying on Disqus, a closed source platform, is not ideal because it slows down page load times, does not contribute to SEO, and it does not let you host and search for comments in your git repo.

Some people argue that adding a dynamic commenting system contradicts the static html goal of Jekyll. Going along those lines, critics say that a conversation is best carried out on 3rd party sites like HN. However, for technical blog posts specifically, a two-way conversation helps illuminate finer points in the original blog post.

Googling around for 'jekyll comments' or 'disqus open source alternative' reveals many people who would use such an idea. However, aside from some quick-and-dirty projects, I see no compelling open source alternative to disqus that will include features such as OpenId, spam prevention, comment threads, etc. Does anyone know of such a project?


Engineer from Disqus here, I work on the front-end side of our product.

Disqus doesn't slow down page load times because we use a non-blocking technique to load required files. We work hard to make sure that we don't add any performance regressions to sites using Disqus.

We are also working on making comments made via our product indexable by search engines.

As for the open source version of Disqus, I am not sure what you mean by that since Disqus is a service and not a program that you can download and install. People prefer Disqus because they don't want to spend time implementing and hosting discussion platforms for their websites just like people using GitHub don't want to spend time implementing and hosting developer collaboration software.

Anton

P.S. If you are having problems with Disqus slowing down your page, email me at anton@disqus.com and I will check it out.


If we put the ideological issues aside there are some other potential issues about using Disqus that I have thought of:

1.) Control of data, I am not sure what rights I am legally signing away to Disqus when using it as my comment service.

2.) Continuity, I am certain that if Disqus passes away the service won't be there and only fools would offer a free service and ensure that the data isn't lost for what ever reason. How are your data liberation policies, a simple click for a zip or a tar-ball? Or would I need to construct my own back-up using your API? If the latter, is that allowed?


You can export your data whenever you want and the process is as easy as clicking one button: http://dl.dropbox.com/u/447925/Screenshots/ao8k.png

Nothing changes when you comment on a website using Disqus—your comment is published on someone's website and becomes their data. That said, if a comment was not originally anonymous, you have an option to anonymize it so that it is not associated with your profile and name anymore. We are and will always be on commenters' side.

This is what I can authoritatively say as a Disqus engineer. If you want more information, email to hello@disqus.com and folks here will be happy to answer all your questions.

Anton


Open source software is not limited to client side code. Reddit and hackernews are examples of open source software that is also hosted as a service.


Things like HackerNews, Reddit, GitHub and Disqus are more useful to everyone using them when they are provided as a hosted service and not a deployable software.

We give site owners a hassle-free discussion platform that can be integrated into their websites with additional perks such as moderation tools, analytics, spam filters (trained on the whole network of websites and not just one) and others.

And people leaving comments on different websites are now able to manage and control their comments across the web, and use their Twitter/Facebook/Google accounts knowing that Disqus will never abuse their trust. Boxed software installed on different sites managed by different people would likely never be able to provide neither the integration nor the trust.

But don't get me wrong, we absolutely love open source. Check out our Code page[1] or our public account on GitHub[2]. We released many different projects, some of which are adored by the Python/Django community (e.g. Django Sentry). I think Disqus as a product is better when it is a service and not a boxed software.

Anton

[1] — http://code.disqus.com/code/ [2] — https://github.com/disqus/


I'm just saying that your software can be both. None of the things you listed seem like they preclude Disqus from being open source. Here is a wordpress plugin that allows visitors to comment using their whatever account. http://wordpress.org/extend/plugins/social-connect/

Also.. uh.. This is kind of unrelated but you kind of abused my trust. I wanted to post an anonymous comment and thought I needed to provide an account for spam reasons, so I logged in, left my username blank, and it automatically put my first name in as the author of the post. I have tried to avoid your stuff since. I think other people were posting things anonymously so it might have just been my fault. Still though, I'm done with it.


You don't need to log in to post anonymously. Sites, however, can disable anonymous posting if they wish to do so.


And I suppose you don't give give your email when you want to post anonymously even it says it won't be published? That's what Wordpress does by default isn't it? I think that's what Disqus also does but it isn't clear. You don't divulge people's information without explicit authorization. Filling in the name field for me is not good. Maybe anonymous is the wrong word. I didn't want my stuff published for the world to see.

Now that I go back to it, I see that it links to my twitter account and provides my first name. I was thinking that just showing my first name would only be kind of bad, turns out I was remembering it incorrectly. It is as bad as I thought it was.


Are you thinking of some kind of hybrid system, in which there's a Disqus-like web app to serve recent comments and enable the commenting infrastructure, but the comments eventually (on a timescale of hours) get rendered into static HTML in my git repository for long-term archiving, SEO, searchability, faster page loads, etc?

That sounds interesting.

My next question is: Does Disqus's API let me do this via... Disqus? Surfing through the API docs suggests that the answer may be "yes".


Yup, the API lets you do that. You can pull our your comments and sync to a local datastore.


Guide: http://docs.disqus.com/help/58 (though it's already automatic in our WordPress and MovableType plugins).


What about a form that lets someone submit a comment and it appeared as a Pull Request in your repository? Once you merge in the change, Github will rebuild your blog and it will appear. That would be kind of cool.

Or you could just have a comment link that uses the github website comments - if you are really interested in technical discussion it's probably fair to assume the poster has a github account


Hi,

For a developer, making your own Disqus is actually easy. And I have done so myself, with free hosting on top of Google's App Engine ...

http://alexn.org/TheBuzzEngine/ + https://github.com/alexandru/TheBuzzEngine

Don't expect the same polish as Disqus. This is meant for my usage mostly and I have simple needs.


> Disqus ... is not ideal because it slows down page load times

Do you know to what degree they are slowed down? I am observing that they load particularly fast (< 1 second) on this blog post.


I started down this path before they even added Ace to the site.

My idea was a little bit different: I would drop in a single file to my Jekyll repo that adds a "Create a new post" page on my blog. There is a text field with a live markdown preview and a "Commit" button that would make the calls (via javascript) to the Github API to create a new commit in the repository. This commit triggers the hooks that rebuild the blog.

The main hurdle was authentication, since Github OAuth doesn't support any client-side flows (which is understandable since it's not a completed spec, to my knowledge). So I would have to pass my user/pass in everytime.

But I got the API calls all working (after Github support helped me get CORS working), but I lost interest in the project and it's just sitting around collecting dust

The code: https://github.com/swanson/lanyon/tree/gh-pages

Demo that doesn't quite work: http://swanson.github.com/lanyon/


That's an incredibly low bar to set for something to be "the ultimate". I can smell the fanboyism from here!


Creating new files from the web-based editor is a little feature that should really be there.

There's another good use-case, which I've suggested to them: Their "We recommend adding a README..." message could just link to a markdown editor, making it really easy to put up some documentation.


I don't think GitHub is planning to nor should compete in that market. The Jekyll/blog hosting stuff has been a neat side effect and I am glad that GitHub hasn't gone out of their way to prevent that type of use but I'm sure they have no desire to be a blog engine.


If they have the talent, time, and funds (they have all three btw), why shouldn't they? The might have not a lot of competition right now, but that will change in the future I'm sure. Any competitive advantage is a plus IMHO. As a developer who uses github everyday, I love that I can use my normal workflow to post to a blog if I so wish.


I'm not advocating that GitHub should compete in the blog space. This is more of a convenience request for the sake of making the most out of GitHub Pages.


If I'm understanding correctly, the request may be in the context of blog-like usage, but the function is of much more general applicability.

I think he's just asking for the ability to create a new file from scratch in github's web interface.


While GitHub is great I think it is more likely that DropBox becomes a dominant blog engine.

Already there are things like TiddlyWiki and DropPages that do this and it's much more approachable for the average user.

I also think as DropBox teams improves and iterates it will be interesting to see more people using Dropbox for basic version control, probably not a good idea but I think it'll happen.


See my comment above. We've built and launched this at http://droptype.com. Would love to hear your thoughts.


This sounds like something I want to use. Some impressions:

The first thing I did was edit my profile, but I found that it doesn't give me enough feedback about errors. I tried changing everything all at once(of course) and then got greeted with the previous defaults. It took some trial and error to figure out that it wasn't accepting the RGBA PNG I had picked out for a profile picture. I'd also like a direct link to the markdown formatting docs, or even just a quick summary, on the profile editing screen.

My profile finished, I proceeded to look in my Dropbox folder. The README is not formatted for Windows Notepad and appears as one long line of text. I switched to NP++ and continued to write a "hello.txt" containing a link and an image. It shows up, so I go back and edit the README, too. Everything is in order, but what is this "cloud+arrow" button? Inspecting it reveals it's publishing, but I don't feel confident about whether I've published hello.txt until I log out and check.

I might continue using this. Some last thoughts:

I will probably want options to organize posts. There isn't enough documentation to know if I already have them.

I found myself wondering if there was a shortcut for marking up the image that would let me point to a folder inside Dropbox without tabbing out to find the public link.

I may not want the displayed title of README to be README.


Thanks for the feedback. Some quick responses:

- You're absolutely right, we definitely need more error feedback.

- We're planning on writing a Markdown tutorial on site and building a browser-based editor (based on Ace, most likely). Will take this under advisement.

- I need to test with more variety of profile images. I held back on doing this until I could abstract away the entire image handling code.

- We wrote all the text files on a Mac so we're probably seeing some problems with Windows vs. *nix line-endings. I'll address this tomorrow.

- You're not the first person to be confused about how we're handling publishing, so we'll address this in a UI update.

- In terms of publishing images, we want to be able to process more than just text files in your Dropbox, so eventually you'll be able to relatively link to images instead of having to host them somewhere else. Our browser-based editor will let you browse your Dropbox and select images.

- We do support custom titles (and summaries) using the MultiMarkdown formatting syntax. Just make the first line of your text file look like this:

    Title: The title I want
    Summary: A summary of my text file
And that will customize the title and give you a summary. If that title line is missing, it'll just set the title to the filename.

---

Again, thanks for the feedback and I hope you can give it another go once we make a few tweaks. I really appreciate you input.


Do you have any sample sites who are using your service? If so, you should feature them on the front page.


Not just yet, we're waiting to roll out our theme engine before we feature anyone.


Marco Ament (Instapaper) started working on a Dropbox blogging engine, where you can just maintain a drafts directory and copy it into a pending directory.

It was discussed on his podcast (Build and Analyze), don't think he's published it though.


If they put a more consumer-friendly face on it, they could probably go toe-to-toe with many other platforms out there. Not quite their core business, though.


definitely not their core business, but it seems like it is such a short distance to get there from where things currently stand. And I really like Jekyll and using GitHub to host.


In other news, google docs is one commit away from being the ultimate blog engine.


I think version control and content management are complimentary in some ways, but how is serving static files an “ultimate blog engine”? I feel like we’ve had that for a few years.

What might actually happen is that Git or Dropbox become the interface through which we “put files on the web”. One’s blog is just a subset of files that one is maintaining anyway.

That’s nice, and a consolidation of tools. But not, um, advanced.


    What might actually happen is that Git or Dropbox become the interface 
    through which we “put files on the web”.
There are some tools that exist already. Here is one that I recently discovered. http://www.kissr.co/. There was another one also posted on HN recently, I forget its name.


http://pages.github.com/#using_jekyll_for_complex_layouts

So while it is just serving static files, it's static files pre-processed by Jekyll.


We recently launched an app - http://droptype.com - that tries to do static site generation using Markdown files over Dropbox. It's still very much a proof-of-concept and we're retooling to make it a bit more full-featured; but the eventual idea is to let you let you publish web content by just arranging files on any cloud storage platform.

Again, it's still very early and this is more to prove that the idea is doable, but we'd love to hear any input. We're working on some commonly requested features like customized designs, cname redirection, rss feeds. The idea is to have a very hacker friendly publishing tool that doesn't require very much work to set up.


Github's founder Tom Preston Werner had a similar article]1]: Blogging Like a Hacker

[1] http://tom.preston-werner.com/2008/11/17/blogging-like-a-hac...


A problem with this approach though is you end up having to manage a directory full of files called MyAwesomeBlogPost.html etc. Or perhaps using a date or sequence based prefix to keep them in some order. A little tricky to manage once you have dozens of posts...so you'd want some front-end...but these days, it could be a TiddlyWiki or some other pure JavaScript app based on CORS (like swanson mentions in the present thread http://news.ycombinator.com/item?id=3235457)


I'm a coder at a big media company.

I would die to find a gaggle of people who want to work with me on a simple CMS on top of Git.


Who you see as your primary audience for this type of thing? I just don't think developers do CMS a lot


It would definitely have to be designed for the kind of crowd that's never installed Jekyll.

As paleolithic as it sounds, I think a CMS build on flat files would be a lot easier to manage than a CMS built on a relational data store.

If you don't need accounts and personalization, or can just do that all client side, you could simply load balance across micro AWS instances pulling from the git repo and stick everything behind Cloudfront -- all for a few quarters an hour.


The CMS on flat files thing has been done before, for example with a Perl script: http://www.blosxom.com/

Nevertheless I think the concept has potential if done right (and with Github or Dropbox).


I've been wanting to do this. I'm in NYC. I'll be less busy soon.

This should be done.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: