3 ms·

I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of '

I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and ignore the rest, like a modern "Good Parts".

mercer 9y ago
Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.
- erikpukinskis 9y ago
  Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern. But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA. Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new. I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together. I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns. Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.
- just_astounded 9y ago
  There are a lot of reasons, honestly, and it's great beer conversation, but from a high level: producing a concrete instance that invokes a constructor function with a shiny pristine 'this' to build on is a pretty great pattern. Add the ability to muck about with clever prototype manipulation, and you have pretty enormous power - you can do everything that classic OOP can do (if that's your thing) and a lot more.

mercer 9y ago

Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.

erikpukinskis 9y ago
Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern. But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA. Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new. I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together. I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns. Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.
just_astounded 9y ago
There are a lot of reasons, honestly, and it's great beer conversation, but from a high level: producing a concrete instance that invokes a constructor function with a shiny pristine 'this' to build on is a pretty great pattern. Add the ability to muck about with clever prototype manipulation, and you have pretty enormous power - you can do everything that classic OOP can do (if that's your thing) and a lot more.