How we at Adobe put our application on
◦ Developer at Adobe.
◦ Web developer for 2 years with a passion for good UI/UX.
◦ Likes solving usability and performance issues with his team.
◦ Enjoys music and playing his guitar in his free time.
◦ Loves hacking away on new libraries and frameworks, trying to
figure out if he can use it for his next project.
And these were just the ones that we could measure..
Shocked?! So were we..
Page load time 3 sec ~ 0.5 sec
Weird unexplained bugs > 15 < 5
Network Time (combined) 40 sec 10 sec
Module UI redesign time 1 week ½ day
Marionette by design treats all views as small,
Views consist of
◦ A Model/A Collection
◦ A Template
◦ Accompanying styling
Marionette conveniently bundles all these together
so that they can be reused as many times as a
Method and procedure to achieve reusability
◦ Attach view to a region
Marionette detaches the code for the View
from the business logic
Painful UI modifications will now be a thing of
Just switch the UI template and all the
underlying logic works as before
The next Marionette version will come along with a
messaging library: Backbone.Radio
But the library is available to use with the current
Requests unlike events generally want something
(data or action to be performed)
It’s an internal add-on we are creating for
◦ Radio request-reply loops usually take some
◦ It can be either processing time or network
◦ And guess who solves this problem!! The
mighty Cacheable Radio!!
It acts as a wrapper over the regular
Saves time by browser-caching radio
requests (avoiding unnecessary server calls)
It also has an in-built function to invalidate
stored data if a fresh API call is required