Re: Clojure needs a web framework with more momentum

[Malcolm Sparks]

> How do we effectively leverage some of the more advanced Clojure-oriented 
webservers such as Aleph and Immutant?

I've just posted about yada on another thread, a library for 'proper' 
handling of Ring requests, fully supporting async. Although yada is a 
separate library, it fully complements bidi (a url routing library).

There are a couple more complementary libraries on the way which will 
combine to form something akin to a 'web framework' discussed on this 
thread.

Regards,

Malcolm

On Sunday, 3 May 2015 04:19:19 UTC+1, puzzler wrote:
>
> Last week, at the Clojure/West conference, someone (I think it was Brandon 
> Bloom) summed up the general vibe well, by saying something along the lines 
> of, "We now have all the pieces in place to make web development an order 
> of magnitude more productive than in any other language, we just need to 
> figure out how to put it all together and make that happen."
>
> I think that's right.  From a technological standpoint, I think we're 
> there.  The things we most need are informational resources and 
> higher-level shared resources, such as UI widgets.  For example:
>
> How do we use Buddy/Friend effectively to achieve secure web apps?  (The 
> docs are not sufficiently informative for those who haven't thought much 
> about security and assume too much prior knowledge).
>
> How do we effectively leverage some of the more advanced Clojure-oriented 
> webservers such as Aleph and Immutant?
>
> Clojure is great for creating new, disruptive web models, but what's the 
> easiest path to creating something that can be done trivially with, say, 
> Drupal or Django?
>
> Since more and more people are working with Reagent/Om/etc., we need as 
> many Bootstrap-like widgets as possible for those tools, and more 
> informational resources about how to use these new reactive models 
> effectively, for example, how to do animated UIs.
>
> Are there reusable components like, say, shopping baskets?
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[Hari Krishnan]

Sven,

I like this idea.  Thanks.

-Hari

On Wednesday, May 6, 2015 at 11:46:35 AM UTC-7, Sven Richter wrote:
>
> Hi,
>
> I had a short chat with Dmitri (the owner of luminus) and we both agreed 
> that this is a good plan. I just don't have much time right now (family 
> things), but as soon as there is more I will develop a prototype, 
> integrating the features of closp and closp-crud into luminus and make them 
> available as a luminus profile.
>
> Best Regards,
> Sven
>
> Am Mittwoch, 6. Mai 2015 18:08:03 UTC+2 schrieb Sven Pedersen:
>>
>> 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 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey s

Re: Clojure needs a web framework with more momentum

[Daniel Kersten]

I haven't used Luminus since before 2.0, so I guess it may have changed a
lot since. At the time, I was disheartened by the amount of code generated.
I will take another look when I get time.

On Tue, 5 May 2015 at 14:06 Dmitri  wrote:

> Luminus uses a minimal amount of generated code. It completely embraces
> the composable library approach. The difference from rolling your own each
> time is that it provides some structure and it's a curated set of libraries
> that are known to work well together.
>
>
> On Tuesday, May 5, 2015 at 3:46:09 AM UTC-4, Dan Kersten wrote:
>
>> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>>>
>> 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?
>>>
>>
>> This is the reason I don't use Luminus or Modularity or others that rely
>> heavily on leiningen template-based codegen. Its very difficult to upgrade
>> the generated code, especially if you've had to add to or modify it.
>>
>> I'm experimenting with an approach that would generate only the
>> project.clj file and directory structure (putting everything else into
>> libraries), but don't yet have anything to release (my code is currently
>> very targeted at my own use case, but in time I'd like to generalize it a
>> bit and let others at it).
>>
>  --
> 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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

I assume most people here would agree with this: 

"Nothing is merely a pull request; it is someone's valuable time spent in 
contemplation and action."

At the same time, I assume most people who would use Clojure will also know 
something about Git, and I think this applies even to fairly new 
programmers (though not total beginners, and, as I said before, if the 
question is "How do we make Clojure as easy as PHP?" I think it is an 
interesting challenge, and one we are far from having an answer for). 

I am uncertain what restrictions might be appropriate for a documentation 
site. As you say: "I hear PHP suffered from misleading and messy community 
docs… though it was very useful for my (basic) purposes."

I suppose a good answer would combine the openness of a wiki with some kind 
of voting so that visitors could see which edits were judged to be the best 
-- something like StackOverflow. 

Failing that, we could point people to the pull requests on Github, and 
tell them that there is important information in the pull requests, which 
might sound messy, but I don't think it would be any more messy that the messy 
community docs that you say PHP had. 

--- lawrence
 





On Thursday, May 7, 2015 at 5:48:11 AM UTC-4, Tj Gabbour wrote:
>
>  First of all, I apologize to the group for any unfriendliness in my 
> response. (Which may be poisonous to this group’s culture, I don’t know. 
> Unfortunately, many old frustrations of mine were triggered, when I felt my 
> question was given an uncharitable interpretation.) 
>
> The term “pull request” hides a lot of complexity. (Some point out 
> 
>  
> it means “Go fuck yourself.”) Nothing is merely a pull request; it is 
> someone's valuable time spent in contemplation and action. 
>
>  If we were in a team, here’s some things we might discuss: 
>
>- How to support each other? (Given varying 
>skills/confidence/energy/power.) 
>- What is our ultimate goal? (“Documentation” almost never is one. 
>It’s just a tactic.) 
>- What is our audience? (Why do we wish to serve them, and how?) 
>- What is our process for improving quality/effectiveness? 
>(After-action reviews, building institutional knowledge…) 
>- Who are external partners, and how do they think? (We’ve mentioned 
>Clojurewerkz and The Clojure.org 14.) 
>
>
>  So when we’re evaluating contributing to clojure-docs.org: 
>
>- Should we add metrics to show us how many people read 
>clojure-docs.org, as a first step to gauging effectiveness? 
>- What do you think about the content there, and how would you make it 
>far better? (Pictures? Examples? Literary structure?) 
>
>
>  When we’re evaluating contributing to clojure.org: 
>
>- Examples of our intended audience, and what problems do they have? 
>- How to best work with the strengths of The Clojure.org 14’s 
>conservativism? 
>- Clojure’s uses are diverse; how do we represent its core? Might it 
>be entirely appropriate to have a sparse site, more or less like it is 
> now? 
>Because the real entry-points should be around emerging clusters like 
>React.js libs? 
>
>
>  These may seem like lots of things to think about, but so is writing 100 
> good lines of debugged code. 
>
> *are any restrictions that should be put on a documentation site?*
>>
>>
> Yes, depending on what you want to avoid. 
>
> For example, I hear PHP suffered from misleading and messy community docs… 
> though it was very useful for my (basic) purposes. 
>
> But once we agree there need to be restrictions, what can we do to 
> mitigate the downsides? For example, raising barriers to entry can lead to 
> intimidation. But you can mitigate it by being supportive and offering 
> mentoring. Or simply being proactively honest and apologetic about it. 
>
> I hope I didn't misunderstand your points?
>  

-- 
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.

Re: Clojure needs a web framework with more momentum

[Surgo]

One way to think about documentation is this: you've just written this 
great and useful library! You surely want it to be useful and people to 
actually use it, right? (See earlier in the thread about Pedestal.) Well, 
the only way you'll reach that goal is by having solid documentation that 
can provide an on-ramp to people who you think should be using the library, 
but don't know anything about it.

We all know what bad documentation looks like, but what about good 
documentation? Examples would be useful here. Two projects whose 
documentation I like:
* core.match
* Immutant

-- Morgon

On Thursday, May 7, 2015 at 5:48:11 AM UTC-4, Tj Gabbour wrote:
>
>  First of all, I apologize to the group for any unfriendliness in my 
> response. (Which may be poisonous to this group’s culture, I don’t know. 
> Unfortunately, many old frustrations of mine were triggered, when I felt my 
> question was given an uncharitable interpretation.) 
>
> The term “pull request” hides a lot of complexity. (Some point out 
> 
>  
> it means “Go fuck yourself.”) Nothing is merely a pull request; it is 
> someone's valuable time spent in contemplation and action. 
>
>  If we were in a team, here’s some things we might discuss: 
>
>- How to support each other? (Given varying 
>skills/confidence/energy/power.) 
>- What is our ultimate goal? (“Documentation” almost never is one. 
>It’s just a tactic.) 
>- What is our audience? (Why do we wish to serve them, and how?) 
>- What is our process for improving quality/effectiveness? 
>(After-action reviews, building institutional knowledge…) 
>- Who are external partners, and how do they think? (We’ve mentioned 
>Clojurewerkz and The Clojure.org 14.) 
>
>
>  So when we’re evaluating contributing to clojure-docs.org: 
>
>- Should we add metrics to show us how many people read 
>clojure-docs.org, as a first step to gauging effectiveness? 
>- What do you think about the content there, and how would you make it 
>far better? (Pictures? Examples? Literary structure?) 
>
>
>  When we’re evaluating contributing to clojure.org: 
>
>- Examples of our intended audience, and what problems do they have? 
>- How to best work with the strengths of The Clojure.org 14’s 
>conservativism? 
>- Clojure’s uses are diverse; how do we represent its core? Might it 
>be entirely appropriate to have a sparse site, more or less like it is 
> now? 
>Because the real entry-points should be around emerging clusters like 
>React.js libs? 
>
>
>  These may seem like lots of things to think about, but so is writing 100 
> good lines of debugged code. 
>
> *are any restrictions that should be put on a documentation site?*
>>
>>
> Yes, depending on what you want to avoid. 
>
> For example, I hear PHP suffered from misleading and messy community docs… 
> though it was very useful for my (basic) purposes. 
>
> But once we agree there need to be restrictions, what can we do to 
> mitigate the downsides? For example, raising barriers to entry can lead to 
> intimidation. But you can mitigate it by being supportive and offering 
> mentoring. Or simply being proactively honest and apologetic about it. 
>
> I hope I didn't misunderstand your points?
>  

-- 
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.

Re: Clojure needs a web framework with more momentum

[Tj Gabbour]

 

First of all, I apologize to the group for any unfriendliness in my 
response. (Which may be poisonous to this group’s culture, I don’t know. 
Unfortunately, many old frustrations of mine were triggered, when I felt my 
question was given an uncharitable interpretation.) 

The term “pull request” hides a lot of complexity. (Some point out 

 
it means “Go fuck yourself.”) Nothing is merely a pull request; it is 
someone's valuable time spent in contemplation and action. 

 If we were in a team, here’s some things we might discuss: 

   - How to support each other? (Given varying 
   skills/confidence/energy/power.) 
   - What is our ultimate goal? (“Documentation” almost never is one. It’s 
   just a tactic.) 
   - What is our audience? (Why do we wish to serve them, and how?) 
   - What is our process for improving quality/effectiveness? (After-action 
   reviews, building institutional knowledge…) 
   - Who are external partners, and how do they think? (We’ve mentioned 
   Clojurewerkz and The Clojure.org 14.) 


 So when we’re evaluating contributing to clojure-docs.org: 

   - Should we add metrics to show us how many people read 
   clojure-docs.org, as a first step to gauging effectiveness? 
   - What do you think about the content there, and how would you make it 
   far better? (Pictures? Examples? Literary structure?) 


 When we’re evaluating contributing to clojure.org: 

   - Examples of our intended audience, and what problems do they have? 
   - How to best work with the strengths of The Clojure.org 14’s 
   conservativism? 
   - Clojure’s uses are diverse; how do we represent its core? Might it be 
   entirely appropriate to have a sparse site, more or less like it is now? 
   Because the real entry-points should be around emerging clusters like 
   React.js libs? 


 These may seem like lots of things to think about, but so is writing 100 
good lines of debugged code. 

*are any restrictions that should be put on a documentation site?*
>
>
Yes, depending on what you want to avoid. 

For example, I hear PHP suffered from misleading and messy community docs… 
though it was very useful for my (basic) purposes. 

But once we agree there need to be restrictions, what can we do to mitigate 
the downsides? For example, raising barriers to entry can lead to 
intimidation. But you can mitigate it by being supportive and offering 
mentoring. Or simply being proactively honest and apologetic about it. 

I hope I didn't misunderstand your points?

-- 
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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

This is certainly true:

"Docs are about empathy, which means discussions should show empathy."

I am not sure what you mean by "That response does not respect people’s 
limited time." I think you mean that Pull Requests are often a waste of 
time, because you can not be certain if the Pull Request will be accepted? 
And some Pull Requests linger for months, or they are never accepted but no 
reason is given for their rejection? I'm curious if you feel there are any 
restrictions that should be put on a documentation site? 



On Wednesday, May 6, 2015 at 7:32:28 PM UTC-4, Tj Gabbour wrote:
>
>
> On Wednesday, May 6, 2015 at 11:12:58 PM UTC+2, Andy Fingerhut wrote:
>>
>> Maybe you are not aware of the history, but clojure-doc.org exists 
>> specifically because someone who spoke out loudly and repeatedly against 
>> CAs took the time to create it, and it _only_ requires a Github account and 
>> creating a pull request.
>>
>
>  That response does not respect people’s limited time. Examples from my 
> own brief experience: 
>
>- Had to run some Ruby server… the instructions of which are currently 
>in a dead link 
>
> .
>  
>
>- Had to fix a problem 
> with that Ruby 
>server’s markdown lib. 
>- Weekly+ releases were jarring when I was used to rapid release 
>cycles. 
>
>  You’re advocating a course of action whose predictable effect is to eat 
> up unexpected hours of helpful people’s time. Probably triggering Impostor 
> Syndrome in half of them because it’s supposed to be raly easy… 
>
> People need to make rational decisions on time allocation. They should be 
> cautioned that clojure-doc.org vs clojuredocs.org is a highly confusing 
> situation, which will impact the effectiveness of their efforts. Docs are 
> about empathy, which means discussions should show empathy. 
>
> This whole discussion is such a headache… With all the attempted shaming 
> for not contributing, when many of us spend massive amounts of time 
> contributing, and are merely trying to assess pitfalls from the morass of 
> half-truths… 
>   
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 11:12:58 PM UTC+2, Andy Fingerhut wrote:
>
> Maybe you are not aware of the history, but clojure-doc.org exists 
> specifically because someone who spoke out loudly and repeatedly against 
> CAs took the time to create it, and it _only_ requires a Github account and 
> creating a pull request.
>

 That response does not respect people’s limited time. Examples from my own 
brief experience: 

   - Had to run some Ruby server… the instructions of which are currently 
   in a dead link 
   
.
 
   
   - Had to fix a problem  
   with that Ruby server’s markdown lib. 
   - Weekly+ releases were jarring when I was used to rapid release cycles. 

 You’re advocating a course of action whose predictable effect is to eat up 
unexpected hours of helpful people’s time. Probably triggering Impostor 
Syndrome in half of them because it’s supposed to be raly easy… 

People need to make rational decisions on time allocation. They should be 
cautioned that clojure-doc.org vs clojuredocs.org is a highly confusing 
situation, which will impact the effectiveness of their efforts. Docs are 
about empathy, which means discussions should show empathy. 

This whole discussion is such a headache… With all the attempted shaming 
for not contributing, when many of us spend massive amounts of time 
contributing, and are merely trying to assess pitfalls from the morass of 
half-truths… 
  

-- 
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.

Re: Clojure needs a web framework with more momentum

[Alex Miller]

On Wednesday, May 6, 2015 at 2:15:53 PM UTC-5, Andy Fingerhut wrote:
>
> First some facts, without any evaluation:
>
> There are only a handful of people in the world with authorization to edit 
> pages on clojure.org.  I would guess maybe only 5.
>

14
 

> Far more have authorization to edit the wiki pages on dev.clojure.org -- 
> hundreds, I think.  A subset of those who have signed a Clojure CA and 
> requested permission for editing those pages.
>

320
 

> Writing good documentation and giving it away is time consuming, 
> painstaking, often thankless.  There are probably some rare individuals who 
> can write lots of good documentation in less than an hour per 'page full of 
> text', but I am not one of them, and I wouldn't be surprised if the typical 
> number is more like 5 to 10 person-hours per 'page full of text' for good 
> documentation.  It isn't just writing it the first time, but re-reading and 
> editing it 2 or 3 times, responding to requests to fix errors and 
> suggestions for improvement, and updating as new software versions obsolete 
> old documentation.
>
> I do not know how many hours that Alex Miller has spent during the last 2 
> years editing the content on clojure.org that exist today.  
>

