Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good afternoon I hope you all enjoyed your coffee and your short break I have the pleasure of introducing Jersey beach one of the overarching themes of the front end track this year is pushing boundaries going beyond Drupal and taking what is already a powerful
tool and pushing it to become even more so naturally I reach that too Jessie because she is one of the persons one of the people have been pushing Drupal you shall reach his keynote this morning you saw the accessibility maybe show the toolbar this is the
work jessie has been working on and taking an already complex system and then pushing it and yesterday I was tweeting with her and she was at the sprints and naturally she was in the heart problems sprint cracking the problems that nobody else can so so without
any further ado introduce you Jesse beach so how many people here are front-end developers an tastic I am too excellent I was hoping I get a lot of people in the room front-end developers so the name of this talk is evolving front-end development but it's
a bit of a pun because front-end development is something that we are evolving in Drupal we're making it better but it's also something that evolves around us and I like to refer to this field as dancing on the tip of a hurtling rocket because as front-end
developers we're in a field that changes what feels like almost daily so I absolutely love the web this picture to me just expresses the feeling that I have almost every day when I get to sit down and write code to invent things and to make content findable
but the front end is also a place of mystery and and in fact terror some days I feel like you know I'm presented with problems very often that I don't know how to solve that require me to you know dive into forums and you know lists so I wanted to
kind of get a sense of how much information is out there that a front-end developer might pass I have to know for you know becoming an expert so I counted all of the specifications and the recommendations out there in the w3c that you know you might in one
day have to read or have to be familiar with things like you know css3 CSS to the akron scripts but also you know really esoteric ones like geolocation or web workers and it ends up being a lot of documentation i mean just for javascript there are over 80
things you might have to read and they're not exciting reading to say the least and as i was counting those numbers i got this tweet from kevin subtle talking about display properties that i hadn't known about up to that point and i just had this moment
where I was like and now there's something else I have to go in research like I have no idea what indent edge reset is for display mode and I felt like I understood CSS completely up to that point I also put together a list of responsibilities that a front-end
developer might have and went and counted all of the different libraries like the third party libraries that you might have to someday evaluate or understand to know like should I go with angular or backbone how we're going to do our behavior driven development
you know any type of responsibility that you have as front-end developer is probably already represented in some library and there's probably 15 of them that do the thing that you need to do and it just creates a lot of noise in the front and development
space to understand you know how do you choose the best path to get your job done so I tweeted out this list and I asked for input from people that follow me and mark drummond responded that of the list of things that I had put up as responsibilities for front-end
developer i forgot crying and i had to agree with him when you look at this list that has like 60 responsibilities it feels completely overwhelming so whereas some days you know i feel like this most days there are definitely some days where I feel like this
looking at you know how we as runnin developers complete the requirements we have to do and how we do it in the best way possible that makes our users as successful as possible so during this talk I really want you at the end to feel good about what you already
know as a front-end developer and to understand that there are areas that we all don't understand within this community we're constantly learning from each other and with in Drupal 8 itself we're trying to build in support structures and features
that allow us to develop you know as quickly and and to the best practices as possible so we have to talk about doubt doubt to me is something that I feel every day and I like to express this because I think too often we we get the sense that people that we
aspire to or esteem know a lot more than we think they do I certainly feel this when I look at someone like leave Aroo I get the sense that I just don't understand CSS given you know the types of things that she's she's doing in her research so
a really good example of you know this kind of fundamental moment of doubt to be experienced came during the development process of Drupal 8 so in 2011 Drupal kind of opened its arms wide to outside libraries you know we pulled in Symphony we pulled in guzzle
a little bit later on but we also pulled in some things in the front end we pulled in two libraries one was create j/s crate j/s is a library that essentially looks to the page finds anything that's editable makes that editable takes those changes saved
them and provides them through an API for you to push back to whatever you know system you have behind that to save that content in our case it was Drupal so this allowed us to very quickly you know short circuit that piece of the puzzle that we were trying
to solve for in place editing by giving us something that understood the Dom understood its semantically and then gave us information about how users were editing those pieces create j/s was also nicely coupled with a front and editor that we wanted to put
into core Aloha Aloha was being developed as an html5 of standards first in place editor just like ckeditor tiny MCE we had this crisis moment in late 2012 when we had been pushing forward with Aloha editor we knew there was some gaps in the function Ellen
did they supported one very striking gap was the fact that you couldn't use Aloha on the back end on a back-end form to edit your content and we kind of had the sense that we're going to have to solve that problem in the future but then out of the
darkness of their closets were they were developing the ckeditor folks emerged with not only an in-place editor but an editor that could work on the backend that had 10 years of development behind it and had excellent support for accessibility they also came
to us with about four developers in two weeks of their time to make an integration with Drupal we we reached this point where we had to make an incredibly painful decision to break the ties with Aloha the relationships we had formed and to also give up in
about eight months of work that we put in up to that point and essentially take a dive off a cliff and take a chance that we were going to make the right decision to switch editors essentially while the plane was in midair so I want to take this point just
to mention and this is something that I think about is a front-end developer everyday that behind every line of code there's a fragile ego seeking affirmation you know we write code because I think we love it and when someone else loves it as well it's
a good feeling I know that some days I'm not the best at being a positive force in development specifically when people mess with my passwords not making or allowing me to make my passwords as a as strong as i'd like them to be i actually think about
this tweet a lot when I'm just about to like rage on somebody for doing something stupid I step back and you say know what I've probably done something stupid like that as well all right anyway so back to create we pulled out Aloha replace with ckeditor
the reason that we had create in Cornell was coming less and less salient and we were running into problems with the model that create has for editing content in place they have a field based model so you added one thing you make a change you save it and that
change gets pushed you know back into your content management system we were trying to move to an entity based editing model where you'd edit multiple fields in the front end get all those changes into a package and then push that change back into what
maps nicely to a revision on the back end in Drupal the problem was that the model inside of create was almost impossible to change and I personally SAT there for about 48 hours coming up to a weekend trying to decide if I just didn't understand it as
well as I could you know was I not understanding this library or did it really not do what we what we needed it to do so I spent a weekend looking at the possibility of running through this codes essentially bypassing create and getting to the point where
I could edit something on the front and of Drupal and save it on the back end without create doing anything and I managed to do that so with that very happy prototype in place we looked at some of the other factors that affected this decision one of them being
the commit history of create up to the point in April where we were faced with this decision to to pull it out and you know build our own code or to keep it and we had to recognize that there just wasn't the activity in this project that we had hoped was
[ ... ]
Nota: se han omitido las otras 4.741 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.