I've been doing a lot of reading about AJAX, and wanted to know which is the better way to approach things: by using a library such as jQuery using their built-in methods or creating JavaScript without a library for AJAX?
Ajax has a lot of quirks when working with the XMLHttpRequest Object. When you start to work with it, you will not see it, but when it is out in a production environment, it will bite you in the butt. Browsers, browser version, user settings, the type of server, type of request, and much more can affect what needs to be coded. Libraries tend to solve most of the problems, but they all are not perfect.
I always tell people it is great to work with a tutorial to see how the XMLHttpRequest works. After you have learned how to do it naked, work with a library that fits your needs.
Eric Pascarello
Why create a library when plenty already exists? If you create a library it is going to take time and effort and you'll end up going through the same hurdles others already have. And unless your company is trying to sell an Ajax library then stay away from writting your own plumbing code.
I am currently using both JQuery and Microsoft's Ajax in my site and have found that they are both feature complete with plenty of options of different ways you can set up the communication.
If you ask this question on comp.lang.javascript you'll get lots of different answers, many of which disdain the commonly-used libraries (one quote sometimes taken slightly out of context is Richard Cornford's post on c.l.js in 2007: "Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not the
best source of advice on designing systems that use javascript.")
The argument for libraries is they abstract away most of the differences between browsers and allow for cross-browser scripting. The argument against libraries is that they are bloated code with quirks of their own, so you'd have to learn just as much to use them well as you would to use cross-browser techniques in raw javascript. If you are writing lots of Javascript that you're going to reuse in multiple places, and you're trying to make websites that load quickly and use a minimum of excess bandwidth (e.g. if you have pay-per-use webhosting like via Amazon S3 or nearlyfreespeech.net), then it's probably worth stripping whatever you're going to use out of a good library, tweaking it, and using that.
I was all psyched about Prototype for a while, but then decided I just need a few simple building blocks. I tend to use Doug Crockford's simple JSON library, and then some of Fork Javascript's minimalist libraries as needed (primarily FORK.Ajax), and do the rest myself from scratch or reusing routines from an earlier project that I've honed to something that works well for me.
why wouldn't you use library if it meets your needs. you're using .net framework, or java JRE, or php built-in functions...
you can create your own javascript for the purpose of learning, or to do something libraries don't offer. but for regular development, you are much quicker with library and you get cross-browser compatible JS without having to code cross-browser support manually, it's already built-in into the library
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When should I use a javascript framework library?
All,
I'm fairly new to web app development.
Recently, I've built a few HTML5 apps specifically targeted at iPads and iPhones.
I've noticed that very few people seem to use straight JavaScript - virtually everyone uses jQuery (Prototype, YUI, Mootools, etc. seems somewhat less popular).
If I'm starting out - SHOULD I use jQuery? Or, would I be better off writing my own JavaScript?
In general - I prefer using as much of "my own" code as possible. I'm uncomfortable using a framework if I can avoid it - I feel like it prevents me from understanding what's going on "underneath the hood."
(Sure - even if I'm using straight JavaScript - there are many levels "underneath the hood" (e.g., browser's JavaScript enging, the OS, kernel, etc.), that I don't understand, but the lower the level I do understand, the better.)
The only concrete advantage I can think of for not using jQuery... loading the ENTIRE jQuery framework, when I only need a handful of it's functions - seems unnecessary and wasteful.
So - in general - would I be better off creating my own, highly-tailored, application-specific JavaScript for each project?
Or - should I bite the bullet, get over my reluctance to use someone else's code, and use jQuery? Are there advantages to it besides just not having to create my own versions of functions that have already been written by someone else?
E.g., are it's functions somehow optimized or more efficient than what I could produce on my own?
[UPDATE]
One of the common themes in the answers so far... jQuery eliminates the need to worry about browser differences. Good point.
By in my case, I'm writing apps specifically for the iPhone, iPad, and Android. As far as I know - the browsers are pretty consistent. The vagaries and idiosyncrasies of IE6, 7, and 8 really don't seem to apply. Is that true? If so, does it eliminate a major reason for using jQuery?
Another key issue... jQuery is so popular, that there's a good chance that it's already in the user's cache, thus eliminating the need to load it. True... but is that the only performance hit? In other words... does the existence of the hundreds of functions that are part of jQuery impact the performance of my page? (I don't know how JavaScript engines work, so I have no idea if this is the case...).
Many thanks in advance for your advice and guidance.
I do understand you. I had the same thoughts for quite a while. However, in this particular instance it has a good reason why so many people are using a framework (jQuery as the most popular nowadays). The reason is, not to care about browser-differences + a nice toolkit of methods and functions.
But the first thing (browser differences) is by far more important. If you're going to write everything on your own, you just have to care about SO SO many things for all those browsers and versions out there, it's just disgusting. So some smart clever people came up with the idea, why not creating a library which abstracts all those differences and we can use the same set of methods on almost any browser platform. Boohja, that is how a Javascript library is born.
Another point you mentiond: loading the ENTIRE jQuery framework (...)
Well, as you also correctly mentioned, jQuery is so popular it's so likely that an user already has a jQuery-version cached in his browser. So it's always a good idea to first try to load a library like jQuery from a common CDN like Google. The chances that the browser don't even need to download it are pretty good.
Now I'm not gonna argue about the code quality and stuff like that. But jQuery is a pretty solid lib. It offers a very nice browser abstraction along with a convinient syntax (jAndys opinion). But there are lots of other very nice librarys out there. In general I would always recommend to use one, especially for large scaled web applications.
At some point, you'll start anyway to write your own methods to abstract browser differences and behaviors on your own, because it is just annoying to write so much more code every time. Therefore no need to invent the wheel here (only for learning purposes probably).
This is more a question of philosophy than anything else. jQuery is highly optimized for performance, lightweight and there's a lot of things that are just tedious to do by hand every time. If you have a project, that only needs 4-5 functions, there's probably no need to use a library.
But if there's an application that uses class/id/attribute selectors, animations, listens to events, etc., then you should "bite the bullet".
There's no reason not to go with both approaches imo, just choose according to the project.
My opinion is that if you think that you can bend javascript to your will and not need a framework, then go for it.
I'd go for jQuery if I were you, simply because of the cross-browser quirks JavaScript has. jQuery handles this for you.
E.g., are it's functions somehow optimized or more efficient than what
I could produce on my own?
Probably, although there might be a few exceptions.
JavaScript (web browsers) should be standardized, but they not (yet). jQuery do that!
You might be interested in list of tiny JS frameworks, if you think jQuery is too large.
Yes, jQuery hides a lot from you. Yes, a page with jQuery will be slower than an optimized page without jQuery. But computers are so powerful these days that, unless you are using jQuery in a very inefficient way in huge applications, nobody will notice.
About the download issue: it is only 31KiB. Even with GPRS this will only take a couple of seconds to load.
My advice: learn jQuery, and then use it when appropriate.
I've been looking into the javascript package Dojo, and I noticed that it uses sort of its own form of Ajax, but as far as I can tell it does the same things as standard Ajax. Is there a benefit to using either over the other, or is there really a difference?
I'm new to both Ajax and Dojo so feel free to correct anything I may have said.
The first line of the Dojo description sums up the benefit: "Dojo saves you time."
You can code all of your AJAX functionality by hand, or you can use a framework (Dojo, jQuery, Prototype, etc) to take care of a lot of the mundane tasks for you.
Edit:
For a good list of reasons to use Dojo or something similar, please see: 6 Reasons To Use JavaScript Libraries & Frameworks.
Like other libraries and frameworks for client-side web applications, Dojo provides a wrapper around the native browser ajax capabilities. Ultimately it can only do what the browsers will allow. It can, however, make things a little more convenient, in a way similar to that by which php makes assembly language programming more convenient.
I have developed one of my modules using Dojo. Its gone really well and I have done a lot of custom plugins and server support in Dojo to allow AJAX calls, RPC + SMD communication with my server.
However, now that I am getting onto the user side of things, I am seeing that jQuery has some really nice already built plugins. Do you think it is possible to support both JS libraries realistically without it being a massive problem?
What kind of integration can I achieve? Does anyone have experience in this?
I have probably written somewhere in the region of 30k lines in Dojo for my Administration panel...
jQuery is very good about not messing with the prototypes of built in javascript objects (unlike Prototype), this allows it to be used with other libraries quite easily.
A source of potential conflict is jQuery's use of $ as a shortcut for jQuery. I'm not a dojo user, but if this conflicts with dojo in some way, there are instructions addressing this.
That said, I think you'd be better off looking at these jquery plugins and rewriting them and porting them to dojo. I'm sure the dojo community would appreciate it, and it would give you experience. It'd also make your application a little slimmer in the waist area.
Edit: I've noticed a couple answers trivializing the download speed of adding an additional library. I'd take this with a grain of salt.
As developers we tend to see only the extra 10ms it takes to download the library over localhost, or from our development server on a 100 Mbit LAN. The download speed is not so trivial from California to Virginia, or especially from USA to Europe. Additionally, it adds further burden on your client's javascript engine. If they are using a 1-2 year old good computer with Safari or Chrome, this would be negligible, but if they're on IE, FF2, or some versions of FF3 the difference can be severe, or at least measurable.
When using 2 libraries (both of which, I'm sure - were designed to be used by themselves) you have 2 main worries:
That one library will effect the other.
That having a dependency on 2 libraries will bloat your pages.
In this case, I would bet that #1 is not going to happen. Although #2 is still a concern.
Most of the popular JS libraries can be scoped to their own global shortcuts. JQuery can be set to not initialize the $ variable. JQuery aside, I hear that Dojo and Prototype can work together without conflicting.
Regardless of what combination of JS libraries you decide to use, the best way to get information on compatibility issues is to hit the mailing lists relevant to the JS libs you'll be using with each other.
http://docs.jquery.com/Using_jQuery_with_Other_Libraries
http://www.dev411.com/blog/2006/06/13/dojo-and-prototype-together
Query.noConflict() makes for fairly easy interoperability because you can redefine $. As hobodave draws attention to, Prototype is lousy in this regard (because you can't easily just redefine $ with Prototype). I am not sure but I think Dojo doesn't have any issues of it's own and plays nicely with others out of the box (please someone correct me if that's not true).
The biggest problem I've had is the number of "must have" libraries written in specific frameworks, such as for things like sophisticated graphing that would be non-trivial to implement from scratch.
Bloat is bad, but compared to image sizes JS script sizes are of negligible concern (because it's so small and connections are so fast and it's only on first page load if you get your caching right, it's almost a non issue). I'd say maintiainablity being more of a worry, and it's a matter of deciding if you want that must-have-plugin that you don't have the time or inclination to reinvent in whatever framework you are using.
I have used Prototype, jQuery, and ExtJS on several projects (for various reasons) and almost always use jQuery and ExtJS together. One way to limit trouble would be to avoid mixing libraries in any given page - keep Admin page to dojo and new pages to jQuery - but what fun would that be? :-)
I find few problems when integrating jQuery and ExtJS. I pick a framework for classes/objects/inheritance (I use ExtJS) and stick to it. Then, I use ExtJS to create most widgets and I use jQuery for low-level DOM manipulation and simple widgets. Again, I cannot recall running into conflicts when using two libraries, but FireBug is a good tool to uncover suspected causes of such conflicts.
We started a new project and realized that we needed a general purpose javascript library that contains a nice set of string functions, MD5, base64, allows extensions, etc. Also, copying and pasting functions from other libraries doesn't sound very attractive.
So, I guess the question is which javascript library contains the most general purpose functionality out there? or maybe there is a good collection of global functions out there we could use/extend. We know DOM manipulation is covered by many AJAX libraries including JQuery.
*Mind you, we could alternatively extend ExtJS, JQuery, etc. Is that what you guys are doing?
Google Closure Library
It contains (quoted from link):
a large set of reusable UI widgets and controls, and from lower-level utilities for DOM manipulation, server communication, animation, data structures, unit testing, rich-text editing, and more.
It also contains a nice set of string manipulating methods, in goog.string namespace.
Underscore
Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js
Underscore is intended to go along with other library, like jQuery or prototype.
It's not extensible like jQuery or Google Closure, though.
*Mind you, we could alternatively extend ExtJS, JQuery, etc. Is that what you guys are doing?
Yes, I do and I think most are. A lot of what you describe as a "general purpose library" is covered by Frameworks like JQuery, Prototype or Moo. And short of clipping the webmaster's nails, there's a JQuery plugin for everything that's not already in the core.
Still, I'm interested to see whether any other "general purpose" libraries come up here. There are fields - like string manipulation, as stated in one of the comments to another answer, and advanced date operations - where none of these frameworks is the holy grail AFAIK.
I use the jQuery library and a bunch of plugins. jQuery's plugin directory contains a lot of useful tools. There's also jQuery UI, a set of interactive components and effects, which you can use if you don't want to use a more complex library like ExtJS.
Of course every project is different, and you will probably end up writing some helper functions on your own.
I realize that others are going to say the same, but jQuery truly amazes me every time I learn something new about it.
DOM, CSS, and event manipulation along with easy AJAX, extensibility, and the plethora of existing extensions make jQuery a wonderful tool for web development.
jQuery is incredibly useful for UI manipulation. However, being open source, it contains some less than optimal code. If you start running into performance issues, don't be afraid to delve into the source and see what's going on.
I have been using jQuery for some time now and that seems to handle most of the basic operations I need. It has a healthy library of plug-ins and you can always write your own. It is a very good lightweight js library and even if it doesn't do all that you need it to you it is a good starting point.
I am developing my first ASP.NET MVC application and I beleive that Script# can help me a lot. But it cannot find the resource necessary to support my development.
I could not find The codeplex site;
There is only one manual, which is very good, but it is not enough;
I could find very few tutorials;
I know that Script# was used to develop ASP.NET MVC scripts and that the source of MVC distributes the library.
But it seems that it is used only internally in Microsoft.
Where can I find other resources???
Do you really think that Script# will be continued and new versions will be deployed and it should be used by third-party projetcs ???
Thanks in advance
Don't be afraid of Javascript, it's a beautiful and powerful language. And with frameworks like jQuery, Prototype and Dojo, DOM manipulation and AJAX are greatly simplified and cross-browser issues are mostly history.
About Script#, I agree with this answer by mcintyre321. Last release over a year ago + closed source = no go for me.
UPDATE Jan/2010: there have been new Script# releases since the original writing of this answer. It's still closed-source but the author mentions open sourcing it after 1.0
UPDATE May 2011: Script# is now open source.
In short, my answer is: if you like powerful IDEs that run on Windows, OOD and C#, use ScriptSharp. It is more maintainable and structured, and demonstrably stable enough to use on serious projects. It can also be easily extended, as illustrated below and by other projects.
Since this is yet another Google indexed thread where people refer to Script# and jQuery as mutually exclusive I just wanted to point out some people are merging these two worlds, and in my case unleashing a lot of power by doing so. I'm offering a completely free and reusable library to access jQuery 1.4 from Script# projects, and full source code for the solution that generates it (almost exclusively from jQuery's own API documentation file):
http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp
IMHO Script# fits well for large projects only, with really "rich" web client. Participating in such kind of project, I could only say that Script# helped us much. josephhemingway's remark about strongly typed is 100% true for such case. Also it allowed us to introduce new .NET developers without any JS background quickly. Assuming Nikhil Kothari's plans to open-source it in the summer 2008, we even decompiled (don't tell anybody! it's illegal) it and introduced generics, operators overloads, various bug fixes, etc.
BUT. Then Script# support faded away. Project on CodePlex with discussions and issue tracking was closed (interesting that parts of framework were published there shortly before). No updates, no future plans, no explanations. After such thing I'd consider Script# only after it goes open source to give the community ability to support it. E.g. on CodePlex.
I use Script#, I think it is great. You can use it with any framework, jQuery, dojo whatever, you would however have to wrap the framework, this could be a big job...
It's only benefit as I see it is that it allows you to develop javascript in a strongly typed environment. I think this is a HUGE benefit. I refuse to develop in weakly typed languages as maintenance is a nightmare.
If however you like to work in a weakly typed language then you wont need Script#.
Short answer NO. Wait for TypeScript.
Script# is really cool, but MS decided not to support it at all. The reason for that turns out to be that they were working on a better version of that - TypeScript (http://www.typescriptlang.org/)
It adds support for everything you need in a static language (intellisense, type checking, interfaces, classes etc.), but still looks very much like JS, and more importantly - confirms to the upcoming ECMA Script 6 standard. (unlike Script# or google's Dart)
Like the others have I would recommend some JavaScript (namely jQuery). Should you wish to continue with Script#, Nikhil Kothari's blog may be a good resource for you. http://www.nikhilk.net/ScriptSharpIntro.aspx -- That being said, I think you'll find that you are more productive with jQuery. There is a large database of community written plugins so you wouldn't necessarily have to reinvent the wheel on everything you want to do. jQuery plugins instead of ASP.NET Controls
Wow Val you got generics to work in
it, I'm impressed, was it hard?
Generics support would be great, so
would method and operator overloading.
josephhemingway
The whole point is that ScriptSharp's parser supports full C# 2.0 syntax. The only thing needed is to generate the proper JS. Not much work, considering JS dynamic nature. Generics would act as Java-style ones, i.e. no generation for each closed type argument set, just one class.
Are you sure that it is illegal to
decompile it, I will have to have a
look to see if it is the terms of use.
josephhemingway
Yep, it's illegal. EULA showed in setup clearly mentions that.
A release went out today, so it is good to see that it is still active.
Regardless of the previous lack of updates and that it not been open sourced I would still use it over plain js. You can stop using Script# at any time and more forward with the 'compiled' js if you don't like it.
I agree with you Val though that it really only fits large js based projects. I don't think you would get much benefit out of using it to perform basic page functionality like validate form input etc. It probably wouldn't be worth setting it up.
If however you are heavily using javascript and need to replicate OOP then I think it is a must. Things like refactoring becomes so easy, with plain js I would never refactor because it was just too hard to implement, over time my code became a mess.
Wow Val you got generics to work in it, I'm impressed, was it hard? Generics support would be great, so would method and operator overloading. Are you sure that it is illegal to decompile it, I will have to have a look to see if it is the terms of use.
The other advantage of using ScriptSharp that no one has mentioned is that if you need to interact with C# (using AJAX/REST/SOAP) you can use the same class definitions in both places and be sure that you have the interface defined properly, because it's the same source file! I have tried to use logic in shared source files with minimal success due to the way ScriptSharp's corelib is not 100% compatible with the C# corelib. But it works great for data file definitions.
I am using jQuery. It is really good. But I beleive that It is more confortable to me to work with C#. Even if it is a subset.
Also I would like to add that you certainly should use ScripSharp when you are planning to develop multiplatform projects. For example, at present time I write my image processing library code for .NET, JavaScript (ScriptSharp), Android (Mono) platforms on C#. Also I am planning to port my code on iOS (Mono) and Windows Phone in the future. And I think it's great code reusing and developer time minimization!