Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A class action


Published on

A dispute on probably the most controversial feature in ES2016 leads us back to age old questions at the base of the most common practices of the development universe.

Do the “sacred laws” still apply?

jsDay 2016 closing keynote (

Published in: Software
  • Be the first to comment

A class action

  1. 1. Luciano Colosio Good morning, my name is Luciano,
  2. 2. @unlucio you can google me as unlucio. I am a nerd and today I’ll be playing the prosecutor in this case
  3. 3. A Class Action It is my pleasure to represent the people of this language as we’ll discuss a controversial matter dividing opinions in the last years.
  4. 4. ES6 ES2015 class In 2012 a new keyword was proposed as a new addiction to what it will became better know as the 6th version of the ecma script standard
  5. 5. class I beg you a moment to contemplate this word. How can, such a small and simple word, be considered so harmful by many?
  6. 6. Ladies and gentleman of the jury, I will call three witnesses to the stand.
  7. 7. The Function My first witness will be the Function. We all here know the function, we are well aware of her meaning and powers. It’s well known how her been higher order is an empowering feature in our daily job. Did we really need a shorthand for manually defining a constructor Function?
  8. 8. The Prototype As my second witness I call to the stand the Prototype. This gentleman deeply influencing the nature of the language will see his daily job getting even more miss understood and hidden.
  9. 9. The Class And at last I’d like to call to the stand The newly introduced Class. Does she really add something new to the language? And most of all: will she simplify the life of everybody use to other languages and to the classical object oriented programming?
  10. 10. So this was the idea: investigating a new feature through the scene of a trial. And showing how our “class” character would turn out to be essentially conman.
  11. 11. it’s able to declare a constructor sure, just like the Function is able to do. Adding properties and methods to the constructor’s prototype, just like we already use to do. No matter how you look at it, hardly class can be defined as any kind of addiction to the language.
  12. 12. class No matter how I looked at it but the class case was pretty simple
  13. 13. Sugar. Syntactic sugar. This is how we quickly cut it off. Almost as pointing out that is not such a big deal and it doesn’t change much: it’s suppose to make our life sweeter.
  14. 14. and It’s easy to get excited for stuff that seems to make our life sweeter. Right?
  15. 15. I mean, think about promises. They’re a great tool, I love them but it’s easy to get carried away.
  16. 16. not always: I remember reading of promises as the solution to the Xmas tree hell
  17. 17. Yeah, but OOP is good for you… at least that what they say.
  18. 18. Don’t get me wrong: Classical oop is great, except when is not: - Huge dependency trees can get messy and cause over structuring and over engineering
  19. 19. new GlassOfWater(); and all the sudden you find a reef in you drinking water because some how it ended up depending from the Ocean.
  20. 20. and any way Dispise you can create instances for “class” defined objects only using “new”, Class still doesn’t create a blueprint. Applying the classical oop, often struggling with the prototypal inheritance, we want familiar instruments.
  21. 21. (it’s better to look at the graph from right to left) Under the hood this is still happening and Object.create() is a way better and more expressive way to imply this kind of behaviour. Just think about what’s happening here and what are the side effects: calls traversing the hidden links and going up in the chain to fulfil a request.
  22. 22. What is Prototypal inheritance? but wait a second: there seems to still be some kind of confusion about prototypal inheritance? Is it classes? Is it blueprints? Is it super? No, none of these
  23. 23. Code Reuse Isn’t it all the point? This is what we really care about Write code once, use in multiple situations (sometimes the most used way is still copy&paste) prototypal inheritance makes this easy don't think about new, super, and extends don't even think about javascript's prototype property Prototypal inheritance is about fallbacks
  24. 24. var base = { firstName:"Luciano", nickName:"unlucio", getFullName: function() { return `${this.firstName} (${this.nickName})`; }, }; // base is the fallback var obj = Object.create(base); // where the magic happens obj.alertName = function() { alert(this.getFullName()); }; obj.alertName(); // Luciano (unlucio) // this is code reuse! console.log(“getFullName" in obj) //true console.log(obj.getFullName === base.getFullName) //true
  25. 25. it doesn’t seems to be that hard :D
  26. 26. This is pretty nice but actually I don’t remember the last time I used it. actually i don’t remember the last time I really used inheritance anyway (in javascript).
  27. 27. On the other side as javascript widespread it’s impossible not to note how functional programming gains more and more traction. Ramda, lodash, the introduction of promises, map, reduce in ES6
  28. 28. Is it classical oop still a thing?
  29. 29. Functional VS Object Oriented So Which one should we use?
  30. 30. Functional -> minimised Object Oriented -> segregated It’s about State Since the beginning as programs got more and more complex the “state” problem rises. Pure functions shouldn’t deal with state, so we deal with the problem minimising the state. In Object Oriented we package the state in units called objects.
  31. 31. And if you think about minimising the state and segregating what’s left over is something we do in distributed systems as well since dealing with lots and shared states goes towards madness.
  32. 32. Functional VS Object Oriented
  33. 33. Functional + Object Oriented What about using them together?
  34. 34. do we really need class? But… Does class and classical oop really help in all this? Well, minimising the state is something only our brains can really do at design time. What about segregating what’s left?
  35. 35. What about modules? - they have their own isolated scope - they’re easily reusable (which is mostly what we care of) - has its own scope and expose a convenient api (kind of like a service in a soa) - seems pretty easier than what happens in, let’s say for example java ;P
  36. 36. Let’s just try to not go nuts on modules now ;) I mean, the mind blowing growth of the javascript ecosystem is well known and very positive, but sometimes the frenzy for pushing and using the latest module can be potentially harmful. unpublishGate? Do we really need an pm module for 15 lines of code?
  37. 37. A D V I S O R Y Controversial Content any way: You might strongly disagree from this point on. Let’s talk about coffee for an instant.
  38. 38. The espresso, as we enjoy it in Italy. When coffee is good you don’t need sugar…
  39. 39. Some others might actually like it sugared. I use to, until I tried and learned how more enjoyable coffee without sugar can be. In the same way I understand why “class” was an highly requested feature, for years I used the classical oop and I still do in those languages where it makes sense.
  40. 40. And really, to me “class” seems really more like aspartame more than sugar. The difference is that aspartame can kill you.
  41. 41. @sandropaganotti 4 years ago a friend come back form a conference in london telling me: “Hey, you know what? Objects are just a side effect of functional programming” and he blew my mind starting my journey away form the classical OOP.
  42. 42. So by the end it’s always important to understand our tools, their meanings and how they work.
  43. 43. It’s not always easy, nor it’s quick and there are a million variable all around. I changed many languages in my professional life. I was taught that the good computer science professional should learn at least 1 language per year.
  44. 44. But in case of javascript I always felt more like the general approach, rather than proving the necessary paradigm shift, it’s more about turning it in something more and more familiar because for one reason or another more and more people need to deal with it and it’s easier to stay in our comfort zone.
  45. 45. In our career we all build up a pretty significant baggage of experiences
  46. 46. dedicated to @cirpo But sometimes is good to let go, exit out confort zone and let it go. Re-mesh all what we learned and what we know. (please tweet to @cirpo the frozen song in your native language)
  47. 47. Because the real building blocks are simply all our experiences, and the real reusability comes from our ability to turn and compose around all what we know.
  48. 48. Thank you very much for listening, and happy coding.