Front-end Workflow
Request for Comments
Recurly
Jan 2014
Current state of affairs
Goals for a better workflow
Fun
Light
Future-facing
Pieces we've already fit together:
Separation of concerns
React.js
In production at Facebook since 2011
Used by Khan Academy and Instagram
Can be adapted piecemeal and mixed with other code
Is only the the "V" in "MVC"
Benefits we've seen
Virtual DOM
Faster than traditional binding
Code re-use through composition
Server-side rendering options
Postback-style code simplicity minus the drawbacks
Excellent marriage with CommonJS
Browserify
Aki, take a deep breath...
Rework + NPM
("build your own SASS")
Live Reload!
Reporting: proof of concept
(let's do it live!)
Next Steps (we think):
1. Integrate Recurly-UI as a component.
2. Publish
versioned
assets to a CDN.
b1234/
build.js
build.css
b1235/
b1236/
scout.js
3. Dogfood a private, beta
API-V3
4. Gradually spin out components from Recurly-UI
Missing Pieces:
Data layer (backbone?)
Application architecture (SPA? Routing?)
The full deployment story
Static assets via NPM (fonts, images, etc)
Splitting, bundling, packaging assets
API design (Isaac?)
Testing workflow
How to encapsulate rather than fragment
What are we missing?
Poke holes in our thinking
(please!)
We want front-end work at Recurly to be fun.
What sucks about this? How can it be made better?
Does it create new pain points?
Are we crazy to be so excited?
Made with Slides.com