Looks like Grails have new competition

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Looks like Grails have new competition

Michael Mallete
http://www.playframework.org

Pretty much a Grails clone, sans the Groovy. Wonder why the need to reinvent the wheel. :-|
Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

jondo_w
Yep, sadly very much the way of the Java world. There's often so much proliferation amongst Java library options that in my mind it becomes a liability to Java usage and adoption. And the more dilution, the less attention and support there is for a particular framework. So yes, Grails suffers.

Right I'm off to rewrite all my applications in the latest and greatest Play! framework!!! ;-)


From: Michael Mallete <[hidden email]>
To: [hidden email]
Sent: Friday, November 28, 2008 8:20:39 AM
Subject: [grails-user] Looks like Grails have new competition

http://www.playframework.org

Pretty much a Grails clone, sans the Groovy. Wonder why the need to reinvent the wheel. :-|

Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Fred Janon
In reply to this post by Michael Mallete
It actually uses Groovy:

"You will love to write :

You've ${email.unread?.size() ?: 'none'} unread emails !
The expression language used by the template engine is Groovy"

Aah, it seems that Guillaumes are very active... :)

Fred

On Fri, Nov 28, 2008 at 15:20, Michael Mallete <[hidden email]> wrote:
http://www.playframework.org

Pretty much a Grails clone, sans the Groovy. Wonder why the need to reinvent the wheel. :-|

Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Guillaume Laforge-2
On Fri, Nov 28, 2008 at 9:28 AM, Fred Janon <[hidden email]> wrote:
> [...]
> Aah, it seems that Guillaumes are very active... :)

It's not me, it's not me, I swear!
But I met the guy once, a while ago, as he's based in Paris. Nice and
interesting guy.
And obviously, he's got a great firstname ;-)

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Robert Fletcher
In reply to this post by jondo_w
On Fri, Nov 28, 2008 at 7:12 AM, Darryl Pentz <[hidden email]> wrote:
> Yep, sadly very much the way of the Java world. There's often so much
> proliferation amongst Java library options that in my mind it becomes a
> liability to Java usage and adoption. And the more dilution, the less
> attention and support there is for a particular framework. So yes, Grails
> suffers.
>

I disagree. There are some pretty clear leaders in the field of
Java/JVM frameworks (e.g. Spring, Hibernate, Grails) and some
interesting options bubbling under (e.g. Stripes) and some horrible
monoliths from whose mistakes we can learn (e.g. Struts, JSF). Variety
is good in my view, the good stuff will bubble to the top and even
those ideas that fall by the wayside may offer something to learn
from.

On Fri, Nov 28, 2008 at 8:28 AM, Fred Janon <[hidden email]> wrote:
> "You will love to write :
>
> You've ${email.unread?.size() ?: 'none'} unread emails !
>

"You've none unread emails!"? That's even better than JetGroovy's "Do
you want the project reference the plugin"

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

jondo_w
These are very much our opinions and we'll have to agree to disagree.

I've been on my soap box before on this forum, but at the risk of repeating myself, I used Webwork 1.x many moons ago. It was an excellent framework. Fast, lean, powerful, simple. There was nothing wrong with it. Then a few bored developers decided it would be a good idea to just rewrite the damn thing, for what ultimately would be trivial benefit... and so Webwork 2 was born - a far more complicated beast with XWork at its core just to thicken the plot. So now those of us actually solving business problems with real jobs and real applications and whatnot, had to either stick with Webwork 1, or translate all our real world apps across to Webwork 2 if we wanted the benefit of continued support for JEE standards and whatnot. Due to the specific requirements of my projects, I was able to just stick with Webwork 1 so it was not a big deal to me, though there was a lot of effort now put into Webwork 2, that could have been better spent just optimizing Webwork
 1, and evolving it over time. So I was frustrated at having to be left behind by the peleton, to use a cycling analogy. So, many people ported their apps, toy and real world over to Webwork 2 - which was not a mere 'flip a switch' job.

Not much longer after that, in terms of product lifecycles, I hear that the Webwork 2 developers have obviously gotten bored again, and decided it was a great idea to merge Webwork 2 with Struts. I pity the poor people who all had to now port all their apps to what was now to be called *trumpet sounds* Struts 2. No doubt, soon, Struts 2 will fork, or merge with some other YetAnotherJavaWebFramework and the cycle will continue. And after all that, the actual bottom line benefit to developers ends up being very little. There's not a helluva lot more I can do with Grails now roughly 6 years on, that I couldn't accomplish with Webwork 1. If in that time, those developers had just stuck with the Webwork 1 core code and optimized it, improved it, evolved it, it would be a much better animal today. Instead it seems like all the rewriting and merging makes us just move sideways.

