jQuery in Action 154
Michael J. Ross writes "As perhaps the only substantial computer language embedded inside of the major Web browsers, JavaScript has brought an unprecedented level of power to client-side programming for the Internet. Yet as a result of cross-browser incompatibilities and other problems, it has probably also resulted in an unprecedented number of headaches for Web developers. JavaScript libraries attempt to mitigate much of these difficulties. One of the most popular such libraries, jQuery, is explored in a book by Bear Bibeault and Yehuda Katz, titled jQuery in Action." Keep reading for the rest of Michael's review.
Released by Manning Publications on 7 February 2008, under the ISBNs 1933988355 and 978-1933988351, jQuery in Action attempts to cover a large amount of information within its 376 pages. The material is grouped into nine chapters: an introduction to jQuery; wrapped element sets; modifying element properties, attributes, styling, and content; browser event models, including jQuery's; animations and effects; jQuery utility functions; plug-ins; AJAX; and four powerful plug-ins. The book concludes with an appendix, which may be the best place to start reading in the book, because it reviews many of the key aspects of JavaScript upon which more advanced jQuery heavily relies. The authors assume that the reader has a solid understanding of JavaScript, and is familiar with the basics of AJAX
| jQuery in Action | |
| author | Bear Bibeault and Yehuda Katz |
| pages | 376 |
| publisher | Manning Publications |
| rating | 9/10 |
| reviewer | Michael J. Ross |
| ISBN | 978-1933988351 |
| summary | A well-crafted guide to jQuery. |
As an introduction to jQuery, the first chapter briefly presents the rationale behind jQuery and its contribution to "Unobtrusive JavaScript," which is essentially the long overdue separation of JavaScript and CSS code from HTML markup — that is to say, separating behavior from structure in Web pages. With this new approach to JavaScript, the resultant code may in some cases be a bit longer, but it is far more readable, maintainable, and robust. Anyone who has tried to decipher cryptic JavaScript interwoven with HTML, will appreciate this leap forward. However, after these first two sections, prior to starting with the details of jQuery and its syntax, the authors should have explained to the reader where to find jQuery and how to reference it within a page. This critical information is provided only in the chapter summary, almost as an afterthought. A reader skipping the chapter summary could easily miss it.
The second and third chapters lay the groundwork for what will follow. The former chapter explains how to specify and manipulate sets of elements on the Web page, known as "wrapped element sets." This is done using all of the selection methods supported by CSS 3, as well as some additional selection capabilities built into jQuery. The latter chapter explains how to manage the properties and attributes of page elements, and how to get and set attribute values and other attribute manipulation techniques. The authors show how jQuery gives programmers tremendous control over the HTML and CSS of their Web pages, which can be changed by creating and modifying elements, and wrapping them in new elements, as well as adding and removing class names within the HTML, thereby using the existing CSS code. On the other side of the same coin, styling can also be updated by getting and setting the styles themselves, thereby using the existing HTML code. The last section of the third chapter focuses on form elements, which have special properties within both HTML and jQuery.
Event handling is a key aspect of any GUI, and is the subject of Chapter 4, in which the authors describe the DOM event models — focusing on Levels 0 and 2 — and how the jQuery event model helps to neutralize the problems introduced by Internet Explorer (naturally) failing to follow industry standards in its implementation of the DOM Level 2 Event Model. The chapter concludes with an extended examination of some sample code — in this case an order page from the online menu of an imaginary Asian fusion restaurant.
The book shifts gears in its fifth chapter, which explains how to use animation and other effects to jazz up the Web page — such as fading images in and out, as well as smoothly resizing and moving elements on the page. For instance, the first application of these capabilities is in the form of a collapsible list, which is ideal for making lengthy vertical navigation menus far less space consuming. Chapter 6 arms the reader with an understanding of jQuery's many utility functions, which can be used to trim unneeded spaces from strings, iterate through collections and properties, filter and translate arrays, extend objects, load scripts dynamically, and determine the site visitor's user agent and box model. These functions add the capabilities to one's jQuery code; yet one can even extend jQuery itself, by using plug-ins created by other developers or by oneself. In Chapter 7, the authors explain how anyone can write custom utility functions, which they illustrate with a date formatting function. They also explain how-to create custom wrapper methods.
Although it has its detractors, Asynchronous JavaScript and XML (AJAX) has enabled a plethora of new ways to make Web pages respond faster to user events, without requiring the overhead of wholesale page reloads. AJAX is the topic of Chapter 8, and the authors begin with a review of how to make asynchronous requests using the JavaScript XHR object, thus enabling the page to communicate with the server. This can be used for loading content into page elements, making GET and POST requests, and more. Similar to the previous two chapters, this one ends with a detailed examination of sample code. The final chapter in the book begins with a brief overview of jQuery plug-ins, and then examines in detail four highly popular plug-ins for handling HTML forms, controlling the dimensions of elements, declaring element behavior prior to creating the elements themselves, and gaining even greater control over the user interface, such as dragging and dropping elements on the page.
Anyone interested in learning more about the book can consult the publisher's page, which offers a book description, excerpts from reviews, and links to pages containing the supplemental sections of the book, such as the table of contents. It also has the book's errata, of which there are listed (as of this writing) five in the second printing, and three from the previous printing. Two sample chapters (2 and 5) are offered, as well as all of the sample source code. The PDF version of the book can be purchased online, at a discount to the printed version; the two can also be purchased as a bundle. Lastly, there is an authors' forum, where readers are invited to post questions, almost all of which have been kindly answered why the authors.
jQuery in Action illustrates how the primary aim of programming frameworks is to encapsulate much of the details of the language being used, so the developer can focus on the higher-level purpose of the code they are creating, and not the minutia of syntax and, in the case of JavaScript, differences among browsers. The authors successfully demonstrate the major concepts, primarily through the use of what they refer to as "lab pages" — essentially detailed code samples, with explanations, beginning with the second chapter. These exemplify the spirit of Manning's "in Action" series of technical books, which recognizes that in computer programming — as with probably most every other field — the best way to learn is by doing, and in this case, seeing sample code in action. This also makes it easier for the reader to modify the given code and experiment with it, to confirm what they have learned, and perhaps discover something new. Most of the sample code for this book runs fine in a Web browser opening the HTML files, without having to be run on a local Web server.
This book should prove a favorite among jQuery developers. The authors zero in on the core components of the library, and explain everything clearly — providing thorough coverage, without excessive verbiage. They are forthright about the weaknesses of jQuery, just as much as its strengths. The book does not contain a large number of screenshots or other figures, but it does use those in conjunction with code snippets, tables, and command syntax summaries to help break up the text visually. The authors improve the readability of the material with a genuine sense of humor, yet without resorting to the silliness currently found in many books written by programmers.
There are few blemishes, and of those, none are major. Phrasing in a few instances could be confusing to the average reader, such as referring to functions as elements just a few paragraphs after mentioning CSS elements (in the "NOTE" on page 9). The chapter summaries add no value, and should be jettisoned. Also, they should not be used as a place to introduce information not even mentioned in the corresponding chapters, e.g., the jQuery download information noted above. Almost every chapter summary touched upon something that had not proceeded it; such material should be folded into the particular chapter proper. The chapter titles should be in title case, and not sentence case. On the other hand, some phrases are incorrectly put in title case, such as "Rich Internet Applications" — a phrase overused. There were only a few errata not already reported on the publisher's Web page, such as "it incursion" (page 15). As with many computer books nowadays, there is an excessive use of exclamation marks. In terms of the sample code, it is complete and quite handy for trying out the ideas discussed in the book, and learning by modifying it. However, the JavaScript portions of the code can be difficult to read, because most of the code is compressed, with almost no use of whitespace to enhance readability.
With its capable technical coverage, extensive use of sample code, and approachable style, jQuery in Action is a valuable resource for any Web developer seeking to maximize the power of JavaScript, and a must-have for anyone interested in learning jQuery.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase jQuery in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
If jQuery were a woman, I'd marry her (Score:2, Funny)
And then make her do all the hard work while I sit back and relax.
Vs. Mootools? (Score:4, Interesting)
No mention of jQuery versus other similar JS libraries? My company is considering switching from mootools to jQuery for new projects, but the only significant benefit I see is better documentation. So how does it stack up against the competition?
Re: (Score:2)
Forget both and use ext.js
Re:Vs. Mootools? (Score:4, Informative)
Re:Vs. Mootools? (Score:5, Informative)
That was my feeling too until I learned about how he licenses the code, and his views on what the GPL3 means for web applications.
http://extjs.com/products/license.php [extjs.com]
If you are writing an open source app then that's great but if you are going to use it at your company for a closed source project make sure they understand they need to buy a commercial license from the author.
Re: (Score:1)
Re: (Score:2)
Stay well away from Ext. They have demonstrated a willingness to sue anyone who even extends their code as a web app even if they don't distribute it.
It's like they believe that if PHP was under the GPL, that anyone coding an app in PHP should have to open source it. It simply doesn't follow from the license text. But they'll certainly try to bankrupt you with legal fees in the meantime if you don't buy a commercial license, even if the GPL says you should be able to use it.
Re:Vs. Mootools? (Score:4, Interesting)
I guess they argue that because JS is a client-side program, you have to send the JS parts of your web application to the user and are therefore distributing it just by letting anyone use it.
I'm not sure how the GPL works with respect to licensing parts of a webapp. Can you just distribute the JS parts under the GPL and keep the server-side closed source?
Seeing as you have to send the client the source code to allow them to run the javascript and it's effectively impossible to prevent them from re-using it somewhere else it's not such a big deal to allow your javascript code to be open sourced.
Re:Vs. Mootools? (Score:4, Informative)
I can't see anything on their webpage that indicates that they have a strange interpretation of the GPL v3.
I get the impression that they believe merely using ext JS on a public website is distribution. I would agree with that. Therefore, if you modify the code, and then distribute it, you have to release under GPL v3 to be "legal". I don't see anything wrong with that.
You don't have to modify the code, and therefore, you don't have any obligations.
In either case, you don't have to worry about the source code requirement, because the source code is being downloaded by the browser anyway.
Regarding server side code, that's different. You aren't distributing the code, you are merely presenting the results of the code. I understand that in the USA and Australia at least, that it is not possible to copy right the output of a program (at least not in general cases).
So, you can take WordPress (which is released under the GPL), and modify it all you want, and so long as your modifications stay on your server, you have no worries.
This "hole" in the GPL coverage is "closed" by the AGPL, which mandates that if you modify the code, and use it, then you have to offer a link to download the changed source code to anyone who accesses the program over a network. (Or something like that anyway, see section 13.)
The question of which is more appropriate, depends on who you consider the "user" to be, the public, or the web master.
Re: (Score:3, Interesting)
The problem is that they've previously argued that if you use the GPL version, the requirement extends to open sourcing the entire backend code to your webapp because it all becomes a derivative work of Ext.
I do note that they seem to have since changed their page so their opinion is less evident, but there was a huge row about it previously, both on Slashdot and on their forums.
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
ext is much larger than jquery. It takes longer to initialize the runtime environment. That may or may not be an issue depending on the application you are writing.
Re: (Score:3, Insightful)
but the only significant benefit I see is better documentation.
A big plus in my book.
Re:Vs. Mootools? (Score:5, Insightful)
I personally like jQuery (and jQueryUI) because it's more terse and elegant. It is not as self-documenting, but it does css selection much better than prototype (IMHO). Most importantly, it was very easy to tack onto our web-based internal applications by referencing a simple .js script (or two) and adding a few function calls to manipulate existing html/css. Finally, I found the libraries of widgets just much more compelling in jQuery (with the exception of grids).
Re:Vs. Mootools? (Score:5, Interesting)
I have not used Mootools. I was first exposed to jQuery when I was trying to integrate WYMEditor into my company's CMS. When we ran into an issue, where we needed to add a CSS class to some server-side-generated code that we could not touch, the answer from somebody on a forum was, "Just use jQuery," and I was shown a one-liner that did exactly what we needed. Not only that, it was instantly understandable. My initial reaction, having struggled with doing this manually in the past, was, "It can't be that easy." Of course, I have used it in countless ways since then. I personally find it quite self-documenting.
Re:Vs. Mootools? (Score:4, Interesting)
"I personally like jQuery (and jQueryUI) because it's more terse and elegant."
I have used prototype pretty extensively for years now. I recently made the switch to jQuery and have been doing quite a bit with it. jQuery UI is awesome. I have never been a fan of combining prototype with scriptaculous because that *really* bloats your pages. And you really cannot minify prototype, at least as far as I know. jQuery UI is extremely intuitive to use and is lightweight thanks to the awesome build-your-own-download site they have.
That said, I prefer prototype for straight ahead AJAX stuff, mainly for one reason: jQuery requires you to use the jQuery object. The prototype $() just returns a nice fully qualified object reference with which you can do all sorts of stuff. jQuery lets you do the same things, but requires you to learn all kinds of jQuery stuff. jQuery thus moves you one more layer away from using straight ahead javascript, which in turn makes your skills more about jQuery than the underlying language. That is A Bad Thing.
Re: (Score:2, Interesting)
the prototype.js $() function is super handy, but it is a poor citizen in many respects. Prototype alters the global JavaScript namespace by altering the default nature of objects provided by the browser (e.g. strings, arrays, etc)
This can cause headaches for legacy JS scripts or integration with other libraries.
JQuery (and Dojo for that matter) do not pollute the global namespace - and therefore integrate better with other JS solutions.
Re: (Score:2)
Yeah...I have heard that before. I honestly haven't made the effort to understand why this is true. Hasn't caused a problem for me yet, though. YMMV.
Re:Vs. Mootools? (Score:4, Informative)
If you're into grokking the underlying language, try reading John Resig's book [jspro.org] or his articles online [ejohn.org].
I've found that my desire to have a fundamental understanding of javascript, which kept me away from most of the popular libraries for quite a while, is one of the main reasons I love jQuery, and also that understanding jQuery and how it works has given me a much better fundamental understanding of javascript.
While jQuery does create a pretty big abstraction from the core DOM functions, it does so efficiently.
I'm confident that when I use jQuery to find a list of elements with a particular class for example, that I wouldn't be able to write something from scratch to achieve the same effect that would be substantially more resource efficient.
It's also, last I looked, the smallest download of any of the major js libraries.
Re: (Score:2)
"I've found that my desire to have a fundamental understanding of javascript, which kept me away from most of the popular libraries for quite a while, is one of the main reasons I love jQuery,"
Interesting point. Care to share one or two ways that jQuery helped you understand javascript better?
I'll be the first to admit I am still missing prototype and maybe that's why I haven't fully embraced jQuery yet. I do like its terseness and the small size, so I really *want* to like it.
Re: (Score:3, Informative)
I suppose it would more accurate to say learning how jQuery works has helped be better understand javascript, rather than simply using it.
The best example that comes to mind is the way that jQuery handles queuing functions to fire when the document is ready. I don't recall the specifics off the top of my head, but reading Resig's articles on that and other topics have really given me a better handle on the core concepts of javascript.
Re: (Score:2)
Yeah, you probably mean callbacks. And when you talk about callbacks, you often use closures. And anything that helps you grok javascript closures is A Good Thing.
Re: (Score:2)
Mootools allows for using traditional OOP concepts like "Class", "Implement", and Extend" in your JavaScript code. I haven't seem a similar mechanism in any other "lightweight" javascript library, including jQuery. I can think the same in my Java and JavaScript, while simplifying my code base by using inheritance and polymorphism. Having OOP in JavaScript might seem silly or unnecessary, but for large apps, it really helps. When I was coding a website that required drag and drop with validation that the input source could be dropped onto the drop target it saved me lots of time.
Javascript is inherently fully object oriented. It's a strange and terrifying beast if you're well used to the class-based system, but it has objects with abstraction, inheritance, encapsulation and polymorphism.
Re: (Score:2)
That being said: Jon Resig, the author of jquery did publish some fairly minimal class-like system [ejohn.org] on his blog that I found useful at times..
Re: (Score:3, Interesting)
Re: (Score:2, Informative)
Re: (Score:2)
To be more precise, it would $teer away the folk$.
Re: (Score:2)
Haven't you heard that "emrace, extend, extinguish" memo enough on Slashdot? You know, the one that appears in article tags every time MS either implements or supports some open standard in their new product, or reuse some OSS library or project.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It does mean Slashdot staff. Which, given the newness of this member ID, leads me to another question: Are you guys hiring? And if so, where do I apply?
Re: (Score:2)
The PHP developer job looks very interesting. Unfortunately for now I'll have to wait until I'm done school (or at least the summer) to apply... and also until I get my US visa, I suppose.
Re: (Score:3, Informative)
Amazingly. Not only is jQuery thoroughly documented, demos and examples are widely available. Also, the amount of code required to do something is drastically smaller (and therefore, faster to write) for simple stuff, without restricting your options when you want to do something more complex.
$.get('test.php', function(data) {
$('#div').html(data);
});
That (if I got it right off the top of my head) makes a GET request to the file test.php and dumps whatever test.php produced into
Re: (Score:2, Insightful)
No mention of jQuery versus other similar JS libraries? My company is considering switching from mootools to jQuery for new projects, but the only significant benefit I see is better documentation. So how does it stack up against the competition?
I've used jQuery, Mootools and Prototype/Scriptaculous extensively and I have to say jQuery is my favourite. I can't really compare to extjs since I haven't used it.
You're right, the documentation is much much better than the others that I've used. That alone IMO is a reason to use it.
Two more reasons:
GWT FTW (Score:4, Informative)
as a result of cross-browser incompatibilities and other problems, it has probably also resulted in an unprecedented number of headaches for Web developers. JavaScript libraries attempt to mitigate much of these difficulties.
IMHO GWT is the closest one to that goal. If you're a Java developer give it a go, if you're not, then GWT is the perfect reason to become one :)
Re: (Score:1)
I get the sense that GWT is a great way to build an app but a terrible way to add functionality to existing pages (because it wants you to do everything its way...). Is this way off base?
Re: (Score:1)
In the end I think that GWT is more suited to build something from scratch... but then again, it all depends on your needs...
Re:GWT FTW (Score:4, Interesting)
As a GWT developer I'd agree with the above statement. We're using it for all sorts of Javascript-generation tasks and it works really well - it's just that you need to understand the abstraction.
I consider it to be a strongly typed version of Javascript, rather than a full abstraction layer. It's just too leaky to cover up all the differences. You still need to understand IE's hasLayout and CSS shortcomings.
That said, if any of you know GWT inside and out and are looking for a job, we at dotspots.com are hiring (you'll figure out how to find us). :)
Re: (Score:1)
cappuccino and sproutcore are also hovering in the same vicinity as gwt.
Re: (Score:1)
Maybe cappuccino and sproutcore allow you to do some neat stuff pretty quickly, but when it comes to refactoring and debugging, nothing will help you more than the right tools (like eclipse). Do you know if you can use a good IDE to code sproutcor
Re: (Score:2)
Another big advantage is structured testing in JUnit across all browsers. You can run your build in Hudson, start VMs and test your code at a unit-level in IE6, IE7, FF, Safari, etc.
Sharing code between server and client isn't a guarantee. The GWT emulation of the java.* hierarchy is spotty and you end up having to emulate some of the less-common-path Java features in some rare cases. For the most part, well structured code runs fine on both client and server.
Re: (Score:2)
Was it GWT Special Edition? That would make anybody throw up.
what happened to javafx? (Score:5, Interesting)
Re: (Score:2)
JavaFX was yet another Flash-killer wannabe, but that niche is getting crowded already. Silverlight might just have a chance there, and mostly only because Microsoft is as big as it is, and can be really nasty when it wants to be (which is that case). But a dying company like Sun? Forget it.
Author's Name?? (Score:4, Funny)
Who names their kid "Bear"??
Ah well, could be worse, I guess. Coulda named him "Chicken" or "Goat".
Re: (Score:3, Funny)
It's all part of a theme of names. Notice that the co-author's name is Katz.
Re: (Score:2)
Sir Michael and Sally Grylls, for one. Apparently giving ridiculous names is a family tradition; Bear Grylls named one of his sons Marmaduke.
Re: (Score:1)
Re: (Score:2)
You could say he was clumsy and had bad breath...
Re: (Score:2)
A simple request (Score:4, Insightful)
Dear web developers,
PLEASE FOR THE LOVE OF GOD, don't use javascript unless there's a need. Keep the content separate from the interface. I see way to many people using javascript to mangle this golden rule.
Don't use it to hide the contents so you can throw up a "but you have cookies disabled and we can't track you."
Don't try and block off your page because your advertisers want to use javascript to enable a billion popups.
Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway.
Don't use it to load content; That's what CSS and XML are for and it renders faster anyway.
Don't try and use javascript to obfusciate or disable standard web features (like view source). It's not going to stop anyone who wants to make a copy and it'll piss off everyone else.
Don't make your entire site dependent on having javascript enabled. If you're worth your salt as a developer you can find a way to make that page render without enabling javascript. Sure, it may not have all the chrome and pretty-shiny on it, but remember that there's a lot of devices and a lot of browsers that use the web, as well as people who are color blind, blind altogether, or who use low-end systems, or cell phones, or PDAs, etc.
Re: (Score:2)
Don't use it to load content; That's what CSS and XML are for and it renders faster anyway.
So "don't use Ajax", is that it? You know, quite often reloading a div is a whole of a lot faster than refreshing an entire page.
Re: (Score:1)
Clarification: Stuffing your content into a .JAR and then calling that to display the content as an example. Reloading a div or twiddling a few page elements is not the same thing -- those should still render if jscript is disabled... but if the content isn't there because jscript is disabled that's a problem.
Re: (Score:2)
Did you just confuse JAVA and JavaScript, or have I misunderstood you?
Re: (Score:2, Troll)
So "don't use Ajax", is that it? You know, quite often reloading a div is a whole of a lot faster than refreshing an entire page.
I despise ajax. I agree it feels a need. But I'd rather the 'web' be the 'web', and and web applications be -something else-. Asynchronous Javascript and XML is a the ugliest kludge to make an application I have ever seen... its not designed for it, and it breaks all the time. Show me any AJAX app and I can bang on it for a few seconds and break it. Click too fast, too often, in t
Re: (Score:2)
AJAX isn't the problem - it's just broken code. The same thing happens with non-AJAX websites all the time. I'll click something that submits to the server, wait for a while, give up and click it again and it fails because it was already submitted.
Normal websites are virtually unusable on crappy wireless connections. You are waiting all the time. Well written apps like Google Docs/Google Reader handle crappy network connection situations much better.
Re: (Score:2)
AJAX isn't the problem - it's just broken code.
No its just the the browser DOM, event model, plus a scripting language happen to be a lousy platform for applications.
Well written apps like Google Docs/Google Reader handle crappy network connection situations much better.
But they are ALL utter crap compared to a client side application, even on a fantastic network, because the browser itself is a lousy application platform for modern apps. scheduling, multi-threading, and so on simply aren't supported. You c
Re: (Score:2)
Perhaps, but this is irrelevant to the question of when to use js or whether to use AJAX.
Its entirely relevant. Any time you choose to make an 'application' in AJAX, you have probably failed at correctly determining when to use AJAX.
A company like Google shouldn't be trying to make ajax apps like googledocs... they should be pushing better platforms to run googledocs on. Whether its 'moon/silverlight' or 'java' or whatever, and then building googledocs on top of that. Or going the route of citrix published
Re: (Score:2, Interesting)
I have the Web Developer add-on for Firefox and with a Ctrl+Shift+S, all CSS is broken/disabled. Does this mean I should not use CSS?
I've gone through various stages in web design. At one time I was in the "JS is evil crowd!". Now, I use JS to enhance the user's experience but the pages must not depend on JS.
I would recommend looking into DOJO [dojotoolkit.org]. Though jQuery is also working on Section 508 compliance. From what I recall, the guy who worked on Dojo's 508 compliance is now working on jQuery's though I cannot c
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2, Insightful)
IMO, a better idea is to design your code to enhance [wikipedia.org] progressively [alistapart.com] instead [accessites.org]. A subtle difference, but it's nevertheless worth mentioning. In essence it's designing the basics first and adding style and functionality on top of that, rather than designing the whole thing exactly how it's imagined to be then making sure it works for everybody else and creating fail-safes or degraded versions for the cases in which it doesn't.
Re:A simple request (Score:5, Informative)
Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway.
You ALWAYS should handle it on the backend regardless, but doing it on the front-end TOO isn't necessarily a bad idea; it takes some load off the backend, and saves the user waiting for a round-trip to the server to find out something simple is missing or whatever.
Re: (Score:2, Insightful)
Yes, but it shouldn't be necessary to have scripting enabled to submit the data in the first place, which was my point. If the jscript is formatting the data in a particular way that the backend script processes, such that a regular POST submission will fail (and I've seen this) -- it's bad form.
Re: (Score:2)
Your original post said, in no uncertain terms, NEVER USE JAVASCRIPT UNLESS YOU NEED TO. That was your main point, was it not?
Well I'm sorry but that's just wrong, there's nothing wrong with using Javascript to enhance the user experience, so long as it remains functional without it.
A better rule is: Never make your site DEPENDENT on Javascript unless you need to. Perhaps that's actually the point you were trying to make, but that's not how you phrased it.
Re: (Score:2)
Bill Clinton, is that you?
I disagree. Necessity is an objective and well defined term. Food, water, and oxygen are necessities of life. Javascript is a necessity for, say, a drop down menu working in IE6 due to lack of proper :hover support.
Something like client-side validation, however is not a necessity. According to your stated position, that means it should never be used. Period. But that's asinine, there's nothing wrong with client-side va
Re: (Score:2)
If the jscript is formatting the data in a particular way that the backend script processes, such that a regular POST submission will fail (and I've seen this) -- it's bad form.
And moreover, it's a bad <form>.
Re:A simple request (Score:4, Insightful)
Script should be used to check POST submissions, before they are rechecked sever side. Saves so many round trips.
Of course, if we had Forms 2.0 and the ability to add a regex to form inputs, this tedious task could be done by the browser saving a whole bunch of script.
Re: (Score:1)
Should != Must. That's my only point.
Re:A simple request (Score:4, Insightful)
Checking the form submission in script is like the sign outside a stadium that says, "don't bring knives into the stadium."
Checking the form submission on the server side is the burly guy with the metal detector at the entrance.
The latter can do the job all by himself. The former, by itself, can't be trusted - but the idea of it is to (hopefully) cut down on the other's workload a bit.
Re: (Score:2)
I think girlintraining's original point was, continuing your analogy, that at some stadiums illiterate people cannot even approach the burly guy with the metal detector; ie with js off you should at least have the chance to submit your data.
Re: (Score:3, Insightful)
Of course, if we had Forms 2.0 and the ability to add a regex to form inputs, this
tedious task could be done by the browser saving a whole bunch of script.
yeah, that's a great idea. what's stopping me from feeding malformed data to your silly app using CURL or a plain socket on 80? people that try to break your app won't be following any "2.0" rules. and many "developers" already fall for this by relying only on JS validation.
I like JS when it's actually useful (hint: Google shit), but I don't like it people have forms with no submit button, and just a normal button with an onclick event. hitting enter anywhere in the form won't submit just as no JS support
Re:A simple request (Score:4, Insightful)
Girlintraining also seems to be developerintraining...
Some of your points make sense, I think most would agree about the futility in trying to lock down right clicks and such.
But there's a lot here that's simply wrong.
Not sanitizing content on the client side? You're right, it should be done on the server side. That's non negotiable. But it should also be done on the client side. It gives users immediate feedback and it prevents a wasted round-trip to the server. There are wrong ways to do this (alert() for example) but it's a must-have.
And your comments about hiding content, loading content, cookies and JS-dependance miss the point entirely: The goal here is graceful degradation.
Why am I going to cripple usability on a site by not supporting JS just because some luddites have it disabled? There's no reason you can't build a UI that relies on JS but degrades gracefully when it's not available, even if that means certain features being disabled.
Not to mention, some of your comments make me wonder if you've ever actually done any of this. How, exactly, is CSS and XML going to provide loading and reloading content on-demand the way JS can?
Furthermore, using JS does not, at all, mean mingling content and interface. Just because it's all composed in the browser as a single page doesn't mean it's developed that way.
Development is about nuance. Your "JS is bad" theory displays no nuance whatsoever.
Re: (Score:1)
Not sanitizing content on the client side? You're right, it should be done on the server side. That's non negotiable. But it should also be done on the client side.
There's no reason you can't build a UI that relies on JS but degrades gracefully when it's not available, even if that means certain features being disabled.
So you're agreeing with me that you should still be able to submit data to a server via a POST submission when jscript is disabled (ie, degrades gracefully)? I think you mistook my points -- which is exactly about failing gracefully. You're adding a feature to save the user time, and that's a good thing. But if the user doesn't want to use jscript (for a multitude of reasons, including because it isn't available on their browser) -- they should still be able to submit a POST query and get useful results bac
Re: (Score:1, Redundant)
Re: (Score:2, Informative)
they should still be able to submit a POST query and get useful results back.
I'm a bit confused by this. You do realize it's entirely possible to have client-side error checking on a form AND have it still submit to the server(for server-side error checking) if javascript is disabled, right?
What you are describing is a problem with people designing bad client-side checking, not a problem inherent to client-side checking itself.
Googlebot is a NoScript user (Score:2)
Totally agree, and just to add one extra point: if your site requires javascript to make the content appear, the single most important visitor to your site, the Googlebot, won't see it.
Re: (Score:2)
Somebody better feed Grandpa his oatmeal.
Re: (Score:2)
Does he deserve it for degrading gracefully?
Re: (Score:3, Insightful)
"Keep the content separate from the interface."
Great! I like pork chops! What does that have to do with the subject at hand?
Javascript is neither content nor interface. Javascript, HTML, and CSS are more like a MVC-type setup.
Javascript is great, and while I do agree with some of your rules, they really have more to do with *what* you use javascript for, not whether you should use it. Honestly, I worry about people who are *still* scared of javascript and AJAX. These are usually people who do not under
Re: (Score:2)
Great! I like pork chops! What does that have to do with the subject at hand?
Worse. One of the whole points of jQuery is that it (a) makes it practical/easy to do js in this "right way" (b) furthermore, makes it difficult to do it any other way!
You build something that works fine without any js, for example links that go to <a href="page.php?id=4" class="tablink">, and then $(document).ready() gives you a functional place to remove those links and attach your
$('.tablink).click(function(){
// put in your funky ajax/dhtml way of showing the stuff in the id specified in thi
Re: (Score:2)
Did you mean to reply to my post? It doesn't seem related.
That said, I agree with you. Event binding is awesome and libs like jQuery make it easy. It's the last step in making sure that CSS, HTML, and Javascript are all loosely coupled and therefore potentially independent.
powerful but obtuse (Score:3, Insightful)
web programming itself is completely misunderstood. HTML is a "display" mechanism, and people believe it to be "programmable".
then along comes javascript, one of the most fundamentally powerful yet utterly obtuse programming languages, and it gets "thrown in" amongst the "display" mechanism.
we've known for years that mixing HTML into a programming language and vice-versa is a bad idea: you only have to look at how people get themselves into an awful mess with PHP to appreciate that. in that respect, javas
Re: (Score:2)
JavaScript is, at worst, as high-level as Java is. I would actually say it's more high-level (in the same way that Python is more high-level).
In particular, there's nothing inherent to JavaScript that makes an "AJAX mess". You'd still get that if you used Python or Ruby.
Re: (Score:3, Interesting)
Don't use it to hide the contents so you can throw up a "but you have cookies disabled and we can't track you."
Thankfully I've only run into this a couple times, and have never returned
Don't try and block off your page because your advertisers want to use javascript to enable a billion popups.
The keyword advertising and the click-anywhere-on-the-page-to-open-a-popup advertising are the worst
Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway.
After reading the other comments and your clarifications I have to agree on your point (of forcing JS POST sanitation and refusing to post otherwise). I've even run into a couple cases where there is no 'submit' button, just a button that runs some JS that will do the form submit...
Don't use it to load content; That's what CSS and XML are for and it renders faster anyway.
I'd agree for cases where the entire page content is JS
Re: (Score:2)
Re: (Score:2)
You forgot:
Don't load your styles with javascript. If you think I'm going to whitelist your otherwise functional site because it looks ugly then... you're probably right but hell, why should I have to? Is a <link> tag so hard to write?
Re: (Score:2)
I have given up trying to get along with Chrome because I can't disable all the unpleasant javascript I never realised was out there. Back to Firefox and NoScript for me.
Put blame where blame is due (Score:2)
Re: (Score:2)
These days, cross-browser issues fall into two camps:
- IE and everyone else
- Minor intepretations of the spec that are easy to fix
The first ones are pretty insidious - you end up tweaking things so far for IE that it breaks the standard browsers. Examples: hasLayout, iframe contentDocument, etc.
The second ones are easy to fix. Usually it's a corner case anyways.
Comment removed (Score:3, Interesting)
Could you at least explain what it is (Score:1, Redundant)
This review would be much more useful if it came out and said what jQuery is, instead of assuming the reader already knows. All I can gather is that is has to do with not interleaving javascript, CSS and html.
Re: (Score:2)
Re: (Score:2)
The opening paragraph describes it as a popular cross-browser Javascript library. The rest of the review describes in detail what you can do with it.
You could also Google it and go to their homepage or Wiki article for more info.
It's a book review, not an article on jQuery. He provided plenty of context imho.
jQuery is very well thought-out (Score:5, Interesting)
With that experience, I became not just a convert, but a jQuery software evangelist at the Federal Government agency where I work.
The next intractable problem that jQuery solved here was the old mouseover/mouseout problems with DHTML menus (that sometimes stayed open in some browsers). jQuery's ability to simulate one-event-only mouseenter/mouseleave in all modern browsers solved that problem in only one line of code too. I haven't seen our shared DHTML help menu stay open ever since.
The ability to bind multiple event handlers to the exact same event is really going to help us refactor and stratify our data validation JS. Everything's getting better and faster and simpler, all at the same time.
My biggest complaint has been the lack of books explaining the IDEA of how jQuery works. I've had to survive largely by reading the jQuery source code. I bought this book (the one reviewed above), plus Learning jQuery and jQuery Reference Guide, and not one of them has adequately explained how the animation queue works. I believe that I now understand the animation queue better than the authors of those 3 books do. Or better than their ability to explain, at least.
What I'm saying is, this book and the other 2 constitute a good first wave of jQuery books, but they don't do justice to this marvelously well thought-out JavaScript Object.
Re: (Score:2)
Heh, I hear you on the animation stuff. Took me a while to figure out why sliding menus were getting truncated when I came back to them... it's because stop()'ing the animation midway on mouseout doesn't reset the object to its start or end state, you have to do that yourself. (Which makes sense when you think about it, but this point could be documented a bit better)
Javascript Compilers: AJAX in Java, Python, Ruby (Score:2)
Javascript is an awful language to develop in, yet it is also incredibly powerful.
That makes it a better target as an "intermediate" language - as human-readable assembler, if you will.
There are two projects that allow web browsers to be programmed in much more understandable languages:
1) GWT http://code.google.com/gwt [google.com] which is a java-to-javascript compiler and AJAX library
2) Pyjamas http://pyjs.org/ [pyjs.org] which is a python-to-javascript compiler and AJAX library
by using this kind of technology, not only do you g
Re: (Score:2)
..that we can get through a SINGLE /. posting without some comment bashing Microsoft or one of its products??
In an article about web development, you expect the fact IE sucks to not be brought up? That would be like talking about WWII without talking about Hitler or any of the bad things he did.
Re: (Score:2)
Re: (Score:2)