I have a list where I batch them up and then periodically I'll take an 
afternoon to make updates. Or add new pages like for transducers (that took 
about 2 days). Plenty of things still to fix. Depending what the changes 
are, I have Rich review them too (and then I have to rewrite them :).
 

> There is no public change log I am aware of for its content like there is 
> for the wiki pages.  I suspect it is up in the many tens, at least.  This 
> editing has been in the form of adding new text, and clarifying and 
> reorganizing existing text, primarily, not in redesigning the look and feel 
> of the site.
>

I don't think it's linked anywhere, but:
http://clojure.org/wiki/changes
 

-- 
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.

Re: Clojure needs a web framework with more momentum

[Andy Fingerhut]

On Wed, May 6, 2015 at 1:27 PM, Fluid Dynamics  wrote:

> On Wednesday, May 6, 2015 at 3:15:53 PM UTC-4, Andy Fingerhut wrote:
>>
>>
>> The "rough edges" show up on a lot of things in the Clojure ecosystem. I
>> know I suck at documentation which is why I moved clojure.java.jdbc’s
>> documentation out to
>> http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html which can
>> be maintained by the community through Pull Requests etc. *In two years,
>> there have been just two small changes from the community: the rest of the
>> updates are from me, despite several people complaining about the
>> documentation being unclear or insufficient.*
>>
>
> Perhaps the barrier to participation is simply too high to get many
> contributors. Consider Wikipedia's: go to website, click edit, fix/add
> something. No pull requests, no written and snail-mailed(!) CAs, no
> creating yet *another* login/pass pair to remember, no other hoops to jump
> through.
>
> Argue all you want about why  is *absolutely essential*
> to keep the vandals/copyright infringers/terrorists/spammers/whoever out;
> it won't change the empirical fact that you only get mass participation
> when the entry barrier is *very* low (even a free registration is a
> substantial deterrent that will cut participation by an order of magnitude
> or more). Or the empirical fact that Wikipedia actually works pretty darn
> well...
>

Fluid:

Maybe you are not aware of the history, but clojure-doc.org exists
specifically because someone who spoke out loudly and repeatedly against
CAs took the time to create it, and it _only_ requires a Github account and
creating a pull request.

If you think a Github account and creating a pull request is too high a
barrier, there is clojuredocs.org, too, but that tends to be separate
documentation for each funcation/macro, not more broad-ranging articles.

Andy

-- 
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.

Re: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 9:15:53 PM UTC+2, Andy Fingerhut wrote:
>
> I am not 'in the know' on decisions regarding clojure.org.
>
> [...]
>
What I find more interesting than the portion of Sean Corfield's post that 
> you chose to quote, was this one (emphasis added by me):
>

  

To clarify, because I detect an implication in your words: I never said the 
part I “*chose to quote*” was the most “*interesting*”. It was merely the 
one which I wished clarification on. (The answer affects a planned action 
of mine.) 

Good to hear Alex Miller spends much time on documentation. Others, like 
Kathy Sierra, not only do so, but under infinitely worse conditions. I 
respect them all. 

Personally, I allocate much time on technical docs too. I’m participating 
in Clojurebridge soon, not to mention the private mentoring where I write 
“class notes” most days a week. I’m behind on them; here’s my backlog of 
classes to illustrate: 

   - suddenly jumped from machine language  
   to get high-level perspective: 
  - class where I explained data (used Clojure datastructures, as it’s 
  the clearest) 
  - class where I explained code (used a simple lisp, and basically 
  explained an evaluator) 
   - class on I/O: polling vs. interrupts vs. hybrid; memory mapped vs. 
   port mapped 
   - class introducing C: lldb, offered choice of texts 
   - class explaining “what’s a sourcecode file”: inodes 

(And the task requires skills like a certain kind of brevity; reaching down 
into underlying concepts; visual details like non-intimidating typefaces, 
etc.)

Admittedly, for the Clojure community, I only contributed this doc: 
http://clojure-doc.org/articles/cookbooks/strings.html … after which I 
decided to allocate my time to efforts which (hopefully) help people more 
than liberating programmers from technological drudgery. 

Anyway, I retract my tiny question; I’ll just privately ask people I know.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Alex Miller]

On Wednesday, May 6, 2015 at 11:34:15 AM UTC-5, Sean Corfield wrote:
>
> On May 5, 2015, at 11:48 PM, Kristo Koert  > wrote:
>
> My argument was that a more visually appealing homepage would leave a 
> better first impression and attract more new beginner developers to check 
> out clojure. (Ex. comparing haskell.org or scala-lang.org vs clojure.org). 
> An opinion was expressed that "we don't need these low quality people in 
> the community". 
>
> This is not the opinion of Cognitect or anyone supporting Clojure. We will 
update the clojure.org site at some point. I do not control the 
prioritization for when that will happen, but it's absolutely on the list. 
Ditto for ClojureScript (and props to the http://cljs.info folks for 
building some momentum).

I expect the existing "documentation" style pages to continue to exist on 
clojure.org - they are heavily linked to and cross-linked and are as close 
as we have to reference documentation for the language. I regularly update 
it based on feedback for things that are wrong, missing, or unclear. If you 
have feedback, send it to me - google group, email, twitter, jira, whatever.

I expect a newer site to also have other things as well, such as official 
or community sourced tutorial-style information. I have done some work on 
what this should/could look like information-wise (thankfully no one will 
let me near design :). 

> This excludes quite a lot of complete newcomers, because ofcourse they 
> cannot tell the merits or demerits of a languages from a wall of text in 
> unfamiliar syntax from a page that seems to be without much love. They will 
> see a seemingly unappealing language. They will not have the opportunity to 
> learn to not judge a programming language based on the homepage until far 
> later in their careers maybe.
>
>
> This is particularly frustrating from the point of view of someone 
> involved in ClojureBridge, where the whole point is to reach out to tech 
> minorities and encourage complete beginners to try Clojure. The issue has 
> been raised several times and is pretty much always shut down by "those in 
> charge". 
>

I do not know of anyone "in charge" ever "shutting down" anything. 
Certainly, people have made prioritization decisions, but that's a far cry 
from what you are suggesting.
 

> It was a huge struggle just to have the Getting Started page updated to 
> remove complexity and point at the wiki instead (although the wiki is also 
> _horrible_ from the point of view of new users).
>

I am happy to work with anyone to improve the Getting Started page. I have 
repeatedly made this offer and no one has ever followed up on it. If you're 
referring to changing that page to point to the wiki, that happened like 5 
years ago, so does not seem relevant to today. I do not recall it being a 
struggle even when it happened.

Seriously, if someone wants to work on this, make a page on the design 
wiki, flesh out some text and I'll work with you to publish it. 

Alex 

-- 
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.

Re: Clojure needs a web framework with more momentum

[Fluid Dynamics]

On Wednesday, May 6, 2015 at 3:15:53 PM UTC-4, Andy Fingerhut wrote:
>
>
> The "rough edges" show up on a lot of things in the Clojure ecosystem. I 
> know I suck at documentation which is why I moved clojure.java.jdbc’s 
> documentation out to 
> http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html which can 
> be maintained by the community through Pull Requests etc. *In two years, 
> there have been just two small changes from the community: the rest of the 
> updates are from me, despite several people complaining about the 
> documentation being unclear or insufficient.*
>

Perhaps the barrier to participation is simply too high to get many 
contributors. Consider Wikipedia's: go to website, click edit, fix/add 
something. No pull requests, no written and snail-mailed(!) CAs, no 
creating yet *another* login/pass pair to remember, no other hoops to jump 
through.

Argue all you want about why  is *absolutely essential* 
to keep the vandals/copyright infringers/terrorists/spammers/whoever out; 
it won't change the empirical fact that you only get mass participation 
when the entry barrier is *very* low (even a free registration is a 
substantial deterrent that will cut participation by an order of magnitude 
or more). Or the empirical fact that Wikipedia actually works pretty darn 
well...

-- 
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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 6, 2015, at 12:15 PM, Andy Fingerhut  wrote:
> What I find more interesting than the portion of Sean Corfield's post that 
> you chose to quote, was this one (emphasis added by me):

Thank you Andy, yes, that was indeed my main point. The guides repo (behind 
clojure-doc.org ) is testament to a huge amount of 
time and effort by a small team of volunteers — but outside of that small team, 
the community really hasn’t rallied around and contributed.

Folks who want clojure.org  to be better could contribute 
to clojure-doc.org  to make that the central, 
appealing, beginner-friendly site for all things Clojure.

> Sean Corfield wrote:
> The "rough edges" show up on a lot of things in the Clojure ecosystem. I know 
> I suck at documentation which is why I moved clojure.java.jdbc’s 
> documentation out to 
> http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html 
>  which can be 
> maintained by the community through Pull Requests etc. In two years, there 
> have been just two small changes from the community: the rest of the updates 
> are from me, despite several people complaining about the documentation being 
> unclear or insufficient.


-- 
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.

Re: Clojure needs a web framework with more momentum

[Andy Fingerhut]

First some facts, without any evaluation:

There are only a handful of people in the world with authorization to edit
pages on clojure.org.  I would guess maybe only 5.

Far more have authorization to edit the wiki pages on dev.clojure.org --
hundreds, I think.  A subset of those who have signed a Clojure CA and
requested permission for editing those pages.

Writing good documentation and giving it away is time consuming,
painstaking, often thankless.  There are probably some rare individuals who
can write lots of good documentation in less than an hour per 'page full of
text', but I am not one of them, and I wouldn't be surprised if the typical
number is more like 5 to 10 person-hours per 'page full of text' for good
documentation.  It isn't just writing it the first time, but re-reading and
editing it 2 or 3 times, responding to requests to fix errors and
suggestions for improvement, and updating as new software versions obsolete
old documentation.

I do not know how many hours that Alex Miller has spent during the last 2
years editing the content on clojure.org that exist today.  There is no
public change log I am aware of for its content like there is for the wiki
pages.  I suspect it is up in the many tens, at least.  This editing has
been in the form of adding new text, and clarifying and reorganizing
existing text, primarily, not in redesigning the look and feel of the site.


Now my personal commentary:

I am not 'in the know' on decisions regarding clojure.org.  I would guess
that from their point of view, they haven't tried to "shut down" a
differently-organized web site, but rather have decided to spend their time
on other efforts, given how considerable a job it is.

What I find more interesting than the portion of Sean Corfield's post that
you chose to quote, was this one (emphasis added by me):

Sean Corfield wrote:
The "rough edges" show up on a lot of things in the Clojure ecosystem. I
know I suck at documentation which is why I moved clojure.java.jdbc’s
documentation out to
http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html which can be
maintained by the community through Pull Requests etc. *In two years, there
have been just two small changes from the community: the rest of the
updates are from me, despite several people complaining about the
documentation being unclear or insufficient.*

Andy


On Wed, May 6, 2015 at 11:34 AM, Tj Gabbour  wrote:

> On Wednesday, May 6, 2015 at 6:34:15 PM UTC+2, Sean Corfield wrote:
>>
>> The issue has been raised several times and is pretty much always shut
>> down by "those in charge". It was a huge struggle just to have the Getting
>> Started page updated to remove complexity and point at the wiki instead
>> (although the wiki is also _horrible_ from the point of view of new users).
>>
>
>  Did they ever articulate reasons? (Even if vague/brief?)
>
> --
> 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.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

Hi,

I had a short chat with Dmitri (the owner of luminus) and we both agreed 
that this is a good plan. I just don't have much time right now (family 
things), but as soon as there is more I will develop a prototype, 
integrating the features of closp and closp-crud into luminus and make them 
available as a luminus profile.

Best Regards,
Sven

Am Mittwoch, 6. Mai 2015 18:08:03 UTC+2 schrieb Sven Pedersen:
>
> 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 

 LuminusClojure28678 
 CaribouClojure 2275 

 BeegoGolang991522 

 PhoenixElixir  1241949 

 YesodHaskell   1303722 

 LaravelPHP2684421 

 PlayScala   4176085 

 SymfonyPHP113020914 

 RailsRuby   269151000 


 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 
>>>

Re: Clojure needs a web framework with more momentum

[Tj Gabbour]

On Wednesday, May 6, 2015 at 6:34:15 PM UTC+2, Sean Corfield wrote:
>
> The issue has been raised several times and is pretty much always shut 
> down by "those in charge". It was a huge struggle just to have the Getting 
> Started page updated to remove complexity and point at the wiki instead 
> (although the wiki is also _horrible_ from the point of view of new users).
>

 Did they ever articulate reasons? (Even if vague/brief?)

-- 
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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

>Also, most of the time you do not need any complex "framework" to build a 
basic webservice with Clojure. 

True. Also, what is a basic web service? I have a friend who just got done 
with the 12 week crash-course in Rails that is offered by DevBootcamp in 
New York City. In 12 weeks he had to learn: 

what is an http header?

what is a request?

what is a response?

what is Unix?

what is a terminal? 

basic terminal tools: cd, find, grep, cat, less, |, >, <, sudo, chmod

what is a "port" and how does it work with IP addresses?

what is DNS?

what is an application server? 

what is a web server? 

how to set up a reverse proxy

Javascript

Ruby

gems

Rails

Rake commands: db:migrate, db:load, 'rake routes' etc,

ActiveRecord

SQL

MySql

foreign key relationships

Javascript

pre-processors

HTML template languages

etc, etc, etc,

You get the idea. There is a lot to know. The only language that makes it 
really easy to get going on the web is PHP. If the question is "How can 
Clojure be as simple as PHP to get started with?" then I think that is an 
interesting question, and we could work toward that as a community -- there 
might be some defaults that eventually let Lisp demonstrate its power to 
simplify things. But making things as easy as PHP is a difficult challenge. 
Making things as easy as Rails should be easy, because Rails is not 
especially easy for beginners. 





On Wednesday, May 6, 2015 at 9:20:58 AM UTC-4, Stanislav Yurin wrote:
>
> A bit strange approach. Where are ring, compojure, or maybe .. om?
>
> Also, most of the time you do not need any complex "framework" to build a 
> basic webservice with Clojure. 
> Say, Luminus and Caribou are too complex for me, hence too restrictive.
> After writing sufficient amount of fairly good Clojure code, super rapid 
> web-service mocking skills come to you as a bonus.
>
> On Saturday, May 2, 2015 at 11:43:53 PM UTC+3, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what 
>> I found: 
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>>
>> LuminusClojure28678 
>> CaribouClojure 2275 
>>
>> BeegoGolang991522 
>>
>> PhoenixElixir  1241949 
>>
>> YesodHaskell   1303722 
>>
>> LaravelPHP2684421 
>>
>> PlayScala   4176085 
>>
>> SymfonyPHP113020914 
>>
>> RailsRuby   269151000 
>>
>>
>> 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.

Re: Clojure needs a web framework with more momentum

[Sven Pedersen]

Yes, Sven Richter has started a project called closp-crud that does just 
that. However it is also pretty easy to use Korma or YeSQL directly, 
especially from Luminus.
--Sven

On Wednesday, May 6, 2015 at 1:15:20 PM UTC-4, larry google groups wrote:
>
> > Maybe I don't entirely understand what a web framework is, but it seems 
> to me 
> > like Immutant is an example of something that might fit into a lot of 
> the buckets. 
>
> I agree. Perhaps people feel that it lacks the auto-generation of 
> scaffolding for CRUD? Though I imagine that would be easy to fix. 
>
>
>
>
> On Tuesday, May 5, 2015 at 7:29:28 PM UTC-4, Surgo wrote:
>>
>> Maybe I don't entirely understand what a web framework is, but it seems 
>> to me like Immutant is an example of something that might fit into a lot of 
>> the buckets. Could someone explain how that isn't the case?
>>
>> Thanks,
>> -- Morgon
>>
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> Maybe I don't entirely understand what a web framework is, but it seems 
to me 
> like Immutant is an example of something that might fit into a lot of the 
buckets. 

