Open Letter to Play Framework Developers

[Roman Bykovskiy]

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 I 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 project 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 happened? And 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.

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.


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 by 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!)

[冉兵]

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]

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

Agree!

[Edward]

+1

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

[冉兵]

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]

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]

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]

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:

https://github.com/manuelbernhardt/play2-groovy-templates

or

https://github.com/mbknor/gt-engine-play2

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]

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]

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]

You can use Groovy templates with play 2 :

https://github.com/manuelbernhardt/play2-groovy-templates

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]

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

like JPAPlugin should bind Collection of Entities from DB

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]

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]

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]

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]

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

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]

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.

[Guillaume Bort]

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]

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]

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]

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]

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]

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]

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

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

--

[Роман]

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]

 

 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 happened? And 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.

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

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]

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 I 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 project 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 happened? And 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 by 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 I 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 project 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 happened? And 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 by 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]

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]

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]

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]

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.

[Роман]

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

 

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]

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)

Please see: https://github.com/playframework/Play20/wiki/Modules

 

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

 

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

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]

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]

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]

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]

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

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

[冉兵]

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]

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]

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]

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]

 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]

For one thing Play 1 requires the "play runtime" on the target machine (big difference)

This is the solitary reason I chose Play 2 over Play 1.  Not having to install Play on the server means I can bring up a machine in AWS, type "fab deploy", and now my app is running on an additional server.

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. 

Fantastic!  Thanks so much for sharing!  I will definitely give this a go myself now that I have even more confidence it is likely to pay off.  It will be hard for me to have any complaints about Play 2 then.

--

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

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

[peter hausel]

btw japid for play 2 https://github.com/branaway/japid42 is missing from the module's wiki, I hope it's OK if I am adding it. Cheers, Peter

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.

[Pascal Voitot Dev]

I can understand some critics, it's normal (except when only trolling)!
But keep in mind that Play2 is a very young child: it will evolve with new tools, helpers, modules, performance improvement etc... But for a such young dude, it's already quite robust and promising!

Yet, I bet my little coin that when one will see what can be done with Play2 to build real industrial, intensive and ultra-robust web-centric and dataflow oriented solutions, a few minds will be different.

Pascal

--

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

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

[malcolm smith]

