6 ms·
Maintainable JavaScript (2014)
- 2pointsomone 10y agoIsn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
- Swizec 10y agoYes 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.
- wereHamster 10y ago> Views should be dumb and do as little as possible. Yes, just like React advocates.
- BigJono 10y agoI 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 10y agoIt'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 :)
- kowdermeister 10y agoI ditched handlebars because of that. I used dust and some twig implementation.
- vladimir-y 10y agoWell 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 :)
- Dr_tldr 10y agoOnly 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?
- benjoffe 10y agoHe 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 10y agoProbably easier to just use an assertion library here. E.g. assert.ok(element)
- woah 10y agoEven easier- typescript or flow
- Touche 10y agoAdding a build step adds complexity.
- malcolmgreaves 10y agoNo. Using a weak, dynamically typed language adds complexity. Using a compiler isn't adding complexity.
- ben_jones 10y agoExcept the transpiled code is still dynamically typed. People act like when they started writing Typescript they stopped writing bugs..
- pzh 10y agoMaintainable JS? Har har har
- kimshibal 10y agoI handle a big React app at my job. It's messy as fuck with JSX. We made a transition to Vue. Couldn't be happier.
- deevus 10y agoDo people still use Grunt these days?
- douche 10y agoOf 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.
- jiggly_piff 10y agoWebpack accomplishes everything you would need grunt/gulp for and is much more powerful. Grunt is essentially obsolete at this point
- ehnto 10y agoWhile 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?
- deevus 10y agoNot sure why I got downvoted. I was legitimately interested.
- nittr 10y agocan someone summarize it in like 100 words or so
- oever 10y agoThe 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.
- 131hn 10y agoThis 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.
- ben_jones 10y agoAgreed, 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.
- continuational 10y agoNot to mention Flowtype or Type Script.
- navalsaini 10y agoHello. 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
- deleted 10y ago[deleted]
- partycoder 10y agoThe 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.