Sv: [Lift] Lift/Scala over Java/Spring/Struts

[Andreas Joseph Krogh]

På tirsdag 21. mai 2013 kl. 19:03:14, skrev Rohit Pathak <insolen...@gmail.com>:

Hi guys, I have been using Lift/Scala for some time. Using lift mainly I have been doing POC and preparing prototypes. I am an old user, but not an expert on Spring or Struts framework, nor of Lift, but I would still prefer Lift over these. Recently I have been handed over to lead a web application project (appox. 18-20 people), but I am finding it hard to convince my upper management to choose Lift/Scala for this development, instead of Java/Spring/Struts. Can any expert of frameworks (such as Spring/Struts) help me identify some key areas/points where Lift beats Spring/Struts so that I can get help convincing the management about Lifts advantages.

However on the downside I know that we don't have a mature IDE support and documentation support for Lift.

Thanks in advance.

 

I used to be a hard-core Struts/Struts2 user (used Struts since before 1.0 and never really bought Spring-MVC), but have used and still am using Spring extensively otherwise. In 20011, after having used Scala with Struts2+Spring for ~2 years I finally chose to jump on the Lift-train. It was then I really learned how to exploint the power of Scala and functional programming, with great help from this great Lift-community (which also happens to be the best support-forum I've ever experienced).

 

Back in 2009 the IDE argument could hold water, but not today. Both IntelliJ (which I perfer) and Eclipse Scala IDE are really great. I work on a project with 50 modules (using Maven), some mixed Scala/JAVA and some pure Java and Scala, which has 70K lines of Scala code and 180K lines Java code and IntelliJ manages just fine, navigating between mixed Scala/Java-classes with ease.

 

The absolute key sellingpoint for me is typesafety, in all layers of the app. Especially in the presentation-layer Lift excels. Having such a clear separation between templates(markup) and logic (snippets etc.) has become a must for me. We can now refactor just about anything without having to fear some random page blowing up due to fragile use of reflection-based web-frameworks which operates on JSP/Velocity etc. Other than type-safety Scala's expressiveness, being a combo FP and OO-language, together with native XML-support and how Lift does Css Selector Transforms is what I enjoy the most. Lift also has the best AJAX and comet-support, with minimal boilerplate needed.

 

Having said that I have some experience converting JAVA-temas to Scala and that is not always easy. It takes time to learn new paradigmes, and un-learn much of old useless patters.

 

Thanks.

 

--
Andreas Joseph Krogh <and...@officenet.no>      mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

 

[Austen Holmes]

I recently converted a spring mvc application to Lift.  The spring application was written in a mixture of scala and java.  I have never used Struts.

The biggest selling points for me:

Lift supports all of the concepts of Struts, Spring MVC, etc, but to make those frameworks support all of the concepts of Lift, you would spend a few years writing large numbers of libraries.

Ajax is built right in, and very secure.  If you wanted to build a generic event handling mechanism for Spring MVC, you would have to expose a controller and manage mapping client events to executable function handlers on the server side.  Ensuring this controller isn't open for attack probably isn't a simple task.

For event-driven programming, as most user-facing applications are, having higher-order functions in a language greatly reduces this task as well.

If you use lift webkit, for example, the framework is built for the web.  It understands the differences between production, staging, and test environments, and you can use those concepts to customize your environment (a must for a production application.)

Building a lift application feels very similar to building a client web application.  If you are familiar with jQuery selector transforms, you can use the same concept when using lift's templates.  This has been the quickest way for me to expose developers to lift.  I ask them to write a simple snippet, so they get the feel of using CSS selectors/transforms.

You can use any Java library you wish.  I make use of quite a few (Amazon S3 API being the most prominent).

As mentioned by another user, separation of presentation and logic is great.  My html is MUCH cleaner, I don't have velocity/freemarker/jsp code intermingled with html, etc.  I can create a page in html, put some placeholders there, and run it through snippet resolution.

Lift is VERY configurable.  This is scary at first, but in the end becomes a great tool.  Being able to swap out implementations for a session, request, etc (even as granular as a single use) can be very powerful.  I can envision a scenario where you have 2 implementations of the same trait, one for power users, one for everyone else.  You wire up the correct class when the session is created.  It makes security/access policies very simple.

Things you may want to consider:

Lift generally has many different solutions to the same problem.  For larger teams/codebases, this becomes an issue.  Come up with some Lift Design Patterns that work for your organization, document them clearly, and ensure users adhere to them, especially during the transition.

Encourage your devs to use the community.  This has actually been difficult for me to get across to some users.  The community is generally very helpful and will, more often than not, respond to even the most obvious questions.

Lift is lacking documentation for a lot of its internals.  I've had to walk the codebase a few times to figure out what's happening.  It's not always clear in Scala code exactly what's happening (this applies to most other Scala frameworks).

To sum it up, the developer we just hired said that Lift feels like a framework that was made to make modern web development more easy.  With all of the other frameworks, web development feels like an afterthought.

-Austen

[Diego Medina]

However on the downside I know that we don't have a mature IDE support and documentation support for Lift.

Like Andrea said, Intellij works great for LIft projects, you no longer see valid code marked as red, and if you do, you have an error in your setup (which we can help you fix)

And about documentation, if your team is new to lift, have them buy

http://www.packtpub.com/lift-web-applications/book

then have then read

http://simply.liftweb.net/

and finally have them at least read the titles of this:

http://cookbook.liftweb.net/

I would say that we have come a long way on documentation.

And have your team join the mailing list and know that they can ask any questions here, this is the one thing that I have a hard time at my job, for some reason people don't want to ask questions here (granted we have a few committers in our team so they just ask us :) )

For me one of the biggest selling of Lift is that security is part of Lift's core. It is really nice to just have pages with 20, 30 form fields, several rest apis,  comet, ajax and you never have to worry about escaping or protecting any of them. In Lift, you have to do extra work to make an application vulnerable to common attacks like xss or sql injections, which is great.

Thanks

  Diego

 

Thanks in advance.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Rohit Pathak]

