How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.
These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
angular.forEach([1,2,3] ...
$.each([ 1, 2, 3 ], ...
[1,2,3].forEach(...
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.
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.
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).
It seems like you're presuming that they must lack proficiency in the DOM if they're choosing to use jQuery. Perhaps you're trying to say you want to see them demonstrate that they're not just copy/paste coders.
Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.
I don't use this in my interviews, and I'm surprised everyone took this literally given that we have a weekly blog article about the villainy of technical interviews and how they destroy the very fabric of software development. I'm using a hyperbolic example to demonstrate what I perceive as a negative trait; A reach for unnecessary tooling to solve simple problems. My hiring experiences have pointed towards it being indicative of a comfortable one-trick-pony.
> Given your code example above, I wouldn't want a candidate to know the difference between each `forEach` method, but I would expect them to know that each provides a means of iterating over a set of values.
Likewise. However, if I'm hiring someone for a back end role, I'd expect them to be able to know basic SQL and not just their language's ORM. I'd expect them to be able to type `cd` and not just navigate through their IDE. I don't think there is anything different between that and the relationship of jQuery/angular and vanilla js. jQuery isn't written in jQuery. Debugging rarely stops at the script tag/require statement.
for(let thing of things) {...}
for in, on the other hand is wrong
https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
https://stackoverflow.com/questions/500504/why-is-using-for-...
Sorry, what does this even mean? When we consider it bad to use an external solution we call it Introducing Unnecessary Dependencies, when we consider it good to use an external solution we call it Not Reinventing The Wheel.
What you're doing here is fetishizing some arbitrary knowledge that you've set up as a litmus test. I've hired probably close to a hundred engineers by this point in my career, and I have to say, unless you are hiring for specialists to fill a very specific purpose, the only test that matters is Joel Spolsky's smart-and-gets-things-done test. There are plenty of web developers out there who only ever used jQuery and thus never learned javascript properly—that says nothing about their talent. There is a good portion of them who, upon being told, "we don't use jQuery here, just raw javascript" will learn and be better at it than you in a couple months. Even more importantly, any good engineer is going to have a lot experience which you don't have, and which to you is an unknown unknown. The best team is made up of diverse backgrounds and experience, not a bunch of people who managed to pass through a series of arbitrary knowledge gates.
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')
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)
These were Rails positions, which in my experience almost always equates to the same skillset expectations as a front-end engineer.
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.
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.
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.
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.
I'm excited about it, and I appreciate your explanation. I've never been a front end guy (all devops/scripts and some crud type stuff), so this helps me greatly.
I've also heard claims that React's theory of slow DOMs is wrong. Which doesn't make it a 'bad' framework to make use of, just optimized on the wrong thing. I haven't had time to suss this out. I spend a lot of time in "good enough for now" mode because I'm not a dedicated front-end person.
Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.)
I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :)
EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).
I usually see 3 categories:
- I want to learn Web Development.
- I want to learn Web Development, but in all actuality I'm going to quit in 3 days.
- I want to learn Web Development, but in all actuality I just want something working with no effort.
None of these need an informed decision. The latter 2 don't matter anyway, and the first one is better off starting with a vanilla ajax request[0], and they likely know it. When it comes down to it, "I'm going to make an app today" means your decision likely doesn't have long-term consequences and an informed decision isn't all that important. Pick up jquery like the other 80% of the living internet[1].
[0] https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-...
Either way, by going through the problem solving process, you will develop some of the skills needed to recognise the motivation behind the solutions provided by 3rd party libraries and you will be in a better position to evaluate them.
Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things.
But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here.
The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."