Open Letter to Play Framework Developers

16224 views
Skip to first unread message

Roman Bykovskiy

unread,
Mar 30, 2012, 2:42:36 AM3/30/12
to play-fr...@googlegroups.com
Dear friends!


One small truth

Scala sucks. Well, the language might be considered quite good but the fact that compilation really takes a lot of time is indisputable.
Up to 13sec! And that's after slight changes made to the template (!)
Having allocated myself a separate server especially for compilation, I managed to increase the speed to 5 sec – 
butstill it remains a lot. We've tried it on different platforms.

One big lie

"The Play framework makes it easier to build web applications with Java & Scala."
The truth would be: "The Play framework makes it easier to build web applications with Scala, but if you want to use Java.... then, well ok May The Force be with you!"
I'll speak about that later.


My story

When I read about Play framework for the first time, I entered the website and watched the video about the 1.
x. version. Oh my God! This is it! - I thought. I've installed it, repeated everything according to the example on the video,and quickly applying documentation outlined a copy of the project that I'm working on.
A whole month I tried to convince my boss of using Play Framework in new projects, because it was much better than what we were using. And I did it. But you have played a trick – changed everything 
radically.

Now when we are realising a new pro
ject using Play framework 2, my colleagues give be black looks, but I can't make any excuses– explain that it is not what it used to be, that I cannot help them when I don't know the way it works.


Quick elaboration

What I liked in Play 1.x 
was the speed. Not the work speed (now everybody has it up-to-date), but the elaboration speed. Everything is quick and simple. In the 2.0 it's a torture. 
Resistance to the current circumstances, efforts to find the way of doing what used to be done easily and in several modes.

Scala

I am a Java developer. Why must I study Scala to make an elementary template? That is just a template! A means of formating an information output. That is fantastic that it can be compiled. But what do I need it for? If I spend a great deal of time on elaboration, especially on waiting.

Maybe in America you compile Scala code, but here in Russia Scala code compile you. 
It hurts!

To 
fulfill the simpliest things I have to adress Google groups because there is no information.
I cannot set a variable in the template to use 
it later in the cycle.
What for do I need this sort of template engine that I have to “overcome”: 

[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:156: '(' expected but ')' found.
[error]                                                                                                 """),_display_(Seq(/*123.14*/for)),format.raw/*123.17*/(""" ((sector,i) <-subevent.sectors.zipWithIndex) """),format.raw("""{"""),format.raw/*123.64*/("""
[error]                                                                                                                                 ^
[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:421: illegal start of simple expression
[error] """)))})),format.raw/*388.2*/("""
[error]       ^
[error] two errors found


Eh? Where should I look for a mistake in this output? Please don't say that in line 156...
How THIS can help me to find out what has happenedAnd it was just an extra space character.

What about data transfer to the template?

Before I could transfer all the data to the template by use of @Before, for example menu that I have on every page. '
Now I have to transfer menu data in every template call, and in each of them I should pass it through the base one. That's nonsense!

Porting

That is great that you believe that Scala is the thing of the future ( while I doubt that with this compilation speed you mean the nearest future, but ok). Do add but don't substitute! You consider Ebean better than Hibernate – leave the choice to the ones who are used to it!

Try opening a restaurant in Japan. Substitute sticks with forks ( because there exists a wide-spread opinion that forks are more progressive than sticks) and look if it works out.

B
ackward compatibility always was a basis of Java, that is why it was developing slowly, though there were no problems with launching old projects in new versions.

You have removed war creating – how should I deploy it on tomcat.
You have added 
processing of text output through org.apache.commons.lang.StringEscapeUtils.escapeHtml(text). Oh, that is nice! But it crumples all the text turning it into &#1057;&#1099;&#1085;&#1086;&#1074;&#1100;&#1103;
to turn it off I have to edit Templates.scala and somehow recompile (taking into account that I have no idea how it should be done manually). After a Play framewok version update – I will have to do it again.


Conclusion

Now Play is a 
pain in the neck ! If in the beginning it was a very simple and very fast framework, now it has become just one of many.
You will probably attract Scala fans, but you will lose Java developers, because it is just impossible to avoid working with Scala while creating a product on Play.

Maybe Scala is not that bad, but I am a Java developer and can study another language only when I have time. But now I must do what I am to do, by the use of the means I know, and the knowledge of which was announced b
y framework developers.

p.s. Remember 
Apple's goal which is “to create simple objects”. The user was deprived of everything unnecessary. It is true that he was bereft of some frills, but as it turned out to be a golden mean. Moreover he still can do everything he wants but at the same time an ordinary user is not distracted with all that additional stuff. 

p.p.s. Return ok (…) are you serious? If I'm ready to return something to the user it is already ok! Otherwise I throw exception.

P.P.P.S If this idea of Scala belongs to the man who has made the website acid green than it is him who is the root of evil!) Get rid of him!)

冉兵

unread,
Mar 30, 2012, 3:10:37 AM3/30/12
to play-fr...@googlegroups.com
Man, hold yourself a bit.  If you're happy with 1.x, just stick to it like I and many others do. Play team had bigger business consideration than just technical merits (like backward compatibility) when they decided to go full Scala.  If you have to use the latest except the templates, well, you have the Groovy port and the my Japid port.  Ranting I guess won't change anything. 

Peace. 

Bing


2012/3/30 Roman Bykovskiy <802...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/IanbqC-c-MkJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

Ontheroad

unread,
Mar 30, 2012, 3:16:30 AM3/30/12
to play-fr...@googlegroups.com
+1

In my opinion, the version 2 of something is try to improve something and overcome its disadvantage. But what happened to play is that Play2 add some cool stuff, but it discard all it's important benefits. 

The mix of java and scala is sucks. Especially the problem every play user talking about, compiling time, which really makes the framework impossiblly usable. And it seems it's not a bug, it's like a design failure and can never be solved.

I always wonder why mix java scala together. Why not make two separate Java version and Scala version instead. Or like play1 provide a scala module.

Force people to learn scala is fine. it's actually very fun to learn scala. But thing problem is that you force people learn some thing, it indeed give a little bit of benefits, but the overall speed and user experience sucks..

Sent from my iPad
--

Alexander L.

unread,
Mar 30, 2012, 3:18:49 AM3/30/12
to play-fr...@googlegroups.com
Agree!

Edward

unread,
Mar 30, 2012, 3:19:48 AM3/30/12
to play-fr...@googlegroups.com
+1


On Friday, March 30, 2012 10:42:36 AM UTC+4, Roman Bykovskiy wrote:

冉兵

unread,
Mar 30, 2012, 3:23:18 AM3/30/12
to play-fr...@googlegroups.com
There is one mistake they have made: they call it Play2. They made people feel they have to "upgrade" from 1 to 2. If they had call it something else, both Java developers and Scala developers will be happy.  But again, I believe it has been a business decision rather than a technical one. 



2012/3/30 Ontheroad <onther...@gmail.com>

Nicolas Leroux

unread,
Mar 30, 2012, 3:26:31 AM3/30/12
to play-fr...@googlegroups.com
Why don't you just continue to use the 1.x then? Nobody forces you to use 2.x. I don't understand your problem there. Please, don't forget that this is open source and that we are not backed up by large company.

Nicolas

Roman Bykovskiy

unread,
Mar 30, 2012, 3:43:15 AM3/30/12
to play-fr...@googlegroups.com
We have to be up to date in case 1.x is not supported anymore and still has bugs  

пятница, 30 марта 2012 г. 11:26:31 UTC+4 пользователь Nicolas Leroux - committer написал:
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


пятница, 30 марта 2012 г. 11:26:31 UTC+4 пользователь Nicolas Leroux - committer написал:
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


пятница, 30 марта 2012 г. 11:26:31 UTC+4 пользователь Nicolas Leroux - committer написал:
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


пятница, 30 марта 2012 г. 11:26:31 UTC+4 пользователь Nicolas Leroux - committer написал:
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


пятница, 30 марта 2012 г. 11:26:31 UTC+4 пользователь Nicolas Leroux - committer написал:
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

Manuel Bernhardt

unread,
Mar 30, 2012, 3:47:30 AM3/30/12
to play-fr...@googlegroups.com
Roman,

a lot of your pain seems to come from the increased reloading time when working on views, and on obscure error reporting when using the Scala templates.

I know where you are coming from, we were in the exact same situation with Play 1 & Scala 0.9.1 some months ago. We had 30 views and it took 3 minutes to reload the application when changing a space in a template. Some of that reloading time was related to all the bytecode enhancement going on, but the root cause was the classloader being dropped when a Scala file was changed, leading to all the reloading. So we ported everything to Groovy templates, and had a decent development turnover again (at least when developing on views). Things got better when we switched to Play 2, but then again we're doing this with Scala - I must confess I haven't had time to try Play 2 with Java yet much.

If you want to use the Groovy templating system of Play 1 in Play 2, this is possible, via:


or



We're using the first one in production, it covers our needs in that regard. So as a way to reduce your pain, I'd recommend trying this way out.

Manuel

Nicolas Leroux

unread,
Mar 30, 2012, 3:48:12 AM3/30/12
to Roman Bykovskiy, play-fr...@googlegroups.com
1.x is supported and releases are still planned.

Nicolas
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/7-m--_2W9XoJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

Steve Chaloner

unread,
Mar 30, 2012, 3:57:57 AM3/30/12
to play-fr...@googlegroups.com
The mix of Java and Scala is completely under the covers.  If you want to develop a pure Java app on Play 2 you can - the templates may or may not be Scala-based, since the template engine is pluggable.  The potential is there to develop pure Java/pure Scala/hyrbid apps - it just depends on what you prefer.  Each language has its own API, so you're not forced to use Scala idioms when writing Java code..

Take a look at the architecture circle diagram at http://www.playframework.org/ - there are distinct and non-overlapping circles for Java and Scala.
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

Roch Delsalle

unread,
Mar 30, 2012, 4:35:50 AM3/30/12
to play-fr...@googlegroups.com
You can use Groovy templates with play 2 :


2012/3/30 Steve Chaloner <st...@objectify.be>
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/qNyrhUtiF58J.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

Allen

unread,
Mar 30, 2012, 5:08:53 AM3/30/12
to play-fr...@googlegroups.com
Roman: I think you use the wrong words.

But, in my opinion the play framework is at the moment in a very difficult and dangerous phase.
We are developing (still) mainly play 1.2 applications and are very happy with it.
Anything is included and you can do such many in a very simple way. I switched over from rails
but like more the java way.

Play 2 is for me in a state where I am cannot make my projects at the moment:
- no tomcat deployment
- slow scala compilation time in dev mode
- no directly JPA support 
- no CRUD module

Also it seems that the framework did go a step back. I know its a complete rewrite but you have todo many things 
in another way (here a migration guide would be very helpful which describes how you can do things in play 2 in comparison to play 1),
and very often you hear "that should be done by modules and is no longer included in the core framework" (sure we can discuss what should
be in the core, but the main problem is that there is no module available at the moment).

I know that sometimes you have to change your development style to makes thing on a better way, and maybe thats the idea behind
play2 but to make the transition the gap is very wide and I am afraid that during migration or making a new project with using play2
the problem comes up that the feature is not available in the framework. So in my eyes some features of play 2 are very nice, but
many important things from play1 did not make the transition and this way I will stay on play1.

On the other side it looks to me that only little effort is done for play1 because it maybe have a lower priority. There are still important bugs open

I hope that this situation about play 1 and 2 will clean up and play will stay as the nice web framework it ways in the past.
At least I will still thank the dev team for the nice and much work on play!

Best,
Allen

P.S: I would be great if there is a kind of wishlist for modules. Maybe we can use something like http://www.uservoice.com/
to collect ideas and vote about it.

novi border

unread,
Mar 30, 2012, 5:32:34 AM3/30/12
to play-fr...@googlegroups.com
Hi,

I would like to add my 2 cents..

Play2 is very nice framework when you look at it from the outside, but it is still not ready
to provide java developers with the same speed and ease of use as the play 1 does.
I think the main problems are scala compilation speed together with using sbt and scala views
which force some rather cryptic error messages on the java developers coming from play1.
The situation will probably clear up a bit with time, but I am still concerned it will not come
near play1 in terms of ease of use in developement, which was one of plays strongest selling points.

Now, the play team has been swamped with making play2 release since last fall, and play 1 was pretty
much abandoned. This is purely a business decision necessitated by finite resources of the developement team, what will happen in the future remains to be seen, now that play team has more time. I hope play 1 will not
continue to be abandoned, and will at least get some needed updates, like fixing some bugs and updating websockets to the new version.. There is also SPDY support in new netty which many pla1 devs would probably like, but I don't know will it be coming to play1.

I like scala and have used it a few times in the last 5 years, I like clojure/noir also. But, probably like many other devs, I have to use java on my job. Commiting to play1 was not an easy decision to make, but it is such a productive and fast framework that we decided to give it a shot. The current state of play is not encouraging to many of us, mostly because of much slower turnaround, and still some cryptic error messages. I think, most java devs would have been happier with smoother upgrade to play 1 which would have integrated Akka more into the existing framework, it would have made play stand out even more among java frameworks. I still hope we will get there, but since the scala compiler is now so tightly integrated, it will probably take much longer to get there..

Anyway, sorry for the rant, and kudos to play team!

Roman Bykovskiy

unread,
Mar 30, 2012, 7:00:49 AM3/30/12
to play-fr...@googlegroups.com, Roman Bykovskiy
I think you should call Play framework 2.0 something like Play Scala ..  by now it's looks like 2.0 is a next step of 1.x, but it's totally diferrent. It's s misleading.
If you are planing to support 1.x - let's call it Play Java,  and 2.0 - Play Scala.  
To make someday Play Java 2.0 )