Thank you all for your valuable inputs.

 

However I am still not convinced/clear regarding the support of IDE and documentation. As I said, we have already started working on our prototype in Scala/Lift and listed below are some of the issues we are facing:

1. No doc for lift-2.4

2. No lift-machine for scala-2.9.2 so I have to revert to scala-2.9.1 which in turn forced us to move to lift-2.4 (instead of lift-2.5 M4)

3. I see red lines in IDEA intellij for many of the things, some of the popular messages are:

 - Cannot resolve symbol /

 - Cannot resolve symbol >>

- Cannot resolve symbol #>

- Cannot resolve symbol notice                 -> for S.notice

- Cannot resolve method Box.apply

and some other symbols

 - Cannot resolve method RewriteResponse.appy

 - Too many arguments for method apply(...)                       -> Our source is full of these

 

however our code compiles just fine

 

Our configuration:

IDEA IntelliJ 12.1.3

Scala plugin 0.7.264

sbt 0.12.3

scala 2.9.1

 

Am I doing something wrong which is causing all these issues?

[Kristof Jozsa]

I think Lift's exceptional points are security and it's ajax+comet support. Otherwise, it's damn elegant approach though I don't think it's directly comparable to a primitive (as in structurally simple) MVC based approach like Spring MVC and Struts are. For me it's much more resembling Apache Wicket.. in spite of their numerous differences.

As of making a good business decision between these mentioned technologies - IDE support, documentation or skilled workforce available to hire are important to note, but my main concern is whether you can still compile or even run your unchanged existing codebase in a few years, and I seriously doubt that. This problem has nothing to do with Lift though.. but can become a dealbreaker easily. I had run into exactly this with Ruby a few years ago and it's quite an unpleasant experience..

thanks,
K

On Tue, May 21, 2013 at 7:03 PM, Rohit Pathak <insolen...@gmail.com> wrote:

Hi guys, I have been using Lift/Scala for some time. Using lift mainly I have been doing POC and preparing prototypes. I am an old user, but not an expert on Spring or Struts framework, nor of Lift, but I would still prefer Lift over these. Recently I have been handed over to lead a web application project (appox. 18-20 people), but I am finding it hard to convince my upper management to choose Lift/Scala for this development, instead of Java/Spring/Struts. Can any expert of frameworks (such as Spring/Struts) help me identify some key areas/points where Lift beats Spring/Struts so that I can get help convincing the management about Lifts advantages.

However on the downside I know that we don't have a mature IDE support and documentation support for Lift.

[Diego Medina]

Hi,

I'm glad you posted actual issues you are having, because your pain points are due to misinformation:

1. No doc for lift-2.4

We are on 2.5-RC6 and so far it looks like it will become final in two weeks, and the books I posted are for 2.5

 

