A good thought/discussion provoking post, thanks. I find myself between two camps here. On one side and coming from the position of both learning Clojure and coming back to web development after a long period of mainly working on large backend database apps, the suggestion of a nicely bundled and complete clojure web framework is appealing.
On the other hand, having been required to become familiar with some frameworks, such as spring, being forced to search through large quantities of documentation and then finding 80% of what it offered was not relevant to what I needed for my application, I'm far less enthusiastic regarding complete frameworks. I think there may be two different requirements here which need addressing. The first is for those, often new to clojure, who would like to get up and running fast. They have a new idea to start developing and don't want to spend hours evaluating lots of different, but outwardly similar libraries - especially as they may not yet have the knowledge to easily make such decisions. The second requirement is for more experienced or knowledgable devs or those who have a well defined design who just need to know which specific libraries to use. I suspect that as you gain web dev experience with clojure, you will move more twards the second group. If this is the case, complete frameworks are likely to be of only limited benefit while you become familiar and experienced. This may asiist adoption to some degree. However, as individuals become more experenced and accustomed to a more clojure style philosophy of fewer and more specific libraries for a task, they will likely move away from the framework. Unfortunately, this may have a detremental impact on the maintenance of such a framework as it may be difficult to attract or retain interest as experience grows. I think possibly the best way to assist adoption and also provide valuable content for more experienced developers are things like case studies, examples and reviews which cover the various libraries and their use. Example dependency templates etc may also be useful. Blogs such as yours, where you document your experiences and give examples are very valuable. Articles like the hooroku one or Andrew Brehaut's one are extremely useful and valuable. Possibly what would be very valuable would be one consolidated place where all this valuable information could be found. Someone interested in clojure and web development could just go to a single place and find a majority of the good articles, case studies, overviews and evaluation of web dev relevant libraries and techniques/idioms for Clojure. Ideally, this would just be part of another well know Clojure documentation site. Tim On Saturday, January 12, 2013 3:52:05 AM UTC+11, Paul Umbers wrote: > > I've been experimenting with Clojure web services recently, and posting > the work on GitHub <https://github.com/3rddog/doitnow> and my > blog<http://internistic.blogspot.ca/search/label/clojure> > . > > When putting this test app together, it occurred to me that most other > languages have a full-stack API available which makes life easier when it > comes to making decisions about which libraries/APIs/frameworks to use. It > also reduces the possibility of "impedance mismatch" between the libraries. > For Java, you can use Spring (or any one of a dozen or more other popular > frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, > Ring, several logging, validation and database libraries, and they can be > used together but they don't constitute a coordinated full stack - and that > creates issues. > > For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and > not the latest version of Ring (1.1.6) which has significantly better util > functions available - but I can't use them until Compojure catches up. By > the time you add logging, validation, data access, etc the odds of a > mismatch between these libraries goes up dramatically. > > This is a concern, because these mismatches must be worked around in *my*code > and are likely to break as the libraries are upgraded in future > versions. So, I'm having to spend my time maintaining what are essentially > "patches" for third-party libraries just so that they work together. > > Now, it may not be the best decision to try to put together a true > full-stack framework from scratch, but is it worth choosing a bunch of > existing frameworks and coordinating their releases - in much the same way > as Eclipse coordinates plugin releases for major releases - so that putting > together a full-stack app becomes easier? > > Projects taking part in the "meta-project" will work together to harmonize > their functionality & APIs, and coordinate their development cycles & > releases so that the meta-framework remains consistent and easily usable. > > Is this another barrier to adoption the Clojure community can remove? Is > this even a barrier? Am I missing something? > > Thoughts? > > [Also posted to http://www.reddit.com/r/Clojure] > -- 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
