We Keep Coding

Is there a client+server-side MVC JS framework

I've been working with Node+Express for a while now, and I'd like to start looking for a strong structure for building average to huge web apps, but which could also be used (and not be too much overkill) for simple websites.
I've been taking interest for backbone, but I'm looking for something much more "complete" already. I Know backbone can do everything with the right plugins and by respecting the best practices, but what I'm looking for is something more "strong" as is and from the start, like AngularJS, CanJS or Ember (maybe CanJS is the best compromise between flexibility and conventions althought all of this can be mostly subjective).
Just to be sure to keep into the best practices, even if I must stick to an opinionated FW.
Now, before choosing anything, and because I'll be using Node in the backend, so full JS, I'd like to know if there is a framework which would deliver client+server MVC capabilities, or if I must use Node/Express in the back and something else for the front.
Other info that may be useful, I'd like to code in CoffeeScript/LESS, and keep HTML as is (so no Jade-like stuff). If I'm not asking too much, I'd like to use this technology for all of my projects, which will be targeting also mobile phones, as websites (for sure), and sometimes even as Phonegap-based apps. Maybe this becomes hard (Meteor doesn't support Phonegap for it's client-side part for what I've read, maybe Derby ?).
Also, I must point out that I'm not asking anything subjective like "what is the best between ..." but simply if full client+server MVC JS framework exists, and if yes, which ones meets those needs.

rendr (backbone with server-side support)
meteor (very real-time oriented)

Meteor and DerbyJS seem great but very real-time oriented, I am not going for those.
I think I'll use TowerJS which seems to have really great features (live JS/CSS injection in browser when files updated, live node files reloading without restarting, pre-built development, staging and prod environments, MVC+ORM client+server-side, Redis for temp data and Mongo for DB...).
For Phonegap projects, I'll keep tower server-side and I'll find something else for the client, maybe simple backbone.

Take a look at the ExtJS 4. Also there is Sencha Touch 2 for mobile app development. Both of them has strong support for MVC.

sails.js is the most popular node.js MVC framework nowadays, and has a huge and growing community.
Meteor is also a great tool; my experience with the extjs community is that they are not very welcoming (rtfm noob! type of stuff).

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

Decision about web application architecture

I am facing a decision about the web application architecture I am going to work on.
We are a small team and actually I will work on it alone (everybody work on something else).
This application will consist of front-end build on the ExtJS library
and it will use the model "load page, build GUI and never refresh".
On the web "desktop" there will be a lot of data windows, map views (using openlayers + GeoExt) and other stuff.
GUI should be flexible and allow every user to modify (and persist) the layout to fit his/her needs.
It should be possible to divide the application into modules / parts / ... and then let users in specific groups use only the specific modules. In other words, each group of users
can have different GUI available on the web "desktop".
Questions are:
First of all, is this approach good?
There will be a lot of AJAX calls from clients,
may be this could be a problem.
How to handle code complexity on client side?
So far I have decided to use dojo.require / dojo.provide feature and divide the client side code into modules
(for production they will be put together using dojo build system)
I am thinking about to use kind of IoC container on client side, but not sure which one yet.
It is very likely that I will write one for myself, it should not be difficult in dynamic language like JavaScript.
How to handle AJAX calls on server ?
Should I use WCF on server side ? Or just ordinary ashx handler ?
How to handle code complexity on server side ?
I want to use Spring.NET. May be this approach could help with modularity problem.
Data access - here I am pretty sure what to use:
For DAL classes I will use nHibernate. Then I compose them with business classes using Spring.NET.
I would really appreciate some advice about which way to go.
I know about a lot of technologies, but I have used only little part of it.
I don't have time to explore all of them and be fine with the decision.

