Ask HN: JavaScript developer – what do I need to know? | Hacker News Reader

Ask HN: JavaScript developer – what do I need to know?

46 pointspeterchon44 comments

I feel like I have a pretty firm grasp on OOJS and am proficient at solving any JS problem without using a library. What should I be concentrating on now to be "Javascript developer"?

View on HN

JS doesn't really become a "thing" until you combine it with the web. Learn the new and recent things that are happening with the web platform - Web Workers, Service Workers (Holy crap this will blow your mind when you learn about it.), WebRTC, etc. I'm going to go directly against the grain of the highest-rated comment here (sorry) and say "DON'T learn any of the frameworks" (Angular, React, whatever one they came out with this week) unless you are completely bored with the web platform / ES6 stuff. Reason: Platform stuff will be here 5 years from now. The framework they are all monkeying with (is it React this week?) most likely won't be. Go ahead and learn one of the frameworks if you want to appear erudite in an interview or something, but otherwise focus on things that will stick. (For suggestions, browse "caniuse.com" and read the crap out of anything JS-related you haven't seen/heard of that at least 2 browsers intend on implementing.)

Node. This is the most focused way to become one with "asyncness" in JS.

Lodash. is JS zen. Even if you don't use it for everything, try and "think like it" when you are solving problems.

For grins and giggles go read some of the "Data Structures and Algorithms in JS" posts or books they have. Do different sorting algorithms.

My breakthrough moment in my JS journey was codewars.com . When you see how clever you aren't after understanding other people's much more elegant solutions to problems - only then do you realize what you need to do to get better. True in life - true in JS.

You're honestly recommending he learn about Service Workers, which are, right now, a working draft with partial support in Chrome and Opera and nothing else?

I mean, yes, in a way learning that would give him a taste for what modern development in JavaScript is like, but not really in the nicest sense!

