We Keep Coding

Why SPA (Single Page App)?

Inspired by John Papa's video at Pluralsight, I started learning SPA. It appears pretty interesting. However, before I fully jump in, I'd like to clarify some of my questions.
From what I learnt, SPA is a lean server, fat client app. I think this should work well for small apps like what John Para demonstrated. Does it scale? How big it can be? Anybody has experience with this?
In SPA, you seem to code all the business logic in JavaScript. Is this a good idea at all? How do you hide the business "secret"?
With my background primarily in C#/WPF/.NET, moving to JavaScript seems to be very difficult (well, I learnt a little JavaScript more than 10 years ago - I hated it and never touched it again). With my limited knowledge, I ran into several problems. Debugging JavaScript seems to be a nightmare to me. The highly praised component Breezejs seems to be still in its early stage (e.g. it doesn't support UOW, doesn't support CascadeDelete, doesn't support enums). So, I'm wondering this is good time to jump in?

Directly to your questions:
Since the server logic is thin you can use some kind of cloud services and they scale pretty good. The most of the logic will be handled by the browsers of your users.
You should be careful if you depend on client. HTTP protocol can be easily manipulated. Don't forget that you should always do the validation logic both on client and server side! Also the "hidden" validation and other "secret" logic should be located only on the server.
Debugging JavaScript isn't so bad at all. You can use the built-in tools (Inspect element in Chrome and FireBug in Firefox, etc.) Also there are a lot of useful third party tools that will help you with the debugging.
If you start a new project just for your own use then I advice you to try the SPA approach. If you are writing production code you should become an expert in this area and then try to use these technologies.

Regarding UoW, take a look at the TempHire sample. It demonstrates using the UoW pattern on the client as well as the server.
https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire

I believe SPA's provide a better framework for Business Intensive Applications as well as simpler application workflows such as that of Facebook. I have worked with Multi Page Applications for banking application with complex workflows and it get daunting to handle every thing and still keep up the application performance.
But I do think Knockout Alone wont be able to handle large applications as it is to connected in nature. I would recommend something like Backbone Marionete or Angular for that venture.
I am building a framework for large scale SPA development for the opensource community so I do believe it is the right direction.
Interested parties can go to my demo page at http:\saqibshakil.github.io I have demonstrated some of my work there.

i have been looking into it for months. My conclusion is to use Knockout with a light path.js or sammy.js for your url. I use json with a standard Visual Studio MVC ( which can return Json) as the backend.
I am still not done with the project but so far so good. It's lightning fast, elequent and lightweight.
Stay away from the frameworks. Get a look at the standard libraries: how they are written; You can learn a lot of JavaScript that way. Finally debug with chrome or explorer developer tools.
Good luck

JavaScript Web Application

I built a quiz taker app with Ruby on Rails, using the MVC framework. I want to do basically the same thing with pure JavaScript, and add more features with jQuery for mobile devices and special effects, since jQuery is just awesome like that.
I have looked around on sites like TodoMVC for comparisons on frameworks, but I'm foreign to how these frameworks function. Why do they use Collection rather than Controller in their MVC definition? It seems to me that these are just client-side frameworks. Would I use something like Backbone.js for client-side work and Node.js for server-side?
I'm just unsure as to how development with pure JavaScript functions. I need to create a database to store quiz and user information and be able to access that database when viewing most pages, so I feel the MVC framework is the best way to go.
Any suggestions as to where to start?

Wow, that's quite a broad post; let's take things one at a time
Why do they use Collection rather than Controller in their MVC definition?
The exact answer varies by library, but a simplistic answer is that the Controllers in most Javascript apps doesn't really need any framework; they can be raw Javascript and work just fine as they're usually not very complex.
Furthermore, parts what you might consider to be "the Controller" are often provided separately. The primary example of this is Backbone's Router object: it is similar to the implied routing (and routes.rb) in Rails, or the urls.py in Django. Just as those frameworks don't consider routing to be part of "the Controller", Backbone (and similar frameworks) provide routing as a separate piece ... even though it could fall under the C in MVC.
Similarly, much of the DOM manipulation functionality that jQuery provides would normally belong in the Controller of an MVC app, so in a sense jQuery helps you build your controllers; it's just not explicit the way Backbone.Model helps you build your models.
Would I use something like Backbone.js for client-side work and Node.js for server-side?
That's really apples and oranges; to put in server-side terms, Backbone is more like Rails, and Node is more like Ruby (or Mongrel or something). So yeah one's client-side and the other's server-side, but the differences are deeper than that.
Any suggestions as to where to start?
Pick a framework and get your hands dirty! Seriously, you can spend hours reading reviews of the different frameworks, and still be no closer to making a decision at the end than when you started (I speak from experience). But if you just pick one and try it, you'll likely find that it either "gels" with you or doesn't pretty fast.
Personally, I'd recommend starting with Backbone just because A) it's very popular these days, and B) I'm biased: I use it on a daily basis and love it. Also, it probably would fit you well because it was created by the CoffeeScript guy (and CoffeeScript was his attempt to make Javascript more Ruby-like). However, Ember.js is also very popular these days, and Hector mentioned ExpressJS, which I know nothing about but could be cool.
But the point is, pick one, do a hello world, or maybe something a little more complex like an introductory tutorial (Backbone has one around a To Do app). A few hours of coding with it will tell you far more than I (or anyone else on Stack Overflow) ever could about whether it's right for you.