I'm really thankful to Graeme that he's been incredibly conservative with additions and changes to the Grails core code. Long may that live on while the variations can thrive in plugin land.

That's my $0.02 and I'll leave it at that. No, I'm not bitter! :-)

- Darryl



----- Original Message ----
From: Robert Fletcher <[hidden email]>
To: [hidden email]
Sent: Friday, November 28, 2008 10:43:28 AM
Subject: Re: [grails-user] Looks like Grails have new competition

On Fri, Nov 28, 2008 at 7:12 AM, Darryl Pentz <[hidden email]> wrote:
> Yep, sadly very much the way of the Java world. There's often so much
> proliferation amongst Java library options that in my mind it becomes a
> liability to Java usage and adoption. And the more dilution, the less
> attention and support there is for a particular framework. So yes, Grails
> suffers.
>

I disagree. There are some pretty clear leaders in the field of
Java/JVM frameworks (e.g. Spring, Hibernate, Grails) and some
interesting options bubbling under (e.g. Stripes) and some horrible
monoliths from whose mistakes we can learn (e.g. Struts, JSF). Variety
is good in my view, the good stuff will bubble to the top and even
those ideas that fall by the wayside may offer something to learn
from.

On Fri, Nov 28, 2008 at 8:28 AM, Fred Janon <[hidden email]> wrote:
> "You will love to write :
>
> You've ${email.unread?.size() ?: 'none'} unread emails !
>

"You've none unread emails!"? That's even better than JetGroovy's "Do
you want the project reference the plugin"

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


     

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Marcos Silva Pereira
A lot of static stuff in Play! that I can't understand. Why controller methods must be static? Anyway, would be amazing to see error pages like that in Grails:
http://www.playframework.org/manual/_detail/error.png?id=contents%3Aoverview&cache=cache

Kind Regards

--
Marcos Silva Pereira
http://marcospereira.wordpress.com
"People who are crazy enough to think they can change the world, are the ones who do."


On Fri, Nov 28, 2008 at 7:19 AM, Darryl Pentz <[hidden email]> wrote:
These are very much our opinions and we'll have to agree to disagree.

I've been on my soap box before on this forum, but at the risk of repeating myself, I used Webwork 1.x many moons ago. It was an excellent framework. Fast, lean, powerful, simple. There was nothing wrong with it. Then a few bored developers decided it would be a good idea to just rewrite the damn thing, for what ultimately would be trivial benefit... and so Webwork 2 was born - a far more complicated beast with XWork at its core just to thicken the plot. So now those of us actually solving business problems with real jobs and real applications and whatnot, had to either stick with Webwork 1, or translate all our real world apps across to Webwork 2 if we wanted the benefit of continued support for JEE standards and whatnot. Due to the specific requirements of my projects, I was able to just stick with Webwork 1 so it was not a big deal to me, though there was a lot of effort now put into Webwork 2, that could have been better spent just optimizing Webwork
 1, and evolving it over time. So I was frustrated at having to be left behind by the peleton, to use a cycling analogy. So, many people ported their apps, toy and real world over to Webwork 2 - which was not a mere 'flip a switch' job.

Not much longer after that, in terms of product lifecycles, I hear that the Webwork 2 developers have obviously gotten bored again, and decided it was a great idea to merge Webwork 2 with Struts. I pity the poor people who all had to now port all their apps to what was now to be called *trumpet sounds* Struts 2. No doubt, soon, Struts 2 will fork, or merge with some other YetAnotherJavaWebFramework and the cycle will continue. And after all that, the actual bottom line benefit to developers ends up being very little. There's not a helluva lot more I can do with Grails now roughly 6 years on, that I couldn't accomplish with Webwork 1. If in that time, those developers had just stuck with the Webwork 1 core code and optimized it, improved it, evolved it, it would be a much better animal today. Instead it seems like all the rewriting and merging makes us just move sideways.

I'm really thankful to Graeme that he's been incredibly conservative with additions and changes to the Grails core code. Long may that live on while the variations can thrive in plugin land.

That's my $0.02 and I'll leave it at that. No, I'm not bitter! :-)

- Darryl



----- Original Message ----
From: Robert Fletcher <[hidden email]>
To: [hidden email]
Sent: Friday, November 28, 2008 10:43:28 AM
Subject: Re: [grails-user] Looks like Grails have new competition

