Wednesday, December 16, 2009

Lift from a Wicket Developer's Perspective

I've been messing around with Scala again lately. After learning the basics of the Scala language, I decided to have a look at the lift web framework - "the simply functional web framework". In this highly subjective post I will outline, why I'll stick with Wicket.

My Lift Experience


To be clear, I'm not an experienced Scala developer. I did my first steps in Scala a year ago or so, and I just started learning Lift by having a look at the getting started guide. But this short first impression was enough for me to decide, that I'm not going any further with lift. Without going into much detail, here's why:

  • Lift is a template driven framework, whereas Wicket is component based. In Lift you compose a page of (X)HTML templates, called snippets. In Wicket you compose a page of components, i.e. not through (X)HTML but through an object graph/hierarchy. Lift's template approach allows for reusable templates, but I like the Wicket's object oriented, hierarchical approach much more.

  • There's not much documentation on Lift. There is the getting started guide, but the examples did not work immediately, because the API had changed. This troubled me a lot. Also, there's not much documentation in the source code.

  • A positive aspect of Lift is that it comes with an integrated OR-Mapping API, which looks quite interesting. Also there's a nice query API that can be compared to Hibernate's criteria API, and at first glance it looks even nicer. I heard that lift also runs on Google App Engine (?). I wonder, though, how hard it was to get this integrated OR-Mapping/Query API to run on GAE.

  • The model/entity classes have too many responsibilities. They contain validation logic and OR-mapping logic. This is okay so far. But there's also conversion logic in there, e.g. from String to the specific data type, and there's also code for HTML and even JavaScript generation. The MappedBoolean class for example, which is used to represent a boolean property of an entity, also has methods like toForm, which yields a (X)HTML checkbox element, and asJsExp, which yields the corresponding JavaScript expression of the value. I'd rather seperate these responsibilities into more than one class.

  • In general, the seperation of presentation content and logic is not quite as good as stated in the getting started guide. Here is an example snippet from the getting started guide:

    Without getting into the details, this method contains presentation logic in the form of HTML span elements and a checkbox input element generated by the ajaxText call. Actually, these aren't really HTML element strings in the code but this is Scala's XML support. But that does not make it better, right? You'll never - well, almost never - see such things in Wicket.

  • Lift is a Scala web framework, Wicket is Java. And although Scala in general is a great language and superior to Java in many aspects, I'm still not quite sure whether it will become my first language of choice ever. I still have some issues with it.

  • Related to this is the tooling aspect. The IDEs (Eclipse, IDEA) still lack full support for the Scala language. Maven support for Scala/Lift is quite good, though.



So, this is was my first impression of Lift. Don't get this wrong, Lift has some interesting aspects and in some ways it's much better than many other Java frameworks. But if I had to choose a web framework for a green field project right now, I'd certainly go with Wicket.





18 comments:

kopfkind said...

Thanks Nick for the comparison between Lift and Wicket. I've also been 'messing around' with Scala lately - mostly around the interesting articles in IBM's developerWorks and then reading the book "Programming in Scala" (still in progress).

I share your opinion about Scala being more elegant in many cases than Java, but I will also stick to classic Java web frameworks for the "dirty work". My favourite currently is Spring MVC, especially with Roo and the new Spring release today.

Ben said...

As a Wicket/GWT developer with an interest in Scala, I'm a little disappointed to hear that there are these kinds of problems. I still might give Lift a try.

Nick Wiedenbrück said...

@Ben Sure, go for it. It's not my intention at all to discourage anyone from having a look at Lift. It was also a worthwhile experience to me. And it's probably a lot of a matter of taste, too. So Lift might be a good choice for you.

Anonymous said...

As a Wicket developer with a strong interest in Scala (written two webapps with Wicket + Scala):

I like Lift better than Struts or JSF, but at the same time it got a bit over-excited with Scala: just because XML support is there, you don't have to push to use it in presentation. Same thing with ORM support: feels like Lift is trying to do too many things for too many people.

One of the strengths of Wicket is that it has a strong sense of core purpose and doesn't try to do things beyond it (third party add-ons do that) and composability rather than being all things to all people.

Jim Barrows said...

