Javascript  spaghetti stirtrek_5_17
Upcoming SlideShare
Loading in...5
×
 

Javascript spaghetti stirtrek_5_17

on

  • 515 views

 

Statistics

Views

Total Views
515
Views on SlideShare
515
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • I attended this presentation at Stir Trek. It was an awesome presentation and I appreciated Jared's time and attention to sharing important information with a presentation that obviously took a lot of work to put together. Joe Kunk, Microsoft MVP Visual Basic
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Javascript  spaghetti stirtrek_5_17 Javascript spaghetti stirtrek_5_17 Presentation Transcript

  • Building Rich User ExperienceswithoutJavaScript Spaghettiby Jared Faris@jaredthenerdjaredthenerd.com
  • About me
  • Traditional Web DevelopmentWeb 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).
  • Traditional Web DevelopmentThe design is focused on making the CRUD pretty, notusableThe design of the UI/UX happens in Photoshop... if ithappens at all.Most of the application is just CRUD.
  • We have a widgetstableWe need awidgetsscreen!
  • Traditional Web Development“Advanced” web developers write lots of unorganizedbits of jQuery.Most user interactions result in lots of POSTS backto the server.JavaScripts are something someone download fromhotscripts.com.
  • We have a widgetstableWe need awidgetsscreen!Make sure youadd a date pickerAnd a lighbox!
  • JavaScript: Not a “Real” LanguagePatternless design.Built as a glue to bind pieces together, not as a corecomponent of the application.Not thought through like server-side code.
  • Not Real? Why?A lot of development tools traditionally hid the JS behindconfigurable controls.Libraries like jQuery make it really easy to pile on lots oflittle events.JS used to be a tool for doing image rollovers.
  • 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 modularapplication design needs something more.
  • Questions So Far?
  • A Typical Product LifecycleSomewhat dramatized...
  • Designer Developer
  • We need thisfeature
  • I got this
  • ?
  • Tweaking time...
  • I got anothergreat idea
  • Now you tellme
  • The developer bolts on some more code
  • And anotherthing...
  • grrr
  • We don’t‘really’need this
  • Uh, yeah wedo
  • The developer bolts on some more code
  • Some time passes‘Some time’ is defined as:Just long enough that the developer doesn’t rememberexactly how his original code works.
  • I’ve got a newfeature
  • Angry developerscan really do this.IT managers bewarned.
  • Protective Beret
  • More messy code
  • The last bugOh wait, one more
  • Finally(14 tests ought to be enough for anybody)
  • The next day...
  • Two weeks pass.
  • I’ve got a newfeatureGahh!
  • No developers were harmed in the makingof this dramatic reenactment.
  • Poor design patterns+ crappy code= JavaScript spaghetti
  • Why does this happen?
  • 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
  • This really all boils down to one thing.We developers suck.
  • Three JavaScript PrinciplesPush events, not stateWrite small, discrete bits of codeDecouple everything
  • Decouple EverythingApply your OO best practices here too.Remove dependencies between objects.Start thinking about UI pieces as individual JS objects.
  • Small Chunks Of CodeEven if you don’t test everything, learning how towrite testable code means learninghow to write better codePut the rest of the stuff in classes that you can test.Separate DOM dependent stuff into a single layer.
  • Push Events, Not StateInform 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.
  • Writing Better JavaScriptFind the tools that make your life easier.Use the design patterns you already know.Leverage language features whether JS has them or not.
  • Language FeaturesKeep state inside of the objects and expose methods.Objects have state and behavior.JavaScript loves its objects. Create them to representpage elements.
  • Language “Features”Consider using namespaces.
  • JavaScript Namespacing
  • Language “Features”Use inheritance or faux subclassing.Consider using namespaces.
  • JavaScript Prototyping
  • Coffeescript Classes
  • Language “Features”Pass JSON around asynchronously.Use inheritance or faux subclassing.Consider using namespaces.
  • Design Patterns
  • Mediator Pattern“The essence of the Mediator Pattern is to ‘Define anobject that encapsulates how a set of objects interact.Mediator promotes loose coupling by keeping objectsfrom referring to each other explicitly, and it lets youvary their interaction independently.’”-Design Patterns: Elements of Reusable Object-Oriented Software
  • NavControlMediatoritemSelected()Events from someother objectunselectAll()
  • Observer Pattern"Define a one-to-many dependency between objects sothat when one object changes state, all its dependentsare notified and updated automatically."-Design Patterns: Elements of Reusable Object-Oriented SoftwareThink jQuery $(‘.something’).click()
  • NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModel
  • Tools & Frameworks
  • KnockoutMagic.Setup a template with some markup binding it.Setup a JavaScript object with some KO code.
  • A KO WarningIt’s really easy to go overboard with KO events.I prefer to use KO for the VM binding (observables andcomputeds) but rely on jQuery for events.jQuery’s .on() binding and a good understanding of‘this’ makes for much cleaner events.
  • BackboneViews 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.
  • Backbone Use Case
  • What about all the otherframeworks?
  • Pub/Sub + Fairy Dust = Service BusPub/Sub is great to make sure events propagate.It starts to get brittle with lots of different controls.
  • Way Too Much Pubbing and Subbing
  • Service BusYour 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.
  • Postal.js
  • 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 eventswithout modifying the publisher.• We can re-use pieces more easily because they workin a standard way.
  • NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModelReportMediatoritemChanged()unselectAll()viewModelService Bus
  • NavControlMediatoritemSelected()Events from someother objectunselectAll()viewModelReportMediatoritemChanged()unselectAll()viewModelService BusHistoryControl
  • Service BusTeamControlGets team changedmessage, makes AJAXcall for this team’s data,rewrites team with templateNo view model
  • Service Bus
  • TestingTry to have layers of your application’s JS that don’ttouch any HTML elements.Store data in models inside individual controls and testthat published messages change the state of thosemodels correctly.
  • Underscore
  • Underscore
  • Underscore w/ Coffeescript
  • What Else?I don’t have a third bullet point hereBrowser DebuggersTemplates
  • A Typical Product LifecycleRound Two
  • We need thisfeature
  • I got a fewquestions
  • ?
  • Tweaking time...
  • I got anothergreat idea
  • Ok, Cool
  • And anotherthing...
  • Done.
  • Two weeks pass...
  • I’ve got a newfeature
  • No worries.
  • Wha? Ohhhk.
  • A short time later...
  • Examples
  • Questions?
  • Special thanks toHe did the frame artBlame me foreverything else
  • My Stuff@jaredthenerdjfaris@gmail.comhttps://github.com/jaredfarishttp://jaredthenerd.com