DocPad

[jtwebman]

How is this any different then DocPad?

[zspecza]

Hi @jtwebman - there is a small note on the rtfd.org site regarding this comparison (it's the first bullet point):

DocPad: Powerful, but complex interface for users and developers. Roots has the same power, and is complex for developers, but simple for users.

@jenius can probably give a more detailed breakdown of the differences if asked, but he is occupied with the adventure of a life time at the moment, so do not be alarmed by sparse response times. :)

Speaking from limited experience with DocPad, I much prefer Roots' simple configuration and file-extension based workflow, without detracting the ability of hooking very deep into internals if need be with it's super powerful extension system.

If it's not the internals and abilities Roots provides, it's the completely awesome level of warm, friendly support you get from the team here and their persistent encouragement for and welcoming nature towards contributions, even going so far as to provide the necessary starting point when one is clueless as to where to begin adding a feature or fixing a bug.

Since I started using Roots some time ago, back when it was still early 0.2.0 - I have seen my productivity and development speed shoot up exponentially and have even grown as a developer through reading the very well-documented and clean source code and discussing things here with the Roots team, so much so that it has positively affected my career in ways I could never have imagined and opened me up to opportunities I'll never forget, which is not something a lot of self-taught 22 year olds can say for themselves.

I urge you to give Roots a try and form an opinion of your own - and please do share that opinion, every bit of feedback helps. :)

[jescalan]

Yeah Declan covered it quite well. This question is essentially the same as asking "how does using snapchat differ from texting a picture then deleting it?". At it's core the two products aim after the same problem, building static sites, but they handle it in very different ways. You could ask the same thing about middleman, grunt, brunch, or any of the other large numbers of static site builders. What it comes down to is that you should watch some of the tutorial videos on the site and try it out yourself. While you might come out with a static site from any of these tools, it's simply a different experience building it. Roots focuses on less and simpler configuration to get you up and running faster.

Closing this issue as it's not an actual issue under active management, but feel free to continue discussion here!

[jtwebman]

I actually think it is very different then asking the grunt and gulp question and I feel the analogy is a little off. After watching the videos and playing around with a site I think it is like the difference between Instagram videos and Vine videos. I think maybe you guys have never used DocPad because from what I see they are exactly the same thing with only minor differences like 8 sec video vs 15 secs video.

Here is what I see and some of what I think is missing that Docpad has:

1. The config looks like it forces me to use coffee script. I am one of those people that really doesn't like CoffeScript. Docpad lets me write the config in javascript or even json if it is simple.
2. Accord just makes it a little easier when you start out but that really is it. Docpad just does this with plugins. The plugins way is much better because I don't have to wait till accord supports the library or send you a pull request. Also maybe my library isn't public so it wouldn't make sense for you to put it in Accord. I can just build the Docpad plugin with no other dependencies. In Roots I am guessing I could write my own extension to do this just seems strange having accord and extensions when it could all be done with extensions.
3. I am concerned that your employee page was dynamic. In Docpad you could easily have done it with collections and then markdown or yaml or what ever you wanted. Unless maybe the employees could update the data themselves. Roots-record requires json Docpad it could be anything. Paging also is no issue in Docpad. It can be easily setup to generate each page. The advantage being that it all gets indexed by google.
4. Client-templetes was a really nice feature that Docpad is missing though if I needed it for something I don't think it would be hard to add in. I would love to see it done with React vs Jade. My only concern is client-templetes is dependent on Accord.
5. The Wordpress thing is cool but Docpad does that as well as you can use Tumblr, Medium, MongoDB (Really and DB).
6. Templetes was nice but Docpad has skeletons which are very close to the exact same thing.
7. Last, when I played around with the code you end up changing the config so much but then you have to restart the watcher. Doesn't seem like a hard task to add in that the watch auto resets when the config changes.

So from my point of view you are rebuilding Docpad. You both even like CoffeeScript. Image if you guys would have just worked with Docpad and added maybe client-tempeltes how much farther along both of these would have been. This is why I asked the question because you guys are both doing the same thing. Comparing to Wordpress or Grunt doesn't make sense but Docpad and you do the same thing, almost exactly.

[jescalan]

Hey @jtwebman,

Wow what a post. Appreciate you taking the time to write this out and your point of view. Unfortunately, I just can't totally agree with you. You started out saying that they are the same and we are rebuilding docpad. You then followed this up by pointing out that there are a bunch of things that are different between docpad and roots, but that you like docpad better. I could make a very similar comment to this for brunch, middleman, grunt, and gulp quite easily. It would say that some things were the same, some things were different, but I preferred X or Y. On top of that, roots is not like a new thing we just started. We started building roots more than three years ago, when docpad was in its infancy and not even similar to what it is now.

Let me respond to the concerns you brought up here:

1. We considered adding a javascript config option, but never followed through because there wasn't enough demand for it. Coffeescript is just cleaner for simple things like config files. You aren't doing any heavy lifting with the code, just config. It would be a very easy feature to add if someone was interested and sent in a PR.
2. Are there any languages you plan on using that are not supported by accord? I see where you are coming from in theory, but you'll find that in reality accord provides a much simpler and more trustworthy way to deal with compiled languages. You don't need to sort through and find one of potentially a few third party extensions, figure out which one is still maintained, then load it in with any of its dependencies. You just install the compiler direct, add the extension, and that's it. You can trust that accord is actively maintained and thoroughly tested. The team behind this project is quite active and you'll find that getting another language accepted to accord takes no time at all if you have written a thorough implementation and tests. And if you haven't, we'll work with you to get it up to speed.
3. The employees update the data themselves through an API. It could easily be static if we wanted. In fact, we could easily convert it back to static using roots-records, we just haven't got around to it yet. Most of carrot.is is controlled by a CMS.
4. You seem to be worried about accord, but I don't get why. Have you had problems with it? Client templates work perfectly fine, give them a shot. We already have full support for jsx in accord and a template for a working react app in roots and have had this for a while. I'm interested in using react with jade instead of jsx as well and it is feasible, just have not implemented all the adapters for it yet, personally. I'm traveling this year and have less working time than usual. But if anyone is interested in speeding up this process would be happy to work with them. Honestly it shouldn't take more than a day or two to get the tools in place for this.
5. We could and would add any of these services if we had a need for them. It generally takes us about one work day from a single employee to add a vendor-specific extension. Wordpress extension took me about a day. We build things as we need them. If there's something you need, we would be happy to work with you and make it happen.
6. We have an entirely separate and very robust library for this called sprout. In fact, as you have seen with accord, much of roots is actually split out into other independent libraries. Anyone is welcome to use these libraries independent of roots. Roots is just the glue.
7. Wouldn't be hard, just hasn't been a high value feature for us. If anyone wants this it shouldn't be tough to add.

If you like docpad better, that's entirely ok, you are welcome to use it, and not use roots. If you have a docpad feature that you like and wish roots had, we can discuss that particular feature and I'd be happy to break down why we made the decision that we did. But if you think that roots is "rebuilding docpad", it simply could not be further from the truth. They are two entirely different products that handle building static sites in different ways. The only thing that's similar between them is that they produce a static site in the end.