пятница, 30 марта 2012 г. 11:48:12 UTC+4 пользователь Nicolas Leroux - committer написал:

пятница, 30 марта 2012 г. 11:48:12 UTC+4 пользователь Nicolas Leroux - committer написал:

grandfatha

unread,
Mar 30, 2012, 7:32:51 AM3/30/12
to play-fr...@googlegroups.com
My 2 cents to this post are simple:  I started using Play1 when 1.0 came out and absolutely fell in love with it. But Play2 is not longer the framework I love, which made me switch to Python/Django just to avoid the hassle of dealing with Scala compilation speed.

tschundeee

unread,
Mar 30, 2012, 7:43:34 AM3/30/12
to play-fr...@googlegroups.com
+1 I also thought about writing such a thread... Revive Play 1 and give it the attention it deserves. Play 2 is not what a Play 2 should be...

Jan De Cooman

unread,
Mar 30, 2012, 8:03:35 AM3/30/12
to play-fr...@googlegroups.com
Well, I have been using Play 1.x.x for a while now and the simplicity and speed of the framework astonished me. It seems to me that Play 2.0 has a lot of useful features but made the mistake of trying to be "the super-best framework of all times which can do everything you ever dreamed of". You cannot create a framework to satify everybody. Scala is also nice, but does it really solve major existing problems? Is it faster? No. It's a pity to see that the new features are clouded by some major (unnecessary) changes like the switch to Scala. I'd wish that some new features are back-ported to 1.x.x branch. But I agree with Roman that the Play 2.0 is "over the top". Who needs scala, what the hell is sbt? 95% of the Java-developers use Maven. Now we have to learn sbt, Scala etc. I know that a lot of programmers love to brag about all the "new" frameworks they use, but after 15 years in software development you tend to see things different. It's all very nice in theory, but out there in the wild, all those new features sucks because they slow down the development cycle and they do not solve problems which couldn't be solved before. It just make things a little bit nicer, but no customer of mine cares about that. They want that the development cycle is minimal and quality is superb. That is why I will continue to use Play 1.x.x for now and hope that the 2.0 version will be simplified again. Just extend the 1.x.x branch and really, rethink those new big changes.

I don't want to demotivate the guys behind Play, but maybe they wanted too much.... Keep the saying in mind: "he who wants everything, gets nothing" which goes for Play like "the frameworks which wants to solve all problems, doesn't solve any problem at all".

Take care
Jan


Am Freitag, 30. März 2012 08:42:36 UTC+2 schrieb Roman Bykovskiy:
Am Freitag, 30. März 2012 08:42:36 UTC+2 schrieb Roman Bykovskiy:

Guan

unread,
Mar 30, 2012, 8:13:24 AM3/30/12
to play-fr...@googlegroups.com

Agree. Actually every people falls in love with play after they use it. Java community need such a thing to escape from heavy/slow J2EE and compete with RoR/Pythons.


But, the play2 turns not to be what people expected. Before it release, everyone looking forward it,  but in turn, it shocks everyone, or at least Java developers...


Really hope there will be an evolution version of play1-java. Something like integrating good features of play2 such like akka, coffee/less assets compilation, no source code deployment. Maybe a rework of play1 core to put these cool features in, but keep it familiar as what it was...


Moreover, a concern is that, although play team guys say they are still maintain play1.2. But it obviously that it's not as active as before, people stop contributing new modules, new release slow... People hardly see a clear and healthy further of play1....


Currently play status is really confusing/misleading, and in danger... People, especially java developers love play so much! They really want it to be moving forward, as expected.

Message has been deleted

Guillaume Bort

unread,
Mar 30, 2012, 8:18:40 AM3/30/12
to play-fr...@googlegroups.com
I admit that currently the Scala compilation speed is slow. We are
aware of that, but:

- It keeps improving everyday. When we started working on Scala it was
really slower than today.
- We are working on it. Especially the guys from the Scala compiler
and SBT are making it faster every release.

Most importantly:

We are building a framework for the future, not for the past. The
choice we make today are importants; if we want to have the best Web
framework in 2 years, ready for real-time Web applications, supporting
many JVM languages, able to scale to ten of thousands of concurrent
users, we have to start now.

Just don't expect us to release in 2012 a Web framework supporting
only Java (and backward compatible with Java 1.4 because you need it),
compatible with the Servlet 2.0 API (to be able to deploy your
applications on your "enterprise servlet" container), allowing only an
old school blocking model (allowing only basic CRUD and "dynamic" web
application of the 200x) and integrating natively with Spring (because
this is the new cool thing that will kill J2EE for sure).

If you are not an early adopter, or you have another focus now, I can
understand it. No one force you to use this new version released only
2 weeks ago. Just keep using the previous Play version, waiting for
the brand new one to become more mature.

> We have to be up to date in case 1.x is not supported anymore and still has bugs