I agree. Perhaps people feel that it lacks the auto-generation of 
scaffolding for CRUD? Though I imagine that would be easy to fix. 




On Tuesday, May 5, 2015 at 7:29:28 PM UTC-4, Surgo wrote:
>
> Maybe I don't entirely understand what a web framework is, but it seems to 
> me like Immutant is an example of something that might fit into a lot of 
> the buckets. Could someone explain how that isn't the case?
>
> Thanks,
> -- Morgon
>

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Shaun Mahood]

On top of all of that, Pedestal is a non-starter for me due to the specific 
definition of Windows being a non-supported platform.

On Wednesday, May 6, 2015 at 10:48:58 AM UTC-6, Sean Corfield wrote:
>
> On May 6, 2015, at 9:42 AM, Sean Corfield  > wrote:
>
> And that’s why I thought that Pedestal looked very complex and hard to 
> use. Even the Hello World example is couched in terms that make it look 
> overly complex.
>
>
> I Googled to see if there was a better page explaining Pedestal and didn’t 
> find anything obvious. I did find this tho’:
>
> http://www.lispcast.com/what-web-framework-should-i-use
>
> "Pedestal… Though, I would caution you that it's not for a Clojure 
> beginner. *Pedestal introduces a lot of new concepts that even 
> experienced Clojure programmers have to learn.*The tutorial is long and 
> arduous. You will have problems learning Pedestal without knowing Clojure." 
> (Eric’s emphasis)
>
> Admittedly that is talking about the entire Pedestal stack, not just the 
> back end portion that it has become now. Until recently, I didn’t know that 
> Pedestal had split in two and had previously discounted it as "that complex 
> full-stack thing" (much like ClojureScript One etc). Eric’s article has 
> this note:
>
> "Update: Pedestal has changed dramatically since I last looked at it. It 
> is no longer a frontend framework. *It is now a high-performance backend 
> server for high performance asynchronous processing.* It's worth looking 
> at if you need that. Otherwise, I stick with my recommendation to use basic 
> Ring." (my emphasis)
>
> Anyone looking for an easy web framework to get up and running with is 
> likely to think the same thing.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 6, 2015, at 9:42 AM, Sean Corfield  wrote:
> And that’s why I thought that Pedestal looked very complex and hard to use. 
> Even the Hello World example is couched in terms that make it look overly 
> complex.

I Googled to see if there was a better page explaining Pedestal and didn’t find 
anything obvious. I did find this tho’:

http://www.lispcast.com/what-web-framework-should-i-use

"Pedestal… Though, I would caution you that it's not for a Clojure beginner. 
Pedestal introduces a lot of new concepts that even experienced Clojure 
programmers have to learn.The tutorial is long and arduous. You will have 
problems learning Pedestal without knowing Clojure." (Eric’s emphasis)

Admittedly that is talking about the entire Pedestal stack, not just the back 
end portion that it has become now. Until recently, I didn’t know that Pedestal 
had split in two and had previously discounted it as "that complex full-stack 
thing" (much like ClojureScript One etc). Eric’s article has this note:

"Update: Pedestal has changed dramatically since I last looked at it. It is no 
longer a frontend framework. It is now a high-performance backend server for 
high performance asynchronous processing. It's worth looking at if you need 
that. Otherwise, I stick with my recommendation to use basic Ring." (my 
emphasis)

Anyone looking for an easy web framework to get up and running with is likely 
to think the same thing.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 6, 2015, at 4:26 AM, Paul deGrandis  wrote:
> I would argue that Pedestal is perhaps objectively simpler than Ring.  I 
> would also add it's more performant, more flexible, and more secure (by 
> default).

As Surgo said in the other thread:

"Projects like Pedestal do themselves a tremendous disservice with their poor 
front pages. It's probably an amazing project but it was very difficult to get 
a sense from the README.Md what it could actually do for me. Whoever owns the 
Pedestal project, please add a section to the top that is literally called 
something like "What Pedestal can do for you" and answers that question."

And that’s why I thought that Pedestal looked very complex and hard to use. 
Even the Hello World example is couched in terms that make it look overly 
complex.

And it’s not just Pedestal. A lot of Clojure projects suffer from this. 
java.jdbc suffers from this and it’s really easy to use too — I just haven’t 
figured out how to explain it properly :(

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

Thanks Avi! I’ll bookmark that and see whether I can either borrow from it or 
contribute to it in the context of FW/1 :)

Sean

> On May 6, 2015, at 3:46 AM, Avi Avicenna  wrote:
> 
> There is one,
> 
> Wakeful (https://github.com/ninjudd/wakeful) routing library fits your 
> criteria. 
> 
> Here I copy the sample from its README
> 
> (use 'flatland.wakeful.core)
> 
> (def handler (wakeful "awesome.api"))
> Now http calls dispatch to methods calls in namespaces under awesome.api:
> 
> GET  /photo-123/thumbnail  -> awesome.api.photo/thumbnail
> GET  /photo-123/tags   -> awesome.api.photo/tags
> POST /photo-123/tag/user-1 -> awesome.api.photo/tag!
> 
> Unfortunately, it's been 2 years since last commit.


-- 
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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 5, 2015, at 11:48 PM, Kristo Koert  wrote:
> My argument was that a more visually appealing homepage would leave a better 
> first impression and attract more new beginner developers to check out 
> clojure. (Ex. comparing haskell.org or scala-lang.org vs clojure.org). An 
> opinion was expressed that "we don't need these low quality people in the 
> community". 
> 
> This excludes quite a lot of complete newcomers, because ofcourse they cannot 
> tell the merits or demerits of a languages from a wall of text in unfamiliar 
> syntax from a page that seems to be without much love. They will see a 
> seemingly unappealing language. They will not have the opportunity to learn 
> to not judge a programming language based on the homepage until far later in 
> their careers maybe.

This is particularly frustrating from the point of view of someone involved in 
ClojureBridge, where the whole point is to reach out to tech minorities and 
encourage complete beginners to try Clojure. The issue has been raised several 
times and is pretty much always shut down by "those in charge". It was a huge 
struggle just to have the Getting Started page updated to remove complexity and 
point at the wiki instead (although the wiki is also _horrible_ from the point 
of view of new users).

It shows through in Clojure tooling as well (the most popular editor — Emacs — 
is far from beginner-friendly). ClojureBridge chose LightTable because it 
seemed to be the most beginner-friendly (even tho’ you still needed Leiningen). 
CCW and Cursive are great for developers who already use IDEs but not for folks 
who’ve never programmed before. Some of the other easy on-ramps are too clunky 
right now to stick with beyond initially learning Clojure — and LightTable has 
the added benefit of being a good editor for HTML, CSS, and JavaScript (with 
live in-browser evaluation). Unfortunately, LightTable development has stalled 
and its future is rather unclear.

The "rough edges" show up on a lot of things in the Clojure ecosystem. I know I 
suck at documentation which is why I moved clojure.java.jdbc’s documentation 
out to http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html 
 which can be 
maintained by the community through Pull Requests etc. In two years, there have 
been just two small changes from the community: the rest of the updates are 
from me, despite several people complaining about the documentation being 
unclear or insufficient.

I think this is also part of the reason behind the lack of approachable and 
well-maintained web frameworks: the sense that smart people don’t need them and 
beginners will either figure it out or they won’t — that and the fact that the 
majority of us in the Clojure community seem to suck at documentation (with a 
few shining exceptions!).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Clojure needs a web framework with more momentum

[Sven Pedersen]

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 
>>>
>>> LuminusClojure28678 
>>> CaribouClojure 2275 
>>>
>>> BeegoGolang991522 
>>>
>>> PhoenixElixir  1241949 
>>>
>>> YesodHaskell   1303722 
>>>
>>> LaravelPHP2684421 
>>>
>>> PlayScala   4176085 
>>>
>>> SymfonyPHP113020914 
>>>
>>> RailsRuby   269151000 
>>>
>>>
>>> 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

Re: Clojure needs a web framework with more momentum

[Sven Pedersen]

Good points, puzzler. 

I'm in the last stages of getting an commerce site ready for production and 
my issues with getting authentication to work properly may force my company 
to switch to an inferior but easier to configure technology (i.e., abandon 
Clojure). 

Sven Richter's friend-ui/closp work on auth/authz is quite good, but not 
there yet. Luminous is brilliant (pun intended) but the auth piece is not 
there yet. I've started a lib for payment gateway integration with 
authorize.net and there is a partly broken implementation of PayPal IPN 
(callback handling). I've got a nice JavaScript shopping cart -- a fork of 
SimpleCart(js) that is functional for most cases, with a Clojure parser for 
its terrible POST format (not yet released).

Modularity, as Clojure's web libraries have been pursuing it, is a very 
good idea -- I've been able to choose among several options and put 
together an app like Legos. Alas, small differences in dependencies make 
some modules unable to work together. But I think the Leiningen  template 
way is very effective.
--Sven

On Saturday, May 2, 2015 at 11:19:19 PM UTC-4, puzzler wrote:
>
> Last week, at the Clojure/West conference, someone (I think it was Brandon 
> Bloom) summed up the general vibe well, by saying something along the lines 
> of, "We now have all the pieces in place to make web development an order 
> of magnitude more productive than in any other language, we just need to 
> figure out how to put it all together and make that happen."
>
> I think that's right.  From a technological standpoint, I think we're 
> there.  The things we most need are informational resources and 
> higher-level shared resources, such as UI widgets.  For example:
>
> How do we use Buddy/Friend effectively to achieve secure web apps?  (The 
> docs are not sufficiently informative for those who haven't thought much 
> about security and assume too much prior knowledge).
>
> How do we effectively leverage some of the more advanced Clojure-oriented 
> webservers such as Aleph and Immutant?
>
> Clojure is great for creating new, disruptive web models, but what's the 
> easiest path to creating something that can be done trivially with, say, 
> Drupal or Django?
>
> Since more and more people are working with Reagent/Om/etc., we need as 
> many Bootstrap-like widgets as possible for those tools, and more 
> informational resources about how to use these new reactive models 
> effectively, for example, how to do animated UIs.
>
> Are there reusable components like, say, shopping baskets?
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[Surgo]

Projects like Pedestal do themselves a tremendous disservice with their 
poor front pages. It's probably an amazing project but it was very 
difficult to get a sense from the README.Md what it could actually do for 
me. Whoever owns the Pedestal project, please add a section to the top that 
is literally called something like "What Pedestal can do for you" and 
answers that question.

Compare to the Immutant front page, which immediately tells you what it can 
do for you and how it works.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Stanislav Yurin]

Colin,
Indeed, there is no ready-made shopping cart for Clojure (from what I 
know). 
Recently I was making the personal project site, and was also seeking for 
that, with no luck.
Until I have realized that the shopping cart is just two data tables and 
(optional) user auth system (buddy worked for me). 

On Sunday, May 3, 2015 at 11:40:33 PM UTC+3, Colin Fleming wrote:
>
> A shopping cart. All the available Java ones require a J2EE stack.
>
> On 3 May 2015 at 21:49, Sven Richter > 
> wrote:
>
>> Hi,
>>
>> Am Sonntag, 3. Mai 2015 11:38:14 UTC+2 schrieb g vim:
>>>
>>> On 03/05/2015 05:24, Sean Corfield wrote: 
>>> > On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg >> > > wrote: 
>>> > 
>>> > Clojure is great for creating new, disruptive web models, but 
>>> what's 
>>> > the easiest path to creating something that can be done trivially 
>>> > with, say, Drupal or Django? 
>>> > 
>>> > 
>>> > The question tho' is why you'd want to use Clojure for something that 
>>> is 
>>> > already trivially solved with free packaged software for widely used 
>>> > scripting languages where cheap, plentiful developers are falling over 
>>> > themselves to help... :) 
>>> > 
>>> > Clojure doesn't have to be the solution for every problem. It 
>>> certainly 
>>> > doesn't need to be the solution for low-value problems... 
>>>
>>> Forgive me if that sounds a little elitist. What if I want to do what 
>>> Django can do but in Clojure? If Clojure is a better option there should 
>>> be something which can do more than Django. If my only choice is library 
>>> composition by definition it doesn't do what Django does well, ie. a 
>>> fully-structured setup out of the box with a predictable, best of breed 
>>> set of technologies. 
>>>
>>> There are many businesses, large and small, who will only go with a 
>>> well-established web framework with a vibrant community. Sadly, 
>>> Clojure's preference for protecting its niche means it will never be an 
>>> option for these opportunities, hence its poor showing in job listings. 
>>> Do we, as a community, want to be paid for what we do? 
>>>
>>
>> Again I am missing some exact requests on what can be done in django that 
>> cannot be done in clojure? This by no means an offense, I am just curious 
>> about your experiences.
>>
>> Best Regards,
>> Sven
>>
>> -- 
>> 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.

Re: Clojure needs a web framework with more momentum

[Stanislav Yurin]

A bit strange approach. Where are ring, compojure, or maybe .. om?

Also, most of the time you do not need any complex "framework" to build a 
basic webservice with Clojure. 
Say, Luminus and Caribou are too complex for me, hence too restrictive.
After writing sufficient amount of fairly good Clojure code, super rapid 
web-service mocking skills come to you as a bonus.

On Saturday, May 2, 2015 at 11:43:53 PM UTC+3, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> 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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Paul deGrandis]

This is for Sean specifically, but hopefully this will clear some things up 
for other people

I would argue that Pedestal is perhaps objectively simpler than Ring.  I 
would also add it's more performant, more flexible, and more secure (by 
default).

In Pedestal, everything is an interceptor - a record that has `:enter`, 
`:leave`, and `:error` actions/functions (there is no distinction between 
handlers and middleware).  Interceptors take a context (a map that holds 
the `:request` and `:response`), and returns a context.  Requests and 
Responses are exactly the same as they are in Ring.  As soon as a 
`:response` is present in the context, it's returned through the 
interceptor chain (sent to the client and processing is stopped).  If you 
want to go async, your interceptor returns a core.async channel (instead of 
a context), which will eventually receive a context.  Your response bodies 
can be just about anything, including NIO things (byte-buffers, etc.).

Everything in Pedestal is programmed against a protocol, allowing you to 
extend every piece of the system to fit your application.

By default, Pedestal uses secure headers, CSRF protection, and a host of 
other best-practices for secure web services.

You know how everything works in Pedestal.  Release notes are very 
detailed: https://github.com/pedestal/pedestal/releases

Cheers,
Paul

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Avi Avicenna]

There is one,

