MountainWest JavaScript 2014

Gestionando los módulos de EcmaScript 6 en el navegador

Guy Bedford  · 

Transcripción

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

thank you all so much for inviting me here to speak with you I want to share with you three projects related to package management and module management in the browser and instead of just diving straight into these projects and trying to justify them to you

and explain them to you from the from where they are today I thought a nice way to go into it would be to actually start by explaining to you how I got involved in these projects in the first place and then the decisions can make a lot more sense from that

perspective so two years ago I was basically began work on this framework cords sjs and I been working on a number of dynamic web applications and one of the things that I was asking was the same sort of question that seems to come up time and time again which

is how do you actually build these things and how do you encapsulate parts of components of your app and really modularize so that you can have cleaner code and it was that kind of idea just how to encapsulate a single component that I was working on in zest

year so I really dug into this problem really enjoyed digging into it and as I got deeper into it just felt like it really was a problem with module management so then I found requirejs and this was an amazing project I absolutely really liked the ideas and

started bringing this into the framework so what I managed to do was basically design the different components to each be a module in requirejs so that you could basically naturally through the modularity of the app it created a natural encapsulation and a

code organization without needing much more than that and basically what ended up was with something like this so you could require a component so say you had a dialogue or something the stylesheet was a dependency so I used a require JS plugin to automatically

inject the style when you load the component so as soon as you require it the Styles been injected and then the templates as well would be part of that so you just render these components into a containing elements and with some rendering options so any component

could have some options so I was pretty excited about it I worked on it for quite a bit of time went down lots of wrong paths and sort of came up with a system and I was ready to now sort of send this out to people get users and hopefully get some feedback

on it so I started posting out to websites and the next thing I wanted to do as well was the natural part of using modules to kind of structure app is that you can firstly it's the code organization perspective the second part of it is you can share code

between apps so if I make a dialogue component for one side it should be very easy to use that dialogue component on another site so if I wanted to actually use this dialogue component on another site what I need to do is share this configuration so I'd

need to make sure that the same require JS configuration was shared with the other sites and this was immediately a hurdle so this require JS configuration really is a massive pain and I don't know how many of you use required yes but this is really what

what kills the the experience of it we none of us really know quite how to configure we're all using slightly different configurations and there's two main problems with that we need to be referring to modules by the same unique names we need to be

calling jquery the same thing we need to be calling bootstrap the same name so that my modules can work with your modules so if we really want to be able to share code we need to be sharing module names and the other side of it is that all of us are individually

doing this configuration and the shim config and all these things but we're all redoing it none of us are really sharing the configuration that we're doing so if I want to use bootstrap I have to go through the same process of working out okay it's

dependent on jquery and it has to export the jquery export so it's going to be easy to require and then everyone else has to do the same thing so i'm not able to share my configuration with you so I was just wondering about how this can be done better

because i really wanted an easy way to share these components as modules and around that time there was this project jam i don't know how many of you have used this remember it but this is great a really amazing project it was a front-end package manager

I think it was probably the first really decent front-end package manager and what I would do is we have the same names for the modules so when i install backbone i just require backbone and we're both talking about the same backbone module so my code

can naturally work with your code and then would automatically at the bottom you see updating required config die jeaious so it automatically inject the configuration necessary to shim these modules to make them work correctly so it's solved those two

problems unique module naming so globally unique module naming just like urls a unique model name should be unique and configuration injection and sharing but of course being a developer I had to question whether this could have been done even better and around

that time I was talking with Adam Kishan of its he was working on a framework called kick strap and he was saying that what he wanted for his uses was the ability for them to just open up an HTML page and start developing he didn't want them to have to

install a offline package manager so I was thinking about this and it made a lot of sense actually the web was very much designed around this principle that you can just open up a web browser and start developing as soon as we started making tools a prerequisite

to development we immediately kill that workflow which is one of the fundamental workflows on the web so it seems to make sense that you know if you want people who are less technical involved in a website and still to be able to work on it and load it in

a development phase it could be a nice thing to to maintain and the other thing is making it really easy to to load modules the lower the friction is to using something and especially on the web we feel is so much the lower that initial barrier to entry the

[ ... ]

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