For those of you who may have missed it:
I hope this is true. It would be cool.
For those of you who may have missed it:
I hope this is true. It would be cool.
Yes, we plan to support Play. If anyonw wants to help us, please feel free to.
I'd be interested in helping, but I'm not very familiar with play framework and I'm not sure what the learning curve will be. Would the task consist of writing a module for Play, like the scala module (http://www.playframework.org/modules/scala)?
Yes, the task is, basically, along these lines.
Providing a template engine based on Kotlin «Groovy styled» builder could also be great, no?
I think that I really know how does the Play! framework work, so in my opinion the main problem we should solve, if we speak about basic support of Kotlin in Play, is creating of cool kool templater and of course we also need annotations with parameter values support. I am very interested in this, so I will spend my free time on writing this Play! module.
Super Kool !!!
Awesome! "If anyonw wants to help us, please feel free to." I would love to do it :) Is there anything started? Will the module be hosted on github? Indeed I think it would be nice to have a Kotlin templating system, and a comprehensive API for controllers. I guess it will be based on Play2.0. Do you know if the kotlin version will support JPA annotations (like java version) or someting like Anom (like in play2 scala version)? Great news anyway!
I was wondering about templating too. As far as I can tell, Play 1.x uses Groovy for templating and the new Play 2.0 uses a Scala-based templating. While I agree that a Kotlin template engine would be great, I also wonder what's the path of least resistance? Does it make sense to develop a new template engine right away, or use the groovy templating to begin with?
Here is a problem with Play 2.0 - it is written on Scala (about 70% of code) and so we will have 2 additional runtime libraries and a lot of data conversion...
So you want to make a module for play1? It would still be cool but I'm afraid that all the community is moving to play2...
I think there will be some resistence for Java developers to adopt Play 2, and there will be some time for Play 2 to mature. So if it's minimum effort (because it's Kotlin interfacing with Java and not Scala) to support Play 1.x with groovy templates first, then later Kotlin templates, I wouldn't think that's a bad idea.
In Play 2, the core is built in scala but the scala api is wrapped by a java API. If the idea is to provide the possibility of using kotlin instead of java for web development the integration should not be so difficult.
Morevover, I don’t completely share your views about the java community that would stay on play 1. I can’t imagine someone starting a project on a version of a product knowing that the codebase will not be compatible with the next major version. If I have no visibility on the duration of the framework, I prefer using another framework.
Maybe a good choice would be to make a fork (a kork?) of Play1 to have a independent and alive product (not managed - or locked- by zenexity, who may refuse some evolutions in the 1.x version) ?
Why not minicing play2 , developing a new type-safety & stateless framework ? With kotlin's easier grammer , I think it will quickly attract a lot of java developers (who are reluctant migrating to play2's scala area )
The news that kotlin chose play framework for a web framework is really excellent.
Nevertheless I think that it could mean very different things, I’ll try to clarify a bit the options I see and that have been discussed in this thread
go for a new framework developed with kotlin from scratch
well, that’s certainly a lot of work. and maintaining it and keeping it upto date adds some great burden too
stick with play 1
a couple of options
take into account that play developers found a couple of limitations to this approach. they had to modify the core framework to support scala (have a look at the source, you’ll find many scala ad hoc modifications) they couldn’t support latests versions of scala, and finally the chose to rewrite the framework in scala
there has to be a good reason to fork a project, you’ll have to deal with support, enhancements, backport new features from the original project, etc…
Take into account that, in general lines, even though, as play developers clearly stated, play 1 will certainly be supported for a long time, the community is heading to play2.
ride on play 2
I don’t think you can provide play support with just a module, like in play1. I think you’ll have to create a project like they did with java: https://github.com/playframework/Play20/tree/master/framework/src/play/src/main/java/play, providing a kotlin API to all the play2 functionality.
that would be a fine starting point
then you could add a module for a template system based on kotlin. Ideally this would be an independent project that could be used outside of play (I think the current play2 tempalte engine, written in scala) is designed that way). Then this kotlin template engine could be used by play2 scala, java and kotlin users, or even outside of play.
Then you could also develop another module to define the routes in kotlin.
I think that the play2 path is the way to go. Jetbrains could provide a whole kotlin type-safe, asynchronous, well supported, framework, without the user ever knowing the core is in scala.
The good news is that play2 already supports an additional language (that is, java), so this use case has been taking into account.
Java has certain limitations, and lot’s of developers just don’t feel quite comfortable with scala (ok, I think that kotlin devs know this better than me So a kotlin API for play framework 2, with the tools and support provided by Jetbrains, would be great.
I’d like to know what kotlin developers think on this subject.
Sebastian, thanks for explaining of the different options. As someone not very familiar with Play, that was useful.
So to summarize the options you suggested:
1a) Develop module for Play 1, like the scala module (less work, but some limitations)
1b) Fork the project, and gradually adapt it and rewrite portions in Kotlin (more work and maintenance, but will overcome some limiations of option 1a)
2b) Ride on Play 2, and create a Kotlin API similar to the Java API. Since this is not a module per se, it would in a sense mean forking the repo and then hopefully Play maintainers would pull the Kotlin code into their repo… or otherwise it would require some manual process. Also, from what I understood, this option would mean pulling in both scala and kotlin libraries, so the runtime dependencies could become bloated and performance may suffer. Does that make sense?
I’m just laying out the options again as I understood them, how can we move the conversation forward and evaluate these options?
About forking Play1, I don't think there will be a lot of new features to backport from Play 1.x branch (Play2 will be stable very soon). On the other hand, if there is a need to add later new features in the original Play 1(without a fork), it may be difficult to do it on a such mature and (soon) frozen project (I don't know if Play team would agree) About Play2, the only problem is that it would require to have all scala libs/runtime + kotlin libs/runtime in the same time
Yes, those are the options, as I see it...
If you have enough man-power to develop and maintain your own web framework it would be an excellent showcase of what you can do with kotlin as well as provide good practices. I’m sure you’ll come out with an excellent and light-weight product. But you would loose play framework community and typesafe support.
And yes, if you use play2 (or any other scala library, like akka) from kotlin you would need both runtimes.
On the other hand, developing a kotlin API wrapper around play2 (that’s what they did with java) shouln’t be so difficult to achieve. Right now, when you create a new play2 application, you are being asked if you want to create a java or scala app. I guess that to achieve that level of integration you should have to work togeter with play developers.