5 ms·

I use Lift. There could be better frameworks, Lift looks terribly complicated and verbose, but it's fast and works. I'm not into ORMs, but use the Lift ORM to

I use Lift. There could be better frameworks, Lift looks terribly complicated and verbose, but it's fast and works. I'm not into ORMs, but use the Lift ORM to get started before writing JSON to NoSQL storages. IDE: Intellij with the Scala plugin. I will possibly use Mustache templating via Scalate in Lift instead of the Lift version, as Mustache templates can be reused in the web frontend in Javascript. SBT with ~test-quick and Specs is fantastic for TDD. I've played with Play alot, it's nice but the default Groovy templating is slow as hell and I'm not sure their usage of exceptions for work flow does scale - from my operations experience I think it won't (perhaps this changed in the last 5 months).

alnayyir 16y ago
>I've played with Play alot, it's nice but the default Groovy templating is slow as hell and I'm not sure their usage of exceptions for work flow does scale - from my operations experience I think it won't (perhaps this changed in the last 5 months). Fixating on the way wrong things here. Cf. rb2k_
- Uchikoma 16y ago
  Care to elaborate?
  - alnayyir 16y ago
    All it takes is for 5% of your requests to require a uncached database fetch for your concurrency model and I/O handling to be more important than rendering or other CPU bound activities in the process of serving a request on the frontend. Wrong priorities in the absence of circumstantial profiling.
    - Uchikoma 16y ago
      "Wrong priorities in the absence of circumstantial profiling." Puh, then I'm glad we extensivly profiled our app.
    - Uchikoma 16y ago
      If Groovy is 20x slower than Java templating, but 5% more uncached database fetches, which is faster?
      - alnayyir 16y ago
        It depends!
kingcub 16y ago
We used lift, we're in the process of ripping it out and replacing it with something else, anything else really. When I last checked a few month's ago, Lift's documentation is terrible given it's complexity. A project that is as large as Lift cannot be learned by scanning the source code and the number of examples out there to do something really custom is lacking. Tons of it's source files have only the slightest smidgen of Scaladoc if any at all. Also anything that actually is documented is probably deprecated or about to be usurped by another feature. No classes should be added to lift without proper documentation added first. Yes it's open source, yes no one wants to write documentation at the end of the day it hurts the project however. I don't want one on one support or having to write to mailing lists I want a good explanation of what is going on top to bottom. However I hear over and over it has worked wonders for other people, so YMMV. It's certainly not the only way to make a Webserver in Scala it just has the benefit of being one of the first big Scala projects, and it has used that time to bloat out and grab as many features as it can without documenting them properly.
- gtani 16y ago
  books on Lift 2 http://manning.com/perrett http://manning.com/perrett (Manning's always running some promo codes, so ~$20 for MEAP and final PDF book) http://simply.liftweb.net/Simply_Lift.pdf http://simply.liftweb.net/Simply_Lift.pdf
  - kingcub 16y ago
    While I really hope these develop into good resources, The first one isn't out. The second one is not remotely usable by itself at the moment. Most of the chapters are empty. There is a smattering of code that revolve around some very basic things can be found in other Lift books (which are now outdated). The 4th longest chapter (ch 15) is a wall of text & self promotion that goes on about how Scalable/Better Lift is than other frameworks.[1] BTW Here is another book, that is, to my knowledge, the most complete free reference available for Lift: http://groups.google.com/group/the-lift-book?pli=1 http://groups.google.com/group/the-lift-book?pli=1 Here is a [link](http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/scaladocs/index.html http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/s...) to the Lift Scaladocs. Most methods do not have any descriptions, several classes don't either. This forces digging through source code / searching and asking question on the mailing list to figure out how Lift wants you to do something. Ultimately, with how fast Lift moves it's really hard to have any faith in any book keeping up. 1: Even when using Lift’s session-afﬁnity dependent features, Lift applications have higher performance, identical availability, identical scalability, better security, and better user experience than applications written with web frameworks such as Ruby on Rails, Struts, and GWT.

alnayyir 16y ago

>I've played with Play alot, it's nice but the default Groovy templating is slow as hell and I'm not sure their usage of exceptions for work flow does scale - from my operations experience I think it won't (perhaps this changed in the last 5 months). Fixating on the way wrong things here. Cf. rb2k_

Uchikoma 16y ago
Care to elaborate?
- alnayyir 16y ago
  All it takes is for 5% of your requests to require a uncached database fetch for your concurrency model and I/O handling to be more important than rendering or other CPU bound activities in the process of serving a request on the frontend. Wrong priorities in the absence of circumstantial profiling.
  - Uchikoma 16y ago
    "Wrong priorities in the absence of circumstantial profiling." Puh, then I'm glad we extensivly profiled our app.
  - Uchikoma 16y ago
    If Groovy is 20x slower than Java templating, but 5% more uncached database fetches, which is faster?
    - alnayyir 16y ago
      It depends!

kingcub 16y ago

We used lift, we're in the process of ripping it out and replacing it with something else, anything else really. When I last checked a few month's ago, Lift's documentation is terrible given it's complexity. A project that is as large as Lift cannot be learned by scanning the source code and the number of examples out there to do something really custom is lacking. Tons of it's source files have only the slightest smidgen of Scaladoc if any at all. Also anything that actually is documented is probably deprecated or about to be usurped by another feature. No classes should be added to lift without proper documentation added first. Yes it's open source, yes no one wants to write documentation at the end of the day it hurts the project however. I don't want one on one support or having to write to mailing lists I want a good explanation of what is going on top to bottom. However I hear over and over it has worked wonders for other people, so YMMV. It's certainly not the only way to make a Webserver in Scala it just has the benefit of being one of the first big Scala projects, and it has used that time to bloat out and grab as many features as it can without documenting them properly.

gtani 16y ago
books on Lift 2 http://manning.com/perrett http://manning.com/perrett (Manning's always running some promo codes, so ~$20 for MEAP and final PDF book) http://simply.liftweb.net/Simply_Lift.pdf http://simply.liftweb.net/Simply_Lift.pdf
- kingcub 16y ago
  While I really hope these develop into good resources, The first one isn't out. The second one is not remotely usable by itself at the moment. Most of the chapters are empty. There is a smattering of code that revolve around some very basic things can be found in other Lift books (which are now outdated). The 4th longest chapter (ch 15) is a wall of text & self promotion that goes on about how Scalable/Better Lift is than other frameworks.[1] BTW Here is another book, that is, to my knowledge, the most complete free reference available for Lift: http://groups.google.com/group/the-lift-book?pli=1 http://groups.google.com/group/the-lift-book?pli=1 Here is a [link](http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/scaladocs/index.html http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/s...) to the Lift Scaladocs. Most methods do not have any descriptions, several classes don't either. This forces digging through source code / searching and asking question on the mailing list to figure out how Lift wants you to do something. Ultimately, with how fast Lift moves it's really hard to have any faith in any book keeping up. 1: Even when using Lift’s session-afﬁnity dependent features, Lift applications have higher performance, identical availability, identical scalability, better security, and better user experience than applications written with web frameworks such as Ruby on Rails, Struts, and GWT.