4. Traditional Web Development
Web assets are created last to glue together things.
Stakeholders, architects and developers define the
“real” application.
The application is built model first (from the DB up).
5. Traditional Web Development
The design is focused on making the CRUD pretty, not
usable
The design of the UI/UX happens in Photoshop... if it
happens at all.
Most of the application is just CRUD.
6. We have a widgets
table
We need a
widgets
screen!
7. Traditional Web Development
“Advanced” web developers write lots of unorganized
bits of jQuery.
Most user interactions result in lots of POSTS back
to the server.
JavaScripts are something someone download from
hotscripts.com.
8. We have a widgets
table
We need a
widgets
screen!
Make sure you
add a date picker
And a lighbox!
9. JavaScript: Not a “Real” Language
Patternless design.
Built as a glue to bind pieces together, not as a core
component of the application.
Not thought through like server-side code.
10. Not Real? Why?
A lot of development tools traditionally hid the JS behind
configurable controls.
Libraries like jQuery make it really easy to pile on lots of
little events.
JS used to be a tool for doing image rollovers.
11. Is That A Problem?
In a workflow-based application it falls apart.
For form-based apps that was mostly fine.
Customized, reusable controls and a modular
application design needs something more.
43. Some Reasons
• JavaScript isn’t real code
• We don’t treat client side things as real features
• We can’t easily test it
• We don’t like writing it
• It behaves differently in different browsers*
* Or at least it used to
44. This really all boils down to one thing.
We developers suck.
46. Decouple Everything
Apply your OO best practices here too.
Remove dependencies between objects.
Start thinking about UI pieces as individual JS objects.
47. Small Chunks Of Code
Even if you don’t test everything, learning how to
write testable code means learning
how to write better code
Put the rest of the stuff in classes that you can test.
Separate DOM dependent stuff into a single layer.
48. Push Events, Not State
Inform other controls that “X happened to Y”,
not “Y is in X state”
Let controls worry about their own state.
Know about the Law of Demeter.
49. Writing Better JavaScript
Find the tools that make your life easier.
Use the design patterns you already know.
Leverage language features whether JS has them or not.
50. Language Features
Keep state inside of the objects and expose methods.
Objects have state and behavior.
JavaScript loves its objects. Create them to represent
page elements.
58. Mediator Pattern
“The essence of the Mediator Pattern is to ‘Define an
object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects
from referring to each other explicitly, and it lets you
vary their interaction independently.’”
-Design Patterns: Elements of Reusable Object-Oriented Software
60. Observer Pattern
"Define a one-to-many dependency between objects so
that when one object changes state, all its dependents
are notified and updated automatically."
-Design Patterns: Elements of Reusable Object-Oriented Software
Think jQuery $(‘.something’).click()
66. A KO Warning
It’s really easy to go overboard with KO events.
I prefer to use KO for the VM binding (observables and
computeds) but rely on jQuery for events.
jQuery’s .on() binding and a good understanding of
‘this’ makes for much cleaner events.
67. Backbone
Views help you control the visual rendering.
Routers help you organize page flow.
While KO is Model < > View magic, Backbone is structure.
Models help you keep track of state.
72. Service Bus
Your controls are then only coupled to a single thing.
Controls that want to communicate speak through it.
A service bus is another layer that sits outside controls.
74. Service Bus + Mediator
• Controls no longer need to know about others.
• We can remove/replace controls individually.
• We can add controls that listen to the same events
without modifying the publisher.
• We can re-use pieces more easily because they work
in a standard way.
79. Testing
Try to have layers of your application’s JS that don’t
touch any HTML elements.
Store data in models inside individual controls and test
that published messages change the state of those
models correctly.