Wakeful (https://github.com/ninjudd/wakeful) routing library fits your 
criteria. 

Here I copy the sample from its README

(use 'flatland.wakeful.core)

(def handler (wakeful "awesome.api"))

Now http calls dispatch to methods calls in namespaces under awesome.api:

GET  /photo-123/thumbnail  -> awesome.api.photo/thumbnail

GET  /photo-123/tags   -> awesome.api.photo/tags

POST /photo-123/tag/user-1 -> awesome.api.photo/tag!


Unfortunately, it's been 2 years since last commit.


On Wednesday, 6 May 2015 06:53:14 UTC+7, Sean Corfield wrote:
>
> Perhaps I should rephrase that as a request for simple, convention-based 
> routing that works with Ring directly? :) 
>
> I’m sure Pedestal’s great, but just looking at the repo and documentation 
> doesn’t exactly scream "simple"… I just don’t want to have to read that 
> much documentation to get a simple web app up and running. 
>
> Sean 
>
> On May 5, 2015, at 4:45 PM, Paul deGrandis  > wrote: 
> > Pedestal's router is just an interceptor in the chain.  You could easily 
> write an interceptor that looks at the request and sees if it can resolve a 
> var by that name.  You could even stack multiple routers - first the var/fn 
> lookup and failing that, a more explicit router. 
>
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[Hildeberto Mendonça]

Recommended article for those who want a library accumulator, with 20%
effective utility and 80% fat, also called framework:
http://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/04/mso2015020010.pdf

On Wed, May 6, 2015 at 8:48 AM, Kristo Koert  wrote:

> I unfortunately agree on the difficulty of entrance for newcomers to
> clojure and I'd like to add that I've been left feeling that this seem to
> not be a priority in the community. Once I discussed the visual asthetics
> of clojure.org on #clojure and although the tradeoff of easy data access
> and eye candy was explained to me, it was done in a way that left me a bit
> uneasy.
>
> My argument was that a more visually appealing homepage would leave a
> better first impression and attract more new beginner developers to check
> out clojure. (Ex. comparing haskell.org or scala-lang.org vs clojure.org).
> An opinion was expressed that "we don't need these low quality people in
> the community".
>
> This excludes quite a lot of complete newcomers, because ofcourse they
> cannot tell the merits or demerits of a languages from a wall of text in
> unfamiliar syntax from a page that seems to be without much love. They will
> see a seemingly unappealing language. They will not have the opportunity to
> learn to not judge a programming language based on the homepage until far
> later in their careers maybe.
>
> This leaves me feeling that clojure is only for the already experienced
> developers who know the ins and outs of programming and thus know how to
> choose their tools, so clojure would have a high concentration of high
> quality partitioners. (although less in number) Such a community would have
> little use for opinionated web framework, because everyone is smart enough
> to choose their own tools.
>
> Unfortunately I do not feel I fit in and struggle daily to choose the
> right tools, since there are no clear cut, best general purpose
> defaults. Just my 2c.
>
> Regards
> Kristo
>
> On Monday, May 4, 2015 at 5:42:08 PM UTC+3, Thiago F M wrote:
>>
>> My 2 cents:
>>
>> I don't think the biggest problem is that the community is fragmented as
>> there is many options to choose, but that the attitude towards newcomers is
>> bad.
>>
>> Let's say that I was learning clojure about 2 years ago and when I asked
>> about which web framework should I use, people started raising stuff about
>> the implementation of those frameworks like pedestal have some very strange
>> concepts like this one:
>>
>>
>> https://github.com/pedestal/docs/blob/master/documentation/application-overview.md
>>
>> So I was like: WTF. I'm fucked. Forget that. Let's just go back to the
>> clojure book and write a factorial implementation.
>>
>> So every once in a while I came back to clojure, did something. Studied
>> some clojurescript and finally I think that I can write some clojure... but
>> that took time and I still don't feel good about it. I feel sometimes that
>> there's a lot of very good people working in Relevance which knows
>> everything about clojure, but doesn't share anywhere. Maybe if we had a
>> couple of very good screencasts and proper documentation of how to write a
>> webapp in clojure available in the web. It could be very optioned(about
>> what libs to use), it could be even wrong... but getting something done
>> when you are beginning is way more important than to be concerned about if
>> you are doing the right thing.
>>
>> But that might be just me.
>>
>> On Mon, May 4, 2015 at 3:34 PM, Ernie de Feria 
>> 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,

Re: Clojure needs a web framework with more momentum

[Kristo Koert]

I unfortunately agree on the difficulty of entrance for newcomers to 
clojure and I'd like to add that I've been left feeling that this seem to 
not be a priority in the community. Once I discussed the visual asthetics 
of clojure.org on #clojure and although the tradeoff of easy data access 
and eye candy was explained to me, it was done in a way that left me a bit 
uneasy.

My argument was that a more visually appealing homepage would leave a 
better first impression and attract more new beginner developers to check 
out clojure. (Ex. comparing haskell.org or scala-lang.org vs clojure.org). 
An opinion was expressed that "we don't need these low quality people in 
the community". 

This excludes quite a lot of complete newcomers, because ofcourse they 
cannot tell the merits or demerits of a languages from a wall of text in 
unfamiliar syntax from a page that seems to be without much love. They will 
see a seemingly unappealing language. They will not have the opportunity to 
learn to not judge a programming language based on the homepage until far 
later in their careers maybe.

This leaves me feeling that clojure is only for the already experienced 
developers who know the ins and outs of programming and thus know how to 
choose their tools, so clojure would have a high concentration of high 
quality partitioners. (although less in number) Such a community would have 
little use for opinionated web framework, because everyone is smart enough 
to choose their own tools. 

Unfortunately I do not feel I fit in and struggle daily to choose the right 
tools, since there are no clear cut, best general purpose defaults. Just my 
2c.

Regards
Kristo

On Monday, May 4, 2015 at 5:42:08 PM UTC+3, Thiago F M wrote:
>
> My 2 cents:
>
> I don't think the biggest problem is that the community is fragmented as 
> there is many options to choose, but that the attitude towards newcomers is 
> bad.
>
> Let's say that I was learning clojure about 2 years ago and when I asked 
> about which web framework should I use, people started raising stuff about 
> the implementation of those frameworks like pedestal have some very strange 
> concepts like this one:
>
>
> https://github.com/pedestal/docs/blob/master/documentation/application-overview.md
>
> So I was like: WTF. I'm fucked. Forget that. Let's just go back to the 
> clojure book and write a factorial implementation.
>
> So every once in a while I came back to clojure, did something. Studied 
> some clojurescript and finally I think that I can write some clojure... but 
> that took time and I still don't feel good about it. I feel sometimes that 
> there's a lot of very good people working in Relevance which knows 
> everything about clojure, but doesn't share anywhere. Maybe if we had a 
> couple of very good screencasts and proper documentation of how to write a 
> webapp in clojure available in the web. It could be very optioned(about 
> what libs to use), it could be even wrong... but getting something done 
> when you are beginning is way more important than to be concerned about if 
> you are doing the right thing. 
>
> But that might be just me.
>
> On Mon, May 4, 2015 at 3:34 PM, Ernie de Feria  > 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 co

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Mischov]

Routes-as-data routing libraries, such Bidi or (I know... complicated...) 
Pedestal, should be able to (fairly) easily create abstractions that permit 
convention-based routing.

It's not exactly what you're talking about, but I made a little toy example 
of how you could mimic Rails resource routing on top of Gate.

https://github.com/mischov/gate/blob/master/examples/gate/examples/crud_example.clj

On Tuesday, May 5, 2015 at 6:53:14 PM UTC-5, Sean Corfield wrote:
>
> Perhaps I should rephrase that as a request for simple, convention-based 
> routing that works with Ring directly? :) 
>
> I’m sure Pedestal’s great, but just looking at the repo and documentation 
> doesn’t exactly scream "simple"… I just don’t want to have to read that 
> much documentation to get a simple web app up and running. 
>
> Sean 
>
> On May 5, 2015, at 4:45 PM, Paul deGrandis  > wrote: 
> > Pedestal's router is just an interceptor in the chain.  You could easily 
> write an interceptor that looks at the request and sees if it can resolve a 
> var by that name.  You could even stack multiple routers - first the var/fn 
> lookup and failing that, a more explicit router. 
>
>

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 5, 2015, at 6:30 PM, Herwig Hochleitner  wrote:
> Cool Idea! Convention based routing is a great way to get started quickly and 
> I think that it actually might make a lot of people, asking for clojure 
> frameworks, happy.
> I'm not aware of any clojure lib that does that, but I'd like to speculate a 
> bit on what it might mean:
> 
> As it happens, when I hear 'convention based routing', I think of mapping web 
> paths to file system paths, the way most web servers do, where resource 
> variants and/or behavior are configured by path patterns (most often by 
> suffix a'la *.php).
> 
> A lot could be said about the merit of letting people use just their file 
> browser to set up even moderately complex web apps, but of course there are 
> also downsides:
> This approach leads to components being scattered over multiple files, where 
> n files would need to be renamed to rename a single resource.
> Also it probably won't interact well with java's classpath loading, so a 
> leiningen plugin would be needed to index the app before packaging.

Yup, arbitrary URL-to-file system mapping is often horrible.

Here’s how FW/1 works:

* A request comes in for /foo/bar
* FW/1 attempts to require {appname}.controllers.foo
* If that succeeds, FW/1 attempts to resolve {appname}.controllers.foo/bar as a 
symbol
* If that succeeds, that function is called as a handler for the current request

Only public functions in existing namespaces in the /{appname}/controllers 
folder will resolve to match inbound requests.

FW/1 locates views and a cascade of optional layout wrappers via convention 
too. There are also "before" and "after" extension points for pre- and 
post-processing to occur application-wide and/or per-controller. You can also 
specify some explicit routes that should map differently (basic but standard 
routing with :name style placeholders — explicit routes are currently 
undocumented as they’re a work-in-progress).

A simple "user manager" example is here: 
https://github.com/framework-one/fw1-clj/tree/master/examples/usermanager 


As indicated in the original thread, a lot of people have built substantial 
production apps with FW/1 in its original language. It’s hit a particular sweet 
spot for a lot of people in being really easy to get up and running with, but 
useful enough to build serious business apps. Right now, no one is using this 
Clojure port (except me, mostly for fun). That’s why I haven’t promoted it here 
(beyond a few passing mentions).

There’s a Leiningen template:

lein new fw1 tryme
cd tryme
PORT=8321 lein run
go to http://localhost:8321/

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Herwig Hochleitner]

Cool Idea! Convention based routing is a great way to get started quickly
and I think that it actually might make a lot of people, asking for clojure
frameworks, happy.
I'm not aware of any clojure lib that does that, but I'd like to speculate
a bit on what it might mean:

As it happens, when I hear 'convention based routing', I think of mapping
web paths to file system paths, the way most web servers do, where resource
variants and/or behavior are configured by path patterns (most often by
suffix a'la *.php).

A lot could be said about the merit of letting people use just their file
browser to set up even moderately complex web apps, but of course there are
also downsides:
This approach leads to components being scattered over multiple files,
where n files would need to be renamed to rename a single resource.
Also it probably won't interact well with java's classpath loading, so a
leiningen plugin would be needed to index the app before packaging.

Still, for accessibility, I'd put my money on automatic file-system-path
mapping, rather than method mapping or source annotations.


At this point, I'd like to honorably mention the nix programming language,
where the idiomatic way to define a module is to define a file like this:

{dep1, dep2}:
implementation ...

That is a file, containing a nix function with a single parameter `param:
body`, where the parameter is destructured. This function can be loaded as
is, by `import ./file.nix`. It can by auto-called with its dependencies by
`pkgs.callPackage ./file.nix {/*dep-overrides*/}`, thus, the package
instantiated (yes, callPackage discovers the needed dependency symbols and
takes them from pkgs, with optional overrides). This makes it easy and
idiomatic to work with file-mapping, while not even needing namespaces or
top-level names.

Maybe something like that could be done to sneak clojure behavior into
static file serving?


What do you think?

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

Perhaps I should rephrase that as a request for simple, convention-based 
routing that works with Ring directly? :)

I’m sure Pedestal’s great, but just looking at the repo and documentation 
doesn’t exactly scream "simple"… I just don’t want to have to read that much 
documentation to get a simple web app up and running.

Sean

On May 5, 2015, at 4:45 PM, Paul deGrandis  wrote:
> Pedestal's router is just an interceptor in the chain.  You could easily 
> write an interceptor that looks at the request and sees if it can resolve a 
> var by that name.  You could even stack multiple routers - first the var/fn 
> lookup and failing that, a more explicit router.

-- 
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.

Re: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Paul deGrandis]

Hi Sean,

Pedestal's router is just an interceptor in the chain.  You could easily 
write an interceptor that looks at the request and sees if it can resolve a 
var by that name.  You could even stack multiple routers - first the var/fn 
lookup and failing that, a more explicit router.

Cheers,
Paul

-- 
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.

Re: Clojure needs a web framework with more momentum

[Surgo]

Maybe I don't entirely understand what a web framework is, but it seems to 
me like Immutant is an example of something that might fit into a lot of 
the buckets. Could someone explain how that isn't the case?

Thanks,
-- Morgon

-- 
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.

Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Sean Corfield]

In the web framework thread, a number of routing libraries were mentioned but 
they all seemed to be based on explicit routing.

I’m used to working in web environments where routing is usually implicit so 
that a request for:

/foo/bar

gets automatically routed to a method bar() in a handler named foo (usually as 
a class).

This is nice because you don’t need to declare every route: you can just write 
a view template in the appropriate place and you have a web response — and you 
can add an appropriately named handler function and have the business logic 
automagically wired in.

You can generally provide overrides for some explicit routes as well if you 
want them handled differently.

Are there any such libraries for Clojure? Are they well-maintained?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Clojure needs a web framework with more momentum

[Kyle Dawkins]

Justin Smith speaks the truth about Caribou.  I'm also one of the team 
members, and although we did lose our funding, we're all still around and 
there are a number of active Caribou projects alive and well.  It does have 
everything Justin says, and yes, it's imperfect, but it's also very easy to 
get a site up and running quickly.  But you don't lose the modularity that 
we all love in the Clojure world.  You can use just part of it (we know of 
numerous people using Polaris for routing, for example, and nothing else at 
all from the Caribou ecosystem) or all of it if you want.   The CRUD UI in 
the admin tool is handy but a bit on the clunky side (for historical 
reasons which I won't go into here) but can be customised quite easily if 
you have a decent UI/UX person to do it.   When we had our funding, we were 
all very invested in the project and are deeply proud of what we were able 
to achieve in a relatively short timespan.   We also have the best URL :)

http://let-caribou.in

Cheers!
Kyle




On Tuesday, May 5, 2015 at 8:41:51 AM UTC-7, Justin Smith wrote:
>
> Wow, what a thread! 
>
> As one of the authors and designers of Caribou, I have a couple of 
> clarifications to offer. 
>
> When the initial post compared contributors and commits, it picked our 
> "caribou" repo, which, while extensive, holds no code, only our docs. The 
> actual code is in caribou-core (persistence layer via edn abstraction), 
> polaris (routing via edn data structures), caribou-api (rest api to 
> caribou-core), antlers (an extended edn friendly mustache for templating), 
> lichen (automated caching image resizer with optional s3 integration and 
> stand alone http server), schmetterling (web ui for debugging exceptions, 
> with in frame evaluation and locals display), caribou-frontend (pulling 
> together core, antler, lichen, polaris and ring to make a site), and 
> caribou-admin (crud ui for caribou-core models, including a drag and drop 
> ui to define routes that can be imported by polaris). 
>
> Caribou is not abandoned, though it did lose funding. I currently use core 
> plus polaris without the other components at my day job, though working on 
> Caribou itself is not strictly in scope for my salaried work. 
>
> Which is to say, Caribou is very much a "modular framework" ( though much 
> of it does rely on the caribou-core persistence abstraction). It's 
> imperfect but useful, and work is slowed but not abandoned. 
>
>  I'm always always in #caribou on freenode, and we have extensive docs.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Justin Smith]

Wow, what a thread!

As one of the authors and designers of Caribou, I have a couple of 
clarifications to offer.

When the initial post compared contributors and commits, it picked our 
"caribou" repo, which, while extensive, holds no code, only our docs. The 
actual code is in caribou-core (persistence layer via edn abstraction), polaris 
(routing via edn data structures), caribou-api (rest api to caribou-core), 
antlers (an extended edn friendly mustache for templating), lichen (automated 
caching image resizer with optional s3 integration and stand alone http 
server), schmetterling (web ui for debugging exceptions, with in frame 
evaluation and locals display), caribou-frontend (pulling together core, 
antler, lichen, polaris and ring to make a site), and caribou-admin (crud ui 
for caribou-core models, including a drag and drop ui to define routes that can 
be imported by polaris).

Caribou is not abandoned, though it did lose funding. I currently use core plus 
polaris without the other components at my day job, though working on Caribou 
itself is not strictly in scope for my salaried work.

Which is to say, Caribou is very much a "modular framework" ( though much of it 
does rely on the caribou-core persistence abstraction). It's imperfect but 
useful, and work is slowed but not abandoned.

 I'm always always in #caribou on freenode, and we have extensive docs.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Sébastien Orban]

To be honest it's disquieting that some of use think that because the 
problem is "solved" elsewhere we can't do better : we can, and we should. 

I appreciate the effort that has been made since the dawn of PHP for simple 
website - but we seem to be stuck on "Rails" iterative period - by that I 
mean that nothing that change (maybe not improve...) the status quo has 
arisen. Clojure, with its power and possibilities could be the mean to this 
end - I hope so (if not Clojure, let's hope it will be in a language that 
offer that much). 