So Play 2.0 is not the version after Play 1.2.4. If you have a bug in
1.2.4 it will be fixed in 1.2.5, not in 2.0. This is a completely
different code base.

If you are worried about support for Play 1.x, you have 2 choices:

- Ask for professional services.
- Involve yourself in the community, help the developer team (that are
volunteer community members, not paid for their work) to keep fixing
issues (instead of doing noise), and at one point, ask to join the
developer team.

We are doing Play 2.0 because today our clients ask us for a new kind
of modern, real-time, social, highly-distributed, mobile, web
application, like:

http://console-demo.typesafe.com/de...@typesafe.com/apps

You can try as hard as you can, you can't do this with Play 1.x of
with the Servlet API.

So we need anew tool for this. If it's not your case (yet), then you
don't have to use Play 2.0 (yet). But be sure that the Web evolving,
and that we enter in a new era of Web applications.


On Fri, Mar 30, 2012 at 1:43 PM, tschundeee <b.ra...@gmail.com> wrote:
> +1 I also thought about writing such a thread... Revive Play 1 and give it the attention it deserves. Play 2 is not what a Play 2 should be...
>

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/E7Rwis1oZYAJ.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.


> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort

LexeY4eg

unread,
Mar 30, 2012, 8:19:55 AM3/30/12
to play-fr...@googlegroups.com
First of all, Play! is really cool, but i agree with Roman, Play 2.0 looks like step backward.

When I started to work with Play! 1.x.x it's was a lot of fun and positive emotions.
I have developed with Play 1.2.x three projects, one of it's is still in active development, and it's was really great time spent. It's was a breath of fresh air after working with hardcore Java web frameworks.

I had waited Play 2.0 like others, with big expectations. I had checked it out, and it's unsuitable for use, and i will continue to use 1.2.x.
I known it's possible to replace Scala templates with other and use Java for coding and etc. But i really don't known why Play! become slow and ineffective out of the box.

Developers, started to use Play! from version 2.0 will not like it, i guess. As a result, a Play! community will stop growing.

Anyway, i want to say thanks Play! developers team for their work, and i belive in a light future of Play!

Tom Carchrae

unread,
Mar 30, 2012, 8:44:21 AM3/30/12
to play-fr...@googlegroups.com
I'm not sure if you've heard of the three stages of invention, but Play 2.0 is a new invention.  The phases basically go "what the fuck?",  "hey, that was my idea", and "that is not innovation, it's common sense".  http://mises.org/daily/2246 - I look forward to trying Play 2.0 someday - Scala has been on my list of cool things to try for about 4 years (need coming from high performance computation).  

I'm grateful to the Play team for making their work available, and the rest of the community for contributing.  It's easy to forget that this is free and open source.  I'd like to state that, besides being fast to develop and run, I cannot tell you how much I love being able to trace through the entire server code.  Working with bugs in J2EE code involving proprietary modules sucked so hard and there is only so much help a java decompiler can give you.

I would like to see a minor evolution of Play 1.2.x as well.  Mostly, I'd like to 'de-rails' it a bit.  I know 2.0 took some steps in that direction. The main thing I don't like about 1.2.x is the 'convenient magic' that was conceived to save time, but in reality creates surprise and confusion and eats more time debugging.  

I am not clear how many are working on that team (but certainly thank you Nicholas and Morten!).  Do you guys need help?  https://play.lighthouseapp.com/projects/57987/milestones/131471-125  The best thing people can do is support the parts of the project they love.

Tom 


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/YcgYfbPq6UAJ.

Steve Chaloner

unread,
Mar 30, 2012, 8:45:33 AM3/30/12
to play-fr...@googlegroups.com
I've got projects in production using Play 1.x (including a huge one that took over a year to write - and which would have taken much longer without Play).  Do I think Play 1 is going to die? No - because lots of people, including Zenexity, have got lots of projects running on Play 1.  For them to let it die would be like shooting themselves in the foot - got this from Guillaume and Sadek directly last night.

Do I want to port those projects over to Play 2? No - because they're running perfectly well on Play 1, and are now in maintenance mode.

What will I choose for my next project?  Probably Play 2, unless the code requires deployment as a war, and this seems to be a point that a lot of people are missing.  There's nothing that can be done in Play 1 that can't be done in Play 2, and if you want, you can do it all in Java.  My Scala is still pretty much at the beginning of the learning process, but this in no way discourages me from coding with Play 2 because *I don't need to know Scala*.  For a comparison, how many people knew Groovy before they started using Play 1 Groovy templates?

Backwards compatibility is important, and that's why Play 1.2.5 (and .6 and .7 and .n) will be backwards compatible.  For Play 2 to not be able to move past what has come before would maybe win some fans in the short term, people who want to be able to drop their Play 1 projects into Play 2 without a code change, but in the mid- to long-term it would have been obsolete before it even started.

There is no Play Scala or Play Java - it's Play JVM, and that's what it always has been! 

Tom Carchrae

unread,
Mar 30, 2012, 8:47:09 AM3/30/12
to play-fr...@googlegroups.com
I am not clear how many are working on that team (but certainly thank you Nicholas and Morten!).  Do you guys need help?  https://play.lighthouseapp.com/projects/57987/milestones/131471-125  The best thing people can do is support the parts of the project they love

Peter clearly deserves a shout out too.   :)

Tom

Stephane Maldini

unread,
Mar 30, 2012, 9:12:30 AM3/30/12
to play-fr...@googlegroups.com
As a Grails committer (and Play early adopter), I must disagree with

Just don't expect us to release in 2012 a Web framework supporting
only Java (and backward compatible with Java 1.4 because you need it),
compatible with the Servlet 2.0 API (to be able to deploy your
applications on your "enterprise servlet" container), allowing only an
old school blocking model (allowing only basic CRUD and "dynamic" web
application of the 200x) and integrating natively with Spring (because
this is the new cool thing that will kill J2EE for sure).

And 

You can try as hard as you can, you can't do this with Play 1.x of
with the Servlet API.

So let's end some legends just to be clear and do not suffer from this kind of FUD (and I like both frameworks)
  • Play scales better - Play barely scales better than grails 2 in bench tests (for instance, dummy rendering test - 12k r/s for play2 vs 11k req/s for grails2) - In production , high profiles sites such as BigLot or Sky or Vodaphone are doing very well with grails and servlet API. Moreover in production environment they seem to get benefits from rich client (backbone.js, local storage) and high available caches systems (from terracota to memcached, or gemfire or so). Memory use is fair more important with a standard architecture. But ok 3Mb vs 60mn without load - I can live with that.
  • Play 2 allows better UI ? (the dynamic web interface 200x point) : I don't get how this is relevant to a server side framework. If this is about server push, well there are nice solutions around for standard architectures with Atmosphere and Servlet 3. About scalability I get your point with websocket protocol, but some java servers come with this support and Tomcat 7 next release will have it too. Anyway I'd rather prefer to get a simple websocket server communicating with the backend through Redis or similar. Lift Framework have also nice ideas on the rendering topic and still use servlet API.
  • Integrating with Spring: Ok that's a point, some don't like it. I advocate for a complete separation and get it as a plugin in Grails but anyway, it doesn't bring much drawbacks except the startup time compared to the advantages of many integrations we win.
  • Play 2 should be rebranded: Surfing on hype is cool but as a Play 1.x fan I understand the frustration with Play 2 (I'm not Scala fan and I'm not very sensible to buzzwords like Akka, there was GPars before and I don't get why I should change as its just a plain copy...). Maybe it should be called SeriousWeb or something
My 2 cents, 
Stéphane MALDINI
--


Guillaume Bort

unread,
Mar 30, 2012, 9:40:51 AM3/30/12
to play-fr...@googlegroups.com
> Play scales better - Play barely scales better than grails 2 in bench tests
> (for instance, dummy rendering test - 12k r/s for play2 vs 11k req/s for
> grails2)

Sorry I don't talk about request/seconds here, or even about raw
performance. I talk about to be able to keep 10.000 connections opened
during 20 minutes, streaming data in real time. And without consuming
10.000 threads on the JVM. The whole point of the new Play 2.0
architecture is to be able to allow that.

> Play 2 allows better UI ? (the dynamic web interface 200x point) : I don't
> get how this is relevant to a server side framework.

Again I don't argue that Play allows for better UI. But that a new
kind of Web application (with Streams, WebSocket, Real-time
notification, etc.) are this new kind of Web applications.

> Play 2 should be rebranded

I know, Java itself is backward compatible, even if they rebranded
Java 1.5, 1.6, 1.7, to Java 5, Java 6, etc to let people think that
there are major versions of Java.

But for me a major version is a major version. Each project manages it
versioning its own way. We chosen this versioning (Calling Play 2 the
next generation of the Play framework) like for example Symfony 2
(which is the next generation of the Symfony Web framework not
backward compatible with Symfony 1), and not like Grails 2 (which is
just Grails 1 plus new features, so of course, backward compatible).

--
Guillaume Bort

Stephane Maldini

unread,
Mar 30, 2012, 10:24:57 AM3/30/12
to play-fr...@googlegroups.com
On Fri, Mar 30, 2012 at 3:40 PM, Guillaume Bort <guillau...@gmail.com> wrote:
> Play scales better - Play barely scales better than grails 2 in bench tests
> (for instance, dummy rendering test - 12k r/s for play2 vs 11k req/s for
> grails2)

Sorry I don't talk about request/seconds here, or even about raw
performance. I talk about to be able to keep 10.000 connections opened
during 20 minutes, streaming data in real time. And without consuming
10.000 threads on the JVM. The whole point of the new Play 2.0
architecture is to be able to allow that.

That's the point of continuations, suspending requests etc. But ok I get your point on the fact that by the end it would be more scalable at least because of the protocol and memory use (depending of the architecture). I agree that Netty has nice success in handling requests and I'm deeply interested into that too but the same goal can be more or less with way more technics. 
 

> Play 2 allows better UI ? (the dynamic web interface 200x point) : I don't
> get how this is relevant to a server side framework.

Again I don't argue that Play allows for better UI. But that a new
kind of Web application (with Streams, WebSocket, Real-time
notification, etc.) are this new kind of Web applications.

I do server side pushed apps with Atmosphere or DWR and older technics for some years now, interactive pages didn't wait for websocket nor server side events to exist. You didn't quote the following part where I explained that the same thing can be achieved in Servlet API. Anyway, I must confess that for the moment, even if I'm a ServerPush enthusiast, this kind of use case is pretty niche (lol @ chat demos, real stockwatch etc). At least I can understand the parallel rendering patterns, or pushed streamed contents. 

> Play 2 should be rebranded

I know, Java itself is backward compatible, even if they rebranded
Java 1.5, 1.6, 1.7, to Java 5, Java 6, etc to let people think that
there are major versions of Java.

But for me a major version is a major version. Each project manages it
versioning its own way. We chosen this versioning (Calling Play 2 the
next generation of the Play framework) like for example Symfony 2
(which is the next generation of the Symfony Web framework not
backward compatible with Symfony 1), and not like Grails 2 (which is
just Grails 1 plus new features, so of course, backward compatible).

Grails 2 is different in many points but I won't debate about that. As a mature framework used in critical projects we couldn't just cut off backward compatibilities. If architecture is widely reviewed in Grails 3, we will at least try to maintain this by providing core plugins set, I guess that is also a SpringSource wish.  Ok we loose some hype mindshare, but we provide good productivity tools for standard architectures and we don't keep spitting on NIO/Scala/Play friends because they do not embrace what we do. If I reacted to this post, this is because I'm tired of implicit or explicit servlet api bashing, like and also NIO vs BIO, Groovy dynamic typing or grails bashing coming from Scala or Play people. I personally like both frameworks (with a preference to grails but this is certainly due to the groovy and spring adoption under the hood). I just want to stop people bitching on our community :) I love you all and you are doing something nice (cocorico), so keep on the good work and don't leave your community with such counter productive answers.

