205

We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.

This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.

We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.

This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.


UPDATE 17 July 2013 Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.

The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.

UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.

Modika
  • 6,192
  • 8
  • 36
  • 44
  • 6
    So how'd it go? I'm in the process of trying to figure out how to move a 50+ page ASP.NET application to a pure HTML + Javascript + REST application and I really don't get how that would work as a SPA. – Greg Oct 22 '13 at 21:07
  • 1
    We had to shift onto something else. From the discussions we had and will be having again as this kicks off again, is that and SPA can be a very focussed cog in a much bigger machine. So translating our instance to yours (we were using pure node with express) if you wanted to remain in a familar stack (.Net) you could use MVC as your scaffold and use angular within the views to add the dynamic stuff (each feature). unless you can condense your app down, implementing 50 pages of logic into a single page could choke. – Modika Oct 24 '13 at 10:04
  • 1
    What that does is make each section (i.e. users, news, products etc.) a SPA in its own right, but collectively they form your app. – Modika Oct 24 '13 at 11:39
  • 1
    Great, thank you. Is there any specific coding that has to be done to tie the different SPAs together? Or just regular links? – Greg Oct 24 '13 at 14:57
  • 1
    @Greg, from our limited knowledge so far, as they are essentially apps in their own right standard linking would work, obviously it probably wont be a straight forward as that and some form of persistence (cookies, local storage) will be needed to persist shared information like maybe and identity or profile if the app is behind some form of Login. Our apps will be tightly linked to our API and as we are building a trusted app we are using oauth to protect each request, i think Trello do something similar, but i could be wrong. – Modika Oct 30 '13 at 16:48
  • What's the best way to handle login in a situation like this? If it's a single page app all the authentication might be handled through the router. But what if you have multiple pages. Where's the state stored? – Fredrik L Jul 23 '15 at 17:42
  • @FredrikL this project got pushed to one side but i guess it depends. Our architecture was a core API which was the power behind the app so we used OAuth with the Request Owners password grant to generate a token on login, stored in a local cookie which persisted. Every API Call used the token, this was persisted the token across pages (apps). We didnt get around to securing actual pages in the typical sense before we moved on. We are picking this up again soon, so will update the question as we go along. – Modika Jul 27 '15 at 12:44
  • @Modika FYI, Angular2 supports the ability to load components on-demand. So, it's possible to specify all your routes but only load the main component + default route to start. In addition, it will be able to support nesting routers so you can create multiple layers of routing. – Evan Plaice Nov 03 '15 at 17:38
  • @Modika as a reader who also wants to know where it makes sense to use Angular, it would be useful to know how you reached the decision to build your app with Angular instead of your initial approach with Express. i.e. we see the consensus, but how did you reach it? – T. Webster Jun 18 '16 at 06:27
  • @T.Webster we used express as the framework and are building using React at the moment, but the general process is the same. Question has been updated, hope it helps. – Modika Jun 18 '16 at 20:15

5 Answers5

217

Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.

You have a large list of features that will benefit you outside of client-side routing:

  • two-way binding
  • templating
  • currency formatting
  • pluralization
  • reusable controls
  • RESTful api handling
  • AJAX handling
  • modularization
  • dependency injection

It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".

If it fits your project, use it.

