 Hello. How are you doing? Are you sleeping now? Okay, fine. My name is Michael. I am a front-end developer at Yandex. I also teach JavaScript, Node.js and other web technologies and write about them. And if you miss, Yandex is a major search engine in Russia. It also provides a number of web services and mobile apps. And today I would like to talk about components. Oh, and if you like naming them modules. I think you know we have such a great tools like libraries, code libraries. They have abilities to build our applications. They save our time. They help a lot. And as GeneRazix said, jQuery was designed to fix a massive web. The massive donk, excuse me. Underscore fills ECMAScript 3 to ECMAScript 5 gap and Backbone and other NB, whatever library structures our applications. And all of them were created to fix a web in a some way. And today every great tool or library is, well, is a code library, not a code component. And what's wrong with these libraries? And I see these libraries like book libraries in real life. In Russia we have some of them. In each library is boxes with paper cards. On each card there is author name, a book name. And if you want a book you have to look through all these cards, write down some code, book code, and bring this code to the librarian. And only then you will get this book. Libraries, code libraries are big and complicated. It's actually hard to understand how they work inside. Well, it's easy to understand the interfaces because there are so many articles, so many questions on Stack Overflow about, well, AJAX to play it in anything about jQuery. But it's hard to understand how they work inside. Because, for example, cyclomatic complexity of jQuery AJAX is 43. This is a crazy number. And this means that you can execute this function in 43 different ways depending on its arguments. These libraries are too powerful. I think Lowdash is too much powerful. And some of jQuery functions are powerful too. Just take a look on AJAX or Animate. And even it's hard to get a small part of this library because it's tightly coupled. Well, it's possible to get just AJAX or template or jQuery deferred from this library because, for example, jQuery is using AMD modules and you can get a simple module and this module will bring also some unwanted dependencies. And also there are a lot of good interface elements which depend on jQuery. And only if they need a simple selector engine, they all want jQuery and become the plugins of jQuery. So if you want this library or, well, this component custom like gallery or custom select box you have to include jQuery because this library forces you to do that. There are also many libraries which wants more than one big library. For example, it wants jQuery and underscore and it becomes a big library on top of other libraries. And also these libraries force us to manually manage their dependencies to download certain version of their dependency to include it before the code of these libraries. And I want to say thank you for NPM and BoA developers that we have such a great tool which do a half of our job. It install all dependencies which all these libraries want. And all these code libraries were created many years ago in order to fix a messy DOM or fix some missing parts of web. Well, for example, in two years jQuery will celebrate its 10th anniversary. It's a big day. And today, I think web is fixed. It was actually fixed after EA9 release. And now browser passes AC3 test. They has valuable APIs like local storage, selector, Sanjian, even XMLHPRequest level 2. And they all have ECMAScript file. And in case of some of these APIs are missing, we can easily fix them using one of these great polyfills. For example, for HTML5 tags or ECMAScript 5, we can also fix CSS3 selectors. Well, CSS3 selectors polyfills are actually slow, but still many developers use it. And I think you know that we live in the era of mobile devices. And most of browsers of mobile devices were created valid from the very beginning. And according to the statistics, the quantity of mobile devices is growing. And this year, they will reach the quantity of desktop devices and go even beyond it. And I want to ask you a question. Why do we use these libraries? Who is using jQuery? I think it's obvious question. And who is using jQuery partially? Only Ajax or only DOM manipulation. No one? Oh, one hand. Well, I think it's all historical reasons or maybe we have some legacy code or some plugins which want Ajax query and you don't know what they want exactly from jQuery. Maybe DOM manipulation, maybe CSS management or maybe some animations or maybe Ajax, you don't know. And let's look at this problem from another side. And if libraries are sets of functions and then components just one simple function or two or three of them? No, it's not. It's okay? And this? Okay. Then components is just a simple one function or few of them. And components can consist of other components and be a part of a bigger component. Components are simple like this equation. They lightweight. For example, there is a DOM component which provides jQuery style, DOM manipulation and event management. And it's only 28 kilobytes uncompressed. And these things you do all your time. I think 99 or 90% of time you spend with jQuery you do event management and some DOM manipulations, fighting, replacing, adding. All these components do one simple job. They have single responsibility. For example, there is a component named DOMify which simply turns JavaScript string into a set of DOM nodes. And this is it. This is its job. And these components are simple and it's easy to understand how they work inside. It's easy to send a purchase to the maintainer and write a test. Also components are standalone. They contain all dependencies and most of them are external. And you can simply move one component from one place to another or copy it. Then install your component and it will work as a design. And the last principle of successful component, they are isolated from other components from the environment. There is no JavaScript leak, no CSS conflicts and if it's possible flexible layout if we are talking about UI component. Also they have restricted access to other components or their siblings, for example, using require function. About two years ago W3C released first working draft about web components, not just components, about web components. And have you ever heard about them? About web components? Yeah, a few hands. That's great. Last year I actually also talked about web components and there is a link below to this talk. Just take a look if you want to learn more about them. Well, components is actually simple idea of custom HTML elements and some APIs to build this element. And that's it. And that's all. Web components are not so common now. All of them are landed in Chromium-based browsers. Some of them are in Firefox Nightly. But all of them we can fix using Polymer project in any major browser. And actually web components don't bring anything new. And all of these web components APIs are already implemented in different component engines. Well, for example, we can simply replace Shadow DOM with BAM methodology or template binding with any declarative template engine. For example, from AngularJS or from Nacout or even we can use RISJS. And web developers may choose one of these component engines and create almost the same component. Well, for example, just take a look at React. It's a great library, great component engine. Or even we can create almost the same component using all-style jQuery UI widgets. The same idea by different interface. I mentioned also BAM before. And have you heard about BAM? Astia was a warrior. He has a talk about BAM. Well, anyway, I should mention some core ideas of BAM. Because I'll use this methodology in my presentation further. The main idea is to avoid CSS cascade and use CSS only as style sheets without first C. BAM consists of three parts. The first is block and in terms of web components is a custom element. Block consists of elements and in terms of web component element is Shadow DOM. Also, there is a modifiers which can customize the view of element or block itself. And also quick example. This is a tab panel block. Tab panel consists of elements and this selector describes element, tab and each element may have state active. And this is a modifier. Just a quick example. I think all that theory about components and web components and custom elements is good. But I think it's better to practice and create a custom element using only simple functions, simple components and modules without using any big custom component engine. I named this component my share. Well, this is just an anchor and if you click on it, it will open Twitter share window with custom text and you can share current page with your friends. This is stupid simple component. You can't see. But before we start, let's keep in mind three main principles of successful component. It should be simple, isolated and standalone. Every component begins with simple package file. This is like a contract. It contains component name, version and its dependencies. And you can't start building your house without agreement with builders or without contract with them. And you can start writing your component without that package file. Right now it's simple. Only name, version and internal dependencies. And this is about JSON format and we will use in Bower as our dependency manager. As soon as we have this file, we can start thinking about our custom element layout. And this layout is also simple. It consists of three tags. The root tag is anchor and it has plus my share and in terms of BAM, this is a block. Block consists of two elements and icon and label. And that was a private HTML interface of our component. And we should simplify it and only then this component can be easily used. And if you notice this my share custom element is just an anchor but on steroids. We'll add some custom tags, data href and data icon and this is it. And this will be interface of our component. And in comparison with web components, the custom element of web components are much the same. Just take a look. Web components and this is our component. Also CSS of our component is simple. We are using BAM naming conventions to define some styles for our elements. And if we compare CSS of our component with CSS for web components, you will notice they are much much the same as well. Just a few changes. CSS of web components is isolated due to DOM APIs and CSS of our component is also isolated due to BAM naming conventions and avoiding CSS cascade. I think it's really possible to create a successful component using just DOM APIs but I think it's better to include some helper components which can greatly reduce size of our code and also development time. We will use a simple template component. It's a part of low-dash. And we will use this DOMify thing which I mentioned before. And to keep this component standalone, we should declare all these dependencies in our package file. Well, it's time to write some JavaScript. On top of our module, we ask for dependencies using this require function. We don't get them from globals or any namespace. And this keeps our component isolated from other components, from other modules. Then we simply require our template and turn this template to the template factory in order to reuse it. Logic file components is also simple. We get component state or component options, then render our component, then bind events, and finally put it into the DOM. And at the end of our file, we just export this component. And that was command.js format. It prevents us from globals leak. It asks for requirements and provides some resources. And if you like AMD module format more, you can also use it in your components. Now we have our JavaScript, CSS, and HTML layout of our component. And it's time to build this component. And building process is required because we're using some external dependencies and we must include them into our final JavaScript file. Also, we can use styles for CSS and copy script for scripting and we should compile them to the native format. Assembly process is also automated and simple. And developers may choose one of these build tools to build to assemble their components. For example, Browserify or BAM tools or even LMD. And at the end of building process, we will get only two simple files, just CSS and JavaScript for our component or our page. And this is a final layout of our component, of page with our component. And just take a look at web component. And if you notice, they are much the same, but one line less because HTML import is already includes CSS and JavaScript and some templates. Different interfaces, but exactly the same idea. And this is a live example of my share. This is a simple anchor tag. And if I click on it, it will open Twitter share page, but it's Internet and Wi-Fi is not so good. Well, anyway, let's close it. And this is a content of this page. Simple script, simple style and simple interface of our component. And this component is declarative and that's why there is only its own scripts without code which activates this component. Many developers used to build their applications using this application layout strategy. There is a DOM. It may be fixed or not, but today in most cases it will be fixed. Then we add some libraries like jQuery, yellow dash, backbone, whatever and on top of this better DOM, like DOM and on top of this DOM is better DOM with better functions. We built our application. And I think for the modern web application, especially for mobile applications, this strategy with polyfills and components is better than the previous one. So also a DOM in most cases will be fixed and if not, we will add some polyfills. Then we add a layer of custom components of third-party components and on top of these components and polyfills we built our application. And this is a final slide and what I want to say you at the end of my talk. Web is valid. It was actually fixed after E&I release and we are living in era of mobile devices and their quantity is growing and they will go even beyond the quantity of mobile devices. Libraries are big and clumsy. It's hard to understand how they work inside. It's hard to send patches to the jQuery or any other library. But it's simple to understand their interfaces because they are so popular. There are many questions on Stack Overflow, there are many articles on web. And I see web components is yet another component engine, but it's powered by W3C and it's official. And that's why it's so popular now. I know it's hard to throw away jQuery or your favorite library and use this component approach. But you may try it on your next web application and only then you can help build modular web with simple components and without big libraries. Thank you. And if you have any questions I'm ready to answer. Also there is a bunch of useful links for code on my share component and you know to do this thing. Yeah, one question. Is it possible to build web components keeping progressive enhancement in mind? Can you please repeat your question slowly? Is it possible to use web components and still keeping progressive enhancement philosophy in mind? Yeah, why not? How exactly I would like to know. It's possible to create the custom layout of custom components, custom elements and enhance this layout with JavaScript or CSS of web components. For example, we can create a layout of custom select on top of just select. I have a question. So how does this compare with Facebook's React framework? Yeah, yeah. Hi, so how does BEM compare with Facebook's React framework? Facebook's React framework is also about components. It uses some sort of shadow DOM or some... Yeah, exactly. They have similar ideas but the different interface and also BEM... Well, actually BEM consists of two parts. The BEM methodology is how to create... how to write styles, how to write selectors, how to put your styles into folders or whatever and it also provides some tools and BEM tools is really close to the React. Any other questions? Any questions? When we say terms of components, so basically we are creating our own set of components from our own code base instead of using libraries. So in that case, don't you think it would be more time consuming because sometimes it's very easy. Let's take an example of AngularJS or jQuery framework. So these provide functionality which can be very easily reused and generally when we people are working here sometimes we have to develop things very fast with maybe the exact set of functionality. So in that case, how will you suggest, how we should approach? Is the component thing we should be going with components or is it a good idea to go with frameworks? Well, I think it's faster to create applications using jQuery because all of us are used to write our applications using jQuery. It's just our experience. But we can do exactly the same thing and even better using components. And if you understand the core principles or about jQuery style event management or DOM manipulation or whatever or template binding, you can simply switch from jQuery into a set of simple components. Or you can throw away, for example, AngularJS and use RevistJS with simple model library or model component which provides only data storage without any layer of IJAX layer. Any other questions? Well, no more questions. Okay, thanks.