Cheers,



--
Stéphane MALDINI
--


Роман

unread,
Mar 30, 2012, 10:29:20 AM3/30/12
to play-fr...@googlegroups.com
Choosing this name you mislead people. Look how many astonished and
disappointed there are.
Everyboy considers this to be an update instead of brand-new product
In my opinion you should set the case clear and rename 1x into
PlayLite for instance - it looks illogical that in spite of the fact
that there exists the 2.0 version you are about to release the 1.5.
You create outstanding products, let's make them look transparent to
everyone! Seriosly

30 марта 2012 г. 17:40 пользователь Guillaume Bort
<guillau...@gmail.com> написал:

peter hausel

unread,
Mar 30, 2012, 10:56:25 AM3/30/12
to play-fr...@googlegroups.com
 
 Hi Roman,

A few things here. Template compilation while slow, it still means your templates are compiled (while providing template inheritance, tags etc.). The groovy templates in 1.x represented a different trade-off. You sacrifice type safety and runtime speed for development speed. I'd choose the first combo any day. That said: compilation speed will only get better (there are many things happening in this area) and you are not forced to use the built in templates. 

 
One big lie

"The Play framework makes it easier to build web applications with Java & Scala."
The truth would be: "The Play framework makes it easier to build web applications with Scala, but if you want to use Java.... then, well ok May The Force be with you!"
I'll speak about that later.

I am not sure what you are referring here. You do not need to write a single line of scala if you do not want to. 
 
Scala

I am a Java developer. Why must I study Scala to make an elementary template? That is just a template! A means of formating an information output. That is fantastic that it can be compiled. But what do I need it for? If I spend a great deal of time on elaboration, especially on waiting.

that's true for most template languages, including the groovy-based version in play 1. No news here.
 
 
To fulfill the simpliest things I have to adress Google groups because there is no information.
I cannot set a variable in the template to use 
it later in the cycle.
What for do I need this sort of template engine that I have to “overcome”: 

[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:156: '(' expected but ')' found.
[error]                                                                                                 """),_display_(Seq(/*123.14*/for)),format.raw/*123.17*/(""" ((sector,i) <-subevent.sectors.zipWithIndex) """),format.raw("""{"""),format.raw/*123.64*/("""
[error]                                                                                                                                 ^
[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:421: illegal start of simple expression
[error] """)))})),format.raw/*388.2*/("""
[error]       ^
[error] two errors found


Eh? Where should I look for a mistake in this output? Please don't say that in line 156...
How THIS can help me to find out what has happenedAnd it was just an extra space character.

Yeah, the scala template error reporting can be tough to read sometimes. We are aware and working on making it better.
You could help us by reporting these issues (with template snippets) in the issue tracker.

 


Porting

That is great that you believe that Scala is the thing of the future ( while I doubt that with this compilation speed you mean the nearest future, but ok). Do add but don't substitute! You consider Ebean better than Hibernate – leave the choice to the ones who are used to it! 
 
There is nothing stopping you from using hibernate. See this example: https://github.com/playframework/Play20/tree/master/samples/java/computer-database-jpa
 
Try opening a restaurant in Japan. Substitute sticks with forks ( because there exists a wide-spread opinion that forks are more progressive than sticks) and look if it works out.

B
ackward compatibility always was a basis of Java, that is why it was developing slowly, though there were no problems with launching old projects in new versions.

You have removed war creating – how should I deploy it on tomcat.
You have added 
processing of text output through org.apache.commons.lang.StringEscapeUtils.escapeHtml(text). Oh, that is nice! But it crumples all the text turning it into &#1057;&#1099;&#1085;&#1086;&#1074;&#1100;&#1103;
to turn it off I have to edit Templates.scala and somehow recompile (taking into account that I have no idea how it should be done manually). After a Play framewok version update – I will have to do it again.


Guillaume already talked about versioning and why war support is not as trivial as it may appear. 

Conclusion

Now Play is a 
pain in the neck ! If in the beginning it was a very simple and very fast framework, now it has become just one of many.
You will probably attract Scala fans, but you will lose Java developers, because it is just impossible to avoid working with Scala while creating a product on Play.

Maybe Scala is not that bad, but I am a Java developer and can study another language only when I have time. But now I must do what I am to do, by the use of the means I know, and the knowledge of which was announced b
y framework developers.

To summarize:
1) you do not need to learn or use scala if you do not want to. 
2) The templating solution is optional. The amount of specific knowledge you need to acquire is about the same as with groovy or haml or dust or mustache etc. 
3) There are fewer assumptions in Play 2 about your stack and you can just stop using API-s if you do not need/like some
4) play 2's major selling points in my view: 
* less magic
* designed  to be flexible and extensible. You can plugin and use any framework you like
* standard (can be embedded into other apps, published as maven artifact etc.)
* dev console improvements (assets compilation, extensible built tool)
* more type safety (routes and template compilation)
* async goodies (akka, websockets, streaming, comet etc.)
* java and scala lang support
5) that said, play 2 represents a different trade-off than Play 1. Play 1 is not going anywhere. Feel free to choose the one that suits your needs

Hope this helps.

Thanks,
Peter
 
 
P.P.P.S If this idea of Scala belongs to the man who has made the website acid green than it is him who is the root of evil!) Get rid of him!)
 