I see a lot of comments about Scala compilation, it does seem like a problem (http://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly/3612212#3612212) but not to the degree that people discuss it here.  Perhaps there are other elements of the Scala Template generation process that could improve the overall round-trip time.  Also many people use Eclipse or IDEA for an IDE which are sometimes configured "out of the box" to use SBT or incremental compilation at all.  There is typically a big difference between sbt ~compile and the out-of-box IDEA make.

[Helena Hjertén]

Den 30 mars 2012 22:06 skrev peter hausel <peter....@gmail.com>:

... 

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.

Indeed, I am curious about your arguments for this and which type of project requirements point to 1.2.x, and which point at 2.0.

Both in regards to the actual application itself, but also in regards to requirements on support and on future work. 

And thanks Peter, for really making an effort to answer lots of questions today and this evening. After all, it is a Friday evening (for you too I guess :-) . 

/Helena Hjertén

 

-- 

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

https://groups.google.com/d/msg/play-framework/-/jkXaEQufTMwJ.

[malcolm smith]

Also -

From this message in scala-user list - asking about super-long compile times was resolved with a code change to the compiled code to identify a specific type on a generic list rather than having the compile do a full-code-base search to determine the inferred type.  Not suggesting that there would be such a specific fix for Play 2 template code - but who knows it is at least theoretically possible that the code gen happens to trigger a pathologically bad performance mode for the scala compiler.

http://tqft.net/hg/metaphor/diff/e005154ae030/src/main/scala/net/metaphor/api/FinitelyPresentedCategory.scala

[peter hausel]

Thanks Malcolm. Rest assured, we will look into how to make the template compilation faster.

[Drew Hamlett]

I'm liking Scala but I'm all for the Java side having Java templates and Java routes, and the Scala side having Scala templates and Scala routes(like it is now).  It only makes sense.  

I know Japid is a module right now but I think it would make sense to integrate it(or Rhythm) into the Play 2 project.

I think it would make a lot of people happy(also improve compile times for those who stick with Java).  Thanks.

On Friday, March 30, 2012 3:32:26 PM UTC-4, Bing Ran wrote:

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.

[Ben McCann]

I'm not familiar with Rythym and Google didn't turn up anything.  If there's a Play 2 module for it, could you add it to the wiki:

https://github.com/playframework/Play20/wiki/Modules 

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/CLJw6QPxf5wJ.

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

[canavar]

30 Mar 2012 22:27 tarihinde "Serkan Durusoy [DNA | encoding the future]" <serkan....@dna-tr.com> yazdı:

We can see that zenexity has not enough energy and motivation to support Play 1.x even without typesafe. I think a new organization should be constructed for our far best Java web framework. Zenexity should go on only as a contributor to the project.

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

[peter hausel]

 Hi Helena,

Thanks for your kind words.

Speaking only just for myself, here a few questions I'd ask:

- how important is it to your organization to have all the new shiny async goodies in your toolkit?

- how important is it to your organization to be able to compile assets (javascript, less, coffeescript)?

- how important is it to your organization to have commercial support or training?

- deployment consideration? 

- would you be OK with container-less deployment?

- are you using any cloud providers?

- is there any value in being able to publish to a maven repo?

- is there any value in having play in a maven repo?

- how big is your team or company?

- have you used any version of play before?

- if you are a play 1 user, are you happy with it?

- are you interested in scala?

- is your company a java shop?

- is there any other language used in your stack?

- what kind of product are you building?

- what's your industry?

- are you planning to use play as a web service or a full stack web framework?

- are you using a database or a NoSQL store?

Answering to these questions would give me a pretty good idea which version I would recommend. 

Sometimes my answer would be 1.X and sometimes it would be 2.0 - it all depends.

Hope this helps.

Thanks,

Peter

 

 

-- 

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

https://groups.google.com/d/msg/play-framework/-/jkXaEQufTMwJ.

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.

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.

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.

[Drew Hamlett]

It's only a Play 1 module right now.

https://github.com/greenlaw110/play-rythm

This is the source for the engine

https://github.com/greenlaw110/Rythm

I had been working a little bit on a plugin for Play 2 but haven't got to far in it.  I'm thinking Green Luo maybe working on one too(I don't want to put words in his mouth though).  I like Rhythm slightly better but both Japid and Rhythm are very good.

[peter hausel]

On Friday, March 30, 2012 5:38:04 PM UTC-4, Drew Hamlett wrote:

I'm liking Scala but I'm all for the Java side having Java templates and Java routes, and the Scala side having Scala templates and Scala routes(like it is now).  It only makes sense.  

just a minor point but play2's router is just an external DSL.

[Ben McCann]

Drew, thanks for the Rhythm link.  I like it very much since it's syntax is so similar to the Scala templates.  If it ever becomes available for Play 2 then it'd be very easy to convert my existing app to use it.  I'd be very interested to know if that happens.

 

just a minor point but play2's router is just an external DSL. 

True, but I believe it's then compiled to Scala and then compiled to bytecode, unless I'm mistaken, and this last step is very time consuming.  I've often thought about trying to have it compile to Java instead to speed up my development.

 

--

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

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

[peter hausel]

On Friday, March 30, 2012 6:05:30 PM UTC-4, Ben McCann wrote:

Drew, thanks for the Rhythm link.  I like it very much since it's syntax is so similar to the Scala templates.  If it ever becomes available for Play 2 then it'd be very easy to convert my existing app to use it.  I'd be very interested to know if that happens.

 

just a minor point but play2's router is just an external DSL. 

True, but I believe it's then compiled to Scala and then compiled to bytecode, unless I'm mistaken, and this last step is very time consuming. 

I do not know. Maybe my projects are different in some ways or it's just my dev laptop (newish MBP with SSD) but I have never found the compilation speed of routes (or even templates) *that* bad. Not to say it's fast or we won't try to make it better but it looks like different folks have different expectations.

Either way, from my end I am going to look into how to make things even faster.

[peter hausel]

just to provide some data points (zentask java app) on my machine after rebuilding the whole thing  (play clean compile) and running the dev server:

route change reload (average):

real 0m1.121s

user 0m0.006s

sys 0m0.003s

template change reloading (average):

real 0m2.105s

user 0m0.006s

sys 0m0.003s

(MBP 2.3 i5, 8GB RAM, SSD, OS X 10.7. Java 6)

again while this is far from fast, for me at least as a developer this is completely acceptable (remember how long it took to rebuild a project and redeploy in a servlet container? yup). Your experience may vary and we would like to know if you see different numbers on reasonable hardware.

My closing remark is that play 2.0 came out like 3 weeks ago. It's a young technology(hello early adapters!) and instead of folks jumping to conclusions, how about making it better together? See a performance issue? Please put together a ticket in lighthouse. See a way how to make things faster? We would certainly like to hear about it, so please bring it up on the mailing list etc. etc.

Anyway, thanks for all the comments!

In and out,

Peter

[Jean-Francois Im]

I think the pain point is mostly with larger apps. We haven't finished
migrating our play-scala app from 1.2.3 to 2.0, but I remember that
sometimes with the play-scala plugin it took two or three minutes to
compile the hundred or so files when making a change in the model.

Hopefully the play 2.0 integration with sbt will make it a bit faster.
If not, well, I'll keep on having a really clean desk. :P

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

[Ben McCann]

(remember how long it took to rebuild a project and redeploy in a servlet container? yup)

Yes, that experience from many years ago is awful and much worse.  My point of comparison is the one I came from of running Jetty in embedded mode with pure Java.  There are no redeploys and a page refresh is instantaneous as compared to multiple seconds.  2-3 seconds I can generally live with.  However there are some changes which rigger larger recompilations and take much longer.  In any case, if it's helpful to show how to achieve instantaneous refresh with Jetty, I can put together an example app to demonstrate.

My closing remark is that play 2.0 came out like 3 weeks ago. It's a young technology(hello early adapters!) and instead of folks jumping to conclusions, how about making it better together? See a performance issue? Please put together a ticket in lighthouse. See a way how to make things faster? We would certainly like to hear about it, so please bring it up on the mailing list etc. etc.

Totally agreed here!  It is very encouraging to me that Bing Ran was able to refresh the page so quickly using Japid.  This is a very helpful data point and is encouraging to me.

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

[peter hausel]

On Friday, March 30, 2012 7:39:14 PM UTC-4, Ben McCann wrote:

(remember how long it took to rebuild a project and redeploy in a servlet container? yup)

Yes, that experience from many years ago is awful and much worse.  My point of comparison is the one I came from of running Jetty in embedded mode with pure Java.  There are no redeploys and a page refresh is instantaneous as compared to multiple seconds.  2-3 seconds I can generally live with.  However there are some changes which rigger larger recompilations and take much longer.

 

OK, this is really the last one:-) I am sorry but you are comparing apples to oranges here. Changing a java class in play 2.0 is instantaneous (certainly sub second on my box). We talked about routes (which by the way are not compiler checked in most frameworks to begin with) or (compiled) template hot reload, outside of play. As for larger recompilations, please report issues like this in lighthouse. Thanks!

[green]

Hi Drew,

Thanks for your interesting on Rythm template engine. Unfortunately I am afraid I can't work on play2 plugin, at least for now. The reason is in two folds:

1. I am fully occupied with other stuff including maintaining existing modules (morphia, greenscript etc) and improving Rythm as a play 1 module

2. I don't have enough expertise to work on play 2 at all.

I will be glad to provide any support if you can help to create a play 2 plugin based on rythm.

Kind Regards,

Green

PS. The stuff is caled "Rythm", not "Rhythm"

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/m1lHsOv8DkgJ.

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

[Ben McCann]

OK, this is really the last one:-) I am sorry but you are comparing apples to oranges here. Changing a java class in play 2.0 is instantaneous (certainly sub second on my box). We talked about routes (which by the way are not compiler checked in most frameworks to begin with) or (compiled) template hot reload, outside of play. As for larger recompilations, please report issues like this in lighthouse. Thanks!

