On Thursday, November 14, 2013 2:28:51 AM UTC-8, Sean Johnson wrote: > > Framework vs. ecosystem of interoperable libraries. The monolithic > framework (see Rails and Django) is not the way web development is done in > Clojure. Instead imagine the Clojure world as a set of legos. You get to > build whatever you want with your legos, selecting just the blocks you > need, in the colors and sizes you want, and they all snap together [1]. The > benefit to this approach is simplicity. There is a LOT to know about the > Rails and Django frameworks, as they are big, mature things that have grown > to solve all the common web development needs, and you start your > development with ALL of that framework. Your starting point with Clojure on > the other hand is much simpler. It will seem too simple... at first you'll > be wondering... where is all the "stuff"? You start with maybe just ring > and compojure (web middleware and routing) and a few lines of your code and > your first couple of stories are already complete. You add libraries as you > find you need them as you build out your app over time, but at all times > your app is as simple as it can be, and only has the "stuff" it needs. It's > therefore much easier to understand and less a "big ball of mud". >
I don't believe the legos analogy is very accurate for clojure. Or, rather, it's more of a vision than a reality. I'm unaware of any libraries in clojure that you can piece together to give you the features of django-south, django admin, and the forms/validation/db layers, for example. Today, clojure web libraries are more like an auto parts store: your chance of putting together a complete car from the inventory is slim indeed, and your chance of doing it in a timely fashion is exactly zero. There are about a dozen migration libraries for clojure, for example, but none of them integrate very well with the other libraries because there isn't much in the way of a data modeling framework for the different components to leverage. Also, I don't think any of them provide the simplicity of south, where your data model is declared in one place (rather than in a sequence of sql commands that you have to interpret to deduce the final data model), and migrations are derived from changes in the data model. The putting of things together is the hard part of software engineering. This makes a huge difference in development time. Clean algorithms are easy in comparison. Rich talks about the importance of taking things apart, but you can't take things apart that never fit together in the first place. IIRC he actually suggested that one take things apart such that they fit together again. I agree with this, but I don't think it describes much of clojure web tooling today. Also, the overwhelming majority of db and web work is boilerplate. That's what django provides: all the mindless boilerplate that is completely uninteresting to your problem domain, but necessary to launch a web site. With the current clojure web tools, there is no solution for most of that boilerplate, which can easily add an order of magnitude to your development time. And again, I will have to reevaluate all of this in light of caribou, which appears to address much of it. Also, I'd be very happy to hear that I'm wrong, if anyone has example projects to show, or libraries I've missed. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