Ben Lesh
  • 107,825
  • 47
  • 247
  • 232
  • 43
    Another point to mention is that Angular doesn't even need to be used for full pages - it can be integrated into an existing system to build components, i.e. a complex widget or plugin inside a legacy application. – Alex Osborn Mar 05 '13 at 21:06
  • 2
    @Blesh, thank you for the answer, it makes sense but what we are struggling to find is "the how" we use it build multi page apps which is why the question was posted, that is indeed a different question so your answer has been accepted but for instance can we use angular.js with express.js or is something like that just a waste of time and over complication. – Modika Mar 06 '13 at 09:41
  • Angular with Express is nearly ideal! It's really, really easy to create a RESTful API with Express you can consume from your Angular application(s). Google NodeJS Express RESTful API and Angular's $resource and $http services. After that, just start prototyping and playing with it. I think you might find you're overthinking/worrying too much about the "HOW" once you see how nicely they work together. – Ben Lesh Mar 06 '13 at 14:11
  • @Blesh, sorry for coming back late. We already have a REST/Hypermedia API built using Restify, i guess we need to find a neat way to link the separate "apps" created together somehow, will look into this and probably update the question at some point. – Modika Mar 11 '13 at 17:47
  • @Modika were you able to find any good resources, or have any good insights for multi page apps? – dre Jun 04 '13 at 22:52
  • To link the multipage app together, you might want to look into a clientside storage solution like [Lawnchair](http://brian.io/lawnchair/). You can easily wrap that in an Angular Service, then use that in each of your Angular apps on each page. If there's something you need to persist from page to page, you should be able to do it there. It's either that or you'll have to shift the burden to your server, which might be more reliable in some ways, but will be "chatty" and will create a dependency on session information being stored on the server, which might not be desirable – Ben Lesh Jun 06 '13 at 05:25
  • @dre, i think blesh makes a lot of good points in the answer and the latest comment. We are currently finalizing our API and have not delved too deep into the Angular front end stuff yet, but we are looking how other apps do it (not specifically Angular just in terms of overall design) like trello which uses HTML5 push state where we mimic the multi page approach but still are still working on the single app paradigm. We will definitely put some pointers up when we start implementing for anyone who is interested. – Modika Jun 08 '13 at 14:10
  • This comment is dead-on. I use AngularJS daily to build SharePoint 2010 applications which leverage ASP.NET pages. I just use a WCF service with WebInvoke for the web service and $http to invoke. Works just fine with a multi-page app. – sidney.andrews Aug 26 '13 at 16:52
  • I wholeheartedly support the spirit of this answer. I would just add that certain features are definitely designed only with SPA-type functionality in mind. If you try to use Angular form validation with a "classic" round-trip HTTP POST you'll find yourself doing all kinds of workarounds. I know validation wasn't included in the list of features. Just saying that there are things that don't make sense for traditional HTML forms. – regularmike Jan 05 '15 at 04:11
  • @regularmike - your example "Angular form validation with a 'classic' POST" ... No workarounds, just set the method and action, like any other form: http://jsbin.com/pilufe/1/edit?html,output – Ben Lesh Jan 05 '15 at 17:57
  • @BenLesh yeah, I got that far, but do you know a way of hiding the error messages until submit is clicked? It's OK to show 'required' but something like 'credit card is invalid' is a bit awkward. I couldn't figure out how to hide messages without using an `ng-click` or `ng-submit` function that calls `submit()`. Checking `$touched` only works if field has been blurred, which doesn't seem reliable. I thought I could check `form.$submitted` in an `ng-show` directive on a div with the messages, but that won't get set as long as the button is disabled. – regularmike Jan 05 '15 at 18:16
  • For a credit card check you're looking probably a custom validator. I'd recommend feedback to the user ASAP, rather than after submit is clicked, but if you do go that route, you'd do the check, then set some error message and prevent default. This should probably be another question on SO, if it's not been asked already. – Ben Lesh Jan 05 '15 at 20:44
  • Yes, I ended up implementing with a custom validator. But I don't think it's appropriate to complain to the user as soon as they start typing the first digits of their credit card number. And it seems difficult to avoid doing that without wiring up an event handler. – regularmike Jan 28 '15 at 22:56
16

I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.

Ron
  • 353
  • 3
  • 7
6

Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:

https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/

Each of these applications has it's own local routing mappings between states in the application. I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.

Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.

In response to your question:

Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.

I also support the idea:

What’s the difference between a project and an app? An app is a Web application that does something – e.g., a Weblog system, a database of public records or a simple poll app. A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.

fedorshishi
  • 1,467
  • 1
  • 18
  • 34
3

If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.

Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.

Javascript namespacing allows you to keep your code separate and manageable.

var myCo = myCo || {};
myCo.page = {
    init: function(){ ... },
    ...
}

And in a script tag after your other scripts are loaded

<script>
    myCo.init();
</script>

The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).

Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.

Fred
  • 1,344
  • 1
  • 11
  • 16
1

I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.

Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.

Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.

Links:
https://vuejs.org/
http://aurelia.io/

Filipb
  • 31
  • 3