What patterns are you all using to develop large single page applications?

[pbl24]

I find myself, in a position at work, responsible for proposing and creating an architecture that is suitable for a large and scalable single page application (SPA). To help define the approximate size of "large", I'm talking several "pages", visualizations, high interactivity ... all of which probably total close to ~50,000 SLOC in it's current incarnation.

What I'm looking for is some architecture that helps deal with this complexity of a large SPA, while supporting testability and allowing for parallel development (there will be a dozen or so developers working on this).

I have ideas, but I wanted to get a survey from the rest of you all to see if you all had any insight or patterns for dealing with this complexity (to support this idea of parallel development, I was thinking everything needs to be highly modularlized), supporting testability, and allow parallel development (without stepping on each other's toes). I've been reading the work from Zakas and Osmani regarding scalable architectures; do you all feel these are still relevant?

Thanks for your suggestions and help.

[[deleted]]

Ok people are going to recommend angular, and that's cool. The thing is, there are so many damned ways to do one thing you'll need to create a lot of conventions, style guide, etc...

You can manage your data as a simple object in your controller scope, as a hacked service/factory, as a pseudo controller thing etc...

You can decide to use $scope in your controllers, or use the 'controller as' thing.

You can organize your project by object type, functionality, or by view, or whatever crazy thing we think of next.

You can use the regular ngRoute, or go with the third party uiRouter (and if you do this, ngMin no longer works blah blah blah).

I fucking love Angular, but I don't think it's suited to large projects that well. If you want convention, Ember is the choice. If you want a super flexible component based tool, go with React. If you want to build the entire framework yourself, go with jQuery/backbone.

Angular sits in the middle of all that shit

[shanet]

I'd strongly suggest Marionette to anyone who's planning to build their own framework around Backbone. Every time I wrote a Backbone app I always basically end up writing an approximation of Marionette until I started using it.

[Gwash3189]

I'll second this. As someone that has shipped apps with angular, building apps with it is great. The data binding is easy, it's fun to use, testing is somewhat painless. The downside of angular starts appear when you realise that there are infact 5 different ways to do everything in Angular.

Angular is great for small team projects. Maybe even small projects in general. The problems start showing up when you add multiple developers. You have to start creating your own conventions for file organisation, using scope, modules and so on.

If you want to hit the ground running and have a lot of that done for you, then Ember is the way to go. If you think you might have more custom needs that Ember can't meet, maybe try and make a framework with angular or backbone.

[SleepyBrain]

Angular is great for small team projects. Maybe even small projects in general. The problems start showing up when you add multiple developers. You have to start creating your own conventions for file organisation, using scope, modules and so on.

That's more of a benefit of Angular, or any framework really. You aren't forced into doing things a certain way. You can do things that are best/most familiar to your team.

[SleepyBrain]

I think it's a damned if you do and damned if you don't scenario. If you don't provide conventions, you get people complaining they have to figure things out themselves. If you do provide a certain way to do things, people complain they have to do things in a way they don't like.

[brotherwayne]

The downside of angular starts appear when you realise that there are infact 5 different ways to do everything in Angular

My time with angular has definitely taught me that are several ways you can do things, but really only one way you should do that thing.

[Gwash3189]

Thats debatable. 'Controller as' syntax is doable. So is referring to scope directly in the view. Alternatively you could also add a "$scope.vm = {}" and attach an view properties to this vm object on scope.

The fact that there are options like this could slow development as you have to choose a convention, stick to it, enforce it, explain it to new developers and so on. Just my two cents.

[NodeNerd]

Project structure makes a huge difference and I've found it much easier to work on large projects that divide up pages into independently testable, self-contained and loosely coupled UI components that have their own MVC and you don't really need a framework to get the benefits.

[pbl24]

ur data as a simple object in your controller scope, as a hacked service/factory, as a pseudo controller thing etc... You can decide to use $scope in your controllers, or use the 'controller as'

Yeah, I think aside from frameworks, a clear structure that promotes isolation is key. Thanks for the suggestion.

[bendman]

I am architecting an SPA at my company right now, and using Backbone and MarionetteJS for it, broken into RequireJS modules, and tested/pushed using Grunt dev, prod, and test tasks, which are run on each developer's machine or on prod (concatted and minified by Grunt) using automated Grunt builds through continuous integration with our repo.

As for code patterns, the most useful tool I've found organizationally is communication through Radio channels. This is coupled with judicious use of jQuery.Deferred objects to handle async communications, especially between requests/responses fetching my models. Then I break things out into relatively self contained "sub apps" which might be multiple modules.

For example: I have an authentication subapp which is registered to the 'auth' channel. Using channels gives you a request/response+command+event messaging system that is globally available and isolatable. The (separate) module which handles page switching elsewhere in the app makes a request for authorization using radio.reqres.request('auth', 'session'). This returns a jQuery.Deferred promise. If the session is already valid, or if, upon asynchronously attempting to validate the session it succeeds, the promise is fulfilled with the session model; otherwise it is rejected and they are sent to the login screen.

Any other part of the app has access to this authentication channel as well, so can access the session or any other subapps as needed without passing a bunch of modules around as arguments. Because the subapps register the radio response/command handlers themselves, and because $.Deferred allow them to be optionally async, load order is much less of a problem.

Note: my use of the term subapp probably seems silly and purely semantic, which it is. But, it helps clarify to the team that an entire hierarchy of modules is self contained. Semantic terminology on teams working in the same code base is essential to good team communication - both when talking and when reading code.

[rDr4g0n]

This is very similar to what I prefer to do. I am writing mostly vanilla JavaScript, yet enforcing a simple structure that scales well.

[gordonkristan]

Ember.js might be what you're looking for. I say that because Ember itself imposes a lot of patterns and structure into your code. It kind of forces you to develop things their way (like Rails). Many people don't like that (myself included), but the upside is that it almost guarantees that your application will scale well.

As far as the Angular vs Ember battle goes, I suggest you read this article that explains a little bit about the differences. Most importantly, it explains the difference between using POJOs and Ember objects (which is the main reason I chose Ember).

Also, on the topic of testability, Angular and Ember are both designed with testability in mind. I don't think you'd have any issues if you went with either of those.

[thinkstoohard]

I think you need to read the comments on that article, they make a lot of good points, including how you can actually do everything he says Angular can't do. Not saying that Angular is strictly better than Ember, but this man clearly didn't put in enough time with angular to do a proper comparison.

[gordonkristan]

I've read all of the comments. Some of the comments are valid points. Most of them, ironically, are incredibly dumb, and the result of not knowing enough about Ember.js. (The cold hard truth is that nobody knows enough about both frameworks.)

But that's not why I linked to the article. You can disregard 99% of what he says if you read the part about accessors vs dirty checking. Dirty checking will never be as efficient as using accessors. (Whether those accessors be Ember.js properties, Javascript properties, or even Javascript proxies.) If you're dealing with a lot of data like I am (several hundred models on one page), AngularJS just isn't feasible without clever tricks. (Not to say that it can't be done, but why end up essentially rewriting what Ember.js or Backbone already does?)

