Madurando con Backbone

Extracto de la transcripción automática del vídeo realizada por YouTube.

alright so cool if anybody wants to follow along my slides are not easy on you yet the clone is Rico and then run grunt so hopefully you have drunk myself if you want to follow along so this is actually kind of mini web app in the broadest sense possible I'll

go into some of how I built us a little bit later but yeah just say that if you want to follow along it's not just HTML you have to run this repo cool um so yeah hope it was fun good right now I know I am like up my favorite coffee i got my cat hair hoodie

i'm ready to rock so this is going to be a little bit different so my slides it's just a full presentation but i'll be showing a little bit more code than the previous talks have been doing I've been doing a lot of experimenting with some of

the new features coming out just people have been complaining a lot about modules and like which format am I supposed to use there's a couple of posts that have been coming out recently leaning towards Ekrem script 6 so I've done a little bit about

that and just seeing what it's like to build on that bone out that way so I mean did slides up cool see the total top is growing up a backbone and this was a just a title in my head that I had for a while before I comment came up with content for it and

it's just that I felt ever since I started using backbone and become a stronger developer even though there have been times where I wish backbone did more for me the fact that it didn't it kind of gave me that opportunity to grow my skill set so I

talked to a few other developers and they kind of inspired me subliminally that you know there are other fellows need this help maybe they don't when I start giving these slides and seem really obvious every single step yet I see so many boiler plates

that are getting released and people talk about web app development they don't even scratch the surface of some of the stuff so um this line right here is something that had discussed with the mic stand to the left of me and I had to sell them on what

I meant so so through the nature of the weapon like specifically in this case and backbone we're all becoming our own little like fun and independent framework developers who have to like cobble together a whole bunch of different random projects to make

our own projects build and run and do what we want them to do cific we're always assembling pieces and as they come together we have our own little thing that maybe you have our own personal background boilerplate so that's a unfortunately domain title

it's really tense workflow project is so as I come up with better ideas I put them into this project and I discuss with other people there's m / tools and brian florence created his own workflow to work with ember and i'm sure you have your own

if your add your own company using java you probably have some kind of weird build script that puts together application you're becoming your own little framework engineer so the three parts of this talk they're originally for I was going to try and

get to data binding but all the good presentation books that you do three sections so one with three I there's going to be plenty of content I'm going to go for another 40 minutes on this though so where to start with structuring so just like what

do you need to structure your application and that's not necessarily what module system you're choosing for what template engine or anything like that this is not like how you put your models where where you put your collections this is like how is

the file system structure how are your tasks running in order to build an optimized distribution then we're going to go into like modular development like what are the different modules systems out there and we're going to look at some code that I've

written right now that I think has the best possible way to use either AMD or echo scripts six at this point and the last bit or just how what are some techniques for using components what our web components I was going to do a deep dive onto like shadow DOM

and some other piece like kind of like very expansive SPECT components of web components and that's not going to happen i'm going to go over how i see developers using backbone integrating with the methodologies and philosophies of web components oh

actually I just forgot that I implemented speaker slides or i'm not even using them also okay so these two philosophies are not mutually exclusive by any means I'm just trying to take two different ideas that I have found that are very distinct and

they're very odd what's the right word like specific so like the Linux philosophy that I picked us through arch linux and that's the distribution I'm running right now they are very geared towards elegance and simplicity yet giving you all

the options available so like they give you everything up front it's up to you to customize what you want but they not they're not layering tools upon tools that make this job simpler you know they're keeping it raw and basic and there are a lot

of purest developers that really abide by that methodology they want to keep things pure simple basic and then you have the Apple philosophy here and this is like after Steve passed away I've been watching all of his videos and this guy's a genius

and one of the videos is when he got magically announced back at Apple I could nobody knew who he was doing this so the guy who followed him even kind of freaked out but it's up a 25-minute mark this is what he's demoing open next and it's integration