Sorry if I wasn't totally clear.  When I said "pure Java" I mean a compiled template hot reload, but using Java templates.  E.g. I've used typesafe Java templates with instantaneous reload before by using Jetty and GXP.  I brought it up just to say that typesafe templates and instantaneous reload have been possible for awhile, so I think it's something we can accomplish with Play 2.  Not just to whine :-)  If I get a chance in the future, I'll try to take a look and offer something more concrete in the way of making things better.

Thanks as always for your work on Play!

--
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/-/PlDqiR-vSW4J.

[Drew Kutcharian]

We've been using Play for a few years now and we've been pretty happy with the 1.x releases, but for our most recent project we chose to go with Play 2/Scala even though we had already spent a good 3 months developing using Play 1/Java. That meant pretty much rewriting everything from scratch, but looking at the long term gains and the state where the project is now, I'd say it was well worth it. We use a lot of "modern" web features, so Play 2 is just a great fit.

As everyone already mentioned, Scala compilation is slow, but we were able to get around that by splitting up our app into many different modules and using "publish-local" to publish it into Play's repository. That way you're not compiling the whole project every time so compile times are much more bearable. Steve Chaloner has two nice posts on how to do this.

http://www.objectify.be/wordpress/?p=363

http://www.objectify.be/wordpress/?p=374

