We Keep Coding

How to write a modular JavaScript application?

I am planning to rewrite an existing Silverlight application using HTML, JavaScript and CSS. This will be a rich internet application connecting to a server only for data (JSON based web services) - so there will be no server-side presentation framework such as JSP or ASP.NET. The application consists of about 8 screens, most of them in a tabbed layout. The question is...
What is the best way to write such an application in a modular fashion? I would like to write the individual screens as standalone modules communicating with each other only via events. I would also like to use some sort of an MVC framework to decouple the presentation layer from the model.
Any thoughts on which frameworks I should look at? Have you had a good experience using them? I am starting to look at Backbone.js, JavaScriptMVC and SproutCore. Am I missing anything that is worth considering?
Thanks in advance for your time.
P.S. If you'd like to see the application that I am trying to rewrite, an online demo is available here - it is a realistic trading application built for learning and comparing technologies.

I haven't yet had a chance to try SproutCore, but I hear good things about it and want to look into it at some point. I would recommend trying out at least Backbone and Sproutcore to see which of the two fits your needs and your programming style better.
I do a lot of work with Backbone, and what your suggesting sounds like it would be a very easy fit with backbone. I follow an event-driven architecture with my backbone apps and I find it works very well. it keeps code clean and separated, and allows me to add functionality easily by binding to events that my objects raise.
there are a lot of great tutorials and screencasts for backbone out there, too. here a few of them that should hopefully give you some of the information you need (including my own blog posts):
http://lostechies.com/derickbailey/category/backbone/
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ (introduce event-driven apps in backbone)
http://joeybeninghove.com/2011/08/16/backbone-screencast-introduction-views/
http://peepcode.com/products/backbone-js ($)
http://tekpub.com/view/mvc3/6 ($ and specific to ASP.NET MVC integration)
again, don't just pick one and never look back. it's worth your time to at least do some simple trial applications in backbone and sproutcore, if not additional frameworks.
hope that helps.

With Sproutcore, you can create so-called frameworks so separate your application. Every SC project has a frameworks directory, you just add a directory for your custom frameworks, and include the frameworks in your buildfile.
It's not a bad idea with SC to at least separate your Model layer into its own framework, for loose coupling and testing purposes (SC is heavily MVC). It might make sense to separate your screens into their own frameworks, depending on how beefy they are. One of the benefits of this approach is you can reuse your frameworks in other projects if needed.
SC also includes a robust Statechart mechanism, so using custom events is quite natural, and because of the statecharts its relatively easy to insure that the events are handled only when the app is in the right state.

Have you tried the Relay framework? Your write your individual screens as standalone modules and use relay's event system to link them together.
http://relay.github.com

Javascript framework for Java EE project

I'm working on a Java EE project right now, using lots of javascript function, but only using jQuery library.
I would like to know if anybody has some experience with this, used a Javascript framework with Java before, and tell me what would be the best way to do it, and best tool to do it.
Also, part of requirements are that I want to use the Framework to make it easy to handle the events, and to define a state machine for the website. I was looking a sproutcore, but couldn't find any information on how to use it inside a Java EE project.

For pure frontend compilation, there are several options, darioo mentioned Google Web Toolkit, though this is all very low level and thus harder to roll into out of the box. There are several GUI frameworks out there based on GWT.
Ext GWT
Smart GWT
Vaadin
Out of those three I hear our Java devs are most happy with Vaadin, though it's quite hard to create really customized (your average funky website with never before seen features...) frontend apps with these frameworks and you will long back for the expressive freedom JS toolkits like jQuery have to offer in a lot less code.
Then there are hybrids (JSP based), allowing more freedom in you frontend files (aka. frontend developers can tinker with it without knowing Java). Java code doesn't compile JS, but offers out of the box solutions you can tinker with in the JSPs.
JSF2 (uses YUI)
Spring Roo (uses Dojo JS framework)
Spring Roo scaffolds an entire frontend provides/uses the Dojo framework. JSF2 was/is looking nice as well according to our Java devs, though wwhen looking at the website, the angst of Oracle seeps in.
Both Dojo and YUI are quite expansive and mature JS frameworks specialised for large JS projects. Whereas jQuery is nicer for smaller JS projects with a rather flat architecture.
Ignoring Java based solutions, you can always fall back to YUI, Dojo or even MooTools for more architecture options.
You can also stick with jQuery, but imo. you need to be happily insane and masochistic (aka. frontend/JS developer) to maintain large scale JS/Html/CSS projects. jQuery is a nice toolkit, but as a framework, it offers meager architectural/structural solutions, you will have to devise them yourself by mixing and matching it with other small toolkits like RequireJS.
My best advice would be, build your app without JS first, using page refreshes and whatnot. Then apply a JS layer and build Ajax services for that layer. That way, your views and JS solution are losely coupled and theoretically, you can always switch frameworks without touching your JSP's too much.

If you already know Java, Google Web Toolkit is the most Javascript centric framework out there that I'm aware of.
Note: it's not just another Javascript library like jQuery, but a full blown framework with set rules you must adhere to. By writing Java code, it will generate Javascript for you that's highly optimized for speed, size and multiple browser compatibility.

What kind of architecture should I learn to make good JavaScript based software?

