I have to build a simple app, and I'm not sure if it worth to use the jQuery framework. Besides the complex or fancy applications, When is it recommended to use the jQuery and not the pure javascript.
In addition to complex or fancy applications you could use jquery in applications performing cross browser DOM manipulations and AJAX and which could benefit from the hundreds of available plugins.
using jquery will increase the development speed and you get the benefit of browser compatible code too.
It's more or less an issue of personal preference: jQuery, MooTools, Prototype and other JavaScript frameworks bridge many browser incompatibilities and simplify many of the common tasks for which JS is used, and thus shorten development time.
IMHO, if you are using JS for the usual "effects, AJAX, input widgets, pre-submit validation" tasks, a framework like jQuery is much faster and easier to use than rolling your own implementation. The drawback of loading one more script file and minding its license is negligible when compared to the flexibility and efficiency that it brings.
(also, most frameworks have plugins for various advanced tasks, but that's a bit beyond the scope of the question)
Besides all the facilities for writing code, I think that you should think at what you will put inside your application (i.e. plug-ins): jQuery offers a lot of useful plug-ins, both internal (calendar, tabs...) and external (e.g. jqGrid for displaying grid data). It is very helpful to have all this things in one single and standard framework (e.g. jQuery): otherwise you'll have to look each time to a different javascript plugin.
Related
I was wondering what the difference is between ColdFusion's built-in AJAX functionality and using a JS framework like JQuery?
It seems that ColdFusion ships with tags that can do fancy Javascript layouts and controls e.g.<cflayout> and <cfwindow>. If it can already do this then why would one want to look at JQuery?
I'm asking this question because I have been given the task of making an internal CRM application which should have a 'rich' UI. I started investigating JQuery and ExtJS which do the fancy client-side UI work. However I also noticed that CF has similar abilities. Because I am starting from ground zero I was wondering whether to spend (a lot of) time learning JQuery or ExtJS, or cut down on my development time and just use CF's built in AJAX tools.
With some good design skills, would it not be possible to create a 'rich' application with CF's built-in AJAX controls and some fancy CSS styles?
Any advice would be greatly appreciated.
Some things to consider:
Yes, you could use CF's built-in Ajax/UI stuff to build a nice application. The downside is that doing anything outside the box of what CF has baked in is a big headache., Plus, the version of Ext JS which CF has is quite old...so getting all the goodness from the latest version (v.4.2+) is not an option, since CF doesn't have a mechanism for upgrading that library seamlessly (or freely).
As others have mentioned, you should definitely use a non-CF alternative--they are all dead-simple to integrate with CF-backend anyway, so the amount of effort required to do that vs. wrestling with tweaking the internal CF stuff is actually lesser.
Which library to use? Well, you need to seriously consider your options before jumping into one or the other. jQuery (and jQuery UI) and Bootstrap are nice for design...unlike Ext JS, however, they don't come baked in with uber-rich "data-aware" components (grids, trees, etc). They are more libraries than they are frameworks (like Ext JS). On the other hand, Ext JS, for your purposes, will not be free. Unless you plan on open-sourcing your "internal" CRM codebase, you'll likely have to commercially license the software, which is on a per-developer seat basis. I think it's well worth the cost, considering what you get, but that will have to be part of your organization's calculation if you decide to go that route.
Personally, I don't recommend using CF's Ajax functionality. I've build internal tools using ColdFusion's built in javascript and they run very slow to say the least. Your best bet is to go with JQuery and Bootstrap. This could be a bit more difficult at first, but it would open a lot of doors down the road.
Good luck! Al
How does GWT compare (or can it be compared) to Javascript frameworks such as backbone.js, angularJS, Ember, JQuery, etc.? Do they aim to accomplish the same job, making them competitors, or can they be used together?
Yes and no. While GWT's compiler is essentially a Java-to-Javascript converter, the benefits it offers far outweigh anything I've seen from any popular JS libraries.
Since GWT-based apps are written in Java, they gain many of the benefits thereof, such as being strongly typed and extremely easy to refactor. If something changes that affects another class, you know it immediately. And for those things that Java isn't great at, you can always use Javascript to handle the case with JSNI. Google has also provided a great plugin for Eclipse which allows you to debug your code like nothing I've ever seen of a JS library. Another benefit of this is that you write your client- and server-side code in the same language, and GWT does the heavy lifting of tying them together.
There are also the benefits of the automatic generation of multiple permutations. GWT kicks out a copy of your code that looks and behaves identically (inasmuch as is possible) on the most commonly used browsers. Your clients all see the same thing without you carrying the extra weight. You aren't responsible for writing endless lines of code to deal with those countless browser idiosyncrasies that have plagued web developers forever. While to some extent these things are handled by some JS libraries, GWT makes it completely effortless.
In my experience, the libraries you mentioned are all great in their own right, but simply can't provide the powerful debugging, portability, extensibility, maintainability and portability that GWT does right out of the box. GWT isn't really built to work with other libraries, and instead gives you the capacity to do (mostly) everything those libraries can without their help. (Of course that isn't to say that you can't use other libraries wherever you want...you can if you really feel the need to do so.)
So in my opinion, no, there is no competition. GWT is the figurative heavyweight champion in this arena.
I am an avid user of the YUI framework (http://developer.yahoo.com/yui/). It has its' strengths and weaknesses both performance wise and syntax wise. I have seen a bit of JQuery and I have worked a little with prototype as well but I have stuck mainly to YUI. My question is, is it better to stick with one Javascript library per application, or leverage the abilities of multiple javascript frameworks in your application?
I think it is better to use one framework for at least two reasons:
1. Code is easy to maintain because there is no syntax mix.
2. Application loads a little faster and I think should execute little faster.
My guess is that multiple frameworks is better as long as each has its purpose. If I'm building an ASP.Net web application with AJAX functionality, there may be some built-in ASP.Net AJAX Javascript libraries being used automatically that can be combined with JQuery to handle some situations. Alternatively, one could have third-party controls like Telerik's RAD controls that also bring in more Javascript code possibly. The key is to understand what each framework is adding in terms of rolling your own.
Sure less frameworks in the same website will make your life easier, so try as you can to use one framework, and if you are going to use more than one, take care from conflicts and redundancy.
If i am in your place, i will start searching the framework i have for some plugins and updates, if didn't find will add the new framework.
One more point: don't panic from using more than one framework, the big and famous frameworks such as jquery has its implementations to solve conflicts and work side by side with other javascript libraries
Also... if you use 2 diffrent frameworks at the same time, some functions in one framework could override an function in the other framework, and make ugly conflicts.. e.g the $() could be implemented in diffrent ways, and make something crash, if other functions of the framework is using it. (and they sure do!)
I think its better to use 1 framework in your development, for consistency of API and loading speed. the problem sometime is no framework is comprehensive enough to have all of our development needs.
This is just came into mailbox, their advertisement saying it's a comprehensive framework, with plenty of widget: grid with grouping, charts, forms, tab, fields and so. I haven't play it long, but it seems very promising. check here
I have one question about Javascript frameworks. I'm using ExtJs on my application, but there are many problems with licensing and such things, so i wonder about this thing.
Is there a way to follow some strategies in developing Javascript so that i could easily switch from one Javascript framework to some other framework?
If you did that, I have a feeling you would have developed your own JavaScript framework. I doubt that's feasible. Better choose one at the beginning and stick with it.
I think it is never really easy to switch entirely from one Framework to another without rewriting most parts of the application. Especially the JavaScript Frameworks are extremely different. I don't really know any realistic alternative to what ExtJS offers (I know they had some licensing issues but I still don't get why commercial application developers are so hesitant to pay the 330 to 1300 $ for what the Framework has to offer. And if you Open Source it you don't have to worry about licensing anyway).
What you should do is to get rid of any JavaScript Framework specific code on the Server side (make the data transfer as generic as possible). This makes it way easier to switch to another Framework on the Client side even though you'll probably have to rewrite most of the codebase there (but only there) (I don't even see an easy way to e.g. just switch from Prototype to jQuery and they are relatively similar to each other). The only JS Framework I know that has a "Library Independent" approach is JavaScriptMVC (you can e.g. switch between native, jQuery or Prototype for underlying functionality, but even they are considering to base it entirely on jQuery for the next relase).
Let me try to blow in some fresh air into the discussion.
The major problem with many Ajax libraries and frameworks is that every and each of them have different (and proprietary as well) API. Moreover different libraries also enable and promote different programming models. This is all indeed reasonable, since there is no API standard that have all features that frameworks have to offer. However many frameworks forget that there is quite a basic API and programming model that lays in the browsers natively - XML (in simple case HTML) for layout, CSS for styling and DOM for scripting. This bundle is not only available from browsers, but also for example in Gecko XUL technology, Flex and Silverlight too.
There is a Javascript GUI Framework that brings that natural programming model back to the hands of developers - Ample SDK. Working with that you can layout your interface in a XML appliance (XHTML, XUL or SVG1.2), style the UI with CSS3-featured rules and still write code against standards-based API DOM (Level 2/3) - all cross-browser.
Having choosen for that approach you can make sure that tomorrow, when browsers have all implemented the basic features (mentioned above) equally good you can reuse lots of application javascript code, since it will then run natively!
Indeed that was part of the story - interacting with the View (although many javascript frameworks and libraries do not draw any line between M, V and C - that is the pain). Coding Javascript application is often way more than just interacting with DOM, and then MVC and PAC code architectures come in place. They have proven their efficiency, they are implementation-agnostic. Pick one implementation (as suggested by Daff - PureMVC, for example) or create your own.
There are times when I want to use mootools for certain things and Prototype & script.aculo.us for others but within the same site. I've even considered adding others, but was concerned about conflicts. Anyone have experience, or am I just trying to make things too complicated for myself?
If you really, really want to do this, then you will be able to without too many problems - the main libraries are designed to behave well inside their own namespaces, with a couple of notable exceptions - from Using JQuery with Other Frameworks:
The jQuery library, and virtually all of its plugins are constrained within the jQuery namespace. As a general rule, "global" objects are stored inside the jQuery namespace as well, so you shouldn't get a clash between jQuery and any other library (like Prototype, MooTools, or YUI).
That said, there is one caveat: By default, jQuery uses "$" as a shortcut for "jQuery", which you can over-ride.
So, yes, you can do it, but you'd likely be creating maintenance headaches further down the line for yourself - subtle differences between framework functions may be obvious to you today, but come back in 6 months and it can be a whole other story! So I would recommend keeping it as simple as you can, and having as few different frameworks (preferrably 1!) as you can in your codebase.
AFAIK, all the popular frameworks are designed to be combined with other frameworks. I don't think combining them is that much of a problem. I would however discourage combining them purely from a case of bandwidth needs. A slow site experience is less forgivable than a more complicated development experience.
A recent question: jQuery & Prototype Conflict
Prototype.js library used to be very offensive and conflicted with many other libraries / code. However, to my knowledge, they recently given up with some really hard-core staff, such as replacing Element object etc.
You are better off sticking with a single framework per application. Otherwise your client will spend too much time/bandwidth downloading the javascripts.
That being said, Prototype and JQuery can work together. Information is on the JQuery web site.
My suggestion is to learn one (or more!) framework(s) very well so that you will be able to replicate the features you need without adding the overhead of multiple frameworks.
remember the more code that you push to the client the slower everything becomes.
From my experience I can say that some javascript libraries rather conflict with the browser, than with each other. What I mean is the following: sometime code written against some library will not well co-exist with the code written against browser DOM.
My Framework Scanner tool is useful for finding JS/CSS conflicts between libraries:
http://mankz.com/code/GlobalCheck.htm