In the end for us the extra compile time is a small price to pay for the great type safety we get with Play/Scala. Gone are the days that the templates would break because of the controller/model/etc changes. Now everything gets compiled and you see the errors immediately.

Overall we are very thankful of the Play developers and all their efforts.

cheers,

Drew

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

[Alex North]

Thank you Guillaume et al.

My team love's Play 2's direction. Your team's willingness to break with aging conventions and start fresh contributed greatly to our confidence that Play will evolve into a fantastic framework. I believe such schisms are an essential part of technical innovation, of building something for the future. The number of features that Play 2 *doesn't have* also spoke hugely in its favour. I have spent far too much time fighting the magic that other frameworks inject into an application, so it's refreshing to see that Play is not going to make it hard for my team to do things the way we want, and easy for us to add modules as and when we require them.

We look forward to the continued improvement.

Alex
On Friday, March 30, 2012 11:18:40 PM UTC+11, Guillaume Bort wrote:

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

--
Guillaume Bort

[Drew]

We've been using Play for a few years now and we've been pretty happy with the 1.x releases, but for our most recent project we chose to go with Play 2/Scala even though we had already spent a good 3 months developing using Play 1/Java. That meant pretty much rewriting everything from scratch, but looking at the long term gains and the state where the project is now, I'd say it was well worth it. We use a lot of "modern" web features, so Play 2 is just a great fit.

As everyone already mentioned, Scala compilation is slow, but we were able to get around that by splitting up our app into many different modules and using "publish-local" to publish it into Play's repository. That way you're not compiling the whole project every time so compile times are much more bearable. Steve Chaloner has two nice posts on how to do this.

http://www.objectify.be/wordpress/?p=363

http://www.objectify.be/wordpress/?p=374

In the end for us the extra compile time is a small price to pay for the great type safety we get with Play/Scala. Gone are the days that the templates would break because of the controller/model/etc changes. Now everything gets compiled and you see the errors immediately.

Overall we are very thankful of the Play developers and all their efforts.

cheers,

Drew

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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!)

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by 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.

[Bendanpa]

I don't know how many play1 users deploy their apps to GAE. But lack
of GAE support (not even in the near future) definitely stops many GAE
users to try play2.

