Debug Node .. Finally (It shall be Simpler)

Node-Inspector …

  1. npm install -g node-inspector
  2. node –debug-brk web.js (web.js here the node script)
  3. node-inspector & (open in new tab caonsole)

Debug like you do in Chrome (browser side)

Node code debugged


Control your feelings .. Mr. Browser , Just debounce

This is something new for me , so thought – something like this might be a news for some of the crowd. And I was immensely helped by this concept, so sharing.

Here I was- working once again on a project that required vast usage of Ajax requests. Not a problem – i thought. Have been working on similar projects, and it’s unlike the initial days of my developer life, where I was scared and wary, looking to the Javascript man in the team each time something related to Ajax came up.

Jumping off the context a little – I still remember the first time I heard of  ‘Ajax’. It was an job interview, where after I did reasonably well on the Java quizzing, I was asked – ‘What do you know about Ajax?’, and I made an honest admission that I have never heard about it. Well, after the interview, I came back and did a google on ‘Ajax’, and I realized – oh well it’s a football club from Amsterdam. But why the hell was that being asked in a programming interview? 🙂 .I went on to next results .. and came to learn about the JS Ajax(the one which would be of more value/interest to me in the coming years !!).

Back on to the debounce and throttle needs when making Ajax requests. How much Ajax has been used since it’s inception needs no enlightening. What has been my learning lately though, has been a case of an unnecessary overuse of Ajax, and the tricks which can be used to avoid this misuse.

The use case involves  any repeating user Behavior acting as a trigger for a server side request made via Ajax from the UI – (Some examples that I could think of)

  • on each keypress you need to update and display a list of words (which come from and Ajax request), Think an autocomplete example based on server side data.
  • on each drag of the scrollbar of an endless-scrolling application page you need to get results from the server, corresponding to the area/page to which the scrollbar is being dragged. See virtual scrolling examples here . Remember Twitter/Facebook/LinkedIn UI and you got it.
  • On each mouse move event you need to display the current position of the cursor and use it in an Ajax request. Think of a GIS application using latitude/longitude data corresponding to cursor coordinates.

So, what’s the big deal here I asked. (btw .. Mine was the infinite scrolling examples where paginated data was to be retrieved from an Ajax request). The big deal is that Mr. Browser thinks that you are done scrolling when you are in the process of scrolling. I mean you want to go from page 1 to 100 by dragging the scrollbar down and Mr. browser believes you’re done at 10, again at 13 again and 17 and so on… And each time Mr. Browser says you’re done, the bound event gets fired and your written code ditches you on Mr. browser’s word to go ahead and make a useless Ajax request. Useless because eventually all the intermediate requests are going to be futile and only the data corresponding to page 100 is going to be displayed. So, effectively you end up making ‘N’ server requests instead of just 1 or maybe 2 or 3(in case the drag is too long). So, this is a Javascript and browser limitation. It’s a browser bug, you might say, and your supervisor may just stare at you and move on to the next scientist. So, DON’T TRY THAT AT WORK.

The workaround is in Javascript and it is the simple concept of debouncing(and a related concept of throttling). I won’t present the dictionary meaning of both, although I did need to look myself.

But effectively the solution is to tell the browser in someway that – “Please treat the last activity made in a period of ‘n’ duration as the final one, and fire an event for this last activity only(ignoring the earlier ones)”.  This technique is termed as debouncing.

A probable alternative solution could be throttling –  to limit the execution time of the function on the event(triggered by user activity) by providing a duration limit( in miliseconds) . This approach again may or may not solve the problem you have at hand (depending on the use case). For example for a toggling of a flag var state, this might not be useful, and debouncing will be required.

While the description may go all over your head( 😦 I’m not good at explaining), the implementation of these is pretty simple. Thanks to jQuery plugin by  “Cowboy” Ben Alman .  A five minute read would be more than enough for implementing the required and getting your next month’s pay-cheque from your supervisor instead of a nasty stare.

The examples at the shared link  (again courtsey Ben Alman) demonstracte just how helpful this concept could be. How hardly you might be hit in abscence of this fix, will depend on what happens in those Ajax requests, How time consuming they are ?,  Do they modify concerned state also ? etc. factors.

Another recommended read to those interested would be

Apparantly, the multi-utility library – ‘underscore.js’ also provides the similar functionality. See here.

Feedback welcome.