In the meantime, the Luminus approach seem spot on : aggregate package and 
build on top of it. We have solution for nearly everything, but it can be 
sometime hard to discover it. Sometimes it's documentation, sometimes it's 
because there isn't a following huge enough to get result... Sad thing is : 
most of the libraries I've search for, even if obscure, are of very high 
quality.

But let's not be sad : it's getting easier. Tools are getting better and 
better, and the web framework we're discussing about will probably arise 
soon. Other eco system are not that lucky - people want it to happen in the 
Clojure world. And they want it to be top notch !

On Tuesday, May 5, 2015 at 5:01:35 PM UTC+2, Gary Schiltz wrote:
>
> Colin's response is spot on. The Clojure ecosystem is a lot of fun, and is 
> really good for solving complex problems, but I think it falls short for 
> handling things that have already been solved in other less technically 
> interesting ecosystems. Shopping carts and payment gateway integration, as 
> he mentioned, are two obvious ones; anything related to customer 
> relationship management is another category, i.e. mailing list management. 
> Probably in these cases, it would be better to just go with the existing 
> less elegant (technology-wise) solutions, including content management 
> systems like WordPress, Joomla, or Drupal. In fact, it would be worthwhile 
> to go through their plug-in pages to categorize what types of problems and 
> solutions are provided for CMS type systems. Just be sure to wear tall 
> boots if you have to wade into the PHP :-)
>
> On Sunday, May 3, 2015 at 1:21:31 AM UTC-5, Colin Fleming wrote:
>>
>> Because, in my case, I'm going to need a website shortly that I can use 
>> to sell Cursive. I'd really like to use Clojure for that. I could use Rails 
>> or Django which would make the site itself trivial, except I don't know 
>> either of them and then I'm stuck maintaining something in a language and 
>> framework I have no interest in and don't understand how to deploy or 
>> maintain. Or I could do it in Clojure which means that I understand the 
>> libraries, frameworks, deployment and monitoring inside and out, except I 
>> now have to implement a shopping cart and integrations with payments 
>> gateways etc. Neither of these are great options for me.
>>
>> On 3 May 2015 at 16:24, Sean Corfield  wrote:
>>
>>> On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg  
>>> wrote:
>>>
 Clojure is great for creating new, disruptive web models, but what's 
 the easiest path to creating something that can be done trivially with, 
 say, Drupal or Django?

>>>
>>> The question tho' is why you'd want to use Clojure for something that is 
>>> already trivially solved with free packaged software for widely used 
>>> scripting languages where cheap, plentiful developers are falling over 
>>> themselves to help... :)
>>>
>>> Clojure doesn't have to be the solution for every problem. It certainly 
>>> doesn't need to be the solution for low-value problems...
>>> -- 
>>> 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)
>>>  
>>> -- 
>>> 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://gro

Re: Clojure needs a web framework with more momentum

[Gary Schiltz]

Colin's response is spot on. The Clojure ecosystem is a lot of fun, and is 
really good for solving complex problems, but I think it falls short for 
handling things that have already been solved in other less technically 
interesting ecosystems. Shopping carts and payment gateway integration, as 
he mentioned, are two obvious ones; anything related to customer 
relationship management is another category, i.e. mailing list management. 
Probably in these cases, it would be better to just go with the existing 
less elegant (technology-wise) solutions, including content management 
systems like WordPress, Joomla, or Drupal. In fact, it would be worthwhile 
to go through their plug-in pages to categorize what types of problems and 
solutions are provided for CMS type systems. Just be sure to wear tall 
boots if you have to wade into the PHP :-)

On Sunday, May 3, 2015 at 1:21:31 AM UTC-5, Colin Fleming wrote:
>
> Because, in my case, I'm going to need a website shortly that I can use to 
> sell Cursive. I'd really like to use Clojure for that. I could use Rails or 
> Django which would make the site itself trivial, except I don't know either 
> of them and then I'm stuck maintaining something in a language and 
> framework I have no interest in and don't understand how to deploy or 
> maintain. Or I could do it in Clojure which means that I understand the 
> libraries, frameworks, deployment and monitoring inside and out, except I 
> now have to implement a shopping cart and integrations with payments 
> gateways etc. Neither of these are great options for me.
>
> On 3 May 2015 at 16:24, Sean Corfield > 
> wrote:
>
>> On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg > > wrote:
>>
>>> Clojure is great for creating new, disruptive web models, but what's the 
>>> easiest path to creating something that can be done trivially with, say, 
>>> Drupal or Django?
>>>
>>
>> The question tho' is why you'd want to use Clojure for something that is 
>> already trivially solved with free packaged software for widely used 
>> scripting languages where cheap, plentiful developers are falling over 
>> themselves to help... :)
>>
>> Clojure doesn't have to be the solution for every problem. It certainly 
>> doesn't need to be the solution for low-value problems...
>> -- 
>> 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)
>>  
>> -- 
>> 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.

Re: Clojure needs a web framework with more momentum

[Dmitri]

One way I could see this working is having a more opinionated profile like 
+site or something that sets up an app with authentication, logins, a 
default model and so on. I would definitely support merging the efforts on 
this front. Ping me by email, and we can try figure out the details. :)

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 
>>>
>>> LuminusClojure28678 
>>> CaribouClojure 2275 
>>>
>>> BeegoGolang991522 
>>>
>>> PhoenixElixir  1241949 
>>>
>>> YesodHaskell   1303722 
>>>
>>> LaravelPHP2684421 
>>>
>>> PlayScala   4176085 
>>>
>>> SymfonyPHP113020914 
>>>
>>> RailsRuby   269151000 
>>>
>>>
>>> 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

Re: Clojure needs a web framework with more momentum

[Dmitri]

Luminus uses a minimal amount of generated code. It completely embraces the 
composable library approach. The difference from rolling your own each time 
is that it provides some structure and it's a curated set of libraries that 
are known to work well together.

On Tuesday, May 5, 2015 at 3:46:09 AM UTC-4, Dan Kersten wrote:
>
>
>
> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>> 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?
>>
>
> This is the reason I don't use Luminus or Modularity or others that rely 
> heavily on leiningen template-based codegen. Its very difficult to upgrade 
> the generated code, especially if you've had to add to or modify it. 
>
> I'm experimenting with an approach that would generate only the 
> project.clj file and directory structure (putting everything else into 
> libraries), but don't yet have anything to release (my code is currently 
> very targeted at my own use case, but in time I'd like to generalize it a 
> bit and let others at it).
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[Thorsten Wilms]

On 05.05.2015 03:02, Daniel Compton wrote:

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.


I think the ideal* would be a single starting point 
(website/brand/platform), with a mix of literate programming and library 
store. It could be a bit like a checklist of general concerns like 
routing, authentication and so on, listing and comparing mature 
libraries for each of those.


If a literate program explains what is to be achieved and how you go 
about it in code, this would extend that concept to library selection.


This would be the place to find out if seemingly competing libraries 
happen to have different strengths. Where library authors explain their 
choices and may find ways to join forces. Where it will be made clear, 
if a library does happen to be the best in its field or simply stands 
alone. Yes, of course I do see problems around reaching consensus ;)


The development branch of this resource should be a gathering point for 
the community to define current best practices.


* ideal for newcomers to learn how to go about web development, where 
covering standards like blogs and stores are not only matters for 
themselves, but serve as basis for free-form exploration. Ideal for 
seasoned developers for collaborating on furthering the whole field.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

--
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.

Re: Clojure needs a web framework with more momentum

[Daniel Kersten]

On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
> 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?
>

This is the reason I don't use Luminus or Modularity or others that rely
heavily on leiningen template-based codegen. Its very difficult to upgrade
the generated code, especially if you've had to add to or modify it.

I'm experimenting with an approach that would generate only the project.clj
file and directory structure (putting everything else into libraries), but
don't yet have anything to release (my code is currently very targeted at
my own use case, but in time I'd like to generalize it a bit and let others
at it).

-- 
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.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

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 
>>
>> LuminusClojure28678 
>> CaribouClojure 2275 
>>
>> BeegoGolang991522 
>>
>> PhoenixElixir  1241949 
>>
>> YesodHaskell   1303722 
>>
>> LaravelPHP2684421 
>>
>> PlayScala   4176085 
>>
>> SymfonyPHP113020914 
>>
>> RailsRuby   269151000 
>>
>>
>> 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://gr

Re: Clojure needs a web framework with more momentum

[blake]

>>Do the advantages you've pointed out apply to teamwork, though? That's
supposed to be where frameworks make life easier.

Frameworks make life easier for teamwork, sure—as long as everyone knows
the framework and has the same (presumably correct =P) understanding of it.
In practice here, everyone's understanding of rails was slightly different,
and we had to establish a whole lot of in-house convention, and the churn
on that was really painful.

Like, we switched to using mountable engines. Cool idea, but it was ugly,
and we ended up with pieces that were mountable and pieces that were not,
and it was fragile and hard to deploy. We've had that problem across many
iterations of Rails. (And, some teams having adopted Angular, it looks like
there's going to be some issue there since the next version of Angular is
supposed to be backward incompatible.)

I just don't see that happening with the Clojure apps. I've let a complete
neophyte add stuff to my main web app, and he's gotten useful work done.
(He made some goofs because he didn't get the "stateless" thing, but that's
about it.) I had a graphic designer come in and fix the Hiccup to make it
more professional looking. She didn't have a hitch.

Separation of concerns, simplicity, clarity...I guess they do have some
value.


On Mon, May 4, 2015 at 3:47 PM, gvim  wrote:

> On 04/05/2015 23:17, blake wrote:
>
>> I went from Ruby to Clojure in short-order and while I struggled
>> mightily with the functional aspect (after assiduously avoiding those
>> concepts for years), I much prefer every aspect of Clojure web
>> programming to Rails.
>>
>> The bible of rails programming is the Hartl book. In the edition I read,
>> before you got to any actual programming, you were introduced to
>> 14—fourteen! I counted!—different domains, including things like RSpec
>> and Cucumber. And it was all treated with this, "Well, you can figure
>> out what this all does because, hey, it looks just like English"
>> attitude, with a patina of "you don't need to know what's going on under
>> the covers".
>>
>> The advantage of having an opinionated framework is that it saves one
>> the effort of having to make up one's own mind. This means you're
>> trusting someone with literally no understanding of your problem domain
>> to make up your mind for you. It's sort of amazing that this works at
>> all, and that there aren't =more= vulnerabilities turning up like the
>> Rails XML hack.
>> ​
>> This made me really uncomfortable with Rails.
>>
>> My current Clojure web app is more sophisticated than anything I did
>> with Rails, though my Rails apps doubtless carried far more untapped
>> potential. But I know just about exactly what it does. I know because I
>> added each piece of middleware as I needed it, and this allowed me to
>> understand what going on. I needed access to Mongo and MS-SQL, so I
>> added those. I needed a front-end so I started with Hiccup, which is
>> "obvious" (and remarkably similar to Smalltalk's Seaside, which I've
>> used), and then added in some Javascript.
>>
>> I'll turn the Javascript into Clojurescript, but I felt that was too
>> much to absorb at once. And unlike Rails, I didn't need to absorb every
>> hot library du jour to get going. (And damned if in Rails, each tutorial
>> has a different idea of which libraries are essential.)
>>
>> Then I added authentication, and threading (which was ridiculously
>> easy), and so on. Each piece as needed, with an understanding of what
>> was going on. Now, I don't get ALL of it. But I know where my weaknesses
>> are. I have, now, an opinionated framework, but it's made of =my=
>> opinions. And I made those opinions by looking at what the libraries I'm
>> using did, which is way simpler in a shallow functional world than in an
>> object-drill-down world.
>>
>> In Rails, you don't know what you don't know.
>>
>>
> Do the advantages you've pointed out apply to teamwork, though? That's
> supposed to be where frameworks make life easier.
>
> 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.
>

-- 
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 unsubscri

Re: Clojure needs a web framework with more momentum

[Daniel Compton]

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
 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"  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, driv

Re: Clojure needs a web framework with more momentum

[larry google groups]

> 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" > 
> 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  > 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...@googlegroup

Re: Clojure needs a web framework with more momentum

[larry google groups]

> I read several comments about how easy it is to upgrade Rails. 
> Either things have been improving at the speed of light or I am 
> a complete idiot. My last upgrades from 2.x to 2.y have been 
> nightmares, dependency hell multiplied by an unknown factor 
> above 100... 


I strongly agree. I think of upgrading as the major pain point in the Rail 
eco-system. It has gotten better, but as recently as last week I was trying 
to upgrade a gem and ran into version conflicts. Search StackOverflow for 
Bundler error messages and you realize this is still a huge point of pain 
-- there are thousands of people struggling to deal with cryptic version 
conflict errors, and unable to get Bundler to resolve the problem for them. 





On Monday, May 4, 2015 at 10:42:15 AM UTC-4, Luc wrote:
>
> +1 
>
> This exactly the kind of exercises that needs to done as part of a 
> product design. New potential needs have to be foreseen at this 
> stage, not 18 months after a first release. 
>
> This is why I hate frameworks, they assume some of these 
> decisions and it's not always stated clearly. Someone has to 
> discover the sad effects and if you are not lucky, you're the 'king of the 
> farce'. 
>
> They lure you in a trap pampered with 'easy', 'obvious'... Until 
> you have a need that cannot be met along the way. 
>
> I read several comments about how easy it is to upgrade Rails. 
>
> Either things have been improving at the speed of light or I am 
> a complete idiot. My last upgrades from 2.x to 2.y have been 
> nightmares, dependency hell multiplied by an unknown factor 
> above 100... 
>
> I would rather deal with an explicit dependency graph than 
> work with magic stuff that eventually breaks in obscure ways 
> after an upgrade and requires mods in remote places in foreign code. 
>
> Luc P. 
>
> > 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  > 
> > 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 

Re: Clojure needs a web framework with more momentum

[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 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> 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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> 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.

Composable libraries instead of plugins avoids the biggest problems that 
Rails faces. In my experience, the toughest issue with upgrading old Rails 
apps is upgrading the plugins. I recall last year I was given the task of 
upgrading an old install of Redmine. I struggled with it for 2 days -- the 
app itself was easy to upgrade, but all the old plugins broke. I offered to 
fix them all by hand, but I estimated that would take me a week or two, at 
which point management decided that the problem was no longer worth it, so 
they decided to live with the old version of Redmine until such time as the 
whole thing could be replaced entirely. 

The world of Rails, and the world of Ruby, has evolved, and nowadays 
plugins are just gems that follow some conventions. Which is to  say, Rails 
has been moving in the direction that Clojure is already in. But Clojure is 
out in front on this issue. In the Clojure eco-system, if you use the word 
"plugin" you are probably talking about lein, or maybe Stuart Sierra's 
Component system. The conversation is happening at higher level than in the 
Ruby world. 

I think it is a sign of failure when you have to do what we did with 
Redmine -- give up any hope of upgrading it and instead wait till you can 
replace it entirely. At least so far, I have not see than come up in any 
Clojure project I've worked on, though I acknowledge Clojure projects don't 
have the age of old Rails projects. 

If, 10 years from now, Clojure has the reputation that upgrading rarely 
hits the "we must replace this entirely" problem, then I think we can say, 
in absolute terms, that Clojure is superior than Ruby. And this would also 
be true in the specific category of "web frameworks". 







On Monday, May 4, 2015 at 8:09:35 AM UTC-4, Sean Johnson 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 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.

Re: Clojure needs a web framework with more momentum

[Christopher Small]

And Flask was inspired by Sinatra, IIRC. Also, the rails folks thought that
Sinatra would be a joke and no one would take it seriously. They were
surprised. Ditto with Merb, which was a similarly more modular, and became
so popular that rails actually merged with it.

Clojure's Noir used to be similarly minimalistic, but it became deprecated
and split up into peices which live on today as lib-noir, and can be used
with (e.g.) Luminus.

Chris


On Mon, May 4, 2015 at 5:25 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

> > Very interesting discussion going on here. As a beginner, what I'd like
> to see is not something
> > like Django or Rails, but something like Flask.
>
> Flask started off as a sort of joke -- a few Python programmers,
> responding to criticism of bloat in Django, said it should be possible to
> create a single file web app. And they succeeded.
>
> You can certainly create a single-file web app in Clojure, and I think
> there are several examples on the web, that are very much comparable to the
> simple examples given for Flask. But, again, I agree with those above who
> suggested that maybe this should be offered as a lein template.
>
>
>
>
> On Monday, May 4, 2015 at 6:06:46 AM UTC-4, John Louis Del Rosario wrote:
>>
>> Very interesting discussion going on here. As a beginner, what I'd like
>> to see is not something like Django or Rails, but something like Flask.
>> Where someone can just (require 'someframework) and it works. Maybe it
>> could have thin wrappers over compojure, etc., since it will need to be
>> opinionated anyway. It's still very simple, but takes away a lot of the
>> guesswork and the distributed docs across multiple projects problem.
>>
>> Additional features can be done as libraries then, but specific for
>> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>>
>> Just my 2c.
>>
>> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>>
>>> I recently did some research into web frameworks on Github. Here's what
>>> I found:
>>>
>>>
>>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>>
>>> LuminusClojure28678
>>> CaribouClojure 2275
>>>
>>> BeegoGolang991522
>>>
>>> PhoenixElixir  1241949
>>>
>>> YesodHaskell   1303722
>>>
>>> LaravelPHP2684421
>>>
>>> PlayScala   4176085
>>>
>>> SymfonyPHP113020914
>>>
>>> RailsRuby   269151000
>>>
>>>
>>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Re: Clojure needs a web framework with more momentum

[Luc Préfontaine]

I certainly have some personality disorders, but I am not bipolar :)
What am I ? Help ! :)