We do this type of single page interface where I work on a pretty large scale for our clients. (Our site is not an internet site)
This seems to work pretty well for us. The more js you have the more difficult it gets to maintain, so have as many automated js tests as you can and try to break up your js logic in an mvc fashion. 4.0 is supposed to make this much easier.
Ext 4.0 has this built in if you are trying to limit the code you bring down. If you have the same users day after day, then I think it would be best to just bring all the source down (compressed and minified) and cache it.
We've found asmx to work really well. I have nothing against wcf, but last I looked it seemed like more trouble than it was worth. I know they have made many improvements recently. asmx just works though (with a few request header changes and managing the "d." on the client side).
Our Server side data access layer is pretty complex, but the interface for the ajax calls is pretty simple. You have not really given enough info to answer this part. I would start as simple as possible and refactor often.
We are also using nHibernate. Works fine for us. We have built a DDD model around it. It can take a lot of work to get that right though (not sure if we have it right after months of working at it).
If I were you I'd start with just extjs, your web service technology, and nHibernte.

I would recommend ASP.NET MVC 3 with Razor instead of a lot Javascript and calls to Service you can just do ajax calls to an Action in a Controller and that will let you have more maintainable code and use a IoC like Ninject. EF instead of NHibernate.
But it's your decision.

I would look into using a tool like Google Closure Compiler, especially if you're dealing with a very large project. I don't have too much experience with ExtJS, but large projects in JavaScript are hard and something like Closure Compiler tends to make it easier.

Need help determining how to approach building my project

I'd like to create something similar to a family tree online app (like geni.com). I'm unsure what languages I should use to build it with. My IT strong points aren't in programming and this project is going to require me to sit down and learn some languages. My problem right now is that I don't know what languages I should use.
So with the idea of a family tree online app in mind here are some of the specifications.
- I do not want to use flash.
- The app needs to be zoomable and scrollable (sort of like google maps)
- The app needs to be able to add content without reloading the page. Perhaps there's a little "+" sign and when I click it, I can add a tag/title/description/picture
- The app needs to be able to save your work for that user to retrieve later on.
- The layout that a user is able to create in is sort of widget based where the user can add a new bubble and then in that bubble they are able to add text or content.
I started programming this with HTML5 canvas and Javascript, but I'm stuck on creating a connection to the database that isn't directly from Javascript (because that seems very insecure to me). But I'm not just stumped on how to interact securely with the database (I don't even have a database picked out), but also I'm concerned that I won't be able to build out the app with just javascript and may need something else like ajax or something but I'm unfamiliar with what each language does nowadays.

