As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We are a small team of developers building a javascript application.
If we weren't using jQuery, we'd want to spend a lot of time making sure the code is cross-browser compatible, and we would run unit tests on all the platforms we supported. This is time-consuming, and adds to our workflow, or takes time to set up.
But, we do use jQuery. Do we still really need to do all that cross-browser testing?
I'm looking for some arguments for and against doing extensive cross-browser testing (i.e., using TestSwarm or something similar) if we already use jQuery -- a library that basically eliminates cross-browser issues.
Thoughts?
jQuery runs on all major browsers, but it always depends on the implementation and anything may go wrong, so it is always a good practice to test it across browsers.
Doing this you will be safer. 99% of the code will work correct but there is still a risk involved for 1% of the code and that 1% may creep critical bugs.
But, we do use jQuery. Do we still really need to do all that cross-browser testing?
Yes
I'm looking for some arguments for and against doing extensive cross-browser testing
Because jQuery might have quirks you might not know about, unless you are really updated with their builds, bugs and fixes.
jQuery might not have patched all differences.
As far as I know, there was this difference in the older versions because IE did not support changing the type of the input when the element was already created:
//IE:
$('<input type="text"/>');
//Other browsers:
$('<input/>',{
type : 'text'
});
jQuery does not patch everything.
This argument holds true as to why map() is patched, but not reduce(). A bug report was created for this, but most of the responders replied that reduce isn't required internally thus it was omitted.
jQuery, like other software, has bugs too
Because there might be some newer JS API that your team members might consider stable when they aren't. An example is querySelectorAll which works quite well already, supported in many browsers, but has quirks which are different from what you'd expect.
Just because you use a great CSS framework doesn't mean all layout problems have been solved. You still even do UI testing to make sure everything looks the same. Same logic should go for all languages, even JS.
How extensively you test depends entirely on your application. It’s a bit of a “How long is a piece of string?” question.
I would say that with jQuery specifically, I’ve encountered bugs in IE 8 and older, often due to invalid HTML, that haven’t presented in other browsers.
And, as #kinakuta’s comment pointed out, jQuery doesn’t cover every browser JavaScript API, or replace the language itself. I’d imagine it’s unlikely that every significant line of JavaScript you write in your application will be jQuery.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm developing Desktop-Software with different OO-based languages. I haven't got in touch with web development since recently. I just started playing around with jQuery and jQuery Mobile to build simple web applications.
I noticed that my projects usually end up with a HTML-file as a base and a *.js file which contains the methods, eventhandlers etc. This somewhat feels like programming spaghetti code and I can't think of how this could work with more complex projects. (Reusability, Performance, ...)
Usual jQuery-Tutorials are just showing trivial examples which work well with the "all methods into a single script-file"-approach. I also read somewhere, that it is better to provide just a big file because it is faster to load just one file instead of a lot small files.
Can someone tell me how bigger jQuery-projects are structured and what the reasons for that are?
I'll try to break up your question into smaller parts:
"I noticed that my projects usually end up with a HTML-file as a base and a *.js file which contains the methods, eventhandlers etc. This somewhat feels like programming spaghetti code and I can't think of how this could work with more complex projects."
Sounds like your OO background has you spoiled. Javascript won't force you to use it's prototypal inheritance, and neither will jQuery. Nevertheless, it is there. Douglas Crockford wrote a piece about moving from a classical OO-centric inheritance to the prototypal equivalent: Prototypal Inheritance in Javascript
"Usual jQuery-Tutorials are just showing trivial examples which work well with the "all methods into a single script-file"-approach."
Yes, putting all your code in one file will work fine for a small website or web-app, but it doesn't scale.
However this is no difference from putting all your C method declarations in one header and all the code in one source file. My point being that you don't have too.
I'd recommend you look at a script loader like RequireJS as a solution to this problem. In worst case there's still nothing wrong with putting your script tags inline in your HTML code but this also doesn't scale well.
"I also read somewhere, that it is better to provide just a big file because it is faster to load just one file instead of a lot small files."
Well ... yes, but this is negligible in most cases. Even if you do see a drop in performance, why treat your development code as your production? Use a compression tool such as YUI Compressor to compress and merge your JavaScript. Smaller load times without the pollution.
Final piece of advice: jQuery is not going to help you solve your JavaScript architecture problems any more than a dictionary will help you structure a sentence. (In other words, don't rely on jQuery examples to teach you good JavaScript practices).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know programming in general but always been doing either Delphi, VB 6 or C#.net! Now I must do web-dev and must do it fast! I haven't written a hello world in JavaScript yet and must learn jQuery because there are some charts that I must show in my web-app and looks like I must know JavaScript and jQuery to do that.
So I am looking for a jQuery resource that during its course or maybe at the first chapter gives us also a jump start on minimum JavaScript knowledge too. Some book or resource that I can hopefully sit and read through it in one day like 12 hours and after then learn enough to be able to use it and embed those darn charts and graphs into my web-app.
What do you suggest ?
The basics of Javascript as a language are actually fairly straightforward, particularly if you've got a background in several other languages as you have. You'll find it immediately familiar with curly braces and other syntax that you'll recognise from elsewhere.
If you've worked with C#, you will hopefully have been exposed to lambda functions or closures. These are very important in Javascript, where they are key for the event-driven code that drives most websites, and in particular if you're using a library like jQuery, where they are used for virtually everything. You need to get a strong handle on how these functions work if you're going to make head or tail of jQuery.
The other thing to be aware of is that Javascript's object handling works a bit differently to the other languages you's used to. There are similarities, but if you try to write your classes and objects in the way you're used to, you will get some unexpected results. See What type of language is JavaScript for more info on this.
Beyond that, I don't think you'll have a problem with the syntax.
The other thing to worry about is the DOM -- ie the browser's API which is accessed via Javascript. The DOM is not technically part of the Javascript language, but it is inextricably linked to it, and is as much part of the learning challenge as the language itself. jQuery abstracts a fair amount of the DOM away from you, but it still helps to know it.
Hope that helps get you started.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Learn JavaScript before learning JQuery?
I have read that thread and I still don't find any points convincing me that Javascript is a must-learn-before-jquery thing.
I think jquery is far more than just a javascript library, I would like to call it a redefinition of the dynamic language, the new javascript instead. The library writers clearly made the greatest hit here to change old JavaScript's face almost completely.
Javascript and Jquery are co-existing because Jquery is the javascript library and the fact that people support learning JS first before jquery is likely because they've been client side coders long before the jquery was out, WHICH CURRENTLY EASES THEIR INVESTIGATIONS INTO THE LANGUAGE FAR BETTER, psychologically, they certainly then say "Oh yes, procedural methodologies work greater".
For points concerning writing a function call via mouse/keyboard events, I still agree that javascript structures are preserved and need learning. But does this really make a big difference whether or not learning jquery first should be more beneficial at all ?
Ex:
function something()
{
//jquery code
}
////
<input type="..." onclick="something();"/>
Advice and corrections are required. Thank you so very much.
There are many reasons why its important to learn the native JavaScript, in addition to the jQuery Library:
jQuery is written in JavaScript, so if you ever run into a jQuery bug, or need to patch it, you will need to know the JavaScript
if you ever want to use jQuery efficiently, in many cases it's helpful to read the underlying JavaScript
it isn't guaranteed that jQuery will always be the best Library (something like Scriptaculous may one day surpass it), thus you shouldn't be library-dependent
in many cases you still need to run JavaScript inside of a jQuery function
jQuery may make many things simpler (accessing DOM elements), but in many cases it isn't required
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I occasionally write JavaScript code. I am interested in minifying it for better performance, but I don't plan to spend to much time on that, especially in testing the minified result.
I found this online service:
http://www.lotterypost.com/js-compress.aspx
So a couple questions:
Is it reliable?
Microsoft AJAX minifier vs. YUI Compressor, what's the best option?
Any other similar online tool to recommend (and why is it better than the above link)?
Google's Closure Compiler
is an excellent Javascript minifier and compiler. It analyzes the code and reports the detectable errors. It removes redundant space and unreferenced code, and renames objects to shortest possible names. You just need to compile together all Javascript files that belong to one HTML page.
That link you post happens to be the one that I use too.
Use the MS AJAX Minifer. It's way better than the yui one. besides:
http://stephenwalther.com/blog/archive/2009/10/16/using-the-new-microsoft-ajax-minifier.aspx:
The Microsoft Ajax team (I work on
this team) has been using this tool
internally for a number of years. For
example, we use the Microsoft Ajax
Minifier to minify the Microsoft Ajax
Library before publishing it.
Well if you don't trust me, run your source code (if you don't have an actual source code to test, just grab the source at http://code.jquery.com/jquery-1.6.2.js) through both and see which is more "minified".
==
Google has the Google Closure Compiler but it analyzes your code and removes unreferenced code (to furthur reduce the size of the resultant file). However usually this is not what you want because even though the functions/variables are not referenced within that file, it may be referenced from your other js files that make up your site)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For scripting on web browsers, the only option now is using javascript.
I wonder if Ruby ever could make it to the web browsers?
It's highly unlikely cause MS doesn't have any reasons for letting Ruby to become first class citizen, wouldn't that be bad for their current platform? I don't know how Apple sees it.
If Ruby can't be first class citizen in the browsers, how likely is it that a add-on could be installed on the browser, letting the browser execute Ruby also. In that way, we programmers could just use Ruby instead.
Your best bet is probably a "language converter" like:
http://rb2js.rubyforge.org
Honestly though I would just bite the bullet and learn Javascript. A plug-in could be created, but it would never catch on: businesses won't inconvenience their customers just so that their programmers can use the language of their choice.
I don't like JS that much. For a scripting language its way too much verbose, it suffers from bad design decisions that got into the ECMA standard... It has however some nice features which make it unique and powerful.
I wish the web was more agnostic with client-side languages, but its very unlikely, sadly.
If you want something that feels like Ruby you may try CoffeeScript. You write your code in CoffeeScript which then gets turned into JavaScript. It borrows a lot of ideas from Ruby and Python which makes a great mix.
http://jashkenas.github.com/coffee-script/
I am personally enjoying it very much.
It may not be in the near future or it may never be implemented as the browser scripting language. But people are playing around with that idea. Check out rubyinside.com, they seem to have a working demo. The last time I checked the demo page crashed the browser :(
But don't loose hope yet ;)
It's not exactly using Ruby as a replacement for Javascript, but you can run Ruby on Silverlight (and Moonlight, the Linux implementation of Silverlight).
No one can tell the future, but I'd say it's incredibly unlikely. Browser vendors aren't likely going to want to support multiple client side scripting languages (see the death of VBScript in the browser). Javascript fills the client side niche already so there's no reason to vendors to introduce a new language just so that there is an alternative syntax. 3rd party plugins aren't really a good solution either because users get no benefit from installing it (unlike something like Flash which can offer functionality that HTML/Javascript can't).
There are some Javascript libraries that try to emulate a Ruby style of coding -- for instance, JS.Class.