I know Model-View-Controller well, have known about it for years and used it in terms of server-side development with languages like PHP.
However, I am now working with JavaScript and building a big application with it utilizing SVG, Canvas among other great features modern browsers support. The project is big, so, the architecture behind it must not be fragile.
JavaScript and MVC do not get on like a house on fire, because JavaScript is event-driven by nature. So, are there any architectures or anything else I should definitely learn, understand and implement?
The software will have to deal with data. It already utilizes local storage and web SQL database. I need a Models, right? There is an UI, so I have Views? However, do I have Controllers? What about events? How do I structure everything?
Architecture, architecture, architecture -- that's what I'm interested in. I'm fine with the language of my choice.

First, I'm the author of JavaScriptMVC, so I'm extremely biased in a whole variety of ways. First, there are 6ish things you will ever do in a JS application:
Load Scripts
Respond to user events
Update the DOM
Request data from the server
Convert that data into something useful for JavaScript
Organize your front-end business logic
Your choice of architecture might depend on what tools you want / need.
For general architecture, I do think it's important to separate concerns.
I strongly encourage you to find some way of doing dependency management, and client side templates. They will make your life a lot easier.
JavaScriptMVC uses a tiered MVC approach that's based heavily around custom UI events and OpenAjax events.
I build my low-level widgets with $.Controller in a similar way to how you would build jQuery widgets. The big difference is that the widgets produce a non-ui event that top level controllers can listen to. For example, a tabs widget might produce a "tab.activate" event like:
$('.tab').trigger('tab.activated')
Then, my higher order controller might listen to tab.activated events, and a the model to update the tab content like:
".flickr tab.activated" : function(tabEl, ev){
Flickr.findAll({type : "rainbows"}, function(images){
tabEl.html("//path/to/view", images );
}
}
Flickr.findAll essentially does a query for flickr messages, then calls back with a list of images. Wrapping the service/ajax functionality with models makes them a lot more reusable.
You'll notice that in the callback I update the html of the tab element with the rendered content from a view. This probably isn't the 'best' way of doing it, but I wanted a quick example. Better would be passing the tabs controller the rendered output, for it to do what it will with it. That way if your tab wants to fade in content someday, it will be able to and your master controller won't have to know about the tab's implementation.
The most important thing is to break down your app into the smallest pieces you can. Have them individually testable (and flexible), and combine the little parts into bigger parts as you work your way up to your application.

Take a look at Ext JS. It has a clean architecture that is well-suited towards highly complex javascript applications.
Data handling and server communication is done via stores. Data rendering is done via grids (with in-cell editors), and forms (with a rich set of form controls), which can both talk to the stores. There's also a set of layout classes to abstract away CSS positioning (border layout, box layout, table layout, form layout, ...).
It is however not MVC in the typical sense. The library encourages a programming style that avoids dealing much with HTML and CSS, letting you live (mostly) in pure JavaScript land. You end up thinking in terms of components and data, instead of individual dom elements and style rules. If you don't like that approach, be warned, you won't like this library.

MVC is still the way to go, in my opinion. If you're looking for a good framework to help you achieve that a little less painfully, I would look at JavaScript MVC, it has models, views, controllers, unit testing, jQuery support, etc.

You should learn the Event Based nature of client-side JavaScript and how it blends with MVC based server-side applications.
You should also learn how to properly program inside of the Prototype based inheritance structure of Javascript.
Both of those things will allow you to write you JavaScript so that it meshes with your server-side application framework and is extensible and re-usable.

One thing i have learned over the years of javascript programming is writing UnObtrusive Javascripting which basically means seperating as much as possible structure(HTML) and style(CSS) from Behaviour(JAVASCRIPT).

Althogh not a raw javascript solution, take a look at CoreMVC, the jQuery architechure of MVC.
CorMVC is a jQuery-powered
Model-View-Controller (MVC) framework
that can aide in the development of
single-page, web-based applications.
CorMVC stands for client-only-required
model-view-controller and is designed
to be lowest possible entry point to
learning about single-page application
architecture. It does not presuppose
any server-side technologies, or a web
server of any kind, and requires no
more than a web browser to get up and
running.

If you want a ready-made reference architecture that combines soem industry leading JS libraries with some good JS design patterns for large scale development, have a look at:
http://boilerplatejs.org/
I'm the main author of it and thought of sharing knowledge we gained after developing few large scale javascript products. It addresses following main concerns:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation

Pure JavaScript-based clients

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.

Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.

I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.

Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.

Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.

What kind of architecture is good for my JavaScript software?

I am writing a software for a website where people can manage the website content. The interface is similar to Windows with all those windows floating around, click-able components, type-able text fields, etc. The admin interface is written in JavaScript, HTML and CSS. I'm wondering what kind of architecture should I apply to my admin system before it's too late (I've written some minor code so far).
For example, for the PHP back-end I'm using MVC, but what should I use for the client-side JavaScript admin system?

If you were developing an GWT application, you would automatically have an architecture. For custom JS, with AJAX calls a two-tier architecture would be more than sufficient. However, I prefer going the event-driven way, where I have a layer full of listeners and another layer of handlers. I use closures for the most part and use custom page-ids. Works like a charm. I rarely separate the AJAX calls out, owing to the single-threaded aspect of JS.
P.S: I had to use the term layers for lack of better alternative.

You can use an MVC on the browser too.
But it may be overkill.
The minimum you can do is to separate the HTML(view) and the JS(logic) code.
We use a javascript templating engine (PURE) for our JS app, but there are plenty of other available on the web.

jQuery and jQuery UI are a good start.

Have a look at JavaScriptMVC. It's an MVC framework for front end JavaScript applications. Version 2 is jQuery based so you'll get the power of that fantastic library into the bargain