2. No lift-machine for scala-2.9.2 so I have to revert to scala-2.9.1 which in turn forced us to move to lift-2.4 (instead of lift-2.5 M4)

if there is no lift machine for 2.9.2, all you have to do is post that on the list ans we would work on getting it fix. And 2.5-RC6 is compiled for 2.9.1

Also note that 2.5-M4 is pretty old by now.

 

3. I see red lines in IDEA intellij for many of the things, some of the popular messages are:

 - Cannot resolve symbol /

 - Cannot resolve symbol >>

- Cannot resolve symbol #>

- Cannot resolve symbol notice                 -> for S.notice

- Cannot resolve method Box.apply

and some other symbols

 - Cannot resolve method RewriteResponse.appy

 - Too many arguments for method apply(...)                       -> Our source is full of these

 

go to "project structure -> jdk and make sure that the correct jdk is there

also, do you use the sbt-idea plugin:

https://github.com/mpeltonen/sbt-idea  ?

 

however our code compiles just fine

 

Our configuration:

IDEA IntelliJ 12.1.3

Scala plugin 0.7.264

sbt 0.12.3

scala 2.9.1

 

Am I doing something wrong which is causing all these issues?

Let us know if you still have issues

Thanks

  Diego

[Rohit Pathak]

First of all thanks for your valuable inputs. Please see my comments below: 

 

1. No doc for lift-2.4

We are on 2.5-RC6 and so far it looks like it will become final in two weeks, and the books I posted are for 2.5

I was more of referring to java-docs and information shown in IDE. As far as I have seen my team work, what main advantage I have seen in Java+someframework is that you just hover your mouse over an API and information pops up. This helps in rapid development a lot. From what I see in Lifts source, there are many API's, methods and classes which don't have doc-comments in source, so it becomes hard to go through source and get information.

 

Although I am excited that 2.5 is going to be released soon, as I can't use any intermediate/milestone release (such as 2.5-M4) in our product. I hope source of 2.5 contains much more doc-comments.

 

2. No lift-machine for scala-2.9.2 so I have to revert to scala-2.9.1 which in turn forced us to move to lift-2.4 (instead of lift-2.5 M4)

if there is no lift machine for 2.9.2, all you have to do is post that on the list ans we would work on getting it fix. And 2.5-RC6 is compiled for 2.9.1

Also note that 2.5-M4 is pretty old by now.

 

Thanks for this too. But I just hope that lift-machine's update is released too along with lift-2.5. Then I would better to shift my development over scala 2.10 with lift-2.5.

 

 

go to "project structure -> jdk and make sure that the correct jdk is there

Again thanks. This was a life-saver tip. Although one red line still remains after choosing the SDK. It is for below listed code:

 

override def toForm : Box[NodeSeq] = SHtml.fileUpload(
        fileParam =>
          set(Box(fileParam.asInstanceOf[OnDiskFileParamHolder]))
      )

 

I am getting the message: "Cannot resolve method Box.apply". Do you have any idea what might be causing this.

 

also, do you use the sbt-idea plugin:

https://github.com/mpeltonen/sbt-idea  ?

Yes we use sbt-idea plugin 1.4.0.

[Tim Nelson]

Hi Rohit,

Regarding Box.apply: I think the way you are using it is deprecated. There are 2 ways to resolve this;

If you're worried about the asInstanceOf call throwing an exception, use util.Helpers.tryo:

    set(tryo(fileParam.asInstanceOf[OnDiskFileParamHolder]))

If you're not worried about that, (you probably should be), use Full:

    set(Full(fileParam.asInstanceOf[OnDiskFileParamHolder]))

And for completeness sake, the other use case here involves null. If you're expression could possibly return null, you should use legacyNullTest (or it's alias !!):

    set(Box !! fileParam.asInstanceOf[OnDiskFileParamHolder])

Tim

[Rohit Pathak]

Hi Tim,

    Thanks for your valuable inputs. You are right, I should be using Full instead. But my actual point of concern was that the IDE is not able to judge this statement properly. The code is compilable, but its just that IDEA IntelliJ shows a red line for it.

[Richard Dallaway]

On 22 May 2013 07:46, Rohit Pathak <insolen...@gmail.com> wrote:

However I am still not convinced/clear regarding the support of IDE and documentation. As I said, we have already started working on our prototype in Scala/Lift and listed below are some of the issues we are facing:

1. No doc for lift-2.4

2. No lift-machine for scala-2.9.2 so I have to revert to scala-2.9.1 which in turn forced us to move to lift-2.4 (instead of lift-2.5 M4)

