Develop Reference

What is the impact if we use the jquery plugins in angular 7?

I'm new to angular. Some forums and tutorials show how to integrate jquery plugins in angular. Actually there are plenty of jquery plugins. I used a lot of jquery plugin in my previous projects which were implemented only in jquery. So I would like to get that feel (colors,UI, animation...) into my angular 7 project. But in the middle, I'm worrying that some forums say "Don't mix jquery plugins with angular"
So may I import jquery plugins inside angular? Will it be a problem? For Eg : Datatable has a lot of function where I need most. Jquery Confirm Master gives a better UI. And there are a lot of API calls also. If I need to use these kind of jquery plugins, what can I do?

There are some core reasons you shouldn't access the DOM directly in Angular (as you do with Jquery). I answered a similar question here
Angular is a fully blown framework where you shouldn't differ from the 'Angular way'. There are several reasons for this. For one your code will become very complicated in the way it works. Some things you do in Jquery is very hideous compared to how simple you can implement the same thing with Angular. Another reason is that Angular applications are not always meant to be ran in a browser. For example you can run Angular in a web worker, which doesn't have direct access to the DOM. Your components will become dependent on Jquery when there is no need to, which might hurt you if you want to reuse those components in other Angular applications.
Your value point for sticking to Jquery is that you can reuse that code. To that I will say that you should rewrite those components for your Angular application so you can later reuse those components in other Angular applications. Modernize / rewrite your components now, so you have optimized clean Angular components. You will quickly find that your Jquery code is overly complicated compared to how you do similar things in the Angular framework.

Are all Flux for Angular Libraries Experimental?

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 :)

Is Google's Polymer a fully functioning Frontend Framework to Subsitute OR Complement other Frontend Frameworks?

The question is in regard to AngularJS, BackboneJS, EmberJS and the other frameworks.
I have to translate a project from php to javascript and I have to decide, if I am going to use:
AngularJS
Polymer
A combination of them
I prefer using Polymer, because I like it.
Yet, I am missing (and correct me where I am wrong) the ability to make:
Views and link between them (like in Angualar)
Controllers
I know that the structure is up to me, on how to build my application, but it seems that angularjs has a well predefined structure for building mvc-applications.
Therefore I want to know: Is Polymer a substitute for Angular, if you want to build a well structured web application or is Polymer complementary library to be used along other existing frameworks?
EDIT 21.09.2014
No one really answered the question to my fullest satisfaction, therefore I marked it as not answered yet. Many say it just "DEPENDS". But no one is able to elaborate, on what exactly it depends.
On the complexity of the application? On the needs of the application? For what needs does Polymer fit and for which doesn't it fit? These are the answers I was looking for.
Some say it can be used as a frontend framework. Others say that is just a library and others say "Yes and No". Unfortunately rather confusing answers.
I wish there was an official answer to this, but I let you in on what my feeling is. I believe it is a substitute, but Polymer hasn't yet reached the structure, that other frameworks require to work. Maybe this is intentional, maybe it is just a matter of unreached maturity, because the framework is new.
I hope that the creators will explain, when it is best to use AngularJS and when should someone use Polymer for building large scalable web applications.
EDIT 15.08.2015
Polymer 1.0 is out. And it turns out Polymer is officially NOT a framework and is supposed to work in a complentary way with other frontend frameworks.
https://youtu.be/fD2As5RmM8Q?t=6m42s

IMHO both are two different things and they both are to serve two different purposes. Though they have some common features to offer, data-binding can be one of them.
Polymer
If you truly want to use the Awesome Webcomponents, Polymer is one way to achieve that. There are other options like you can go with your vanilla JS, or use other libraries like X-Tag from Mozilla or Bosonic. These libraries polyfill the webcomponent features which are still in drafted state. So, these libs help us have/provide the same user experience across browsers even where there is no native support for the webcomponents.
Angular
This is a full fledged MVC framework. And people here know what Angular as an MVC framework includes/provides.
That all said to answer your question
Google's Polymer is not exactly a fully functioning Frontend Framework and can be used as a Subsitute OR Complement to other Frontend Frameworks. It can be used as a substitution for the V part in Angular as MVC. Like people use React as V in different frameworks. It is not much a different case for me. Being more specific in case of Angular, Polymer is like directives in Angular 1.x while like components in upcoming Angular 2.x.
References
To be more sure of what I am talking about and for additional sources on how to use the Polymer with Angular2 (Angular2 not released to this date)
you can check this video at "https://youtu.be/7WgEuNZCCHk?t=32m15s" starting from time 32:15 where Rob explains how to use the generic webcomponents/polymer as the components/View in the Angular2.
you can check this project "https://github.com/rkirov/youtube-app" which uses Angular2 and google-youtube web component.
https://github.com/ebidel/polymer-experiments/tree/master/polymer-and-angular/together
From the polymer-starter-kit
Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!
So, in my view these two projects are not competing each other.
Webcomponent Specs
The webcomponent specs are here for one's reference
Custom Elements - http://w3c.github.io/webcomponents/spec/custom/
HTML Imports - http://w3c.github.io/webcomponents/spec/imports/
Shadow DOM - http://w3c.github.io/webcomponents/spec/shadow/
I just wish the webcomponents are native to the evergreen browsers ASAP.

