Slashdot Mirror


jQuery in Action

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. 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. 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

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.

154 comments

  1. If jQuery were a woman, I'd marry her by Anonymous Coward · · Score: 2, Funny

    And then make her do all the hard work while I sit back and relax.

  2. Vs. Mootools? by truthsearch · · Score: 3, 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?

    1. Re:Vs. Mootools? by encoderer · · Score: 1

      Forget both and use ext.js

    2. Re:Vs. Mootools? by Frosty+Piss · · Score: 2, Insightful

      but the only significant benefit I see is better documentation.

      A big plus in my book.

      --
      If you want news from today, you have to come back tomorrow.
    3. Re:Vs. Mootools? by xmuskrat · · Score: 4, Informative

      I might use ext for an intranet project, but it seems to be a big pain on doing things the way I want to put them together. It's annoying to have so much formatting in JSON where if you miss a comma somewhere, the page doesn't even render let alone handle the error. I think the core of a good JS library is a great, fast CSS selector model and extensive plugin support. JQuery helps me write clean, easily readable code that almost always is reusable in a different situation.

      --
      activestudios web design
    4. Re:Vs. Mootools? by rsborg · · Score: 4, Insightful

      No mention of jQuery versus other similar JS libraries?

      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).

      --
      Make sure everyone's vote counts: Verified Voting
    5. Re:Vs. Mootools? by rgigger · · 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

      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.

    6. Re:Vs. Mootools? by Sulihin · · Score: 1

      Seconded. I'm personaly extremely unclear on how the GPLv3 applies to something like a js script. Certainly it isn't the intent of the license that running said script inside IE applies the license to IE, but I've yet to find actual wording that explains why. Then in the context of a rather complex web application, do I have to GPL3 the whole application including all the tiers, or just the web tier or just the js? I mean really an html/js application is already open source by the nature of it's use. But what about the jsps or servlets that produce the html/js? I really try to avoid FUD, but when I was looking into ext.js the UD was unavoidable for me... so I stuck with mootools.

    7. Re:Vs. Mootools? by Teilo · · Score: 4, 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.

      --
      Mir tut es leid, Menschen daß Einfältigfehlersuchenbaumfolgendenaffen sind.
    8. Re:Vs. Mootools? by anomalous+cohort · · Score: 2, Interesting

      Well, this might steer you away from jQuery but it looks like Microsoft will be using jQuery under the covers for its future ASP.NET AJAX technology offerings.

    9. Re:Vs. Mootools? by hobo+sapiens · · Score: 3, 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.

      --
      blah blah blah
    10. Re:Vs. Mootools? by naoursla · · Score: 2, 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.

    11. Re:Vs. Mootools? by z0ph4r · · Score: 1

      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.

    12. Re:Vs. Mootools? by Anonymous Coward · · Score: 0

      No mention of jQuery versus other similar JS libraries?

      uh, well its a jquery book review not a js library shootout.

    13. Re:Vs. Mootools? by Mr.+DOS · · 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 an element with the ID "div".

      You specifically mentioned Mootools. I used it (and liked it) for a while, but I eventually got frustrated with the lack of documentation and the amount of JavaScript it took to get anything done. I really encourage you to take a shot at jQuery just to see how it matches up.

      One thing that did take me a while to get used to is the non-Prototype-like selectors: if you're selecting an ID, you can't just do $('el'); you've got to do $('#el'). However, this really simplifies things if you've got to select by class ( $('.class') ).

            --- Mr. DOS

    14. Re:Vs. Mootools? by olliM · · Score: 1
      More precisely, they integrate jquery with asp.net, provide intellisense etc. See:

      The old asp.net ajax components are still there, but since one of the big benefits of jQuery is that it plays nice with other libraries, you can use either one or both on the same page.

    15. Re:Vs. Mootools? by robbrit · · 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:

      • I find that with jQuery you tend to write less code than you do with Mootools or Prototype because of the jQuery object and selectors.
      • I find you can do client-side processing more easily. I've been working on is a web app that let's you filter through a large amount of data. I've started to attach things to pieces of data using hidden divs and/or classes, and then with jQuery use selectors to apply filters instead of having to make requests back to the server and get SQL to filter them. Takes a huge load off of your databases. You can do this with the other JS libraries, it's just very elegant with jQuery selectors: $(".user .male").hide() will filter out any male users from the list.

      There are reasons not to use it too. It is higher level, so if you're old school and want to do things the old school way, then you'll probably have to fight a bit with jQuery to do it. When I first tried jQuery I hated it because it wouldn't let me do things the way I always had. However after you get used to it, I think it is an investment well made.

    16. Re:Vs. Mootools? by Anonymous Coward · · 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.

    17. Re:Vs. Mootools? by TheSpoom · · Score: 1

      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.

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    18. Re:Vs. Mootools? by aj50 · · Score: 3, 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.

      --
      I wish to remain anomalous
    19. Re:Vs. Mootools? by drpimp · · Score: 2, Informative

      I recently just added the intellisense for my ASP.NET MVC project I am working on. My only question is the some what (IMHO) hackish way to have to include a vsdoc.js file in the project, or adding some if(false) {} ASP logic to get the intellisense to work thinking it included the javascript file for view pages if your actual jquery javascript src is in the site.master. Not to mention if you have prototype used in your project as well it will not work as expected. You end up not being able to use the shortcut $() nor if you make a noConflict alias $j(). But if you do something like $j = jQuery; then it will start to work again. Oh and you must be using the NON-minified version to get any sort of details of the parameters. I know it's minified and that the reason why, but if anyone else has that problem just thought I'd point that out.

      --
      -- Brought to you by Carl's JR
    20. Re:Vs. Mootools? by f1vlad · · Score: 1

      Why would this steer away folks?

      --
      o_O
    21. Re:Vs. Mootools? by grahamd0 · · Score: 3, Informative

      If you're into grokking the underlying language, try reading John Resig's book or his articles online.

      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.

    22. Re:Vs. Mootools? by Anonymous Coward · · Score: 0

      I'm not sure how the GPL works with respect to licensing parts of a webapp.

      It doesn't. According to the FSF, the GPL isn't a meaningful license for webapps. That's what the AGPL is for.

    23. Re:Vs. Mootools? by grahamd0 · · Score: 1

      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.

    24. Re:Vs. Mootools? by Mozk · · Score: 1

      Off-topic, but what is that Slashdot badge next to your username? I couldn't find anything in the FAQ.

      --
      No existe.
    25. Re:Vs. Mootools? by hobo+sapiens · · Score: 1

      "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.

      --
      blah blah blah
    26. Re:Vs. Mootools? by beav007 · · Score: 1

      I think that means that f1vlad is a subscriber (that is, they pay money to be able to post "fr0sty p1ss" before regular readers see the articles).

    27. Re:Vs. Mootools? by Anonymous Coward · · Score: 0

      The frameworks satisfy different needs.

      ext is good if you want an end product that looks like a desktop app. But it can be too much for many applications.

      jQuery is usually the way to go to add those extra useful features to your website.

    28. Re:Vs. Mootools? by Anonymous Coward · · Score: 0

      I would say jquery has a larger user base now compared to mootools and good documentation. Regarding licensing you guys are looking at extjs licensing that's not jquery.

    29. Re:Vs. Mootools? by Mozk · · Score: 1

      That's what the asterisk is for, though. And it just seems unlikely to me that a user with an id over 1.2 million would subscribe (I'm not claming that mine is low or anything).

      --
      No existe.
    30. Re:Vs. Mootools? by grahamd0 · · Score: 2, 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.

    31. Re:Vs. Mootools? by xmuskrat · · Score: 2, Interesting

      That's pretty sad since that they extended upon Yahoo's JavaScript library, YUI. That's how they got the Ext name.

      --
      activestudios web design
    32. Re:Vs. Mootools? by Anonymous Coward · · Score: 0

      simple answer -- yes

    33. Re:Vs. Mootools? by beav007 · · Score: 1

      Hmmm. Good question then. I've seen a couple of them. /. staff maybe?

    34. Re:Vs. Mootools? by hobo+sapiens · · Score: 1

      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.

      --
      blah blah blah
    35. Re:Vs. Mootools? by hobo+sapiens · · Score: 1

      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.

      --
      blah blah blah
    36. Re:Vs. Mootools? by thebjorn · · Score: 1

      $.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 an element with the ID "div".

      Isn't that the same as

      $('#div').load('test.php');

      ?

    37. Re:Vs. Mootools? by apathy+maybe · · Score: 3, 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.

      --
      I wank in the shower.
    38. Re:Vs. Mootools? by TheSpoom · · Score: 2, 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.

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    39. Re:Vs. Mootools? by TheSpoom · · Score: 1

      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?

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    40. Re:Vs. Mootools? by shutdown+-p+now · · Score: 1

      Why would this steer away folks?

      To be more precise, it would $teer away the folk$.

    41. Re:Vs. Mootools? by f1vlad · · Score: 1

      I get it. I do not get, however, how many fail to see that M$ will actually help jQuery, and that is not a bad thing in my mind.

      --
      o_O
    42. Re:Vs. Mootools? by f1vlad · · Score: 1

      Yes, in fact we do. Check out the bottom of this very page. In the footer there's a link to corporate website.

      --
      o_O
    43. Re:Vs. Mootools? by Mr.+DOS · · Score: 1

      I didn't know you could do that - thanks for the tip!

            --- Mr. DOS

    44. Re:Vs. Mootools? by shutdown+-p+now · · Score: 1

      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.

    45. Re:Vs. Mootools? by TheSpoom · · Score: 1

      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.

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    46. Re:Vs. Mootools? by fforw · · Score: 1
      I'm not too keen on trying to push class based inheritance into javascript because it usually ends up inelegant and bloated and often ignores better solutions in the javascript world (interfaces?? just stick to duck typing)..

      That being said: Jon Resig, the author of jquery did publish some fairly minimal class-like system on his blog that I found useful at times..

      --
      while (!asleep()) sheep++
    47. Re:Vs. Mootools? by f1vlad · · Score: 1

      What visa are you thinking about obtaining? If it is H1B, It may not be worth it anymore.

      --
      o_O
  3. GWT FTW by darkvad0r · · 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 :)

    1. Re:GWT FTW by maxume · · 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?

      --
      Nerd rage is the funniest rage.
    2. Re:GWT FTW by Anonymous Coward · · Score: 0

      Ive never heard of GWT, but honest to say, I just threw up in my mouth after reading about it.

    3. Re:GWT FTW by larry+bagina · · Score: 1

      cappuccino and sproutcore are also hovering in the same vicinity as gwt.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    4. Re:GWT FTW by darkvad0r · · Score: 1

      Well, you can add GWT functionality to existing pages but I consider that as an advanced GWT technique as you have to really know how all of it works and comes together to do it correctly.
      In the end I think that GWT is more suited to build something from scratch... but then again, it all depends on your needs...

    5. Re:GWT FTW by Rayban · · Score: 3, 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). :)

      --
      æeee!
    6. Re:GWT FTW by darkvad0r · · Score: 1

      I think most of the power of GWT comes from the fact that you can use a Java IDE to write and refactor your code. Not to mention the fact that having all of your code base in one language (in this case Java) is a big acceptance factor in an enterprise environment.
      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 sproutcore or cappuccino ?

    7. Re:GWT FTW by Rayban · · Score: 1

      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.

      --
      æeee!
    8. Re:GWT FTW by larry+bagina · · Score: 1

      cappuccino has XCode support.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    9. Re:GWT FTW by Anonymous Coward · · Score: 0

      Not entirely true... You can easily create a div somewhere on the page and tell GWT to live inside it to quickly add GWT to an existing site.

      Additionally, if your existing layout is well defined, it isn't too hard to write helper functions to replace parts of the page client side. You just lose a lot of the cool layout tools if you are trying to embed new widgets in an existing layout.

      If you just want to add javascript handlers to the existing elements, it is much harder. Your best bet is to write as much of the code in GWT and then just add a 'publish' function to map the real GWT function to a visible javascript function. Force all of the old code through one or more of these published functions.

      I'd highly recommend just removing the existing elements client side and replacing them with GWT widgets instead.

    10. Re:GWT FTW by Hognoxious · · Score: 1

      Ive never heard of GWT, but honest to say, I just threw up in my mouth after reading about it.

      Was it GWT Special Edition? That would make anybody throw up.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    11. Re:GWT FTW by Anonymous Coward · · Score: 0

      We have used GWT to great success in a fat-client re-write to the web. We were able to duplicate nearly all of the fat-client feel with the advantages of a web application deployment.

  4. Anonymous Coward by Anonymous Coward · · Score: 0

    What about MooTools? For anything UI related, Moo is the way to go.

  5. what happened to javafx? by peter303 · · Score: 4, Interesting

    Client-side scripting java-syntax language seamlessly compiled into Java and supported by Sun. Supposed to solve the issue of those third party scripting languages out there.

    1. Re:what happened to javafx? by shutdown+-p+now · · Score: 1

      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.

  6. Author's Name?? by TheNecromancer · · Score: 3, Funny

    Who names their kid "Bear"??

    Ah well, could be worse, I guess. Coulda named him "Chicken" or "Goat".

    --
    Attention all planets of the Solar Federation! We have assumed control! - Neil Peart
    1. Re:Author's Name?? by Anonymous Coward · · Score: 0

      The composer for the Battlestar Gallactica soundtrack is named Bear, too. It might be common in some Native American cultures, although Bibeault doesn't sound like a good match for that.

    2. Re:Author's Name?? by Zathain+Sicarius · · Score: 3, Funny

      It's all part of a theme of names. Notice that the co-author's name is Katz.

    3. Re:Author's Name?? by Chris+Mattern · · Score: 1

      Who names their kid "Bear"??

      Sir Michael and Sally Grylls, for one. Apparently giving ridiculous names is a family tradition; Bear Grylls named one of his sons Marmaduke.

    4. Re:Author's Name?? by xmuskrat · · Score: 1

      What about Bear Grylls? He served three years with the Special Air Service, a special forces unit of the British army. During his service, he broke his back in three places in a parachuting accident over Southern Africa and still hiked ten miles on his fingertips all the way to Paris, France. He has drank his own pee and eaten about 100 species in situations of life or death survival. I don't think he'd look kindly at you saying he's a chicken.

      --
      activestudios web design
    5. Re:Author's Name?? by Anonymous Coward · · Score: 0

      What about Bear Grylls? He served three years with the Special Air Service, a special forces unit of the British army. During his service, he broke his back in three places in a parachuting accident over Southern Africa and still hiked ten miles on his fingertips all the way to Paris, France. He has drank his own pee and eaten about 100 species in situations of life or death survival. I don't think he'd look kindly at you saying he's a chicken.

      Yeah, and Bear Grylls simply walks into Mordor.
      Bear Grylls is is the pen name that Chuck Norris uses when he writes jokes about himself on the internet.

    6. Re:Author's Name?? by Foofoobar · · Score: 1

      Hyper Sonic Deathgoat Jones. The name for my next child. I will be registering him for kindergarten class as such.

      --
      This is my sig. There are many like it but this one is mine.
    7. Re:Author's Name?? by larry+bagina · · Score: 0, Flamebait

      Who names their kid "Bear"??

      somebody who likes gay sex with hairy men

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    8. Re:Author's Name?? by Anonymous Coward · · Score: 0

      Isn't he the guy that stays in hotels when he is supposed to be living off the land for a t.v. show?

      I guess to him roughing it is a 3 star hotel rather than a 4 or 5 star.

    9. Re:Author's Name?? by ShieldW0lf · · Score: 1

      What about Bear Grylls? He served three years with the Special Air Service, a special forces unit of the British army. During his service, he broke his back in three places in a parachuting accident over Southern Africa and still hiked ten miles on his fingertips all the way to Paris, France. He has drank his own pee and eaten about 100 species in situations of life or death survival. I don't think he'd look kindly at you saying he's a chicken.

      You could say he was clumsy and had bad breath...

      --
      -1 Uncomfortable Truth
  7. A simple request by girlintraining · · 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.

    --
    #fuckbeta #iamslashdot #dicemustdie
    1. Re:A simple request by kalirion · · Score: 1

      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.

    2. Re:A simple request by gandhi_2 · · Score: 2, Informative

      The jQuery authors tell you to design your code to "fail gracefully". Let the content still be accessible even if the stylesheet is missing or the js doesn't run.

    3. Re:A simple request by vux984 · · Score: 4, 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.

    4. Re:A simple request by sakdoctor · · Score: 3, 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.

    5. Re:A simple request by encoderer · · Score: 3, 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.

    6. Re:A simple request by shivamib · · Score: 0

      No, he means things way, way more fugly.

      The rule of thumb would be: don't use javascript unless you really need it.

      One important thing to keep in mind is to keep your app as resourceful as possible, as the API really pays off later. Don't add a method that can only be called from javascript, provide necessary fallbacks.

      Ruby / Rails is really good for this kind of setup. And personally I've always liked prototypejs.

    7. Re:A simple request by girlintraining · · 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.

      --
      #fuckbeta #iamslashdot #dicemustdie
    8. Re:A simple request by vux984 · · Score: 1, 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 too many places and you'll break it every time. Either it will hang, or render wrong, or you'll confuse it some other way.

    9. Re:A simple request by girlintraining · · 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.

      --
      #fuckbeta #iamslashdot #dicemustdie
    10. Re:A simple request by girlintraining · · Score: 1

      Should != Must. That's my only point.

      --
      #fuckbeta #iamslashdot #dicemustdie
    11. Re:A simple request by smallshot · · Score: 0, Insightful

      i disagree partly. I ONLY check post on the client IF I feel the need to stop the post and display an error message immediately. Otherwise i see it as wasted code prone to bugs because if you check your post on the client side, you ALSO have to check it on the server side anyway (even if only for security reasons) which gives you 2 different copies of the same code that you have to make changes to. twice as many places to make mistakes and create security holes.

    12. Re:A simple request by IL-CSIXTY4 · · Score: 1

      I think the OP is referring to a deeper issue than AJAX itself. There are sites out there which use AJAX to simulate an iframe. There's no refresh when going to a new page, but your URL never changes, either. So, you can't bookmark an inner page, and I'm sure Google can't crawl a page like that.

    13. Re:A simple request by girlintraining · · 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 back.

      I never said "JS is bad", and I didn't call it a theory either. But I believe accessibility is more important that features or spiffy-shiny. If JS is a requirement to use your website in a meaningful way, you had better have a strong case for that design... And frankly, 99% of what I see on the web is not a strong case for this (despite it being required). And lastly, I'm not a developer in training... I do this professionally and like everyone I have some (achem) religious beliefs about my work. One of my commandments is accessibility is king.

      --
      #fuckbeta #iamslashdot #dicemustdie
    14. Re:A simple request by Rayban · · Score: 1

      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.

      --
      æeee!
    15. Re:A simple request by jbezorg · · 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. 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 cite the source off the top of my head (A catch 22. I do remember it was on the person-in-question's blog).

      Dojo Accessibility Compliance
      People familiar with accessibility and accessibility guidelines such as the W3C's Web Content Accessibility Guidelines, and the US Section 508 requirements, are often interested in a compliance statement for Dojo. While Dojo does not make an explicit claim of compliance to W3C WCAG 2.0 Level A or to US Section 508, every attempt has been made to meet those guidelines and to make the 1.0 and future versions of the core widget set, dijit, accessible to keyboard, low vision and assistive technology users. Keyboard support has been added to all of the dijit widgets and is supported in Firefox 2 & 3 on Mac and Windows as well as IE 6 & 7 on Windows (Safari and Opera do not yet support full keyboard navigation of scripted content). All of the dijit widgets support font resizing and work in Windows High Contrast mode to support low vision users. Dijit utilizes the under development W3C Accessible Rich Internet Applications (ARIA) specification so that all dijit widgets are accessible using the latest versions of the JAWS or Window-Eyes screen readers with Firefox 3. Additional WCAG 2.0 and US Section 508 compliance details are provided below.

      --
      I've lost all my marbles except one & It's fun to test angular & centripetal acceleration in my skull
    16. Re:A simple request by Bill,+Shooter+of+Bul · · Score: 0, Redundant

      Usability is king. Accessibility is duke. Over all your points do make some sense, but only after your follow ups to obvious criticisms.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    17. Re:A simple request by Teilo · · Score: 1

      Somebody better feed Grandpa his oatmeal.

      --
      Mir tut es leid, Menschen daß Einfältigfehlersuchenbaumfolgendenaffen sind.
    18. Re:A simple request by Anonymous Coward · · 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.

    19. Re:A simple request by Anonymous Coward · · Score: 0

      You've got to love people this presumptuous. *retches*

    20. Re:A simple request by hobo+sapiens · · Score: 2, 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 understand said technologies.

      --
      blah blah blah
    21. Re:A simple request by Frools · · Score: 1

      Yeah those sites are annoying, if you really must do that the very least you can do is use anchors to allow you to link/bookmark directly aswell.
      As in www.domain.com/index.html#page3 and then use either server side scripting or JS to pull in the right page when first loaded.

    22. Re:A simple request by SirJorgelOfBorgel · · Score: 1

      Does he deserve it for degrading gracefully?

    23. Re:A simple request by chaim79 · · Score: 2, 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 loaded, the HTML you get is an empty DIV and a few headers and CSS files. Those sites take forever to really load and degrade to something even worse on bad connections. However using JS to dynamically load subsets of content VS loading the full list (several mb) or doing multiple page loads to navigate the content is Very handy (for reference, part/model tree, full data set was over 5mb, organized in a tree structure, page loaded root of tree, each selection loaded that branch of information from the tree, really worked out great)

      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.

      Getting source or pics from 'protected' websites is no harder then Firefox -> Web Developer -> Disable Javascript (after page is loaded) :) So much for that protection that irritates 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.

      A good way to see the effects of this is to use something like LORI for Firefox, shows number of items downloaded from the server, the total size of the information loaded, and the total time required for you to get it all. One of our dev sites started getting all fancy with really cool JS libraries and tons of CSS and other functionality, which got dropped once we checked and found out that it was loading nearly 300k for all the content (and minimal images, less then 15k).

      While I agree on all points, the big one I hate is Flash, unless it's for some rich media functionality (YouTube) I hate flash, and will usually run around the web with it disabled. As much as JS can be missused and abused Flash can be exploited to ruin your web experience.

      --
      DEMETRIUS: Villain, what hast thou done?
      AARON: Villain, I have done thy mother.
      Shakespeare invents 'your mom'
    24. Re:A simple request by Anonymous Coward · · Score: 0

      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?

      Do explain how the client-side error checking can occur with javascript disabled...

    25. Re:A simple request by kv9 · · Score: 2, 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 won't submit. great job there!

    26. Re:A simple request by Anonymous Coward · · Score: 0

      www.facebook.com

      troll.

    27. Re:A simple request by Legion_SB · · Score: 3, 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.

      --
      'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'... if you're reading this, it didn't work.
    28. Re:A simple request by Wraithlyn · · Score: 1

      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.

      --
      "Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
    29. Re:A simple request by CodeBuster · · Score: 1

      Or you could just use NoScript. If you are waiting for the all of the self-proclaimed web designers and developers out there to change their ways then you are likely going to be waiting for a very long time. Firefox + AdBlock + NoScript...accept no substitutes.

    30. Re:A simple request by girlintraining · · Score: 1

      Well, you shouldn't use it except out of necessity, but that goes for any technology. The definition of necessity, however, is a moving target and flamebait to discuss.

      --
      #fuckbeta #iamslashdot #dicemustdie
    31. Re:A simple request by vux984 · · Score: 1

      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 can't fix it by writing 'better code', you fix it by building a better more robust platform to run things on.

    32. Re:A simple request by vux984 · · Score: 1

      www.facebook.com

      That site a shit hole.

      troll.

      right back at ya

    33. Re:A simple request by Anonymous Coward · · Score: 0

      jQuery is used for manipulating the look and feel of the page such that you can add animations or image galleries with ease etc

      You don't use jQuery to POST information.

    34. Re:A simple request by Anonymous Coward · · Score: 0

      I guess that's what the Forms 2.0 reference was about. Define your validations in one place: one regex attached to a form that is checked on the client and on the server, with additional checks on the server for more complex or non-immanent conditions.

      That goes in the right direction, but make Microsoft Forms a web standard? I hope that will never happen. Maybe XForms.

    35. Re:A simple request by Wraithlyn · · Score: 1

      "The definition of necessity, however, is a moving target"

      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 validation (for improved user experience, and reducing server hits) backed up by proper server-side validation (for security).

      Well, you shouldn't use it except out of necessity, but that goes for any technology.

      You seem to have a habit of making sweeping generalizations that fall completely apart under scrutiny. No technology should be used except for reasons of necessity? Really?

      Ever used elevators or escalators when you could've taken stairs? Ever used a car, bike, or transit when you could've walked?

      Ever use technology for entertainment purposes? Ever watched a movie? Played a video game? Surfed the web?

      The fact is, we all use technology to make things more convenient and improve our quality of life on a daily basis, and much of it has nothing whatsoever to do with actual NECESSITY.

      --
      "Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
    36. Re:A simple request by Mozk · · Score: 2, Insightful

      IMO, a better idea is to design your code to enhance progressively instead. 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.

      --
      No existe.
    37. Re:A simple request by Anonymous Coward · · Score: 0

      It doesn't, that's the point. <form href=... onclick="return self.validate();"> Is it so hard to understand?

    38. Re:A simple request by Bitsy+Boffin · · Score: 1

      Stuffing your content into a .JAR and then calling that to display the content as an example.

      Did you just confuse JAVA and JavaScript, or have I misunderstood you?

      --
      NZ Electronics Enthusiasts: Check out my Trade Me Listings
    39. Re:A simple request by Anonymous Coward · · Score: 0

      Mostly fairly valid points, except: 1. Why should my server take an extra hit every time a novice user types an invalid date or misses a required field? And why should the user have to wait for another page load and re-enter any data that can't be sent back to the browser (passwords, file locations, etc)? 2. Forgive my possible ignorance on this one but how would you load data from the client with XML and CSS without javascript? Are you suggesting that the web was a better place before AJAX? On the whole I agree with your comments but as long as javascript is used in a way that's unobtrusive it can improve the user experience without having any negative impact on accessibility.

    40. Re:A simple request by soliptic · · Score: 1

      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 this.attr(href) instead
      })

      When using jQuery, you don't hardcode the ajaxy way into your <a onclick="javascript:"> attrib, because the $ object isn't guaranteed to be available. So, it pretty much forces you to do it properly and register an event the nice way - after the fact, separate to your well-formed structural markup. Oh, and you're selecting stuff with CSS selectors, so you're pretty much forced to do "right way" CSS too.

      Before frameworks - you were in a world of hurt even figuring out how to attach events in a plays-nicely way (example). Even a fundamental like getElementByID meant browser incompatibility issues. You spent so much time tearing your hair out about this crap, by the time you had the javascriptified version working, you honestly struggled to care about the 2% of people surfing with js disabled.

      By (a) taking away all this bullshit and (b) encouraging (through their documentation/community), if not outright requiring, a "best practice" type of "house style" / coding conventions, frameworks like jQuery actually let developers spend time writing useful stuff that you KNOW won't fuck people's shit up, because someone cleverer than you made sure it won't, instead of spending all your time writing boilerplate nonsense to make sure it doesn't fuck people's shit up.

      I mean, seriously, where is the jquery plugin for loading a "billion popups"? Where is the John Resig blog post that advises you javascript means you don't need to check POSTs server side anymore? Oh yeah, they don't exist. So this is pretty much the last audience that needed that lecture (correct as it was, in it's own right). Still, I suppose it's too much to expect for there to ever be a js related story on slashdot without someone charging in with an irrelevant anti-js rant. Same as every phone story has to have the obligatory I JUST WANT A SIMPLE PHONE wahmbulance post. *sigh*

    41. Re:A simple request by Anonymous Coward · · Score: 0

      I would rather pull my hair out of my head one hair at a time then follow your anal restrictive methods. javascript IS part of the web space and even Googles Chrome is in reaction to it. Part of the great portability of web apps is its open method for handling server calls via the client and handling them on the client.

      Go ahead disable javascript knucklehead the rest of us will move on. You were probably one of those people that were defiant against flash because you considered it malware. Who would have thought Flash would become the main conduit for streaming video on the web? Gee go figure.

      People like you annoy me. If I I want my site compliant for phones etc I have a WAP app for that purpose.

    42. Re:A simple request by hobo+sapiens · · Score: 1

      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.

      --
      blah blah blah
    43. Re:A simple request by Nycran · · Score: 1

      "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." Fair enough. "Don't try and block off your page because your advertisers want to use javascript to enable a billion popups." Agreed. "Don't use scripting to sanitize your POST submissions; You should handle that on the backend, it's more secure anyway." No, disagree. Validation should be both client side and server side. It wastes the users time making them wait for a post operation when a simple alert would have done the trick. "Don't use it to load content; That's what CSS and XML are for and it renders faster anyway." Neither CSS or XML can be used to load content. They're both descriptive, not active. Javascript on the other hand, via AJAX, does load things. And AJAX IMHO is good, if used in the right places. It can make interfaces more efficient. "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." There is no golden rule for this. It's all about context. If I'm building a web application (as opposed to a brochure web site), then I think requiring javascript is absolutely fair game. If you don't like javascript, don't use web apps and stick with traditional desktop apps. I'm guessing from your attitude that you probably do 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." Yup, agreed.

    44. Re:A simple request by Anonymous Coward · · Score: 0

      That's not what I said. I said it was still possible for a form that had client-side javascript validation to still submit to the server if javascript was turned off. Only the second part(after the AND) of that statement was to be included under the 'if javascript is disabled' caveat.

    45. Re:A simple request by Redwing · · Score: 1

      Perhaps, but this is irrelevant to the question of when to use js or whether to use AJAX.

      --
      Raisinettes are my raison d'etre
    46. Re:A simple request by Anonymous Coward · · Score: 0

      Don't forget that if you want to get to the guy with the metal detector you have to wait the queue, and if by mistake you wear something not allowed you have to wait the queue again. :P

    47. Re:A simple request by Keeper+Of+Keys · · Score: 1

      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.

    48. Re:A simple request by Keeper+Of+Keys · · Score: 1

      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?

    49. Re:A simple request by Keeper+Of+Keys · · Score: 1

      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.

    50. Re:A simple request by vux984 · · Score: 1

      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 applications... but publishing applications that were designed from the ground up to be published in this way, or hybridizing the two ... but do something actually works... and not try to emulate multi-threaded event driven applications in a web browser environment that doesn't actually support half those things.

    51. Re:A simple request by jez9999 · · Score: 1

      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>.

  8. GXT by Anonymous Coward · · Score: 0

    Ever since GWT, I hardly touch any JS, but due to lack of skins and custom widget, I vote to use GXT currently.

    http://extjs.com/products/gxt/

  9. Put blame where blame is due by dgun · · Score: 1

    Cross browser issues have been more in the DOM and css, much less than JavaScript itself.

    --
    FAQs are evil.
    1. Re:Put blame where blame is due by Rayban · · Score: 1

      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.

      --
      æeee!
    2. Re:Put blame where blame is due by Anonymous Coward · · Score: 0

      I concur, even more, javascript has been used as a way of working around those same issues

  10. Excellent book by MikeRT · · Score: 2, Interesting

    I have it on my desk next to me for when I have to do JavaScript by hand. It's one of the only programming books that I've bought where several months after the fact I still consider it money well spent.

  11. Could you at least explain what it is by Chris+Pimlott · · Score: 0, 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.

    1. Re:Could you at least explain what it is by Legion_SB · · Score: 1

      You know, I'm thankful that when I go to a sports website and read an article talking about a quarterback that throws too many interceptions, there aren't morons in the comments complaining that the article doesn't explain what an interception is.

      --
      'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'... if you're reading this, it didn't work.
    2. Re:Could you at least explain what it is by Wraithlyn · · Score: 1

      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.

      --
      "Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
  12. He'll never use that name by Anonymous Coward · · Score: 0

    He'll obviously shorten it to H.S. Deathgoat Jones.

  13. Is there any chance, even a slim one by kaizendojo · · Score: 0, Troll

    ..that we can get through a SINGLE /. posting without some comment bashing Microsoft or one of its products?? Now, I'm not going to claim that since I started working for Microsoft I think they're awesome (like the Motorola Krave astroturfer), but for Christ sake give it a rest. NO browser is completely compatible to the 'standard' and a REAL designer can code for the two major browsers without much effort - and if he/she can't it's probably time to rethink the design.

    Grousing about compatibility or quirks is for sissies. Flame if you like, but the reality of the matter is that browser share is about dead even these days. The mark of an immature designer is made even more obvious with the tags "Best Viewed in..."

    1. Re:Is there any chance, even a slim one by mweather · · Score: 1

      ..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.

    2. Re:Is there any chance, even a slim one by fforw · · Score: 1

      Godwin! .. but, yes.

      --
      while (!asleep()) sheep++
  14. Re: and tell us what the jQuery soldier is smoking by Anonymous Coward · · Score: 0

    The little toy soldier dude appears to be smoking something from a little pipe.

    I'm guessing it's a little wooden crack pipe?

  15. jQuery is very well thought-out by WebManWalking · · Score: 5, Interesting

    My first attempt to teach myself jQuery with a real-world example was a screaming success. I had to fix a huge page in 3 major sections that confused and frustrated users. (Couldn't be helped. Management decision.) In less than an hour, I vastly simplified the page using only one line of jQuery code for each section. I repeat, only one line of code for each section.

    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.

    1. Re:jQuery is very well thought-out by Wraithlyn · · Score: 1

      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)

      --
      "Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
    2. Re:jQuery is very well thought-out by WebManWalking · · Score: 1

      Glad I'm not the only one who thinks animation could be better documented.

      BTW, I finally found a pretty good book on explaining the ideas behind jQuery: John Resig's own book, Pro JavaScript Techniques. It's pretty old by Web standards, so it doesn't exactly correspond to jQuery 1.2.6. But it's damn good.

      I guess I'm revealing that I'm behind the times by saying that. Oh well.

      What's cool about it, reading it for the first time nowadays, is seeing the concepts presented before they came to fruition as jQuery. I chuckle to myself reading it: Gee, it would be really cool if there were a library that would do all of this for you. :-)

      I'm not done reading it yet. Just got it. Only up to chapter 5. But I'd already recommend it if you're looking to understand how jQuery was written and why things were done the way they were.

    3. Re:jQuery is very well thought-out by WebManWalking · · Score: 1

      By the way, don't get me wrong, this is a damn fine book to learn jQuery.

  16. Extjs is the worst library I've ever dealt with by Anonymous Coward · · Score: 0

    If you are writing an application with any level of complexity, you'll kill yourself over Ext pains long before completing your project.

  17. Help site by Anonymous Coward · · Score: 0

    www.jqueryhelp.com is a useful help site for jQuery.

  18. Wanted: JQuery Developer by KozmoKramer · · Score: 1

    Skills: SQL, JAVA, C#, Oracle, C++, and 10 years experience coding in JQuery........

    --
    My name is Inigo Montoya. You killed my Father! Prepare to die!
  19. Javascript Compilers: AJAX in Java, Python, Ruby by lkcl · · Score: 1

    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 which is a java-to-javascript compiler and AJAX library

    2) Pyjamas http://pyjs.org/ which is a python-to-javascript compiler and AJAX library

    by using this kind of technology, not only do you get to write your code in a decent high-level language, subdividing it into modules, classes and functions, but also the technology takes care of all the browser incompatibilities - again, by putting them behind well-written modules and classes with a common API.

    until AJAX was properly discovered, browsers were being treated as no more than "thin clients", where the HTML was generated by the server. AJAX has turned that on its head, as code is now being executed client-side (browser-side).

    it's becoming increasingly clear that javascript is a wildly inappropriate language to do web development in, yet it's also not going to go away and, because it is so powerful, it shouldn't HAVE to go away.

    and, if you have a compiler which turns decent high-level languages into javascript, automatically, javascript DOESN'T have to go away.

    see http://advogato.org/article/985.html comment "a question and an open request" for more information on javascript compilers such as rb2js.

  20. powerful but obtuse by lkcl · · Score: 2, 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, javascript is no different.

    my take on this is that it's far better to do web client programming in a higher-level-language such as python or java. fortunately, javascript is an extremely good fit with python, and java has a limited subset of the dynamic capabilities of javascript, so is also a good (one-way) fit.

    by programming in python, java or ruby and having it translated into javascript automatically, the fear that people have of getting into an awful AJAX mess goes away.

    http://pyjs.org/
    http://code.google.com/gwt

    1. Re:powerful but obtuse by shutdown+-p+now · · Score: 1

      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.

  21. Who has JS disabled anyway? by quadrofolio · · Score: 1

    I find all these very emotional responses of people saying that it should all run with JS disabled tiring. Who has it disabled anyway? Come on.

    1. Re:Who has JS disabled anyway? by fforw · · Score: 1
      > Who has it disabled anyway?
      • people with old browsers
      • people with disabilities
      • people in companies with strict security policies
      • google bot
      --
      while (!asleep()) sheep++
  22. Googlebot is a NoScript user by Keeper+Of+Keys · · Score: 1

    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.