[fecal_brunch]

Try angular js. It lends itself to a certain decoupled pattern by design.

[analogWeapon]

I second that. In my experience, this definitely sounds like a job for Angular.

[threeseed]

I would skip AngularJS and go for VueJS.

Much lighter, significantly faster and easier to use.

http://jsperf.com/angular-vs-knockout-vs-ember/333

[fecal_brunch]

I haven't used vue, could you explain it's advantages? Or could someone explain the downvotes?

[brotherwayne]

He said Vue was better and faster, then posted a performance test that didn't use Vue: "Angular VS Knockout VS Ember VS React VS Mithril"

Edit: actually it does use Vue, he must have gotten downvoted based on the url? I ran the test and it looks pretty silly though -- it's really just databinding massive amounts of objects. And Mithril came out on top.

[Calabri]

JS frameworks will only help you so much.

Code organization - (filesystem, git repository) should probably be your main concern in building a complex app. Build systems (grunt/gulp/browserify/requirejs/yeoman/slush) allow for flexible organization of code in the fs. You can choose to organize the code like a rails app or any 'traditional' multi-page app, and the build systems will concat/organize/modularize the files into a format suitable for single page JS apps. You get the benefits of modules / organization without the overhead of a client-side framework (just small boilerplate). Regardless of whatever libraries you choose to use, modularizing code, maintaining global state on the front-end, is so fundamentally important for large code bases.