If you are looking for a JavaScript MVC-like framework take a look at Express.js http://expressjs.com
Express.js is more like Sinatra than Rails, but it will give you a good foundation on the server side.

I would definitely look at Google Closure. I have started to use it with LimeJs on a personnal pet project and really got caught with it's compiler and it's modular design.
It's not really MVC, but since JavaScript should be thought more in an asynchronous fashion, I tend to think more of it as event driven than simply a request-pipeline-response way.
So, Closure Library and jQuery / jQuery UI (both on Google API) for the client side and ExpressJs for the server side. Also, take a look at this framework comparison chart, you might find it interesting.

Lift, Play! or BlueEyes (with a bunch of Javascript Frameworks)

I find myself in a bit of a conundrum. I'm building a new, modern, web-based application and not only do I have to pick a technology, I have to pick an architecture. I think it is fair to say that these days its a tough choice because we have more options than we did even 5 years ago.
First things first, I've made the decision that Scala will be the server-side language. I have my reasons, and this is not a Scala versus XYZ post - that choice has been made. I've also sucummed to the fact that we're on the web, in the cloud, so I'm not even going to try and get away from Javascript. Maybe I will with CoffeeScript, but I will be writing Browser-hosted code.
Now, assuming Scala, most people would probably jump to either Play! or Lift. Probably Play! given it's endorsement from Typesafe, but I think I have another more important question that needs answering first. What's the architecture? If I want a very rich client, do I really need more than a simple stateless service layer based on the fact that we'll have a tonne of Javascript anyway? I'm not sure it'll be a single-page webapp, but is something like BlueEyes potentially the right choice? Lift and Play! are much more heavyweight in that they take on much more responsibility. They generate the HTML and for these frameworks, the browser is pretty dumb. Things like routing, validation, Ajax and Comet support are all server-side concerns. Because the browser is more capable today, rich, interactive features are normally implemented by generating and injecting Javascript from the server.
My question boils down to this. Do I go with a traditional Lift/Play! framework where the server takes on both the client and server responsibility or do I go with a rich client + REST-style service layer where the client takes a more prominent role in the application? An architecture where the client deals with routing, validation, binding, etc. I'm seeing frameworks like KnockOut.js, Sammy.js, Sproutcore, Backbone.js,... I'm not going to list them all but suffice to say that they all take on some of these framework features from a client-side perspective.
If I choose Play!, am I giving up some of that rich UI? What about situations where I want to provide service API's for integration/mashup/mobile purposes? How would Play! help me here? Clearly BlueEyes plays well here. I think I need a service layer regardless.
If I choose BlueEyes, what does my client code look like? How many of these Javascript-based frameworks do I need to give me what I need? I still want most of my business-logic in my service layer, but routing, binding.. all that UI stuff would be a concern of the client.
I'm not sure there is a right or wrong answer, but I think this community can probably point me in the right direction.
I also posted this to my blog at http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-it-u-45228

If all you want is a REST API on the backend, then Lift, Play! or Blueye will work just fine. But I'll just point the advantages of using Lift.
It is not true that Lift tries to impose doing both, the front and back end. We support REST-only use of Lift and it is encourage for the right project.
While Lift comes with jQuery and blueprint, you can use any javascript library and css framework, there is currently a lot of people on the mailing list showing how they use twitter boostrap with Lift. See this Lift module that helps integrating Bootstrap.
With Lift, you can start stateless, and if along the way you find that your needs change, you can go statefull. You can even mix and match them on the same application.
Want some modern looking UI? Lift's comet support is one, if not the best one, out there. Very simple to use, proven and tested on many browsers/workloads. I have written several posts showcasing Lift's comet support.
If you decide to use Lift for both, front and back end, you get for free an application that is secured by default, no need to worry about xss, xsrf, or many of the top 10 OWASP security vulnerabilities.
Need commercial support, there is a growing list here
Need training? There is a Basic training coming up in London and the founder of Lift also provides other training sessions.
There are several books about Lift available. Lift in Action , Simply Lift and Exploring Lift
There is a very active community ready to help.
Who uses Lift? Just to name a few: Foursquare , OpenStudy , The Guardian UK, StackMob and many more.
Well, I should stop here, but in short, Lift is an awesome framework that has a lot to offer, you take as much or as little as you need.

