 Okay, so we're going to get started. As I said, this is the first time we've done this. I'm going to introduce the idea. I'll let the people who are up here in the panel introduce themselves. We've got, most people will recognize these three guys. They've all been up here at one point or another talking. But let's talk about the format. I'm going to be a little bit of a dictator for now. This is what we're going to try this time, but we're totally open to different ways of doing this. If you guys afterwards say, hey, you know, it would have worked better if you did it some other way, just come and tell us that. But basically, we've got 40 minutes of which we'll spend the first 30 just doing a structured Q&A. So me interviewing the group, if you have questions that are more of a clarifying questions I didn't hear or I didn't understand, you can ask that during. But otherwise, just kind of hold your questions. We will have time at the end of it. I say 30 minutes. I don't really know exactly how long we'll go in this kind of structured Q&A, but we'll leave some time certainly at the end for you guys to ask questions as well. Hopefully that works. And without further ado, I'm going to turn the light off of Alex. He doesn't have to stare at the sun. And we're back. Okay. So we're here to talk about Ember's views versus components. I am going to ask the audience a question first. And that is, how many of you have written a view in Ember before? And a component? So similar group raising their hands. I think a few more on the component side. Okay. Well, that's good to know for the panel as well as myself. Can we just go kind of, let's go left to right or Alex driving through? Okay. So hi, my name is Alex Speller. I'm currently lead developer at a company called Digital Science, which is a sister company of Nature Publishing Group trying to figure out what's happening in science publishing world over the next decade. I'm going to start up myself. My name is Christopher Gammie. I'm working on my own startup, which is something called Dance Cloud, which is kind of event management and ticketing system for dance organizers. So that's currently in a kind of private pilot at the moment for a few selected organizers. So that's what I'm working on at the moment. And I'm Jen to craft our company called Minified. We build web products, clients and some of our products ourselves. We'll be releasing soon. Great. Okay. So I thought maybe we start with a very quick history. As I'm sure all of you know, Ember is an MVC framework for the front end. The C doesn't stand for component. It stands for controlling. It wasn't that long ago that views this conversation wouldn't happen because we weren't the work components. I think it was around. Was it August, September of last year, somewhere in that sort of timeframe, but components came around. And I think the question of which one should I use has been asked ever since. We're going to not try to aim for concrete answer, but hopefully have a good discussion about it. The in terms of the overall history, I think the motivation in some part was for components was to line up with the web initiative of web components. What I'd ask the panel though is do one of you want to just take a stab at talking any more about either the Ember part of the history or how that alignment with web components? Okay, fine. So I mean, first off, one thing that's quite, probably the dimension is the components are a subclass of views. A component is a subclass of the view. And they are very, very similar in a lot of ways. I'm not sure we'll get into that in the future. But in terms of web components. So I know that you heard a cat is part of TC 39 is working, working to improve standards for the future web components. One of the things that is hopefully coming in the future to improve building stuff on the web and improve building interactive web applications. And I think that that's something that's going to be really useful. Web components. You mentioned TC 39. Is that web components? Is that the same? I believe I'm not entirely clear on this. I'm completely wrong. But I believe that that's part of a standard body that's one of the things that they're going to be able to do. By the way, just for the audience, what I'm doing here is entirely unfair. What I should have done is I should have let these guys know what questions I was going to ask them. That's the way it's normally done. Sorry. So I mean, anyway, we're probably the best way to describe web components is a way to abstract the DOM from reusable components. So a good example is given is a component where you would have effectively make a new HTML tag that would be a comment tag. There are some naming conventions that in Ember are components have to have a dash in the name. I believe in the local names, but I have to start with x dash to their extension. And the idea is that you have some DOM in the component that is not visible in the DOM inspector. And is not visible when working with that component in the DOM and in JavaScript. And it basically lets you abstract functionality in a reusable way. And in a way that's consistent and in a way that doesn't, you know, is not the kind of basically JavaScript jQuery mess that's very, you know, the way that you do things at the moment. If you were another example, it's like a calendar component. If you look at jQuery UI, that has a calendar component. And, you know, what do you expect that in the DOM inspector in the debug tools? What you get is a load of table tags. And, you know, you're seeing like this structure of this component. And when you compare that, for example, to input type equals date, if you get a calendar component in HTML5 input, you literally see input type equals date, you don't see how that component is built, even though in WebKit that would actually be built probably with HTML internally, sometimes. So I guess that may be a intro to the Web Components idea outside of them though. Okay, well, that's very helpful. Do you guys want to add anything else? Or is that I don't know. I definitely think about it as just creating my own kind of a DOM element. I've invented my DOM tag. So if I've got something I think I could use this in any other scenario in any other application, or I might use it a lot of times in different locations across my application, then to me, it's just kind of it's quite a clean way of abstracting it to think of it just as its own effectively a DOM tag that I've created. And the other component can achieve the ability to do that. So that's kind of how I think about it. Yeah, I think the specs actually for Web Components encompasses like five different parts that make up Web Components. And the part, I think, Ember Components are most common with the custom element, the custom element section, which allows you to define these abstractions that you have referenced in your HTML. So this is probably me asking a dumb question. But so, you know, I remember, I think the original description that was either on the Ember website, or it was kind of through some sort of Ember official channel, the big benefit was you could build these components. And I thought, okay, my first thought that sounds great. I don't something like I'd like to do that. But in fact, you know, when I look at a component, I mean, I do like syntactically, I like the way a component, you know, looks on a template, but it's not really that different. Is it from just being able to say view, and then doing the same thing? I mean, so if you want to create a comment, you could say view, and then create your comment. I mean, the big difference, I guess, is visibility and scope of the variables. Is that right? I mean, for me, the biggest difference is the scope variable. So all the scenarios that I'm using it in, I want to, I want a component to be self contained, so that it doesn't matter what my controller or my model or whatever the property is called, I can reuse that component by passing it in. And I know that it's going to be contained, it's going to be dealt with, contained within the component. So that's kind of how I'm using it. Wherever I've got something I want to manipulate, particularly something on a, on a model that I want to just control in different scenarios, but I don't want to be, I want to be a little bit agnostic of what it's called on the model and things like that. That's where I use a component. So the example, the main one that I've got going is I've got a countdown timer that I put in different places across the application. And on the models, effectively, what I do is passing the relative, in the component, I call it relative date, so I'm passing the date from the model from that. And wherever I use it, I know that it's being used in exactly the same way. It just occurred to me, this isn't going to be a bit awkward, but like, even though I'm asking you questions, and I think it's very nice that you're looking at me. Can you just pretend I'm not here and look out of the room? Because I think that'll work better for most people here. Thank you. Okay, and a very good answer. So for you, there's a clear separation in terms of that? Yeah, just, I mean, I generally, I like to build in a separated way. So I like to separate stuff out and have things as isolated as possible, and I know where the interactions across different things. Sorry, I forgot, I'm not meant to be looking at you. So yeah, so it just kind of, that kind of logic, the moment I read the description of components, it was that, it was that description that really sold it for me, so that I could really isolate and then reuse it as well in different places. James, do you have any sort of like rules of thumb that you use in terms of, this is, this out feels like a view to me, this feels like a controller. I'm sorry, not controlling, but about it. Yeah, so it pretty much everywhere where I would, in a template, reference a view, sort of historically reference a view using this ember view helper. Like now, by default, you define a component and reference it with the handlebars and the component name. That's the sort of like, the way that I do, yeah, do all of like the reusable bits of UI. I just always use this component. The only place where I define it, like actually use a view, is when I'm using the router and the templates rendered automatically for me and it's looking up a view with that name. Those are actually the types where I define a view class anyway. Yeah, so you're starting to go into a question I was going to ask and I'll ask all of you guys. James, you got already answered in a way, but let's imagine that you're going into battle. You've got your MacBook Air, you've got your favorite editor open, and this use case kind of is charging out of the woods. And you need to tackle it with either a viewer component. Are you pretty much just going to go with one? I mean, so it sounds like for you, James, the answer is 99% of the time it's going to be component for you. There's the kind of automatic stuff that you kind of feel obliged to go over the view route. But how do other people feel about that? Is that also the way you'd approach it is mostly components these days? Or well, the app that I've written, I don't think I've written any custom views in it. The only views I've got in it are where I'm extending a view from the framework and customizing it. But yeah, so basically, pretty much everything I've had to write, I've just gone with the component. Because generally, I can see a case that I might use it again somewhere else in the application. Or I might use it in a different application. Plus, it just has that level of abstraction as well that I like. I found that, so I was working on a very big ember app around the time that I was introduced and had a lot of, you know, obviously had a lot of views. I think if you're doing custom DOM stuff, you will end up having a lot more views than you would otherwise. So this app was full of D3 charts. And obviously D3 doesn't support embers, data bindings. Natively, you kind of have to set observers and create the DOM in your view and then use the view to abstract around the events that D3 happens. So I mean, if you're just doing HTML stuff, if you're just doing relatively basic web app stuff or very complex web app stuff, you may not have much opportunity to have much call to use custom views. But when you do, I've kind of found that components tend to enforce good practices that you can code with views anyway. So components enforce isolation from the surrounding scope. And there's no reason you can't write views that are isolated from the surrounding scope. But they do, or views also have the default context of the current controller. So I think that whilst components don't really add a huge amount, they do restrict you a bit and they restrict you to what can be considered good practices, isolation, readability, and good things. Not good writing the same code twice and it's not good hunting down obscure bugs because things are interdependent on other things in your complex app. So I think that really a lot of the time components are a good choice over views. I think that one use case where views still are very relevant is actually building up complex components. So you can nest components one within the other. And so let's say it will be an example of that. Let's go back to the calendar widget where you might have calendar components. And inside calendar component you'd have like a day component that's 30 times for each day. And the problem with doing that with nested components is because they're isolated from each other, you would, let's say you're passing a date to the top level component, you then have to pass that date down into each of the subcomponents. And you might argue that that's not too bad a thing, but if it's something very complex you might end up having so much state that you have to pass down this tree of subcomponents that it just gets to be a hassle. So one perfectly reasonable use case is just using views inside the top level component so that your component is a single object effectively that shares a single set of state. And that way you don't have to kind of have these huge tags that are passing like five different values down the tree into the bottom layer of the dormant. I think that's probably one use case I can think of for a user. And you know obviously where you have to use views as part of the end of convention. So mentioned roots, that's obviously a root gets a view assigned and you know that's just how it works. So yeah I have no choice there. I don't actually see it as like a views versus components decision really. Are you a past this in January? No I just see the components as an evolution of the views. Just you know the custom elements from the from the spec are like clearly a good idea and the way that things are headed and this is like the way the ember is polyfilling now for that spec that hasn't been formalized yet. Yeah I see them as just like an evolution and like you should be or people tend to be using components like where they would historically use nested views like throughout their templates and things referencing these components for the reusable bits and then ember still using the views as part of the rendering like the root rendering processing. That's where you use views. This is just a kind of sniggly little question that I kind of started to run into. I was using the container view and what I don't know is to the container view doesn't actually have any templates associated with it and it's really used when you want to programmatically have a number of sub-views underneath it. Alex when you were talking about the calendar widget I was kind of thinking maybe in some ways that is well probably not the best example of that but it's a is there a comparable subclass on the component side that you can use that allows for that containment relationship easily to be set up? I don't think so. Yeah okay. I don't think it would be that hard to to write. I mean actually I haven't looked at the source code component for a while now but I mean last time I looked it was you know less than a hundred lines of code probably a quite a few more. I looked this morning it's probably about the same. Right. So I mean it's you know component is a subclass the direct subclass of handle view and there's not much there. There's quite a small amount of code there so if you want to duplicate the functionality of collection of container view in a component I'm sure it would be too hard to do that. Okay so this I'm not sure if this is a dead-end question because I think we've talked about it to some degree but when you think about the two. Well before I do that one thing we haven't talked about I don't know if this is kind of the third the third wheel in a way but what what do you how do you guys feel about handle bar helpers? Where do they fit in? Yeah that's interesting actually because I was thinking about that today I was reading an article about about ember components and they were talking about how to define components and things and they were working through an example and then they got to a point where they wanted to format a date and at that point they went and defined handle bar helper to format the date and I was thinking well you could just define a component for that right and it's got pretty much the same like syntax in the template when you look at it and handle bar's helper which you pass the date to versus like the name of the ember component that you pass date equals something to and like it struck me as odd that in this sort of article where they were talking about whether they're explaining components and the reusability of them and everything that they then sort of jumped off and to find this handle bar's helper and I was wondering like that's just like another thing thrown into the mix is this helper and I was wondering like what that gives you like how small do you take your components you know something like format in a date would obviously for the author it wasn't a valid use case to define a component but it was a valid use case to find a helper I mean it stops you with your extra div wrapping the you know of your element in the DOM that might be the reason they went that way but yeah um yeah your thoughts on well I suppose I use handle bar helpers to format dates things like that so I suppose for me it's the difference between my helpers and components is the components have normally have a little bit more to them so they don't have to so you could format a date just with the component but my components tend to either have that might have a few computed properties they might have action handlers on them they might have some logic and things like that in them which obviously that's starting to get very difficult to do that in a helper whereas it's kind of a lot more obvious to put it into a component so I suppose yeah I suppose without thinking about it I've kind of divided it on it do I need to do something extra with this rather than just sort of taking a value and just display formatting it or something like that for the user yeah I think there's definitely a lot of overlap there and I think that helpers might end up becoming you know less and less used just because so I mean stepping back a little bit I think controller in ember is misnamed and I think that leads to a lot of confusion I think the controllers in ambition really be named presenters because that's really the role they fulfill and why why I mentioned that is that formatting a date you know that's perfectly valid to do that in a computer property on a controller you know it's a presentation of the data and that's what controllers are really really good at so you know why would you then need to do that in a helper when you could just have a you know a formatted date property so I think that um so you have cats has a gist that I was reading in preparation for this and he was talking about the web components back and you know what how ember is kind of following that to some degree um and I guess that you know that doesn't seem to be like any proposal for helpers in you know the future of the web it's kind of an ember specific thing but web components are intended to be a subclass of html element um and I mean if you look at polymer um which I don't think most people may have heard of it so a google framework that's like a polyfill of the future api that's proposed um and it lets you kind of subclass html element um and sorry that basically lets you create custom elements which is what components let you be doing ember and the idea is that um polymer and ember have um have aligned long term goals but the medium term goals are not aligned um in the sense that ember wants to give a stable api at the moment um that people can use and rely on and the web components api is not necessarily usually stable at the moment it's developing things might change um you know stable is obviously a relative term in the entire world but um relatively stable let's say um and therefore components um are you know are likely to stick around long term um I'm not saying helpers are probably ever likely to be removed from ember but the concept of kind of components is something that's probably going to be relatively stable long term um both in ember and on the web in general so that everything that makes a lot of sense to me I I guess one thing I would ask is and it's kind of more of a philosophical question is ember is an opinionated framework um you know you can sort of see that these these things come in for logical reasons over different periods of time it's easier to be opinionated when you're young uh you know uh actually that's in life actually it's the way around um it's easy to be opinionated when you're old um but the um for ember I think it will be harder to you know to break out some of the old things so maybe helpers being taken away should should helpers be just be allowed to should be allowed to be allowed to have our opinions around these three different options or should they actually be simplified and one of them be taken out well I don't know about you know they're taking out of them because I'm like I was surprised today when I was looking at the um ember source and looking at um I think well I was looking to see where components were used in the ember source and I think they're used in the um in the text fields um there's a ember text field component which used to be like a text field view um so that's a change of component and then there's the um text area component I think that's the two points where components are defined but what I found interesting was that they then had um handlebars helpers registered for input and text area um so they're not using the component um like in in in your template in your templates you're not when you're not referencing uh the ember text field or text area component which you know you that's one of the things that components give you like you you define your component then you get to reference it in your template using that um they've gone to the trouble of registering these helpers as well so obviously they've done that for a reason I don't know what that reason was I just found found it interesting that they've they've got the components but yeah they're also using the helpers well I mean anything that you put inside the moustaches that isn't a property access is a helper so components are helpers actually um but I mean that's kind of an implementation detail when you say like my dash component um the reason that works is because a helper called my dash component has been registered based on the fact that a certain template with a certain name existed in your application when it booted um so I mean it's very unlikely that helpers will ever disappear completely um but I you know custom helpers I know I think you always have to be able to register them to extend them were an interesting ways but I don't think that you know I'm trying to think I can't think of a use case really where you really need a helper and a computer property on a controller wouldn't do like maybe I just have thought of them but I think you know in a lot of cases that makes sense and it also just seems easier to to to do like you know properties and um dependent keys have very clear semantics um and you know I've I have made helpers in the past and they you know it's been unclear if they've been bound correctly if they update at the right times and it's a bit fiddly okay uh so I've been uh told that we're a little bit short on time so I'm going to ask you know it was always the best question for last and this is a really a doosery uh but um and then we're gonna obviously have time for people to ask their own questions too so um so the a lot of the idea behind components is to be able to get reuse whether that's reuse internally on a project across projects internally within an organization or maybe even externally across organizations um and my question is and this I mean let's try to be succinct about this because I think we could probably talk about this for a long time we probably will at the bar but you know the is there any kind of best practice anything that you've found works well for you in terms of being able to take these components and a product and then reuse those assets could be my worst question I know the reusability across projects or even across so like just finding something that already exists on the internet pulling it to projects is is a bit of the unanswered question I think at the moment because there's all kinds of issues about some name spacing and things like that if you're of course a component can have a template that can be using CSS and tags in it and are they name space so that you can you know you can isolate all those kind of things um I think that that's going forward that that's when components will become really useful when you can like I need a I need a calendar date picker I just go on I find one that someone's already built for everyone pull into my projects and that's when they'll become incredibly useful but it's really unclear how that's actually going to work in a moment so I think that could be a really killer feature for him yeah November had like a really good library of components that you could easily install and I mean Joe I know you're working on command line tools and I don't know if you've considered this but um like I think I think that having you know having that as part of the default that comes with ember yeah could be really powerful just be brilliant I mean because there's no point lot lots of ember developers out there all building a date picker you know there might be you know you need a couple so you've got a bit of choice about implementation that you don't all need to start kind of reinventing those wheels so yeah it's just say if it could be incorporated in command line tools and things like that forever be incredibly powerful I think the building blocks are there I think that the building blocks are there and components enforce the practices that the development model that is necessary for that to work but I think we're right to what if we take the so that sounds like a great thing we're aiming for and hopefully Joe's gonna solve that problem with us for us but but um but uh well yeah weeks months whatever uh but the in the shorter term just for it with internal projects if you have more than one thing going at the same time is there anything you've done internally to help leverage that date picker you know let's um date pickers are used everywhere let's maybe use it in three different apps that are forward the same client is that well I've only I can't really answer I've only got one ember app at the moment right about in about six weeks time I'm gonna start my second one so maybe ask me then I've only on a couple of occasions about you needed to use a component and copy and paste a bit of my friend that's gonna be my solution as well they've really just been like little trivial things that I just needed to take from what to do yeah I've been found like that that source yeah of packaged components okay well so um I have no idea how this is going to work from a video standpoint but we are now over to you guys so anyone have a burning question when the components kind of came around did you do much upgrading side grading you know did you do my three factings that change your lots of views in the components or was that okay so the question was because I was working on a big app around time components came out did I do a lot of refactoring and was that painful so I kind of stopped working on that big app not too long after this happened and I believe that my colleagues did do that refactoring and I don't know if it was painful there was some rumbling but yeah yeah I mean I think I think that some of the D3 stuff specifically was moved over to components but I don't think it made a huge amount of practical difference just because I think we were kind of using views in the way that components are being used at the moment so we were using them by passing in all the values they weren't relying on you know plucking values out the the outside controller state so I don't think it made practically that much difference or was that hard but I might be wrong they might listen to this video and say it was really hard so I guess when so it's the idea of components that when wet components kind of standardize the machine with browsers you can just whip a switch and then you'll have your scoped css and everything you know so you can take the D3 to the graph component and put it anywhere in any but in any end the app it will look the same how can you say um so I mean I I don't think it will end up being that simple and I think that like you know by the time we get to the stage when web components are actually you know standardized and deployed in all of the browsers that we need to support even I don't know what apparently supports you know any IE's anymore um you know I think that by the time even that's in you know the the sensible browsers um it it's just you know almost all the apps we developed today are probably going to be in maintenance mode like that's just you know most apps don't last that long um and the API is going to be different like Polymer is designed to body fill the expected API and that will literally be flicking a switch um and embers components are explicitly designed to maintain a uh you know to have a stable API even though the underlying API will change so I don't really think that that's realistic unfortunately um but I still think it's a good development model to be using right now um I think it's helpful one of the questions good luck I think that's the only way you can say the ember's opinion and ember's opinions are all to obtain if you started from when it was three 1.0 things changed really quickly after 1.0 and then you stuck components is probably one of the more major changes recently and it's worth even if you don't get the material benefit from changing from helpers to components or confused to components if components is the opinion to do then you should probably think about about conforming to that what's the difficulty about that is with working with ember and backflip ember 3.0 and backflip for that was the opinions when you go and stack overflow whatever you know understanding what's the current state so what you're supposed to be doing how it's supposed to be built differs the backbone to name it because it's just a thousand different ways to do it because it's not really a framework and ember's the problem because the opinions changed from 1.0 to 1.0 so and if that's the that's what you're supposed to do then you should probably do it yeah and then hopefully become bigger like easy and of course you have your handiwork stuff to to two other developers for the clients then you know carefully so we my colleagues and I announced we stare at studio with a guy who works for crowdmark who i think that's the company an early ember adopter and he is basically doing the graphing work for their using d3 but what they ask of him is that he package up the stuff he builds as any components so he will he'll build something in pretty much trippy d3 knowing that things will be passed into it through this quite simple interface packs it up in a component kind of sends it across the ellantis so they can then deploy it and that's quite a quite exciting use of them i think so on that as well we had a talk from annie appleton go cartless i think it was in january really good talk well worth looking at on video and he talked about the way that they have modularized their their applications ui was an angular application and so they've got a a github organization full of all these requests all the different widgets they use as angular bundles or directives or lots of chunks of hgl template and not css that i don't think so that's that's like again even they're not quite there and then those all come in the power doc jason and that's how they install them so they end up with a stack of stuff in the pair of projects but even then they still depend upon the pair of projects having the css that knows how to style these directives that's what you're trying to do that's why i see the biggest difference between ember components and all the components is that the share of them is has a lot of access to that the scope css yeah actually sorry talk from the from uh i've got the guy's name but one of the polymer developers and they they've gone to how do you how do you explain it yeah really talk absolutely amazing at the London JS conference and they've doubled down on components to the point where if you want to make an ajax request you put an ajax tag xx ajax tag in your doc with the attributes found up to the stuff you want to request that's how to interact with the browser can give you so they've gone to the everything is a tag end of the spectrum like barely writing JavaScript itself okay we are going to get kicked out soon but i think if there's one burning question left we have time for it and then we're going to the bar we don't have to have a question but we can go right to the bar can i ask a question so it's on the role of controllers so in ember outside of components you've got your templates your views your controllers and your models and your controller layer is this sort of decorator layer that you mentioned now as more and more people's apps are moving to components and when you're in a component you've got the data that's passed in you've got the component instance and you've got the template and you don't have that controller layer like that decorator layer like do people think that that's something that's missing or are they are they fine with that do they think that that's just some extra bulk on the ember side of things that isn't isn't necessarily there just seems that in the inside of components and outside of components you've got two slightly different breakdowns of where the responsibilities are yeah i mean it might be interesting to note the way as an implementation detail the components actually have a controller property which is set to the component itself so the component object acts both as the view and the controller does that mean i mean what that might mean is that you end up with like if you had a really complex component you end up with all your event handling code abstracting of the DOM along with all your presentation code like to wash it into a file and you know i think that you can handle that relatively easily with traditional OO techniques so you can either use composition and have an object that manages your presentation or you know a certain part of your functionality or you could use mix-ins kind of like concerns an active record where like you divide up your functionality into separate classes and separate files but they end up with solutions to the same object but i think i think you're right there is there is a difference between inside component to outside components and it may you know i suspect that if components get really complex if there's a lot of really complex components it may become necessary to to kind of add that back in but again that's kind of differing from the work components spec as that's currently proposed so i don't know if that's something that we would consider you know i think you can manage these code complexity problems without that but yeah it's an interesting question as things get more complex if that's rises an issue or not okay i'll speak to myself i thought this was great you guys were awesome can we give a big hand for the three of us