Peer Reynders

+ Follow
since Aug 19, 2005
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Peer Reynders

I don't know Ember.js but for the time being it should be the least jQuery hostile framework as Ember's code base seems to occasionally use jQuery itself (, which isn't that surprising). That being said there seems to be some suggestion that jQuery shouldn't necessarily be the first tool to reach for when you are using Ember: jQuery to Ember: How to Make the Jump Without Falling - YouTube and

No, really, Let Ember handle things!

The Top Mistakes Developers Make Using Ember & Rails - 4 Ember isn't jQuery, either
Basically jQuery is safe as long as nothing else is competing for access of the DOM - things change once a framework wants (preferably) exclusive control of the DOM. In general once you are using a framework you should always find out whether there is a way to do something through that framework first before you get another library involved (even if you already know how to do it with that other library) or even use the browser API. Unfortunately every framework/library "has its own way of doing things" so there is always yet another learning curve to deal with (discovering what your tools are doing for you under the hood can sometimes help flatten the curve the next time around).

In the end the question that really needs to be asked much more often: "Is implementing this web application as a Single Page Application the best solution?"

For the time being counter-movements like ROCA (Resource-Oriented Client Architecture) are being largely ignored (where jQuery libraries are listed among others under ROCA JavaScript Libraries). But there are cases where organizations have gone from front-end page generation back to rendering pages on the server side:
Improving performance on | Twitter Blogs
Delicious Changes | The Official Delicious Blog

... so in some instances the issue should be more about avoiding SPAs - though be prepared for accusations of being "anti-progressive" and "stuck in the past".
Why I hate your Single Page App — Medium
  • You have been repeatedly asked to indent and format your code properly - it makes it easier to read - if you would indent and format it properly it should occur to you that the second half of the code isn't even part of the event handler.

  • You really need to look over the "Debugging" section of the Javascript Links (Wiki forum at Coderanch). If you use Google Chrome/Chromium: Chrome DevTools Overview - Google Chrome: Debugging JavaScript, Debugging JavaScript - Google Chrome: Debugging with breakpoints. The console of the development tools would have immediately told you that the return on line 47 is illegal (because the code is not inside a function).

  • The browser ignores your script because your script failed during the page load - so as far as the browser is concerned the script doesn't exist, so it goes straight to submit because that is what the HTML is designed to do.

  • In more recent years it has been considered bad practice to use inline JavaScript event handlers or on-event handlers. You were made aware of the alternative in your validation in javascript topic.
  • Here is an example: Event Handling Using addEventListener.
    Note that the code in the example uses this while the code above above uses inside the event handler. There is a subtle difference between the two:
  • inside an event handler this refers to the element the event handler is attached to
  • while is the element the event originated from
  • You could get the effect that you are looking by wrapping the code in the if(count%2 == 0) block in a function and using setTimeout.
    Try this out in a tiny side project first so that you have chance to get a handle on how things work first.

    WindowTimers.setTimeout() - Web APIs | MDN
    John Resig - How JavaScript Timers Work
    Really Understanding Javascript Closures

    Ryan O'Neill wrote:I cannot for the life of me figure out why the 2nd card doesn't flip when isAddTrue is true.

    Now as I'm not running the code, so I can't say for sure - but are you sure that it isn't simply a matter of not seeing that the card is flipped? You first recreate the table with the second card flipped and then destroy it immediately to create the table with both cards off the table. So the browser may never get around to rendering the table with the second card flipped and immediately goes to rendering the table with the two cards removed.

    Ryan O'Neill wrote:Any help with this loop would be a big help. I can't get it to go into the first if.

    Well there is no "if" inside the loop. The "if" is part of the click handler that is set by the loop - so the if only gets hit when something is clicked.

    An alternate view of your code (after just a quick scan over it):

    You really need to follow Bear's advice and look over the "Debugging" section of the Javascript Links (Wiki forum at Coderanch). That way you'll get a better idea of how your code executes.

    Use Google Chrome/Chromium if you can:
    Chrome DevTools Overview - Google Chrome: Debugging JavaScript
    Debugging JavaScript - Google Chrome: Debugging with breakpoints

    Also you seem to be tackling a lot of things that are new to you at the same time. Maybe step back and see if you can create a number of HTML/CSS/JS mini projects which only deal with one single problem/aspect of the solution at a time so that you can explore each issue in detail and isolation. Once you are sure you know how all the pieces work, start combining the ideas, one at a time.
    What is it that you are actually trying to do? Looking at your code makes me wonder whether you are loading images that are generated in real-time - like in a security console - in which case the entire idea of "pre-loading" goes out of the window because you are always loading images that didn't exist before.

    If that is the case you may need to vary your approach:
  • Load the image asynchronously into an element that isn't part of the DOM (javascript - Asychronously load images with jQuery - Stack Overflow).
  • When the load is complete replace the stale image element with the fresh one. Also use setInterval to schedule the next asynchronous loading of the next, more current image after ?? seconds (The ?? delay is primarily there to give the server a break - especially if you have a separate asynchronous request going for each image that is currently visible on the document).
  • a.dropbtn:hover .dropdown-content reads as "a.dropbtn:hover is an ancestor to .dropdown-content" - now take a look at your HTML.
    Hint: Adjacent sibling selectors | MDN.

    That being said probably best stick to the fix that you have already found.
    How to Create a Simple CSS Dropdown Menu - Treehouse Blog
    Simple Pure CSS Drop Down Menu | codepen
    In future posts, please be sure that your code is properly indented.

    sarojni agrwal wrote:in which I want to check the numbers in debit card and other fields also, but I am able to check only one, because, in input field onclick function is not used, if there are buttons rather than text boxes then I will handle, by put onclick on every button , but how can I handle here by input text texts?

    What makes you think that you need a separate event listener for each input text field? When the user clicks the submit button an event listener on the form element will fire. will be form element and you can easily get a hold of each of the form's input fields inside the listener and retrieve their values for validation.

    In the above code I got the value of the "search" text input element. If there were more text input elements I could get their values in exactly the same manner - no need for separate event listeners.
    Just a word of caution: It may worth your while to spend a bit more time and effort to consolidate your JavaScript skills before diving into jQuery at this point in time.

    jQuery is a JavaScript library and using jQuery requires writing JavaScript code, so having a good grasp of JavaScript is essential for using jQuery competently.
    It is unreasonable to expect to "pick up JavaScript on the side" by learning jQuery - all you are really doing is investing time and effort into learning jQuery and the jQuery way of doing things.

    There is no argument that jQuery is invaluable when working with traditional, non-SPA web applications. It is used with older SPAs written with Backbone.js; even AngularJS 1.x included a jQLite gizmo - but then in the FAQ: Common Pitfalls you'll find this:

    Stop trying to use jQuery to modify the DOM in controllers. Really. That includes adding elements, removing elements, retrieving their contents, showing and hiding them. Use built-in directives, or write your own where necessary, to do your DOM manipulation. See below about duplicating functionality.

    If you're struggling to break the habit, consider removing jQuery from your app. Really. Angular has the $http service and powerful directives that make it almost always unnecessary. Angular's bundled jQLite has a handful of the features most commonly used in writing Angular directives, especially binding to events.

    In fact many people "raised" on jQuery seem to struggle when transitioning to another framework like AngularJS (example - well, they call AngularJS opinionated for a reason).

    Also modern JavaScript frameworks like AngularJS 2.x and React tend to implement a shadow or virtual DOM (there is even the minimalistic virtual-dom library). For performance and convenience reasons you are supposed to manipulate the framework's virtual DOM and leave the browser's DOM to the framework - in this situation jQuery cannot be used because it can only manipulate the browser's DOM and not the virtual DOM and jQuery's interference is going to lead to undesirable behavior from the "the other" framework. Typically the "other framework's" mental-model-of-the-browser-DOM is in some way based on the Ye Olde mess of a DOM (though 7 years later things are a little better) - so ultimately there is no escaping the DOM in the browser.

    jQuery in Action, 3e; "about this book" p. xxv:

    The book assumes a fundamental knowledge of HTML, CSS, and JavaScript ... To top it all off, we have provided an appendix highlighting key JavaScript concepts such as function contexts and closures—essential to make the most effective use of jQuery on our pages—for readers who are unfamiliar with, or would like a refresher on, these concepts.

    The 16 page appendix "JavaScript that you need to know but might not!" has to be well understood before venturing into jQuery.

    If you don't have access to the book you could try:
    YDKJS Up & Going | Kyle Simpson
    jQuery Fundamentals - JavaScript Basics | Rebecca Murphey

    Understanding JavaScript makes it easier to understand all the JavaScript-related stuff. This is now more important than ever because npmjs/nodejs have become an integral part of the web development tooling pipeline - no help from jQuery here as there is no HTML, CSS, and DOM to deal with; only pure JavaScript and some nodejs. Example: webpack.

    So you know jQuery. Now What? | Remy Sharp (2013)
    If you haven't you should have a quick look over the Javascript Links (Wiki forum at Coderanch)
    Right now you should be interested in the "Debugging" section.

    For example if you are allowed to use Google Chrome/Chromium as your browser you should be looking at:
    Chrome DevTools Overview - Google Chrome: Debugging JavaScript
    Debugging JavaScript - Google Chrome: Debugging with breakpoints
    so that you can follow Bear's advice:

    Bear Bibeault wrote:Set a breakpoint in the code [, step through your code] and inspect your variables. Which one is wrong?[For example, is any variable null or undefined when you don't expect it to be - is there an error message in the JavaScript console that may indicate that something has gone wrong?]

    sarojni agrwal wrote:so how can I put onclick on that input textbox?

    The real question is: Why don't you want a visible submit control? Users can submit an HTML form simply by pressing "Enter" while the focus is inside a text input field (not in a textarea) without ever clicking on the submit control. More code is needed once you remove the submit element from the form - i.e. an event handler would have to monitor key presses to intercept "Enter" and coordinate the submit programmatically (which won't necessarily work for tablets anyway).

    If absolutely necessary, "hide" the submit control and leave most of the work to the browser:

    HTML forms guide - Web developer guides | MDN
    submit - Event reference | MDN
    html - Submitting a form by pressing enter without a submit button - Stack Overflow

    Thank You!

    And Kyle Simpson, thank you for your time and advice, and congratulations to the other winners!