You don't have to use Mapper at all if you don't like it. Lift isn't tied to it. I use lift quite easily with JPA for instance.
Also you're going to have to put logic in the view at some point. Lift says keep it out of the HTML, and put it in what some would call the controller. This means that sometimes your view leaks into the controller.
A snippet isn't the xhtml page, it's the code that the xhtml page refers to/calls. A snippet isn't really a controller either.
Taken together the XHTML and the snippet are a component, and can be treated as such.
However, the tag line for lift is the key to understanding it I think. "The simply functional web framework". Functional in this case is overloaded. Not only functional in that it works, but functional in a functional language kind of way.
Since Scala lives at the Functional/OO boundary, it makes sense that Lift does as well.

Steve said...

Had some thoughts, both pros and cons of Lift:

PROS:
1) Lift *does not* force you to use presentation in your Scala code, it is not even the recommended approach. This is what bindings are for.
2) The current IDE support for Scala in Eclipse may be a little rough, but it is certainly quite usable.
3) One of the things that I particularly like about Lift is that, unlike Wicket, component reuse doesn't mean tying an HTML panel to backing code. The problem of the panel is that often I don't know the particular context in which the presentation will need to occur (are these two collaborating form fields in a table/fieldset/other), which is very limiting.
4) In terms of bindings, I can bind many things in a Lift snippet that I don't necessarily use in the page. In one context I might need a person's first and last names, in another I might need quite a bit more. With a single snippet I can adequately address both needs. This is the advantage in (again) not tying the backing logic for a component to a single presentation.
5) I've got Mapper in Lift. After my last Wicket project, where the team used Hibernate (oh the humanity), the ORM in Lift is like a breath of fresh air. It does with the database what you would expect. Unfortunately, in Wicket (and I understand this) there is no particular persistence hooks - the framework is for the front end only.
6) Though it was not mentioned, there is a book available on Lift. It isn't as good as 'Wicket In Action' and is too thin in many areas, but it can be found on the Internet for free and has been a great help to me so far.
7) There seems to be a whole lot less plumbing required in Lift for many common web-isms. Out of the box Lift not only has an ORM solution, but also SiteMap for site menuing and particularly easy to set up email support. The fact that one of its archetypes also takes care of setting up basic user handling is a huge bonus.

CONS:
1) It is not at all clear to me how to do in Lift some of the AJAX things that I used to do in Wicket. The learning curve seems steeper.
2) I agree that it is possible to define too much logic inside the entities in Lift. While I appreciate the use of object fields, I think that stuff like HTML/JS/validation should be deprecated and that this should only be done in the snippets.
3) I kind of liked that in Wicket there was never any need to do anything with JS. I think I can avoid it for the most part with Lift, but I know that the framework takes great advantage of JQuery.
4) Snippets are more terse than the equivalent code. As a relative newbie to Lift, I'm starting to grow accustomed to this terseness, but it is going to take some time.

All that said, I have a very healthy amount of respect for Wicket, and have championed its use on several projects. I think that the draw of Lift for me is that it is a more 'batteries included' type of framework in which I can leverage Scala to turn around behavior in a shorter amount of time.

For those who are going to use Wicket, please at least don't punish yourself by doing so with Java. Wicket and Scala are so good together that it was originally hard for me to get interested in Lift.

Web design Firm said...

Hi

Great information in this post and this short first impression was enough for me to decide, that I'm not going any further with lift.

James Parker.
Web design Firm

strumpfhosen said...

As a Newbie, I am always exploring online for articles that can aid me. Thank you

Unknown said...

I am amazed to see such an amazing post. Keep up the good work.lg parts

Water Filter Canada said...

I am so happy to read this. This is the kind of manual that needs to be given and not the random misinformation that is at the other blogs. Appreciate your sharing this best doc.

Forsyth Septic said...

Simply want to say your article is as surprising. The clearness in your post is simply great and i can assume you are an expert on this subject. Fine with your permission let me to grab your RSS feed to keep up to date with forthcoming post. Thanks a million and please continue the rewarding work.

Hotpoint FF4DK said...

Thanks you. Very good post.Unless they can offer a really compelling reason for users to come back, it will be the next Bebo, MySpace

Training Tampa said...

It is an interesting post, and really appreciable. The clearness in your post is simply spectacular and i can assume you are an expert on this subject. I will grap each and every information and refer to my friends also.

filters for fridges said...

Thanks, great post

Vancouver Internet Marketing said...

Thank you, thats very interesting information. I need to share with my friends.

Channing Tatum workout said...

This blog is awesome full of useful information that i was in dire need of.

Beyonce workout said...

Another informative blog… Thank you for sharing it… Best of luck for further endeavor too.

Luxury Watchmaker said...

Excellent site, keep up the good work my colleagues would love this. I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say I’m glad I found your blog.