Hacker News Reader

Comment by SirensOfTitan | Hacker News Reader

I've noticed this spirit of "learn everything" all over the React and JavaScript community, and I don't think it's a good thing.

Learning happens contextually as you figure things out. I see no use to learning half of the things on here that you'll never use. You do risk, however, in the confusing and complex JavaScript landscape, getting paralyzed by choice and never getting off the ground. I shutter thinking about how large some peoples' `package.json` files are.

There will always be a better way to build and some better technology. Build based on what you know and know how to pick tools when you run into a wall. When you need to refactor, you'll have a much stronger appreciation for /why/ you need some tool anyway.

View on HN

This exact ideology hindered me when I first started learning to program. If I had decided to learn Just Enough To Get Crap Done I would've fared much better and joined the industry much sooner.

Thankfully I found a good mentor who helped steer me away from all the terrible specifics and trying to learn the full stack and only learning what I needed

Any advice on finding a mentor?

This might sound bullshit but I found one via "LinkedIn Career suggestion" and he's given me some great perspectives.

Not "perfect" but sure its good

Appreciate the reply. No need for perfect :^)

or advice on what to focus on then? when ur a beginner its tough to know how much is just enough to get done. and its not easy finding a mentor either!

It's not bad to offer suggestions on what to learn if you're looking to solve some particular problems. It's a cheat sheet. But cheat sheets like the one OP linked to scare people like me away! It shows everything all at once without any context as to why you would want to use each part over its alternatives (including none).

If I made a chart like this one, I would take out CSS preprocessor section completely, replace the whole Build Tools section with "create-react-app", remove PropTypes and Flow in favor of TypeScript, move the State Management into a separate de-emphasized chart, and a bunch more.

Once a deadline hits, it's a little late to START learning (some percentage of learning will always have to happen, but its a bit rough if it's a big piece, ESPECIALLY if other people around you don't have to. If this happens all the time, it starts looking bad on your performance).

Then you add the fact that learning something similar to what you already know is much easier than going from scratch (eg: learning a state management pattern/library if you already know another is much easier than if you have no experience with them).