It is live in Chrome 41 right now (with the exception of the cache API, I think, which it can be used without). It is live in Firefox nightly - and they have clearly stated they are bringing it to Evergreen soon. It is in Opera. Even IE has stated "under consideration". (see https://jakearchibald.github.io/isserviceworkerready/ )

It's a lot farther along than a lot of folks realize. And IMHO, the impact of it makes it something that even Safari will have to begrudgingly implement soon after Firefox brings it to production.

If I thought it was anything less than inevitable, I'd say "wait". But for a JS-dev, I honestly think this right now is the sweetspot between "Hot Shit" and "Will ACtually Still Be Relevant in 5 Years". (Think XHR 6-7 years ago.) So, yeah, I stand by the recommendation.

I recently told a friend who is also learning to program that using frameworks is like driving a speedboat, and he was still learning to swim. Yes, the point is that they get you down the coastline faster, but if it springs a leak, it will be really bad to not know how to swim.

jQuery and underscore/lodash might be a speedboats. Backbone might be a small yacht. Just about everything else popular is a cruise ship or aircraft carrier.

Then, if we don't call passengers on cruise ships engineers, then why do we call Angular users engineers?

I wholeheartedly agree with the part about the frameworks. I've been writing JavaScript since it was in beta and I can assure you that you're doing yourself a disservice if that's all you know.

Don't start with a framework. It's a crutch. If you feel you've mastered JS then feel free to try out some of the frameworks but I suspect you'll quickly realize they're not really all they're sold as.

I'm going to second most of this.

> become one with "asyncness" in JS.

This is probably the biggest hurdle most people hit with Javascript. Really understand the concept of asynchronosity, and learn about all the different abstractions over it (callbacks, promises, streams, etc). Then look at how other languages (say, Go and Erlang) handle concurrency. Then come back to Javascript and look at things from a new perspective.

> Lodash is JS zen. Even if you don't use it for everything, try and "think like it" when you are solving problems.

This largely means thinking in a "functional" way (as in, functional programming), and is golden advice IMO. Probably the most common piece of advice I give people that want to get better at JS is to program in a more functional style. Warning to OP: you mentioned having really grasped OOJS - be prepared to let some of that way of thinking go. There's definitely a place for object-orientation in Javascript, but in my experience, thinking in more functional terms leads to much simpler, easier-to-maintain code.

> DON'T learn any of the frameworks

This is where I disagree slightly. I don't advocate trying to become a master of every framework-du-jour that comes along, but I think that discerning the key features and insights from popular frameworks is a good way to augment your skills. React promotes a heavily functional style, and emphasizes "one-way flow of data", which I believe is a very powerful concept. One of Angular's more important features is dependency injection - this can do wonders for the structure of your application. These are just some examples, there's plenty to be gained by reading about popular frameworks/libraries, without necessarily becoming a new flavor of zealot every few weeks.

Lodash looks similar to underscore js[0]

[0] - http://underscorejs.org/

It's a fork, with improvements (speed, [a large amount of very useful] extra methods, a curried version, amongst other things)

• Patterns (FRP, RP, etc)

• Ecmascript 6

• Frameworks (React, Ember, Angular are the big three)

Beyond that, it's important to understand the pain points that people are trying to solve. For instance, why is React a better approach to front-end UI's than MVC? Is JSX a reasonable approach to the DOM, and is it worth breaking conventional wisdom? What problem does Facebook's css-layout solve? What issues with modularity and reusability are people trying to solve, and how is this different at different scales of complexity? What's the "why" behind the changes to ES6?

And even beyond that, look at the future, and see what people are trying to solve that nobody has quite solved yet.

In other words, don't just understand what you can do with Javascript, understand what hurts and how people are trying to fix it, or at least make it hurt less.

It's really weird to me trying to do a lot of data handling on the front-end side rather than using server-side.

I spoke to one acquaintance about this after he told me that for his team, they are doing the calculations on the frontend mostly - his explanation was that it turned out to be too unperformant to cache precomputed values in a remote database (and even in IndexedDB) and pull them out (his company does a lot of work involving heavy data analytics & visualizations).

Especially considering how fast even the slowest computers of today are, the client-server architecture gives us the option to immediately decentralize calculations across all clients as needed. It's an easy optimization that's hard to give up, but does present it's own challenges.

You should usually be doing 'data handling' wherever results in the best user experience. Persistence and calculations which are essential to the integrity of your application's data obviously need to be done (or at least validated) on the server, but if the application has any kind of complex workflow then constantly going back to the server to generate new application states is likely to severely bog down that workflow.

Instead of learning Angular, learn Meteor, React, and/or Ember. Just trust me on this one..

See if http://eloquentjavascript.net works for you. It doesn't focus on OO, but that's okay, because trying to model everything as OO in JS is going to be painful.

yes. yes it does.

The first few chapters of this book are, to the extant that I'm aware, the best introduction to the concepts of programming in existence.

Also, the online version of the book features an inline code-highlighting text editor from the same author as the book. You can use it to edit and evaluate the examples. It's actually the same editor used in the Chrome developer tools.

If you're focusing on OOJS then you should be focusing on learning other programming patterns in JS, because it isn't meant to be used in an OO context.

Look into stuff like functional programming, reactive programming, contextual programming. Learn the patterns and learn to apply them in your projects

I guess that was the problem I faced when I started down the OOJS - what do I exactly use this for? I understand that it's a great way for reuse & extending, but aside from giant applications with numerous developers, is it really useful?

Well with any program language you can solve a multitude of problems I guess what you need to do is start by learning the concepts from the basics

http://eloquentjavascript.net/1st_edition/chapter6.html

Also maybe look at larger libraries like underscore, lodash and get acquainted with the programming concepts they apply since they are well maintained libraries.

I read you are familiar with AngularJS, get into the source code, understand how the beast works. Get your hands dirty, maybe build something into the angular library itself just to test it out.

This comment is really one of my pet peeves. Javascript is absolutely meant to be "used in an OO context" -- everything including functions have been designed as objects since very early on in the language. It does not implement classical inheritance, sure, but classical inheritance isn't a mandatory design pattern for a language to be considered OO.

Functional programming & reactive programming are absolutely valuable, though, and fulfill very real design patterns in Javascript. They're great skills to learn. No one reading this comment should come away thinking that OO is not absolutely important to JS, and that if you try to solve every problem in JS without utilizing it's aspects, you're probably hamstringing yourself without need.

- Location of a good bar near your workplace.

- A taste for strong drinks.

- An ignorance of how nice other languages/environments are.

I have been reading through this awesome book series called You Don't Know JS (youdontknowjs.com), and it's helped me SO MUCH to understand JS at the next level.

I had the immense pleasure of taking a workshop with Kyle Simpson, the author, at a conference last year and it covered much of the material from his books. In particular I found the book on 'this' and object prototypes to be fantastic.

I'll have to check that out - thanks!

http://wtfjs.com

interesting find. It's a wonder that JS is moving into everything.

Every language has its idiosyncrasies, annoyances, and wtf's. Because they're written by humans who have idiosyncrasies, annoyances, and wtf's.

JS is moving into everything because it's easy to learn, reasonably expressive, and is accessible. It may not be the best but often as not its the "good enough" that seems to rise to the top.

In other words; you're better off accepting it for what it is and doing the best you can with it.

Better off compared to what?

Fighting it, complaining, being miserable. None of which will get you anywhere really. If you hate JS that much it probably makes sense to focus your efforts towards a different kind of development than web.

"If you don't like something, just forget about it and do something else."

I can't wait to teach that to my kids.

No. It's moving into everything because it's well established in browsers. Otherwise nobody would use it.

Thus it being "accessible".

the fun bit is going through it and realizing that at least part of those "wtf"'s are because people don't understand basic programming.

I think Rebecca Murphey's latest "Baseline" post [1] covers this pretty well. Not sure I'd include Node, but ES2015, modules, testing and build tools/automation for sure. You should know your way around the browser dev tools, have a good handle on async and promises and understand the DOM and events.

[1]: http://rmurphey.com/blog/2015/03/23/a-baseline-for-front-end...

Closure/ Promises.

I am surprised by how many js developers that I personally know are unaware of them.

I think you need to get hands on Front end JavaScript frameworks like AngularJS. Also you should be comfortable with widely used JS libraries and plugins (bootstrap, J query etc)

I have a pretty solid understanding of AngularJS, and I can't really think of any project that really <i>requires</i> jQuery.

Yet many projects do use jQuery, so if you're in an interview you should be able to say you've built a jQuery plug-in.

If you haven't already, start compiling a portfolio. Show what you can do, and all the better if you can show that what you've worked on has practical use.

I have, but I'm having hard time creating projects that uses (or rather justify using) the higher-level JS programming paradigm.

Build a social network to compete with Facebook.

I kid (I tried to do the same thing), but in reality, the higher level programming paradigms come into play when your software complexity increases to unmanageable levels.

Building small projects won't help you understand why they're necessary.

Are you looking to develop server-side projects in javascript, client-side applications, or both?

Reply on news.ycombinator.com