Lift, Play! or BlueEyes (with a bunch of Javascript Frameworks)

Question

I find myself in a bit of a conundrum. I'm building a new, modern, web-based application and not only do I have to pick a technology, I have to pick an architecture. I think it is fair to say that these days its a tough choice because we have more options than we did even 5 years ago.

First things first, I've made the decision that Scala will be the server-side language. I have my reasons, and this is not a Scala versus XYZ post - that choice has been made. I've also sucummed to the fact that we're on the web, in the cloud, so I'm not even going to try and get away from Javascript. Maybe I will with CoffeeScript, but I will be writing Browser-hosted code.

Now, assuming Scala, most people would probably jump to either Play! or Lift. Probably Play! given it's endorsement from Typesafe, but I think I have another more important question that needs answering first. What's the architecture? If I want a very rich client, do I really need more than a simple stateless service layer based on the fact that we'll have a tonne of Javascript anyway? I'm not sure it'll be a single-page webapp, but is something like BlueEyes potentially the right choice? Lift and Play! are much more heavyweight in that they take on much more responsibility. They generate the HTML and for these frameworks, the browser is pretty dumb. Things like routing, validation, Ajax and Comet support are all server-side concerns. Because the browser is more capable today, rich, interactive features are normally implemented by generating and injecting Javascript from the server.

My question boils down to this. Do I go with a traditional Lift/Play! framework where the server takes on both the client and server responsibility or do I go with a rich client + REST-style service layer where the client takes a more prominent role in the application? An architecture where the client deals with routing, validation, binding, etc. I'm seeing frameworks like KnockOut.js, Sammy.js, Sproutcore, Backbone.js,... I'm not going to list them all but suffice to say that they all take on some of these framework features from a client-side perspective.

If I choose Play!, am I giving up some of that rich UI? What about situations where I want to provide service API's for integration/mashup/mobile purposes? How would Play! help me here? Clearly BlueEyes plays well here. I think I need a service layer regardless.

If I choose BlueEyes, what does my client code look like? How many of these Javascript-based frameworks do I need to give me what I need? I still want most of my business-logic in my service layer, but routing, binding.. all that UI stuff would be a concern of the client.

I'm not sure there is a right or wrong answer, but I think this community can probably point me in the right direction.

I also posted this to my blog at http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-it-u-45228

Fowler

Not to put you off of Scala, but you might like Haskell and Yesod. Yesod is apparently very RESTful. – Interlope

Answer 1

The Play 2.0 Beta contains a sample application that is exactly what you are looking for (ZenContacts). Its server side is just a bunch of restful interfaces while its client side leverages coffeescript etc. to build a rich user interface.

Macrocosm

Nice. I'll have a look. Could be exactly what I'm looking for. – Fowler

The app says that models and client-side templates are missing from Backbone code, and it is not recommended in real life. Then is the architecture of zentasks a recommended one overall? Why would we need views and models in Play otherwise? – Helve

I settled on AngularJS for the front end – Fowler

Answer 2

If all you want is a REST API on the backend, then Lift, Play! or Blueye will work just fine. But I'll just point the advantages of using Lift.

1. It is not true that Lift tries to impose doing both, the front and back end. We support REST-only use of Lift and it is encourage for the right project.
2. While Lift comes with jQuery and blueprint, you can use any javascript library and css framework, there is currently a lot of people on the mailing list showing how they use twitter boostrap with Lift. See this Lift module that helps integrating Bootstrap.
3. With Lift, you can start stateless, and if along the way you find that your needs change, you can go statefull. You can even mix and match them on the same application.
4. Want some modern looking UI? Lift's comet support is one, if not the best one, out there. Very simple to use, proven and tested on many browsers/workloads. I have written several posts showcasing Lift's comet support.
5. If you decide to use Lift for both, front and back end, you get for free an application that is secured by default, no need to worry about xss, xsrf, or many of the top 10 OWASP security vulnerabilities.
6. Need commercial support, there is a growing list here
7. Need training? There is a Basic training coming up in London and the founder of Lift also provides other training sessions.
8. There are several books about Lift available. Lift in Action , Simply Lift and Exploring Lift
9. There is a very active community ready to help.
10. Who uses Lift? Just to name a few: Foursquare , OpenStudy , The Guardian UK, StackMob and many more.

Well, I should stop here, but in short, Lift is an awesome framework that has a lot to offer, you take as much or as little as you need.

Forsberg

I've been part of the Lift community for a couple of years now and have built some things with it. I'm familiar, and agree that it is capable of handling my use case. The question is more around how much of it I use. – Fowler

If you end up just needing the a REST APi, then Lift will not be in the way, you just put it together extending the RestHelper and away you go, you don't have to worry about sitemap, comet, ajax, anything. So It doesn't feel heavyweight, or what do you mean by "how much of it I use?" – Forsberg

I like Lift, but I'm a bit scared that it'll go away. Now that David has mostly left to do other things with Visi... I was hoping that he would have jumped on at Typesafe, but something prevented that from happening. It's too bad because I think it hurts the Lift community a tonne. – Fowler

I am launching a new product exclusively using Liftweb with one single REST-Helper. Even if you do not end up using all the richness Liftweb has to offer, if you in any case need ANY of that sugar, you'll have it ;) – Superfamily

David did not leave, he just re-prioritized, and he is still very very active! :) – Superfamily

