Refactoring sass and less integration into their own separate components
Definitely! The whole less/sass thing needs to be reconsidered. For SASS I’d like to move to sass4clj-component , which is based on sass4clj . It uses JNI to bind with libsass, meaning in the end it uses the same SASS implementation as sassc.
There’s also less4clj , there’s no corresponding less4clj-component apparently, but that shouldn’t be too hard to create.
Component integration for cljs
I’m not against this, but also not 100% convinced we need it. My current feeling is that for what Chestnut currently does it’s overkill. On the CLJ side introducing Component makes sense because it allows us to clean up and streamline stuff we’re already doing. I don’t see that so much on the CLJS side.
My mind might change on this, I just haven’t used Component at all so far on the client side, but I’m planning to use Sente for a project so I might give it a try. A concrete example of how this would look in Chestnut would also be helpful.
Skeleton for configuration
I understand the need/want for this, and mainly want to balance that out with Chestnut’s desire for minimalism. If there’s a common pattern that people are using for this, that’s easy to wrap your head around, that doesn’t add much boilerplate, and that I find aesthetically pleasing (;)), then I think I’d be all for. I think for this one it would be best to discuss concrete proposals.
(long diversion ahead)
I think it makes sense to talk a bit about the principles that I think make Chestnut what it is, and also where Chestnut is situated in the “market”
Chestnut tries to be “minimal but complete”. It provides a hand picked stack of libraries and tools, preferably things that are pretty standard and widely used, all integrated to “just work” out of the box. It provides the glue to make it all work together, and it provides a skeleton so you have some obvious entry points where you can start adding code.
That’s where it ends. In particular generated code should not contain any code that actually “does something”, like custom middleware, or custom components, these should all be provided by libraries.
Chestnut aims to be user friendly and accessible for beginners. It does this by being small enough that it’s easy to wrap your head around, by being unsurprising (try to follow patterns you might see elsewhere), and by being well documented. This last part is very important and is something that I’d like to further improve in the future.
I think the two main “competitors” at the moment are Luminus and Duct. Their goals are different enough though that there’s still room for a Chestnut. I also think Chestnut is more focused on ClojureScript than either of those. I’m really liking what I’m seeing from Duct, but it’s decidely harder to wrap your head around, it’s also scarcely documented. I think Luminus is fantastic for someone looking for a complete Rails-esque complete solution and doesn’t care so much for minimalism. Luminus is superbly documented, definitely an inspiration.
Regarding the future, my own insights as well as those of the community as a whole have evolved over the few years that Chestnut has been around, and I think it makes sense that Chestnut evolves with those. This does not violate Rich Hickey’s “rename if you change it” rule, because Chestnut is not a library. We don’t break existing apps by changing Chestnut. The main reason I’ve held off of extra features, especially extra optional flags, is because of rising complexity in testing and maintaining the template. I used to test that live reloading of code+css worked, as well as the browser repl, for every combination of flags. I’ve tried to automate this but it’s tricky, so it’s still mostly a manual process. However I’m willing to relax my stance on this, other templates have dozens of flags and seem to be doing fine. We’ll just have to be careful not to break things