Hacker News Reader

Care to expand on why Lift is crap? (I still have paltry experience with it, but I also still feel it has the best template mechanism out there.)

I spent quite a bit of time evaluating Lift for some fairly significant (2 man-year+) projects. My final conclusion is that while it is technically brilliant, and many of the concepts make a lot of sense, it's just very hard come up to speed on and be productive in, especially if you aren't already a Scala wizard. Any Lift project is likely to have a fairly low "bus factor" if you don't already have multiple strong in-house Scala folks.

I had some technical concerns as well - in particular the database connectivity stuff is a bit painful.

Hmm.. I'd never heard of the term bus factor. Amusing concept. How do you feel Lift compare with the likes of Play?

I can say that the few small things I pushed out with Lift greatly benefited from the fact that the views were strictly html. To the point that nobody else involved even had to learn scala. Even though they did make some changes to the scala code. Being able to let folks edit that to their hearts content was ridiculously nice. That is, the fact that I did not have to (a) educate everyone on the templating mechanisms or (b) split apart templates received from someone else was huge.

As for the database connectivity, I guess you didn't like the agnostic approach they took?

Re: Templating

I can see how that's a factor for some, but since around here I'm also the guy who writes all the HTML it isn't really a factor one way or the other.

Re: Databases

Yea, ActiveRecord tends to spoil one. I don't like any of the Java ORMs nearly as much as AR, or SQLAlchemy for that matter.

Re: Play

I like Play a lot less than Lift. Lift I could see using for a personal project. Play I could not. It's just like Rails but crappyier and with all the java headaches and baggage.

Awesome. Thanks for the responses!

> Yea, ActiveRecord tends to spoil one. I don't like any of the Java ORMs nearly as much as AR, or SQLAlchemy for that matter.

That's a funny thing to say considering the huge difference in philosophy between Active Record and SQLAlchemy.

There's nothing unique about lift's template system though, you can get something like that in many languages, potentially while also using a good framework.

I have not seen another templating system that compares. What other framework has it such that the templates are html. Not "html like" but actual html?

Honestly, I think for me the big win with them is actually the inversion of how the template is done. Instead of writing some template that specifies how it is manipulated, you write a template and then directly manipulate it in the framework. (That make sense?) In essence, it seems that it is automating the typical first task on getting some html from a designer. This is great, because often the template can be redone and then all of the modifications the programmer was going to make to them is just part of the framework.

As noted by TylerE above, I can see how this might not be a factor. I personally loved it.

http://en.wikipedia.org/wiki/Template_Attribute_Language is the most widespread example. We ended up switching to haskell and using heist, which is the same type of deal. The "view first" thing was certainly very irritating, but minor overall compared to other weaknesses in the framework.

Any better examples? Neither of those appear to have the same strengths I was referring to. (Not to say they are crap. Just not the same.)

Though, similar to TylerE, I'm curious to hear what you think are the other weaknesses? Similarly, how do you feel it compares with its peers? (A peer being a JVM targeted framework.)

I don't know what you are referring to. What strengths? They are html templates.

If you are going to restrict "peers" to jvm frameworks then I really can't offer you anything. I haven't used any other jvm frameworks, I tried the two scala options (lift and play) and ran screaming.