From the Polymer Starter Kit:
"Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!"
Update:
What was described as Carbon Elements seems to fall under:
Polymer(version 2) App Toolbox
Component-based architecture using Polymer and web components.
Responsive design using the app layout components.
Modular routing using the elements.
Localization with <app-localize-behavior>.
Turnkey support for local storage with app storage elements.
Offline caching as a progressive enhancement, using service workers.
Build tooling to support serving your app multiple ways: unbundled for delivery over HTTP/2 with server push, and bundled for delivery over HTTP/1.
Carbon Elements adding framework features
During The Polymer Summit 2015 Keynote, Google announced a new "Polymer idiomatic and framework oriented" set of elements, tentatively named the Carbon elements.
Some quotes from the longer tjsavage answer regarding Angular 2 vs Polymer Carbon:
"The trick is in thinking about the web platform as an application framework... Polymer the library is to the web components component model as the carbon elements will be to using the web platform itself as an application framework: the opinionated rails to make it easier to understand and achieve."
"Angular 2 will provide one way of structuring your application that uses Angular's view of what makes a good application structure. The carbon elements will provide a different way of structuring your application that more directly uses what the web platform itself provides as its structural underpinning."

Polymer is almost fully functional.
Currently it is missing routing for example but this doesn't mean you can't do this with Polymer.
There is now https://elements.polymer-project.org/elements/app-route
In Dart also dependency injection works fine with Polymer because of the types. If it's possible in Dart, it's possible in JS as well because Dart transpiles to JS. DI in plain JS might be more cumbersome though.
In this package (Dart)
https://github.com/bwu-dart/bwu_polymer_routing
I made the routing and DI packages used by Angular.dart available for Polymer. There are also routing packages for Polymer.js available.

I put together some router demos. The "missing parts" really depend on what type of application you're building.
https://github.com/erikringsmuth/polymer-router-demos

I've used it as both, as an enhancement to an app written in another framework, and as the full framework itself, where it was responsible for every element on the page.
I really like just about everything about Polymer, so I've been very happy using it for the whole app, even built my own router. If you've got an existing app I'd recommend dipping your toe in the water, as Polymer works great composed into other apps to see if it's to your liking.

