Add Devcards as an option about chestnut HOT 11 CLOSED

Hadn't heard of it before. It looks neat on first glance, but I'm starting to see a pattern here of "how about adding support for $x", and I feel like I need to push back a bit on that. chestnut.clj is already getting convoluted. Before we add more stuff there I feel it should be rethought a bit to make the options more modular to implement. I have some ideas but as always not sure when I'll get to it.

Also, as we add more of these options the number of cases to test grows exponentially. I try to manually test every option before releasing a new version, but this is going to get painful. We really could use some automated testing, but that's hard because you'd need a full integration thing to e.g. test that reloading in the browser works as expected.

As a general guideline I'd say options to "support $x" can be added if

• multiple people ask for it
• $x is considered somewhat mature/stable
• adding $x to your project requires several non-trivial steps
• it fits in the philosophy of Chestnut

from chestnut.

If people are lurking here, would love to have some more opinions.

cc @swannodette @jellea @mklappstuhl

from chestnut.

DevCards is very cool but I think still very experimental. To speak to the larger desire around Chestnut to get pet features in - I think Chestnut should stick to a small set of the most impactful features / options. To me that's the config free web server, REPL, dev/prod builds, deploy, and testing. Anything else should be included only if there's seems to be a strong community desire for a something that represents best practice.

from chestnut.

Maybe a good alternative to adding them as --flags would be to add "recipes" to the project that detail how one would go about adding things like clix or garden. I imagines these to be basic .markdown files in a separate directory, linked to from the main Readme file. This would reduce the amount of code in the template that people don't understand because they haven't seen it.

I feel like having the template tested + adding a basic testing setup for users should be of higher priority right now. (I'm guilty myself though as I was trying to get Garden merged in hehe :)

from chestnut.

@martinklepsch I quite like that idea! Chestnut really should also get its own web presence, and then we can host these tutorials there.

from chestnut.

With regards to supporting additional pet features, one point I'd like to make is that I think the value that a user gains from using the template is proportional to the complexity of configuring the features they would like to have. Having a feature that does nothing more than adding a project dependency doesn't make a big difference, as anyone should already know how to do that on their own. For the more complex features one can get many of them from one template or another, but the more of them you wish to use, the more complex getting all of them to work side by side becomes. For example when it comes to Devcards, even though I have used it before and played around with setting it up, it's not at all obvious to me on what the best way to integrated it with Chestnut might be. A lot of the cognitive burden of configuring a sufficiently complex project is not in finding out how things work, but in the abundance of choices one can make.

This of course creates some conflicts in trying to keep the complexity of the Chestnut template itself manageable, and I agree that a web presence with tutorials might be a good compromise for the time being.

from chestnut.

It seems to me that the desire to include these libraries in Chestnut is a smell. In fact, the need for Chestnut to begin with is a smell (meaning no disrespect or lack of gratitude for @plexus's work).

In an idea world, these pieces would be so easy to set up and so orthogonal that a template would be completely unnecessary. Indeed, most libraries simply require a one-line addition to the :dependencies list. I think the question to ask in pushing back is: Why is setting up this library so difficult that it's worth including the boilerplate in a generator? Sometimes, there will be a good answer, and that's why we still need Chestnut and other templates, but if the library can be improved instead, it should.

After all, including code in a generator does nothing for existing projects which want to start using the library.

from chestnut.

In an idea world, these pieces would be so easy to set up and so orthogonal that a template would be completely unnecessary.

I guess we don't live in an ideal world then, alas. For someone new to Clojure, just letting Figwheel play nice with a browser connected REPL is a major PITA. I agree in general with the Clojure community's preference for composable libraries over frameworks, but the hurdle of just setting basic development stuff up so you can start tinkering is huge, and it's hampering adoption.

If you want to learn Rails, you do rails new myapp and you're rolling, the rest you can learn step by step. For someone coming in cold just a "Hello, world" with Clojurescript takes a day or more.

Chestnut is not so much about libraries that your app uses, but just about a sane dev setup that represents the state of the art, works with zero extra setup, is ready to be deployed, etc. More experienced users might have varying opinions on what a "sane state of the art dev setup" includes, and for those we have options to deviate from the defaults.

from chestnut.

Yeah, absolutely. What I really mean is to agree with @swannodette's point above. Chestnut is most useful if it's minimal and impactful.

from chestnut.

FYI there's a documentation site now for Chestnut. This would be a great place for adding tutorials on adding/using extra features/libs.

Just drop a Markdown file in the doc/ directory, I can handle the rest. Result at http://plexus.github.io/chestnut/

from chestnut.

Closing this, Chestnut will mostly be in feature freeze from now on, until we can migrate to a more modular approach using rewrite-clj.

from chestnut.