Hey Sven, It looks to me like you could really polish the +auth part and integrate most of that part of closp into Luminus. I'd be happy to help with that. Then you could make a +closp that depends on +auth and build the UI parts, etc. Having a working +auth with a default db configuration, possibly with both yesql and korma as back end options, would make auth/authz trivial to set up. Then you could also focus on what makes closp unique. --Sven
On Tuesday, May 5, 2015 at 1:27:21 AM UTC-4, Sven Richter wrote: > > Hi Dmitri, > > When I was building closp I was taking luminus as the base for it with > some minor adoptions. I just had a look at the website of luminus and saw > the massive amount of work you put into the documentation again. If that > sounds reasonable for you I'd like to try to move closp and closp-crud to > luminus as an opionated part of it. > So if you call lein new luminus projectname +closp you will basically get > what you get now with closp. You can look here for the additions: > https://github.com/sveri/closp. > I would like to maintain that "branch". > > I am not sure if that will work out the way I think, but I'd like to > evaluate it at least. It would be nice to have a common base and a common > documentation for it. > > Best Regards, > Sven > > Am Dienstag, 5. Mai 2015 02:38:41 UTC+2 schrieb Dmitri: >> >> 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.
