[marrs]

In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they are letting the tools choose them.

They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don't want to feel left behind.

Choose a library or tool because it improves your development process. If it doesn't appear to improve it, don't use it (at least not unless external forces compel you to). Especially don't use it if it appears that it will retard your performance (cough Angular cough).

For example, after months (years?) of finding ever more efficient ways of enforcing object interfaces (or even basic types) at runtime, I eventually reached the limits of what JS and unit testing alone could acomplish and found myself researching Typescript, Flow, and the like.

That's not to say I'm a user of either of those, but if I do choose to adopt one in a project, I will know exactly what performance gain I am expecting from it. I'm still very productive without them.

In fact, I've successfully avoided a lot of fads in the industry for most of my career. It turns out that being able to explain why I don't use a tool makes me look like I know what I'm talking about and not just cargo culting. Employers quite like that.

Incidentally, this isn't unique to the front-end. I've seen the same thing happen with the SQL->ORM->Mongo->Couch->SQL nonsense, or the myriad of templating engines written for PHP, a language that itself is a templating engine.

[hemancuso]

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.

[cloverich]

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]

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.

[sangnoir]

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

[mathgeek]

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

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.

[raverbashing]

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]

You sound like the article

[snlacks]

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.

[morsmodr]

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.

[lloyd-christmas]

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.

[dasil003]

> Walking through people's code demonstrates whether or not they default to other people's solutions than their own.

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.

[marrs]

I have to say, this strikes me as an odd way of filtering out bad developers. jQuery is a time-saving library.

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.

[lloyd-christmas]

> I have to say, this strikes me as an odd way of filtering out bad developers.

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.

[lovich]

@cloverich I think this comment is showing exactly how the author of the article wasn't exaggerating

[lloyd-christmas]

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?

[tomatsu]

> Interview question: "iterate over an array":

  for(let thing of things) {...}

forEach only obfuscates the imperative nature of your loop.

[raverbashing]

Good, but that's more modern

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

[badthingfactory]

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]

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

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

[cloverich]

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.

[ci5er]

I'm lead to believe that either jquery isn't useful for dealing with virtual DOMs, or that it does screwy things when working together with a virtual DOM system (like react) or both.

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.

[clifanatic]

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

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

[tunaoftheland]

I've found that settling on a fairly narrow set of tools that will cover most use cases is a good start. "Best tools for the job" is not a good advice in the JS app development... Rather, "Good-enough tools for most situation" has been what I've been telling myself. (The caveat is that I am the only developer in this case, or I am in a position to determine the technology stack for the rest of the team.)

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

[lloyd-christmas]

"I want to study oncology" - On the biological side? Go learn biology. On the ML research side? Go learn basic python syntax before trying to train a neural network.

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

[1] http://trends.builtwith.com/javascript/jQuery

[marrs]

A good place to start is by writing productive code. As part of the development process, look back on what parts of the code are holding you back the most. Perhaps bugs keep appearing in this dialogue, or that list renders very slowly, or setting up the unit tests takes a lot of boilerplate. Something on the project will be impacting your delivery the most. Work out what it is if it isn't already obvious, then fix it. You might do this by using a pre-existing library, or you might write your own solution.

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.

[garysieling]

For Javascript I'd start from a project template (e.g. https://github.com/sahat/hackathon-starter). This approach teaches you learn some useful defaults and how the pieces fit together, as well as where the defaults break down.

[drostie]

This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices.

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

[murukesh_s]

100% agree with the point "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."

[Tloewald]

I think that someone coming to the field cold is going to be sucked into the vortex of enthusiasm surrounding one or more frameworks and, eventually either become a die-hard fan of some specific stack or jaded by the phenomenon.

I'm a member of the second group since, like 1995.

Right now we're on the nth cycle of lemming like enthusiasm which is currently favoring React because it just tried Angular two years ago and writing a new site with React sounds a whole lot more awesome than fixing the incomprehensible pile of crap you wrote in Angular which, guess what, seemed like a great idea at the time because of the mess you made with jquery UI.

[wccrawford]

As someone who learned Unity well enough to do game jams, then tried to switch to Unreal Engine 4 and failed to get traction for a year, I absolutely agree.

I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year.