You're totally right that learning everything up front is a waste of time, but you do need SOME foundation, especially as more and more people enter the market and you start competing with candidates (the days of infinite entry level positions are coming to an end, if they ever existed). That map looks like it's a lot, but it really isn't, especially if you think of it as "things you should have cursory knowledge of" rather than "things you should be expert in". Eg: I've never built a production app with the CSS libraries mentioned (even Bootstrap I've only used in throwaway projects for a few hours), but I've taken a peek at the doc of most of them, so I at least know where to start if it's ever necessary.

Who cares about face. The best time to learn is when you have to. That's not to say be lazy, it's to say continuously challenge yourself so you frequently "have to".

It's not about face. It's about being able to effectively deliver stuff without needing to blow all estimates because you have to learn everything.

My family doctor constantly has to learn about new things, but he needs to have a basic foundation so he doesn't have to learn everything every time a new patient comes in the door. If he did, I'd go see someone else.

Very true, in the end everyone has limited time and it's impossible to learn everything. However, I do personally like roadmaps/guides like this since, as a beginner, it's hard to figure out what you dont know. So being able to see a list of what's considered some of the most important/relevant topics is useful in that regard.

Still I totally agree that getting paralyzed is a big problem, it's way better to program something "the wrong/inefficient/bad way" rather than to program nothing. A big part of my learning and growth as a programmer has come from coding something terribly, realizing "hey, this kinda sucks, I bet there is a better way to do this.." and googling a bit until I learn a new/better method of doing X.

> Still I totally agree that getting paralyzed is a big problem, it's way better to program something "the wrong/inefficient/bad way" rather than to program nothing.

I'd argue that this depends on the situation. If you're writing code that needs to meet a deadline but also needs to be supported months/years from now, there are considerations and the possibility that you'd have been better off not writing the code before learning about at least the reasonining behind the existing alternative

Still, I'm with you on GTD being my personal preference in most situations.

Definitely agree with that, it's a tough balance between code quality and efficiency. But at least as a beginner that is trying to learn new things, you usually don't have to worry much about things being supported later on compared to just getting something out there/working and improving as you go along.

As one grows old we learn to avoid learning every new fad until dust settles.

I saved a few brain cells by not bothering with GWT, CoffeeScript, mootools, YUI, prototype...

Now is a good time to learn front-end tech. Skipping YUI was good, but you should learn at least one of Mithril, React, Preact, Inferno. I recommend Mithril for learning and React for job opportunities.

It's OK to have skipped CoffeeScript, but you don't want to skip TypeScript in 2018. The past couple of years have been good as it has increasingly harmonized with ES6.

Sure, native front-end tech.

This Time It's Different™

No thanks :D

You can work perfectly fine in the industry without typescript.

Not for much longer. TypeScript is such an easy productivity boost compared to JavaScript.

I think you mean different things under “the industry”.

I'm perfectly happy in ClojureScript to be skipping TypeScript and most of the JS ecosystem :)

Not everything on the web has to use the normal stacks. I used TypeScript in the past but didn't enjoy the complexity of most JS libs, even with typings. Clojure was a breath of fresh air, and still is.

mithril should be the default choice for everyone. no compiler, no file format, no commandline tools, comes with its own router and request functions, and is 8kb.

That's silly.

GWT was a solid platform for quite a large number of years, and is still used in quite a large number of enterprises. Also, there are a lot of good ideas in there that the JS community is only just catching up to, like dead code elimination.

A lot of modern javascript/typescript syntax is inspired by CoffeeScript. And CS is so trivially easy to learn that "saved a few brain cells" sounds like intellectual laziness.

There's a fair argument to be made for not jumping on the bleeding edge. But your examples are all mature technologies that had good solid lifespans during which people used them to build successful products. If those are fads to you, I'm guessing you must still do most of your work in C?

Plain old good Java, C#, C++, JavaScript and SQL.

Since 1993, C only when not allowed to use C++ instead.

Honestly, have you ever stumbled upon a job offer requiring any of those while looking for a job?

I'm not saying that job offers requiring e.g. coffeescript don't exist, I'm asking how much more likely you are to find a job that suits you because you know coffeescript?

I think job postings hide those requirements by not advertising them on purpose. They just kind of spring them on you in the first day and if you don't know it you will pick it up. Which is mildly ironic because they advertise all the technologies which you must have 5 years experience in or you won't be considered. I kinda don't buy it anymore.

Today? Not many coffeescript projects getting started today since ES6+ adopted much of the syntax. But there were tons of GWT and CS jobs before... actually, there still are plenty of GWT jobs.

> I've noticed this spirit of "learn everything" all over the React and JavaScript community, and I don't think it's a good thing.

I strongly disagree there. The only way for an engineer to make good decisions as to what tools / framework to pick from is to know and understand as much tech as possible.

It is fundamental for an engineer to do this job of tech-watching in order to not become religious and blinded by the tool it's currently using.

React is good , but it has it's own issues. If you don't do the effort of learning other tech ( Angular , Vue ) you have absolutely no idea what those issues are, and you will just learn how to work with them ( Atomized ecosystem , Heavy Boilerpate ) and basically accept them as a normal thing.

They aren't.

Learning other tech makes you more encline to try new things and to criticize the tool you are working with and how to improve them.

Strong disagree to your strong disagree. I understand right tool for the right job, but for the job of"front end framework" React vs Angular isn't hammer vs screwdriver, or even sledge vs ball peen - it's like Dewalt vs Milwaukee, claw hammers both. For a given class of problem, your comfort with the technology will outweigh the edge cases you hit with one choice vs another. So pick your favorite hammer, screwdriver, saw, and tape-measure. If someone else hands you theirs sure, use it, but the time you spent learning the ins and out of everything is _way_ more than any time you will save.

React is a view library that doesn't even provide a way to do XHR requests. Angular is a complete framework. They are very much hammer and screwdriver, completely different and incomparable tools.

There seem to be a lot of people thinking front-end is just a mess of different options all doing the same thing. And the same people show little understanding of the complexities and nuances of front-end solutions.

OK, to be explicit: React ecosystem vs Angular. The difference between to two is how to separate the concerns - inside on large package or into an ecosystem.

I work primarily in Django. I could have given the same comparison of Django vs Flask. The pedant would say flask doesn't have an ORM, and would be correct.

Given the context of this article and HN in general I thought the shorthand referring to React generally would be understood.

I'd much rather work with a developer proficient with C, Java, JS, React, DDD and a deep knowledge of Unix than someone who has spent the majority of their time on JS, Backbone/Knockout/Angular/Ember/React/Vue/Mithril, Redux/MobX/Vuex and Grunt/Gulp/Brunch/Webpack.

Knowing how a technology works is important. Knowing technologies needed to accomplish tasks to be done is important. Knowing seven different technologies that accomplish the same thing is at best a marginal benefit.

Your entire JS ecosystem should be narrowed down to React, Webpack, and maybe Redux. Easy

My "JS ecosystem" no longer includes any of those three.

I’m on your side, but the “why” is simple: a lot of people hiring will want someone to know these things. Not all or even half, but there’s a disconnect between people learning for fun vs people that want a job ASAP.

Reply on news.ycombinator.com