I said "mostly left", which is absolutely fair. He's on a one-day-per-week schedule. In any event, if Typesafe picked it up under its umbrella I would be less concerned. I don't want to get into that debate here, but I'm sure I'm not the only one feeling that after the combination of David doing Visi.Pro and Typesafe endorsing Play!. Whether that should matter is irrelevant, in many peoples' minds it does matter. Like I said, I like Lift. – Fowler

The fact that I need a server-side module to use Bootstrap seems completely broken to me. – Fowler

Well Bootstrap does the Wiring of your components and routing, therefore i cannot think where else to put it :) If you have just 2 lines in your Boot class, what's wrong with that? :) – Superfamily

Btw, why do you give the Typesafe "endorsement" so much weight? I'd go to where the better solution is presented, not where the bigger marketing campaign was made. just my few cents :) btw i don't have anything against typesafe, i just find the idea somewhat strange. – Superfamily

In any way, have a good look at assembla.com/spaces/liftweb/wiki/REST_Web_Services it really shows how easy and powerful lift is in the REST-Area – Superfamily

Answer 3

As far as I know, both Play! and Lift can be used as basically a "back end", and you can use HTML5+CSS+JS as your "front end"; they do not necessarily restrict your ability to create the front end you desire, so rejecting them for that reason would be silly. Notice things like knockout.js advertise that they "work with any web framework". However, it might be true that they are more "heavyweight" than what you need.

I have never heard of BlueEyes before, but it appears to be aimed at a particular kind of use case. If that fits your bill, then it will probably be the most streamlined solution to your problem.

But if this is something you plan to actually put on the web, "routing, validation, binding, etc" practically need to be handled by the back end; I simply cannot imagine any of these things (securely) being handled by code that runs in the client's browser. Also, if your users choose to disable JavaScript, your website would be completely unusable.

Interlope

Yes, of course then can be used in that way. Lift has Rest helpers that allow you to serve JSON services, but that's not the primary use case. The primary use case for Lift is a one-stop shop web frameworks, it even assumes jQuery and Blueprint as a default, because it doesn't want to have you depend on anything else. I'm not sure that's the job of a server-side framework in the new rich-client world. Not sure. – Fowler

Your last comment about disabling Javascript - if users do that they're disabling not only my application, they're disabling the Internet. – Fowler

"in the new rich-client world" :) We will apparently forever be bobbing back and forth between "The Cloud/thin client" and "Rich Client/minimal backend". Anyways, I'm fairly certain that Lift, Play, and probably even BlueEyes provide enough flexibility to be used in the way you desire without getting in your way very much. Much of the nifty scaffolding and power of the frameworks will be unnecessary for your project, but that doesn't necessarily mean it's a bad idea to use those frameworks. – Interlope

It's a question of focus I suppose. I don't suggest a "minimal back-end" at all, just one focused on serving data, processing, calculations, etc. Again, I'm not sure there's an answer so I guess I'm looking for a pros/cons discussion. – Fowler

Answer 4

If I choose Play!, am I giving up some of that rich UI?

What exactly you mean by rich UI? more javascript on the frontend?

If you consider - HTML5+CSS3+jQuery as a rich UI - then these work very well with any "backend" (Lift/Play).

The other thing which you might want to consider is the maturity of the framework. Like you mentioned Play 2.0 supports Scala natively, has endorsement of Typesafe and is rapidly being adopted. Plus you can expose RESTful services easily and consume then in the frontend (one of your requirement).

Leaning towards HTML5+CSS3+jQuery + Play 2.0 :)

just my thoughts..

Adao

Play 2.0 is also still being developed, with bugs being fixed every day and a lack of complete documentation. It isn't as mature as Play 1.0, even though Play 1.0 had less thorough Scala support. – Lozada

I agree - I'm pulling from master and I'm experiencing it first-class! :-) – Fowler

Answer 5

What's the architecture?

Play! strongly encourages your server to use an MVC architecture, creating packages in a standard pattern:

app/
  controllers/
    Application.scala
  views/
    Application/
      index.scala.html
  models/
public/
  images/
  stylesheets/
  javascripts/

This makes it easier to follow the architecture than to break it.

I can't speak for either Lift or BlueEyes, but afaik neither of them encourage an architecture as strongly.

Lozada

I'd say Lift is more of a bag of tools. That's great, for the right team and right problem. BlueEyes doesn't really compare in that it's very focused on serving HTTP requests and makes no assumptions as to the consumer. – Fowler

I'm not really asking about View-First (Lift) versus MVC (Play!), I'm more interested in how much the server participates in client-side concerns. – Fowler

In that case, none of the frameworks you list should have any effect at all on the client-side architecture. – Lozada

They don't have to play that role, no. But they're built with that intent. – Fowler

Answer 6

Definately have a look at http://twitter.github.com/finagle before making up yiir mind. Finagle can take care of most of your backend stuff. It's desinged around a very flexible architecture that separates concerns cleverly using filters.

Transplant

Cool, thanks, very interesting. I've run into it before, but never did a dive. Seems similar to BlueEyes (they're both built on top of Netty), but BlueEyes is HTTP only, so Finagle is even further up the abstraction tree. The HTTP Server example seems incredibly similar to BLleEyes. – Fowler

Answer 7

I have looked at apache click, wicket, a little bit Lift (feel a bit like wicket), and then play 1.2.4. So far so good with Play. Really beautiful approach to the web development. Keep up the nice work, play! team.

Soever