functional-js-reverse-engineering-the-hype



functional-js-reverse-engineering-the-hype

0 7


functional-js-reverse-engineering-the-hype

Functional Web UIs for Normal People

On Github banderson / functional-js-reverse-engineering-the-hype

Functional JavaScript

Reverse-engineering the Hype

Learning to Program

as a working programmer

Think back to the first time you learned OOP Put yourself there: what language? What was computer like? Think: what was the example? was it something like: Dog inherits from Animal? Did you override the speak to say "woof" instead of whatever it is a BaseAnimal says? Was it more like Circle inherits from Shape? And did you override draw so that it can differentiate itself from other shapes like Square, Triangle, etc.? Is this still what drives you today? We've exceled at it through determined practice, building large and complex systems We put in the work

Big Ideas

Small Examples

It's also unfortunate that when we start looking to adopt FP patterns, we are tempted with examples like this:

Adopting Big Ideas

  • It took a generation to agree that high-level languages were a good idea
  • It took a generation to agree that objects were a good idea
  • It took two generations to agree that lambdas were a good idea

it takes a generation of programmers to retire or die off in order for new ideas and paradigms to take hold And the audience exploded in applause. While I understand the sentiment, I'm a little less pessimistic than Doug. I think what it really takes is understanding how to build real systems with our new way of thinking. Not Cat inherits from TerribleAnimal, but real, useful systems. Systems we make at work. Every day. So I want to provide a tour of some of the higher-level functional concepts I've come across in my journey. Application-level ideas, actionable ideas. I hope to give you the spark you need to realize you can do these things today. Right now. After lunch. When you get back to your desk. For those who've been either over- or under-whelmed FP as they've seen it.

Adopting Big Ideas

"the best idea in the history of programming..."

And the audience exploded in applause.

Adopting Big Ideas

"wait for the previous generation to retire or die before we can get critical mass on the next big idea"

And the audience exploded in applause. While I understand the sentiment, I'm a little less pessimistic than Doug. I think what it really takes is understanding how to build real systems with our new way of thinking. Not Cat inherits from TerribleAnimal, but real, useful systems. Systems we make at work. Every day. So I want to provide a tour of some of the higher-level functional concepts I've come across in my journey. Application-level ideas, actionable ideas. I hope to give you the spark you need to realize you can do these things today. Right now. After lunch. When you get back to your desk. For those who've been either over- or under-whelmed FP as they've seen it.

MakingReal Apps

Functional JS Agenda

Why now? Why Javascript?

Functional Patterns, for Real Apps

Revisting the Mental Model

Intended Audience

This won't be theoretical I don't want to re-write Lodash I want to create applications

Unfortunate divide Unfortunate that practitioners have to feel like this

Put your speaker notes here. You can see them pressing 's'.

Put your speaker notes here. You can see them pressing 's'.

WhyFunctional?

"But I think there's no longer any debate,the future has to be functional, immutable data, and it has to be concurrent. It's the only way to grow."

Dave Thomas

Put your speaker notes here. You can see them pressing 's'.

"it's almost certainly true that functional programming is the next big thing"

Uncle Bob Martin

Put your speaker notes here. You can see them pressing 's'.

Put your speaker notes here. You can see them pressing 's'.

Put your speaker notes here. You can see them pressing 's'.

WhyJavascript?

Capability

meets

Opportunity

"The best thing about JavaScript is its implementation of functions. It got almost everything right."

— Douglas Crockford

Put your speaker notes here. You can see them pressing 's'.
Put your speaker notes here. You can see them pressing 's'.

MakingReal Apps

λ UIs

Problem

DOM is stateful, imperative

It will undermine your functional quest

elm-lang.org

virtual-dom

Functional Components

fn(props, state) == UI

Put your speaker notes here. You can see them pressing 's'.

λ Domain Logic

"The Data"

Collections and Models

λ Collections

λ Models

But first...

Primitive Obsession

"The idea that your app, no matter how complex, can be described by solely primitive values at the language level (arrays, numbers, strings), or the library level (maps, lists, sets, stacks, etc.)"

The guy on stage

Primitive Obsession

Like other models, exceptyou can't change them

Immutable Benefits

You can trust them

Your app can trust them

λ Transforming Data

"The Functions"

Services and Queries

λ Services

Stateless function that accepts and transforms immutable data to fulfill a business operation.

λ Queries

Stateless function that accepts immutable data and transforms, calculates, reduces, repurposes...

RSI( Avg( getStocks( ) ) )

RSI( Avg( getStocks( ) ) )

RSI( Avg( getStocks(state) ) )

λ Framework for Change

"The Actions"

Change the outside world

λ Framework for Change

Demo Time

λ Mental Model

Static vs Dynamic

redux: "predictable", "behave consistently"

Put your speaker notes here. You can see them pressing 's'.

λ Mental Model

fn(state) == UI

Put your speaker notes here. You can see them pressing 's'.

λ Mental Model

fn(state, ) == UI

λ Mental Model

fn(state, ) == UI

Put your speaker notes here. You can see them pressing 's'.

"Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."

Edsger W. Dijkstra (1968) Hat tip @gnijor

"...as wise programmers aware of our limitations..."

"Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed."

"For that reason we should do... our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible."

On the Shoulders of Giants

Featured Tools

Learning Functional Style

NodeSchool: Functional Javascript Workshop Build something.