Any cool mobile-app example cooded with Lift3?

[Andreas Joseph Krogh]

Hi all.

 

We're using "standard Lift" for our mobile version of our web-application. This means we're rendering HTML5 on the server, using good-old snippets, SHtml.idMemoize, SetHtml, Replace and the other nice mechanisms for replacing zones of the page dynamically. We've not looked at any of the "single-page-app"-frameworks and Lift3's new cool "streaming comet-actors".

 

Does anyone have any cool example-app written in Angular, Node.js, Knockout or similar?

 

Thanks!

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

[Neil Visnapuu]

We use Angular, and the guys from my team can elaborate here (if they're reading!).  I can arrange for a looksie, if of use.

--
--
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/d/optout.

[Andreas Joseph Krogh]

På torsdag 23. april 2015 kl. 23:49:48, skrev Neil Visnapuu <neil.v...@gmail.com>:

We use Angular, and the guys from my team can elaborate here (if they're reading!).  I can arrange for a looksie, if of use.

 

We do all of our computing and rendering serverside to keep using Scala for type-safety. It would be cool if you can elaborate on how to keep type-safety using Angular. If giving up type-safety and using lots of JS is the issue I'd appreciate some explaination of why taking this approach is a win.

 

Thanks.

[Torsten Uhlmann]

Hi Andreas,
I'm part of that team Neil mentioned.
We use Lift 2.6 servers with a Mongo database on the backend, AngularJS and JavaScript on the client.

I have some experience with applications that render server side, and while I think both approaches have its place, I think client side rendering enables you to create more responsive applications.

I agree there is this impedance mismatch between Scala server and JavaScript client, which you also have even if you do just small bits of client code. it's just not that obvious.

For client-server communication we mostly use Resthelper Apis. That means on the server side we have session state and type savety, and as soon as the json data travels back to the client we are in full dynamic land. While I sometimes wish for a compiler to be there and tell me what a type looks like, dynamic JavaScript on the other hand also enables things that you can just dream about in Scala. Want some extra data in that object? Just put it in...

You may also want to look at Dart or Typescript. I'm not sure how well they play with Angular, they are supposed to give you some type safety though.

One other though to throw in the mix. If you just starting to look at client side rendering have a look at ReactJS. After you overcome the initial urge to throw up because you mix code and markup, something we have learned for 20 years not to do, you will start to see how powerful this concept is and how much easier programming becomes.

I hope that helps a bit,

Torsten.

--

[Andreas Joseph Krogh]

On Friday 24. April 2015 at 08:53:00, Torsten Uhlmann <tuhl...@agynamix.de> wrote:

Hi Andreas,
I'm part of that team Neil mentioned.
We use Lift 2.6 servers with a Mongo database on the backend, AngularJS and JavaScript on the client.

I have some experience with applications that render server side, and while I think both approaches have its place, I think client side rendering enables you to create more responsive applications.

I agree there is this impedance mismatch between Scala server and JavaScript client, which you also have even if you do just small bits of client code. it's just not that obvious.

For client-server communication we mostly use Resthelper Apis. That means on the server side we have session state and type savety, and as soon as the json data travels back to the client we are in full dynamic land. While I sometimes wish for a compiler to be there and tell me what a type looks like, dynamic JavaScript on the other hand also enables things that you can just dream about in Scala. Want some extra data in that object? Just put it in...

You may also want to look at Dart or Typescript. I'm not sure how well they play with Angular, they are supposed to give you some type safety though.

One other though to throw in the mix. If you just starting to look at client side rendering have a look at ReactJS. After you overcome the initial urge to throw up because you mix code and markup, something we have learned for 20 years not to do, you will start to see how powerful this concept is and how much easier programming becomes.

I hope that helps a bit,

 

How do you cope with refactoring when having so much dynamic code on the client? In our, rather large, app, any developer can change the name of any class/field without worrying about braking anything. "Find usages" etc. in the IDE works as expected and actually finds all usages. I'm really worried that if going down the dynamic, untyped, road the codebase will become really fragile. For example, when a case class changes, producing different JSON, are we back to maintaining 1000 unit-tests again?

 

Another question; When we use "standard Lift" for our mobile-app  we can fully enjoy Lift's comet-support. How is this handled when using RestHelper combined with client-side non-Lift JavaScript-libs? Do you have any examples of who to push JSON (using comet, Lift-3's new pure JS-comets if you like) to the client when the client is REST?

[Tim Nelson]

To answer your last question, the initial page load is done via Lift and a single comet is loaded. That comet then subscribes to different channels as they're needed. We're still using Lift 2.6, so we don't have any examples with 3.

One other point to note is that we load forms using Lift, which covers 90% of code that manipulates data, most of the API calls are only for retrieving data. 

Your concerns about most of the client code in JavaScript are quite valid. I much prefer the safety of Scala, but the user experience in an SPA is much better imo and may be worth it. One drawback is that you end up making multiple API calls per page to fetch data, whereas if serving it via Lift those would have all been made on the server and only a single request made.

Something I started working on, but haven't gotten back to, is a way to use an independent routing library (like crossroads [1]), but load the page content via Lift instead of using javascript. That seems to me like it would be the best of both worlds. I tried this with Angular, but their routing module assumes the template you are fetching is static html and will always cache it and I never found a decent way around that.

For us, we could still use Angular, we would just ditch their routing module and then each page becomes it's own angular app. But you could keep most of your code in Scala/Lift and get the user experience of an SPA.

Tim

1 - http://millermedeiros.github.io/crossroads.js/

[Diego Medina]

Hi Andreas,

Refactoring client side code is definitely different than scala, for the past week and a half I worked on a large refactor of our app and it involved both, client and server side changes, like you said, for the server side, it was mostly a matter of shift + F6 over the name of the variable/function and keep sbt in ~compile to make sure it worked as expected, but  the client side wasn't too terrible, there it was a matter of find/replace at the root of all the client side code, and paying attention I was skipping the matches that were not supposed to be changed. It helped that I was familiar with the area of the app. And it also helped that we use grunt and jshint to catch some errors (not types though), but typos and stuff like that.

I would also say that having rest apis to give you the data also means you have to write more code to make it secure, not just check that the user has to be authenticated, but also check that the right user has access to the specific resource, so this area takes discipline and whoever does code review needs to make sure you don't end up having apis that anyone can hand craft the url to get someone else's data.

And finally, you mentioned on previous emails that your app has lots of long reports, if you move them to client side, note that you need to be careful and send just the json data you need, it is very easy to end up  with several MBs of json going down to the client, and then the client takes several seconds, even minutes to read it all and render it, so while the initial surrounding of the page may load fast, the user's content may take a really long time.

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/d/optout.

--

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

[Andreas Joseph Krogh]

På lørdag 25. april 2015 kl. 14:48:57, skrev Diego Medina <di...@fmpwizard.com>:

Hi Andreas,
 

Refactoring client side code is definitely different than scala, for the past week and a half I worked on a large refactor of our app and it involved both, client and server side changes, like you said, for the server side, it was mostly a matter of shift + F6 over the name of the variable/function and keep sbt in ~compile to make sure it worked as expected, but  the client side wasn't too terrible, there it was a matter of find/replace at the root of all the client side code, and paying attention I was skipping the matches that were not supposed to be changed. It helped that I was familiar with the area of the app. And it also helped that we use grunt and jshint to catch some errors (not types though), but typos and stuff like that.
 

I would also say that having rest apis to give you the data also means you have to write more code to make it secure, not just check that the user has to be authenticated, but also check that the right user has access to the specific resource, so this area takes discipline and whoever does code review needs to make sure you don't end up having apis that anyone can hand craft the url to get someone else's data.

 

And finally, you mentioned on previous emails that your app has lots of long reports, if you move them to client side, note that you need to be careful and send just the json data you need, it is very easy to end up  with several MBs of json going down to the client, and then the client takes several seconds, even minutes to read it all and render it, so while the initial surrounding of the page may load fast, the user's content may take a really long time.
 

Thanks
 

Diego

 

Our app is the kind of app which you have to maintain for 10+ years so choosing technology and frameworks is not an easy task. Lift has serverd us well so far and I have faith in it and its community. Refactoring is always "easy" when the codebase is rather small and you know it all, or most of it. Our codebase isn't small and there exist parts which I don't even know about so relying on a type-safe language like Scala when doing refactoring and doing processing server-side makes me sleep at night:-)

 

About long reports: I still havent't found a way to produce large reports and process them using CSS Selector Transforms in an efficient way. We see that serverside processing of a list (with some onclicks, onmouseover etc. for each row) often takes > 10s. That is, over 10 s. applying the transforms iterating the result-set, even on a warmed up JVM. Reloading and manipulating this list using AJAX often results in huge amounts of used RAM. But this is quite a different problem and not really relevant for this thread.