I am new to phonegap development & I am trying to pick a framework to use. I'd like to use AngularJS as I've read good things about it, but I'd like it to work with Parse.com as a backend. I noticed that one Parse.com they don't specify any compatibility with Angular, and all their documentation and Javascript API requires Backbone.
I know AngularJS supports http, so I can communicate with Parse using the REST API. But is this going to end up being a mess & will I save myself time & stress if I use Backbone with the Parse.com Javascript API instead?
I have not worked on Parse, but I believe as long there is a REST API available AngularJS can very well integrate with Parse.com. These links substantiate that fact
https://parse.com/questions/does-any-know-of-any-angularjs-sites-that-are-built-with-parse-that-are-open-source
http://brandid.github.io/parse-angular-demo/#/
Said that, AngularJS is a very capable framework with a steep learning curve. The simple stuff is simple but one needs to put ones head down and start learning the not so simple stuff like directives once one starts building any decent size application. The more you invest in learning AngularJS the more rewarding it becomes.
It has a very clean separation in terms of view and code. The code is further organized into modules, factories, services, controllers, directive, filters etc.
But still nothing stops you from creating a mess with the implementation :) What I have realized over the time is even if you create mess within AngularJS the effects are localized rather than affecting the complete application, due to the modular nature of Angular.
I suggest you try creating or looking at some samples with AngularJS (such as TodoMVC)
This is how i felt learning and implementing AngularJS solutions
Thanks for bring up our Parse x AngularJS boilerplate - we've just updated it today too.
Our entire site getbrandid.com is built with Parse x AngularJS and no servers of our own.
We built this boilerplate after because having spent a few years building BRANDiD, we had a lot of best practices to share with the Parse and AngularJS communities. We think it is a match made in heaven, and is the fastest way to build powerful complex, highly maintainable serverless apps.
We've basically extended the Parse SDK to support AngularJS bindings, we've eliminated a ton of boilerplate code, and most importantly, we've established an architecture for large serverless apps using Parse and Angular.
I highly encourage you to check it out -
Parse x AngularJS Boilerplate
Actually Parse's documentation does not say that you have to use Parse with Backbone, it just says that some stuff are compatible with Backbone classes, like the Collections object, which might be useful ONLY IF you use Backbone.
The big hassle of using 3rd party stuff inside angular is its lifecycle, as it uses POJOs and only watches for changes in these objects at specific points in time - Check the Scope Life Cycle documentation for more info.
Given that, when Parse returns its callbacks, AngularJS might no longer be observing those Parse objets, so you need a way of telling angular that thing changed, and you have to do it inside the digest loop, for example using $scope.$apply
I created a small wrapper for Parse.Query and Parse.Object to avoid the need for $scope.$apply all the time, let me know if you find it useful: https://github.com/felipesabino/angular-parse
The easiest way I found to communicate with the parse.com backend is to use the jimrhoskins/angular-parse Angularjs module that replaces the (backbone) ParseSDK.
Ads instant :-) I included it in this angular/parse boilerplate.
We've been using this method fairly frequently. We decided to document our experience. Its a 2 part series on building angular apps with a parse backend. Hope it helps!
Related
Both angular and laravel are great frameworks meant for slightly different purposes. Since they achieve to do similar things like -
They both focus on an MVC-inspired application structure, and each of them support a different directory structure by default
They both offer templating engines of their own, with conflicting syntax (which can be changed of course)
They both offer DOM iterators ( php foreach vs ng-repeat )
And many more similar conflicts
Since they are so similar in philosophy, isn't it redundant (and even conflicting sometimes) to develop a web app which uses both these frameworks?
Since each of them are so powerful in themselves, would it be a good idea to mix both? How common is the combined use of these in real world websites?
Am I better off using angular with basic PHP instead, if say, I was developing a medium scale web service (5000+ users)
What are some of the other backend+frontend framework combinations which are symbiotic and most frequently used?
Yes they can do similar things, but they don't have to.
Of course it doesn't make much sense to use the same feature of both of the frameworks. Meaning if you choose to use AngularJS for templating you don't need Laravel's views. But that's nothing you should worry about. If you don't use it, you don't use it. The fact that you don't use the entire functionality of a framework shouldn't have any bad impact on your application.
But note: Be consistent
Don't render one view with Laravel and use AngularJS for the other.
Recommendation
I personally have made good experiences with Laravel as a RESTful API and AngularJS taking care of the rest. So AngularJS is doing all the frontend stuff and communicates with Laravel only via JSON.
I'm working on a project which has the luxury of using ECMA 6 on the latest browsers for a product that will be shipped in 1.5 years. So we thought why not use Web Components now that Angular 2 isn't available (which is going to be ECMA 6). And while we are at it, can we replace Angular altogether without having to go back to stone age?
How to replace Angular?
There's this site called youmightnotneedjquery.com which is basically about how modern browsers actually have most of the stuff that jQuery was traditionally used for. I'm interested to see something like that for Angular.
We mainly use four Angular features. What are my options for replacing them?
Angular Directives --> Web Components
Angular Modules --> ECMA 6 Modules (not exactly the same thing)
Angular Routes --> ???
Angular 2-way databinding --> ???
PS. We don't want to replace Angular with something similar like Backbone or Ember. We want to replace it with standard web technologies but if we have to use small tools to fill the gap, we'll consider it.
I've been researching in the past 3 weeks and turns out many people are thinking about an alternative after Angular took a drastic change path. Fortunately the upcomming W3C Web Components standard actually has all we need and it works right now with polyfills from the Polymer project. So to answer the question:
Angular Directives --> Web Components use the polyfill until all browsers support it.
Angular Modules --> ECMA 6 Modules part of the problem is solved with HTML imports. But you can also use Traceur until the browsers support it.
Angular Routes --> There's a component for that™ use <app-router>.
Angular 2-way databinding --> Polymer adds a "magic" layer on top of the plain standard web components. This includes many features including data-binding.
+Plus More
If you're wondering about the build process for concatenating files in order to reduce the number of HTTP requests, take a look at Addy Osmani's post about Vulcanize. Spoiler: you may not need it with the upcoming HTTP 2 optimizations.
Many Angular projects use Twitter Bootstrap for the layout. Polymer can do that plus it plays nicely with Google's Paper elements (totally optional but superbly awesome).
If you want to make yourself familiar with web components in general, here is a bunch of nice articles: http://webcomponents.org/articles/
And here is a wealth of web components: http://customelements.io/ I don't know if it's going to be a new NPM, but the list components is pretty impressive and growing.
It's relatively complicated to expose an API for an Angular component. People have come up with all sorts of methods from link function to emitting events. In Web Components, however, it's really easy to make your component interact with the world outside and indeed the API and events you expose aren't much different from standard HTML tags like <audio>.
Just like Angular, you can use Polymer with Dart as well.
Conclusion
Overall, I don't see any reason to use Angular except if:
You have a huge source code investment in angular and don't want to port everything to standard web. (Angular 2.0 will deprecate your code anyway, so you're stuck with Angular 1.*)
Your team is too lazy to learn a new technology (in that case web might not be the right platform for this attitude anyway).
Angular was good for what it was doing and had its own Hype cycle. Web components solve many of the issues Angular was trying to address. Probably Angular had a role as a proof of concept for the Web components. But now it's time to move on. Web is reinventing itself everyday and it's inevitable to moves someone's cheese.
I'm not saying that Polymer is the ultimate answer to everything. At best it's another Angular which will render useless in a couple of years, but now it's a good time to learn and use it. The W3C standards don't die easily though, and Polymer tends to be much closer to them.
There's an element for that™ is the new There's an app for that™
TLDR: seriously consider writing an almost Angular 2.0-compatable Angular 1.3 app before rolling your own framework
It seems as if you've identified that Angular does a lot of things the right way and that's why you're attempting to replicate it, so basically you're going to roll your own by combining a hodgepodge of libraries. Unless you have an enormous investment of Engineering hours, the framework you build will likely be:
Lightly documented
A cross-browser maintenance nightmare and (worst of all)
Difficult for new hires to learn
If there wasn't a framework out there that did what you want to do already, I think rolling your own makes sense, but by trying to recreate Angular you're:
Taking on a lot of Engineering work that has already been done by a dedicated team, that could have been spent on building product
Made it MUCH more difficult to onboard new employees because you have to:
Find candidates that are willing to use a home-grown framework instead of growing their skills at an open source framework they could use elsewhere
Train these employees to use your framework (and good luck unless your documentation is mature)
I know your question asks how to replace Angular, but I've seen too many companies go the route of rolling their own and paying for it down the road. Again, if your budget includes a ton of core resources to build out (and document, and maintain) the framework and you don't think there is any chance corners will get cut when push comes to shove later if timelines get tight, then rolling your own might make sense. However, I think you should seriously consider reading up on how to write Angular 1.3 apps so that they're easy to port to Angular 2.0 and go the Angular route. Just look at the size of the community you're missing out on:
http://www.airpair.com/js/javascript-framework-comparison
We got an app written in AngularJS but we have run into performance issues as the app tries to load a large amount of data from the server and lets the user play around with it (read a complex DOM). Surfing around and reading about it seems that two-way data binding, intrinsically called $watch expressions etc of AngularJS is posing a problem that we are unable to surmount. And then we have come across fb's ReactJS that promises fast view rendering.
This has set us wondering if ReactJS could be used with AngularJS to just take care of the 'view' part. Would be very grateful if anyone could provide some insight or direction regarding this?
Thanks
This tool (single-spa, a javascript framework for front-end microservices) allows you to use different libraries and frameworks combine. In this way, you can save your old business logic.
Have you tried ngReact? I haven't tried it myself but it seems to do what you want (using React components in Angular).
i'm playing with that now to combine angular directives with react, but for my app in pure angular on large data set, i used angulars for $compile and rendering and it works pretty fast, but data manipulation and whole building of this part of HTML is done by d3.js, maybe you can look on that lib...
I'm still learning AngularJS, but I'm not sure if having less control (via javascript) as I read is a good thing. I mean, everything is done via bindings through HTML code / attributes. How can I access $rootScope , or any of the services other than having them injected to my controllers via 'low level' javascript code?angular global variable doesn't hold much when logged to the console. What else to use to discover possible methods accessable via javascript?
I suspect this will be closed as opinion based but here is my opinion:
Angular does not remove your ability to control the page via javascript. Instead it isolates that code that manipulates the DOM. The learning curve for angular is a little like a roller coaster, in that you feel differently about the framework after learning a new piece. I felt really great after learning how templates and controllers worked but then felt low after seeing the limitations and complexities it created only to feel really great when I learned about Directives and how to manipulate the DOM through them. Six months into it, I am comfortable with Angular and would never go back to all the boilerplate of straight JQuery/javascript.
An important thing to keep in mind. Angular is not a UI library but rather a way of organizing your development files. There are many integration libraries of well known UI frameworks into angular Directives but by far the most popular is Twitter Bootstrap.
This blog post really nailed it: https://coderwall.com/p/3qclqg
I am considering using AngularJS instead of Handlebars with MeteorJS. I am more familiar with AngularJS, but it doesn't work well out-of-the-box with Meteor. Handlebars is default templating engine used in MeteorJS.
I would like to know the trade-off between the two, e.g., whether AngularJS provides more flexible front-end coding than Handlebars.
My question is: when pairing with Meteor, what AngularJS can do that Handlebars can not in terms of front-end programming?
(Note that people love AngularJS in part b/c of its two-way binding and data model, but Meteor-Handlebars do these very well too).
Update: Please do not vote to close this question if you think it is a duplicate of another question in SO that compares Angular and Handlebars. Meteor added significant power to Handlebars due to its "database on client" approach.
Angular and Meteor can be combined, and it's a pretty neat combo. Angular's templating system and its two-way bindings (DOM to JS model) can even be made to go the whole way and be kept in sync with a Meteor collection. Such a pairing of Angular and Meteor means you get instantaneous DOM to database syncing, which is very cool. Angular can't do that by itself, nor can Meteor (without writing more or less tedious event handlers) and even less Handlebars.
The angular-meteor Meteor package is pretty much ngMeteor's successor (it builds on ngMeteor code) and integrates Meteor collections with Angular models, the two templating systems, Meteor Session variables etc.
TL;DR: Meteor works best with packages (think jQuery, bootstrap, d3, underscore, stylus, less) since they enhance a framework. Those same packages would enhance Angular too (well, kind of). Angular is an end-to-end framework, so trying to integrate it on top of another end-to-end framework like Meteor is a recipe for headaches.
Handlebars has very similar expressions and bindings that you're probably familiar with in Angular. But while the templating engine is similar, it's the rest of the frameworks that differ greatly.
Angular leans heavily on its internal directives (ng-repeat, ng-form, ng-bind, etc.) to easily tie in javascript (i.e. power) to your markup. There's a lot of magic behind the scenes.
Meteor leans heavily on the pub/sub model and connecting to your true data stores. Their secret sauce comes from easily adding but abstracting packages (handlebars is one of their default packages, but some others are bootstrap, accounts-ui, d3, etc.).
Meteor follows very different ideologies and has different opinions on framework design than Angular does. In my opinion, Meteor's are superior though the project is still in its relative infancy. You'll find that Meteor is really, really good at prototyping quickly, especially if you need to tie in user support and want to use Twitter/Facebook/Google.
You'd be better off choosing one or the other, but if you're not strong on the server side, you could write a pretty slick Meteor app to just act as your API server.
If you want to use angularjs with meteor you can just install a package that does that. Then you can use both meteor and angular.
Meteor is realy nice for getting your data from server to client, angular is very nice in getting that data displayed (and stable).
mrt add angular-stack
or
mrt add ngMeteor
Generally speaking, AngularJS has passed the version 1.0 milestone and is considered ready for production use while meteor is still alpha software. Consequently, Angular is more polished, has directives, modules and rich third-party libraries like AngularUI.
But if you feel like experimenting with a bleeding-edge framework, don't think you'll have to do super-fancy templating-stuff but need a database built in, go with Meteor!
I think you might find this answer helpful.
Also I think it might be a duplicated question.