Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so I'm super excited to be here I actually feel really at home talking about us talk about the backbone so today we're going to explore the little opinions and big possibilities tools and patterns for building large scale applications so this is actually
one of my favorite topics to talk about I feel like it's one of the least known areas of backbone and one that I see a lot of developers strongly with I guess the introductions already been made for me but since the beginning of this year I've been
writing and producing screencasts for a site that I created called backbone rails which basically focuses a lot on these topics building application architecture so today we're going to be talking initially about why I think architecture in backbone is
so difficult and I'll show you some tools and patterns that I've used successfully build some really scalable apps and I feel because backbone has a relatively small set of tools and components I feel like there's an unfair bias on backbone really
only being suitable for solving those small problems when I was looking at submitting a talk here to back on calm I got really excited because the call for speakers emphasized utilizing backbone within a large application so let's start off by exploring
the definition of a large-scale application and I mean what do you think it is do you think visual complexity like a lot of moving parts on the page perhaps you think maybe it's a really advanced data synchronization model maybe real-time collaboration
like that like with Google Docs or maybe instead you know you think in terms of size perhaps a code base that reaches a hundred thousand lines is is officially large and audio smonny and his paper on patterns for large scale JavaScript application architecture
says that in his view large-scale JavaScript apps are non-trivial applications requiring significant developer effort to maintain where most heavy being of data manipulation and display alter the browser he goes on to say that I'm working on a significantly
large JavaScript application remember to dedicate sufficient time to planning the underlying architecture that makes the most sense it's often more complex than you may initially imagine I certainly agree with all of that but it's still pretty abstract
I don't feel like we're really any closer to really defining what it is so I'd like to try to define some characteristics of backbone applications that will hopefully play us in the right direction so let me just first start off and just say what
is not a large-scale application and I really wanted to use to do NBC here as the poster child because it's unfortunately most likely the first backbone app that most new belt most new developers use to understand backbone or even compare it against the
other different MVC frameworks and if you're looking at two MVC you try to four see what it's like building a large-scale backbone app this pretty much couldn't possibly point you in a worse direction and why well so let's see I mean you can
add some to dues here which creates additional rows you check them off and clear them but overall this is really just a single function app it just does this one thing and the problem is is that this doesn't even come close to modeling or reflecting even
what most basic backbone applications need to do in for instance there's no rattling events there's no page changes there's that means there's no need to manage like view hierarchy figuring out how to replace old views and bringing new ones
in and most backbone apps consists of many multiple pages one of the first steps in organizing those is breaking those out into distinct modules if we tried separating out everything into the MVC lead to you know significant over-engineering probably turn
a lot of new developers away for lack of a better understanding but i think i think this is a good starting point so we've identified some characteristics that you don't see present and really small single function applications so now let's raise
the bar way up and personally why I think of ambitious applications that I've used ones which are of sufficient size and scale undoubtedly needing to follow solid design patterns I think of applications like our do Google Analytics WordPress Pandora and
while Google Analytics is the only one of these that's not actually built with backbone I believe without a doubt that it could be built with backbone and to me it's probably the single greatest example of the power of like a fully client-side application
and so when I sit down and I'm writing backbone absent code this is this is where I said the bar for me for today for our demo product for our demo app the one that we'll focus on and come back to throughout this talk is actually going to be our do
the first one so I want to show some examples of why I believe our do is a sufficiently complex in large-scale application for those of you who don't know have never use it audio is just an application that lets you play music through your browser assemble
playlists and create like a music collection so in this screenshot I'm looking at my collection of music and this lists out all the artists and displays of list those songs currently sorted by artist name and I can of course change the sort order to something
different so when I click play play count so if I play count it only updates that one portion of the page like that alternately filter by searching or just clicking on any artist from the list there a little left which instead of sorting it would just filter
down those lists of songs and argue those some really intelligent guessing and caching based on how large your collection of music is I've been the first time that I sort this list of songs to come back to this exact same sort order instead of making a
fetch to the server for that data it would actually just display the cache collection which will make the UI appear really snappy and so also note that every single change though I didn't show it in this demo every single change that affects the UI such
as changing the sort order or filtering or searching argue is manually going to use the push 8 to update the URL so that means that if we were to hard refresh or open up that link in a new tab we would actually be returned to this exact same state that we
left that we left off it so that really means that two interesting things are happening is one that state of the of the page is actually gradually changing as we click different buttons and interact with the UI but that there's also this other representation
of that state that's that should be able to read be rebuilt solely from the from the URL only so so far we've just been updating that one portion of the page but if we come over to the playlist over here on the left and we click on any item in this
collection to say you know we click that we click Pink Floyd then the entire music collection that main region is going to be replaced and we're given a loading spinner to indicate that we're fetching one or more dependencies from the server and then
when those are returned then our page displays and now it takes up that entire than entire main region as our collection music did so we also go into our settings and this just repeats the same process we played settings it changes out that main region and
there you go so we have all of these modules on the screen which are visually orchestrated together but they're actually all completely independent from one another different UI events may replace only a small small portion of the screen while others wipe
the entire main region and of course you know we've only scratched the surface of our do and completely left out the fact that it's playing music real-time in our browser synchronizing that across any other device that we have connected but for the
moment our focus really is on just this UI so if they're looking at argue I think I think we can put together some characteristics of large-scale apps from from pen to paper we know that there is a strong likelihood that we'll be dealing with multiple
if not many routers that means that we'll have to rebuild the state of our UI solely from just a routing URL but also need to manage a significant amount of views right from small or large state changes in the UI so we know that we're going to need
a really great system from being able to nest compose multiple views together within each other and technically we need to be able to make sure that we're cleaning up those old views setting them down ensuring they're eligible for garbage collection
aka no memory leaks and we know that we should be breaking our application into independently smaller chunks into modules and that these different parts of our system would need to communicate based on a series of complex events so when an important action
happens in one part of our system another part should be able to be notified about it so we'll probably have to manage lots of state changes right and for my experience there's a strong likelihood that you'll be dealing with a large quantity hds
there's actually the same way that Jeremy was using and that's the word that I use to refer to either models or collections these are a significant challenge to manage I mean knowing when to pull them from the server when to catch them and have handled
[ ... ]
Nota: se han omitido las otras 4.779 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.