JavaScript: Poorly Designed?— Part 4: Object-based, Higher-order, Functional Programming
— Previously in: JavaScript: Poorly Designed? — Part3: IEEE 754 We looked at floating point precision and touched on when it’s necessary to manage representational errors. IMO two big misconceptions with JavaScript revolve around the “obsession” with static types and the mandatory notion to use object oriented programming.
Let’s have some fun and look at an assorted range of tweets on the subject of OOP vs FP:
As you can see this was an interesting search.
Is OOP the holy grail?
Let’s establish what OOP is:
Basically it’s just a way of doing things, which has worked for over 50 years in computing. Hmm, impressive, but that’s not the only way to do things and just like anything it can become messy and overkill if abused.
When I was new to the world of development I want to use JavaScript in an advanced way even before I understood the language properly.
Everyone was talking about this book: Design Patterns: Elements of Reusable Object-Oriented Software written by four developers refereed to as “the gang of four” how gangsta is that. My obsession with classical inheritance grew. But In reality I rarely emulated it in real JS projects because it was time consuming and convoluted for such minuscule results. Simple clean JavaScript was more practical but it didn’t feel as sexy back then.
I’m not a fan I’m an enthusiast, so I’m not going to over complicate shit just to feel like a smarter person, just because I can. Let’s take that honesty a step further:
I find it easier to read other people’s code in programming languages that I have never written before than I do to read other people’s JavaScript that heavily uses “new”, “this” and “prototype”
And this is coming from someone who has worked on a code base for an app with 100MB+ of JavaScript full of the aforementioned.
This is not an exaggeration. After a while it all doesn't seem very clever as initially thought, because the end result is nothing special. You start to see developers overusing context for every aspect in development, just because they can, we can do better than this tunnel vision.
We have many different ways to build applications:
Object Oriented Programming (class extend etc), Prototype Inheritance, Functional Programming, Reactive Programming, Event driven programming…
The list goes on and most of these styles incorporate one and other.
There is no one size fits all:
User interfaces for websites, web applications and mobile apps do not generally feature enough repetition or similarities to warrant heavy use of inheritance, abstraction or polymorphism let me explain why:
Duplicated functionality and content are symptoms of Poor UX design. Practical UX design may commonly share similarities across pages, steps, components and so forth but rarely as deep as the traits in (let’s say) a typical video game or the back-end of a fin-tech application.
OOP vs FP should not be about style preference it should be a choice based on application, maintenance, parallelism and the necessity for re-usability.
What exactly is JavaScript
So we have wised up to understand that OOP, FP, FRP, and any other Ps you can think of are not the holy grails of programming methodologies. Let’s explore the nature of JavaScript to see where it fits in.
JavaScript “was” not an Object Oriented Language
Since ES6 JavaScript now has classical inheritance built in. As with PHP, JS was not naively born with the concept of classes.
JavaScript is an Object-based Language
This is a powerful paradigm which means that most things in JavaScript derives from the Object constructor.
JavaScript is a Higher-order Language
This is another powerful concept that allows you to pass functions as arguments and values. This allows for currying, partial-application, composing and several other functional programming paradigms.
JavaScript is a Functional Programming Language
What constitutes as an FP language is subjective but in this article let’s base this on what can be achieved using JavaScript (reasonably without a library) in accordance to Haskell’s definition.
- Higher-order functions ✔(Native)
- Purity ✓(By discipline)
- Immutable data ✓(By discipline)
- Referential transparency ✔ (Native)
- Lazy evaluation ✓ (DIY)
- Purity and effects: Side effects in the language ✔(Native)
- Purity and effects: Side effects through monads✔(Native)
- Recursion ✔(Native, No tail call optimisation, large recursions should use a trampoline)
As you can see, despite not being a Swiss Army style FPL like Haskell, JavaScript is very capable as an FPL.
FP and OOP in JavaScript
There are some powerful FP libraries in JavaScript such as Ramda. As mentioned libraries are not required to perform FP in JavaScript but they can aid heavy and detailed amounts of data manipulation.
I’ll repeat again: Front-facing user interfaces are rarely about heavy inheritance. Despite all the modern frameworks sporting classes for components this is quite easy to prove since the levels of inheritance in a typical User Interface rarely goes beyond 1 deep.
Visit 10 major websites and note down the levels of inherited content and components (you will be lucky to come across a site that reaches 2 deep).
As an analogy: A Ford Fiesta is generally more powerful than a Ferrari when it comes to grocery shopping. Just because the Ferrari has the more powerful engine doesn't mean it is more feasible for every transportation scenario.
Conclusion
- OOP is a heavy concept for UI development of any kind not just the web.
- FP is generally at the core of JavaScript as a principle.
- Too much FP obsession may be overkill in JS.
- Too much OOP associated with UI components may be overkill in JS.
Challenge yourself:
- Do you need to use this?
- Do you need to use new?
- Do you need to extend a class?
- Are there circumstances where mutation is plausible?
- Do you need to replicate every concept you love from Category Theory?
Building light-weight, fast and maintainable applications in JavaScript is not about preference and happiness. It should entirely depend on domain and application distinctions.
If you don’t know when to use a mallet vs a Sledgehammer, learn the strengths and weaknesses of both tools rather than glorifying fanboy-ism.
Thanks for the read ;-)
