Client side for Play - what is yours one and why?

[Andrew Gaydenko]

Please share your client-side technologies choice and motivation why do they play in unison  with Play. Thanks!

[Aldo Román Nureña]

I'm using Javascript with jQuery to make AJAX calls to the app, then receiving JSON data and using it as needed. The interaction in the client ends in the AJAX call to a Play route (then Play calls the appropiate controller). I have no use case of a deeper interaction, it does the trick :P

I'm also using MustacheJS to implement templating but that is after the AJAX calls are responded.

Great to share :)

[Chanan Braunstein]

We use AngularJS, I personally prefer knockout.js though.

[kompot]

AngularJS, SASS/Compass, Grunt and Bower (via play-yeoman).

Do not use any Play provided facilities for front-end development (i mean no less and closure compiler).

[Tim Schaub]

We're using Angular, treating a single Play app as multiple Angular apps.  Play renders 4 or 5 UI views and provides an API.  Angular does the rest of the routing.

We're trying to use WebJars for client-side dependencies.  This is handy for quickly bringing in asset bundles, but we'd like to use LESS sources from those bundles and would rather not use RequireJS and wrap everything in AMD (AMD's reason for being was development without any server dependencies, and in my opinion, it's an unnecessary and awkward fit when you have a server that is very capable of doing dependency resolution and asset compilation for production).  We'll likely go back to Node based utilities for dependency management and handling dev & prod needs.

Tim

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.

[virtualeyes]

Bower + GruntJS + Coffee + LESS

All Play based asset generators disabled

Apache front end serves static files; Play is used as application server -- quite happy with the setup.

Motivation? Speed up development.

[Ari King]

How are you integrating the frontend code with play? Are you using GruntJs to combine and store the css/js output files in the public directory?

[Alexandru Nedelcu]

brunch.io + CoffeeScript + Less + Q + JQuery

I haven't been using any framework like AngularJS or Backbone.js, as
the client-side functionality has been simple enough and I prefered to
build simple workflows by means of Q's async promises. I also haven't
been using any templating engine, preferring to write Javascript
functions that manually generate the HTML required ... not ideal, but
many templating engines these days prefer to load the templates by
means of URIs with no easy way to embed the template in the initial
blob and after some searching around, I got tired and went with the
hackish approach.

I look forward to using TypeScript, hopefully support for 0.9 will
land in IntelliJ IDEA. I found my choice of CoffeeScript to be less
than fortunate and my future projects will probably be based on
Closure-annotated Javascript.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to play-framewor...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--

Alexandru Nedelcu
www.bionicspirit.com

[virtualeyes]

I have Grunt generate css/js in local Apache var/www/foo/assets/ directory; Play has nothing to do with assets other than to generate the paths, and even then it's just a single route entry in parent/aggregator project's routes file.

With the

grunt dist

task css/js is combined/minified. To deploy, assets are rsync'd to a separate (from Play) production Apache VM

Far happier with this approach than having Play play the do-it-all (slowly) framework -- Scala compiler is slow enough as is, adding client-side asset generation lag time to the mix makes for a painful developer experience.

Now client-side is rapid fire, code change, instant browser refresh, no 2-5 second delay waiting for asset generator to catch up -- makes a big difference over life time of project....

[Jun Yamog]

We are using angular.js + underscore.js + grunt.js in a separate project from our play project.  Our play project is just part of the resources used by the front end, some are requested on a more traditional tomcat + jersey stack.  We are happy for both backend and frontend to be separate.

--

[virtualeyes]

On the fence, have yet to get on the Angular bandwagon.

Play's @ template layer is decent enough (although supporting generics would push it into the awesome range), and form generation/validation/binding are one the strengths of the framework, IMO. Doesn't offloading template generation to the client throw this valuable functionality out the window?

I agree with @Alexandru that TypeScript is the better long-term decision over plain JavaScript, or Coffeescript (much as I love the concise code, generated JS can be quite suprising, and indentation issues can be a PITA at times).

[Andrew Gaydenko]

Friends, thanks for sharing! Anybody else?

[James Ward]

