Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am just curious. There are many ready-to-use AJAX libraries out there like Mootools, Scriptaculuos, Prototype, YUI etc
My question is, is it possible to combine them? If I download all the code and put them on the same page, will it cause errors?
Which open source AJAX library would you recommend for a beginner?
If you're using Java on the back end, the ZK framework claims to provide full AJAX capabilities, i.e. no need to mix and match a bunch of different libraries. From the testing I've done so far, they seem to be right.
Of course, but like anytime you combine frameworks, you'll find you sometimes have to write your own glue code. For a beginner, it may be simpler to use just one.
It depends on the choice of frameworks you use. If they try to define the same variables then one is going to overwrite parts of the other. jQuery avoids this by defining the aliasing the core function so it has two names and YUI avoids it by not having a blasted dollar function in the first place.
Libraries tend to be relatively large, so you should probably avoid using multiple ones on grounds of bloat rather then anything else.
It is rare that using two different libraries is useful - the main reason for it is wanting to use multiple third party modules that depend on different libraries. In that circumstance, I would try to find alternatives that use the chosen library.
What opensource ajax code you using?
YUI usually. It is robust, well tested, well documented and powerful - although the initial part of learning curve is a little steeper then some of the others.
It does it a disservice to call it "ajax code" though - Ajax is a very small part of any of these libraries.
What would you recommend to ajax
beginner?
YUI.
What ajax features that can impress people?
That depends on who the people are. A lot of people will be impressed by being able to quickly produce slidey, fading, spinning animation effects ... but they aren't all that useful. A good event handling system doesn't do anything that will impress a lay person, but it will make like a lot easier for the programmer.
I recommend you to use the jQuery framework, because in my opinion has one of the best and easiest to understand implementation of AJAX.
An example:
jQuery.post('thescript.php', parametersInJson, function(response){
alert('The server response: '+response);
});
yes you can but you might run into some trouble (you might need to override the $ function...)
and i do recommend jQuery
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
If my purpose is served by core JavaScript only, should I use jQuery?
I mean if I use those libraries, will the application become slower or remain same?
If anyone have any reference, can you please share with me?
Yes, Sure
Actually AngularJS is also use jQuery Dom selection code for angular.element.
Its called jqlite.
Also for most of CSS framework like bootstrap, foundation jQuery is also required because most of utility is still built with jQuery.
AngularJS is also very powerful but sometimes its dependent on jQuery.
So you can use both of it on a single page no worries.
TL;DR: It really depends on what you are planning to do.
For example: A simple static webpage may not need angular or even jQuery for that matter.
A web application on the other hand can really benefit from using libraries/frameworks such as Angular and React.
A good rule of thumb is to use only what you need, not bloat up your project with libraries and dependencies just because.
You can achieve really good page speeds with or without frameworks, a good start is googling around and see what you want to use.
Yes using jquery or angular means additional code that needs to be executed, and that means a measurable difference in execution time, although usually not a noticeable time difference.
But that's the wrong question to ask
I don't know what application you have in mind, and how experienced you are, so ...
both jquery and angular provide a lot of stuff which may speed up your development time tremendously.
can you write code that contains fewer bugs, memory leaks, attack-vectors, etc. than these frameworks, which have already been used/tested thousands of times in production?
Are you sure you can write code that is more performant than these libs? Especially from jquery I know, that there are some pretty ugly corners, but can you do it better? I don't know your skill level.
browser compatibility: how skilled are you on that topic?
and at last, why reinvent the wheel?
Oh, and about performance in web-pages. A few years ago there was a statistic going around about performance, with the general summary:
js usually uses only about 15% of the performance/runtime.
something around 60-80% of the runtime is used to render the page
if you want to "improve the performance" of your JS, don't micro-optimize stuff, but check where you trigger render-cycles that can be avoided.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
For a new page I'm working on, I want to make sure I do everything “right” to the best of my ability. I was wondering what the best practices were re. one JS file per page or one file containing everything. I found this question which helped some, but raised more questions.
I pretty much only use JS for three things:
transitioning things on button clicks (showing/hiding panels, etc.),
pre-validating forms, and
AJAX calls.
When I compare my use cases to the namespacing approach, it seems like overkill; I don't really understand why I would need to set up such a complex framework to work with JavaScript. This leaves me with two questions:
For what I'm doing, should I use one JS file per page, or use Irish's namespace technique and a single script import?
What the hell are people using JS for that requires so much structure?
If your pages don't have anything in common, you might use a script file for each page. If you've got a lot of logic common between your pages, you'd probably want to put those common bits into a file of its own and include it wherever you need it.
As for why so much structure is necessary, people are making more and more complex things with JavaScript. Consider Gmail, for example. I'd imagine there's quite a bit of code in there, and without much structure, it would become difficult to maintain quickly.
OK, That page is from 2009 - The way Javascript is used on the web has changed a lot since then.
Now that most web pages contain multiple third-party Javascript files from different sources (and different developers). It makes a lot of sense to encapsulate your code in a custom namespace to prevent your code being overridden by other code using the same variable names, and it isn't any harder than:
Mynamespace= {};
Mynamespace.foo = "bar";
Mynamespace.foobar = function(){
//function body
};
Writing structured Javascript isn't about adding complexity. Writing structured Javascript allows you to encapsulate behaviours and responsibilities into re-useable portions of code that are much easier to test, maintain, re-use and extend.
You don't even need to make the single-file/multiple files judgement. You can use a framework like require.js that compiles all of your separate code files into one single file for deployment.
JavaScript is now officially a first-class language in Visual Studio Its being used to write web-servers, templating systems and even 3d engines.
Welcome to 2013 ;-)
_Pez
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 recently stumbled upon some javascript forums (sadly, link is lost somewhere in the universe), where you could feel real hate against jQuery for not being... any good?
Most arguments seem to make sense actually.
Now, I really like jQuery, mostly for letting me concentrate on things I want to do rather on browser inconsistencies and it actually makes AJAXing with cool (or overused?) effects fun.
But if really is something rotten in the core of jQuery, I don't want to rely on it the way I actually... rely on it.
I don't want to start yet another argument over which framework is the best... but... Which framework is the best (joke)? As a case usage, think about small to medium web and it's administration.
I'm just trying to figure out, if stuff in some framework or pure javascript with few mine functions really makes difference.
Edit:
I actually tried to have a normal objective discusssion over pros and cons of:
Using a framework over pure javascript and
jQuery vs. others,
Since jQuery seems to be easiest to work with with the quickest learning curve. However, some people just don't understand it and think that I'm starting yet another flame (what I am not). I am actually voting to reopen this question.
Also I'm really interested in:
Does jQuery heavily rely on browser sniffing? Could that be a potential problem in the future? Why?
I found plenty JS-selector engines, are there any AJAX and FX libraries?
Is there any reason (besides browser sniffing and personal "hate" against John Resig) why jQuery is wrong?
jQuery actually, as most used, stands for other frameworks also.
It's all about performance and development speed. Of course, if you are a good programmer and design something that is really tailored to your needs, you might achieve better performance than if you had used a Javascript framework. But do you have the time to do it all by yourself?
My personal opinion is that Javascript is incredibly useful and overused, but that if you really need it, a framework is the way to go.
Now comes the choice of the framework. For what benchmarks are worth, you can find one at http://ejohn.org/files/142/ . It also depends on which plugins are available and what you intend to do with them. I started using jQuery because it seemed to be maintained and well featured, even though it wasn't the fastest at that moment. I do not regret it but I didn't test anything else since then.
Personally i think you should learn the hard way first. It will make you a better programmer and you will be able to solve that one of a kind issue when it comes up. After you can do it with pure JavaScript then using jQuery to speed up development is just an added bonus.
If you can do it the hard way then you can do it the easy way, it doesn't work the other way around. That applies to any programming paradigm.
jQuery like any other good JavaScript frameworks supplies you with functionality independent of browser platform wrapping all the intricacies, which you may not care about or don't want to care about.
I think using a framework is better instead of using pure JavaScript and doing all the stuff from scratch, unless you usage is very limited.
I definitely recommend jQuery!
"I actually tried to had a normal objective discusssion over pros and
cons of 1., using framework over pure javascript and 2., jquery vs.
others, since jQuery seems to be easiest to work with with quickest
learning curve."
Using any framework because you don't want to actually learn the underlying language is absolutely wrong not only for JavaScript, but for any other programming language.
"Is there any reason (besides browser sniffing and personal "hate"
against John Resig) why jQuery is wrong?"
Most of the hate agains it comes from the exaggerated fanboyism which pollutes forums with "use jQuery" as an answer for every single JavaScript question and the overuse which produces code in which simple statements such as declaring a variable are done through library calls.
Nevertheless, there are also some legit technical issues such as the shared guilt in producing illegible code and overhead. Of course those two are aggravated by the lack of developer proficiency rather than the library itself.
Does jQuery heavily rely on browser sniffing? Could be that potential problem in future?
Why?
No - there is the $.browser method, but it's deprecated and isn't used in the core.
I found plenty JS-selector engines, are there any AJAX and FX libraries?
Loads. jQuery is often chosen because it does AJAX and animations well, and is easily extensible. jQuery doesn't use it's own selector engine, it uses Sizzle, an incredibly fast selector engine.
Is there any reason (besides browser sniffing and personal "hate" against John Resig) why jQuery is wrong?
No - it's quick, relatively small and easy to extend.
For me personally it's nice to know that as browsers include more stuff (classlist API for example) that jQuery will update to include it, meaning that my code runs as fast as possible all the time.
Read through the source if you are interested, http://code.jquery.com/jquery-1.4.3.js - you'll see that features are added based on the best case first, and gradually backported to legacy browsers - for example, a section of the parseJSON method from 1.4.3:
return window.JSON && window.JSON.parse ?
window.JSON.parse( data ) :
(new Function("return " + data))();
As you can see, if window.JSON exists, the browser uses the native JSON parser, if not, then it avoids using eval (because otherwise minfiers won't minify this bit) and sets up a function that returns the data. This idea of assuming modern techniques first, then degrading to older methods is used throughout meaning that new browsers get to use all the whizz bang features without sacrificing legacy compatibility.
Jquery VS javascript, I am completely against the OP in this question. Comparison happens with two similar things, not in such case.
Jquery is Javascript. A javascript library to reduce vague coding, collection commonly used javascript functions which has proven to help in efficient and fast coding.
Javascript is the source, the actual scripts that browser responds to.
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 7 years ago.
Improve this question
I've been building a Ruby on Rails site in recent months and I've only used a small amount of built in JavaScript functions. However I will be doing much more JavaScript development in the coming weeks and months and I am debating on which JavaScript framework to go with.
On the one hand jQuery seems to be the more popular one, but then again Prototype is already built into Rails. I've also read a bunch of articles online from a few years ago talking about how jQuery is more concise at some things but sloppy on others, and giving various other opinions.
So my questions are to the people who have used both (preferably recently):
What is the difference in using either Prototype and jQuery from a pure JavaScript and from a Ruby on Rails perspective?
Is there a significant difference between them or are they now pretty close to each other in terms of functionality and code writing?
How high is the switching cost in terms of things that have to be relearnt and code that has to be rewritten?
Thanks
Previous discussion
Much, if not all of your question has been discussed already. See the search or:
How would you go about for switching a site from Prototype to jQuery
Prototype, dojo or jQuery?
Why does everyone like jQuery more than prototype/script.aclo.us or mootools or whatever?
Is it true that Jquery + Rails is problematic?
Using jquery in Rails
Switching from Prototype to JQuery
I'm in the process of switching from Protoype to JQuery, mainly for reasons of performance (I have seen too many benchmarks with Prototype always coming in last to JQuery, MooTools and Dojo.) I would say switching cost is not horrible, because most basic concepts (Selection, Effects, Ajax) are very similar. However, every line of Prototype code has to be carefully rewritten - carefully especially because many helper functions and constructs ($ $$) look deceivingly similar.
If your code contains many complex chained constructs that may be available in Jquery as well, but function differently, migration can become a very cumbersome task. If you use it only for quick $() element selection, effects and a bit of Ajax, not so much.
Either way, be prepared for a phase of intense learning. JQuery constructs are small and smart, but are terrible to read IMHO (and look god-awful compared to a block of native Javascript, but that's a different discussion). It definitely takes time to get familiar with the syntax and principles if you're coming from a different framework, or native Javascript.
Pekka's answer is great, but one thing that should be added is that Rails is moving heavily in the direction of being Javascript framework agnostic. Although when Rails first came out, its AJAX integration was innovative, the Javascript landscape has changed dramatically since then, and the Rails integration doesn't really live up to best practices anymore. As such, the Prototype integration should not be considered a major factor today on Rails 2.3, and it will be even less of a factor in Rails 3.0 which will likely be released within the next few months. I recently read an interesting article describing some of the most significant changes to Rails' Javascript integration in years.
My current project has thousands of lines of legacy Prototype code, but we've recently started using jQuery because its benefits were too great to pass up. My impressions:
Prototype is a mature framework that does a very good job shoring up browser differences and providing very well-rounded functionality. Unfortunately it is a bit heavy-handed with its changes to the default Javascript environment, and it's not seeing rapid development and doesn't have a significant plugin ecosystem.
jQuery is a newer framework that was able to leverage some of the lessons of the early javascript frameworks like Prototype to create something more modular, less obtrusive, and significantly more powerful and concise. I still love Prototype, but jQuery's DOM manipulation and plugin ecosystem is just too good to ignore anymore. If I was starting a greenfield project I'd have to go with jQuery because that seems to be where the innovation is happening (at least between those two choices).
There is a pretty big difference to the way you work with jQuery compared to prototype, once you get used to the nuances of the frameworks it becomes pretty easy to switch between either of them.
The biggest hurdle in the beginning is the fact that Prototype hooks itself into the dom right away. As soon as you include it into the page all dom elements you look up will have the prototype functionality attached to them. With jQuery it leaves all the elements alone until you access one with the jQuery selector $('css-class'). The object you get back from that call will have the jQuery methods attached.
If you want to ease yourself into jQuery you could leave everything using prototype and include jQuery and call jQuery.noConflict(); http://docs.jquery.com/Core/jQuery.noConflict. This will give the '$' method back to prototype and let you use jQuery by calling jQuery('css-class') instead.
If you want to fully jump into jQuery I would recommend using the jRails plugin (http://github.com/aaronchi/jrails). It will replace all the rails ajax helpers and have them use jQuery instead of prototype. I've done this in a number of projects and have never had any problems.
In the end you should just take a look at prototype and jQuery and see which one fits your coding style. You can accomplish the same things with both frameworks, it's just a slightly different syntax and way of thinking for each.
jQuery is more efficient for small, smart client effects. prototypejs is more efficient for deep javascript development.
jQuery has a host of plugins for robust UI effects. prototypejs has a complete library for Enumerables, Functions, Hashes.
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 haven't done web development for about 6 years. I'm trying to get back into it and there is a lot of new stuff out there. I've chosen to write my next project with Perl and Catalyst.
I keep hearing about various JavaScript and CSS frameworks. I know very little about these frameworks so maybe this question is overly broad and open ended.
What are the strengths, weaknesses, and popularity of the various frameworks? Should I be using YUI, JQuery, neither, or something else?
Firstly, it's probably worth perusing Which Javascript framework (jQuery vs Dojo vs … )?.
Secondly, there are two broad categories of Javascript framework:
Rich: made for creating so-called Rich Intenet Applications, they are typically aimed at creating experiences much like a desktop applications with sophisticated windowing GUIs. This includes, but aren't limited to, YUI, Dojo, ExtJS and SmartClient;
Complementary: these are more focused on improving a traditional Website experience rather than replacing it altogether. These include jQuery, Prototype and others. Some might point out that jQuery has jQuery UI but this is a barebones widget library at best and completely incomparable to, say, YUI in terms of out-of-the-box user interface capabilities.
So the first thing you should ask yourself is: what kind of application are you creating?
Personally I think you can't go wrong with YUI or jQuery, depending on your answer.
Why not use both? I have on a couple projects.
jQuery's size is small. You can use the minified version from google's open ajax libraries, and since many people already do this, there may be no download at all b/c it may very well already be in your user's cache.
As for YUI, they have a great configurator for getting exactly what you need. Also their documentation is very thorough and their widgets top notch in compatibility.
Having worked with both, jQuery's strength is it's speed and flexibility to do a lot of tasks. YUI's strength is it's top-notch, ready to use widgets. Both projects have written very solid code that will not interfere with each other. Both projects have worked hard to be compatible across all A grade browsers and careful not to trash the name space - which is better than I can say for some other frameworks.
I personally recommend jQuery. It is extensively developing, fast, powerful and small (comparing to YUI for example which is big). It has jQueryUI library with customizable themes for interface elements and many plugins.
I have used JQuery, however you really should look into trying both YUI and JQuery to see how they work and whether or not they suit your needs.
YUI: http://developer.yahoo.com/yui/
JQuery: http://jquery.com/
I personally find the JQuery documentation to be excellent. I have not really given YUI a shot.
JQuery is the more popular of the two frameworks from what I can tell, I used JQuery at my last job and have seen heavy use of the framework.There are many plugins that have been developed for JQuery and examples can be found all over the web. Again though, I've never really played around with YUI.
Here are benchmarks of MooTools, JQuery, Prototype, YUI, and Dojo on different browsers.
Benchmarks
First question you should ask yourself is: what do I need from this framework? JQuery and YUI, for example, take two totally different approaches. JQuery itself is pretty much a simple querying library that uses XPath selectors to navigate the DOM tree and apply transformations to its nodes. That being said, it also has tons of libraries (such as JQuery UI, as well as hundreds if not thousands of third party ones) that contain UI widgets, nifty animations, and other ridiculously cool things you never knew you could do so easily with Javascript. It's a functional library and doesn't really deal with objects.
YUI, on the other hand, goes the opposite direction. Primarily it's a UI library, meaning it exists to provide you with functional UI widgets (buttons, trees, panels, dialogs, etc). It also has additions and support/utility objects that can be used to do the same sort of XPath DOM tree querying as JQuery, but that's secondary. It's also pretty object-oriented.
The link cletus posted is also a great place to start.