|Re: Full stack Clojure web/REST framework - is there any mileage in it?||James Reeves||1/11/13 9:12 AM|
On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote:
Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon.
Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire.
Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Paul Umbers||1/11/13 10:08 AM|
My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT.
As long as all projects stick to semantic versioning (a lot do), that problem is not so great.
The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time & effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested & compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test & evaluate frameworks.
I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain "feel" to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards).
Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Sean Corfield||1/11/13 10:25 AM|
I think there's a philosophical bent in the Clojure community toward
small, composable libraries, rather than monolithic pre-built
combinations - across all domains. This has come up in discussions
before, mostly around the "full-stack web framework" issue, and the
consensus each time seems to be we're better served by doing a
mix'n'match from the available libraries.
Scala is aimed much more squarely at the enterprise world of Java,
which in turn is much more inclined toward the full-stack approach.
FWIW, I ported my mature, popular, convention-based MVC framework FW/1
from CFML to Clojure and even tho' it's nowhere near full-stack, in
the Clojure world it's already far beyond the norm of small,
composable libraries, as it "bundles" Ring and Enlive and has its own
route processing. In the CFML world, FW/1 was a reaction to the large,
full-stack frameworks inspired by Spring, Rails etc, and those CFML
frameworks have routing, security, DI/AOP, ORM, environment control,
logging, test generation and all sorts of things built in... hundreds
of files, tens of thousands of lines of code, massive documentation
and so on. Even FW/1 (for CFML) has routing, some DI and environment
control all built in! FW/1 for Clojure has no DI nor environment
control (although that probably will get added at some point). I'm
somewhat allergic to ORM, favoring thin, simple data mappers instead
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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
> For more options, visit this group at
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Herwig Hochleitner||1/11/13 11:17 AM|
IMO there is little value in big dependency hair-balls and gui tools leakily abstracting devop taks.
There is, however, value in curated sets of independent libriaries that work well together. Also in having declarative syntax available for common tasks.
Still IMO, Clojure's web story is still somewhat lacking on those. More specifically in in environment integration, since ring does a great job for binding application components.
Lately I'm trying to push all code that deals with environment and project configuration into leiningen plugins.
I think together with project templates, that can be a great way to get more of the convenience of your classic framework.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Dmitri||1/11/13 1:18 PM|
I think a lot of the issues can be addressed via a good template which sets up all the boiler plate, demonstrates idiomatic usage, and defaults to some common libraries. I'm actively working on filling this gap with the Luminus, which aims to make it easy to get rolling, and sets up all the basic things like sessions, static resources, packaging, etc.
On Friday, January 11, 2013 11:52:05 AM UTC-5, Paul Umbers wrote:
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Marko Topolnik||1/11/13 1:27 PM|
I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :)
You are not alone: ORM, together with the idea of a "persistent state manager" is a beautifully paved road---to hell. In the prototype phase it gives the impression of an ideal solution: code looks just like it's operating on plain memory objects. What could ideally be milliseconds, ORM turns them into tenths of a second, and this doesn't get anyone worried. Then, when you have the whole project committed to ORM and start working on some really tough requirements---and only those are the ones that truly add value to your product, tasks that could take a tenth of a second turn into show-stopping pauses of ten seconds and more.
Now, if you are using a full-stack framework like Rails, you are pretty much stuck with its ORM solution, like it or not; with Clojure's mix-and-match approach, you just find what you are more comfortable with.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Eric MacAdie||1/11/13 1:33 PM|
Is there a page that gives "Clojure web recipes"? It would be great for beginners if you could have one place that says "To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs."
- Eric MacAdie
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Marko Topolnik||1/11/13 1:58 PM|
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Eric MacAdie||1/11/13 2:56 PM|
Thanks for the info. I will look this over, and perhaps finally build my world-changing Clojure app. Or maybe just "Hello World."
- Eric MacAdie
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Paul Umbers||1/11/13 3:05 PM|
On Friday, 11 January 2013 12:17:35 UTC-7, Herwig Hochleitner wrote:
I would have to agree with this, because it's exactly the kind of thing I was thinking of in the original post. Eclipse is made up of a core application and a large set of plugins. While the individual plugin developers are free to develop as they see fit, they have all chosen to join together to produce at least one stable, consistent release per year where everything just works together nicely (well, OK, maybe not so nicely with Juno). I know the Clojure philosophy is, as Sean mentioned above, to build from small composable libraries, but to foster increased adoption in enterprise environments there's something to be said for a quick, easy start.
I think maybe a combination approach of curated library versions (that work well together) and a comprehensive set of templates would go a long way towards easing adoption.
I get the feeling we're almost there with Leiningen templates and the more mature libraries (like Compojure/Ring), and it would just take some buy-in and coordinated effort making it happen.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Matt||1/11/13 4:00 PM|
Though the Clojure community has traditionally gone with smaller libraries rather than large frameworks, there is a full-stack web framework for Clojure called Conjure: https://github.com/macourtney/Conjure
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Sean Corfield||1/11/13 5:04 PM|
You could just do:
lein new fw1 myapp
assuming you have nothing running on port 8080 already - otherwise:
PORT=8123 lein run
Noir also has a simple Leiningen template (although Noir is deprecated now):
lein new noir noirapp
(same caveat applies regarding ports)
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Tim Cross||1/11/13 5:58 PM|
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.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||John Gabriele||1/12/13 11:08 AM|
On Friday, January 11, 2013 4:33:15 PM UTC-5, Eric MacAdie wrote:Is there a page that gives "Clojure web recipes"? It would be great for beginners if you could have one place that says "To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs."
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Malcolm Sparks||1/12/13 5:51 PM|
The Clojure tradition of mixing-and-matching small libraries rather than relying on large frameworks like Spring did not emerge by accident. The Java language itself causes library authors to create their own types thereby creating an impedance mismatch with other libraries. Spring (and similar frameworks) have evolved to address these issues, using clever design patterns such as interface adaptation. In contrast, Clojure libraries simply use common data structures (maps, sequences, sets) and Clojure itself has all the functions to convert between them where necessary. The result is that Clojure libraries integrate with each other relatively seamlessly without the need for frameworks like Spring. In other words, the very existence of Spring and other 'compendium' frameworks in the Java world is evidence that a lot of work is required to get Java libraries to work together. The absence of equivalents in the Clojure world is something that we should be very happy about. When you choose a compendium framework, you have to work with whatever libraries have been chosen for you by the framework provider, and hope that the doors you want to walk through are unlocked prior to your arrival. All too often they are not.
I've long felt that large platforms like Spring, Eclipse and even the JDK itself are a trade-off between the benefits of ease-of-use with the sacrifice of future innovation - platforms give incumbent libraries a premature monopoly on a functional area, thereby stifling competition from a potential worthy successor library. What I like about the Clojure eco-system is that, to a large extent, no such monopolies have emerged, there is a truer meritocracy because it is possible for libraries to emerge that provide a better or alternative approach to existing ones - so Ring, Aleph, Hiccup, Enlive, Compojure, Moustache and Liberator (to name but a few) can all peacefully co-exist. Innovative new libraries crop up all the time - so quickly it's almost hard to keep up! In which case, we shouldn't confuse frameworks with simple collections of libraries that some curator has verified work together. This is akin to the function that GNU/Linux distributions perform and there is definite value, especially for beginners, in the community shaping these collections.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Marko Topolnik||1/13/13 6:09 AM|
Great points. Also take RoR as an example: ruby, dynamic as it may be, still relies on the notion of a class as code owner which means that the class is the namespacing unit for all code that wants to participate in operating on a specific data structure, such as a hash or array.
After 20-30 years of intensive experience with the concept of encapsulation, the final verdict is that it was a great idea for in-house, monolithic projects of the 80's, but is an annoying impediment in the modern world of composable open-source.
This difference is akin to the difference between Unix's concept of small tools operating on the common data format as opposed to plugins contributed to all-encompassing environments, a typical scenario on Windows.
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||Luc||1/13/13 7:28 AM|
+1, excellent summary of the key points.
We got rid of Spring, Hibernate et cie for the same reasons. They were somewhat
needed in Java but in Clojure we found that they were cumbersome to use and
brought little value.
We realized along the way that some generated Java code (Hibernate is a good
example) was buggy and needed to be maintained by hand.
If even the generated code to glue things together is buggy, were is the gain ?
You end up having to maintain it...
We cut our backend code by a magnitude of more than 15 times by switching to 100%
Clojure and getting rid of the frameworks. Now down to 15000 sloc and less
dependencies to track...
> necessary. The result is that *Clojure libraries integrate with each other
> relatively seamlessly without the need for frameworks like Spring*. In
> other words, the very existence of Spring and other 'compendium' frameworks> itself are a trade-off between the benefits of ease-of-use with the *sacrifice
> of future innovation* - platforms give incumbent libraries a *premature
> monopoly* on a functional area, thereby stifling competition from a
> potential worthy successor library. What I like about the Clojure> > the work on GitHub <https://github.com/3rddog/doitnow> and my blog<http://internistic.blogspot.ca/search/label/clojure>
> > .
> >> > 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
> --Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||kovasb||1/13/13 5:07 PM|
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
> work on GitHub and my blog.
>> This is a concern, because these mismatches must be worked around in my code
|Re: Full stack Clojure web/REST framework - is there any mileage in it?||edw...@kenworthy.info||4/16/13 4:03 AM|
I'm a bit curious. My immediate reaction was to ask what you use instead of Spring (none?), Hibernate (datomic?) and what did you use to provide the plumbing for web apps (assuming you needed it and didn't just write it all from scratch).
My second thought was then what is the difference between a framework like Spring and a stack like the one I am assuming you used if it were documented and became a de facto framework?