I think there is value, but we as a community are not yet ready for it. The problem is that the "full stack" endgoal is itself shifting in definition, towards single-page apps.
There is not much appetite for the creation of a RoR clone, when the landscape in which RoR was created has shifted so much. The biggest piece missing for a full stack solution in clojure is the client-side solution. There has yet to emerge a dominent client-side cljs library or paradigm. And without that, the full-stack solution is not that full. With that in place (and I'm confident it will come in 2013), what I'd like to see is an end-to-end solution that puts immutability first, including on the database side. We have datomic, but we also have the principles to implement a proper data model within the context of traditional databases. On Fri, Jan 11, 2013 at 11:52 AM, Paul Umbers <paul.umb...@gmail.com> wrote: > I've been experimenting with Clojure web services recently, and posting the > work on GitHub and my blog. > > 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 -- 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