On Fri, Nov 28, 2008 at 7:12 AM, Darryl Pentz <[hidden email]> wrote:
> Yep, sadly very much the way of the Java world. There's often so much
> proliferation amongst Java library options that in my mind it becomes a
> liability to Java usage and adoption. And the more dilution, the less
> attention and support there is for a particular framework. So yes, Grails
> suffers.
>

I disagree. There are some pretty clear leaders in the field of
Java/JVM frameworks (e.g. Spring, Hibernate, Grails) and some
interesting options bubbling under (e.g. Stripes) and some horrible
monoliths from whose mistakes we can learn (e.g. Struts, JSF). Variety
is good in my view, the good stuff will bubble to the top and even
those ideas that fall by the wayside may offer something to learn
from.

On Fri, Nov 28, 2008 at 8:28 AM, Fred Janon <[hidden email]> wrote:
> "You will love to write :
>
> You've ${email.unread?.size() ?: 'none'} unread emails !
>

"You've none unread emails!"? That's even better than JetGroovy's "Do
you want the project reference the plugin"

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Daniel Kimmig
In reply to this post by Michael Mallete

mykol wrote
http://www.playframework.org

Pretty much a Grails clone, sans the Groovy. Wonder why the need to reinvent
the wheel. :-|


I tried Play and I must say it is very nice. They reloading of things is far superior to Grails, because they use the Eclipse Compiler internally. It is truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line stuff. Everything runs a lot faster. There is no cold-start of the JVM (and dont get me started on "grails interactive" which fails after three command invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it can help Grails to get better. There is are for both frameworks, since Grails tries to be this perfectly glued combination of Spring, Hibernate, SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and completely says no to the Servlet API. (You can however create a war file of your play application).
Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Nicolás Dijkstra
If it's pure java, there is no point in comparing it to Grails.


On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Daniel Guryca
Nope,

Groovy is used as a templating language so it's not a pure java.
You can create tags and templates using Groovy.

But yes controllers, domains and others can be written in java only.

Cheers
Daniel

2009/10/30 Nicolás Dijkstra <[hidden email]>
If it's pure java, there is no point in comparing it to Grails.



On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Michael Berg-7
In reply to this post by Nicolás Dijkstra
There is also the Spring Roo framework from springsource.

This framework is based on pure java and comes from SpringSource, who also owns G2One.

Looks promising, although I am surprised that resources are diverted away from Grails development to work on what is essentially a competing framework. I wonder what the strategy behind that is. Hopefully not a way to further one framework at the expense of another.

On the up side SpringSource's STS offers by far the best grails development environment to date.

Regards,
Michael Berg

2009/10/30 Nicolás Dijkstra <[hidden email]>
If it's pure java, there is no point in comparing it to Grails.



On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Nicolás Dijkstra
After 8 years dealing with Java, EJBs, Struts, Hibernate, Spring with all the configurations involved for starting projects up i found (the holly) Grails (along with the wonderful Groovy). i feel so comfrorable developing with Grails that i wouldn't want to try any other framework unless it helps me increase my productivity by far and i don't think that going back to (almost) pure java would do that.

On Fri, Oct 30, 2009 at 9:42 AM, Michael Berg <[hidden email]> wrote:
There is also the Spring Roo framework from springsource.

This framework is based on pure java and comes from SpringSource, who also owns G2One.

Looks promising, although I am surprised that resources are diverted away from Grails development to work on what is essentially a competing framework. I wonder what the strategy behind that is. Hopefully not a way to further one framework at the expense of another.

On the up side SpringSource's STS offers by far the best grails development environment to date.

Regards,
Michael Berg

2009/10/30 Nicolás Dijkstra <[hidden email]>
If it's pure java, there is no point in comparing it to Grails.



On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Michael Berg-7
I agree - however, sometimes I feel like I want to go the other way. Coding by convention, scaffolding, dynamic methods - it's all very nice when it works, but when it doesn't you feel a bit helpless. So much is going on behind your back that it can be hard to identify just what is causing the problem.

Personally I am very comfortable working in pure java + spring xml. I guess it's just a matter of habit and getting to know Grails better. Because I'm convinced that frameworks like Grails are the way forward for web development.

Regards,
Michael Berg

2009/10/30 Nicolás Dijkstra <[hidden email]>
After 8 years dealing with Java, EJBs, Struts, Hibernate, Spring with all the configurations involved for starting projects up i found (the holly) Grails (along with the wonderful Groovy). i feel so comfrorable developing with Grails that i wouldn't want to try any other framework unless it helps me increase my productivity by far and i don't think that going back to (almost) pure java would do that.


On Fri, Oct 30, 2009 at 9:42 AM, Michael Berg <[hidden email]> wrote:
There is also the Spring Roo framework from springsource.

This framework is based on pure java and comes from SpringSource, who also owns G2One.

Looks promising, although I am surprised that resources are diverted away from Grails development to work on what is essentially a competing framework. I wonder what the strategy behind that is. Hopefully not a way to further one framework at the expense of another.

On the up side SpringSource's STS offers by far the best grails development environment to date.

Regards,
Michael Berg

2009/10/30 Nicolás Dijkstra <[hidden email]>
If it's pure java, there is no point in comparing it to Grails.



On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email









Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Björn Wilmsmann-2
In reply to this post by Daniel Kimmig
2009/10/30 Daniel Kimmig <[hidden email]>:

> I tried Play and I must say it is very nice. They reloading of things is far
> superior to Grails, because they use the Eclipse Compiler internally. It is
> truely "fix and reload" and not
>
> - fix
> - see same error
> - restart grails
> - see same error
> - run grails clean and clear the scriptcache
> - run-app
> - error resolved

I see the need for Grails to improve at this point, too. The 'grails
clean and restart' cure-all for strange errors is just awkward.

> Another benefit is the fact that Play uses Python for the Command-Line
> stuff. Everything runs a lot faster.

Good point. While using Groovy for these command line tasks does make
sense in terms of 'eating or own dog food' using a different scripting
language like Python or Ruby for anything that doesn't require the JVM
like pure code generation tasks, certainly would have its benefits in
terms of speed.
Then again, this would require installing another scripting language
on each development machine, which is fine on UNIX-like systems but
pretty much excludes Windows users (at least if you don't want to
provide your own graphical install wizard).

--
Viele Grüße / Best regards,
Björn Wilmsmann

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Daniel Honig
In reply to this post by Michael Berg-7
I was going to say that the demo really makes JQuery look great!
I'm going to have to take another look at JQuery ;)

On Fri, Oct 30, 2009 at 8:42 AM, Michael Berg <[hidden email]> wrote:
There is also the Spring Roo framework from springsource.

This framework is based on pure java and comes from SpringSource, who also owns G2One.

Looks promising, although I am surprised that resources are diverted away from Grails development to work on what is essentially a competing framework. I wonder what the strategy behind that is. Hopefully not a way to further one framework at the expense of another.

On the up side SpringSource's STS offers by far the best grails development environment to date.

Regards,
Michael Berg

2009/10/30 Nicolás Dijkstra <[hidden email]>
If it's pure java, there is no point in comparing it to Grails.



On Fri, Oct 30, 2009 at 9:20 AM, Daniel Kimmig <[hidden email]> wrote:



mykol wrote:
>
> http://www.playframework.org
>
> Pretty much a Grails clone, sans the Groovy. Wonder why the need to
> reinvent
> the wheel. :-|
>
>



I tried Play and I must say it is very nice. They reloading of things is far
superior to Grails, because they use the Eclipse Compiler internally. It is
truely "fix and reload" and not

- fix
- see same error
- restart grails
- see same error
- run grails clean and clear the scriptcache
- run-app
- error resolved


Another benefit is the fact that Play uses Python for the Command-Line
stuff. Everything runs a lot faster. There is no cold-start of the JVM (and
dont get me started on "grails interactive" which fails after three command
invocations due to permGen Errors).


I for one think that this kind of competition is good for Grails, because it
can help Grails to get better. There is are for both frameworks, since
Grails tries to be this perfectly glued combination of Spring, Hibernate,
SiteMesh and GSPs whereas Play is more like Django, RoR, Symfony and
completely says no to the Servlet API. (You can however create a war file of
your play application).
--
View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26129138.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Robert Fletcher
In reply to this post by Michael Berg-7
On Fri, Oct 30, 2009 at 12:42 PM, Michael Berg
<[hidden email]> wrote:
>
> Looks promising, although I am surprised that resources are diverted away
> from Grails development to work on what is essentially a competing
> framework. I wonder what the strategy behind that is. Hopefully not a way to
> further one framework at the expense of another.
>

I don't see it that way. (Friendly) competition is healthy, both
products can learn from each other. Development is not a zero-sum
game; just because some of Spring Source's development effort is going
into Roo doesn't mean Grails necessarily suffers.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

rstudner
Groovy (and thus Grails) scares some folks.. the (real or not) memory  
usage increase and performance decrease.

Some people want java only, no other options allowed (I see this all  
the time)

Roger

On Oct 30, 2009, at 10:19 AM, Robert Fletcher wrote:

> On Fri, Oct 30, 2009 at 12:42 PM, Michael Berg
> <[hidden email]> wrote:
>>
>> Looks promising, although I am surprised that resources are  
>> diverted away
>> from Grails development to work on what is essentially a competing
>> framework. I wonder what the strategy behind that is. Hopefully not  
>> a way to
>> further one framework at the expense of another.
>>
>
> I don't see it that way. (Friendly) competition is healthy, both
> products can learn from each other. Development is not a zero-sum
> game; just because some of Spring Source's development effort is going
> into Roo doesn't mean Grails necessarily suffers.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Daniel Kimmig
In reply to this post by Björn Wilmsmann-2

BjoernW wrote
2009/10/30 Daniel Kimmig <dkimmig@gmail.com>:
I see the need for Grails to improve at this point, too. The 'grails
clean and restart' cure-all for strange errors is just awkward.
Thanks, finally somebody that feels my pain ;)