The Play 2.0 Beta contains a sample application that is exactly what you are looking for (ZenContacts).
Its server side is just a bunch of restful interfaces while its client side leverages coffeescript etc. to build a rich user interface.

As far as I know, both Play! and Lift can be used as basically a "back end", and you can use HTML5+CSS+JS as your "front end"; they do not necessarily restrict your ability to create the front end you desire, so rejecting them for that reason would be silly. Notice things like knockout.js advertise that they "work with any web framework". However, it might be true that they are more "heavyweight" than what you need.
I have never heard of BlueEyes before, but it appears to be aimed at a particular kind of use case. If that fits your bill, then it will probably be the most streamlined solution to your problem.
But if this is something you plan to actually put on the web, "routing, validation, binding, etc" practically need to be handled by the back end; I simply cannot imagine any of these things (securely) being handled by code that runs in the client's browser. Also, if your users choose to disable JavaScript, your website would be completely unusable.

If I choose Play!, am I giving up some of that rich UI?
What exactly you mean by rich UI? more javascript on the frontend?
If you consider - HTML5+CSS3+jQuery as a rich UI - then these work very well with any "backend" (Lift/Play).
The other thing which you might want to consider is the maturity of the framework.
Like you mentioned Play 2.0 supports Scala natively, has endorsement of Typesafe and is rapidly being adopted.
Plus you can expose RESTful services easily and consume then in the frontend (one of your requirement).
Leaning towards HTML5+CSS3+jQuery + Play 2.0 :)
just my thoughts..

What's the architecture?
Play! strongly encourages your server to use an MVC architecture, creating packages in a standard pattern:
app/
controllers/
Application.scala
views/
Application/
index.scala.html
models/
public/
images/
stylesheets/
javascripts/
This makes it easier to follow the architecture than to break it.
I can't speak for either Lift or BlueEyes, but afaik neither of them encourage an architecture as strongly.

Definately have a look at http://twitter.github.com/finagle before making up yiir mind. Finagle can take care of most of your backend stuff. It's desinged around a very flexible architecture that separates concerns cleverly using filters.

I have looked at apache click, wicket, a little bit Lift (feel a bit like wicket), and then play 1.2.4. So far so good with Play. Really beautiful approach to the web development. Keep up the nice work, play! team.

Is Node.js a good alternative to build complete websites?

I'm wondering if using Node.js (express.js) is the best option to go for a complete website. I've been using Rails + Node.js and am wondering if this is still the best option or if I should move completely to Node.js.
Are there websites built completely with node.js? I imagine it must lack many things Rails offers.

I imagine it must lack many things
Rails offers.
I gave a short list below but I would like to know what you could be missing and I think(almost certain) we can give you some alternatives on node.js.
Modules
node.js is getting pretty complete and I think you can run your entire site using only node.js using for example the following modules. I assume you know about npm. If not I really advice you to google for it and learn that. To search npm you can use http://search.npmjs.org:
web framework:
High performance, high class web
development for Node.js
https://github.com/visionmedia/express
Socket.IO aims to make realtime apps possible in every browser and mobile
device, blurring the differences
between the different transport
mechanisms.
https://github.com/learnboost/socket.io-node
I believe with these two web-frameworks you can create a lot of sites. For example express is a very powerfull web framework and supports a lot of cool things like:
session support.
a lot powerful template engines. I like Jade for example. You could also share these between client and server a lot of the times easily.
excellent routing.
just to name a few.
database:
Redis is an open source, advanced
key-value store. It is often referred
to as a data structure server since
keys can contain strings, hashes,
lists, sets and sorted sets.
https://github.com/mranney/node_redis
MongoDB (from "humongous") is a scalable, high-performance, open source,
document-oriented database.
Mongoose is a MongoDB object modeling tool designed to work in an
asychronous environment.
https://github.com/learnboost/mongoose/
With those two databases I think you should be able to accomplish most of your tasks. The nice thing is that Redis is extremely fast/simple advanced KV-store(dataset in memory/also supports VM) and supports replication while Mongodb is more completely(slower then redis) and also supports sharding.
authentication:
Authentication and authorization (password, facebook, & more) for your node.js Connect and Express apps.
https://github.com/bnoguchi/everyauth
Like I said previously you can get a long way with only these modules.