Luc P.


> > And never has this author proven that programmers with bipolar 
> personality are 
> > programming more LISP then other languages. 
> 
> It's a metaphor. The author is not actually diagnosing Lisp programmers 
> with bipolar disorder. The metaphor offers an image of a particular kind of 
> student who starts stuff but doesn't finish stuff. 
> 
> 
> 
> 
> On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote:
> >
> > No, it isn't. And never has this author proven that programmers with 
> > bipolar personality are programming more LISP then other languages. 
> >
> > Many larger libraries in the Clojure community are well documented and 
> > "finished-off properly".
> >
> > Web frameworks have been tried and not been picked up. Users have chosen 
> > the modular compose it yourself approach. Framework authors have simply 
> > stopped maintaining what nobody wanted anyway or split them up into smaller 
> > pieces. 
> >
> >
> > On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote:
> >>
> >>
> >> > The web development industry as reflected in job postings at 
> >> > Indeed.co.uk is still dominated by the likes of Rails, Django, 
> >> Laravel, 
> >> > Zend, Symfony & Spring so I'm not sure how you've concluded that 
> >> there's 
> >> > been a 15-year trend towards composition. 
> >>
> >> That is a good point, though I would also point out that, according to 
> >> Indeed.com, the use of Clojure is also growing. To me, what's important is 
> >> the growth of the Clojure community, rather than the growth of some 
> >> sub-community focused on a particular niche. 
> >>
> >> However, I acknowledge you may have a point about the failure of any of 
> >> the Clojure frameworks to take off. It's possible this is another 
> >> manifestation of the Bipolar Programmer problem: 
> >>
> >> http://www.lambdassociates.org/blog/bipolar.htm
> >>
> >> "Brilliance and failure are so often mixed together and our initial 
> >> reaction is it shouldn't be.   But it happens and it happens a lot.  Why? 
> >> ...But brilliance is not enough.  You need application too, because the 
> >> material is harder at university.   So pretty soon our man is getting B+, 
> >> then Bs and then Cs for his assignments.   He experiences alternating 
> >> feelings of failure cutting through his usual self assurance.  He can 
> >> still 
> >> stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, 
> >> but what he hands in is not so great.
> >>
> >> ...So BBMs love Lisp.  And the stunning originality of Lisp is reflective 
> >> of the creativity of the BBM; so we have a long list of ideas that 
> >> originated with Lispers - garbage collection, list handling, personal 
> >> computing, windowing and areas in which Lisp people were amongst the 
> >> earliest pioneers.  So we would think, off the cuff, that Lisp should be 
> >> well established, the premiere programming language because hey - its 
> >> great 
> >> and we were the first guys to do this stuff.
> >>
> >> But it isn't and the reasons why not are not in the language, but in the 
> >> community itself, which contains not just the strengths but also the 
> >> weaknesses of the BBM.
> >>
> >> One of these is the inability to finish things off properly.  The phrase 
> >> 'throw-away design' is absolutely made for the BBM and it comes from the 
> >> Lisp community.   Lisp allows you to just chuck things off so easily, and 
> >> it is easy to take this for granted.  I saw this 10 years ago when looking 
> >> for a GUI to my Lisp (Garnet had just gone West then).  No problem, there 
> >> were 9 different offerings.  The trouble was that none of the 9 were 
> >> properly documented and none were bug free. Basically each person had 
> >> implemented his own solution and it worked for him so that was fine.   
> >> This 
> >> is a BBM attitude; it works for me and I understand it.   It is also the 
> >> product of not needing or wanting anybody else's help to do something."
> >>
> >>
> >>
> >>
> >>
> >> On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote:
> >>>
> >>> On 03/05/2015 14:39, larry google groups wrote: 
> >>> > The industry has been moving against frameworks for 15 years now. The 
> >>> > peak of the monolithic framework craze was Struts, back in 2000. After 
> >>> > that, people started craving something less bloated. That's why the 
> >>> > whole industry was so excited when Rails emerged in 2004. Bruce Eckel 
> >>> > summed up the sudden change of mood in his essay "The departure of the 
> >>> > hyper-enthusiasts": 
> >>> > 
> >>> > http://www.artima.com/weblogs/viewpost.jsp?thread=141312 
> >>> > 
> >>> > But after awhile, people began to feel that even Rails was bloated, 
> >>> > which lead to the emergence of micro-frameworks like Sinatra. 
> >>> > 
> >>> > And then, continuing with the trend, we've seen the emergence of 
> >>> > eco-sy

Re: Clojure needs a web framework with more momentum

[larry google groups]

> Very interesting discussion going on here. As a beginner, what I'd like 
to see is not something 
> like Django or Rails, but something like Flask.

Flask started off as a sort of joke -- a few Python programmers, responding 
to criticism of bloat in Django, said it should be possible to create a 
single file web app. And they succeeded. 

You can certainly create a single-file web app in Clojure, and I think 
there are several examples on the web, that are very much comparable to the 
simple examples given for Flask. But, again, I agree with those above who 
suggested that maybe this should be offered as a lein template. 




On Monday, May 4, 2015 at 6:06:46 AM UTC-4, John Louis Del Rosario wrote:
>
> Very interesting discussion going on here. As a beginner, what I'd like to 
> see is not something like Django or Rails, but something like Flask.
> Where someone can just (require 'someframework) and it works. Maybe it 
> could have thin wrappers over compojure, etc., since it will need to be 
> opinionated anyway. It's still very simple, but takes away a lot of the 
> guesswork and the distributed docs across multiple projects problem.
>
> Additional features can be done as libraries then, but specific for 
> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>
> Just my 2c.
>
> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what 
>> I found: 
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>>
>> LuminusClojure28678 
>> CaribouClojure 2275 
>>
>> BeegoGolang991522 
>>
>> PhoenixElixir  1241949 
>>
>> YesodHaskell   1303722 
>>
>> LaravelPHP2684421 
>>
>> PlayScala   4176085 
>>
>> SymfonyPHP113020914 
>>
>> RailsRuby   269151000 
>>
>>
>> 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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> Someone earlier in the thread wrote about how Ruby was the abstraction in 
contrast to PHP where libraries 
> were tied to a framework. I've never worked with Rails seriously, but I 
find it hard to believe that libraries 
> such as shopping carts intended for Rails will work out of the box with 
some other framework - is this the
> case? The ones I looked at (admittedly briefly and some time ago) were 
all Rails-specific.

I made that comment earlier. I am curious what gem is specific to Rails? 
Maybe something specific to RailTies? I am imagine you can find a few if 
you try, but I think they are rare. Stuff like ActiveRecord is not specific 
to Rails -- you can use ActiveRecord with Sinatra, or any other Ruby web 
framework. The same goes for Device (authentication) CanCan (authorization) 
and any of the HTML template languages that you can think of (too many to 
list). Middleware is handled by Rack. So you've got an ORM and HTML 
templates and authentication and authorization and all of that is general 
to Ruby, not to Rails. That is in contrast to PHP where the plugins are 
specific to particular frameworks. 

To my way of thinking, Ruby is better than PHP exactly because it allows a 
higher level of composability  and Clojure is better than Ruby because it 
allows a higher level of composability than Ruby. 



On Monday, May 4, 2015 at 5:47:35 AM UTC-4, Colin Fleming wrote:
>
> Note that the shopping cart is just one specific example from my current 
> itch that needs scratching - it's a very common one, but I'm sure there are 
> plenty more reusable component types that people expect these days.
>
> One problem I see with the composition approach (which I'm a huge fan of 
> in general) is the multiplicative complexity. Something like a shopping 
> cart needs access to the persistence layer. In Rails, this is very easy - 
> you use ActiveRecord and you're done because everything else uses 
> ActiveRecord too. However in the Clojure world we have N persistence 
> libraries implementing M persistence strategies - I've never tried to make 
> a reusable component that sits in the "middle" of the stack (i.e. not 
> something that's relatively trivial to make dependency-free like logging), 
> but I can imagine that it's very difficult. And of course, persistence is 
> just one aspect, there must be many more like authentication and so on. A 
> big part of the reason for Ring's success is that it's the only game in 
> town - I'm sure we wouldn't have so much great functionality built on top 
> of it if we had 4 incompatible options to choose from.
>
> Someone earlier in the thread wrote about how Ruby was the abstraction in 
> contrast to PHP where libraries were tied to a framework. I've never worked 
> with Rails seriously, but I find it hard to believe that libraries such as 
> shopping carts intended for Rails will work out of the box with some other 
> framework - is this the case? The ones I looked at (admittedly briefly and 
> some time ago) were all Rails-specific.
>
> On 4 May 2015 at 20:41, Sven Richter > 
> wrote:
>
>> So, what I gather from this discussion are the following points. Clojure 
>> "needs" a "webframework" that is
>>
>> - fully documented
>> - easy for beginners to use
>> - opinionated about the libraries
>> - structured
>> - composable
>> - has something nice like django's admin backend
>> - a vibrant community support
>> - a shopping card (whereas I would see that fit into an external library)
>>
>> I agree that we have almost everything we need in the form of single 
>> libraries. And I think a mix of leiningen templates and plugins is the way 
>> to go here.
>> The reason for the last statement is my experience with django. The admin 
>> UI is awesome and it fullfills 95% of your needs, but for the rest of it to 
>> make it work I had to start hacking my local django source, which is PITA 
>> obv.
>>
>> I would refrain from doing some magic that only works in a specific 
>> context, but instead just generate code that is put into a fixed structure 
>> and works. The advantage is, one can change the code all the time if one 
>> needs to.
>>
>> 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.
>>
>> I am open for everything in that area, as long as it stays in the limits 
>> I stated above, so, if someone wants to join, he is welcome.
>>
>> I would also go the other way around and put efforts into someone elses 
>> project, if that makes sense.
>>
>> Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler:
>>
>>> On Sat, May 2, 2015 at 11:12 PM, Sven Richter  
>>> wrote:
>>>
 Reading through all the discussion I don't get which features you are 
 actually missing. I love luminus and did a lot with it, however, for me it 
 was missing some standard stuff, that's why I put together closp, which is 
 just another leinin

Re: Clojure needs a web framework with more momentum

[larry google groups]

> While I agree that g vim's metrics aren't terribly meaningful, the 
conclusion he's arriving at is an important one. 

I think g vim's metrics have some impact with management. Certainly, its 
worth talking about. A few months ago I was talking to the woman at the New 
York Times who overseas the NYT store, and they had decided to go with PHP 
because it had the Magento shopping cart. Personally, I think Magento is an 
abomination, but Clojure would have been a tough sell there since it has no 
shopping cart app on Github. 





On Sunday, May 3, 2015 at 8:03:43 PM UTC-4, James Reeves wrote:
>
> On 4 May 2015 at 00:51, Jason Whitlark > 
> wrote:
>>
>> While I agree that g vim's metrics aren't terribly meaningful, the 
>> conclusion he's arriving at is an important one.  I've heavily used Clojure 
>> in production for years, and there have been a number of times where having 
>> to hand assemble everything cost lots of support from other engineers.  
>> Luminus is an improvement, but doesn't always generate correct code for 
>> specific sets of options, and is tricky to extend.
>>
>
> I don't disagree. Improving code generation was my motivation for writing 
> lein-generate, and my partial motivation for cljfmt.
>
> - James
>

-- 
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.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> And never has this author proven that programmers with bipolar 
personality are 
> programming more LISP then other languages. 

It's a metaphor. The author is not actually diagnosing Lisp programmers 
with bipolar disorder. The metaphor offers an image of a particular kind of 
student who starts stuff but doesn't finish stuff. 




On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote:
>
> No, it isn't. And never has this author proven that programmers with 
> bipolar personality are programming more LISP then other languages. 
>
> Many larger libraries in the Clojure community are well documented and 
> "finished-off properly".
>
> Web frameworks have been tried and not been picked up. Users have chosen 
> the modular compose it yourself approach. Framework authors have simply 
> stopped maintaining what nobody wanted anyway or split them up into smaller 
> pieces. 
>
>
> On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote:
>>
>>
>> > The web development industry as reflected in job postings at 
>> > Indeed.co.uk is still dominated by the likes of Rails, Django, 
>> Laravel, 
>> > Zend, Symfony & Spring so I'm not sure how you've concluded that 
>> there's 
>> > been a 15-year trend towards composition. 
>>
>> That is a good point, though I would also point out that, according to 
>> Indeed.com, the use of Clojure is also growing. To me, what's important is 
>> the growth of the Clojure community, rather than the growth of some 
>> sub-community focused on a particular niche. 
>>
>> However, I acknowledge you may have a point about the failure of any of 
>> the Clojure frameworks to take off. It's possible this is another 
>> manifestation of the Bipolar Programmer problem: 
>>
>> http://www.lambdassociates.org/blog/bipolar.htm
>>
>> "Brilliance and failure are so often mixed together and our initial 
>> reaction is it shouldn't be.   But it happens and it happens a lot.  Why? 
>> ...But brilliance is not enough.  You need application too, because the 
>> material is harder at university.   So pretty soon our man is getting B+, 
>> then Bs and then Cs for his assignments.   He experiences alternating 
>> feelings of failure cutting through his usual self assurance.  He can still 
>> stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, 
>> but what he hands in is not so great.
>>
>> ...So BBMs love Lisp.  And the stunning originality of Lisp is reflective 
>> of the creativity of the BBM; so we have a long list of ideas that 
>> originated with Lispers - garbage collection, list handling, personal 
>> computing, windowing and areas in which Lisp people were amongst the 
>> earliest pioneers.  So we would think, off the cuff, that Lisp should be 
>> well established, the premiere programming language because hey - its great 
>> and we were the first guys to do this stuff.
>>
>> But it isn't and the reasons why not are not in the language, but in the 
>> community itself, which contains not just the strengths but also the 
>> weaknesses of the BBM.
>>
>> One of these is the inability to finish things off properly.  The phrase 
>> 'throw-away design' is absolutely made for the BBM and it comes from the 
>> Lisp community.   Lisp allows you to just chuck things off so easily, and 
>> it is easy to take this for granted.  I saw this 10 years ago when looking 
>> for a GUI to my Lisp (Garnet had just gone West then).  No problem, there 
>> were 9 different offerings.  The trouble was that none of the 9 were 
>> properly documented and none were bug free. Basically each person had 
>> implemented his own solution and it worked for him so that was fine.   This 
>> is a BBM attitude; it works for me and I understand it.   It is also the 
>> product of not needing or wanting anybody else's help to do something."
>>
>>
>>
>>
>>
>> On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote:
>>>
>>> On 03/05/2015 14:39, larry google groups wrote: 
>>> > The industry has been moving against frameworks for 15 years now. The 
>>> > peak of the monolithic framework craze was Struts, back in 2000. After 
>>> > that, people started craving something less bloated. That's why the 
>>> > whole industry was so excited when Rails emerged in 2004. Bruce Eckel 
>>> > summed up the sudden change of mood in his essay "The departure of the 
>>> > hyper-enthusiasts": 
>>> > 
>>> > http://www.artima.com/weblogs/viewpost.jsp?thread=141312 
>>> > 
>>> > But after awhile, people began to feel that even Rails was bloated, 
>>> > which lead to the emergence of micro-frameworks like Sinatra. 
>>> > 
>>> > And then, continuing with the trend, we've seen the emergence of 
>>> > eco-systems, such as Clojure, that allow the trend to go further: 
>>> > Clojure supports such high levels composition that frameworks are no 
>>> > longer needed. And this is the direction the industry has been moving 
>>> > for the last 15 years. Clojure is simply out in front. Most languages 
>>> > don't allow this lev

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

> Yes, Play has overtaken Lift, not because it is necessarily better, but 
> because TypeSafe are pouring marketing dollars into it, as part of their 
> drive to encourage Enterprise uptake of Scala. They have a vested interest in 
> Play being very successful as it will drive more business for them.


of course, there are folks who say Typesafe wears no clothes.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Kyle Cordes]

 
On May 4, 2015 at 3:51:23 PM, Josh Kamau 
(joshnet2...@gmail.com(mailto:joshnet2...@gmail.com)) wrote:
> Another challenge is: There are alot of abandoned libraries and few reach 
> 1.0. That makes selecting the libraries to compose abit difficult.  


I think this is a key source of trouble. There are so many things to choose 
from, yet so few of them are “done”.

I’ve thought about why this might be. Here is my theory, it is an accidental 
result of reasonable people doing reasonable things. I think the typical 
software developer contributing to open source is a reasonably nice person; 
unpleasant people generally don’t do a bunch of hard work and give away the 
results of their work. But being inclined to be nice can easily lead to this 
endless series of new incomplete projects.

The path is by this dynamic. Imagine friendly developer X wants to solve a 
problem. They look around and find various incomplete solutions to that 
problem. Now they have a choice: do I contribute to one of those existing 
solutions, or do I start my own? Aside from the natural tendency of many of us 
to want to solve problems our own way, I believe there is a social reason also 
pointing people in this direction. There are too many obvious downsides to 
contributing to someone’s existing, partly complete solution:

* Looking at the incomplete project, you wonder, what is left to be done? But 
the person who didn’t have time to finish it, probably also didn’t have time to 
write much about what was still to be done, nor to carefully maintain a list of 
open issues.

* Perhaps you go farther, and make a bunch of local edits. Do you offer these 
is a pull request? Perhaps, but a pull request whose contents are “replace a 
bunch of stuff in this project with my new stuff instead” could certainly be 
seen as not very nice, so perhaps better to just keep quiet about such a 
branch, and not push it, Not submit a pull request.

* Perhaps you want to just urge the existing project in a good direction. You 
find that the issue tracker has a little activity, and the issues already there 
aren’t getting much attention. Is it rational to spend time adding another? 
Probably not. Is it nice, and polite, to add more issues asking for activity 
from someone who obviously has no time to give it? No it is not, so perhaps 
better to just move on to the next project.

* Perhaps you have rather a lot of time, enough time to fork the project and 
drive it to completion. Do you fork? While there are several reasons not to 
fork. Firstly, it could be perceived as unfriendly. Secondly, even if your fork 
is spectacular, on the website where much of the open source ecosystem lives 
(GitHub), forks more or less perpetually appear a second class citizens. There 
is no good way, even if you look at the graph showing off forks, to figure out 
if the community has moved on to some particular fork. The starting point 
project seems forever the main one, even if it is abandoned. So perhaps it is 
better to not forget all.

* Now we’re left with the default position, just starting a fresh new project 
to solve the same problem. But quite often, the hypothetical friendly developer 
in this position does not have enough time to drive their fresh new solution to 
completion either.

Net result: over time we accumulate more and more projects, solving overlapping 
problems, a great many of them never getting close to 1.0.

While this all sounds pretty negative, but I think the factors here are 
actually overwhelmed by the large number of really smart people contributing 
stuff out there. I can mostly find that I look around and am able to solve 
whatever problems I have, often building on the good work of others. But I also 
find that I often pass on an opportunity to push some project closer to 
completion, for the reasons above.




--  
Kyle Cordes
http://kylecordes.com  


-- 
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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 4:10 PM, gvim  wrote:
> I've been pretty impressed with Scala's main framework, Play 2. There seems 
> to be a lot of momentum behind their Typesafe Reactive Platform and, like 
> Rails, plenty of resources to get new users up to speed.

Yes, Play has overtaken Lift, not because it is necessarily better, but because 
TypeSafe are pouring marketing dollars into it, as part of their drive to 
encourage Enterprise uptake of Scala. They have a vested interest in Play being 
very successful as it will drive more business for them.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Clojure needs a web framework with more momentum

[gvim]

On 05/05/2015 00:03, Raoul Duke wrote:

Can you elaborate? Lift got it right or was a disaster?


oh! good question, sorry :-)