Then I recently picked Unity back up (and had to learn a year or more of what I'd missed, including the new UI stuff) and it feels so much better. I'm getting things made and my mood has improved quite a bit.

I haven't completely given up on UE4, but I'm no longer trying to shoe-horn it into my development. I'll wait until it really is the right tool for the job this time.

[AtheistOfFail]

True story, same issue.

We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.

[kraftman]

So what do you do about jobs asking for Angular/React experience? Just tell them you have none because you haven't needed to use them yet? Or avoid those jobs? (There are a lot)

[glenjamin]

I've hired multiple people onto team using React when they have no prior React experience.

The learning curve for React is pretty smooth, so I'd mostly check if they had experience of building the types of apps we were doing with other approaches - and whether they'd seen any ill effects from those choices.

[wccrawford]

I'm not the person you replied to, but I'd recommend learning them well enough to know their strengths, and then telling the interviewer that's what you did.

If you have any experience in other front end frameworks, that'll usually be enough to get you through that part of the interview anyhow.

[vonmoltke]

That's if you get the interview. This is my problem with most of this kind of advice. All the learning in the world won't help if they ignore your resume because your last job didn't us the same technologies they do.

[marrs]

You're presuming that's why they ignored your resume; it might not be. A good recruiter will help you improve your CV and will also ask the employer why you were rejected. It is also worth while including a covering letter that you can use to make some statements up front. Make it relevant to the job description and keep it to the point.

Finally, you may not be ready for the skill level you are targeting and you may need to work out what areas you need to improve in order to be able to progress.

[k__]

Also, after learning a few frameworks, it simply isn't hard.

I mean, if you get the right mind-set of wanting to understand "what is the intention of the framework devs" you can pretty much learn any framework.

Problems mostly come if you try to force your React/Ember/Backbone knowledge into another framework.

I got all my jobs without prior knowledge of the used frameworks.

[marrs]

Just tell them you have none because you haven't needed to use them yet, and tell them why you haven't needed them yet. It may be because you haven't built complex apps or it may be because you have found your own way of dealing with that complexity that didn't require those libraries. Use it as an opportunity to discuss what you can do. If they ask you for an interview anyway then you know that it's not a deal breaker.

Also realise that a lot of the time the requirements are really just a wish list. I was recently sent a job spec that "required" a year of Angular 2 experience. Rather unlikely, given that Angular 2 is still in beta.

[lloyd-christmas]

Demonstrate you know fundamental javascript. I hire "I know javascript" over "I know angular".

[clifanatic]

Unfortunately for OP, you're in a very small minority.

[lloyd-christmas]

I don't really agree. I think people make a lot of assumptions on the "losing" side of the interview table. If you don't get the position and feel like you aced the interview, you search for some justification that has nothing to do with your performance. The fact is, there are 10 people vying for a single position. All else equal, If we use angular, I'll take the angular person over the jQuery person (emphasis on all else equal). That person will likely chalk it up to jQuery instead of the simple fact that there was an equally qualified candidate with a more specific skill set.

[gambler]

You sound like you have not often worked with legacy code or software architecture teams who choose the "right" tools for you. In large companies you rarely choose the tools you use.

Also, when you feel that you need to learn technologies simply to avoid using them something is very, very wrong. I think that is sort of the point of the article.

[cocktailpeanuts]

In my experience, it's not the developers who fall into this trap, it's the culture--nobody wants to learn some random technology that will probably be obsolete in a year (and I'm not even joking when I say this, this really is the reality)

The only situation where you are not affected is if you're a freelancer and you don't need to worry about what's going on around you.

I'm not going to mention where, but I worked at a well known company which you've heard of (you probably would know it as an innovative company), and everyone who worked there was very talented, there is absolutely no doubt about that. But I got sick of what's happening around me and quit recently.

Here's what happened: In the last couple of years a few people started talking about all this "cool new javascript testing/packaging/templating/single page app building" frameworks. Since it is indeed a "cool thing" to talk about these, and since they believe that potential new hires would be excited to learn that we use these hip new technologies to power our company, they started implementing EVERYTHING that the OP mentioned in the article. Of course, I'm sure it looks really cool from a recently graduated college kid's point of view when they interview. But anyway, suddenly the company culture started revolving around these hip technology advocates. I can understand why but at the same time it's really stupid because they keep switching out their stack and spend their money on useless crap instead of actually spending it on building the actual product. For example, they've transitioned from browserify to grunt to webpack in just last two years.

So when I read this article I totally sympathized with the guy.

If you're a web developer who works at a large company that wants to be seen as "innovative" (especially the ones that are already seen as being technically innovative), this is exactly what's going on. And you only have two choices: You either jump on the bandwagon and become one of the "in" crowd, or complain like the rest and be left behind and seen as a "laggard". When I saw these otherwise intelligent programmers moving like bunch of lemmings to adopt the latest new technology I couldn't help but feel pity for them. They grow old day by day thinking they're becoming a better programmer but all they're doing is learning some library that's designed so that the code monkeys can be managed better. They should be spending less time on those meta things and spend more time on building what a user wants instead. At least that's why I became a programmer.

[marrs]

This is very true and cool shiny new things are hard to counter, mostly because ones instinct is to point out the deficiency in the "innovation", which is often only obvious to you.

The best way I've found to counter this is to give your own demonstration showing how you achieved the same (or better) coolness with existing technology, and you did it faster, and it can be integrated into the code base today.

This gives your argument real substance and people have to at least now argue against facts and data rather than hand-wavy speculation.

[Waterluvian]

When I had no experience I was asked to define the next few years for my company's single page app.

I researched all the major tools and committed to django, react, fluxxor, leaflet. As the major parts. All but leaflet (now OpenLayers) are still around and growing well.

The most important thing is that I got to pick which tools felt most resilient to rapid development and lots of rookie mistakes. Even if they may have been overkill or not ideal or some thing I cant possibly know as a newcomer.

In the past I did chase the dream of the one toolset to end them all and it had me never committing for any meaningful duration.