As others have pointed out the comparison isn't really valid. Luminus intentionally aims to leverage existing libraries that are maintained independently whenever possible. I've been doing web dev with Clojure for the past 4 years and overall I do prefer the approach of using composable libraries over monolithic frameworks. With the Clojure web stack it's much easier to tell what's actually happening during the request/response lifecycle as things tend to be explicit. With frameworks like Rails a lot of stuff happens implicitly and requires a lot of in depth knowledge to work with effectively.
However, there are a some downsides to the libraries over frameworks approach as well. The biggest issue is that it's difficult to track what libraries are actively maintained and which ones play nicely together. Since most libraries are maintained by individuals it's common for them to become abandoned. Another problem is that each app becomes a unique snowflake since there aren't a lot of established patterns for structuring them. Finally, security is an issue for Clojure web apps as a lot of it done in rather ad hoc fashion. While this works great for people who are well versed in the Clojure web ecosystem it's a huge barrier for newcomers. I think that the best way to address the problem is via organizations where related projects are maintained by groups of contributors. This helps discovery of projects, and it helps spread the burden of maintenance for them. This approach is already working in the wild on GitHub with Ring, Reagent, and Luminus orgs. Meanwhile, Leiningen templates are a great way to provide reasonable defaults for different types of applications and can be used to address issues such as security. Also, I'm certainly open to contributions for Luminus. I moved it to an org recently and new members would be very welcome. :) On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote: > > I recently did some research into web frameworks on Github. Here's what > I found: > > > FRAMEWORK LANG CONTRIBUTORS COMMITS > > Luminus Clojure 28 678 > Caribou Clojure 2 275 > > Beego Golang 99 1522 > > Phoenix Elixir 124 1949 > > Yesod Haskell 130 3722 > > Laravel PHP 268 4421 > > Play Scala 417 6085 > > Symfony PHP 1130 20914 > > Rails Ruby 2691 51000 > > > One could conclude from this that the Clojure community isn't that > interested in web development but the last Clojure survey suggests > otherwise. Clojure's library composition approach to everything only > goes so far with large web applications, as Aaron Bedra reminded us in > March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower > means less momentum and more bugs. Furthermore, I have a hunch that > Clojure's poor adoption as indicated by Indeed.com maybe due to this > immaturity in the web framework sphere. Why is it that Elixir, with a > much smaller community and lifespan than Clojure's, has managed to put 4 > times as much mindshare into its main web framework when its module > output, as measured by modulecounts.com, is a tiny fraction of Clojure's? > > gvim > > > > > -- 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/d/optout.
