Maintainable JavaScript (2014)
alexkras.com
Maintainable JavaScript (2014)
1–10 of 33 posts
Re: Maintainable JavaScript (2014)
#2Re: Maintainable JavaScript (2014)
#3Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
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.
Re: Maintainable JavaScript (2014)
#4Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
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 expres…
Yes, just like React advocates.
Re: Maintainable JavaScript (2014)
#5Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
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 expres…
Re: Maintainable JavaScript (2014)
#6Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
Re: Maintainable JavaScript (2014)
#7Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
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 expres…
Re: Maintainable JavaScript (2014)
#8Earlier quoted context omitted.
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 expres…
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.
Re: Maintainable JavaScript (2014)
#9Isn't it interesting how React has changed the whole paradigm of "keep html out of javascript"?
It's no different than $(
) in jQuery, so unless you're referring to some pre 2007 attitude, what are you talking about?
Re: Maintainable JavaScript (2014)
#10 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.