Let me give this another try:
The key behind web-components (and thus Polymer) is, that they are self-contained. You have a web-component somewhere, you import it, and (if you're lucky) it just works, wherever it comes from. The web-component will NOT interfere other components. So doing things like MVC is not Polymers business (although it provides a data-binding mechanism), as this belongs to the process of tying things together. It is considered to be best practice that these kind of things are solved by creating new elements too, that create and react to events. When it comes to the model you code non-visual web-components, that don't have/need a template. TodoMVC has an (outdated) example for that (https://github.com/tastejs/todomvc/tree/gh-pages/examples/polymer).
So Angular gives you a path to follow on how to do MVVM, whereas it is up to you on how to do the "logic" in your app when using Polymer. IMHO Angular is for more complex and rather enclosed apps, whereas Polymer is for any kind of app, that embraces the web. You even can use Polymer, if you're not writing an app at all ;)

Creating a loosely-coupled & multi-page JS application using Core(Mediator) / Sandbox(Facade) / Module pattern -- advice?

I'm building a multi-page javascript application. I've read a lot into design patterns, and creating applications using a Core/Facade/Module approach w/ loose coupling (pub/sub scribing to events).
I have a pretty good system worked out that minifies & combines all of my module files & related dependencies into a single external javascript file at deployment. Minimizing extra HTTP requests for my application is a design goal -- therefore I'm not too interested in AMD (asynchronous module definition).
I'm using the guidelines delinitated in Nicholas Zakas's presentation,
Scalable JavaScript Application Architecture
http://www.youtube.com/watch?v=vXjVFPosQHw
&&
Addy Osmani's Patterns For Large-Scale JavaScript Application Architecture
http://addyosmani.com/largescalejavascript/
&&
This premium tutorial, by Andrew Burgess from Nettuts, Writing Modular JavaScript
http://marketplace.tutsplus.com/item/writing-modular-javascript/128103/?ref=addyosmani&ref=addyosmani&clickthrough_id=90060087&redirect_back=true
My question is advice on how to go about managing different pages of this application & their associated modules. I'm also using Backbonejs's Router class w/ ballupton's History.js library to manipulate the HTML5 history/state API and dynamically load pages without a refresh while maintaining backwards compatibility for older browsers that don't support the HTML state API. All of my pages share a common code base (single minified & compressed js file).
Here's an outline of the structure I'm thinking of using in my application:
It's essentially a hybrid approach. The top half consists of a Core/Facade/Module pattern with discrete modules that don't interact directly with each other and publish/subscribe to notifications via the facade.
The bottom half consists of my proposed application structure, which notifies a "main controller" when the state/url changes, the main-controller performs any global operations (such as initializing the header & sidebar-menu of my UI if not already initialized) and the instructs the relevant sub-control to run it's init() method (as well as calling destroy(); on any controller that was previously loaded). Each sub-controller (correlates to ex: home-page, calendar-page, reservations-page, etc.) cherry-picks modules from the pool of available modules and initializes them.
Is this a good approach or am I on a bad track? I can see the modules are still independent of each other which is good for scalability.
I've also considered just treating the Router & Controllers as discrete modules and having them publish/subscribe to the Core, and each controller somehow initializes the necessary modules it needs for it's page.

One thing we did to keep history working smoothly was to first change the URL. On change of the URL an event would get triggered, the router would parse the url then figure out what to do. This event would automatically get triggered on page load as well. If you clicked a link it would simply change the URL, which is fairly simple and completely decouples links/buttons from the application logic. This seemed to work well for our application. We used JQM, but we dropped most of their router since we read most of our instructions from some XML file and didn't have a bunch of HTML pages to load into the main viewport area.
I've often seen backbone apps use the router as the core/mediator. This is a good idea. You can simply listen on change events for the URL and then change the page appropriately. This Mediator should probably be a singleton, although singletons are harder to unit test.
The thing I didn't necessarily agree with Backbone on was its definition of "views". The view sort of seems like an action in a controller (well from some perspectives). We added one more level of separation in our application at that point. Our views made ajax requests to template files which were filled in with some JSON and handlebars.js. I'd say your header/sidebar should just be templates. If you need to refresh them then see how you could do extremely simply otherwise you are looking at creating 4 new modules: collection for a list, model for each item, collection view, and model view. I'd couple templates more tightly with some higher level view until they need to be broken down further (eg. some "Application/Main View").
Having this template layer allows you to make superficial changes without recompiling as well, which is nice. Anytime you can put things into "meta" it is a win (well unless it requires you to read XML (ha)). As a bonus you can then cache the template separately as well (or cache bust it separately for that matter).
Your architecture does seem fine though, and is a valid approach to your problem. One tip I'd give is don't over design up front. Iterating is best. You will need to refactor. It is impossible to foresee what would make your application flow more smoothly 3-6 months in advance.
Update on Dec 18th, 2013
Now a days we are using marionette and more addy osmani tricks. On top of the above items we are using AMD's alternate format:
define(function(require) {
var myTemplate = require('hb!mytemplate.handlebars'),
view = require('myview');
...
});
We are also using the marionette application class in combination with wreqr which provides a request/response layer. This allows us to set application wide objects cleanly. It also allows us to define classes without explicitly stating the class name. This is a pretty good way to sandbox. EG:
this.app.setHandler('CanvasClass', function() {
return RaphaelCanvasView;
});
// elsewhere
this.app.request('CanvasClass').text('123', {x:1, y:2});
This all seems to work out pretty well.
You should also checkout aura js and web components. Our directory structure sort of mimics/anticipates those concepts without investing in them yet.

I think it's a good approach.
I've been developing something similar in 2 huge commercial web-apps (minus backbone, and with a custom history manager) and it works great. I'm also not using AMD and all interactions are handled by pub/sub.
One of my best inspirations (which I'm sure you already know) is: https://github.com/aurajs/aura

Backbone.js Large mutli page app, manage page transitions cleanly destruction, creation etc

I'm currently building a huge backbone app (facebook clone).
Over the last couple of days, feeling pretty happy with how everything works in BB thanks to Rob Conery's excelent tutorial (essential viewing if your starting out with MVC 3 and BB http://tekpub.com/productions/mvc3)
Now I've come to the stage where I need to switch pages in my app, and I am starting to wire this up, but it feels like I'm doing a lot of this myself. This is fine, and I know I will be able to do what I want it to.
I've delt with the memory leaking issues, by making sure I unbind and remove my models/collections/views when switching page, Switching views in backbone for navigating between pages - whats the right way?
But aside from this stuff, there is a whole load of tasks that I want to do when I switch between pages. Essentially removing and adding parts of the page. This is slightly more complicated becuase rather than just removing everything, I'd like to only remove/destory the bits of the page that need to change, based on the transition I'd like to make.
As said, I'm getting it working myself at the moment, but I wondered if there was a pattern to handle this tear up / tear down process, and keep things clean (and not end up with a massively bloated router (controller bloat!!!)

Marionette is definitely the way to go. Specifically, Marionette.Layout is fantastic for swapping out specific regions without re-rendering the entire page. Check out some of Derick's Example Apps to get acquainted with the framework.
I'd recommend staying away from the Router until after you've gotten your app working using plain old events. Then add the Router support after. Basically the Router should be wired up to reflect the state of your app, but you should not depend on it to be your controller.
As an aside, I'm using RequrieJS on a large multi-module Backbone project and it's been a godsend. It's controversial in the BB community, but it's worth looking into if you'll have lots of inter-dependent components and you want to let another framework handle all the dependencies.

I had your same problem and wanted to share how I solved it, so I re-designed the ToDo App example from the Backbone.js docs using my page transition convention:
http://ahamlett.com/Backbone.localStorage/
I haven't tested it for memory leaks, but if there are some just call .unbind() before .remove() in the SetView method of the app's router.