
Maintainable JavaScript (2014) - akras14
http://www.alexkras.com/summary-of-maintainable-javascript/
======
2pointsomone
Isn't it interesting how React has changed the whole paradigm of "keep html
out of javascript"?

~~~
Swizec
Yes and no. Ideally the main logic part should have none of the html-like
part. Views should be dumb and do as little as possible.

Of course in practice ...

This is def a lot better than what I currently use in production: Handlebars
hacked to the point of almost being JavaScript but not really. Then you both
have views with too much logic _and_ they're annoying to implement.

At least with React you get the full expressiveness of JS right in your views.

~~~
BigJono
I played around with a lot of different architectures for my React
applications, and eventually ended up with something very close to traditional
MVC, with components that are either view components, or controller
components, but not both.

~~~
kowdermeister
It's just about personal taste. MVC is fine, I've built quite a few apps with
that approach. JSX is weird but I still find it a viable approach.
#nosilverbullet :)

------
benjoffe
He uses the following example for when to throw your own errors:

    
    
      var Controller = {
        addClass: function(element, className) {
          if (!element) {
            throw new Error("addClass: 1st argument missing.");
          }
          element.className += " " + className;
        }
      };
    

I don't think this is a very good as a native error will have all this
information already in a stacktrace, and if you're running Chrome dev tools
with 'Pause on exceptions' then you'll be shown the exact place this fails.
Additionally, you need to now keep the function name in sync with the string
(your IDE / build tool will not tell you if they get out of sync).

Better cases for custom errors are situations where a native error will not be
thrown, such as:

\- in his example method: if className is undefined

\- valid objects in a state you don't expect

\- switch statements that don't match any expected case

\- etc.

~~~
blubbi2
Probably easier to just use an assertion library here. E.g.

    
    
      assert.ok(element)

~~~
gcanti
I wrote a library [1] and a babel plugin [2] (bonus point: is Flow compatible)
in order to deal with those cumbersome runtime type checks.

[1] [https://github.com/gcanti/tcomb](https://github.com/gcanti/tcomb) [2]
[https://github.com/gcanti/babel-plugin-
tcomb](https://github.com/gcanti/babel-plugin-tcomb)

~~~
philbo
Heh, me too: [https://github.com/philbooth/check-
types.js](https://github.com/philbooth/check-types.js)

------
131hn
This is nice video/article, but strongly outdated / missing "current"
javascript maintainability standards.

Not so much "javascript" specific advices here.

No words on ES6 classes, that help keeping a meaningfull syntax, rest
parameters, template strings.

No words on nodejs callback as last arg best practice.

No words on generator & promises (nor async await) that totally change
callback behavior. No word on synchronious throw / catch vs callback(err)
pattern.

No words on code modularisation.

This video is 4 years old, believe we, javascript change, a lot (and the
"maintainable" best practice)

No link to mozilla MDN, when it's now a de-factor standard for web & js
documentation.

~~~
navalsaini
Hello. I recently wrote a nodejs framework which makes server apps more
maintainable, by breaking up the app into loosely coupled modules. The
framework is called
[https://github.com/archiejs/](https://github.com/archiejs/) and I have not
yet posted it on show HN because the documentation is inadequate (and the
roadmap is not clearly defined). PS... just wondering if you would like to be
one of the first reviewers

------
partycoder
The way I evaluate if a recommendation is good or bad is how it filters bad
code.

The 4 most important things for me to keep under control are:

1) Length

2) Cyclomatic complexity

3) Shared mutable state

4) Coupling

If you keep those under control, the rest of the maintainability will come by
itself. e.g: testability, reusability, thread safety, security and other high
level goals are easier when these low level requirements are met.

And, of course, consistency. Make sure that things do what they say they do.
e.g: make sure the purpose of a variable or function can be explained only
through its signature without requiring to look at the code.

------
oever
The code examples use ==, which does lossy comparison. Using === is much
safer. The tools section mentions JSLint which flags any use of == as an
error.

JavaScript is such a quirky language that I always want the code to pass
JSLint and Closure Compiler with 100% type annotation. I simply do not feel
confident about the code otherwise.

I'm surprised about the lack of space after 'if'. 'if' is not a function so
'if(' looks weird.

------
deevus
Do people still use Grunt these days?

~~~
jiggly_piff
Webpack accomplishes everything you would need grunt/gulp for and is much more
powerful. Grunt is essentially obsolete at this point

~~~
ehnto
While true, that doesn't necessarily mean everyone needs to run off and learn
Webpack. The treadmill of technologies in JS can be very exhausting so if
Grunt is working for your project, why spend the cycles learning entirely new
tooling?

------
pzh
Maintainable JS? Har har har

------
nittr
can someone summarize it in like 100 words or so

