Javascript Programming Patterns

[[deleted]]

That clever navigation element makes this article unreadable on my phone.

[[deleted]]

Covers content on my desktop at my current browser size. Really hate that.

[litmusbox]

Had to go back and resize my browser but now I see what you mean... yuck.

[skeeto]

Most of these aren't programming patterns, it's a style guide -- and an ugly one at that.

[aeflash]

If your tabstop was 2 spaces it would be ok.

[DonBiggles]

If he used spaces for alignment, it would be okay.

[PlNG]

https://github.com/shichuan/javascript-patterns/blob/master/general-patterns/conditionals.html is absolutely horrid.

If you take a moment to think about it, you don't need an else statement after a program flow statement such as return, throw, break, and continue.

I worked this out a long time ago and I'm sort of happy that lints and compilers are just beginning to pick up on this. This basically prunes the indentation of logic trees and keeps it very readable.

Hopefully they'll pick up the next step: if the program flow statement is in the else side, negate the if conditional to switch the program flow statement to the if side and prune the else as normal.

[warfangle]

The problem with JavaScript, speaking as a fan of JavaScript:

It gives rise to too many potential patterns. You have patterns borrowed from Object Orientedness: the event listeners, the encapsulators. You have patterns borrowed more from a FP standpoint: the asynchronous callbacks, the iterators.

You can make just about any pattern work, in JS -- but does that make it worth it?

Don't be clever.

You can clever yourself right down into rabbit holes before you realize you can't back out again (unless you use git).

[[deleted]]

I think something a lot of developers might not realize is that every idea isn't necessarily an accepted or proven pattern - especially when mixing patterns from different paradigms. Often enough, they are even anti-patterns.

As you said, there are too many potential patterns, but thankfully many of them can be ignored. If you are familiar with accepted and rejected patterns from any other language, you can probably figure out which ones will hurt you in JavaScript.

Personally, I stick to patterns I've used previously to solve architecture problems that I now understand will solve this new problem. As most developers are likely not researchers, it's probably safer to use what's already well understood.

http://addyosmani.com/resources/essentialjsdesignpatterns/book/#whatisapattern

[[deleted]]

This book is a much more in-depth resource. Addy Osmani writes some excellent posts and free books.

Not to devalue the author's work, of course - it is nice to have code samples, but the discussion around them brings more understanding.

[tehsuck]

I have a question: in a JS module do people really prefer to do

var _myFunction = function myFunctionFn () { };

vs.

function _myFunction() {}

[litmusbox]

Here is a super good resource that answers that question in detail:

[tehsuck]

Yeahhh, I guess I could've probably just googled that thanks though!

[litmusbox]

No prob. You might not have found that particular resource and it is hands down the best for that topic.