You are entitled to your opinions but please keep the discussion on topic and constructive. (Insulting people won't take you anywhere)

Serkan Durusoy

unread,
Mar 30, 2012, 12:03:53 PM3/30/12
to play-fr...@googlegroups.com
Although I find the "sound" of this post to be "ranting", I do agree with core, which I grasp as:
  • Although Play 2 is definitely a move forward, it is moving in a different lane then Play 1 did
  • Play 1 was appealing to many users because of the simplicity that it provided to "Java" developers
    • Not having to repeat hundreds of lines of platform (framework, library, package etc) specific code just to define an entity and consume it
    • Sending an email, storing a binary in db, or validating form field etc with a single line of code
    • Not having to wait for a build
    • Overall, concentrate on developing the business logic of the app rather then the technical implementation of some library
  • Scala is very exciting, but it is not necessarily "the future" for everyone
  • Since Play 2 is named as "2", although there have been announcements that Play 1 will receive continued support and releases, it "sounds" like newcomers should start off with Play 2
Well, Play 1 was superior to existing frameworks in some ways and Play 2 is superior to existing frameworks in other ways.
 
The concept of superiority and productivity may be different for everyone.
 
I also do understand that there is a company behind Play! and the core target of a company is to gain earnings and profit. The company (Zenexity) has vetted to align with Typesafe and henceforth go Scala. Kudos to both companies, I believe this business move holds a seriously fruitful (not for those two companies, but for the community as well) future.
 
But (there always is a but);
 
Play 2 > Play 1 is not true. Play 2 <> Play 1 is. 1 and 2 are just different.
 
There are a lot of developers out there in the community who have invested largely in Play 1 and would like to keep on that branch and hope continued development on it.
 
At this point, what Zenexity may (hopefully) opt to do is one or more of:
  • Publish a development plan for 1.x branch (including date and content/coverage)
    • Is it going to be maintenance only
    • Or is it going to see new features
    • Or at least, are any of the features going to be improved (apart from bugfixes)
  • Publish a migration guide from 1 to 2
  • Carry out a community survey to better understand
    • Why (for which features) and/or why not developers choose Play 1
    • Why (for which features) and/or why not developers choose Play 2
    • Why and/or why not developers migrate from Play 1 to Play 2
    • What do the developers want to see in Play 1
    • What do the developers want to see in Play 2
  • Perhaps rename Play 1 as suggested by some community members
  • Perhaps consider a community reorganization for Play 1 and its future (I think Canonical and its strategy on Ubuntu is a great example) and where Zenexity is positioned in this community to
    • Improve on most vetted properties on Play 1
    • Develop new functionality that are most requested in Play 1
    • Drop some Play 1 functionality that are not that much required (or perhaps at least lower their priorities to make room for higher priority assets)
I have specific answers for some of those questions I've presented above, but I also believe that my answers are relevant solely to my situation as for everyone's may be different.
 
All in all, let me briefly present my specific case to end this rather long reply.
 
About a month ago, we have decided to use Play 1 (which we have been reading and catching up on for quite a long time now) and just fell in love with it for our specific use case. We were looking up to a 8-10 month long development project with it, with more to come depending on enhancement requests.
 
For the past two weeks (after the launch of Play 2) we've been baffled by the rather uncertain future of Play 1 and the almost completely different nature of Play 2. Now we're trying to make the decision to throw away that past 1 month and go back to our good old friend JPA2+Spring3+JSF2. And mind you, we are paying support customers of the developers of many open source projects. So I'm not ranting about losing a beloved "free as in beer" framework. Our decisions are purely technical in the sence of productivity within a business grade toolset.
 
This is my 2 (or perhaps 3, 4, 5 ...) cents on this topic. I'd love to see Play 1 supported, not just in the sence of maintenance, but enhancements as well.

Eric

unread,
Mar 30, 2012, 12:06:11 PM3/30/12
to play-fr...@googlegroups.com
I'm so sorry to agree with this open letter. But I can understand both pros and cons opinions even if I don't accept the "If you are not happy with the new, stick with the old one".
 
 
Play 1.x.x was so exciting and refreshing.
Play 2.0 is currently a pain because of very slow compilation and cryptics debug messages.
 
The danger is believing Play! is the only initiative to build the "megabest framework for next millenary". All competitors are open sourced, all competitors have good ideas. But the one gathering the most developers will win this battle. And Play 2.0 is losing the Java developers, who are a very big batallion.
 
You said it will be the best framework in 2 years. Who knows ? Who can wait this long ? If this slowness is not nominal, why Play 2.0 is a release version and not beta ?
 
I can stick with Play 1.x.x but as you said, you are not backed by a big company and nothing can guarantee that this will be maintained as efficiently as the Scala stack version. This is already not the case.
 
Play 1.x.x made me create my little self-enterprise and find clients easily with short delays promises and easy maintenance. Play 2.0 made me ... evaluate Stripes, Wicket, JSF2 and a guitarist career too.
 
And I'm extremely sorry. As much as I was extremely enthousiatic at first. This is early adopter's life story. :)
 
 
Le vendredi 30 mars 2012 08:42:36 UTC+2, Roman Bykovskiy a écrit :
Dear friends!


One small truth

Scala sucks. Well, the language might be considered quite good but the fact that compilation really takes a lot of time is indisputable.
Up to 13sec! And that's after slight changes made to the template (!)
Having allocated myself a separate server especially for compilation, I managed to increase the speed to 5 sec – 
butstill it remains a lot. We've tried it on different platforms.

One big lie

"The Play framework makes it easier to build web applications with Java & Scala."
The truth would be: "The Play framework makes it easier to build web applications with Scala, but if you want to use Java.... then, well ok May The Force be with you!"
I'll speak about that later.


My story

When I read about Play framework for the first time, I entered the website and watched the video about the 1.
x. version. Oh my God! This is it! - I thought. I've installed it, repeated everything according to the example on the video,and quickly applying documentation outlined a copy of the project that I'm working on.
A whole month I tried to convince my boss of using Play Framework in new projects, because it was much better than what we were using. And I did it. But you have played a trick – changed everything 
radically.

Now when we are realising a new pro
ject using Play framework 2, my colleagues give be black looks, but I can't make any excuses– explain that it is not what it used to be, that I cannot help them when I don't know the way it works.


Quick elaboration

What I liked in Play 1.x 
was the speed. Not the work speed (now everybody has it up-to-date), but the elaboration speed. Everything is quick and simple. In the 2.0 it's a torture. 
Resistance to the current circumstances, efforts to find the way of doing what used to be done easily and in several modes.

Scala

I am a Java developer. Why must I study Scala to make an elementary template? That is just a template! A means of formating an information output. That is fantastic that 
it can be compiled. But what do I need it for? If I spend a great deal of time on elaboration, especially on waiting.

Maybe in America you compile Scala code, but here in Russia Scala code compile you. 
It hurts!

To 
fulfill the simpliest things I have to adress Google groups because there is no information.

I cannot set a variable in the template to use 
it later in the cycle.
What for do I need this sort of template engine that I have to “overcome”: 

