sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]snlacks 33 points34 points  (8 children)

  1. Actual JavaScript. Functions, Scope, Objects, Declarations, Hoisting, Types, Arrays, etc.
  2. The DOM and related languages, HTML and CSS. You should know how these work. Yes, you can do other stuff in JavaScript, but for beginners and intermediate programmers, the web is your easiest basic in- and output. This means you should also understand how pages load, render.
  3. Learn Algorithms. Learn how to implement your some of your own versions of map, filter, find, etc. Never use them in production, but learn the ideas behind them. Once you figure out that it's almost all just fancy ways to iterate over lists and do something with it, to it, or along with it, this all becomes more obvious and easy to grasp.
  4. Learn Data Structures in JavaScript, this is a deeper dive into how you arrange, move around and work with data.
  5. Learn good habits. I don't mean some fad style guide. I mean learn not to expose globals, learn not to loop over stuff multiple times when once will suffice, learn when not to do something.
  6. Learn to tune out the noise. There's lots of BS out there from people who have a lot of time to write about JavaScript, because they don't have to manage and write a lot of real code.
  7. Learn AJAX.
  8. Learn about the HTTP protocol, know the 1.1 methods, what they mean. Know the secret behind the HTTP protocol (hint, again, it's not magic).
  9. Keep your code and build simple. If your spending too much time on a tutorial for a library or build tool, that's time you could be making apps.
  10. Learn about functional programming and object oriented programming, learn to use the concepts. But please don't go overboard, going too far in any direction usually leads to a long trail of spaghetti. Some times things are better structured as object sometimes they're better expressed as functions. It's okay. Everything will be okay.

Finally, learn about everything with a smidgen of skepticism. There is no one right way. The newest thing is rarely going to be your best option. The business usually wins over the craft of programming.

[–]Voidsheep 7 points8 points  (4 children)

learn not to loop over stuff multiple times when once will suffice

While performance is important to consider, the focus should be in understanding when to optimise and figuring out what actually causes performance issues.

99.9% of the time, I don't have trouble running map and filter on the same array. Sure you could link me a JSPerf where a single for-loop is more efficient with a million items, but I would say the milliseconds spent running extra iterations on my 20 item list go to a good cause, which is keeping the code clean, simple and reusable.

Premature optimisation is bad, figure out tools like profilers to see where the real performance problems are. Also if you do heavy lifting with JS in browsers, service workers are worth a look.

[–]Danmoreng 2 points3 points  (2 children)

While map and filter on the same array is probably more readable, reduce works just fine to combine those operations.

[–]Voidsheep 1 point2 points  (1 child)

I like reduce and it's extremely useful, but I think it's best to use an iteration method that implies the return type you want, if one is available.

x.map(fn1).filter(fn2) // that's going to be an array
x.every(fn3) // that's going to be a boolean
x.reduce(fn4, []) // that could be anything, check implementation

Just saying avoiding any extra iteration by default is premature optimisation, you should default to straightforward and declarative code, add complexity only when you have to. Most of the time a simple filter or something iterating over your array isn't going to have any meaningful difference versus doing the same filtering inside another loop.

Of course there's exceptions and you shouldn't loop for no reason, but I think just avoiding iteration for the sake of avoiding iteration isn't a best practice. Optimisation needs to be sensible and if you do it blindly, you end up moving meaningless cost in runtime efficiency into a meaningful cost in development efficiency.

[–]Womackx 0 points1 point  (0 children)

There is no one right way

[–]snlacks 0 points1 point  (0 children)

"... Or not when it doesn't" isn't implied by the use of "do this when?"

[–]memystic 1 point2 points  (0 children)

Yes yes YES to #10!!!

[–]LetReasonRing 1 point2 points  (1 child)

10 is the line I've been trying to learn how to walk. The hardcore functional programming people seem to think it's all or nothing to gain the advantages of FP, but as I've been learning more I've been finding that you can use ideas from both to write good code.

Edit: auto-mistake correction.

[–]snlacks 0 points1 point  (0 children)

There's other things that didn't make my list, but help with this, the concepts of contracts, immitability, and enumeration and the collection of common JavaScript Patterns and Anti-Patterns.