UI Architecture: all the stuff that it takes to process, package, deliver, and communicate with the client (templating url routing, data validatiion, formatting, ajax). “Between the front and back end”: stuff between presentational javascript and the backend logic. The middle end gives a web 2.0 app performance.
We need to talk about this because of issues with performance and optimization, the MVC model spaghetti code failure (outputting html if a condition exists: the mixture of model code inside view template, too tight coupling between presentation layer and model layer), “don’t repeat yourself” (DRY: repeating code over and over again, i.e., duplicating validation in the client and the server, “any time there is more than one copy of something, one copy is always wrong”), and role separation (wearing multiple skillset hats and mixing contexts–markup/css switch to javascript switch to backend app–without being able to focus on one context at a time).
This isn’t another framework, it’s an optimized/reworked “alternate pattern” of MVC in an attempt to solve some of the weaknesses/problems of MVC. Can we decouple the view from the existing architecture stack?
CVC + JavaScript puts the power of UI architecture in the hands of front-end engineers.
- Presenter(s)
- Kyle Simpson
- Date
- 14 March 2010
- Tag(s)
- #frontandbackofit
- #jsarch
- Sites
- Getify
- Demo of HandlebarJS
- Speaker Feedback
- BikechainJS
- HandlebarJS
Traditional: CVC
The MVC model doesn’t have a clear space for client-based JS app (a JS version of the app that is not just the presentation logic, but a representation of the app inside the client).
New: “Clients Views Controllers” (CVC)
Application Layer (black box): doesn’t do anything with the presentation layer, no markup; only concerned with state management/session records and representing the data in a standard format: JSON API. Multiple other layers can talk to JSON API, so make it primary communication interface with application layer.
Web Server Layer: translates protocol request to hand off to rest of stack.
UI Controllers Layer (server): written in javascript, takes care of url routing, data validation. Allows more reuse of code/less rewriting in server/client layers.
View Layer (server/client): written in javascript, view engine decoupled from application, portable to client because of JS to run in browser.
“look up state, hands off to controllers, choose a view”
Clients
Everything is a client of everything else. Each layer is decoupled, modular, scalable.
Views
Templating, portable, DRY, platform agnostic, uses core web tech.
Controllers
Task oriented. Controlled by front-end engineer. Less dependence on backend architecture. Small, independent.
JavaScript on a Server
node.js is a wrapper around the V8 JS engine. Some Python dependencies for build, but not for execute. V8 is just a shared lib. a different way to process web requests: asynchronous events instead of firing a thread for every request. narwhal is a wrapper around the rhino JS engine. Others: javascriptcore, spidermonkey.
Reference implementation: BikechainJS is Kyle’s wrapper around V8. Loads modules to create a hosted environment to run JS. HandlebarJS is a templating engine that uses text/html templates and accepts JSON data input where you cannot call any methods/math. The only logic you can do is to use application “state” for template selection. Compiles templates into JS the first time a template is parsed. Environment agnostic (server or client).
Standards
How do I read/write files, i/o, execute processes, conduct network requests? CommonJS is a standards community. Very young.