E Ottaviani Aragão Blog Projetos Sobre Mim

Master's Advice: Chapter 1— Stop using this on Javascript

Photo by Angela Compagnone on Unsplash

Throughout my career as a front-end engineer, I’ve experienced several eureka moments — those flashes of insight that reignite my passion and fuel my drive to learn and grow. These moments have energized me and inspired me to push forward in my journey for knowledge.

To reach these transformative breakthroughs, it’s essential to embrace challenges that push you out of your comfort zone. Only by shifting your mindset and experimenting with new approaches can you unlock those powerful realizations.

During my early years studying Computer Science, the focus in academia was all about Object-Oriented Programming (OOP) with languages like Java and C++. Back then, JavaScript wasn’t even considered a “real language.”

Determined to elevate JavaScript to that status, I put all my effort into mimicking OOP concepts within it, pushing the language to fit into the paradigms I was being taught.


var Person = {

    staticProperty: 'Hello',

    Class: function( name, age ){ 

        this.name = name 
        this.age = age 

        this.greetings = function() {
            console.log('Hello there! My name is', this.name )
        }
    }
}

var person = new Person.Class('Eduardo', 24)
person.greeetings() // Hello there! My name is Eduardo

console.log( Person.staticProperty ) // 'Hello'

That’s what my code looked like 12 years ago. I even implemented concepts like abstract classes and polymorphism — anything to make JavaScript resemble traditional OOP and prove myself as a “real programmer” to my back-end coworkers.

At the time, the role of Front-End Engineer didn’t really exist. Most front-end developers were designers who primarily worked with HTML and CSS, while JavaScript tasks were often handed off to back-end developers.

This was the gap I stepped in to fill at the very beginning of my career, carving out my place in a rapidly evolving field.

Stepping into the Senior Phase

At one point in my career, I was determined to become the best Senior Front-End Engineer I could possibly be. It wasn’t about holding a “Senior” title at a company — it was about mastering my craft, regardless of where I worked. For me, it wasn’t about climbing the career ladder; it was about being truly excellent at something I was passionate about.

I come from a time when having a mentor to guide you — someone to show you where to focus your energy and what to learn — wasn’t common. By sheer luck, I stumbled upon a brilliant programmer online who was generous enough to share his knowledge with the world. I seized that opportunity, learning as much as I could from someone more experienced and highly respected in the field.

Douglas Crockford

Something remarkable happened to me while listening to Douglas Crockford. His insights hit me hard, challenging me with concepts that were difficult to grasp but transformative.

Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts.

And also:

  • I stopped using “new” years ago.
  • I have stopped using Object.create.
  • I have stopped using this.
  • I have stopped using null.

That experience completely transformed the way I approached JavaScript. I consider it one of the best pieces of technical advice I’ve ever received in my career.

It unlocked the functional programming potential of JavaScript in my mind, helping me address lingering questions and understand why my code often lacked the elegance and clarity I aspired to achieve. For that, I am eternally grateful.

An essential aspect of Functional Programming

Unfortunately, the front-end community introduced Functional Programming in a way that made it even harder to grasp, by bringing over complex concepts from languages like Haskell, Lisp, and Scheme. These concepts were already challenging in those languages, so trying to apply them to JavaScript only added confusion.

It’s the same mistake I made early on, when I tried to convince people that JavaScript was an OOP language like Java or C#. But JavaScript isn’t bound by any single paradigm. It’s not about diving into the complexities of Category Theory, Monads, Currying, or Functors. The goal isn’t to add more complexity, but to leverage JavaScript’s features to simplify problems and make code more efficient.

JavaScript is a unique language. While it includes elements of both OOP and Functional Programming, it doesn’t conform strictly to either. And that’s the beauty of it. JavaScript allows you to harness powerful concepts and write simple, elegant code that only this language can offer.

The present

It’s been over a decade since I stopped using this and new keywords in JavaScript.

const Person = ( name, age ) => {
    // This is private
    const message = `Hello there! My name is ${name} and I have ${age} years old`

    // This is public
    return {
        greetings() {
            console.log( message ) 
        }
    }
}

const person = Person('Eduardo', 40)
person.greetings()

I learned that many of the issues and bugs I caused were a result of mishandling the scope with the this keyword.


var person = new Person.Class('Eduardo')
...
button.addEventListener('click', person.greetings)
Hello there! My name is undefined.

Many of those bugs were incredibly difficult to track down. I remember spending hours on more complex systems filled with OOP “classes.”

The OOP-style fixes for these issues were often cumbersome and quirky:

var person = new Person.Class('Eduardo')
document.addEventListener('click', person.greetings.bind(person))

But for FP version, it was straighfoward:

button.addEventListener('click', person.greetings)

With that new approach I was forced to use functions everywhere, which simplified things by eliminating the need to deal with complex scoping. This approach helped me break down complexity into smaller, more manageable abstractions.

When the idea of Composition over Inheritance gained traction, I was already on board. It wasn’t an issue for me because, by using functions for everything, I naturally gravitated toward the composition strategy.

I’m not concerned with immutability or pure functions — those concepts often make code harder to write and, in many cases, harder to read. They don’t fit well in the front-end world, where our platforms are stateful and dynamic, just like the language itself.

In an effort to avoid edge cases where mutations or impure functions might cause issues down the line, you end up adding layers of complexity — sometimes 50 times more — just to prevent them.

And the same goes for TypeScript. Trust me, you don’t need it — at least not for front-end development. I can confidently say that.

I encourage you to cultivate a mindset that constantly challenges the way you think. I’m grateful to Douglas Crockford for having the courage to question widely held beliefs and bring the concept of simplicity into the mainstream:

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away ― Antoine de Saint-Exupéry

Unfortunately, many people are more inclined to embrace complexity as the solution to problems, and I believe that’s the current state of the “Modern” Front-End era.

However, I’m proud to be part of the minority who truly understand his message. Wherever you are, thank you, Master, for your invaluable advice.

Nordic.js 2014 • Douglas Crockford — The Better Parts