and what's happening is these objects are just communicating at runtime no codes been generated there's no code to maintain what we found a long time ago was the line of code that a developer can write the fastest the line of code that a developer

can maintain the cheapest and the line of code that never breaks for the user is a line of code a developer never had the right yeah you know you don't have to write any code you can start building this app and I feel like we're seeing that a lot without

a front-end web application frameworks they're talking about less code to write less boilerplate we take care of eighty percent of everything for you and that's just a totally different methodology so I think there are two distinct philosophies here

the kind that wants everything up front no magic no surprises because that's how you build an app that's your mind works and there's the other philosophy where it's like you have made a prototype if you want to thank something out pretty quick

with you just need to get something working the Apple philosophy might kind of a line better with you and the reason i bring in these up are taking a step back and I stop being so opinionated about things because I realized people have different minds you

know we think differently so when somebody complains that oh why are you choosing node modules and browserify this is clearly the obvious choice I'm not going to bash them back and say no because can't build stuff asynchronously and that's something

I really need you gotta explain that I need more control more flexibility and that's just a different philosophy that I subscribe to so it's just like this is something that I've seemed very common that people are on either time and trying to convince

the other side to go there I think it's going to be kind of aware of this as developers so to start it's a web application structure so I was talking to Mike again about like how frameworks and modules don't really have anything to do with your

structure and the cool thing is it's kind of evidenced by the UMD patterns which I'm going to describe later in the modules section but this allows you to kind of unify all these different module formats together and have your code run in all these

environments that kind of that just the fact that we can do that kind of really separates the need for your framework or your your structure to be tied to a specific module type like a specific module format and when we develop our JavaScript and our coffee

script it all gets compiled down to JavaScript of runs in the browser so that's just the one thing think of so when I work on my web apps I can't organize the files wherever I want cuz I know in my mind it's like a sieve and it just comes down

and it ends up in either one CSS file for one javascript file okay so I'm already getting into grunt here but I'm pretty so long run as my task runner make is just as good so you like if you prefer mate that's fine the concepts I'm going to

go over just the steps and the tasks that I run in order to build my application and to structure it and keep it maintained and the whole point of this is that you can actually have more maintainable code so there's nothing that's saying you can't

just write script tags and drop them to your page but are those are those scripts going to be of the load independently another when you're testing and keep them in an isolated environment this is just going to be questions that pop up later on we're

kind of has a fanatical and they things work that way so I prefer to have a very strong foundational structure and I find the developers who can quickly adapt to that like they can see ok I know where this code is because everything works the same way it's

all structured they are easily onboard and onshore project and that's an anecdotal thing that I've noticed there's from developers that are working on these larger applications it was great because I worked on one app where we needed to bring in

one extra developers a Python guy he's full stack but he was able to jump in the product and start working on code and I really kind of blew my mind I thought Anthony like hold his hand and help them through this but we have a decent build process if you

can see the lifecycle of how stuff works it makes it a lot clearer so I'm going to start with really really basic let's step all the way from I don't know where everyone's at with their build.prop how many people here use a build process like

even for your personal projects are we doing build processes or is it more kind of like and that's not as important it's really when you're working on a team that a build process really kind of shines and having proper structure but that at the

very beginning I do this even on my personal projects now I always separate my vendor code my third party code from my own application code so this seems like really really obvious but so many times i'll just see everything dumped into a Java scripts folder

that's your code and the vendor code combine and there are many reasons why you don't want to do this and I'll top my head what I can think it's like when you're hinting or lint in your code the rules that your third-party code have abided

by in there they have their own strip checking that may not necessarily work well with what you're writing your code so for instance they can be using strict and you're not using shirt and now you're mixing these so yeah that's not what we

want so we want to keep that code separate so starting to play even higher level this isn't any slide worthy but you really want to be lending and cleaning out your distribution directories so that you don't get any surprises so so many times that

[ ... ]

Nota: se han omitido las otras 5.736 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.