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?
recurly-frontend
By hunterloftis
