This is an opened question,
In order to make the best choice for my project, I need to know what is the best MVC javascript framework to couple with jsPlumb 1.5.5 (jQuery) to do the easiest and the most robust implementation in order to handle all business logic and a clean code division.
My choice will be made regarding these well-known frameworks :
1) AngularJS
This Stack post refers to a way to separate jsPlumb graphic code with AngularJS controller code (using a custom AngularJS service to handle jsPlumb logic) :
Using AngularJS and jsPlumb (use jsPlumb functions in AngularJS controller)
And there is a simple implementation example here :
https://github.com/mrquincle/jsplumb-example
2) Ember.js
I found this Stack post, referring to an issue (solved) :
Using jsPlumb in an Ember.js Application
3) Backbone.js
I only find one sample very very ligthweight..
I got some informations about these 3 frameworks thanks to this helpful link :
https://sporto.github.io/blog/2013/04/12/comparison-angular-backbone-can-ember/
I need to know what should be the best approach to make an heavy and clean front-end full-js application to achieve this kind of product :
http://equationmap.com/322/#.U1d8gfl_v-1
From my point of view, AngularJS is the best choice today, but I want to understand if it's possible with this framework, to add some new HTML elements on the fly (jsPlumb elements creation) and to bind them an AngularJS business logic ?
For your requirement, I would suggest you to try emberJS rather angularJS. Because(Source):
"Angular’s focus on simplicity has some serious consequences. There
are workarounds for some of these issues that you can implement
yourself in your project with great discipline, but ask yourself this:
are all developers on your team going to follow the same conventions?
Additionally, if you add all sorts of extra constructs to AngularJS to
make it work like Ember, why not just use Ember in the first place?"
Also take a look at: http://ryantablada.com/post/why-i-chose-ember-js
It depends on your preference, familiarity with the framework and most importantly project requirements.
I started using Angular but ended up with Backbone.
IMHO Angular is ok, but the learning curve is very steep, sometimes very difficult to get the desired behavior, where as Backbone, I was able to come up with a TODO in 2 days and took more than 5 days to design a todo in Angular.
The only problem with Angular is it tries to introduce it's own constructs, where as Backbone is like plain javascript gives one all the flexibility. I haven't tried Ember but might surely work upon in near future.
Related
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.
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'm building a web-based drawing program. Since it's a lot of DOM manipulation, I decided to skip AngularJS and instead go for JQuery. I'm using RequireJS to structure it somewhat.
Now, the core drawing functionality and I want to continue building the UI around it: login/signup functionality, project file browsing, UI components for palettes, toolbars, etc.
What would you recommend for frameworks for this? BackboneJS? Marionette? Or use AngularJS for everything else that's not DOM manipulation?
There is no right answer here, you'll probably get different advice from every person you ask. Having built several complex apps using both RequireJS/BackboneJS, and RequireJS/AngularJS, here's my 2 cents:
AngularJS - There's no reason not to use angular because you're doing DOM manipulation, that's what directives are for. You can write directives using jQuery/D3/etc, which are then encapsulated and reusable throughout your application. Angular is very opinionated and 'automagical', so be prepared to spend a lot of time debugging until you understand what's going on under the hood.
BackboneJS - Really lightweight, it's more of a 'toolkit' that enables you to write your own framework because it's lacking some of the glue to connect everything. If that's not your cup of tea, try out one of the opinionated libraries built on / inspired by Backbone.
I successfully used JSViews on my project together with RequireJS and jQuery.
They play well together, and I personnally love the minimalist approach of JSRender/JSViews: take what you want, and go as far as you need.
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.
The JavaScript codebase we are using on our website is pretty well structured (outlined here if anyone's interested).
I have been looking at integrating backbone.js (or knockout.js, for some of the features) into our code -- but after closer considerations I don't think I care that much about data binding (my appliation does not do intensive client<->server data exchange, its more biased towards server->client->js data pipe), so I don't really care if I don't have dynamic data binding and syncing.
As I am not closely familiar with those libraries, I am afraid that by opting-out of using those libraries, I am missing some other vitally helpful features. Am I?
Personally I'd use backbone if I was building a full blown single-page web-app. If your website is primarily HTML, but uses JS for some minor added functionality I'd not worry about it. Backbone is good at handling client-side data models and tying changes to those to view updates.
Personally, I've used knockout and found it's reliance on data-binding in the HTML confusing. It wasn't something that worked well for me. It might be a little bit more friendly to building websites that are partially dynamic, because a lot of the logic goes right into the html view layer. You may want to listen to this recent podcast interview the creator of knockout as it may shed some light on things. http://javascriptjabber.com/
In my case, when building a big website with some dynamic elements I've stuck with the pattern of some global jQuery plugins and page specific JS. It works well enough for simple additions to specific pages.
I don't know if this question is super specific, so here's a generic answer :)
I'd first like to point out that while declarative databinding is the key feature for KnockoutJS, it is not a part of the core-backbone framework. There do exist multiple plugins like (Rivets.js and Orchestrator) which provide such functionality in Backbone JS.
Now coming to the primary aspect of your question - In terms of advantages other than Data-binding KnockoutJS does not have much to offer. However even if interactive data binding is not a primary concern you should definitely consider using BackboneJS. The reason for that is Backbone comes bundled with a client side routing system and a succinct but minimal approach towards managing Data obtained from the server in javascript.
As you have mentioned that your application is data-driven, probably the data that you have fetched in the client is not fetched all at once but is incrementally updated. In that scenario, having observable Models and collections might help you to manage your in-app data-dependencies well (as well as keep any widges for visualizing the data in sync.)