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.
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.
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.
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.
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.
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/
I've been working with ASP.NET MVC for about a year now. I enjoy the ability to create SPA's especially by using the following tools:
Partial views(via html.action() and renderPartial())
Ajax helpers (Ajax.Actionlink() and Ajax.beginform())
My question is, Is it safe to just continue without a JavaScript frameworks or am i seriously missing out on something by not utilising a Javascript framework like Angular JS.
This depends a lot of the type of application you are building, but in general you don't necessarily have to choose between ASP.NET MVC and Angular, you can use both in a project.
For example, if you have a page with a grid where the user will add rows and you have to calculate sums etc you could use angular on that page (and it will speed up the development process).
But if you have pages with static content you can just serve an html file there using ASP.NET MVC.
And you can even use both of them. For something like a blog post, you can use a static html file for the post content and then implement the comments are with angular.
Since ASP.NET is a server side framework, it can only go that far as AJAX insertions. Angular JS is a client side Framework, designed for SPA in mind. If you are going for a light SPA, ASP.NET will do nicely, but I think you should use the right tools for the right job. Don't hesitate to mix them in order to find the right place between server side rendering and client side dynamism.
You are definitely missing some things.
The purpose of frameworks such as angular is not just to handle your bootstrap tab switches or whatever to display just parts of the UI rather than everything. Sure, you can create small and simple SPAs by utilizing such logic but once you come to create real-world apps that approach will become unusable. The reasons to this are:
Your site will be highly unmaintainable
Frameworks like angular provide much more than just templating (more on that in a moment) but features such as routing, which allows on-demand content loading. That is, instead of sending the whole page to the client, much of which (s)he maybe will not even take a look at, you can load fragments of HTML on-demand, which reduces network usage. Imagine you had to download everything (posts, images, videos, chat messages etc) on Facebook and hide them until you actually want to see them.
Back to templating, this is a very powerful feature. Again, in the case of simple apps you can use custom JS code - that is, concatenate strings to create fragments of HTML and then insert them into the DOM. But even with simple apps this is a smelly thing to do. Imagine you had to write custom JS to concatenate your chat messages in an app like Facebook then insert them into the DOM. With angular2, for example, you can do something like this:
<ul>
<li *ngFor="let msg of messages">{{msg.Sender}} said: {{msg.Content}}</li>
</ul>
This way, Angular2 will do all the parsing and DOM handling for you. That is, you write declarative markup rather than imperative logic for what you want to display.
All in all, they help you to decouple the logic from the UI so you should definitely dig into any of the popular frameworks and get a taste of their capabilities if you want to create rich apps. You will not regret it.
So I just spent the past 5 hours reading up on Angular JS. It seems like a lot of people are heavily associating this framework to single page applications especially when accommodated with a back-end MVC framework with nice API usage like Ruby on Rails or Laravel.
I have 2 main questions that have been boggling me:
How do you initialize such apps considering that the content is
dynamic in nature. When using something like RoR/Laravel, I'd prepare
the HTML with the dynamic data at the back-end and then serve the
initial pages. It seems like most people using Angular serve up a
basic skeleton of the HTML and then do a round trip to web server
again for some data. Is this really how its done? if not, please
suggest a the right way.
Secondly, I dont think I am about to embark on a project with a
single paged application in mind. Does that mean it would be overkill
to use AngularJS for my project. Does anyone have a use case that
they think is appropriate that would require AngularJS with non
single page application that jQuery cant handle easily?
I would like to build a new web site using AngularJS. The idea is to build a server side API with Ruby on Rails that serve Json to a front-end AngularJS.
My question is: Is it better to create a full AngluarJS front-end or a standard ruby on rails front-end with some Angular ?
I know Angular can handle routing so a full application is possible but it looks like the default behavior is for single page app.
For example I wonder if it's not a problem to make some change in an angular page 1 that should modify a page 2. This page 2 will not be updated until an action is taken on the page or the user reload the page.
Is there something wrong in my approach ? What do you advise ?
Thanks for reading.
I have personally done variations of a number of angular apps, varying from SPA with 50K+ views to simply using angular as an extension of basic javascript for useful testing and modularization.
The answer to your question isn't actually all that technical but more has to do with the nature of your application and team (You're essentially trying to pick what type of screwdriver to use). As what you're trying to do is feasible on both the client and server side.
Important questions to ask:
Is your team more comfortable in Rails or Angular
How dynamic are your web pages expected to be
What browsers are you supporting
Is there a requirement for data latency and communication with the server
Are you also going to be reusing the server API for other applications
These questions will drive you towards use of Angular or Rails or the combination of the technologies to find the balance.
The routing mechanism in angular is only within a single window object.
If you have two windows you will have two angular applications. If you want to communicate between the windows object angular does not provide any special mechanism further than standard HTML and javascript.
I don't know what is the better approach for you, that depends in your business requirements and constraints.
I am very new to javascript and have mainly been learning Rails previously. I want to be able to make more dynamic websites that give a more dynamic user experience but I am not sure wether to learn Angular.js or JQuery. I want to still serve the web pages through Rails and do not want to get into learning how to build a full SPA and Rails API and connect the two yet.
On the one hand I can see JQuery would be good for adding dynamic interactions to my pages but I have also seen that Angular.js is very popular and many people have told me I should go straight into learning angular. I also like the idea of being able to eventually make full SPAs with Angular in the future.
My main concern is I do not feel ready to start learning how to completely separate my frontend and backend using a rails API and a Javascript framework and would prefer to just add some interactivity to my pages and continue furthering my knowledge of Rails.
Is it possible to use angular to add small amounts of interactivity to multiple pages without having a SPA front end and Rails API?
Thanks for any advice.
Of course you can.
Add html pages to your public folder and put a script reference to AngularJS and you are good to go.