Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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

like image 804
andyczerwonka Avatar asked Feb 09 '12 21:02

andyczerwonka


3 Answers

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.

like image 197
fmpwizard Avatar answered Oct 17 '22 05:10

fmpwizard


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.

like image 31
Dominik Dorn Avatar answered Oct 17 '22 07:10

Dominik Dorn


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.

like image 4
Dan Burton Avatar answered Oct 17 '22 05:10

Dan Burton