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/
Related
I have a Back-end web application that provides me with custom API endpoints (Java - Spring). I like to keep everything separate. one API application that provides everything else remotely. My question is: What is the best practice to start a new Front-end project that connects to my API?
Requirements:
The Front-end project should be on a different server
The Front-end project should support routing, meaning I will have full control regarding the /paths. so no .extensions at the end.
SEO is very important in this specific case.
My preference is to go with React.js but I have doubts regarding SEO because the project I want to migrate from is WordPress (up and running with a good SEO performance).
I wish that I can find a simple solution with pure HTML, CSS and some kind of JavaScript.
Thank you.
React isn't actually bad for SEO. So long as you're taking the proper steps to ensure that the page load time isn't bad. If the site that you're migrating is massive, make sure you're lazy loading.
If you have doubts that Google or other search engines will render the js, then I suggest going with Nextjs like Rakesh K mentioned.
There's also nothing wrong with recreating the site with a templating language like Handlebars, then rendering it on an Express server, or whatever suits you. Just including this option in case you don't know React, and don't want to have to learn it.
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 mostly worked with Springboot framework only with JSP to cover the things I need for the website part. Now, I've got a project to do that mostly revolves, if not all, around the website and I have a couple of questions.
Just to be clear first, I don't have experience either with Thymeleaf or Angular so whichever I pick will be the first time (I think thymeleaf syntax would be easier for me to handle).
Ok so the main goal in my mind is not to render the whole page every time I load data from the backend, so I figure I would have like a header/content/footer parts where every time I click something only the content part would change. Also, I would like the possibility for a loader to show and go away when the content part is changing. This web application will need to be secure for users that register.
I've searched the web to investigate both frameworks, but can not seem to find the right answer so I can continue with my development
I do not mind creating separate REST services in later development if some other platform needs to hook up to the service if I decide to go with Thymeleaf.What do you guys think in what direction should I go, Thymeleaf or Angular? Any help and/or discussion would be much appreciated.
I am sorry if this seems like a general question, but I just need some basic guidelines to start with. Cheers!
I think transitioning to ThymeLeaf is probably going to be the easiest for you, but Angular is a great choice as well, and from there it is up to you. Would you rather use mostly expressions similar to JSTL expressions, but in Spring's SpEL language, then use ThymeLeaf, or would you rather use JavaScript, then use Angular. It just a user's preference for what you are doing.
The fragmenting portion (header, footer, body, etc..) is native to both frameworks. It just depends on which one you want to use. Whatever you go with, to load specific sections while not rendering the others, is going to require AJAX and for you to feel comfortable with how the template frameworks work.
I would suggest reading up on both of them to figure out which one you feel more comfortable with.
Angular
Thymeleaf
Both of them have great documentation for beginners and the Baeldung and Mkyong have good walkthrus for ThymeLeaf. Angular's documentation I found good enough on its own.
For a loader, you can do with simple CSS and JS. There is a ton of demos out there on how to do full screen loaders and how to turn them on or off with JS or CSS. IHateTomatoes has a good article about how to build a full screen loader, that has a No JS fallback option and should give you a good starting point.
Your point about it needing to be secure is a whole other monster. I would look into Spring Security. It's relatively straightforward, especially when using Spring Boot. If you want it can control the users session and assist in preventing session jacking, add CSRF to prevent cross site forgery, control permissions to urls and on down the line, or not. It all just depends.
Either way, don't randomly stab at security, it will end up in something that you feel is secure but it is not, which leaves you and your users in a very bad spot. Again, Baeldung has a great walkthru on the user registration and login process that can help get you started with Spring security and how to tie everything together.
Pretty high level answer, but hopefully gave you some good starting points and some resources.
Build apps decoupling frontend from the backend.
Always build apps following the "The API-first approach"
The API-first approach involves setting up the foundation of your app, which is the application programming interface
For me the differences between Thymeleaf and Angular:
Using Thymeleaf: You don't need to create Restful/web service endpoints on your frontend side because you just need to make calls to the backend from the frontend itself.
Using Angular: Besides of your Restful/ web service endpoints on your backend side, you have to build Restful/ web services endpoints on your frontend side because you don't want to expose direct access from Javascript code to the backend.
Hope this helps and happy coding time!
Facebook React can use a unidirectional data flow pattern called Flux to give structure to applications by using Views, Actions, Stores and a Dispatcher.
I have found the following Flux libraries for Angular:
ng-flux: https://github.com/JustinWinthers/ng-flux
angular-flux: https://github.com/brentvatne/angular-flux
song-flux: https://github.com/gah-boh/song-flux
And this sample: http://victorsavkin.com/post/99998937651/building-angular-apps-using-flux-architecture
Are any of these production ready?
Which ones have plans to migrate to Angular2 and integrate with the Component Router?
I can't seem to find any large application samples using any of these libraries. Additional links would be useful.
I authored ng-flux and I wouldn't say it's production ready since I haven't had the time to test it in a variety of projects. However I am using it in a fairly large enterprise class application currently. I agree that flux-angular has a good team around it and I'd recommend their library. Regardless, flux is simply a pattern that you can incorporate on your own. The issue with any Angular 1.x based approach is always the way Angular manages digest cycles and you have to sometimes jump through hoops for views to update in the background if you process data outside of the Angular namespace. In ng-flux I force a digest cycle if one hasn't occurred.
Flux as a pattern works well to me because it makes debugging and code separation much easier on larger projects, so my goal was to use this pattern on a project that already had substantial legacy Angular code and decrease the time it was taking to triage errors. It's an actuarial application with lots of calculations, so finding small data discrepancies fast was necessary. Writing ng-flux achieved this for me.
Regarding Angular 2, I think it will be easy enough to incorporate Facebook's dispatcher in your project and allow it to manage data flow. I think once Angular 2 is ready, based on what I've read so far it should be easier to use third party JS libraries - especially since Angular 2 will follow more of a web component based architecture somewhat similar to React. I've even seen promises that it will be easier (or more organic) to use third party routers, etc.... If this holds true, I doubt you'll actually need a library to manage a flux based data architecture in your Angular 2 apps. It should be fairly seamless to simply use something like the Facebook Dispatcher as a singleton (properly namespaced) object in your app that you can reference in your Angular components. I think most of the library authors out there realize this - it's more a problem for Angular 1.x apps to use this pattern than it will/should be for Angular 2 apps.
https://github.com/facebook/flux/blob/master/src/Dispatcher.js
I am not a pro in ReactJS, however I am not sure that integrating Flux with AngularJS is really a focal point for many Angular developers. With the release of 2.0, the Angular teams is continuing to make the framework more and more self-sufficient so people do not have to jumble together different libraries, but instead can just rely Angular to accomplish the task at hand.
That said, it seems like this flux-angular libary is stable with versions' 1.x, and it seems like it has pretty good support. I know it does not help your case when dealing with 2.0, however, it does seem like a solid enough API; but, then again, maybe I am just biased because of the functionality I have been able to replicate using Angular 1.2 & 1.3 :)
I currently in the process of concepting a large single page web application.
There will be a lot of components, so a separation of concerns is important to me. The Server is basically a REST-Server with some sugar, like sending Template Code to the client.
So I need to decide which MVC Framework I want to use client side.
I really like backbone.js so I want to have a big Framework relying on it.
What I came over is Marionette.js and Chaplin.js.
Has anybody used one or both frameworks and can say a little bit about them? Strengths, weaknesses, community behind it or are they basically the same?
This should not be a discussion about which is better, just a short feature list, so I can decide better which one to use, because I don't have the time to really get started with both.
Haven't worked with Marionette but basically Chaplin is a wise decision when:
You need a more opinionated architecture. Useful if you need a set of rules/conventions to get up and running in a team.
Memory management is a concern.
You are maybe coming from a Ruby background and feel more comfortable using Coffeescript.
Also, if you are building a big application, in Chaplin get prepared to figure a LOT of things yourself. The documentation is there, but often you will find yourself 'alone in the dark'. Source is well commented though, which is appreciated.
I have experience with Marionette.js about 1 year.
Marionette.js is the best option when you have your own architecture, but you haven't ideas how working with views layer.
I like the next scheme:
Backbone as core for data layer (models, collection, rest api)
Marionette.js for view layer (ItemView for one entity, CollectionView for collection of entities, CompositeView(entity + collection) and so on.
Reveal.js data binding
HBS as templates
Your own routing and core logic
I've recommended to you brunch tool - is rich tool to compile, prepare and build your own SPA.
Of course you must see Grunt + Yo + Bower its another rich tool.