i believe it got it far more right than wrong.



I've been pretty impressed with Scala's main framework, Play 2. There 
seems to be a lot of momentum behind their Typesafe Reactive Platform 
and, like Rails, plenty of resources to get new users up to speed.


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.

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

> Can you elaborate? Lift got it right or was a disaster?

oh! good question, sorry :-)

i believe it got it far more right than wrong.

-- 
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.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 23:49, Raoul Duke wrote:

vulnerabilities that would not exist using an integrated framework.


fwiw, web + security always makes me think of http://liftweb.net/



Can you elaborate? Lift got it right or was a disaster?

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.

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

>> vulnerabilities that would not exist using an integrated framework.

fwiw, web + security always makes me think of http://liftweb.net/

-- 
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.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 23:17, blake wrote:

I went from Ruby to Clojure in short-order and while I struggled
mightily with the functional aspect (after assiduously avoiding those
concepts for years), I much prefer every aspect of Clojure web
programming to Rails.

The bible of rails programming is the Hartl book. In the edition I read,
before you got to any actual programming, you were introduced to
14—fourteen! I counted!—different domains, including things like RSpec
and Cucumber. And it was all treated with this, "Well, you can figure
out what this all does because, hey, it looks just like English"
attitude, with a patina of "you don't need to know what's going on under
the covers".

The advantage of having an opinionated framework is that it saves one
the effort of having to make up one's own mind. This means you're
trusting someone with literally no understanding of your problem domain
to make up your mind for you. It's sort of amazing that this works at
all, and that there aren't =more= vulnerabilities turning up like the
Rails XML hack.
​
This made me really uncomfortable with Rails.

My current Clojure web app is more sophisticated than anything I did
with Rails, though my Rails apps doubtless carried far more untapped
potential. But I know just about exactly what it does. I know because I
added each piece of middleware as I needed it, and this allowed me to
understand what going on. I needed access to Mongo and MS-SQL, so I
added those. I needed a front-end so I started with Hiccup, which is
"obvious" (and remarkably similar to Smalltalk's Seaside, which I've
used), and then added in some Javascript.

I'll turn the Javascript into Clojurescript, but I felt that was too
much to absorb at once. And unlike Rails, I didn't need to absorb every
hot library du jour to get going. (And damned if in Rails, each tutorial
has a different idea of which libraries are essential.)

Then I added authentication, and threading (which was ridiculously
easy), and so on. Each piece as needed, with an understanding of what
was going on. Now, I don't get ALL of it. But I know where my weaknesses
are. I have, now, an opinionated framework, but it's made of =my=
opinions. And I made those opinions by looking at what the libraries I'm
using did, which is way simpler in a shallow functional world than in an
object-drill-down world.

In Rails, you don't know what you don't know.



Do the advantages you've pointed out apply to teamwork, though? That's 
supposed to be where frameworks make life easier.


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.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 21:48, Robert Levy wrote:

Another thing worth mentioning that I don't see already mentioned is the
case for a web framework from a security perspective:
https://www.youtube.com/watch?v=CBL59w7fXw4 Having a lot of different
pieces without standard ways of putting them together can introduce
vulnerabilities that would not exist using an integrated framework.



See the first message in the thread. That was one of my concerns.

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.

Re: Clojure needs a web framework with more momentum

[blake]

I went from Ruby to Clojure in short-order and while I struggled mightily
with the functional aspect (after assiduously avoiding those concepts for
years), I much prefer every aspect of Clojure web programming to Rails.

The bible of rails programming is the Hartl book. In the edition I read,
before you got to any actual programming, you were introduced to
14—fourteen! I counted!—different domains, including things like RSpec and
Cucumber. And it was all treated with this, "Well, you can figure out what
this all does because, hey, it looks just like English" attitude, with a
patina of "you don't need to know what's going on under the covers".

The advantage of having an opinionated framework is that it saves one the
effort of having to make up one's own mind. This means you're trusting
someone with literally no understanding of your problem domain to make up
your mind for you. It's sort of amazing that this works at all, and that
there aren't =more= vulnerabilities turning up like the Rails XML hack.
​
This made me really uncomfortable with Rails.

My current Clojure web app is more sophisticated than anything I did with
Rails, though my Rails apps doubtless carried far more untapped potential.
But I know just about exactly what it does. I know because I added each
piece of middleware as I needed it, and this allowed me to understand what
going on. I needed access to Mongo and MS-SQL, so I added those. I needed a
front-end so I started with Hiccup, which is "obvious" (and remarkably
similar to Smalltalk's Seaside, which I've used), and then added in some
Javascript.

I'll turn the Javascript into Clojurescript, but I felt that was too much
to absorb at once. And unlike Rails, I didn't need to absorb every hot
library du jour to get going. (And damned if in Rails, each tutorial has a
different idea of which libraries are essential.)

Then I added authentication, and threading (which was ridiculously easy),
and so on. Each piece as needed, with an understanding of what was going
on. Now, I don't get ALL of it. But I know where my weaknesses are. I have,
now, an opinionated framework, but it's made of =my= opinions. And I made
those opinions by looking at what the libraries I'm using did, which is way
simpler in a shallow functional world than in an object-drill-down world.

In Rails, you don't know what you don't know.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

Another challenge is: There are alot of abandoned libraries and few reach
1.0. That makes selecting the libraries to compose abit difficult.

On Mon, May 4, 2015 at 9:59 PM, Gregg Reynolds  wrote:

>
> On May 4, 2015 7:16 AM, "Eric MacAdie"  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  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 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.
>
> --
> 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 unsu

Re: Clojure needs a web framework with more momentum

[Robert Levy]

I tend to agree with this Gregg.  Either it's a solution in search of a
need, or it's a legitimate need but no one has produced something
compelling enough that a critical mass (or even a small contingent) has
picked up on and said "yes, this feels like a significant improvement over à
la carte pieces".

Another thing worth mentioning that I don't see already mentioned is the
case for a web framework from a security perspective:
https://www.youtube.com/watch?v=CBL59w7fXw4 Having a lot of different
pieces without standard ways of putting them together can introduce
vulnerabilities that would not exist using an integrated framework.

On Mon, May 4, 2015 at 11:59 AM, Gregg Reynolds  wrote:

>
> On May 4, 2015 7:16 AM, "Eric MacAdie"  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  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 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.
>
> --
> 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 

Re: Clojure needs a web framework with more momentum

[Gregg Reynolds]

On May 4, 2015 7:16 AM, "Eric MacAdie"  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  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 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.

-- 
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.

Re: Clojure needs a web framework with more momentum

[Fluid Dynamics]

On Monday, May 4, 2015 at 1:53:30 PM UTC-4, Josh Kamau wrote:
>
> Thanks Sean. that makes sense.   I didnt want that map to be stored as one 
> cookie because it could potentially be big... (there is a 4kb limit per 
> cookie right?) . I will dig into it and check. If that works for me, then 
> all i need is compojure, ring and the awesome ring-defaults middleware.  No 
> need for a monolithic framework.
>

Seems you can solve cookie size issues with a database table with two 
columns, a UUID (PK) and a BLOB with the "real cookie data", and setting a 
client side cookie with the UUID. This may also have security advantages, 
if the user can also be an adversary and shouldn't be able to hand-modify 
some things in the "real cookie data". (E.g. multiplayer online game, don't 
store any data clientside that the client can (decrypt and) alter 
unilaterally where such a capability would enable some sort of cheating. 
Keep the data, or at least the decryption key, on the server.)

Note that some databases perform more poorly with UUID PKs than with 
autoincrement PKs; however, autoincrement PKs have a severe security 
problem in this context, in that a user can predict valid keys other than 
their own and doctor their cookie to potentially view another user's data. 
There have been a number of notorious breaches that resulted from using 
predictably sequential numbers in cookies, URL query parameters, and 
similar things without any further authentication than "client knew the 
number".

-- 
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.

Re: Clojure needs a web framework with more momentum

[Andrey Antukh]

Yes, without a database, serializing data using JWS or JWE...  I have done
similar thing with buddy-auth stateless backend. It not uses sessions but
the concept is the same.

Cheers.
Andrey

2015-05-04 20:17 GMT+02:00 Sean Corfield :

> On May 4, 2015, at 11:08 AM, Josh Kamau  wrote:
> > @Sean, i wanted totally stateless backend.
>
> Without a database? :)
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 11:08 AM, Josh Kamau  wrote:
> @Sean, i wanted totally stateless backend. 

Without a database? :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

@Sean, i wanted totally stateless backend.

On Mon, May 4, 2015 at 9:02 PM, Sean Corfield  wrote:

> On May 4, 2015, at 10:53 AM, Josh Kamau  wrote:
> > Thanks Sean. that makes sense.   I didnt want that map to be stored as
> one cookie because it could potentially be big... (there is a 4kb limit per
> cookie right?) . I will dig into it and check. If that works for me, then
> all i need is compojure, ring and the awesome ring-defaults middleware.  No
> need for a monolithic framework.
>
> Depends on session-store, I believe. If you use in-memory, only the
> session ID is a cookie, the rest is in memory. Or you could use a data
> store for a distributed app (and, again, only the session ID would be a
> cookie).
>
> Only if your session-store is cookie will everything be stored as a cookie.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 10:53 AM, Josh Kamau  wrote:
> Thanks Sean. that makes sense.   I didnt want that map to be stored as one 
> cookie because it could potentially be big... (there is a 4kb limit per 
> cookie right?) . I will dig into it and check. If that works for me, then all 
> i need is compojure, ring and the awesome ring-defaults middleware.  No need 
> for a monolithic framework.  

Depends on session-store, I believe. If you use in-memory, only the session ID 
is a cookie, the rest is in memory. Or you could use a data store for a 
distributed app (and, again, only the session ID would be a cookie).

Only if your session-store is cookie will everything be stored as a cookie.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

Thanks Sean. that makes sense.   I didnt want that map to be stored as one
cookie because it could potentially be big... (there is a 4kb limit per
cookie right?) . I will dig into it and check. If that works for me, then
all i need is compojure, ring and the awesome ring-defaults middleware.  No
need for a monolithic framework.

On Mon, May 4, 2015 at 8:49 PM, Sean Corfield  wrote:

> Not sure what you mean by "one flash value" — I’d expect you to have a map
> of "flash" scope data and that’s the way my FW/1 behaves: you assoc values
> into the "flash scope" and they’re restored on the next request.
>
> On May 4, 2015, at 8:39 AM, Josh Kamau  wrote:
> > I am currently trying to  "redirect-after-post" with validation errors.
> I have already cooked up my way of validating maps.  However, i cant find a
> straight forward way for pushing the errors in a 'flash' and then read them
> in my template (am currently using freemarker.). I have seen the flash
> middleware but it seems to set one flash value.  My solution so far has
> been to set cookies and expire them when i read.A framework would
> handle this common cases very easily Or am i missing something?
>
>
> --
> 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.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