BjoernW wrote
> Another benefit is the fact that Play uses Python for the Command-Line
> stuff. Everything runs a lot faster.
Good point. While using Groovy for these command line tasks does make
sense in terms of 'eating or own dog food' using a different scripting
language like Python or Ruby for anything that doesn't require the JVM
like pure code generation tasks, certainly would have its benefits in
terms of speed.
Then again, this would require installing another scripting language
on each development machine, which is fine on UNIX-like systems but
pretty much excludes Windows users (at least if you don't want to
provide your own graphical install wizard).
The Play Python scripts are said to be written in a portable manner such that...

"The play command line utility uses python. So it should work out of the box on any UNIX system. If you’re running Windows, don’t worry, a python runtime is bundled with the framework."

no installation by the user is required.
Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Graeme Rocher-3
Thanks for the feedback guys, it really helps. Although not possible
in the 1.2 timeline we are going to be looking at what we can do to
eliminate some of the cached compiled classes issues that require a
'grails clean' shortly after 1.2.

The reason it won't make it into 1.2 is because it may require a
significant rework of the way we do classloading and it is too risky
to do now. There is a possibility of doing a JDT based solution for
Grails as well, but we'll see.

On the competition front Play looks interesting, but Grails is at a
different level in terms of community, adoption and flexibility. I
doubt you'll get over 300 plugins for Play ;-)

