ReasonML vs. Elm
A Reasonable Compromise
A
Persistent
Dilemma
State
A value at a moment in time. This could be UI status, data from endpoints, configuration, user input, or any number of other variables.
Shared state
As complexity grows, so does shared state. Design patterns like OOP and FP are a way to manage that complexity.
OOP
Object-Oriented Programming segregates shared state into object instances with interface methods, allowing each object to manage state independently.
State Intensifies
How to manage state in Object-Oriented code?
- Create more objects
- Group objects into packages
- Make some methods private
- Use more abstract interfaces
- SOLIDly embrace Uncle Bob
Eventually, your code is only expressing a portion of the logic involved.
A
Sound
Solution
FP
Functional Programming seeks to minimize state and restrict it to carefully controlled portions of your application.
Mathematical!
It embraces strategies from category theory to enable compositional programming. Complex abstractions are built up from smaller, pure operations that can be combined in solid and predictable ways.
Type Safety
Ensures that a variable’s value always matches the variable’s static type.
This can be accomplished at compile time, runtime, or a combination.
Type inference allows annotations to be omitted.
Polymorphism allows types to vary.
Soundness
Ensures your program can’t get into certain invalid states. A sound type system means you can never get into a state where an expression evaluates to a value that doesn’t match the expression’s static type.
Pay off technical
debt up-front.
- Less time testing and refactoring.
- When things break down, it's often
easy to see false assumptions. - Sound completeness of the type
checker aids in finding bugs. - Code needs to be more thoroughly
thought out before it will type check. - More time needs to be invested
up-front to handle edge cases.
What could go wrong??
Performance
Functional programming was introduced in the 1950s with LISP. It actually came before OOP!
At the time, memory was very expensive. OOP required less memory.
Even today, mutation gives Object-Oriented code a performance advantage while sacrificing predictability.
Wizardry
In practice, it works! Errors and unpredictable side effects are much less of an issue. Complexity remains a constant foe, however, especially in languages with terse syntax and user-defined operators.
Where does Elm fit in?
Front End
What started as a simple document markup language has grown into a full-scale, cross-platform, accessible, realtime engine for rich applications.
The browser is turning into an embedded operating system, built around JavaScript - a very loose and dynamically typed environment.
Chaos Reigns
An object-oriented focus inherited from Java coupled with very loose and often-silent error handling resulted in the proliferation of buggy, difficult-to-maintain front end applications.
Race conditions and runtime errors became the bane of browser-based development.
Soundness with Clarity
Elm focuses on strict, sound type safety coupled with a strong emphasis on developer experience, with features like friendly error messages and rich tooling.
Interop is restricted to JSON messaging, allowing for exhaustive validation to ensure soundness.
Powerful Performance
Benchmarking shows that Elm's opinionated implementation of the virtual DOM is extremely performant, outdoing competitors with room to spare.
We're Saved!
🎉
Limited Abstraction
The lack of polymorphism and higher-kinded types leads to some frustration when trying to avoid boilerplate and repetition.
Narrow Focus
Because Elm code is built for the browser, code sharing across environments is not well-supported.
Projects to bring Elm to the server or to native clients like iOS or Android are experimental, and not ready for prime time.
Terse Syntax
The unfamiliar representation of HTML presents challenges for collaboration.
Enter
OCaml
OCaml...
- ...is a multi-paradigm (FP & OOP) language with an emphasis on expressiveness and safety.
- ...has a sound type system with rich inference, user-defined algebraic data types, and pattern matching.
- ...has a sophisticated module system with support for type-level programming.
- ...has automatic memory management (garbage collection).
- ...has a rich build system enabling different targets, syntaxes, and extensions.
Elm
Monomorphic Types
Abstraction by convention -
Restrictive Interop
Via JSON message-passing -
Single Environment
Currently browser-only -
Strict Immutability
Values change through - events
OCaml
Polymorphic Types
- Generic types
- Extensible records
- Higher-kinded types
Foreign Function Interface
- BuckleScript
- Convenience macros
Flexible Build Targets
- Windows, Linux, Mac, JavaScript, iOS, Android
Optional Mutability
- Refs to differentiate mutable values explicitly
OCaml
For the Masses
ReasonML...
- ...uses a very familiar syntax, similar to JavaScript
- ...targets native platforms like Mac and Windows, and web-based platforms like browsers and React Native.
- ...uses a toolchain that provides an npm-style workflow whether you’re compiling to JavaScript or native platforms.
- ...allows for gradual conversion of JavaScript codebases.
Pattern Matching
"Codify" your domain knowledge as custom types, and use a switch statement to make decisions based on them.
Exhaustive checking ensures you don't miss a case. Type arguments allow you to pass additional data with a variety of uses.
Reason-React
Polymorphic Variants
Custom, flexible types that don't have to be defined and imported in order to be used. The types can be used interchangeably in many situations.
Compositional Programming
The sound type system allows for powerful abstractions based on category theory.
Extension Points
Allows you to pre-process your OCaml code, transforming it before it is compiled.
