14 ms·
Introduction to Object-Oriented JavaScript
- hoare 11y agoWouldnt the only thing that js need to be fully oo be a proper inheritence? Prototyping has its advantages too though
- sup 11y agoThat's coming in es6
- oldmanjay 11y agoI know people are crying out for this, but I can only shudder inside at the unholy mudball messes that will result. Inheritance is one of those things we shouldn't let anyone use until they're 40 or so.
- leonatan 11y agoOr, with great power comes great responsibility, and we shouldn't let uneducated and untrained quick-buck "developers" work on our software.
- oldmanjay 11y agoWell to be fair to myself, I was mainly making a joke. But the simple truth is that inheritance doesn't bring new power to the table, just syntax sugar, and with great sugar comes diabetes and painful death.
- EugeneOZ 11y agoClasses is a big enough portion of sugar to change expression level of code. After writing ES6 few months I don't like to write ES5 again, when I have to, and there is a lot of people who think so. Arrow functions is the another (if not first) big thing which makes this feeling stronger, and it's just a syntax sugar also. OO in ES5 looks less readable and less.. "native" than in ES6. Hope in some ES version 'this' insanity will be fixed and all will be just fine with classes. just for note: I have never used "extends" in ES6.
- Jweb_Guru 11y agoInheritance is barely ever necessary, or even important, for any software problem, real or imagined.
- hoare 11y agoim rly in love with typescript right now, looking forward to es6!
- hughw 11y agoI just had my first exposure to Typescript recently, and the only part I liked was the fact that it allowed me to mix in plain old, untyped js syntax. TS, used as TS, feels verbose, like java, with lots of extra keyboard-typing to create a simple program.
- ahoge 11y agoWith optionally typed languages like Dart and TypeScript, you only have to add types to things like fields and functions/methods to get all the tooling benefits. Type inference takes care of the rest. Secondly, you should be able to auto-complete pretty much everything.
- hughw 11y ago"you should be able to auto-complete pretty much everything" Requires tooling.
- discreteevent 11y agoEh.. grep is also a tool? Every function you write is a tool. The whole industry is built on tools and tools that make tools..
- hughw 11y agoSure. But programming languages whose claim to utility lies in an IDE -- they aren't necessarily bad, but it's not a programming language you're selling me, it's a whole environment: MS Visual Studio or whatever. A complex language requires lots of tooling like that, and a simple language doesn't. I have never missed autocompletion in Javascript, but I cannot function without IDE support in Scala. We're off the topic of OO in Javascript, but I wanted to make the point that I don't automatically consider that "IDEs can autocomplete" is a positive feature -- if you need autocomplete, that's a problem.
- cygx 11y agoInheritance is no fundamental property of OO systems, and JavaScript has always supported it anyway (it just did not provide syntactic sugar). JavaScript always has been an object-oriented language - arguably just not a partcularly well-designed one, and not a pure one (as not all computation happens through message passing).
- ExpiredLink 11y agoBut why? JavaScript obviously wasn't made with object-orientation in mind.
- stesch 11y agoThat's why every framework invents its own kind of OO for it. :-(
- Matachines 11y agoJS isn't OOP and it doesn't need to be. Please read this instead: https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 https://medium.com/javascript-scene/the-two-pillars-of-javas...
- erikpukinskis 11y agoIf you're trying to say that OOP isn't the central organizing principle of JavaScript, then I 100% agree with you. Lambdas and closures are awesome. However, JavaScript does have the "new" keyword, and I would argue that constructors are quite central to JavaScript and good idiomatic JavaScript uses them. And it exposes YourConstructor.prototype, which I would argue is also useful. So I guess maybe you're saying something about the term OOP that I don't understand. Maybe OOP means "everything is an object" to you? Or it means multiple inheritance? I guess I don't understand the distinction you're trying to draw when you say "not OOP".
- EugeneOZ 11y agoArticle of the same author, on the related subject: https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf https://medium.com/javascript-scene/how-to-fix-the-es6-class...
- zachrose 11y agoThere's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this. 1) Using object literals for values. 2) Using object literals with functions. 3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`). 4) Using the `new` keyword. 5) Designing objects with inheritance hierarchies or prototype chains. 6) Designing mutable and stateful objects with indefinite life spans. I don't understand the arguments that classical-ish inheritance in JS is bad while prototypical inheritance is somehow better. I've worked in codebases that liberally extend objects into different types of objects with long prototype chains, and IMHO they suffered from the same problems that people complain about in classical inheritance: tight coupling, premature/wrong abstractions, gradual violations of open/closed, etc. Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.
- kremlin 11y agoThis is just in time. I just read a chapter in a JavaScript book about OO programming in JS and finished the chapter very confused. It demonstrated about 12 different patterns people have used for creating 'classes' and 'subclassing' them, each with a list of advantages and disadvantages. Eg there's the 'parasitic instantiation' and then there's the 'Constructor pattern' and then there's the 'Parasitic Constructor', and there's like 3 other patterns that have their own permutations. Coming from Python and then Java, where classes just work...it's kind of annoying. [edit] I was being a bit hyperbolic, the book discussed 6 ways of inheritance in JS, those being (1) Prototype Chaining (2) Constructor Stealing (3) Combination Inheritance <- most popular one according to the book (4) Prototypal Inheritance (5) Parasitic Inheritance (6) Parasitic Combination Inheritance <- pattern that is generally the best according to the book
- woah 11y agoInheritance is rarely necessary
- cnp 11y agoWhen will people start releasing ES6 editions of things? Seems so old school when you can simply write `class Foo extends Bar {}`
- bkurtz13 11y agoNow you're being old school. It's called ES2015 now! ;) (edit: app I was using chopped my comment...)
- cnp 11y agoTrue true, though it's more characters to type :) And is ES7 going to be called ES2016? (Considering how JavaScript is starting to run everything there is a certain long-term logic to this naming approach.)
- thomasfoster96 11y agoES7 is still ES7, and ES8 is still ES8. I'm not even convinced ES6 got renamed - nowhere apart from HN comments have I seen it called ES2015.
- deleted 11y ago[deleted]
- thomasfoster96 11y agoI'm still worried that the idea of a namespace is still being thrown around in JavaScript. If you've used PHP (which presumably quite a few inexperienced programmers might have before they get into JavaScript), JavaScript namespaces act nothing like PHP namespaces. A JavaScript namespace is just a global variable. Nothing fancy.
- bbcbasic 11y ago> Or we can set this explicitly using Function#call (or Function#apply), as shown at the end of the example. Or we can define a variable self in the class, set self = this in the constructor, and refer or that hereon.