The Clojure community has a knack for looking at things and distilling them to their essence. I think the discussion on whether Clojure needs a web framework is another opportunity for that.
I don't think Clojure doesn't need a web framework, because Clojure is a programming language and doesn't need anything except a nice, warm JVM. Even if you reframe the question, "Do people need a Clojure web framework?", I still don't think its the right question. People don't need a web framework, they need what a web framework provides for them, and different people have very different needs. If we use the Jobs To Be Done <http://en.wikipedia.org/wiki/Outcome-Driven_Innovation> theory we can see what job different groups of people 'hire' a framework for: "The Business" The business hires a popular framework because * It offers the promise of quick development on features, with less time spent on the unimportant parts. * They want the security that their development team are working with something popular that will be supported, maintained, and used by lots of people for a long time. * They also like the benefit that there will be a relatively large hiring pool of people able to step into their codebase and get up to speed quickly. "Recruiters" Recruiters like to be able to pick out a particular technology and match you to their clients requirements. Like it or not, thats the world that we live in. If there was a common framework that people used, this part would be easier for them and the developer trying to get hired. "The CTO" The CTO shares many of the same concerns with the business, she also * Finds the shared conventions (from the framework and the community) useful for eliminating bikeshedding. * The shared conventions let developers understand each others code more easily. * Using a popular framework means that they are able to pull in battle tested libraries for critical things like auth, and be fairly confident in their quality. * Common concerns that every webapp needs, like templating and pluralisation are also built in. "The junior developer" A popular framework is great for a junior developer, they hire it for * A scaffold of how to build a web application. * The ability to get a quick win and get a real web application running without spending 10 hours banging their head against the keyboard. * Lots of standard functionality and third party libraries that they can pull in without necessarily understanding how to do it themselves (i.e. login and authorisation). * A large amount of documentation to learn from, and a community that is well set up for teaching beginners. * The ability to slot into a larger development team because the work they are doing can be well defined and matched to their skill level. "The senior developer" A framework is least useful to the senior developer, as they are often capable of combining libraries with the functionality they need to build their own webapp. They may find themselves restricted by the framework if they want to step outside of the bounds that the framework provides. If you agree with my characterisations then you can see that a framework provides many different things to many different people. Clojure doesn't necessarily need a web framework, but in my opinion it does need to satisfy each of the parties involved with the development process if it wants to be used more commonly in web app development. What this may look like for Clojure in 2015 is probably very different than what it looked like for Ruby in 2004. It may be a traditional framework, a lein template, a standard pattern of code, a set of conventions and loosely coupled protocols, pretty much exactly what we have now, or something entirely different. On Tue, May 5, 2015 at 12:53 PM, larry google groups < lawrencecloj...@gmail.com> wrote: > > > My guess is that over the next 2-3 years we will see some clojure > frameworks emerge but > > they will not be like "traditional" frameworks. > > Or the space for "web framework" will always default to Rails. Clojure > certainly has some great frameworks in other areas, such as distributed > data processing: > > Avout > > tessers > > Onyx > > Storm > > Pulsar > > Quassar > > (Some of these are more Java than Clojure, but Java interop is one of > Clojure's strengths.) > > > > > > On Monday, May 4, 2015 at 3:00:54 PM UTC-4, Gregg Reynolds wrote: >> >> >> On May 4, 2015 7:16 AM, "Eric MacAdie" <emac...@gmail.com> wrote: >> > >> > I think what Clojure needs is a default. It doesn't matter if it is a >> "web framework" like Rails, or "libraries strung together" like Luminus. >> > >> >> What Clojure needs is, well nothing. What the market MAY need is an >> entrepreneur who will produce the framework the OP craves. No takers so >> far. Conclusion: not a genuine unmet need. But in the long run simple >> economics say the Clojure approach will win. You can't make your product >> stand out by using the same framework everybody else uses. The inevitable >> trend, driven by basic economics, is toward bespoke stuff, which is where >> Clojure excels. My guess is that over the next 2-3 years we will see some >> clojure frameworks emerge but they will not be like "traditional" >> frameworks. They'll be infinitely and easily customizable because they >> wont force choices-they'll just make the easy stuff not only easy but >> flexible. My 2 cents. >> >> > When a Ruby newbie asks how to make a web app, the default answer is to >> look at Rails. In Python, the default answer is Django. Compared to that, >> the default answer in Clojure to do it yourself can sound like "go jump off >> a cliff". >> > >> > = Eric MacAdie >> > >> > >> > On Mon, May 4, 2015 at 7:09 AM, Sean Johnson <bel...@acm.org> wrote: >> >> >> >> >> >> >> >> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote: >> >> >> >>> All in all this is basically the direction I want to go with closp >> and closp-crud. The intention is not to have a webframework, but to >> automatize steps that need to be done manually otherwise. >> >> >> >> >> >> One potential problem with this "web framework" as app template >> approach is upgrade-ability. When 2.0 of your "framework" comes out, what >> happens to an app generated from 1.0 that wants to benefit from the new >> capabilities? >> >> >> >> It's not a showstopper to the approach. It's just something to think >> hard about. I've taken a couple of long lived Rails apps from Rails 1 to >> Rails 4 and while there have been breaking changes with each major version >> change (and some minor versions) in general it's pretty easy to keep up >> with the latest versions and there are copious docs (even whole ebooks in >> some cases) to walk developers through the changes. >> >> >> >> Cheers, >> >> Sean >> >> >> >> -- >> >> 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 >> >> clojure+u...@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+u...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > 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 >> > clojure+u...@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+u...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > -- > 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. > -- 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.