On Mar 30, 5:20 pm, Drew <d...@venarc.com> wrote:
> We've been using Play for a few years now and we've been pretty happy with
> the 1.x releases, but for our most recent project we chose to go with Play
> 2/Scala even though we had already spent a good 3 months developing using
> Play 1/Java. That meant pretty much rewriting everything from scratch, but
> looking at the long term gains and the state where the project is now, I'd
> say it was well worth it. We use a lot of "modern" web features, so Play 2
> is just a great fit.
>
> As everyone already mentioned, Scala compilation is slow, but we were able
> to get around that by splitting up our app into many different modules and
> using "publish-local" to publish it into Play's repository. That way you're
> not compiling the whole project every time so compile times are much more
> bearable. Steve Chaloner has two nice posts on how to do this.
>
> http://www.objectify.be/wordpress/?p=363
>
> http://www.objectify.be/wordpress/?p=374
>
> In the end for us the extra compile time is a small price to pay for the
> great type safety we get with Play/Scala. Gone are the days that the
> templates would break because of the controller/model/etc changes. Now
> everything gets compiled and you see the errors immediately.
>
> Overall we are very thankful of the Play developers and all their efforts.
>
> cheers,
>
> Drew
>
>
>
>
>
>
>
> On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:
>

> > *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 I 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 project 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.<https://lh5.googleusercontent.com/-dyeLKIMrhDY/T3VTc4pcbGI/AAAAAAAAZ3...>
>
> > *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!
>
> > 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.
>

> > *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!)
>
> On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:
>

> > *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 I 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 project 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
>

> ...
>
> read more »

[Guan]

Another suggestion is can we put play1.x document somewhere else to another website? Currently it's like there is no entry point to play1 document. Play team seems trying hide play1 from new people. 

Luckily I found api dropdown list that has a play1 doc link..... But image for some new developer who may want something like play1 instead of play2. When they browse the website, how can they discover the play1.... who can ever imagine play1.2.3 api is the stable version when it appears in a api dropdown list below 2.0...

On Thursday, March 29, 2012 11:42:36 PM UTC-7, Roman Bykovskiy wrote:

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 I 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 project 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 happened? And 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 by framework developers.

[smallufo]

Play2 surprises a lot of Java developers because everything looks so alien ...

The migration path is so painful...

I suggest the future play2 release (maybe 2.1) bundles groovy template and JPA/hibernate ORM for default java project.

Or when creating a new java project , adding another option to select template (groovy/scala) and DB-strategy (JPA-hibernate / ebean) 

I know there are modules for groovy template / and (maybe , not sure) hibernate plugin...

But play2 is so different , developers have no time figuring out the whole structure , 

how can you tell developers "There are modules out there , try to integrate yourself" ...

It's such a difficult task...(for Scala/SBT-unfamiliar java developers)

With built-in groovy/JPA/Hibernate , it'll ease the migration pain , I think there will be fewer noises here.

[Hristo Deshev]

Hi everyone,

Scala guy here. One that really enjoyed Play 1.x and one that won't touch Play 2.0. I thought I'd share my two cents.

Play 2 is a deal breaker for me because of one simple thing - it doesn't have servlet container deployment. If you are building a web framework you really need to take care of the basics first. I feel boring features like that should get more priority than the "cool" Haskell-y stuff like Iteratees and whatnot. Guillaume mentioned that the Play developers are solving the tough, thousands of sessions problems that will make Play the best framework in two years. But, in the mean time, today's real-world problems get neglected. Most developers don't care about handling thousands of sessions - they care about productivity and ease of use. I'll keep following Play, but until that two-year effort bears fruit, I'll use something else.

There are real gems in the Play framework. The template engine, for example, kicks some major butt. I'd love to have those separated out, so that people can use them on their own. Oh, wait, somebody already did that with the Twirl project [1]. I'm using those templates in a Scalatra app now and I quite happy with that! I'd love to see effort by the Play team in that direction too, so that anyone could refer to "play-templates", "play-anorm", etc in their build and use those cool libraries without pulling everything else in his project.

Saying that Play 1.x is fully supported and people should just keep using it is just plain awful and untrue. Play 1 is stuck with Scala 2.8.1, akka 1.0, and an ancient version of sbt. Good luck with those! I have a Play 1.x project on life support that I'll probably migrate to the Scalatra + Twirl combo if I need to move it forward with new features.

Frustratedly yours,

Hristo

[1] https://github.com/spray/twirl

[Pascal Voitot Dev]

it' funny because a few months ago, lots of people were throwing big stones on the head of groovy templates telling it was a pain, it was too slow etc... Now it's as if it was the best stuff in the world :D
Scala templates compiles a bit slower, it's true but it's sure it will get better. But at runtime, scala templates are much quicker and robust as they are compiled. When I can see what I can do with them now, I find groovy templates a bit deprecated...

anyway i can understand that migration can seem a bit hard if you must rewrite all templates...

Pascal

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

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

[Alexander Strebkov]

Just wanted to share my experience with Play 2.0 so far:

I have ported a small project from Play 1.x to Play 2.0 using scala and anorm. I had alot of experience with Play 1.x but zero experience with anorm and Scala (except half-read book). Project includes small CRUD with auth, file upload (stored in database), and a two small template trees for main part and admin part (admin part done from scratch). It took me about three days to port it and it is now deployed to Heroku and running fine for a few days.

I like Scala templates. New syntax is even shorter and clearer compared to Groovy and static typing should be faster in production (I've not tested though) and less error prone. I will probably change my mind once I experience a 30+ seconds compile times... but so far I have not noticed any problems with compilation times (maybe because project is not big enough or because I do not hit reload too often). But for now scala templates is a main reason to consider using 2.0 for me.

Of course some nice-to-have things are missing in framework (or in documentation/examples) at the moment, and some things could probably be improved, but that's what versions 2.1 e.t.c. are for. Of course some things have changed form 1.x to 2.x and some time is required to get used to those.

Back to topic: I do not understand the point of your complains. Play developers owe nothing to your web-shop (or whatever). They created a framework (both 1.x and 2.x) for themselves and shared it with everyone. Everyone is free to use it or use something else. If you have so many problems with Play 2.0 - stick to Play 1 (Play developers said many times it will be supported and from my experience it is fully functional framework already which could be extended with any functionality you may need) or find something else which suits your needs. "I do not like acid-green and scala, so your framework is bad" doesn't sound serious.

Best regards,

Alexander

[Роман]

> Back to topic: I do not understand the point of your complains. Play
> developers owe nothing to your web-shop (or whatever). They created a
> framework (both 1.x and 2.x) for themselves and shared it with everyone.
> Everyone is free to use it or use something else. If you have so many
> problems with Play 2.0 - stick to Play 1 (Play developers said many times it
> will be supported and from my experience it is fully functional framework
> already which could be extended with any functionality you may need) or find
> something else which suits your needs. "I do not like acid-green and scala,
> so your framework is bad" doesn't sound serious.

I'm sorry for style of my very first letter started this branch.
"Scala sucks" was the anchor to continue reading. "get rid of acid colors" - it's an allusion to the first silly complains here after site changing. It's all jokes.

Let's be clear again:

Lof of people have problems with the new version.
It's not about a complaints. If so many people can not solve a simple tasks they do easy in 1.x - the problem exist.  And at this letter we are trying to show it to framework developers.

Here was a good remark to them:

how can you tell developers "There are modules out there , try to integrate yourself" ...
It's such a difficult task...(for Scala/SBT-unfamiliar java developers)

Developers, as far as I understand, are not ready to change plans, because the goal is to make the powerfull framwrok first of all, not like just easy-to-go framework. And it's a worthy goal.
But, however, developers explained  the 1.x (easy-to-go) version will continue to evolve as separate branch, and they even ready to make it more open for the public development.

We also try to convey the idea that the newcomers with no Scaka experience will install the latest version of course, assuming it is not different, but just updating the old one. And will face the same problems. That's the reason to rename 1.x to something else (i.e. PlayLight) to remove the misunderstanding.

It's not a criticizm, we just want to dot the i's.

[Peter Hilton - committer (Lunatech)]

There has been enough discussion in this thread for us to start looking at the big picture. All of the concerns expressed in this thread can be addressed, and chances are they all will be, but Rome wasn’t built in a day. (I’m hoping that’s the same expression in other languages.)

After all of the work to create Play in the first place and release Play 1.0 in 2009, it took us two years and a lot of work to get to a Play 1.2.4 release that has:

• all of the functionality that you definitely need to build an web application
  
• the extensibility to add modules for the features that only you need, without breaking backwards compatibility by changing the core framework
  
• bug fixes and improvements to make Play meet your non-functional requirements
  
• extensive and thoroughly-edited examples, tutorial and documentation, so that you can successfully use the framework
  
• an user community that’s so active that people complain about Google’s collaboration software (Groups) not being good enough to handle the traffic (luxury problem!)
• a developer community that’s so active that no-one can keep up with all of the new open-sourced Play modules (another luxury problem!)
• enough experience on commercial projects to offer expert-level Play 1.2 consultancy, support and training (which isn’t going away any time soon) for organisations that prefer to hire professional external help.
  

There is no reason to believe that these will not all be there for Play 2, but it's simply not possible for them to be there now, weeks after the 2.0 release. It probably won't take two years this time, though.

That’s all I have time for now, because it’s weekend and I have a Play 2 book to write, Play 1 documentation contributions to integrate and support plans to discuss with Nicolas Leroux (over a beer of course).

[Manuel Bernhardt]

On Sat, Mar 31, 2012 at 1:38 AM, Jean-Francois Im <jf...@jean-francois.im> wrote:
> I think the pain point is mostly with larger apps. We haven't finished
> migrating our play-scala app from 1.2.3 to 2.0, but I remember that
> sometimes with the play-scala plugin it took two or three minutes to
> compile the hundred or so files when making a change in the model.
>
> Hopefully the play 2.0 integration with sbt will make it a bit faster.
> If not, well, I'll keep on having a really clean desk. :P

That got a lot better. We also had 2-3 minutes reload time, which was
mostly due to the bytecode enhancements. Now we're down to about 5
sec, much better. This is the time it takes to start the application
up - it does quite a few things there, which probably isn't a too
common case so I'd expect reloading to be very fast in general.

[Gp P]

Yeah you right scala and paly 2 sucks , being a java developer why I care about scala ? If i love scala so much I rather user a pure Scala framework like lift  ..

who needs aka , java world lot of  distributed computing frameworks like gridgain etc

And is there any performance increase between 1.2.x and 2.0 ..with both on  non grovy template engine  ? 

Personally I am not going to touch  play 2.0 , I am happy with play 1.2.4 it works and has some plugins 

If 1.2.x branch is not supported in future , I will got back to spring or fork 1.2.4

We need a pure java framework which just works and is super fast , not on some  JVM language 

--

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.

--
Be  the Change

[Suraj Tamang]

I am with everyone....SCALA SUCKS!!!! at least Groovy is better for template...but SCALA SUCKS!!! AGAIN

Play! 1.2.4 ROCKS!!! I currently developing my Apps using Play! 1.2.4 not interested in 2.0 anymore....

[batshaa]

I want share my two cents too.

I'm a JAVA DEVELOPER! Not a Scala developer! I want a Play 2 version only in Java. I don't care at all about Scala because it sucks and it is complex. What I want for Play 2.0 is full JAVA!!!! with simple! Hibernate support and also the support for Groovy because it is less complex than Scala!! And Servlet and Spring and Maven because it is the stdandard of Java developers!

I work for a company and we use Play with Java for our proejcts. But I say you that we will STOP using it if you don;t want to chanage Play 2 to full Java, Gorovy and MAVEN! 

This is the last chance for you!

Freinds, we need to remove these Play core developers that only want complexity and don;t want to give us the Spring and maven goodies we need, us REAL DEVELOPERS!!!! And we want rthe old website, and also the old google group!! This new google group sucks and look like vomit too on my screemn.

Bts.

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.

--
Be  the Change

[Federico Tolomei]

Is there a plan with features/bug fixis for a 2.1 ? The lighthouse is
still poor about 2.1

--
skype: effe.to