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
Related
I know that this topic was discussed many times but I'm still not quite sure if I'm doing things right..
Many on-line resources embrace directives as a building blocks of the angular applications, in the same time many resources emphasize re-usability of the components. Anyway from my experience when I build typical app, there is not much things to re-use, usually each component has single role and it is used in the single place. As I understand angular, one of the main concepts is to provide semantic DOM, and in order to achieve that we can use directives. So when I build an angular app usually I create a set of directives and combine them in the views.
In my apps in the most cases all the DOM manipulation can be done using the build in directives. Most of my directives has a template and a controller, I do not need to use link function. In most of the resources in the internet I can read that I should use link function when creating directives. But this seems to be far more complicated code... . What is the benefit of the link function if I don't need any fancy DOM manipulations that are beyond build-in directives ?
tldr; I build my apps using directives with controllers and put them into views, is this a right approach ?
I've been developing in Angular over a year now on an enterprise level application and my team has gone by a standard of creating directives if you are using that same element more than once. It saves time, saves the DOM trouble, and makes it easy to create separate, testable pieces of code.
We've created directives for many listing items that use ng-repeat. Pretty much every ng-repeat we have is iterating over a directive to create true isolate scope in our elements' functionality. It's one of the most powerful features in AngularJS when done right and conforms to the standards of Object Oriented Programming where you can really make your applications use abstraction to the finest degree. Here's a wiki link on abstraction.
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
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!
We're about to start a project using mentioned libraries. We have already used jQM in another project, but coupled with Backbone. Now we're thinking about using AngularJS with jQM. Do you think it's a good idea? And if not, why?
To elaborate, the question is whether it is advisable/recommended/easy/beneficial to use these libraries together, or maybe there is something that should prevent us from using them both in one project. We don't want to spend half of project's time on making them work together just on principle.
AngularJS and JQM do different things. AngularJS is MVC + Lot More. JQM on the other hand is for direct UI manipulation (lower level than Angular). The good news is AngularJS is flexible and will let you work with any other Javascript framework including JQM. The recommended way of using them together is use the adapter as mentioned above or create your own reusable directives that will add "JQM nature" to your views. For e.g. you can create a directive that will convert a standard UL to a fancier JQM list. The good thing about doing this in directives and not within your view is that your UI code is separated in separate modules and not intermingled with business logic.
I'm really enjoying learning to use AngularJS. Now I'm looking for components I can use with it. I've been looking at Angular-UI components but I'd like to know if it's possible to use the nice, supercharged components in ExtJS. Does anyone have experience with this? Any hints or tips or Angular directive libraries?
The company I work for is making a similar move. We currently rely heavily on an older version (3.x) of ExtJS, and the effort to upgrade to the current (5.0) version is at least equal to the effort required to move to angular.
To answer the question (to the best of my limited knowledge):
They can exist together in the same JS application.
Can you use UI elements of ExtJs with Angular?
You can put angular in control of markup via HTML templates in Ext.
Is this a wise idea?
Probably not.
Why would I consider doing this?
I need absolute control over the markup and don't care about possible page load issues
I need to serialize or de-serialize in some special way that Ext doesn't innately provide
I need to do something special like pub/sub (still totally possible with Ext)
In our case, it is a proof of concept for a few modals. If I am biased, I am biased in the direction of ExtJs (which is a huge statement given my background). The more exposure I have to ExtJS, the more I personally like it. I've used several frameworks in the past like Ember, Backbone, KnockoutJs and AngularJs and they are excellent tools that are reaching a level of maturity that makes them excellent choices. That said, they don't follow the same development model/pattern that ExtJs does, and I don't think a direct compare is fair to either side.
It would be almost like comparing Ext to Node (silly, I know).
If your project requires some special functionality that you don't believe is possible in Ext, you are probably like me and have limited experience with it. If you have a lot of experience with Ext, and want to try what we are trying, I say go for it. The single downfall of Ext is the size of the built package that is delivered. Another small framework isn't going to help that, but it also isn't going to cause more pain.
In the end, for me, I just love JS and expanding my knowledge of how things work now and in the future.
For the post above asking about the lack of traction for Ext: the answer is simple... it's not free, and thus not an option for many of us who aren't writing commercial software that fits well with the license.
In our AngularJS app at work, we have integrated a 3rd party ExtJS app with it, not for its UI components though. We open certain popups of that app based on user input and when the user commits data in the popup, we respond to ExtJs events to refresh our app. AngularJS is flexible enough to integrate with any other Javascript code/libraries as long as the library has public events to respond to. I would recommend going through the Directive and scope documentation on how to effectively create directives and respond to scope events.
Personally I do not feel ExtJS and AngularJS would be needed together, unless you are forced to use it like me. There is http://angular-ui.github.io/ that brings in a lot to the table. Again any given JQuery plugin can be integrated using directives, filters etc in AngularJS. So you may want to investigate into that before trying to bother with ExtJS.
Why do you need AngularJS anyway if you have ExtJS? I agree learning Ext can be somewhat difficult though once you've bitten through it there is nothing better at the moment. The only disadvantage is the heavier footprint but who cares? It's not like it's causing any problems... We use nothing but ExtJS at work and the progress in our apps is amazing. It integrates seamlessly with Spring MVC. We don't need to hack in HTML directly which I consider more of an advantage than a disadvantage: no more writing tags, no more open/close tag issues, you can still use css and Ext handles any browser incompatibilities so what else do you need more?? Angular is just the new kid on the block but in total it can not (yet) compete with ExtJS. It doesn't even com close. Just my 2$.
Sencha is planning to add support in the framework. Please find the link at the bottom for reference:
At SenchaCon in Las Vegas on November 7-9 2016, Sencha will be introducing the ability to use Ext JS components, layouts, and themes within an Angular 2 application, which we are currently calling the Ext JS Bridge to Angular 2 (also known as ‘The Bridge’).
https://www.sencha.com/blog/first-look-ext-js-bridge-to-angular-2/