From Backbone to Ember and Back(bone) Again

Jan. 7, 2015
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
From Backbone to Ember and Back(bone) Again
1 of 55

More Related Content

What's hot

JSF Component BehaviorsJSF Component Behaviors
JSF Component BehaviorsAndy Schwartz
In The Trenches With Tomster, Upgrading Ember.js & Ember DataIn The Trenches With Tomster, Upgrading Ember.js & Ember Data
In The Trenches With Tomster, Upgrading Ember.js & Ember DataStacy London
Refactoring Large Web Applications with Backbone.jsRefactoring Large Web Applications with Backbone.js
Refactoring Large Web Applications with Backbone.jsStacy London
Refactor Large applications with BackboneRefactor Large applications with Backbone
Refactor Large applications with BackboneColdFusionConference
Introduction to VaadinIntroduction to Vaadin
Introduction to VaadinJeroen Benats
AngularJs Workshop SDP December 28th 2014AngularJs Workshop SDP December 28th 2014
AngularJs Workshop SDP December 28th 2014Ran Wahle

Similar to From Backbone to Ember and Back(bone) Again

WebNet Conference 2012 - Designing complex applications using html5 and knock...WebNet Conference 2012 - Designing complex applications using html5 and knock...
WebNet Conference 2012 - Designing complex applications using html5 and knock...Fabio Franzini
Yeoman AngularJS and D3 - A solid stack for web appsYeoman AngularJS and D3 - A solid stack for web apps
Yeoman AngularJS and D3 - A solid stack for web appsclimboid
Developing Java Web ApplicationsDeveloping Java Web Applications
Developing Java Web Applicationshchen1
RIA / SPA with ASP.NETRIA / SPA with ASP.NET
RIA / SPA with ASP.NETHrvoje Hudoletnjak
Javascript frameworks: Backbone.jsJavascript frameworks: Backbone.js
Javascript frameworks: Backbone.jsSoós Gábor
Rp 6  session 2 naresh bhatiaRp 6  session 2 naresh bhatia
Rp 6 session 2 naresh bhatiasapientindia

Recently uploaded

Jens Happe - Write tests you love, not hate.pdfJens Happe - Write tests you love, not hate.pdf
Jens Happe - Write tests you love, not hate.pdfJens Happe
Top Benefits of Web based Systems. Top Benefits of Web based Systems.
Top Benefits of Web based Systems. sarasiva4
 Database storage engine internals.pptx Database storage engine internals.pptx
Database storage engine internals.pptxAdewumiSunkanmi
eShareseShares
eSharesTeam2080
Applications in PharoApplications in Pharo
Applications in PharoESUG
Advanced Object- Oriented Design MoocAdvanced Object- Oriented Design Mooc
Advanced Object- Oriented Design MoocESUG

From Backbone to Ember and Back(bone) Again

Editor's Notes

  1. explain Coffee + Code
  2. Time Machine: my cohort, Eric Browning, is talking about “No More Static Comps: Design Process in the Modern World” at 11am in Salon D. I’m a consultant that gets to work with lots of different clients and I get to write (and see) a lot of different code. To keep it professional, no names in presentation or during questions besides my own.
  3. Most programmers get paid to write code. They work on different projects.
  4. I get paid to work on MANY different projects. Get to see a lot of good/bad practices, work in different languages, solve different problems. I can bring unique perspective to projects.
  5. Client = Widget Factory if you haven’t guessed, no real names please
  6. Widget Factory hired Vendor Co to build a web application. A dashboard. Many moving pieces / parts. We will focus on front-end UI.
  7. * show latest numbers from server * chart shows historical numbers over past X hours * data loaded when app loads and polls every X seconds
  8. data from API server was in bloated format adding features felt like it was taking too much time
  9. there was some code pairing and information sharing to help bridge gap everyone had best intentions in mind
  10. best intentions in mind Ember has easy data binding, easily update views when data updates
  11. I used Backbone in many projects before, comfortable
  12. laughable, does not provide much in terms of “structure” organizes jQuery spaghetti code (still useful)
  13. the “M” in MVC, organization of data JS Objects and Arrays with enumeration management methods
  14. utilize events for having app adapt to changes in state uniform way to manage DOM events and create custom events
  15. logic to map data and state changes to what the user sees and interacts with ends up doing most of the work
  16. * views have events as well, no biggie nowadays but useful for separation of responsibility
  17. pushes JSON out of the box can be customized, but it can be painful and require a lot of custom code
  18. opinionated collection of “best practices” does a lot of the grunt work for you
  19. * created to tackle complicated web applications
  20. (highlight parts of the definition giving a real explanation of what that means for the developer)
  21. * same as Backbone and most front-end “frameworks”
  22. this is where Ember truly shines directional team very interested in providing best of breed, open to changing technologies
  23. start to build relationships between data separate library called Ember.data that handles async data retrieval
  24. Backbone all manual, Ember is automatic
  25. router gets quite a bit of praise much more powerful than Backbones, handles tiers of triggered controllers (nice if your app plays well with well structured urls) I’m not used to it yet
  26. surprised to see conversations of Rails bloat, but flocking to Ember two way data binding by default produces unnecessary overhead follows Rails, easy to write code, also easy to not know what you wrote (how much computation behind the scenes?) app still suffered from two big issues
  27. * original app looked great with 10 - 20 items * needed to show more than 500, also limited by other architecture choices load all the dataz! write less code, bind more things render it all
  28. Comparing Backbone w/Marionette to Vendor Co’s
  29. took TodoMVC app and “productionized” assets to take performance numbers
  30. I downloaded TodoMVC examples and got line counts
  31. what I believe was the biggest issue with Vendor Co’s app Widget Factory can’t maintain something they don’t understand they would have been disappointed in any solution they received
  32. * technical solution delivered that did not account for non-technical project needs * how often things broke in lib or architectural decisions
  33. * keyword is “our”, built entire structure with assistance from Widget Factory employees * discuss how our solution addressed non-technical needs of project * team uplift / pairing * designing a workflow together * explicit code rather than implicit magic * amount (and quality) of documentation for js libs and css framework (bootstrap) abstracted JS workflow into common Grunt library abstracted common application system and code into common UI library
  34. this will create a Layout based on your application’s main layout you “export” what you want other files to be able to require all dependencies must be required Browserify handles dependency management all source is concatenated into one js file (automatically skips unused source code)
  35. built upon Backbone and Backbone.Wreqr (messaging patterns for Backbone apps) Backbone.BabySitter (manage child views) * Wreqr changing to Backbone Radio in upcoming release of Marionette
  36. removes the copy/paste boilerplate for view rendering from Backbone
  37. bringing design patterns into Backbone: Application singleton module loader view hierarchies view behaviors (sectioned responsibilities for a single view) template caching view regions / region managers
  38. view hierarchies ItemView, LayoutView, CollectionView, CompositeView Regions and RegionManagers Backbone.Wreqr / Radio that uses channels (ex: “global”) commands (do something, don’t care about response) event aggregator (custom events attached to your application) request / response (return data from request)
  39. My challege to all of you consider non-technical needs or else miss expectations on delivery hesitate to introduce new technologies to solve the problem think about the REAL problems and what it takes to solve them, do not focus on only technical problems
  40. I’m Jonathan Knapp of Coffee and Code, thanks!