[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:156: '(' expected but ')' found.
[error]                                                                                                 """),_display_(Seq(/*123.14*/for)),format.raw/*123.17*/(""" ((sector,i) <-subevent.sectors.zipWithIndex) """),format.raw("""{"""),format.raw/*123.64*/("""
[error]                                                                                                                                 ^
[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:421: illegal start of simple expression
[error] """)))})),format.raw/*388.2*/("""
[error]       ^
[error] two errors found

Eh? Where should I look for a mistake in this output? Please don't say that in line 156...
How THIS can help me to find out what has happenedAnd it was just an extra space character.

What about data transfer to the template?

Before I could transfer all the data to the template by use of @Before, for example menu that I have on every page. '
Now I have to transfer menu data in every template call, and in each of them I should pass it through the base one. That's nonsense!

Porting

That is great that you believe that Scala is the thing of the future ( while I doubt that with this compilation speed you mean the nearest future, but ok). Do add but don't substitute! You consider Ebean better than Hibernate – leave the choice to the ones who are used to it!

Try opening a restaurant in Japan. Substitute sticks with forks ( because there exists a wide-spread opinion that forks are more progressive than sticks) and look if it works out.

B
ackward compatibility always was a basis of Java, that is why it was developing slowly, though there were no problems with launching old projects in new versions.


You have removed war creating – how should I deploy it on tomcat.
You have added 
processing of text output through org.apache.commons.lang.StringEscapeUtils.escapeHtml(text). Oh, that is nice! But it crumples all the text turning it into &#1057;&#1099;&#1085;&#1086;&#1074;&#1100;&#1103;
to turn it off I have to edit Templates.scala and somehow recompile (taking into account that I have no idea how it should be done manually). After a Play framewok version update – I will have to do it again.


Conclusion

Now Play is a 
pain in the neck ! If in the beginning it was a very simple and very fast framework, now it has become just one of many.
You will probably attract Scala fans, but you will lose Java developers, because it is just impossible to avoid working with Scala while creating a product on Play.

Maybe Scala is not that bad, but I am a Java developer and can study another language only when I have time. But now I must do what I am to do, by the use of the means I know, and the knowledge of which was announced b
y framework developers.

p.s. Remember 
Apple's goal which is “to create simple objects”. The user was deprived of everything unnecessary. It is true that he was bereft of some frills, but as it turned out to be a golden mean. Moreover he still can do everything he wants but at the same time an ordinary user is not distracted with all that additional stuff. 

p.p.s. Return ok (…) are you serious? If I'm ready to return something to the user it is already ok! Otherwise I throw exception.

P.P.P.S If this idea of Scala belongs to the man who has made the website acid green than it is him who is the root of evil!) Get rid of him!)

Le vendredi 30 mars 2012 08:42:36 UTC+2, Roman Bykovskiy a écrit :
Dear friends!


One small truth

Scala sucks. Well, the language might be considered quite good but the fact that compilation really takes a lot of time is indisputable.
Up to 13sec! And that's after slight changes made to the template (!)
Having allocated myself a separate server especially for compilation, I managed to increase the speed to 5 sec – 
butstill it remains a lot. We've tried it on different platforms.

One big lie

"The Play framework makes it easier to build web applications with Java & Scala."
The truth would be: "The Play framework makes it easier to build web applications with Scala, but if you want to use Java.... then, well ok May The Force be with you!"
I'll speak about that later.


My story

When I read about Play framework for the first time, I entered the website and watched the video about the 1.
x. version. Oh my God! This is it! - I thought. I've installed it, repeated everything according to the example on the video,and quickly applying documentation outlined a copy of the project that I'm working on.
A whole month I tried to convince my boss of using Play Framework in new projects, because it was much better than what we were using. And I did it. But you have played a trick – changed everything 
radically.

Now when we are realising a new pro
ject using Play framework 2, my colleagues give be black looks, but I can't make any excuses– explain that it is not what it used to be, that I cannot help them when I don't know the way it works.


Quick elaboration

What I liked in Play 1.x 
was the speed. Not the work speed (now everybody has it up-to-date), but the elaboration speed. Everything is quick and simple. In the 2.0 it's a torture. 
Resistance to the current circumstances, efforts to find the way of doing what used to be done easily and in several modes.

Scala

I am a Java developer. Why must I study Scala to make an elementary template? That is just a template! A means of formating an information output. That is fantastic that 
it can be compiled. But what do I need it for? If I spend a great deal of time on elaboration, especially on waiting.

Maybe in America you compile Scala code, but here in Russia Scala code compile you. 
It hurts!

To 
fulfill the simpliest things I have to adress Google groups because there is no information.

I cannot set a variable in the template to use 
it later in the cycle.
What for do I need this sort of template engine that I have to “overcome”: 

[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:156: '(' expected but ')' found.
[error]                                                                                                 """),_display_(Seq(/*123.14*/for)),format.raw/*123.17*/(""" ((sector,i) <-subevent.sectors.zipWithIndex) """),format.raw("""{"""),format.raw/*123.64*/("""
[error]                                                                                                                                 ^
[error] /home/romka/projects/ponominalu/target/scala-2.9.1/src_managed/main/views/html/event.template.scala:421: illegal start of simple expression
[error] """)))})),format.raw/*388.2*/("""
[error]       ^
[error] two errors found

Eh? Where should I look for a mistake in this output? Please don't say that in line 156...
How THIS can help me to find out what has happenedAnd it was just an extra space character.

What about data transfer to the template?

Before I could transfer all the data to the template by use of @Before, for example menu that I have on every page. '
Now I have to transfer menu data in every template call, and in each of them I should pass it through the base one. That's nonsense!

Porting

That is great that you believe that Scala is the thing of the future ( while I doubt that with this compilation speed you mean the nearest future, but ok). Do add but don't substitute! You consider Ebean better than Hibernate – leave the choice to the ones who are used to it!

Try opening a restaurant in Japan. Substitute sticks with forks ( because there exists a wide-spread opinion that forks are more progressive than sticks) and look if it works out.

B
ackward compatibility always was a basis of Java, that is why it was developing slowly, though there were no problems with launching old projects in new versions.


You have removed war creating – how should I deploy it on tomcat.
You have added 
processing of text output through org.apache.commons.lang.StringEscapeUtils.escapeHtml(text). Oh, that is nice! But it crumples all the text turning it into &#1057;&#1099;&#1085;&#1086;&#1074;&#1100;&#1103;
to turn it off I have to edit Templates.scala and somehow recompile (taking into account that I have no idea how it should be done manually). After a Play framewok version update – I will have to do it again.


Conclusion

Now Play is a 
pain in the neck ! If in the beginning it was a very simple and very fast framework, now it has become just one of many.
You will probably attract Scala fans, but you will lose Java developers, because it is just impossible to avoid working with Scala while creating a product on Play.

Maybe Scala is not that bad, but I am a Java developer and can study another language only when I have time. But now I must do what I am to do, by the use of the means I know, and the knowledge of which was announced b
y framework developers.

p.s. Remember 
Apple's goal which is “to create simple objects”. The user was deprived of everything unnecessary. It is true that he was bereft of some frills, but as it turned out to be a golden mean. Moreover he still can do everything he wants but at the same time an ordinary user is not distracted with all that additional stuff. 

p.p.s. Return ok (…) are you serious? If I'm ready to return something to the user it is already ok! Otherwise I throw exception.

grandfatha

unread,
Mar 30, 2012, 12:06:47 PM3/30/12
to play-fr...@googlegroups.com
On Friday, March 30, 2012 4:56:25 PM UTC+2, peter hausel wrote:
 
You sacrifice type safety and runtime speed for development speed. I'd choose the first combo any day.


A lot of people feel different about that. Unless tested, compiled does not add much benefit besides proving correct use of syntax. You still have to test whether it does the right thing. This continuous process of validation is harmed by the lack of development speed. The success of product engineering is based on a free flow of ideas which requires very short feedback cycles.

Not having that will harm a typical project much much more than a lack of performance, which it wont need most of the time as not everything operates at web-scale.

If a feedback-loop of 10 second recompile cycles were acceptable for me (lots of others also), I d still work with Servlet-based frameworks.

 
That said: compilation speed will only get better (there are many things happening in this area)

Really? I have heard that for many years now and it still has to materialize.
 

aymer

unread,
Mar 30, 2012, 12:09:11 PM3/30/12
to play-framework, peter hausel
The play developers really deserves to be appreciated for the work
they have done for Play in general.

We are bunch of developers in a start-up with multiple projects
running (In Both Java and Python). Two of our projects are using Play
1.2.3 version. For our latest project, we were trying to use Play 2.0.
But after playing around with, we had to give up and decided to use
Flask framework. Slow compilation, Obscure error reporting, Learning
SBT (Its really bad), Difficulty in getting Scala resources all gave
us hard time.

But since the project we chose to try out was not that big, we are
happy with Flask. But missing static typing.

As many of already pointed out, Play2 should have used some other
name, leaving Play 1.x to flourish.

I believe it was a mistake they mixed Java and Scala together. Not
everyone is willing to learn Scala, and which makes it impossible to
attract more contribution to the core.

Java is not a bad language after-all. It is here to stay, Oracle even
laid out plan for even Java 10 (2017). It is much simpler to get
things done than Scala. Scala is difficult and those ASCII arts makes
people run away. One should not *fight" with a language to get
something done, they have much bigger/difficult problem to solve.

There are some awesome language coming up/gaining momentum, such as
go, which is very fast in both compilation and runtime yet simple.

Although Play devs keep saying they support 1.x for a long, knowing
the fact that it will NOT grow to 2.x, it turning Java devs away (or
failing to attract more people)

Thanks
Aym






On Mar 30, 10:56 pm, peter hausel <peter....@gmail.com> wrote:
>  Hi Roman,
>
> A few things here. Template compilation while slow, it still means your
> templates are compiled (while providing template inheritance, tags etc.).
> The groovy templates in 1.x represented a different trade-off. You
> sacrifice type safety and runtime speed for development speed. I'd choose
> the first combo any day. That said: compilation speed will only get better
> (there are many things happening in this area) and you are not forced to
> use the built in templates.
>
> > *One big lie*
>
> > *"The Play framework makes it easier to build web applications with Java
> > & Scala."*
> > The truth would be: *"The Play framework makes it easier to build web
> > applications with Scala, but if you want to use Java.... then, well ok **May
> > The Force be with you!"*
> > I'll speak about that later.
>
> > I am not sure what you are referring here. You do not need to write a
>
> single line of scala if you do not want to.
>
> > *Scala*
> > *Porting*
> > That is great that you believe that Scala is the thing of the future (
> > while I doubt that with this compilation speed you mean the nearest future,
> > but ok). Do add but don't substitute! You consider Ebean better than
> > Hibernate – leave the choice to the ones who are used to it!
>
> There is nothing stopping you from using hibernate. See this example:https://github.com/playframework/Play20/tree/master/samples/java/comp...
>
>
>
>
>
>
>
>
>
> > Try opening a restaurant in Japan. Substitute sticks with forks ( because
> > there exists a wide-spread opinion that forks are more progressive than
> > sticks) and look if it works out.
>
> > Backward compatibility always was a basis of Java, that is why it was
> > developing slowly, though there were no problems with launching old
> > projects in new versions.
>
> > You have removed war creating – how should I deploy it on tomcat.
> > You have added processing of text output through
> > org.apache.commons.lang.StringEscapeUtils.escapeHtml(text*). *Oh, that is
> > nice! But it crumples all the text turning it into
> > &#1057;&#1099;&#1085;&#1086;&#1074;&#1100;&#1103;
> > to turn it off I have to edit Templates.scala and somehow recompile
> > (taking into account that I have no idea how it should be done manually).
> > After a Play framewok version update – I will have to do it again.
>
> > Guillaume already talked about versioning and why war support is not as
>
> trivial as it may appear.
>
> *Conclusion*
>
> > Now Play is a pain in the neck ! If in the beginning it was a very simple
> > and very fast framework, now it has become just one of many.
> > You will probably attract Scala fans, but you will lose Java developers,
> > because it is just impossible to avoid working with Scala while creating a
> > product on Play.
>
> > Maybe Scala is not that bad, but I am a Java developer and can study
> > another language only when I have time. But now I must do what I am to do,
> > by the use of the means I know, and the knowledge of which was announced b
> > y framework developers.

peter hausel

unread,
Mar 30, 2012, 12:18:20 PM3/30/12
to play-fr...@googlegroups.com, peter hausel
For our latest project, we were trying to use Play 2.0.
But after playing around with, we had to give up and decided to use
Flask framework. Slow compilation, Obscure error reporting, Learning
SBT (Its really bad), Difficulty in getting Scala resources all gave
us hard time.

Can you please elaborate on this? Obscure error reporting where? learning play version of SBT is hard how?

Java is not a bad language after-all. It is here to stay, Oracle even
laid out plan for even Java 10 (2017).
 
We love Java as well as Scala.  That's why both of them are first class citizens.

It is much simpler to get
things done than Scala. Scala is difficult and those ASCII arts makes
people run away. One should not *fight" with a language to get
something done, they have much bigger/difficult problem to solve.

You do not have to write a single line of scala if you do not want to.
 

peter hausel

unread,
Mar 30, 2012, 12:31:31 PM3/30/12
to play-fr...@googlegroups.com


On Friday, March 30, 2012 12:06:47 PM UTC-4, grandfatha wrote:
On Friday, March 30, 2012 4:56:25 PM UTC+2, peter hausel wrote:
 
You sacrifice type safety and runtime speed for development speed. I'd choose the first combo any day.


A lot of people feel different about that. Unless tested, compiled does not add much benefit besides proving correct use of syntax. You still have to test whether it does the right thing. This continuous process of validation is harmed by the lack of development speed. The success of product engineering is based on a free flow of ideas which requires very short feedback cycles.

Not having that will harm a typical project much much more than a lack of performance, which it wont need most of the time as not everything operates at web-scale.
  
If a feedback-loop of 10 second recompile cycles were acceptable for me (lots of others also), I d still work with Servlet-based frameworks.

if you do not value type safety or runtime performance as high as development speed, that's a perfectly acceptable choice.
There is nothing special about the scala templating solution, though, it's just a library, you can plugin anything you like. Folks even back-ported the groovy lib from play 1: https://github.com/playframework/Play20/wiki/Modules but anything else should work without a problem.

 
 
That said: compilation speed will only get better (there are many things happening in this area)

Really? I have heard that for many years now and it still has to materialize.
 
The company behind scala is very young, so please give us a chance. I can assure you that work is being done in this area.

Роман

unread,
Mar 30, 2012, 12:32:27 PM3/30/12
to play-fr...@googlegroups.com
> I am not sure what you are referring here. You do not need to write a single line of scala if you do not want to.

How? It goes from the box with only scala templates support. It's nice
to now how to install groovy (without any knowlege of scala)

> To summarize:
> 1) you do not need to learn or use scala if you do not want to.

For now - I can't. If you can explain me how to do this - it would be
great. Or better - add some scala-free stuff (like Groovy) to future
issues

> 2) The templating solution is optional. The amount of specific knowledge you
> need to acquire is about the same as with groovy or haml or dust or mustache
> etc.

It's not. There is everything is simple. For example to make counter
in loop takes >1 hour for me ..

> 3) There are fewer assumptions in Play 2 about your stack and you can just
> stop using API-s if you do not need/like some