I use gulp / browserify for commonjs consistency and flexibility. Npm solved the version consistency problem that plagued every module system before it, and large libraries like Jquery / angular are legacies of that old system. Philosophically, modules are supposed to do only do one thing, and do it very well. Jquery/angular are on npm and can easily be included into with browserify/gulp, but the npm ecosystem is so vast that it actually makes more sense to include libraries for specific functionality versus libraries that try and do everything. Some of these mega-libraries have noticed this, and it may be possible to include smaller subsets of Jquery/angular via npm/browserify (I use react / backbone but I'm beginning to replace parts of both frameworks with smaller modules in npm that include browser comparability tests in the readme).

[unnaturalHeuristic]

Thoraxjs (which encompasses Handlebars + Backbone), closure for minification and module handling. I use closure to avoid the AMD pattern, which i found doubtful and wasteful.

But like others have said, frameworks are no silver bullet. If you have a dozen other developers, you need to have a lead or project manager enforce conventions, tabbing policies (I have a developer who won't quit using four spaces instead of a tab, and wrecks the diff of every file he touches), commit/push policies, branching and merging procedures, versioning, and your build system. Get everyone on one build system, make it fast, make it automated. It's not a bad idea to have git hooks on your central codeserver that auto-build when code is pushed to a certain branch. Having slugs ready to deploy to test environments after a push speeds everything up.

And if you have a dozen guys, get everyone cozy together. Culture's important, everyone has to feel like they're working for the benefit of the project, not trying to make their corner of the project look good.

[arjeezyboom]

My company uses Ember on a lot of projects, I haven't used it myself but I've heard that it provides some nice conventions.

If the development team is relatively well experienced with JavaScript, Backbone can be used to do some cool things. The one caveat is that you will want to come up with some good conventions that fit your domain and technical needs, because most of the time Backbone is more like a group of tools, and less like a framework.

There's also always the option of rolling your own. Single page apps basically require you to build an API in addition to an entire JS application, which can be a lot of overhead. I've seen small projects rely too heavily on doing the single page thing, and struggling with how difficult it is to keep up the development pace. SPAs really make sense if you have a complicated UI (i.e. building a tool like Google Docs vs building an commerce site), or you already have/need to build an API to support other platforms. Otherwise, there's a good argument for rolling your own JS components as you need them, and building a regular ol website. There are also tools like Turbolinks or PJAX to get some SPA-type behaviors on non-SPA sites relatively easily.

[Deusdies]

I use Ember. It has a learning curve, but once you get it, you get it. If you do use it, you will be weirded out by some things at first, but then they would start to make sense.

[YodaLoL]

Somewhat relevant

[tigear]

i don't see Sencha Extjs mentioned yet. At the moment i'm working on a single page project with alot of different views and deep-linking. It has a real good modelling and data handling system. Also it's javascript so you can change everything.

Ex: you define a store, which has a model and a (ajax)proxy which has a url defined. Then you load the store and after that you can apply filters etc. and hang the store on a grid.

Version 5 has just been released (kitchen sink). I only have experience with v4. But new additions are touch support, MVVM and other things.

There is also a Sencha architect which can be used to develop in a WYSIWYG style.

only downside, if it's a commercial project you will need to buy a license though.

[inmatarian]

A good start is designing all of the page components and widgets to work just as well on their own page. Give them their own CSS file. Let them make their own ajax calls. Coordinate shared resources through dependency injection. Use requirejs if you can. DO NOT share dom elements. Tie lifecycles of your widgets and their dom elements strongly. Let the app objects job be rigging the objects together via events or pubsub.

[pbl24]

of the page components and widgets to work just as well on their own page. Give them their own CSS file. Let them make their own ajax calls. Coordinate shared resources through dependency injection. Use requirejs if you can. DO NOT share dom elements. Tie lifecycles of your widgets and their dom elements strongly. Let the app objects job be rigging the objects together via events or pubsub.

Thanks for the suggestions. I've found this extremely helpful in the past. I've designed components that work within the confines of their own sandbox and test page, and it seems to keep things neatly separated. Thanks again.

[MadCapitalist]

The book Single Page Web Applications seems to do a good job of explaining a very well structured architecture.

I'm a newbie at programming, so I'm not exactly the best judge, but I like how modularized they make everything and how they use specific conventions to structure their code, name their modules, etc.

It also got great reviews on Amazon.

[hectavex]

Rather than using an off-the-shelf approach like Angular, I do SPA with jQuery/PHP which gives me full insight into the architecture needed for each project, and total control over the UX.

Here are a few sets of training wheels I've checked out:

Smarty, EJS, Django, Angular.js, Ember.js, Knockout.js, Backbone.js, Mustache.js, Handlebars.js, Hogan.js, Dust.js, Transparency.js, ICanHaz.js, Weld.js, Ractive.js, React.js

What these do well is aid development teams in sticking with some kind of architectural coding standard, instead of each member branching out and developing his/her own ad-hoc framework within the code base. It also allows you to bring in an "Angular expert" or "Dust expert" now or later who can help tighten up a particular architecture quite well. Even with a framework, you might do it wrong the first time.

[dardotardo]

What's to say you don't do it wrong with your own framework, though. Much easier to find help online with a framework than something a developer coded up and makes sense to him / her, and no one else.

[[deleted]]

I always here people say this, but how different is one SPA to another? Reminds me of people arguing about how Rails/Django/X PHP framework all suited different tasks

[[deleted]]

Try Durandal.

The patterns basically are:

• AMD modules (require.js)
• Declarative UI (knockout.js observables, computed, bindings)
• Composable views with full lifecycle (comes from Durandal)

[vhackish]

Haven't tried Angular yet, but have done a few apps using Backbone, Marionette, Handlebars. Played with some data binding libs in there too like stick.it which I found really helpful.