Typesafe Activator is built with Play + RequireJS + Knockout + WebJars +
LESS:
https://github.com/typesafehub/activator

-James

On 09/12/2013 07:18 PM, Andrew Gaydenko wrote:
> Friends, thanks for sharing! Anybody else?
>

[Andrew Gaydenko]

On Tuesday, September 10, 2013 10:14:16 PM UTC+4, Chanan Braunstein wrote:

We use AngularJS, I personally prefer knockout.js though.

Why?
 

[Andrew Gaydenko]

On Friday, September 13, 2013 5:57:57 AM UTC+4, James Ward wrote:

Typesafe Activator is built with Play + RequireJS + Knockout + WebJars +
LESS:
https://github.com/typesafehub/activator

Is there intention to include webjars into official Play distribution?

[Chanan Braunstein]

I find it very hard to remember Angular. I am not a full time developer. I manage a team. I also do some development from time to time. I learned Angular and used it a bit. When I came back to it a few weeks later, I found that I didn't recall how to work with it and I had to lookup almost anything I want to do. On the other hand, I don't have the same issue with knockout. Having said that, I have used knockout for much longer and that most likely is part of the reason (Although, I am not convinced it is the only reason). For knockout, I I plan to use DurandalJS in the future, but haven't yet.

For my team, they choose AngularJS prior to me joining the team. They are happy with it and use it daily, so they do not suffer my memory problems. Although they have mentioned the high bar to entry in terms of a steep learning curve. The documentation (to me and to my team) seems at first glance to be very comprehensive, but in reality it is very confusing. 

All in all, if you ask me, either of those technologies are very good and you cannot go wrong using either.

[Chanan Braunstein]

In the roadmap doc: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA/pub It mentions something to do with Webjars in 2.3. Not sure if that means adding it directly to Play though...

[Christopher Hunt]

On Tuesday, 24 September 2013 02:39:48 UTC+10, Andrew Gaydenko wrote:

Is there intention to include webjars into official Play distribution?

Going forward, the idea is that we will use Activator to configure a Play project in terms of what features you want e.g. if you require a rich web application using WebJars then it should configure your build accordingly.

WebJars is only one build dependency away though for non-Activator scenarios.

In terms of client side development we are looking into factoring out the client-side components into a series of sbt and play plugins. The existing plugins (CoffeeScript, Less,...) will be going through a re-write and perhaps executed against a browser of your choice including PhantomJs i.e. goodbye Rhino.

We'll have more to report in the next few weeks as our ideas are documented. Please keep the feedback coming here though, this is a great thread and the information is gold.

Kind regards,

Christohper

[Andrew Gaydenko]

On Wednesday, September 25, 2013 2:58:39 PM UTC+4, Christopher Hunt wrote:

Going forward, the idea is that we will use Activator to configure a Play project in terms of what features you want e.g. if you require a rich web application using WebJars then it should configure your build accordingly.

Will this Activator way be friendly with already existing projects? The thing is, you know, today I want LESS and CoffeeScript, but tomorrow Sass and TypeScript are my the best friends :)

 

We'll have more to report in the next few weeks as our ideas are documented.

Great! Coordinating Play with client-side development (not forgetting about smart IDEs projects regeneration) is very exciting area :)

At the moment, say, with Eclipse after every change of dependencies I must regenerate (six ones counting subprojects at my case) eclipse projects, manually resolve nested sources error for each of them and then add additional builders to some projects (say, Sass one). Regenerating itself isn't a pain, but other steps are real life-eaters :)

[Christopher Hunt]

On 25/09/2013, at 9:27 PM, Andrew Gaydenko <andrew....@gmail.com> wrote:

Will this Activator way be friendly with already existing projects? The thing is, you know, today I want LESS and CoffeeScript, but tomorrow Sass and TypeScript are my the best friends :)

That's exactly why we're factoring out LESS and CoffeeScript! 

Activator is already able to work with existing projects btw. Still, adding support for TypeScript (for example) should just be a one-liner for built.sbt on existing projects.

-- 
Christopher Hunt
Senior Engineer
Typesafe – Build Reactive Apps on the JVM!

Twitter: @huntchr