I do not criticize. I'm just pointing at what you probably you can't see.
You started making a motorcycle, and then you made a car. Yes, it has
a roof and a stove, but we fell in love with Play because we wanted a
fast and easy ride instead of comfort traffic-time spending.

> * more type safety (routes and template compilation)
> * async goodies (akka, websockets, streaming, comet etc.)

it's really good!! But not enough documentation and examples for Java

>> P.P.P.S If this idea of Scala belongs to the man who has made the website
>> acid green than it is him who is the root of evil!) Get rid of him!)
>
> You are entitled to your opinions but please keep the discussion on topic
> and constructive. (Insulting people won't take you anywhere)

It was a joke to defuse the tension.

peter hausel

unread,
Mar 30, 2012, 12:36:11 PM3/30/12
to play-fr...@googlegroups.com

 
Play 2 > Play 1 is not true. Play 2 <> Play 1 is. 1 and 2 are just different.
 
There are a lot of developers out there in the community who have invested largely in Play 1 and would like to keep on that branch and hope continued development on it.
 

Play 1 is entirely community driven. If you care about the project, then please participate! It's open source after all.

Cheers,
Peter 

peter hausel

unread,
Mar 30, 2012, 12:41:18 PM3/30/12
to play-fr...@googlegroups.com


On Friday, March 30, 2012 12:32:27 PM UTC-4, Roman Bykovskiy wrote:
> I am not sure what you are referring here. You do not need to write a single line of scala if you do not want to.

How? It goes from the box with only scala templates support. It's nice
to now how to install groovy (without any knowlege of scala)

 

> To summarize:
> 1) you do not need to learn or use scala if you do not want to.

For now - I can't. If you can explain me how to do this - it would be
great. Or better - add some scala-free stuff (like Groovy) to future
issues

There are two groovy template solutions already available(please see above). But you can use freemarker, velocity etc. without any issue.
 

> 2) The templating solution is optional. The amount of specific knowledge you
> need to acquire is about the same as with groovy or haml or dust or mustache
> etc.

It's not. There is everything is simple. For example to make counter
in loop takes >1 hour for me ..

What I meant was that you do not have to use the scala templating solution if you do not want to.
 

> 3) There are fewer assumptions in Play 2 about your stack and you can just
> stop using API-s if you do not need/like some

I do not criticize. I'm just pointing at what you probably you can't see.
You started making a motorcycle, and then you made a car.  Yes, it has
a roof and a stove, but we fell in love with Play because we wanted a
fast and easy ride instead of comfort traffic-time spending.

> * more type safety (routes and template compilation)
> * async goodies (akka, websockets, streaming, comet etc.)

it's really good!! But not enough documentation and examples for Java

Please help us to make it better. The wiki is freely editable! 