Not sure what you mean by "one flash value" — I’d expect you to have a map of 
"flash" scope data and that’s the way my FW/1 behaves: you assoc values into 
the "flash scope" and they’re restored on the next request.

On May 4, 2015, at 8:39 AM, Josh Kamau  wrote:
> I am currently trying to  "redirect-after-post" with validation errors.  I 
> have already cooked up my way of validating maps.  However, i cant find a 
> straight forward way for pushing the errors in a 'flash' and then read them 
> in my template (am currently using freemarker.). I have seen the flash 
> middleware but it seems to set one flash value.  My solution so far has been 
> to set cookies and expire them when i read.A framework would handle this 
> common cases very easily Or am i missing something? 


-- 
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.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

I am currently trying to  "redirect-after-post" with validation errors.  I
have already cooked up my way of validating maps.  However, i cant find a
straight forward way for pushing the errors in a 'flash' and then read them
in my template (am currently using freemarker.). I have seen the flash
middleware but it seems to set one flash value.  My solution so far has
been to set cookies and expire them when i read.A framework would
handle this common cases very easily Or am i missing something?

Thanks.

On Mon, May 4, 2015 at 6:34 PM, Christopher Small 
wrote:

> Cheers, and thanks :-) It's free, so feel... free to use it :-)
>
> On Mon, May 4, 2015 at 8:28 AM, Marcus Blankenship 
> wrote:
>
>> Ok, honestly, this is super cool.  Well done!
>>
>> On May 4, 2015, at 8:19 AM, Christopher Small 
>> wrote:
>>
>> I've been enjoying this thread, but don't currently have the bandwidth to
>> read everyone's messages and figure out in my head what the distribution of
>> opinions is or who is on what side of this conversation.
>>
>> Fortunately, I built a tool for this! It's called pol.is, and it uses
>> real time data visualization and machine learning to help make sense of
>> large scale conversations. It falls somewhere between an open ended survey
>> and a comment thread. Instead of getting more difficult to grok with the
>> number of people comments, it gets EASIER, because there is more data with
>> which the ML & stats make magic.
>>
>> I started a conversation on the state of Web Development in Clojure:
>> https://pol.is/7scufp.
>>
>> You don't need to create an account to log in and participate, but if you
>> connect a social account (twitter, facebook), we can show your avatar and
>> name where you fall in the conversation, so you can see where everyone else
>> stands in relation to yourself.
>>
>> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
>>
>> Chris
>>
>>
>>
>> --
>> 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.
>>
>>
>> Best,
>> Marcus
>>
>> Marcus Blankenship
>> \\\ Technical Coach, Startup Advisor, Calvinist
>> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>>
>>  --
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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+uns

Re: Clojure needs a web framework with more momentum

[Christopher Small]

Cheers, and thanks :-) It's free, so feel... free to use it :-)

On Mon, May 4, 2015 at 8:28 AM, Marcus Blankenship 
wrote:

> Ok, honestly, this is super cool.  Well done!
>
> On May 4, 2015, at 8:19 AM, Christopher Small 
> wrote:
>
> I've been enjoying this thread, but don't currently have the bandwidth to
> read everyone's messages and figure out in my head what the distribution of
> opinions is or who is on what side of this conversation.
>
> Fortunately, I built a tool for this! It's called pol.is, and it uses
> real time data visualization and machine learning to help make sense of
> large scale conversations. It falls somewhere between an open ended survey
> and a comment thread. Instead of getting more difficult to grok with the
> number of people comments, it gets EASIER, because there is more data with
> which the ML & stats make magic.
>
> I started a conversation on the state of Web Development in Clojure:
> https://pol.is/7scufp.
>
> You don't need to create an account to log in and participate, but if you
> connect a social account (twitter, facebook), we can show your avatar and
> name where you fall in the conversation, so you can see where everyone else
> stands in relation to yourself.
>
> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
>
> Chris
>
>
>
> --
> 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.
>
>
> Best,
> Marcus
>
> Marcus Blankenship
> \\\ Technical Coach, Startup Advisor, Calvinist
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Re: Clojure needs a web framework with more momentum

[Marcus Blankenship]

Ok, honestly, this is super cool.  Well done!

On May 4, 2015, at 8:19 AM, Christopher Small  wrote:

> I've been enjoying this thread, but don't currently have the bandwidth to 
> read everyone's messages and figure out in my head what the distribution of 
> opinions is or who is on what side of this conversation.
> 
> Fortunately, I built a tool for this! It's called pol.is, and it uses real 
> time data visualization and machine learning to help make sense of large 
> scale conversations. It falls somewhere between an open ended survey and a 
> comment thread. Instead of getting more difficult to grok with the number of 
> people comments, it gets EASIER, because there is more data with which the ML 
> & stats make magic.
> 
> I started a conversation on the state of Web Development in Clojure: 
> https://pol.is/7scufp.
> 
> You don't need to create an account to log in and participate, but if you 
> connect a social account (twitter, facebook), we can show your avatar and 
> name where you fall in the conversation, so you can see where everyone else 
> stands in relation to yourself.
> 
> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
> 
> Chris
> 
> 
> 
> -- 
> 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.

Best,
Marcus

Marcus Blankenship
\\\ Technical Coach, Startup Advisor, Calvinist
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
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.

Re: Clojure needs a web framework with more momentum

[Christopher Small]

I've been enjoying this thread, but don't currently have the bandwidth to
read everyone's messages and figure out in my head what the distribution of
opinions is or who is on what side of this conversation.

Fortunately, I built a tool for this! It's called pol.is, and it uses real
time data visualization and machine learning to help make sense of large
scale conversations. It falls somewhere between an open ended survey and a
comment thread. Instead of getting more difficult to grok with the number
of people comments, it gets EASIER, because there is more data with which
the ML & stats make magic.

I started a conversation on the state of Web Development in Clojure:
https://pol.is/7scufp.

You don't need to create an account to log in and participate, but if you
connect a social account (twitter, facebook), we can show your avatar and
name where you fall in the conversation, so you can see where everyone else
stands in relation to yourself.

Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)

Chris

-- 
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.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

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  > 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

Re: Clojure needs a web framework with more momentum

[Luc Prefontaine]

+1

This exactly the kind of exercises that needs to done as part of a
product design. New potential needs have to be foreseen at this
stage, not 18 months after a first release.

This is why I hate frameworks, they assume some of these
decisions and it's not always stated clearly. Someone has to
discover the sad effects and if you are not lucky, you're the 'king of the
farce'.

They lure you in a trap pampered with 'easy', 'obvious'... Until
you have a need that cannot be met along the way.

I read several comments about how easy it is to upgrade Rails.

Either things have been improving at the speed of light or I am
a complete idiot. My last upgrades from 2.x to 2.y have been
nightmares, dependency hell multiplied by an unknown factor
above 100...

I would rather deal with an explicit dependency graph than
work with magic stuff that eventually breaks in obscure ways
after an upgrade and requires mods in remote places in foreign code.

Luc P.

> 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 
> 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 (t

Re: Clojure needs a web framework with more momentum

[Thiago Massa]

My 2 cents:

I don't think the biggest problem is that the community is fragmented as
there is many options to choose, but that the attitude towards newcomers is
bad.

Let's say that I was learning clojure about 2 years ago and when I asked
about which web framework should I use, people started raising stuff about
the implementation of those frameworks like pedestal have some very strange
concepts like this one:

https://github.com/pedestal/docs/blob/master/documentation/application-overview.md

So I was like: WTF. I'm fucked. Forget that. Let's just go back to the
clojure book and write a factorial implementation.

So every once in a while I came back to clojure, did something. Studied
some clojurescript and finally I think that I can write some clojure... but
that took time and I still don't feel good about it. I feel sometimes that
there's a lot of very good people working in Relevance which knows
everything about clojure, but doesn't share anywhere. Maybe if we had a
couple of very good screencasts and proper documentation of how to write a
webapp in clojure available in the web. It could be very optioned(about
what libs to use), it could be even wrong... but getting something done
when you are beginning is way more important than to be concerned about if
you are doing the right thing.

But that might be just me.

On Mon, May 4, 2015 at 3:34 PM, Ernie de Feria 
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
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>
>> PhoenixElixir  1241949
>>
>> YesodHaskell   1303722
>>
>> LaravelPHP2684421
>>
>> PlayScala   4176085
>>
>> SymfonyPHP113020914
>>
>> RailsRuby   269151000
>>
>>
>> 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 t

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 15:24, Timothy Baldridge wrote:

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.



A seasoned professional/Clojure guru like yourself will obviously prefer 
a customised approach but the beginner and mid-level developer faces a 
different problem - how to get something fully-featured up quickly and 
maybe get paid for doing a job within a limited budget & timescale where 
exploring all the options and how to fit them together just isn't an option.


I'm all in favour of library composition but not exclusively. In the 
Python world they have Django and a tradition of do-it-yourself 
lightweight options. I don't understand why we can't adopt a similar 
approach.


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.

Re: Clojure needs a web framework with more momentum

[Timothy Baldridge]

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 
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
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 14:34, Ernie de Feria 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.



Clojure needs its own Rails or Typesafe Reactive Platform otherwise I 
fear it will remain a niche player. What's to lose? The current approach 
will always remain an option.


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.

Re: Clojure needs a web framework with more momentum

[Ernie de Feria]

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 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> 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.

Re: Clojure needs a web framework with more momentum

[Sean Johnson]

I thought about it and all that came to my mind that there simply 
won't be
an upgrade path. Once you generated your code / templates / whatever 
you

are done and up to yourself.
Having a supported upgrade path might be

1. to much for one or two persons to handle
2. Incompatible to the "generate" everything approach as one would 
have to
make sure that old code, enriched with user code (which can be 
anything),

still works with new code in whatever feature context that might be.


I think that's a very reasonable approach to take for the app template 
approach to a "web framework". I just wonder if it will ever meet the 
original posters presumed need for a web framework for the Clojure 
community. I think an upgrade path is probably table stakes (for many 
people, not all) for a web framework that will see wide adoption these 
days.


I am curious, why did you upgrade your application over such a long 
time?
Was this a product that got added new features over many years? Or was 
it
more a "it's easy to do, so let's just stay up to date in case we 
might

need it"?


It's the latter case, a few products that started 6+ years ago that 
continue to grow in usage and features. I can also add that the benefits 
that came along with each release (Rails 2, 3 and 4) have been critical 
in being able to add new features and modernize the app. Building 
features today with the tech we had in Ruby/Rails in 2009 would be very 
inefficient.


Cheers,
Sean

--
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.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

Am Montag, 4. Mai 2015 14:09:35 UTC+2 schrieb Sean Johnson:
>
>
>
> 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?
>
>
I thought about it and all that came to my mind that there simply won't be 
an upgrade path. Once you generated your code / templates / whatever you 
are done and up to yourself. 
Having a supported upgrade path might be

1. to much for one or two persons to handle
2. Incompatible to the "generate" everything approach as one would have to 
make sure that old code, enriched with user code (which can be anything), 
still works with new code in whatever feature context that might be.
 

> 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.
>

I am curious, why did you upgrade your application over such a long time? 
Was this a product that got added new features over many years? Or was it 
more a "it's easy to do, so let's just stay up to date in case we might 
need it"?

Best Regards,
Sven

-- 
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.

Re: Clojure needs a web framework with more momentum

[Eric MacAdie]

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.

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  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 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.

Re: Clojure needs a web framework with more momentum

[Sean Johnson]

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 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.

Re: Clojure needs a web framework with more momentum

[Andrey Antukh]

This is something that I'm currently working on:
https://github.com/funcool/catacumba
It is still in alpha, but it has the same philosophy that you have mention.

Cheers.
Andrey

2015-05-04 12:06 GMT+02:00 John Louis Del Rosario :

> Very interesting discussion going on here. As a beginner, what I'd like to
> see is not something like Django or Rails, but something like Flask.
> Where someone can just (require 'someframework) and it works. Maybe it
> could have thin wrappers over compojure, etc., since it will need to be
> opinionated anyway. It's still very simple, but takes away a lot of the
> guesswork and the distributed docs across multiple projects problem.
>
> Additional features can be done as libraries then, but specific for
> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>
> Just my 2c.
>
>
> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what
>> I found:
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>
>> PhoenixElixir  1241949
>>
>> YesodHaskell   1303722
>>
>> LaravelPHP2684421
>>
>> PlayScala   4176085
>>
>> SymfonyPHP113020914
>>
>> RailsRuby   269151000
>>
>>
>> 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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.

Re: Clojure needs a web framework with more momentum

[John Louis Del Rosario]

Very interesting discussion going on here. As a beginner, what I'd like to 
see is not something like Django or Rails, but something like Flask.
Where someone can just (require 'someframework) and it works. Maybe it 
could have thin wrappers over compojure, etc., since it will need to be 
opinionated anyway. It's still very simple, but takes away a lot of the 
guesswork and the distributed docs across multiple projects problem.

Additional features can be done as libraries then, but specific for 
`someframework`, like what Flask has. e.g. `someframework-sessions`, etc.

Just my 2c.

On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> 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.

Re: Clojure needs a web framework with more momentum

[Colin Fleming]

Note that the shopping cart is just one specific example from my current
itch that needs scratching - it's a very common one, but I'm sure there are
plenty more reusable component types that people expect these days.

One problem I see with the composition approach (which I'm a huge fan of in
general) is the multiplicative complexity. Something like a shopping cart
needs access to the persistence layer. In Rails, this is very easy - you
use ActiveRecord and you're done because everything else uses ActiveRecord
too. However in the Clojure world we have N persistence libraries
implementing M persistence strategies - I've never tried to make a reusable
component that sits in the "middle" of the stack (i.e. not something that's
relatively trivial to make dependency-free like logging), but I can imagine
that it's very difficult. And of course, persistence is just one aspect,
there must be many more like authentication and so on. A big part of the
reason for Ring's success is that it's the only game in town - I'm sure we
wouldn't have so much great functionality built on top of it if we had 4
incompatible options to choose from.

Someone earlier in the thread wrote about how Ruby was the abstraction in
contrast to PHP where libraries were tied to a framework. I've never worked
with Rails seriously, but I find it hard to believe that libraries such as
shopping carts intended for Rails will work out of the box with some other
framework - is this the case? The ones I looked at (admittedly briefly and
some time ago) were all Rails-specific.

On 4 May 2015 at 20:41, Sven Richter  wrote:

> So, what I gather from this discussion are the following points. Clojure
> "needs" a "webframework" that is
>
> - fully documented
> - easy for beginners to use
> - opinionated about the libraries
> - structured
> - composable
> - has something nice like django's admin backend
> - a vibrant community support
> - a shopping card (whereas I would see that fit into an external library)
>
> I agree that we have almost everything we need in the form of single
> libraries. And I think a mix of leiningen templates and plugins is the way
> to go here.
> The reason for the last statement is my experience with django. The admin
> UI is awesome and it fullfills 95% of your needs, but for the rest of it to
> make it work I had to start hacking my local django source, which is PITA
> obv.
>
> I would refrain from doing some magic that only works in a specific
> context, but instead just generate code that is put into a fixed structure
> and works. The advantage is, one can change the code all the time if one
> needs to.
>
> 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.
>
> I am open for everything in that area, as long as it stays in the limits I
> stated above, so, if someone wants to join, he is welcome.
>
> I would also go the other way around and put efforts into someone elses
> project, if that makes sense.
>
> Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler:
>
>> On Sat, May 2, 2015 at 11:12 PM, Sven Richter 
>> wrote:
>>
>>> Reading through all the discussion I don't get which features you are
>>> actually missing. I love luminus and did a lot with it, however, for me it
>>> was missing some standard stuff, that's why I put together closp, which is
>>> just another leiningen template providing some more features out of the box.
>>> I'd consider adding even more features if you would become more specific
>>> in terms of features.
>>>
>>
>> For me, one of the killer features that keeps me coming back to
>> Python/Django for web development is the auto-generated admin interface
>> that lets non-programmers add new content to the database.
>>
>> Clojure's Caribou is the only Clojure system I've seen to offer something
>> similar, but as I recall, Caribou is no longer being actively developed.
>>
>  --
> 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 emai