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
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With