5 ms·

Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plai

Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plain old javascript and HTML is fine. Remember we reached for jQuery in the first place because the browser lacked features we wanted, and because it handled cross browser stuff for us. That is, it simplified things we were already doing manually. So the trap is bad advice like "use these 58 libraries" combined with an inexperienced person making the architecture choices. I'd say instead (if you're the inexperienced person) just start building stuff. Then every time you said "this is repetitive, I wish there was a library that did this for me" -- there will be. Go out and get it, and you'll then understand why it exists.

mathgeek 10y ago
I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.
- snlacks 10y ago
  Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery. These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
- lloyd-christmas 10y ago
  Interview question: "iterate over an array": angular.forEach([1,2,3] ... $.each([ 1, 2, 3 ], ... [1,2,3].forEach(... One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own. This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.
  - lovich 10y ago
    @cloverich I think this comment is showing exactly how the author of the article wasn't exaggerating
    - lloyd-christmas 10y ago
      I don't follow. Are you saying _I_ demonstrate why the article isn't exaggerating, or that some of the people I've interviewed are?
      - lovich 10y ago
        I am saying that you demonstrate why the article wasnt exaggerating. Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you. Therefore theres at least a group of people that article is accurately describing
        lloyd-christmas 10y ago
        > Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you That isn't what I said in the slightest. My criticism had nothing to do with jQuery. Go back and replace jQuery with underscore, lodash, ramda... I'm not saying that I would turn away a jQuery developer when interviewing for an angular position. I said that a negative defaulting to a framework/library to solve a vanilla problem is a problem in and of itself. "One of these things is not like the other" is the native Array.prototype.forEach(). It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem.
        cloverich 10y ago
        > Go back and replace jQuery with underscore, lodash, ramda... It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem. Well, jQuery in particular is somewhat of an exception. It achieved such a high level of ubiquity, and solved such a vast array of cross browser issues, it was not unreasonable for a front-end dev to add jQuery as the first step in any project. Similarly, while its "literally built into the language" that's only true in cases where you can drop IE8 support. I would personally be very surprised if there weren't still more quality developers who knew the jQuery or underscore api's better than the native javascript ones. I think the more general sentiment here is: If you use map / reduce / forEach / etc with jQuery / underscore very well, you can very easily transition into dropping or changing those libraries. But your comment made it sound like you were less interested in how well they could code and more interested in which API's they knew (and knocking them for defaulting to the most widely known ones).
- sangnoir 10y ago
  > I've been to more than one interview where I defaulted to jQuery and was immediately disqualified Was the role more biased to front end development? Speaking as someone who has been on the other side of the interviewing table, you won't believe the number of people who can use jQuery but are otherwise unfamiliar with vanilla Javascript. I suspect the question itself could have been solved by via plain JS, and you did the equivalent of $('#id') instead of document.getElementByID('id')
  - raverbashing 10y ago
    Oh I'm sure that's not what they mean. 100% sure While knowing how to use vanilla js is important, nobody uses getElementByID anymore, unless you're doing something very, very simple (or building a library yourself)
    - jerkstate 10y ago
      You sound like the article
  - mathgeek 10y ago
    > Was the role more biased to front end development? These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.
    - SZJX 10y ago
      That probably depends. If the company is really small then you may end up doing quite some frontend work but there can still be significant backend logic going on in Rails.
  - deleted 10y ago
    [deleted]
- morsmodr 10y ago
  As was said earlier, finding the right tool is essential. jQuery can still be used if the problem you are solving is limited and confined in scope. We had a website where angular is almost everywhere, we created a new page where there is just a list of check boxes, and another dev did that with Backend code. I just added a small jQuery event listener as the page needed nothing more than to disable a certain set of buttons when one from a set is selected. I could have re-written the entire stuff making angular get the model from server and then using angular in the view. But no, it was just not worth it. If you see that your jQuery component is building up (adding more functionality) then it gets messy/spaghetti etc. But if the interviewer straight away dismissed you at the sound of jQuery you are better off not working there.
clifanatic 10y ago
> using plain old javascript and HTML is fine. It's fine if it's a single-person's decision. If two or more people are involved in any sort of standardization process, you're going to go back and forth until you land on the most complicated possible approach like in the article.
- marrs 10y ago
  that depends a lot on how well they can work together. This is also where good team leaders add a lot of their value.
badthingfactory 10y ago
This is where OP lost me as well. "Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016." The appropriate response is "Yeah, your problem seems simple enough. jQuery should do just fine." But that article would be boring and not on the front page of HN.
- ci5er 10y ago
  > "Oh my god no, no one uses jQuery anymore..." I've been told that within the last month, almost in those exact words, here on HN. I asked what one should use instead and the answer was React. It felt like one of those "no one goes there anymore, it's too crowded" kind of moments.
  - moosey 10y ago
    The official react tutorial uses jquery for $.ajax[1]. I'm really not well versed in any of these technologies (but came up with a fun personal project that might end up using them) so I'm assuming that using both together is tame, and that the venn diagram for the two projects doesn't overlap too much. [1]: https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html
    - cloverich 10y ago
      Effectively React replaces (in many cases, simplifying) the base DOM manipulation aspects of jQuery -- but of course it does not replace the other useful utilities jQuery provides, nor the many DOM manipulation plugins in the jQuery community. When I first started with React I was able to use those libraries without issue -- you do have to learn how (when) React allows you to access the DOM and when it expects you to clean it up but for an experienced dev, its a short learning curve. Over time, I've seen many libraries similar to those jQuery plugins arise (or transition) into React components and its been fine to slowly phase in / out as I please. Lastly, its been mostly straight forward to encapsulate jQuery (or other) DOM manipulation libs within a React component, such that consumers need not even know its being used internally.

mathgeek 10y ago

I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.

snlacks 10y ago
Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery. These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
lloyd-christmas 10y ago
Interview question: "iterate over an array": angular.forEach([1,2,3] ... $.each([ 1, 2, 3 ], ... [1,2,3].forEach(... One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own. This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.
- lovich 10y ago
  @cloverich I think this comment is showing exactly how the author of the article wasn't exaggerating
  - lloyd-christmas 10y ago
    I don't follow. Are you saying _I_ demonstrate why the article isn't exaggerating, or that some of the people I've interviewed are?
    - lovich 10y ago
      I am saying that you demonstrate why the article wasnt exaggerating. Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you. Therefore theres at least a group of people that article is accurately describing
      - lloyd-christmas 10y ago
        > Cloverich stated that using jQuery was fine and the article was exaggerating how far it has fallen out of favor, but you have stated that anyone using jQuery is out the door when interviewing with you That isn't what I said in the slightest. My criticism had nothing to do with jQuery. Go back and replace jQuery with underscore, lodash, ramda... I'm not saying that I would turn away a jQuery developer when interviewing for an angular position. I said that a negative defaulting to a framework/library to solve a vanilla problem is a problem in and of itself. "One of these things is not like the other" is the native Array.prototype.forEach(). It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem.
        cloverich 10y ago
        > Go back and replace jQuery with underscore, lodash, ramda... It's literally built into the language, and the person added a script tag to include an 85kb file just to run a loop over 3 elements. THAT'S the problem. Well, jQuery in particular is somewhat of an exception. It achieved such a high level of ubiquity, and solved such a vast array of cross browser issues, it was not unreasonable for a front-end dev to add jQuery as the first step in any project. Similarly, while its "literally built into the language" that's only true in cases where you can drop IE8 support. I would personally be very surprised if there weren't still more quality developers who knew the jQuery or underscore api's better than the native javascript ones. I think the more general sentiment here is: If you use map / reduce / forEach / etc with jQuery / underscore very well, you can very easily transition into dropping or changing those libraries. But your comment made it sound like you were less interested in how well they could code and more interested in which API's they knew (and knocking them for defaulting to the most widely known ones).
sangnoir 10y ago
> I've been to more than one interview where I defaulted to jQuery and was immediately disqualified Was the role more biased to front end development? Speaking as someone who has been on the other side of the interviewing table, you won't believe the number of people who can use jQuery but are otherwise unfamiliar with vanilla Javascript. I suspect the question itself could have been solved by via plain JS, and you did the equivalent of $('#id') instead of document.getElementByID('id')
- raverbashing 10y ago
  Oh I'm sure that's not what they mean. 100% sure While knowing how to use vanilla js is important, nobody uses getElementByID anymore, unless you're doing something very, very simple (or building a library yourself)
  - jerkstate 10y ago
    You sound like the article
- mathgeek 10y ago
  > Was the role more biased to front end development? These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.
  - SZJX 10y ago
    That probably depends. If the company is really small then you may end up doing quite some frontend work but there can still be significant backend logic going on in Rails.
- deleted 10y ago
  [deleted]
morsmodr 10y ago
As was said earlier, finding the right tool is essential. jQuery can still be used if the problem you are solving is limited and confined in scope. We had a website where angular is almost everywhere, we created a new page where there is just a list of check boxes, and another dev did that with Backend code. I just added a small jQuery event listener as the page needed nothing more than to disable a certain set of buttons when one from a set is selected. I could have re-written the entire stuff making angular get the model from server and then using angular in the view. But no, it was just not worth it. If you see that your jQuery component is building up (adding more functionality) then it gets messy/spaghetti etc. But if the interviewer straight away dismissed you at the sound of jQuery you are better off not working there.

clifanatic 10y ago

> using plain old javascript and HTML is fine. It's fine if it's a single-person's decision. If two or more people are involved in any sort of standardization process, you're going to go back and forth until you land on the most complicated possible approach like in the article.

marrs 10y ago
that depends a lot on how well they can work together. This is also where good team leaders add a lot of their value.

badthingfactory 10y ago

This is where OP lost me as well. "Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016." The appropriate response is "Yeah, your problem seems simple enough. jQuery should do just fine." But that article would be boring and not on the front page of HN.

ci5er 10y ago
> "Oh my god no, no one uses jQuery anymore..." I've been told that within the last month, almost in those exact words, here on HN. I asked what one should use instead and the answer was React. It felt like one of those "no one goes there anymore, it's too crowded" kind of moments.
- moosey 10y ago
  The official react tutorial uses jquery for $.ajax[1]. I'm really not well versed in any of these technologies (but came up with a fun personal project that might end up using them) so I'm assuming that using both together is tame, and that the venn diagram for the two projects doesn't overlap too much. [1]: https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html
  - cloverich 10y ago
    Effectively React replaces (in many cases, simplifying) the base DOM manipulation aspects of jQuery -- but of course it does not replace the other useful utilities jQuery provides, nor the many DOM manipulation plugins in the jQuery community. When I first started with React I was able to use those libraries without issue -- you do have to learn how (when) React allows you to access the DOM and when it expects you to clean it up but for an experienced dev, its a short learning curve. Over time, I've seen many libraries similar to those jQuery plugins arise (or transition) into React components and its been fine to slowly phase in / out as I please. Lastly, its been mostly straight forward to encapsulate jQuery (or other) DOM manipulation libs within a React component, such that consumers need not even know its being used internally.