4 ms·

1. Fetching content with AJAX and placing it into the DOM is "supported" by every web framework in existence. 2. Proxying ads through your own backend that thr

1. Fetching content with AJAX and placing it into the DOM is "supported" by every web framework in existence. 2. Proxying ads through your own backend that threads itself? Yawn. 3. AJAX and COMET have pretty standard support. Again, this is left up to you with your Javascript library of choice. 4. Again, this is Javascript work. It might save me a little bit of development time, but I'd much rather be in complete control over the process of wiring my pages together. 5. Calling controls through classes isn't any more designer-friendly than Rails or Django template tags. 6. Pretty sure both Rails and Django have one-click install extensions for form Wizards (Rails might support it out of the box, haven't played with 3 enough lately to know) 7. All of these security principles are taken care of my every major web framework I can think of. So we have some magic Javascript-generating controls and... that's it. Those are nice conveniences for sure, but a lot of these are uncommon use-cases, and I know I can probably bang-out a Django app to handle most of them in an afternoon, or just pull the real Javascript code I've used to handle these cases a dozen times over in the past. The condescending attitude and failure to meet expectations means I'll probably never look at this framework again, which is a shame because it seems like it might be neat to toy around with. Too bad.

aaronblohowiak 16y ago
1. Lift goes further in enabling convention over configuration for common AJAX tasks that are part of normal workflows, so there is less boilerplate to write. 2. Parallel rendering means you can move to a SOA where different components on the UI are served by different backend services. This can be great if you have a recommendation service, a shopping cart and main content areas that are all served by different systems that may have different performance characteristics.. It also parallelizes the loading of the different parts of the page, which should decrease page load time. 3. Is there good comet support in existing frameworks out of the box? How would you easily update a partial in a rendered page when an object changes in rails or django? With Lift, you can hook up the rendered page (and its events) to server-side Actors... without any boilerplate code. This helps the productivity of development and (AFAIK) is still a rare feature. 4. You do have complete control, it is merely a matter of style. Lift does more things server-side. 5. One of the differences is that you don't need to have "partials", which could be more designer-friendly. I agree that this isn't a huge win. 6. yep. 7. I don't think the "No Direct Object Reference" security principle is taken care of by any other major web framework. It is a pretty big win for security -- because all of your exposed ids are session-specific, whole classes of problems just "go away". I'm not saying that Lift is to Rails/Django what Rails/Django was to PHP, but it does have some interesting features that set it apart. Note: I have a bias.
- zem 16y ago
  > Is there good comet support in existing frameworks out of the box? nitrogen [http://nitrogenproject.com/ http://nitrogenproject.com/] is worth a look
eeperson 16y ago
3. Ajax support seems pretty common but Comet seems pretty rare. Most major Javascript libs seem to have little or no support for Comet. Also, server side support for Comet seems even rarer. 4. Declarative syntax for dependencies seems much simpler than imperatively updating dependencies in Javascript 5. This one isn't presented very well. Essentially, all server side presentation logic is done in Scala code rather than adding custom HTML generation tags (<iterate>, <if>, etc.). This seems like a win (assuming the Scala syntax isn't awkward to work with) and something that I haven't seen before. 7. I have never seen web frameworks with built in support for A4 and A5 If these are things you have seen in other web frameworks I would be very interested to know where. I'm mostly coming from web frameworks on the JVM so it would be good to know more about what I am missing from frameworks outside of that. I think your right that this is poorly written and maybe a little off putting. However, I think some of the stuff they present looks novel and useful. Edit: formatting
- shadowfiend 16y ago
  Re: 5., the Scala syntax isn't awkward to work with at all. In fact, it's based on CSS. For example: <ul class="l:Users.userList"> <li class="user"> <span class="username">shadowfiend</span> <div class="profile"> <ul> <li class="name">Person Name</li> <li class="hometown">Hometown, ST</li> </ul> </div> </li> </ul> class Users { lazy val users = User.findAll() def userList = { ".user" #> users.map { user => ".username" #> user.username & ".name " #> user.name & ".hometown " #> (user.hometown + ", " + user.state) } } }

aaronblohowiak 16y ago

1. Lift goes further in enabling convention over configuration for common AJAX tasks that are part of normal workflows, so there is less boilerplate to write. 2. Parallel rendering means you can move to a SOA where different components on the UI are served by different backend services. This can be great if you have a recommendation service, a shopping cart and main content areas that are all served by different systems that may have different performance characteristics.. It also parallelizes the loading of the different parts of the page, which should decrease page load time. 3. Is there good comet support in existing frameworks out of the box? How would you easily update a partial in a rendered page when an object changes in rails or django? With Lift, you can hook up the rendered page (and its events) to server-side Actors... without any boilerplate code. This helps the productivity of development and (AFAIK) is still a rare feature. 4. You do have complete control, it is merely a matter of style. Lift does more things server-side. 5. One of the differences is that you don't need to have "partials", which could be more designer-friendly. I agree that this isn't a huge win. 6. yep. 7. I don't think the "No Direct Object Reference" security principle is taken care of by any other major web framework. It is a pretty big win for security -- because all of your exposed ids are session-specific, whole classes of problems just "go away". I'm not saying that Lift is to Rails/Django what Rails/Django was to PHP, but it does have some interesting features that set it apart. Note: I have a bias.

zem 16y ago
> Is there good comet support in existing frameworks out of the box? nitrogen [http://nitrogenproject.com/ http://nitrogenproject.com/] is worth a look

eeperson 16y ago

3. Ajax support seems pretty common but Comet seems pretty rare. Most major Javascript libs seem to have little or no support for Comet. Also, server side support for Comet seems even rarer. 4. Declarative syntax for dependencies seems much simpler than imperatively updating dependencies in Javascript 5. This one isn't presented very well. Essentially, all server side presentation logic is done in Scala code rather than adding custom HTML generation tags (<iterate>, <if>, etc.). This seems like a win (assuming the Scala syntax isn't awkward to work with) and something that I haven't seen before. 7. I have never seen web frameworks with built in support for A4 and A5 If these are things you have seen in other web frameworks I would be very interested to know where. I'm mostly coming from web frameworks on the JVM so it would be good to know more about what I am missing from frameworks outside of that. I think your right that this is poorly written and maybe a little off putting. However, I think some of the stuff they present looks novel and useful. Edit: formatting

shadowfiend 16y ago
Re: 5., the Scala syntax isn't awkward to work with at all. In fact, it's based on CSS. For example: <ul class="l:Users.userList"> <li class="user"> <span class="username">shadowfiend</span> <div class="profile"> <ul> <li class="name">Person Name</li> <li class="hometown">Hometown, ST</li> </ul> </div> </li> </ul> class Users { lazy val users = User.findAll() def userList = { ".user" #> users.map { user => ".username" #> user.username & ".name " #> user.name & ".hometown " #> (user.hometown + ", " + user.state) } } }