First, apologies for taking so long to respond. I almost just edited my other post. (For some reason the "reply" link wasn't coming up.)

Regardless. I see that the Heist language looks like early Lift templates. They got stronger with time. For the TAL stuff, it looks like logic is directly placed in an attribute. Probably both would be a far cry better than the stuff I have become accustomed to, however, Lift still seems stronger. Again, the difference comes in how the templates are "split" and placed in the app. The lift way just requires judicious useage of class names.

Moving past that, though, I'm still interested to hear an analysis if you are up for giving it. While I'm most likely to only understand what I called "peer" comparisons, I'm interested in all.

Edit: Further apologies in that I am likely not going to be able to respond for a while at this point. So, thanks for the discourse!

>They got stronger with time

Stronger how? It is just a pseudo-html document tree being manipulated in scala. I'm not sure how it can become stronger or weaker.

>For the TAL stuff, it looks like logic is directly placed in an attribute.

It is placed wherever you want it. Using a TAL loop attribute is no different than doing the same thing in lift. The only difference is that lift doesn't show doing that in the docs, so people tend not to do it.

>Again, the difference comes in how the templates are "split" and placed in the app

I still don't understand what you mean. We literally took our lift templates and used them in heist just doing a search and replace s/lift://g. We just had to change the scala code "snippets" to be haskell code "splices".

>I'm still interested to hear an analysis if you are up for giving it

Lift assumes too much, and if you go outside those assumptions you are basically stranded. Combined with just being an immature framework where there's things missing/incomplete, and an outright hostile community, it makes things pretty difficult. Form handling was the biggest sticking point, especially when you want to have forms that aren't protected by their CSRF tokens and need to work with cookies disabled. It becomes a case of "well, we don't want to support that so just do it yourself from scratch".

Play we had tons of issues with the weird scala templates they use. It would barf frequently on what appeared to be perfectly valid syntax. Combined with the "developing with play is super fast!" sales pitch, while being slower to recompile than lift was, we didn't bother spending much more time on it.

I should have made clearer that I am reading on those template engines right off. That is, I hadn't really heard of them till you mentioned them. Asking for more was simply on the lines of "if you have other examples right off."

Regarding TAL. Looking at it, it did not look like it fed in the markup of the current tag to anything to process it. That is likely just my misreading of the wiki page.

Regarding Heist. This could again just be my hasty reading, I think. I saw it said it was the same idea as the Lift templates. But then it jumped straight into the bind and apply tags. With the latest lift templates, there are no custom tags. Nor are there custom attributes.

Also, I'm highly curious on the upsides of the Haskell framework you are using.

And again, thanks for keeping this going!

>That is likely just my misreading of the wiki page.

I would say the fault there lies 100% on the docs, not you. The docs are heavily focused on using the attributes that are provided out of the box, rather than on how to write your own.

>But then it jumped straight into the bind and apply tags

That's the equivalent of lift:surround. There's nothing special about those tags, they are just part of the set of default splices that you can use.

>With the latest lift templates, there are no custom tags. Nor are there custom attributes.

What are there instead? The docs still appear to be talking about lift:stuff tags and attributes. There aren't really custom tags or attributes in heist either, unless you want there to be. You are really just binding some haskell code to a tag or attribute. That tag could be a real html tag (like the splice included by default that is bound to the html tag, which consolidates multiple head tags into one). Or it could be a any tag you make up, like we bind a splice to the <user> tag which replaces the contents with the user data.

>Also, I'm highly curious on the upsides of the Haskell framework you are using.

Shockingly enough considering how haskell is known for slow compile times, faster compilation is one of the upsides. Mainly we used snap because it gives us the same thing we liked about lift (templates), but with no assumptions about how things have to work, a more helpful community, and a better language.

I think this does highlight the major problem with lift, which is just scattered documentation. The "designer friendly" templates push all of the lift:foo stuff into class names in the template.

That is funny to hear that haskell compiles faster. Seems scala is really becoming the language known for the slow compilation nowdays. I think there is some form of irony to that. (Though, I had not actually heard haskell was slow. I just know it doesn't target the jvm, which is where I've been living for a long time.)

Regardless, thanks again for coming back to this!

>The "designer friendly" templates push all of the lift:foo stuff into class names in the template.

Oh, I realize you can do that also, I just didn't recognize that there's any difference. <lift:foo> and <div class="lift:foo"> are identical right? Heist lets you do both too.

>That is funny to hear that haskell compiles faster.

Not in the general case, but specifically with snap. I'm not sure what magic they have going on in their dynamic loader, but it is much faster than the one yesod uses for example (another haskell framework).

The difference is pretty much strictly whether it can validate and generally display correctly. I seem to recall browsers were less than good about the tags, whereas just having the classes works great to bang away at a template, and then use it.

Cool to see that Heist is effectively the Lift templating system. I suppose I shouldn't be surprised to see some movement in that direction. I do still for more templating like this in the jvm, though. I'll have to look into TAL more when I get the chance.

Of course, right now I'm having to use GWT for a project. Don't know why, but I loath UiBinder. And, well, most of GWT at the moment. :(

As someone who's just learning lift, it's woefully underdocumented. You can do some really cool stuff with it, but learning requires scrounging tutorials from random blogs, and it then turns out half of them are out of date.

Templating wise the Wicket approach is the best I've ever used, and I wish that style was available in other languages. You don't put any logic or control in your templates; your object graph in code controls your page hierarchy, your components are genuinely reusable objects.

Yeah, I should have mentioned Wicket (it is credited as an influence for lift, after all). I can't remember what made that so difficult to work with. I think it was because you had to effectively mirror the template in code at parts, if I recall. As I noted somewhere else, the lift way of more directly manipulating the template is what I like. (That is, I don't have to have a ton of "liftId" attributes added to the template. In general, I just need the base class attribute added, and then I can manipulate the template using css selectors. This does mean some shape of the template has to be preserved, but I haven't found that limiting yet.)

You should look at Scalatra before dismissing scala web frameworks. It is very simple and easy to use.

Like I asked in other thread, do you have any opinions about Scooter http://www.scooterframework.com/ and ActiveWeb https://code.google.com/p/activeweb/ ? These looks more RoRish and productive than Play!. Also, some users of Play! 1.x looking to fork the framework for better support (I think) https://groups.google.com/forum/#!forum/playone

Can you provide any specific, actual, practical evidence that it is a bad thing to use a dynamically typed language to write a web app? Or is this just a personal prejudice?

>Can you prove your opinion is objectively correct, or is it just your opinion?

Doesn't that question seem rather non-productive? At least if you asked why he has that opinion you could engage in some sort of potentially constructive conversation on the topic.