If you are starting from scratch, then the best language to use is the one you are most comfortable with. Alternately, if you don't plan to be developing the whole thing yourself and you already have some other interested parties on board then the best language to use is the one that the majority of you are comfortable with. If it's just you and you do not yet have any favorites, then look around and play with a few - it's the only way to find out if you will actually like / be effective with them.
That being said, a few of the more likely candidates these days are:
JavaScript: Long gone are the days when this language was simply a way to put the D in DHTML. These days JavaScript is a viable client and server-side language. (Others here have already recommended Node.js -- I'd also recommend NPM (node package manager) to handle your dependencies). With a little bit of planning you can reuse most of your application code on both the client and the server side. On the downside, most of the server side technology is very new (only a few years old at most) and so you may find yourself implementing tools for use in your application rather than your application itself. Finding servers that support it will also be harder, again on account of it's age.
Perl: At the opposite end of the spectrum of age, we find Perl - the first commonly deployed language used to make web applications it still powers a great variety of useful websites out there (include new ones such as Pinboard.) The tools that are popular on CPAN have been vetted under fire. The good news is that it is not going anywhere anytime soon. The bad news is, you might have to search a little harder to find a module that supports [that newest, baddest thing that just came out yesterday].
PHP: The BASIC (or Perl, depending on who you ask) of the modern web, PHP was designed from the ground up to do one thing - make building dynamic web pages easier. Its popularity means that there is quite a lot of server support (PHP + Apache + MySQL is the Model T Ford of web servers -- everyone can afford one) and an enormous amount of pre-built code available for perusal. However, like BASIC, PHP's strength is also its greatest weakness. Almost anyone can write something that works in PHP ... how well it works depends on who wrote it. The caveat emptor that applies to all code snippets found on the web applies in spades to snippets of code written in PHP.
Python: The language that made programing fun again (at least for those who can see past the significant whitespace and lack of blocks / anonymous functions and overlook < 3.x's issues with non-ASCII out of the box.) It's a general-purpose, flexible and multi-paradigm language with quite a substantial standard library (but without .NET or Java's incredible bloat). In addition, quite a large amount of work has been done in it, so there is a good chance that what you need has been already developed by somebody else. Plus, it can make you fly.
Ruby (with or without Rails): The language that made the web fun, coupled, if you so desire, with the framework that made MVC cool. There is lots of documentation out there, and a great community, with many prebuilt tools (called gems) from which to pick and choose - free and cheap servers are not as common as their PHP counterparts, but they are likely to be of higher quality (when chosen at random).
All that being said, they are all great languages for web development. What matters is not what we think you should use ... but what you are most likely to be effective with. All of the languages listed above are mainstream (or will be in the next two years), easy-to-learn and easy-to-write languages. You cannot go wrong, no matter what you choose to start off with.
Alternately, if you want something a little more difficult, or less mainstream ... I am working with .NET applications at work, and with Lisp (SBCL)-based services in my spare time. I have heard great things about Lua and Java too ... there are at least two C++ web frameworks out there ... and I'm sure that there is somebody is having fun building a web service in COBOL with a FORTRAN backend. ;-)

As someone has already pointed out, you will need to work with a server side language as well. (Ruby, Python, PHP) You are exactly right there you should not be attempting a database connection via javascript in the browser.
You'll need to build out a server side application to handle the basic operations of your application.
I'd strongly recommend reading up on the MVC design pattern, and possibly looking into Ruby on Rails as your backend framework, it plays very nicely with ajax like features, and has a somewhat shorter learning curve, I believe, than some other frameworks / languages.

You will need server side scripts in a language like PHP or Ruby on Rails to interact with a database.

If you're already familiar with HTML5 and JavaScript, may I recommend using Node.JS? It's about the closest you'll get to what you already know with browser development. It can also hook in with database systems which are closer to the HTML5-suggested IndexedDB.
with that in mind...
If you're inexperienced with programming and programming languages, then the app you describe will involve a pretty big learning curve. While Flash and Flex have really nice interfaces to build apps with click-and-drag, the tools for HTML5 are much less mature.
That's not saying it's not possible with HTML5. Just that there's still some time to wait before people create tools to bring the app building process closer to what Adobe provides.

Should I use Google Web Toolkit for my new webapp?

I would like to create a database backed interactive AJAX webapp which has a custom (specific kind of events, editing) calendaring system. This would involve quite a lot of JavaScript and AJAX, and I thought about Google Web Toolkit for the interface and Ruby on Rails for server side.
Is Google Web Toolkit reliable and good? What hidden risks might be if I choose Google Web Toolkit? Can one easily combine it with Ruby on Rails on server side? Or should I try to use directly a JavaScript library like jQuery?
I have no experience in web development except some HTML, but I am an experienced programmer (c++, java, c#), and I would like to use only free tools for this project.

RoR is actually one of the things the GWT is made to work well with, as long as you're using REST properly. It's in the Google Web Toolkit Applications book, and you can see a demo from the book using this kind of idea here. That's not to say that you won't have any problems, but I think the support is definitely out there for it.
There's a neat project for making RoR/GWT easy that you can find here (MIT license). I haven't had a chance to try it out yet, but it looks like a good amount of thought has been put into it. One catch is that it looks like it hasn't been fully tested with 2.1 Rails yet, just 2.0, so you may run into a few (probably minor and fixable) errors.

If you are looking to integrate GWT with non-Java backends such as ROR, PHP etc., you should bear in mind that GWT 1.5 now supports JavaScript Overlay types. This feature lets you write classes that can be mapped over the top of native JavaScript objects to easily provide accessor methods for properties of those objects and other extended functionality.
See this link for more details:
JavaScript Overlay Types
So you could return JSON encoded data from your backend via AJAX calls, parse it into a JavaScript Object and then access the data through your GWT Java code using the overlay classes you've created. Or when you render your page you can render static config data as JavaScript Objects and read it in via this mechanism, rather than having to do an AJAX call to grab the data.

If you know JAVA, and have somewhere you can host it (like a tomcat or glassfish container) I would recommend that much more than using Ruby for the back end. The main reason is that then you can share all of your objects, and use the built in RPC mechanism. I've done this for quite a lot of our projects and it's a huge timesaver, not to mention that the code is less error prone, because you don't convert your java objects to anything and then back again.
I have linked my GWT with Rails before, using the to_json function in Rails and then reading the JSON in GWT. It's all supported, but it is far more annoying than just doing the back end in JAVA.
Of course if you have cheap hosting, then Java containers are pretty much out of the question, in which case I would think Rails would be the next best thing.

GWT is very high quality with a great community. However you do need to know CSS if you want to adjust the look of things (you will) - CSS can do a lot of the layout, just like regular web if you want it to. Libraries like GWT-ext or ExtGWT can help a bit as they have stunning "out of the box" looks but for a price (extra size to your app).

You can code everything in Java using GWT, and you can integrate existing 3rd party javascript libraries with it. It's very good. I've never used RoR much though, so can't say anything about that.

If you're experienced in Java but not in Javascript/CSS, then GWT is going to be a lifesaver (unless you want to learn them, of course). CSS has so many little fiddly details. It is not uncommon to spend half a day fixing a 2 pixel misalignment that only occurs in IE6.
I am not sure about how easy it would be to use ROR for the back end... It is possible, I am sure, since GWT ajax communication is just servlets. But they provide some really nice functionality for passing Java objects back and forth which you won't be able to utilize if your server isn't also using Java.

I wrote about some of the disadvantages of GWT recently. Mainly, the disadvantages are: long deployment cycle for changes to some parts of the application and a rather steep learning curve. As a seasoned Java programmer, the second should be less of a problem and if you use a seperate backend, the first is also mitigated (as a complete redeploy is primarily required when you change the 'server' part of the application).

GWT is a wonderful framework with lots of potential. Keep in mind that it's still quite new, though. There are some unresolved bugs that can really annoy you, and they usually require ugly workarounds to get past. The community is great but you'll probably end up with a few problems sooner or later that Google can't answer yet.
But hey, I say go for it. The potential for GWT is awesome, and I bet it's future will be bright.

You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)

This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT
Fundamental Advantage
GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.
Fundamental Disadvantage
The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?
This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?
Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.
Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.
Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.

You could also consider Grails ("Groovy on Rails") which gives you the benefits of a Rails framework and the use of the Java VM.

Our team recently asked the same question, and we chose to go with GWT, especially since the designer plugin made working with GWT more accessible to non-java experts on the team. Whoever makes this choice, just beware you DON'T use the GWT Designer plugin !! It has not been updated (in at least a year, apparently) to create a GWT application that is compatible with IE8.
Our team had almost completed our application layouts, which were working perfectly in Chrome, FF and Safari. Then they blew up in IE. IE 7 would load partial pages (but not composite includes), and IE8 was not even able to load up the application. It just hung.
The designer plugin has buttons that allow the user to add CellTable widgets that are not IE compatible (CellTable, DeckPanel, Horizontal Panel, Vertical Panel, among others). These will cause intense pain when the layouts have to be re-done in java without assistance from the designer.
Experienced GWT users love it, but the designer plugin will kill you.