While I totally agree with you on the topic of composing things to solve a problem at hand I think you are talking about a different audience here than the audience such a "framework" is aiming for. You are talking about experienced developers that know how to solve problems, that know advantages and disadvantages of certain patterns and tools.
I think these people can be found in the intermediat to above layer of programmer experience. All the rest will be stuck and overwhelmed by the choices that are offered (not only in clojure, but in many languages). So they are looking for a set of good documentation and an opinionated path to a valuable product that fullfills most of their needs. Several years ago I was happy to find django and be productive in a short amount of time without having to think of which templating language to choose, but then, like I wrote above, I was hitting a hard edge which led me to search more. Still, I finished my project some years, which I may have never done without some guidance and the very good documentation of the django project. Best Regards, Sven Am Montag, 4. Mai 2015 16:24:22 UTC+2 schrieb tbc++: > > The thing that bugs me the most about these sort of conversations about > "best practices" is that they often present a set of solutions without > first analyzing the problem at hand. > > If I came to this mailing list and asked "I want to write a websever in > Clojure..what should I use?". The response would most likely be Ring + > Compojure. Okay, not bad options, but that recommendation has been given > with absolutely no analysis of what I'm trying to accomplish. What if I > need async? What if I need web sockets? What sort of connection load am I > expecting? Will my system handle mostly persistent connections (like > websockets or SSE), or will it be more canned (and cacheable) data? If > someone recommends Ring to me, I may be pigeonholed into some system I'll > have to refactor later. Perhaps the best option is Aleph or Pedestal. > > That's the real issue with canned responses like rails tutorial. They > assume my needs match your needs and match the needs of most people. That's > just not the best way to go about doing software development. And it's a > problem I've seen in so many areas of computing. > > I've lost countless hundreds of hours of my life to frameworks that > default to bulky serialization formats (like XML or JSON), or frameworks > that assume LAN connections to the servers, or frameworks that assume I > won't be using multi-threading, or frameworks that assume I won't try to > load 10k rows on a single page, or frameworks that assume any number of > things. The thing I love the most about the Clojure community is that, more > than any other community I've been a part of, they try to ask you to think > before you jump. > > So what I would recommend is more of a set of guidelines, and matrices. > List all the frameworks/libraries on one axis, and features on another, and > start commenting. Make a page like this: ( > http://en.wikipedia.org/wiki/Comparison_of_video_container_formats) > > Mention that Ring is well supported by the community, but doesn't work > well with fully async servers, mention that Aleph does all the async you > need, but is a bit non-standard. Mention that data.json is pure Clojure, > but cheshire is most likely faster. > > Just present the options, and let the users make up their own minds. You > don't understand the needs of all of your users. So don't try to solve > their problems, instead present them with options and let them make up > their own minds. I guarantee you that whatever tech you recommend to > someone, the won't like some aspect of it, so better to present them with > all the options and let them choose, then they can only blame themselves if > it doesn't work out exactly like they expected. > > > > On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria <ernie....@gmail.com > <javascript:>> wrote: > >> I would like to echo the sentiment expressed by several posters in this >> thread, but with a slight twist. A few years back I picked up Ruby and Ruby >> on Rails as the language/framework to create a website with moderate >> complexity and functionality. I did this without any prior experience with >> the language of framework. What allowed me to quickly pick up both was the >> excellent documentation around the language and framework. For example, >> with the information from http://guides.rubyonrails.org and the >> canonical application built in https://www.railstutorial.org one can >> acquire the necessary knowledge to develop highly functional websites. >> Branching out to leverage "non-canonical" libraries/products then becomes a >> fairly easy exercise (MongoDB instead of MySQL, Mongoid instead of >> ActiveRecords, etc.). What allows that to happen is the momentum built >> around the Rails ecosystem via community participation and documentation. >> >> We have recently started to build our "back end" infrastructure in >> Clojure. Many times we have discussed the value and desire to unify our >> development efforts on and around Clojure. Inevitably we tally up all the >> functionality inherited from Ruby gems (that play nice with Rails - the >> Framework) that would have to be replicated in Clojure and there always >> shortcomings, not necessarily in the availability of libraries that perform >> these functions, but in the readily accessible documentation about how to >> best integrate them. >> >> The "composable libraries over framework" mantra is technically solid. >> What we're missing, in the "web development with Clojure" subset of the >> community, is the stewardship to create and maintain a canonical >> amalgamation of composable libraries and the best practices around them - a >> la https://railstutorial.org. This would lower the barrier of entry into >> the web development realm for Clojure developers. My 2+ cents. >> >> 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 clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- 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.