>> P.P.P.S If this idea of Scala belongs to the man who has made the website
>> acid green than it is him who is the root of evil!) Get rid of him!)
>
> You are entitled to your opinions but please keep the discussion on topic
> and constructive. (Insulting people won't take you anywhere)

It was a joke to defuse the tension.

 Sorry, I was not sure.

peter hausel

unread,
Mar 30, 2012, 1:02:37 PM3/30/12
to play-fr...@googlegroups.com

 
I can stick with Play 1.x.x but as you said, you are not backed by a big company and nothing can guarantee that this will be maintained as efficiently as the Scala stack version. This is already not the case.
 
Play 1.x.x made me create my little self-enterprise and find clients easily with short delays promises and easy maintenance. Play 2.0 made me ... evaluate Stripes, Wicket, JSF2 and a guitarist career too.
 
Play 1 is entirely community driven, if you like the project and have concerns, please help us to make it better (report issues, fix documentation, send pull requests etc.). It's open source, guys!

Serkan Durusoy [DNA | encoding the future]

unread,
Mar 30, 2012, 1:46:55 PM3/30/12
to play-fr...@googlegroups.com
Hello Peter,

> Play 1 is entirely community driven. If you care about the project, then please participate! It's open source after all.

I agree, and it is my full intent, but you see, there are different levels of participation to a community driven project. One of them being a paid customer of the company who is the lead of that community driven project (I've actually pointed this out in my original reply).

But in order to be able to do that, I believe it is perfectly reasonable to expect a Play 1.x branch roadmap. Play 1.x currently looks like the predecessor of Play 2 rather than a branch on its own, and feels like it may soon be the "old" thing. Why would I invest in that if Zenexity is already diverging most of its development assets towards the 2.x branch?

But again in my original reply, I've referred to an option for Zenexity to clearly redefining the community structure for Play 1.x. In such a case, it will truly become a community project. Currently it feels more like an open sourced project rather than one that is embraced by the community. (Yes it is embraced as usage, but does not seemly like it in the development area, other than few contributers) If I missed something with this regard, please let me (and everybody else) know.

Thanks & regards,
Serkan


peter hausel

unread,
Mar 30, 2012, 2:28:59 PM3/30/12
to play-fr...@googlegroups.com
That's a good point, Serkan

My understanding from Guillaume is that he is ready to open up the 1.X branch to the wider community. We will just need to organize that (expect some more details next week). Also, ideas are welcome! 

Ben McCann

unread,
Mar 30, 2012, 3:03:38 PM3/30/12
to play-fr...@googlegroups.com
The fact that this thread is so active, speaks to the fact that people care about Play.  I think that's a great testament to what the core developers have built.  If no one cared, then there would be no noise.  There are some valid concerns on this thread.  Let's turn the complaints into beneficial action.  I would guess that some of these problems are solvable if we share our knowledge with each other and work together to change the things we don't like.

I disagree with many of the premises in the original thread, but the one thing I whole heartedly agree with is that the Scala compilation times are abysmal.  This is by far the worst part of Play 2 and has made me consider migrating away from it many times.

We should not care what language the framework itself is written in as long as it is still easy to code in Java with it.  I think the Play developers have done a very good job at supporting Java.  I've only come across a few small issues where Java support did not match Scala, and they were fixed when reported.  The only outstanding issue I've encountered is that the OAuth lib only supports Scala, but that bug in Lighthouse has been marked as "Accepted", and I fully believe that it will be addressed given that all other issues related to Java compatibility I've seen have been addressed.

Using Scala in the templates would not be a big deal for me as a Java developer if it weren't for the horrible compilation times.  You shouldn't be putting much logic in your templates anyway, so I rarely do much beyond putting an @ symbol in front of my variable names.  I really love the type safety that they give you.  But having the increased compilation times is a huge pain to deal with.  However, there are other templating systems that do not use Scala.  I've been meaning to take a look at tehm and you may be interested to do so too.  I'm hoping if I get rid of all of my Scala templates my project will stop taking 100x as long to do an incremental compile as my typical Java web apps do.  We as a community should investigate fixes like this.  Has anyone had experience using the Groovy, Japid, or client-side templates?  Do they improve compilation times?  It seems if we just make this one layer swappable and document that then Play 2 is awesome again.  People who want to use Scala templates still can and the rest of us get fast compilation back.

I'm happy Play 2 broke backwards compatibility.  This is needed for true progress.  Play 1.x is still being maintained and you can certainly continue to use it if you do not want to migrate.  A migration guide would help solve many of the complaints I believe.  If anyone has migrated, I encourage you to start a migration guide on the wiki to help those that come after you.  Again, let's take some of these complaints to make the world a better place.  Yes, Play 2 does not have all the features of Play 1.  These will come with time.  I've been using Play 2 since long before the beta release and can tell you lots of progress is being made.  Features do not happen overnight.  If you require these features you can help to develop them!  Or alternatively, you can stay on Play 1 until they are included in Play 2.  There is no rush to upgrade.  Play 1 works just as well as before and is still being supported.

I enjoy many aspects of Play and the Play community.  The only thing I would change are the compilation times.  I hope that we as a community can work on finding solutions to improve this for the Java developers out there that do not have a need for Scala.  It seems to me that it should be very possible to improve the situation even if we're not happy with where it is today.  I would love to hear people's experiences using other view layers.  What if you use client-side templating, Japid, or Groovy templates?  Does this improve the compilation times?  I would imagine it should as it would remove nearly all the Scala compilation.  If it does not, then let's figure out why and make it work.  It would seem that any of these solutions should be made able to compile quickly.

-Ben

Chris

unread,
Mar 30, 2012, 3:15:58 PM3/30/12
to play-fr...@googlegroups.com
I have repeated many of the points of the original thread on this Google Group so I won't do so again.

However, I keep coming back to one important point that several people in this thread have echoed: why is it called "Play 2.0" and not something entirely different?  The fact of the matter is that when people want to check out an open-source framework, they are going to go with the latest version most of the time.  Most people expect the the latest version to have more features, better support, more bug fixes, etc., etc.  Why start with something that is already "old".  

A new user is not going to understand that Play 2.0 is actually, in fact, a very different beast from Play 1.x.  Unbeknownst to these individuals, they may never know that Play 1.x may be exactly what they have looking for.  Instead, they will download Play 2.0 and may be completely put off.

Also, can anyone elaborate on the "business decisions" behind using Scala in Play 2.0?  Does this have to do with Typesafe?

Andy

unread,
Mar 30, 2012, 3:17:06 PM3/30/12
to play-framework


On Mar 30, 8:18 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:

> We are building a framework for the future, not for the past. The
> choice we make today are importants; if we want to have the best Web
> framework in 2 years, ready for real-time Web applications, supporting
> many JVM languages, able to scale to ten of thousands of concurrent
> users, we have to start now.
>
> Just don't expect us to release in 2012 a Web framework supporting
> only Java (and backward compatible with Java 1.4 because you need it),
> compatible with the Servlet 2.0 API (to be able to deploy your
> applications on your "enterprise servlet" container), allowing only an
> old school blocking model (allowing only basic CRUD and "dynamic" web
> application of the 200x) and integrating natively with Spring (because
> this is the new cool thing that will kill J2EE for sure).

I'm not sure I understand what you're saying:

> compatible with the Servlet 2.0 API

Play 1 already has the option to deploy without servlet, so Play 2
doesn't really add anything here, does it?

> allowing only an old school blocking model

Play 1 supports async mode and continuations. So how is Play 2 any
better here?

> ready for real-time Web applications... able to scale to ten of thousands of concurrent users

Play 1 already supports real time web, websocket, and scale to tens of
thousands of concurrent users, no? So again how is Play 2 any better
here?



Serkan Durusoy [DNA | encoding the future]

unread,
Mar 30, 2012, 3:26:57 PM3/30/12
to play-fr...@googlegroups.com
> My understanding from Guillaume is that he is ready to open up the 1.X branch to the wider community. We will just need to organize that (expect some more details next week). Also, ideas are welcome!

This is great news. Were this to happen, I'd have no doubt all issues covered in this topic should come to resolution. I for one am a fan of Canonical's open source strategy on Ubuntu and its derivatives.

They develop and maintain Ubuntu releases while allowing independently branched and vetted community driven derivatives, and promote/support them. What I especially adore is the 6-month release cycle and 1-year turnaround 5-year long term support strategy. The whole development and release plan is known and transparent at any given time. This assures customers to have no second thought in actually purchasing support contracts and revenue for making progress both as a company and community project lead.

In short, what I'd suggest would be:
* Play 2: zenexity/typesafe owned and managed open source project
* Play 1: An open source project that is "executed" by the community (yet still owned, "planned" and supported by zenexity (note the lack of typesafe))


冉兵

unread,
Mar 30, 2012, 3:32:26 PM3/30/12
to play-fr...@googlegroups.com
I have made Japid to take <150 ms to fully reload a changed view consistently with Play2, measured end-to-end with Chrome's built-in network monitoring tool.  Sure, the view does not do any db queries. 



2012/3/31 Ben McCann <benjamin...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/knWp29A0rCAJ.

peter hausel

unread,
Mar 30, 2012, 4:06:39 PM3/30/12
to play-fr...@googlegroups.com


On Friday, March 30, 2012 3:17:06 PM UTC-4, Andy wrote:


On Mar 30, 8:18 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:

> We are building a framework for the future, not for the past. The
> choice we make today are importants; if we want to have the best Web
> framework in 2 years, ready for real-time Web applications, supporting
> many JVM languages, able to scale to ten of thousands of concurrent
> users, we have to start now.
>
> Just don't expect us to release in 2012 a Web framework supporting
> only Java (and backward compatible with Java 1.4 because you need it),
> compatible with the Servlet 2.0 API (to be able to deploy your
> applications on your "enterprise servlet" container), allowing only an
> old school blocking model (allowing only basic CRUD and "dynamic" web
> application of the 200x) and integrating natively with Spring (because
> this is the new cool thing that will kill J2EE for sure).

I'm not sure I understand what you're saying:

> compatible with the Servlet 2.0 API

Play 1 already has the option to deploy without servlet, so Play 2
doesn't really add anything here, does it? 

For one thing Play 1 requires the "play runtime" on the target machine (big difference), also play 2's servet architecture was designed with extensibility in mind. So yeah, they are using the same library (netty), but the implementation is completely different.


> allowing only an old school blocking model

Play 1 supports async mode and continuations. So how is Play 2 any
better here? 

> ready for real-time Web applications... able to scale to ten of thousands of concurrent users

Play 1 already supports real time web, websocket, and scale to tens of
thousands of concurrent users, no? So again how is Play 2 any better
here?

Play 2 provides much more than just async and continuation.  It gives you advance IO handling, streaming, WebSockets, Comet and Akka support out of the box. Can you achieve these features in play1? Maybe, but the main point is that play 1 pulled many tricks to provide async specific features and you can run into serious limitations once you start heavily relying on async processing in general. 

Play2 on the other hand removed all the magic and became more standard, more robust and I think in a way more future-proof (or forward thinking if you will). Hence the versioning.

That said, both codebases represent different trade-offs and t's dangerous to think in "play X is better than play Y" paradigm. 

Evaluate your own needs and make a decision that will work the best for you and your team.

If people ask me which version they should use, I always ask about their project first.

just my 2c.

Cheers,
Peter




peter hausel

unread,
Mar 30, 2012, 4:11:01 PM3/30/12
to play-fr...@googlegroups.com
That's great to hear and this just underscores what I said about flexibility in play 2: it's super easy to plugin your own templating solution, since there is no magic anymore.

2012/3/31 Ben McCann <benjamin...@gmail.com>

To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

peter hausel

unread,
Mar 30, 2012, 4:20:01 PM3/30/12
to play-fr...@googlegroups.com


On Friday, March 30, 2012 3:15:58 PM UTC-4, Chris wrote:
I have repeated many of the points of the original thread on this Google Group so I won't do so again.

However, I keep coming back to one important point that several people in this thread have echoed: why is it called "Play 2.0" and not something entirely different?  The fact of the matter is that when people want to check out an open-source framework, they are going to go with the latest version most of the time.  Most people expect the the latest version to have more features, better support, more bug fixes, etc., etc.  Why start with something that is already "old".  
 
I think both Guillaume and I attempted to answer to that. 

A new user is not going to understand that Play 2.0 is actually, in fact, a very different beast from Play 1.x.  Unbeknownst to these individuals, they may never know that Play 1.x may be exactly what they have looking for.  Instead, they will download Play 2.0 and may be completely put off.

Also, can anyone elaborate on the "business decisions" behind using Scala in Play 2.0?  Does this have to do with Typesafe?

the evolution of the framework was explained here: http://www.playframework.org/ (please see infographics)


Thanks,
Peter

peter hausel

unread,
Mar 30, 2012, 4:28:25 PM3/30/12
to play-fr...@googlegroups.com
 What if you use client-side templating, Japid, or Groovy templates?  Does this improve the compilation times?  I would imagine it should as it would remove nearly all the Scala compilation.  If it does not, then let's figure out why and make it work.  It would seem that any of these solutions should be made able to compile quickly.

 
if you want to have client side templates, you can already use dust (the template compilation is hooked up in the build workflow): https://github.com/typesafehub/play-plugins/tree/master/dust 


Ben McCann

unread,
Mar 30, 2012, 4:28:38 PM3/30/12