Competition is good though, and there are certainly areas of Play we
can learn from.

Cheers,

On Fri, Oct 30, 2009 at 3:23 PM, Daniel Kimmig <[hidden email]> wrote:

>
>
>
> BjoernW wrote:
>>
>> 2009/10/30 Daniel Kimmig <[hidden email]>:
>> I see the need for Grails to improve at this point, too. The 'grails
>> clean and restart' cure-all for strange errors is just awkward.
>>
>
> Thanks, finally somebody that feels my pain ;)
>
>
> BjoernW wrote:
>>
>>> Another benefit is the fact that Play uses Python for the Command-Line
>>> stuff. Everything runs a lot faster.
>> Good point. While using Groovy for these command line tasks does make
>> sense in terms of 'eating or own dog food' using a different scripting
>> language like Python or Ruby for anything that doesn't require the JVM
>> like pure code generation tasks, certainly would have its benefits in
>> terms of speed.
>> Then again, this would require installing another scripting language
>> on each development machine, which is fine on UNIX-like systems but
>> pretty much excludes Windows users (at least if you don't want to
>> provide your own graphical install wizard).
>>
>
> The Play Python scripts are said to be written in a portable manner such
> that...
>
> "The play command line utility uses python. So it should work out of the box
> on any UNIX system. If you’re running Windows, don’t worry, a python runtime
> is bundled with the framework."
>
> no installation by the user is required.
> --
> View this message in context: http://old.nabble.com/Looks-like-Grails-have-new-competition-tp20729529p26130926.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Looks like Grails have new competition

Daniel Kimmig

Graeme Rocher-3 wrote
On the competition front Play looks interesting, but Grails is at a
different level in terms of community, adoption and flexibility. I
doubt you'll get over 300 plugins for Play ;-)
That is true, but the same thing could have been said about Grails in the "0.4"-release times (actually that was the timeframe where I joined the grails-community ;) ).


Graeme Rocher-3 wrote
Competition is good though, and there are certainly areas of Play we
can learn from.
Definetly, and it goes both ways of course. It just hope the two communities keep it at that level and dont get in a useless "my tool is better than your tool"-war ;)
12