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.
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.
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 :)
Well it's well known that Facebook is familiar with PHP and I guess with the oldschool PHP mixing code and representation approach. So why not introduce that approach into the React then :)
Only if you're so ignorant of how React works that you don't realize the JSX isn't HTML, it's syntactic sugar/an alias for the React.createElement method.
It's no different than $(<p>) in jQuery, so unless you're referring to some pre 2007 attitude, what are you talking about?
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
First, they don't act like that, and if they do that's dumb.
Second, how is that different from writing in a statically-typed language like Haskell/Rust/what have you and then compiling down to assembly which is for all intents and purposes dynamically typed? We do it hoping to gain safety from the typing, but do we lose the type safety in the machine code? (We don't, the type-safe language rules out compiling to certain classes of erroneous code.)
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.
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/ 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
Agreed, but I always find it interesting looking back at JS applications 4+ years ago (before I was a developer) and seeing how people groked the complexity. The design patterns in particular for javascript are interesting and I believe still the supporting pillars for frameworks such as Angular, Ember, etc. It's easy to forget those patterns in ES6 etc. because you don't need them as much (IMO) and that's probably a loss.
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.
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.
Of course they do, if they've got a working setup. I haven't seen that Gulp is really any faster or easier to setup, so...
I'm way too young to be a grumpy old man, but I kind of wish people had just decided to learn how to use Make instead of re-implementing it over and over.
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?