Express.js is more akin to Sinatra. They're simpler frameworks than rails.
Express's list of sites is fairly small http://expressjs.com/applications.html
So I think it's also good to look at Sinatra's list http://www.sinatrarb.com/wild.html
So to answer your questions in reverse order. Yes it lacks all the features of rails. Yes there are sites written completely in Express. And going to 100% Node.js might be the right decision for your site.
It depends on which features you'd miss and what performance you need.

I'm not sure, but I guess it's perfectly possible. I have built complete sites using plain server side javascript for years without problems. The advantage of node.js seems to be its event driven model and things like socket.io. I just started experimenting with it, I'll probably will try porting an existing site to node.js.
Here you can find a large list of sites built with node.js.
Finally, you may want to read: What it’s like building a real website in Node.js

Yes, as of now node.js lacks many (well, at least a few) things rails offers. Eventually the set of available node.js modules will collectively provide good alternatives to RoR across the board. Or at least different (and often more modern) approaches to the same fundamental problems. There are still some important things missing in the node.js ecosystem including a good ORM for postgresql (rails has ActiveRecord which is great) and a good DB schema management subsystem. Both of these do not exist in the node.js ecosystem as of this moment, but surely they will be there in due time. Rails has these down pat right now.
There are some tricks node.js has that RoR doesn't. Debugging in node.js is more seamless than RoR and express.js is more flexible. Express is the library approach (you tell it what to do) whereas rails is the framework approach (you fill out the boilerplate it creates for you). There are also some fantastic things like stylus and jade, which have equivalents in rails, but when you have a full app written in one language (either javascript or CoffeeScript, which I prefer) and everything is in a modern node.js/TJ Holowaychuck style, you get a level of cohesiveness that is really nice to work within.
The other thing to keep in mind is that while the list of available node.js modules is quite impressive, many of them are not as mature and battle-tested as their rails/django analogs. It's hit or miss, so beware.

What are the implications of node.js?

I've been reading about node.js lately. I've seen many articles about how it's really great and all from some prominent people. Given the inertia that this project seems to have, and that I am currently learning javascript and jQuery, the project has gotten my attention. I get that many people are excited about it, but I don't quite understand what the implications are.
I understand that it is event driven and non-blocking and all of that, but where I'm confused is in regards to its intent.
Does node.js mean that we now have a foundation to run Javascript on the server-side, so that later maybe someone will create the Ruby on Rails or ASP.NET MVC equivalent for node.js/Javascript? Perhaps there already are web frameworks out there, but if so I haven't heard the hype machine yet.
I hope my question is clear.

I think the major implications are two-fold: huge performance and scalability gains, and the possibility of creating web applications where two or more people may work on the same web application at the same time, watching what the others are doing, in real-time. This latter one not only has big implications for web-based gaming, but also collaboration tools, etc.
It would appear that node.js is exactly what the real-time web needs. For that kind of thing, be sure to also checkout Socket.IO, which achieves cross-browser HTML5 web sockets. Combined with node.js, this makes for an incredible platform.
Check out what was made at the node.js knockout for some examples of what can be done.

I think what you can hope for is going to be more like twisted for Python, rather than e.g. rails for Ruby -- a rich, powerful framework, but still one requiring skill and care to use properly, because asynchronous programming is always like that... it's the price you pay for its absolutely awesome performance potential.
There are and have been Javascript server-side frameworks, but with server-side Javascript never being a really popular option, such frameworks never got the "critical mass" of support and enthusiasm that, say, jQuery has, or rails for ruby on the server side of things.
I doubt async programming (with its subtleness and difficulty) will be the defining trigger for a "mass movement" (hey, I hope I'm wrong, but I see e.g. the relative popularity for Python of Django, with none of the awesome performance, compared with Twisted, with _all_ the awesome performance... but the intrinsic difficulty too!-).
OTOH other developments (such as, simply, the wide availability of powerful, high performing, solid Javascript engines like V8) are more likely to eventually result in wide availability of (non-async;-) server-side Javascript choices, and as a consequence the possibility of the development (or porting -- e.g., a framework like dojo could already offer a lot to a JS server-side app, only parts of it are actually client-side) of powerful, simple, and therefore eventually popular framework. Nevertheless, I wouldn't hold my breath waiting for that either...

Node.js is an application server, not yet another webapp server. As the article says, it saves you the trouble of writing the event loop and using two languages to write apps (python/java/ruby/php backend, js frontend). As it is based in the V8 Engine by Google it's really fast and has a low memory footprint.
There's a web service framework called GeddyJS, and Node.js comes with a set of libraries for IO, database and math. It's also possible to extend it with addons, though last time I checked documentation was still a little rough on that.

There is a node framework called bogart which you can easily use the MVC pattern and mustache or common-ejs for templating.
http://github.com/nrstott/bogart