Machine is available for 2.9.2 with Lift 2.5: 

http://search.maven.org/#artifactdetails%7Cnet.liftmodules%7Cmachine_2.5_2.9.2%7C1.2%7Cjar

During 2.5 it became net.liftmodules rather than net.liftweb, so that may be why you couldn't find it. This should be good or any version of Lift 2.5, for Scala 2.9.1, 2.9.2 and 2.10:

libraryDependencies += "net.liftmodules" %% "machine_2.5" % "1.2"

 

3. I see red lines in IDEA intellij for many of the things, some of the popular messages are:

Maybe check you're generating the project file using the latest gen-idea plugin for SBT: https://github.com/mpeltonen/sbt-idea 

 

Regards

Richard

[Rohit Pathak]

> Machine is available for 2.9.2 with Lift 2.5: 

Thanks for the location of lift-machine.

> Maybe check you're generating the project file using the latest gen-idea plugin for SBT: https://github.com/mpeltonen/sbt-idea 

Yes I am using the latest sbt-idea 1.4.0. 1.5.0 is still snapshot, I hope it fixes some things. After what "fmpwizard" suggested, most of the red lines are gone, and I can live with the only one left in my project.

[Rohit Pathak]

Also how about Lifts defense against Grails?

[Austen Holmes]

I used grails heavily at a previous job.  I was an early adopter and would have considered myself an expert at the time (although I haven't used it for a year or so).  Grails doesn't hold a candle to Lift.

Grails is basically a simpler way to do spring mvc.  Initially it was just a groovy dsl + some conventions around spring mvc and hibernate, probably why it was acquired by springsource a while back.

Where Grails has a one-up is when you need to scaffold a data-entry application.

Also, Scala >>>>>>>>> Groovy (much much greater). Groovy is very slow and prone to bugs because it's not type-safe.  If you're going to learn a new java-ish language, learn Scala.

Unless Grails has made significant strides in the last year (and I don't think they have), I would never recommend it, except for small internal projects that are data-entry driven.

-Austen

[Rohit Pathak]

Austen, thanks for your valuable inputs. You couldn't have explained it better. The type-safety alone would make me drop Groovy, moreover there are other cons of Groovy too  ! Thanks a lot.

[Diego Medina]

On Wed, May 22, 2013 at 12:29 PM, Rohit Pathak <insolen...@gmail.com> wrote:

> Machine is available for 2.9.2 with Lift 2.5: 

Thanks for the location of lift-machine.

Just to note, this is a good example if one of the strengths of this community. You brought up a few problems you were having, things that prevented you from using the versions you wanted, and boom, within hours you got the answer.

The API documentation has gotten better on 2.5, and it continues to evolve, but we still have some areas with little or no api doc. That being said, I have found it very useful to read across the lift codebase from time to time. Even though it  may take some extra time at first, you will end up better off, by knowing a lot more about Lift's internals (which sometimes you can apply to your own code base)

Thanks

  Diego

 

> Maybe check you're generating the project file using the latest gen-idea plugin for SBT: https://github.com/mpeltonen/sbt-idea 

Yes I am using the latest sbt-idea 1.4.0. 1.5.0 is still snapshot, I hope it fixes some things. After what "fmpwizard" suggested, most of the red lines are gone, and I can live with the only one left in my project.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rohit Pathak]

Yes, I have found many useful things too while going through the source.

Also I got quick replies on my posts on this community. I think this community is simply amazing for Lift users. I have started loving this community already :)

[Diego Medina]

On Wed, May 22, 2013 at 2:11 PM, Rohit Pathak <insolen...@gmail.com> wrote:

Yes, I have found many useful things too while going through the source.

Also I got quick replies on my posts on this community. I think this community is simply amazing for Lift users. I have started loving this community already :)

That's what we like reading :)

 

On Wednesday, May 22, 2013 11:34:36 PM UTC+5:30, fmpwizard wrote:

Just to note, this is a good example if one of the strengths of this community. You brought up a few problems you were having, things that prevented you from using the versions you wanted, and boom, within hours you got the answer.

The API documentation has gotten better on 2.5, and it continues to evolve, but we still have some areas with little or no api doc. That being said, I have found it very useful to read across the lift codebase from time to time. Even though it  may take some extra time at first, you will end up better off, by knowing a lot more about Lift's internals (which sometimes you can apply to your own code base)

Thanks

  Diego 

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.