Is Lift a Scala framework like Play?

[Rogerio Kioshi]

Hi,

I'd like to know if Lift is a Scala framework like Play.

[Hussein Baghdadi]

Lift's website says it is a web framework for Scala programming language!
Play! framework isn't really a web framework for Scala, it is a Java web framework that flocked from the Java EE land with a support for Scala programming language.
TypeSafe announced recently that they are adopting Play! framework and it will be part of their stack.

[Mohamed Sanaulla]

Moreover Lift is NOT MVC based where as Play! framework is MVC based, you can read a possible discussion here.

[Timothy Perrett]

Rogerio Kioshi wrote:Hi,

I'd like to know if Lift is a Scala framework like Play.

Both Lift and Play! are "full stack frameworks". In that way they are similar but their approaches are otherwise totally different.

[Bear Bibeault]

Could you expound upon this difference in approach for those of use familiar with Play?

[Timothy Perrett]

Bear Bibeault wrote:Could you expound upon this difference in approach for those of use familiar with Play?

Let me just say that both tools have their place. Nothing is perfect. There is no silver bullet, and both tools make trade offs to improve in different aspects which they find important.

Lift focuses on being awesome for rich AJAX and comet applications, and having great out of the box security and state handling features. Play on the other hand focuses more on delivering the familiar front-controller MVC toolchain to JVM developers. As such Play! is probably far better for building CRUD style apps and "sites" than Lift, but Lift would be better for rich apps. That's an opinion of course, and it is totally possible to build CRUD apps with Lift, of course it is, but rather, if you're looking for top line differentials then its a reasonable starting point.

Without repeating all of chapter 1 of Lift in action, Lifts view first approach is specifically different to the action-style view dispatch found in frameworks like Play!, Rails and Django (diagram of which can be found in one of my old presentations: http://www.slideshare.net/timperrett/javazone-2010liftframeworkpublic ). By not having to decide on a "main" piece of functionality as one would have to with action based view dispatch, you can build highly reusable components of functionality.

I'll try to dig up the video to go with the aforementioned slides as that was a good introduction to some of the key Lift features.

Cheers, Tim

[Timothy Perrett]

Here's that video:
http://vimeo.com/28591363

[Bear Bibeault]

Thanks, the video was very informative.

One question that came to mind: in the video you stress XHTML -- how do Lift templates fit in with non-well-formed HTML5?

[Timothy Perrett]

Good question. In 2010 the HTML5 situation was more confussed, but these days Lift has full parser support for all the regular HTML, XHTML and HTML5 formats (where "support" is built in parsing and transformation if desired)

Hope that helps!

Tim

[Bear Bibeault]

Not sure yet...

Does Lift expect non-Lift markup to follow certain rules? Or is it like JSP where anything that's not a JSP element is simply template text that's sent verbatim in the response?

I'm thinking of use cases like custom attributes and the like.

[Timothy Perrett]

Bear Bibeault wrote:Not sure yet...

Does Lift expect non-Lift markup to follow certain rules? Or is it like JSP where anything that's not a JSP element is simply template text that's sent verbatim in the response?

I'm thinking of use cases like custom attributes and the like.

Provided the XML being sent to the browser passes the (for example) XHTML parser (meaning all tags are properly closed), then you can essentially do whatever you want. Lift will automatically sanitise the content by escaping entities etc etc, but otherwise provided it passes parsing you should be fine.

Thanks, Tim

[Bear Bibeault]

As we know, HTML5 can be written using well-formed markup or non-well-formed markup. So the non-well-formed formats of HTML5 would cause problems?

Just curious: why does Lift care about non-Lift markup? Why does it not treat non-Lift-markup as opaque template text?

[Timothy Perrett]

Bear Bibeault wrote:As we know, HTML5 can be written using well-formed markup or non-well-formed markup. So the non-well-formed formats of HTML5 would cause problems?

Just curious: why does Lift care about non-Lift markup? Why does it not treat non-Lift-markup as opaque template text?

No not at all. The HTML5 parser handles that without issue. If there are any problems, there down to the parser and not Lift (the parser is: http://about.validator.nu/htmlparser/).

Lift treats its templates as XML because it allows us to do some much more sophisticated things within the template handling rather than simply munging strings around which is a nightmare. Additionally if you know that all your template code is XML, you have to then be explicit about passing unparsed data into the output stream which makes it harder for developers to unwittingly add security holes into their apps, as they have to explicitly say "this ABC here is Unparsed".

Hope that helps

[Bear Bibeault]

Excellent -- I really like the approach taken.