-
Notifications
You must be signed in to change notification settings - Fork 99
Add Devcards as an option #29
Comments
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. 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
|
If people are lurking here, would love to have some more opinions. cc @swannodette @jellea @mklappstuhl |
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. |
Maybe a good alternative to adding them as 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 :) |
@martinklepsch I quite like that idea! Chestnut really should also get its own web presence, and then we can host these tutorials there. |
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. |
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 After all, including code in a generator does nothing for existing projects which want to start using the library. |
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 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. |
Yeah, absolutely. What I really mean is to agree with @swannodette's point above. Chestnut is most useful if it's minimal and impactful. |
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 |
Closing this, Chestnut will mostly be in feature freeze from now on, until we can migrate to a more modular approach using rewrite-clj. |
Would you accept a pull-request for this?
I think Devcards is very beginner friendly in that it allows you to develop your application bottom-up, creating small components that work and only later figuring it out how they should play together. However unless you are using the
lein-devcards
template, trying to configure it to work with your existing project can be overwhelming for someone not used to working with Leiningen.The text was updated successfully, but these errors were encountered: