Re: Play 1.x or 2.x - I do not like Scala

[notalifeform]

Hi Fred,

I'm pretty in the same boat as you are; not that I don't like scala, but I don't this is the right moment yet for my team to switch to play2 java or scala.

To get to your questions: 

1) definitely yes - at least incorporate bugfixes, but I;s also appreciate enhancements

2) not sure - I think it would be great if we could get buy in from the core team

3) it would be better if that would not be needed, it would safe rebuilding an existing infrastructure and would be less confusing to the community

You might have noticed this discussion on the playone group:

https://groups.google.com/forum/#!topic/playone/PZkszFYnCbk 

I'd really appreciate a response from the play core team on this subject.

regards,

Robert

[Chris]

I continue to use Play 1.2.4/1.2.5 with much success. I have used Play 2.0 (in the early stages, so I cannot comment on how it may have been improved over recent updates) and will say that I did not find the framework to be as enjoyable to work with, as performant, and it lacked many of the features that I loved about Play 1.x.  Just my two cents.

On Thursday, December 13, 2012 9:39:41 AM UTC-5, Frederik Widenstern wrote:

Dear community, I am used to use Java and would like to avoid having to deal with Scala issues.

Play 1.x seems to be an impressive framework, clear and straight.

But I am not sure, whether I waste my time on an dying project.

I have seen, that there are many pull requests which have to merge into version 1.3.0.

So open questions:

1) Should we spend time to improve version 1.x?

2) If yes, how can we organize, that we have faster releases?

3) Does it make sense to duplicate and setup a new separate project of play 1.x? E.g. playfirst.org

What do you think?

I look forward to your feedback.

Regards,

Fred

[Tom Carchrae]

> You might have noticed this discussion on the playone group:
>
> https://groups.google.com/forum/#!topic/playone/PZkszFYnCbk
>
> I'd really appreciate a response from the play core team on this subject.

Agree.

There are 68 pull requests on Play 1.3 branch - which is sad.
Likewise you see people post modules here and no response or hope of
it being listed on the Play 1.x site.

So; is the answer just fork it and start reviewing/merging those pull
requests and steam on? Or will the core Play 1.x devs be back to work
on it. If there is no answer, I think we might have to presume they
are not coming back.

Tom

[Florian Gutmann]

We also have some 1.X projects running and love the framework a lot.
But still, there would be much room for improvement on the 1.X branch.

Recently we had to decide on a new project which framework to use.
After trying 2.0 we decided to continue with 1.X.
In our opinion 2.0 is not ready for prime yet. It will improve over
time but I'm not sure if it ever will be the framework of choice for
us.

We use a custom build with some modifications of 1.X already for a
while in production.
Unfortunately since the team started 2.X it feels like 1.X got abandoned.

There are 584 open tickets that nobody seems to care about.
https://play.lighthouseapp.com/projects/57987-play-framework/tickets?q=state%3Aopen&filter=state%3Aopen

If needed I would support a fork of 1.X.

--

Florian

On Sat, Dec 15, 2012 at 11:46 PM, René Schwietzke
<r.schw...@googlemail.com> wrote:
> Looking forward to a fork and independent project. 1 and 2 have different
> APIs, different concepts, and so there are already so different that a fork
> won't destroy anything but keep the framework interesting for the Java guys.
> I know plenty of people who liked 1.X very much but did not continue with
> 2.X.
>
> --
>
>



--
Florian Gutmann
irregular.at OG

Rottenbach 2
3911 Zwettl
Tel.: +43 680 2092408
E-Mail: f.gu...@irregular.at
Web: www.irregular.at
Firmenbuchnummer: 364171x
UID: ATU66626145
Firmenbuchgericht: Landesgericht Krems an der Donau
Mitglied der Wirtschaftskammer Niederösterreich

[Guillaume Bort]

Hi Robert,

> I'd really appreciate a response from the play core team on this subject.

Our position is clear: we don't want to have more enhancements or new features (as well as complete API refactoring or rewrite) on the Play 1 project.

We tried to bring more people from the community to the Play team to manage the Play 1.2.x maintenance, doing tickets triage, and managing pull-requests. Unfortunately, I have to agree, they are not very active. But I know that it is a lot of personal investment for a very tedious work. Especially when you discover that there are a giant legacy code base, on which each change breaks a few user's applications.

In any case, the work we agreed to do on the Play 1.2.x branch, has nothing to do with the big changes you are discussing on the other group.

--
 
 

--
Guillaume Bort, http://guillaume.bort.fr

[notalifeform]

HI Guillaume,

I do appreciate the play team not to accept any enhancements or new features anymore to the play 1.2.x codebase anymore. Of course if the team would be able to "restart" the maintenance again on the codebase, that would be a big plus - I'm now forced to use local build. On the other hand I'm pretty sure that there will be loads of discussion if issues should be marked 'enhancement' or 'maintenance'.(but we'll see that when we cross that bridge).

Are you at this moment looking for developers for the play 1.x codebase?

Thanks for your input.

regards,

Robert

[Guillaume Bort]

Are you at this moment looking for developers for the play 1.x codebase?

We could try to extend again the commiter team on the Play 1.x branch, but it's only to do triage work on the pull requests and issur tracker, as well as to integrate bug fixing pull request. 

Please contact back nicolas. 

--
 
 

[Daniel Peixoto]

HI Guillaume,

I understand yours position, but it would really nice if you can release 1.3 branch with major good work already done. It would be a fresh air to users that run their applications on play 1.2.x and "motivates" 1.x commiters.

Until that, gives time to play 2.x to be more "production" ready with the good job you have done.

Regards,

Daniel Peixoto

[Will Hains]

Our position is clear: we don't want to have more enhancements or new features (as well as complete API refactoring or rewrite) on the Play 1 project.

This is making me very nervous. My team is about 6 months into building a large new system based on Play 1.2.5, and about 18 months away from production. Do we keep going on 1.2.5, and risk having problems in production that will never get fixed; or do we go through a major rewrite now to convert to 2.0/2.1, and risk that it won't be production-ready in 18 months' time?

We are a Java team, and I think the learning curve for Scala would simply be too big on a project that's already underway. Worse, it's trivial to bring in new Java developer resources, but Scala developers are much harder to find, and I don't expect that to change in the near future.

Perhaps it was posted somewhere and I missed it, but it would be very reassuring to get some sort of roadmap for existing Play 1.x users from the core Play team. To be honest, I would be quite relieved if there is some kind of resource for migrating existing 1.x projects to 2.x, so we'd know that we have that option later, when 1.x is truly dead and 2.x is truly production-ready.

Warm regards,

Will.

[Monteiro]

Hello,

With Play 2.x you can use another templating language (without needing Scala):

- Groovy (https://github.com/manuelbernhardt/play2-groovy-templates, https://github.com/mbknor/gt-engine-play2)

- Java (https://github.com/branaway/japid42)

Scala is present only in configuration files.

Regards,

[El Softwarerero (the player formerly known as sun)]

@Will Hains

I wouldn't get nervous in your case. It was only said that no enhancements or new features will land in Play 1. Bugs will be fixed and most features and enhancements, if you need them, can be added as plugins.

[Mikael]

I am sorry to say but I would be nervous too if my job depended on choosing Play 1 as a framework for critical projects which go beyond the simple web application scope.
This was the choice I made over a year ago for some my internal enterprise projects.
Initialy everything was amazing given the productivity gain and the fantastic community support.
Even though Play 1 might not have been enterprise ready at the time, the enthusiasm and momentum suggested that it was just a matter of time before we get there.
Now that the momentum has died out and that the community has disappeared or moved to Play 2 I deeply regret having chosen Play 1 for some mission critical applications.
My personal experience tells me Play 1 is great for short term, non critical projects with limited exposure to enterprise functionalities.

[James Ward]

In your scenario, what are the most challenging things about upgrading from Play 1 to Play 2?  What would make that a viable option?

Thanks.

-James

--
 
 

[Mikael]

I cannot speak for others but for me all the concepts are so radically different between 1 and 2 that it is difficult to talk about upgrading. Instead I would rather talk about migrating to a different framework.
For me it would be a matter of working if it is worth the time/effort rewriting my applications and what I could gain from it. But more importantly, what guaranty do I have I won't find myself in the same situation in 2 years time?

[Robin Green]

Actually, Play is 5 years old, and Play 2 was released earlier this year, so if we assume the same timeframe will play out again, we are talking more like 4 years. But it is hard to imagine that Play 2 could go through a radical rewrite and API redesign in just 4 years time - correct me if I'm wrong.

On 29 December 2012 07:46, Mikael <mikael...@gmail.com> wrote:

I cannot speak for others but for me all the concepts are so radically different between 1 and 2 that it is difficult to talk about upgrading. Instead I would rather talk about migrating to a different framework.
For me it would be a matter of working if it is worth the time/effort rewriting my applications and what I could gain from it. But more importantly, what guaranty do I have I won't find myself in the same situation in 2 years time?

--
 
 

[Mikael]

Perhaps and hopefully not for Play 2 adopters. Assuming that the framework comes to maturity (in term of widespread adoption, tooling, support, productivity...) within 2-3 years of it's creation (which is an achievement in itself!), this would leave 2-3 years before considering the possibility of radical changes.
I am not saying it is or isn't a bad thing. Instead all I am saying is that with insight now, I would take this into consideration before adopting a new stack.

[Nicolas Leroux]

Well there is a big difference between play 1 and play 2. Play 2 is backed up by a commercial company (typesafe). It means that you can get commercial support for x years. It also means that ere won't be such radical changes without a clear migration path, because type is not likely to loose existing client. On play 1, lunatech and zenexity tried to provide commercial support but it did not happen. It is also not the core business of both companies (service company vs product company). All I wanted to say is that you are really safe with typesafe having play 2 in his product portfolio.

Nicolas Leroux

--
 
 

[James Ward]

What are the concepts that are different, hard to understand, or missing
in Play 2? Perhaps these are area we can work on.

-James

> --
>
>

[virtualeyes]

Heh, heh, Scala itself is totally mind bending at first -- take Action Composition for example. Imagine coming to Play 2 not knowing any Scala and needing to implement role-based authentication. Despite the decent documentation, good luck with that, only getting one's feet wet in Scala will fill in the blanks.

A year into Scala and I feel as if I'm only scratching the surface. Thankfully for me Play and ScalaQuery do the heavy lifting, but still, you have to do your homework in a major way to get up to speed.

Add in longer build times and Play 1-ers will obviously be put off.

I do enjoy Play 2 Scala, am fully on this train, but can sympathize with the Java heads wanting to stick with the tried & true.

[Tom Carchrae]

> There are 68 pull requests on Play 1.3 branch - which is sad.

I want to point out and give a big thanks to Nicholas and Jesper for
spending the past few days merging these requests:
https://github.com/playframework/play/commits/master

Tom

[Stephane C]

Hello,

I have been using play 2.0 with java since the middle of 2012. And despite of java being a second class citizen, there's no way I am going back to servlet-based frameworks.

Many people who are skeptical about scala have talked about forking play 1.x, but it's pretty clear that most of them underestimate the amount of work required. Imho, people should take a look at japid templates, it's currently a single man project (afaik) but with little work it could easily become a fist-class alternative for scalatemplates. So java developers would be in their java world, they would enjoy ultra-fast compilation time, instant refresh while still benefiting from an healthy and well-supported 2.x code base.

I don't think we'll see a play 1.x clone anytime soon. And even so, community based open-source sure is nice but I am really not sure anyone can invest enough time and effort to maintain it. On the other hand, maintaining a template engine like japid needs way less effort and the project is, right now, nearly in an advanced state.

Please think about it. This could be the peace treaty between play 2.x and Java developers ;-)

[James Ward]

Thanks for the feedback! What are the things that make Java feel like a
second class citizen in Play 2? Is it just that the default templating
language is Scala? Or are there other things?

-James

> --
>
>

[Ben Verbeken]

Hi James, 

Good question. 

Personally I don't think the Scala templates are even part of the problem, people got used to the Groovy templates in Play 1.x as well, without necessarily know it beforehand (I know I have). 

However, I think there's another thing, Ive heard this from others too. 

Play 2 itself is written in Scala, meaning that if I,as a framework user, want to use Play and try to understand how something works, I go look into the code and be able to read Scala. Saying that I don't need to know Scala is wrong, becuase you cannot expect developers to treat a framework (open source or not) as a black box. 

However, that's exactly the argument that's being used, right? 

-- Ben

[James L.]

I feel mixing the project with Java for fast compilation and Scala for productivity is better than a complete pure code, where we have been using different languages in web development like PHP, Javascript, etc too.

[James Roper]

Play 2 itself is written in Scala, meaning that if I,as a framework user, want to use Play and try to understand how something works, I go look into the code and be able to read Scala. Saying that I don't need to know Scala is wrong, becuase you cannot expect developers to treat a framework (open source or not) as a black box. 

I hear you there, you're certainly not alone in this view, I have worked on a development team that was using Play 2 and this was their biggest issue with it too (I was about to leave the company, as the only Scala dev on the team this caused a problem for them).  I for one certainly never treat a framework as a black box.

My own story is that before using Play 2, I had toyed with Scala a bit, but had just used it as a slightly better Java.  I didn't know anything about things like implicits, and I was not at all comfortable with the syntax.  I took Play 2 as an opportunity to ease into a new language.  And Scala is an excellent choice for a new language to learn, it's the first serious language to do a good job of combining OO with functional programming.  As an OO developer, I think you end up a much better developer from learning functional programming, and Scala is the perfect setting to do that in.  I was using the Java API, not writing Scala, so I mostly learnt Scala from reading the Play 2 code.  I did have a bit of a go at writing my own plugins in Scala, and this helped too.

Having now learnt Scala, I believe I am a much better programmer.  I also find it not very hard to read other functional languages like Haskell, the functional concepts you learn in Scala translate really easy to other functional languages.  I think if I had learnt Haskell instead, I probably would have had no problems reading Scala code and picked it up really quickly.  My inference from this is that it's not Scala that I was uncomfortable with, but rather functional programming.

So I guess my argument is that if you're not comfortable reading Scala code, then that's probably a good reason to use Play 2.  You'll be coding in Java where you feel comfortable, but when you need to go deeper you'll be learning functional concepts that will make you a better overall programmer, and allow you to read and understand not just Scala code and concepts, but the whole world of functional coding and concepts.  And with Java 8 lambdas and the like on the way, functional programming is only going to increase in prevalence.

 

--
 
 

--
James Roper
Software Engineer

Typesafe - The software stack for applications that scale
Twitter: @jroper

[Stephane C]

Hello,

From an user's point of view, there is not much, maybe one or two times I had to look at the scala docs but for the most part, my experience was ok with just java. I had some problems understanding field constructors, and when I finally figured out what implicits were and what they did, I decided to use my own templates for rendering fields. Btw one thing I truly enjoy about play is that it rarely (never?) forces you to do things in a predefined way, you can use your own form validation, your own data access code, create your own helpers... 

As for "Do I need to learn scala before I can use play", my answer would be different than the 2-3 people above. It sure is a plus but even if you are far from being an expert in scala you can guess most of what's happening under the trunk, HTTP routing, sessions, form handling, text output generation are no magic. If you can't figure out what the framework does for you, only then it can be considered a black box. Given unlimited time and money I'd be happy to learn every single implementation detail of all the technologies I am using, however it's not the case. As a result, I tend to avoid big frameworks that do too much voodoo magic, reflection, bytecode instrumentation or things that I can not reasonably understand. Maybe I write much more code than many people using sophisticated ORMs and frameworks but as long as the resulting product is delivered on time, fast enough, easy to understand and maintain, that can't be wrong.

Even if I don't know scala very well, what play does sounds intuitive to me. Or at least much more than JSF 1.x ever did, when I had to combine servlet filters, JSF interceptors, a complete new markup language and use facelets for composition. With play and my understanding of http, I have never needed to write guru-level code to address common needs such as page-based authentification.

Now because I don't like scala that much, find it slow to compile and difficult to read, I would not mind if there was a java (or more like java) first-class, full-featured alternative to scalatemplates. At least, as stated in my previous post, I think it would be wiser than forking 1.x branch both in terms of resources and quality. But of course, just like everything else in this post, that's just my point or view.

Best

On Tuesday, January 1, 2013 7:27:19 PM UTC+1, James Ward wrote:

[Will Hains]

Thank you. It does seem that a public "1.2.6" release would go a long way to allaying fears and anxiety, though. If 1.3 is never to be...

[Tom Carchrae]

On Fri, Jan 4, 2013 at 11:03 PM, Will Hains <wi...@willhains.com> wrote:
> Thank you. It does seem that a public "1.2.6" release would go a long way to allaying fears and anxiety, though. If 1.3 is never to be...

As far as I understand it, the plan is for the next version to be
1.3.0. The reason for the version change is because it will support
Hibernate 4 and due to this, will have to drop support for Java 5.
See this discussion:
https://groups.google.com/d/topic/play-framework/SlRy5qxuyu0/discussion

[Nicolas Leroux]

Yes that a correct.

Sent from my iPhone

> --
>
>

[hans]

Hi,

We all have seen a lot of posts of play 1 vs play 2, the debate that they generate shows the controversia of interests and opiniones that exist, nobody can deny it, who convince who and who has better arguments: this goes nowhere.

¿ How can we talk an hear each other with empathy ?

I believe in dialog, listening and agreement, let's stop trying to convince each other of the valdity of one point versus the other.

I think that both opinions technical and/or emotional are valid, there are some serious people who believe in it, and that make them worh consideration.

Zenexity Guillaume, James and the team has give opensource ana amazing framework and deserve or gratitude for that, now, they are in other road, that's the fact.

Should we try to continue trying to convince them that we think that they made a mistake ? The consequences area here in this debates, the community, the confidence and the dialog broken, the whole flow of energy of the play project has stopped.

This has happened before in opensource, hudson vs jenkins is a good example: it's the GPL what permits to just fork and continue.

I guess the only viable way is creating a new community driven fork of play 1 with another name, there we, the community, will face the facts of fundings and technical experts.

Funds: if the main question is fundings we should look forward for apache fundation, eclipse fundation or something else, i don't know.

Hans

El jueves, 13 de diciembre de 2012 11:39:41 UTC-3, Frederik Widenstern escribió:

Dear community, I am used to use Java and would like to avoid having to deal with Scala issues.

Play 1.x seems to be an impressive framework, clear and straight.

But I am not sure, whether I waste my time on an dying project.

I have seen, that there are many pull requests which have to merge into version 1.3.0.

So open questions:

1) Should we spend time to improve version 1.x?

2) If yes, how can we organize, that we have faster releases?

3) Does it make sense to duplicate and setup a new separate project of play 1.x? E.g. playfirst.org

What do you think?

I look forward to your feedback.

Regards,

Fred

[Tu Nguyen]

Hi Hans, your insight is spot on.

PS: Long live Play 1.x :)

[hans]

hi Tu,

Things are like: everybody move to 2.0 or die !!

have a good day

[Frederik Widenstern]

Hi all. Thank you for your many contributions.

I am very glad that there are apparently still hope for the 1.x version of Play.

I've seen a lot of pull requests have been processed. Great work! Thank you!

Obviously Robert (notaliveform) now become committers and takes care of some work. Thank you also.

Now my question: Would it not be appropriate to publish the version 1.2.6?

I look forward to your reply.

Regards,

Fred

[Nicolas Leroux]

There won't be a 1.2.6. We are still committing on that branch so people with a dependency on the jdk 1.5 can build there own package. The next version will be the 1.3 and will require the jkd 1.6+ . 

--

Nicolas Leroux

--
 
 

[Frederik Widenstern]

Hi Nicolas, I see.

Question: To get the latest stable Version of 1.x.. Which branch I should choose? master? 1.3.x? or 1.2.x?

I just took a look to https://github.com/playframework/play/branches

It's a little bit weird to me.

Because 1.3.x and 1.2.x are ~600 ahead and ~800 behind.

What is about the master? Which branch is recommended to follow?

Could you or somebody give a hint or recommendation on that?

Regards

Fred

2013/1/20 Nicolas Leroux <leroux....@gmail.com>

--
 
 

[Tom Carchrae]

Question: To get the latest stable Version of 1.x.. Which branch I should choose? master? 1.3.x? or 1.2.x?

I just took a look to https://github.com/playframework/play/branches

It's a little bit weird to me.

Because 1.3.x and 1.2.x are ~600 ahead and ~800 behind.

What is about the master? Which branch is recommended to follow?

Master is 2.x.  You should look at this to see the difference: https://github.com/playframework/play/branches/1.3.x

[Tom Carchrae]

Master is 2.x.  You should look at this to see the difference: https://github.com/playframework/play/branches/1.3.x

Never mind - I'm so wrong.  Now I am totally confused as well.

 

[Nicolas Leroux]

To get the latest from 1.x it is best to get the 1.3.x. The main difference between the 1.3.x and master is the support for multi db. In 1.3 this is backed up by hibernate( we might want to include some helpers though) while in master it is a custom solution. 

The 1.2.x branch consists of bug fixing for the 1.2.5 and is still jdk5 compatible.

--

Nicolas Leroux

--