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
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create a custom UI framework in JavaScript for web applications (like Google Docs ui) (do not confuse with web application that deploy using languages like PHP, Python, etc.). However, after reading several books about web development, I understand that the best website is layered as follows:
Structure in HTML
Presentation in CSS
Behaviour in JavaScript
So there are several approaches to creating my own HTML document and control it in JavaScript. However in this approach HTML and CSS will be mixed, like in case of extJS UI. I am confused now, and I need some answers from experienced developers on how to write this kind of framework.
If HTML, CSS, and JavaScript is mixed.
What was advantages?
What was disadvantages?
Is there are other methods?
What was the usual type of creating UI frameworks?
I apologize that this answer is extremely long and at times may seem somewhat off-topic, but please keep in mind that the question was not very specific. If it is improved, or made less general, then I will gladly remove the superfluous parts, but until then, just bear with me. This is somewhat of a compilation of the other answers here, in addition to my own thoughts and research. Hopefully my ramblings will be at least somewhat helpful for answering this question.
General Tips for Frameworks
Frameworks are a ton of work, so don't spend all of that time for nothing. Work Smarter, Not Harder. In general, you should remember these things when creating a framework:
Don't Reinvent the wheel: There are tons of great frameworks out there, and if you create a framework that does the exact same thing as another framework, you've wasted a ton of your time. Of course, understanding what goes on inside another library is a great way to make your own library better. Quoting #ShadowScripter, "knowledge -> innovation." However, don't try to rewrite jQuery by yourself. :)
Solve a Problem: All good frameworks (and programs) start with a problem they are trying to solve, then design an elegant solution to solve this problem. So don't just start writing code to "create a custom UI framework," but rather come up with a specific problem you want to solve, or something you want to make easier. jQuery makes selecting and manipulating the DOM easier. Modernizr helps developers identify the features supported by a browser. Knowing the purpose of your framework will make it more worthwhile, and may even give it a chance of becoming popular.
Fork, don't rewrite: If the problem you aim to solve is already partially solved by another framework, then fork that framework and modify it to fully fit your needs. There's no shame in building of the work of others.
Optimize and Test: This is kind of a no-brainer, but before publishing version 1.0 on your website, test every single part of the function, under every single possible scenario, to make sure it won't crash and burn in production. Also, another no-brainer, minify your code (after testing) for performance benefits.
DRY and KISS: Don't repeat yourself, and keep it simple, stupid. Pretty self-explanatory.
Stick to Stable: (This is mostly my personal opinion) Unless you're trying to create a framework specifically targetted to HTML5 in Chrome 31, using experimental features and unstable code will make your framework slower, uncompatible with older browsers, and harder to develop with.
Open Source: (Another of my opinions) It takes years for huge companies like Google with thousands of dollars invested to create frameworks (e.g. AngularJS) so it is an excellent idea to make your source openly available. Having a community of developers contributing to your project will make development faster, and will make the end product faster, bug-free, and better all around. Of course, if you're going to sell it, that's another story...
For more information about best practices when making libraries, take a look at these links:
Javascript Library Design
Javascript Module Pattern: In Depth
Best Practices in Javascript Library Design
Building a Javascript Library
Types of Frameworks
The first thing you need to think about, as mentioned above, is what functionality you want your framework to provide. Here are is the list of types of frameworks/libraries (thanks to #prong for the link). For a much more comprehensive list, see jster, which has 1478 libraries, put into 8 categories, each with several subcategories.
DOM (manipulation) related
GUI-related (Widget libraries)
Graphical/Visualization (Canvas or SVG related)
Web-application related (MVC, MVVM, or otherwise)
Pure Javascript/AJAX
Template Systems
Unit Testing
Other
As you can see from the link, there are already dozens of libraries and frameworks in each of these categories, so there's not exactly much room for something new. That being said, I don't want to discourage you- who knows, you could create the next bootstrap or jQuery. So, here are some resources about each type of framework.
Note: you can't say that any type is better than the others, they simply are designed for different goals. It's like comparing apples and oranges.
DOM (manipulation) related
These types of libraries are designed to interact with, modify, and control the DOM of a website. Here are just a few of the things they do:
Select Elements in the DOM ($("div#id .class"))
Add/Remove Elements in the DOM ($("div#id .class").remove())
Edit Attributes of Elements in the DOM ($(div#id .class).height("30px"))
Edit CSS of Elements in the DOM ($(div#id .class).css("property","value"))
Add listeners for various events taking place in the DOM ($(div#id .class).click(callback))
The most notable of these, of course, is jQuery, and it has one of the largest user bases of any Javascript library. However, it is by no means perfect, and if your library wants to compete, the best thing to do would be to make it excel in the areas that jQuery fails- speed, fragmentation, and "spaghetti" code. (The last two aren't completely in your control, but there are certainly things that you can do to make it easier for users to use the most update version, and keep their code maintainable)
GUI-related (Widget libraries)
I think that this may be the type of framework you're looking to create. These types of libraries provide widgets (datepickers, accordians, sliders, tabs, etc.), interactions (drag, drop, sort, etc.) and effects (show, hide, animations, etc.). For these, people are looking for quantity- the best frameworks out there have several useful widgets/effects that work well. This is one case where it's "the more, the merrier," of course, if it works properly.
Graphical/Visualization (Canvas or SVG related)
The purpose of these libraries is to control animations on the page, specifically on an HTML5 Canvas. These feature animations and sprites for games, interactive charts, and other animations. Again, successful graphical libraries have many, many sprites/animations. For example kineticjs has over 20 different sprites available. However, make sure that quantity does not compromise performance and overall quality.
Web-application related (MVC, MVVM, or otherwise)
Basically, the idea is to provide a layout for the users to put their code in, typically separating the model (data) from the view(what the user sees), with a small controller to provide an interface between these two. This is known as MVC. While it is by no means the only software pattern to base a framework off of, it has become quite popular recently, as it makes development much easier (that's why Rails is so popular).
Pure Javascript- AJAX
This should really be two categories. The first, AJAX libraries, are often paired with a server side library and/or database (though not always) and are designed to make connections with a server and get data asynchronously. The second, "Pure Javascript" are designed to make Javascript easier to program in, as a language, provide helpful functions and programming constructs.
Template Systems
This might also be the type of framework you're looking to create. The idea is to provide components that developers can use. There's a thin line between Template Frameworks and Widget Frameworks (which twitter bootstrap, one of the most popular template frameworks, crosses a lot). While widget frameworks just give a bunch of little elements that can be put in a site, template frameworks give structure to a website (e.g. responsive columns), in addition to making it look good.
Unit Testing
This type of framework is designed to let developers test, or systematically ensure the correctness, of their code. Pretty boring, but also really useful.
Other
This type of framework is for really specific purposes that don't really fit into any of these other categories. For example, MathQuill is designed for rendering math interactively in web pages. It doesn't really fit into any other category. However, these types of frameworks aren't bad or useless, they're just unique. A perfect example is Modernizr, a library for detecting a browser's support for features. While it doesn't really have any direct competitors, can't be put into any of the other categories, and does a very small task, it works very well, and is very popular as a result.
More Types
There are a bunch of other types of libraries. Below are the categories (I'm not listing subcategories because that would take half an hour to copy down) that JSter puts their 1478 libraries into:
Essentials
UI
Multimedia
Graphics
Data
Development
Utilities
Applications
It depends on what you really want. The first distinction that needs to be made is between a Javascript UI framework (which provides structure to the app), an HTML UI Framework (Presentation) and Widget Libs.
Javascript Frameworks such as backbone, angular, ember, and knockout provide MVC-like structure to the app.
UI frameworks such as YUI, bootstrap, and Foundation provide a consistent HTML and CSS base.
Widget Libraries such as jQuery UI, Fuel UX, and Kendo UI provide ready made widgets.
There are also fully-fledged frameworks which provide things across the board, such as Google Closure tools, Dojo with Dijit.
This Wikipedia list pretty much sums it up, and here is the comparison.
In order to find the best way to create a framework, first ask this question: Can any of the above frameworks/libraries solve all or some of the problems/requirements I have?
If something solves all the problems, you can use it right away.
If something solves your problem partially, you can start by extending/forking that project/framework.
Follow DRY and KISS rules. Only solve a problem which nobody has solved as of now.
Fortunately, there is already a good solution: Google Closure Library. This is what Google uses. It shows the approach of mixing HTML, CSS and JS. I wouldn't say it's perfect, but I believe it's one of the best ones at this moment. Its architectural principles rely on proven component based and OOP concepts, and it's accompanied with a static compiler for Javascript. It's definitely worth of studying before baking your own solution.
I'd like to say that cloudcoder2000's answer sums it up nicely. I'm just writing this answer because it didn't seem right in the comment section :P
If you are thinking of making another framework, my suggesting is to stop thinking.
First find the thing in current implementations which troubles you the most, and try to find how you can improve it. Contribute to existing projects, nearly all of them are open source anyways. Also, you don't really need to be a JS-ninja to get into their midst. Take a fork, and get started. Once you're done, and feel that you're code is good enough, make it known to the original repo's maintainers that you have done improvements, and are looking for it to be merged into the project.
Keep in mind here that I'm not discouraging you from solving the problem at all.
I'm just pointing out that there are so MANY frameworks out there, wouldn't it be better if you went ahead and contributed to one of them instead of going for complete glory and implementing a full framework yourself? Making a framework is hard, but getting people interested in your framework is HARD. Really Really HARD, even for Google! Only once Angular got a very good documentation (which itself took quite some time, and resources, of Angular evangelists), that it has gathered so much steam. So, I'm just saying that instead of creating your own monument, perhaps lending a hand to others would be a more worthwhile exercise.
Most importantly though, is the fact that since you are just starting out, I presume you wouldn't have much experience designing frameworks, or thinking in those design terms even. It would of immense value if you contribute to existing projects. Then you will be gathering knowledge and experience of how things are built. Then, you'll be more confident. Then, you can go ahead and make your own framework! Then you'll be more equipped to tackle mammoth projects such as designing a framework. And Then, my friend, will you make something which would be worth the time of countless developers.
Short answer
Build a skinny DOM and only focus on JS code to make it more efficient.
Long answer
A good architect always replies with "it depends." You can't have one single framework that enjoys all others' benefits and suffers from no disadvantages, all at once. There's always a trade-off.
In order to create a framework that is really lightweight, you would probably want the lightest DOM (HTML) structure. However, having a skinny DOM might have the cost of more JS code. So you would probably try to write the most efficient code. You can start here.
Needless to say, you should be keeping the open-close principle, and have the stylesheets separated from HTML, using only classes and never inline styling. I would suggest using less. It makes the implementation faster, and the result is pure css so you suffer from no performance issues around it.
I must respectfully disagree with cloudcoder2000,
From a young age I have been being told don't re-invent the wheel, but why?
During the last 3.5 years, I have re-invented almost all of my web controls using javascript/html/css. From the extremely complex; for example a grid, rich text editor, tree view, dialog. To the very simple, like a progress bar, dropdown. What I gained is a better understanding of html/js/css.
No pain, no gain. I'm so happy with what I was doing these years as I learned more than others.
Some of the controls I re-invented, I think, are much better than the popular ones, like telerik, jquery mobile, extJS. For example, my tree view is fully customizable, with it one can build very complex trees.
So, I encourage you re-invent the wheels, and you will definitely get more than you expected. But also, from the beginning, you need to learn the source code of the popular controls, and re-invent them. You will be very happy when you find yourself be able to make the controls better.
Then the tips on creating HTML controls:
1. use jquery;
2. write jquery plugins(jQuery.prototype...) for simple controls, while define classes for complex controls;
3. separate css from html and js files. Define the html template in js, don't use html files, which make using the controls hard.
Regards,
Leo
For best performance in your UI design, you need to use a lightweight JavaScript framework like angular or backbone, Twitter Bootstrap for the UI, AJAX for base script load and use gzip compression in your app to make it lightweight and help the UI render faster.
If I am starting a new project how should I pick between using YUI 2, YUI 3 and jQuery?
I know there are a bunch of questions/answers already about can you use them together, but I am trying to figure out what criteria I should be thinking about to make my decision.
Are they overlapping?
Is one better at GUI and the other better at internals?
Do they play well together? My understanding from other questions is that they can live in different namespaces, so they can live together, but that doesn't necessarily mean that it is good to use both.
Thanks!
If you are familiar with neither, I personally have found jQuery's documentation and API easier to understand than YUI's, at least for simpler things. It also appears there is more jQuery related information than YUI on stackoverflow.
YUI does have its users and supporters though, so check it out in case you end up finding it suitable for you. It's got a huge library of additional modules you can use for complex web applications.
My usual advice would be to go with whatever you're familiar with, and I say this because I don't think it's worth dropping one to start learning the other from scratch. But if you are familiar with neither, then you should check out how easy the documentation for both is to understand.
PS I would not recommend YUI2 if you're starting anew as it has been superceded by YUI3, which is much better designed.
We need more information about the type and size of the project before a proper library can be suggested.
For example, if you're building a semi-complex/large-ish web app, I would suggest Dojo or ExtJs. Otherwise, for smaller projects, jQuery might be more appropriate. I cannot comment on YUI as I have not used it.
Impossible to say without knowing more details about the project. Use jQuery or Prototype for things like DOM manipulation and making autocomplete, etc. If you need a more powerful Javascript implementation take a look at ExtJS, which is basically a full stack framework for Javascript.
Both are JS frameworks and there to help you. YUI is known to be more natural in them and more closer to the original Javascript while jQuery is known as more easy and you find more jQuery users and support around then YUI. However, as said earlier, it depends on the project, if it is likely that you will be making your own custom widgets, I will suggest you to go with YUI but if it's like a simple e-commerce website in which you just need some fancy galleries and shopping cart, go with jQuery, you will learn and implement that quickly. I am not saying that you can not go more in depth with jQuery but my impression is that jQuery is more of a CakePHP for PHP like of framework which gets you off the grounds quickly.
In my opinion there is no need for you to use them side by side in a single project, that will just produce the over-head as both do whatever you want to do in them i.e creating dialog panels, autocomplete quick searches, event related utilities etc.
I am writing down a series of beginner and mid-level tutorials for YUI users, let me know if you find them useful or if there is anything else where I can help.
http://ciitronian.com/blog/tag/yui/
Aside from the framework, is jQuery worth using rather than creating your own javascript? I've always debated if the framework was better to use than to create your own calls. Are their disadvantages of using it?
Sorry for beginner question, I'm trying to feel out if it would be better to use this and create some of the ajaxish workings of my site rather than develop it from scratch.
Are there other frameworks out there that would be better to use to create an ajaxish website?
Yes, jQuery is worth it. I speak as someone who resisted using any library for a long time, then finally saw the light.
I do recommend that you build some hand-rolled Ajax interactions before you dive into using jQuery for Ajax, so that you understand exactly what is happening with Ajax. Once that's achieved, though, let the library do the dirty work.
jQuery (and most other framework) are for making difficult things simple. It keeps you from having to write cross-browser compatabile code. It keeps you from having to write recursive methods to update multiple dom-elements. It basically cuts your development time down substantially, and saves you a lot of frustration.
Stackoverflow Archive:
Which Javascript framework (jQuery vs Dojo vs … )?
Great discussion (with lots of involvement) over various javascript frameworks. It will benefit you to browse this in depth, or even at a cursory level.
When should I use a javascript framework library?
Which Javascript Framework is the simplest and most powerful?
What JavaScript library would you choose for a new project and why?
Which Javascript Ajax Framework is most powerful and very lightweight?
Which javascript framework can be used for all browsers?
If you like reinventing the wheel, write your own. For me, I prefer to spend my time focusing on solutions rather than lines and lines of javascript code. I'll use JQuery to save resources and frustration
One thing I want to add is for the past couple of months, I was trying to fill a web developer position for my team, and it proved to be a difficult task.
Lots of folks knew how to use a JS framework (JQuery, ExtJS, YUI...), but once outside of the framework, they found themselves in an unfamiliar ground. I had a self-claimed senior JS developer with over 10 years of experience couldn't tell me how to use function.call() or function.apply() or how to implement simple inheritance in JavaScript.
Framework is great and definitely useful, but you will also want to make sure to know how to implement the basic OO concept and DOM manipulation without the framework.
BTW, we use ExtJS and if you are starting to pick a JS framework, you may want to look around to see which one suits you the most.
jQuery is a big project with many users. By that nature, it will be better tested than anything you write by yourself.
It is a great framework for most uses I've come to need.
Is there anything in particular you are trying to do?
jQuery helps you avoid worrying too much about cross-browser JavaScript issues, and helps you get things done quickly. As far as I'm concerned, the key reason for using it vs your own hand-rolled JavaScript probably is the "don't re-invent the wheel" cliché.
Apart from added productivity, JQuery's main plus is that it takes all (most) of the pain out of cross-browser testing.
There is no reason you cannot write your own code and splash in JQuery where needed. JQuery is incredibly lightweight for what it provides and you will quickly find that you can do most takes easier in JQuery (especially once you start using the plugins for it) than by hand. I am a big believer in not reinventing the wheel. The JQuery code is tested by tons of people and there are so many plugins to chose from I could almost guarantee that what I want to do has already been done before.
If you are starting with a clean site, now is the perfect time to take JQuery for a spin though, because if you do get hooked on it your code will be more consistent if you solve similar tasks using the same technique. Go give it a try :)
I would highly recommend using jQuery (or any comparable framework) over straight JavaScript. It just makes common programming tasks easier, most notably cross-browser development.
jquery makes js related work easier and more important standardised/compliant.
If you need re-assurance as to its use:
MS & Nokia are bundling it in their dev platforms.
Its compatible with many of the newest web technologies.
It has a large developer community supporting it.
There are many plug-ins available to aid RAD.
and more...
Give it a go!!
Definutly! Jquery wil save you a lot of time struggling over code and makes your code easier to read to non-experts.
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