 Hi, my name is Gonzalo and welcome to my talk, Birds Eye View of Ember. A bit about me before we start. I'm a computer engineer in London. I'm one of the organizers of Code Bar London, where we run free programming workshops for minority groups in tech. I work at CrowdStrike, and while I've been working with Ember.js for the past half year, before I spent five years working with Vue.js, this talk is about these six months that I've been trying to map my view knowledge into Ember. First things first, what does this talk about? Basically, I want you to know that if you already know Vue, you basically already know Ember as well. I want this talk to be a brief but useful reference for Vue developers new to Ember. I'll be focusing on Ember, Octane and Vue 3, since they are the most recent embodiments of each framework. What does this talk not about that's equally important? This is not about setting frameworks against each other. It's not about the technical details or differences. It's not about favorites, and it's also not going to be an extensive presentation. I'm going to focus on useful and popular Vue features. I want to start with these two diagrams. The first one comes from a presentation from Evan Yew, Vue's creator, and the second one comes from Ember documentation. I find them useful to describe the ethos of each framework. Vue is designed to be incrementally adoptable, where the code is focused on the Vue layer only, Ember, on the other hand, labels itself as a battle-tested JavaScript framework for building modern web applications. Most of the features you would need to build rich, single-page applications are already built into the framework. This difference in philosophy will run deep through the mappings that I'll be doing throughout this presentation. Let's start with our common line interfaces, or CLIs. These are tools you run in a terminal and allow you to create projects, add extensions, etc. Vue CLI is official but entirely optional, in line with its philosophy. You adopt it if it adds something to your use case. Ember CLI is a bit more ubiquitous. Used by pretty much the whole community. You create your project with it, you can scaffold every piece of your application with it, and you also use it to install, add-ons, run tests, and serve your application. Next up we have components, your building blocks in both frameworks. On the Vue site, the component itself is highlighted in bold. We're registering it on our app with a name, an internal state with a data function, and a template defined as a string. The rest of the lines are basically a Vue application that we are creating and setting an instance of this button as our template. On the Ember site, we have the same component split between files 1 and 2. One is a template in a handlebars file, and two is the JavaScript counterpart of it. File 3 is how we would use that component on a page template, for example. Note that if you don't need JavaScript for a particular component, like functional components in Vue, you don't need to create the JS file. On the previous slide, I talked about Ember CLI Generator. The Ember Generate command that you see allows you to create new components with the corresponding handlebars and JavaScript file in its component test, even. If you're coming from Vue background, you're probably a big fan of single file components where you define the template, behavior, and styling of your components in a single file. Unfortunately, there's no such thing in Ember, at least for now. However, there are some initiatives and projects exploring similar concepts. This one over here is just one example provided through a package called Ember template import. Now that we have components, how do we pass data into them? In Vue, they are called props, and you have to explicitly declare them by setting an API, as you can see in file one. On file two, you see how it would use them. Notice the script tag where you have to explicitly import and declare your component. Component imports are explicit in Vue. On the Ember side, props are called arguments and are passed with the act symbol. You don't explicitly declare them, so coming from Vue, this was something that I had to get used to. However, with the advent of TypeScript, you can define your arguments with the type or interface, and the language will do the checking for you for example. Now that we have components and we're passing data into them, how about tracking state and reacting to changes? Here we have a single file component in Vue with a starting state called defined by data, a computed property that reacts to any of their dis properties change, and a watch that looks into a reactive property and gets triggered whenever its object changes. This is where I struggle the most coming into Ember, kind of moving from an explicit declaration of what I want to a more vanilla JavaScript looking way of writing things. I do believe that this is simpler than Vue now that I was able to follow a more Ember-like approach. The way I see it is you set your reactive data with tract. Your computed from Vue becomes regular JavaScript getters that automatically react to changes in Ember as much as possible. One of the guidelines in Ember is data down actions up where you pass arguments to communicate down the tree and you trigger actions upwards. However, when you use observers you are breaking this paradigm using data to trigger changes instead of actions, which usually leads to issues. Let's briefly look at native events like click or focus. In Vue you set them as V on event name or at event name and action or call a method from your component. In Ember this is pretty similar you rely on the on modifier however you can't inline JavaScript as your action. You need to stick to handlebar helpers or actions from your components which are JavaScript functions as you can see from that handle click. Custom events deserve mention as well since this is how Vue components usually communicate with their parents. On file one you can see a custom button where when it is clicked an event of our own choosing called custom click is being emitted. You can see on file two how to intercept it to trigger an event to trigger a method on the component listening to this custom event. In Ember going back to data down actions up paradigm you can see on files one and two our own custom button reacting to a click but instead of sending a message upwards it's calling instead a function it receives as an argument. This is how you leverage parent child communication in Ember. A quick stop on Vue's custom directives which are a neat way to encapsulate DOM low level access into reusable helpers that enhance developer experience. You can do a similar thing in Ember with certain helpers like did insert for example but you can get a perfect match with Vue by installing Ember modifier as you can see from the code. You can almost match Vue's code line by line and added to any element you want pretty much the same way. Besides passing data to feed components we might actually have components that just wrap around other large components or complex information. For these cases Vue has slots. File one is our component defining a slot area where content will be injected. File two shows how to use that component. Notice how it wraps around the string add to do. In Ember these are called blocks and with a similar fashion although notice again how we had to explicitly import and declare our component in Vue but that happens automatically in Ember. File one is our component and file two shows how to use it. In both cases the resulting HTML will be the same as you can see on that red box. When you want something more complicated than a button like a modal a component that would need different areas of content like a header a content and a footer you can use named slots or named blocks. This is how Vue makes it happen. You still use the slot keyword but you name them so they all end up in the right place. In Ember I believe starting from version 3.25 upwards this is available as well. The syntax is a bit more compact but it's similar to Vue. You use yields instead of slots you name them accordingly to the block and voila. As your application gets bigger and more complex you need to start sharing state between several places of your app. In Vue it's very common to bring in Vuex. You define a store or multiple stores you define their starting date you define getters and setters where mutations and you inject that store into your application for your components to use. Besides this Vue 3 brings a new dependency injection mechanism where you provide the data you want from the top of your hierarchy and then you inject it explicitly on each component that needs it. In Ember I would say there are two main ways of sharing state across your application. First off servicers are an important tool that you have at your disposal in Ember. They are singletons which mean they live throughout the lifespan of your session allowing them to keep state if you want and you can inject them into any component by their name. Secondly Ember data for example provides you with a very popular object relational mapping or ORM where you can keep your state in models you might want to persist in a database like a shopping cart for example. If you're building a single page application with different pages having some kind of routing is pivotal. Vue router is the official package review and you can see on the left a Vue application with a functioning router. Everything is based on components so you declare your top level components in this case basic template is enough. You map each top level component to a root. You create a router with the roots you created and you create a Vue application that we use that router. Notice that the apps template and the router link that's where the page component will be inserted. Ember follows a similar pattern that splits it differently. You define your roots in the root app router. You use the link to element to navigate them and your actually pages will be usually folders under the app folder that correspond to the roots you defined previously and that will contain a template handlebars file. If you remember this diagram I showed at the beginning this is one of the main design principles in Ember that I had to get used to. Everything stems from the root. It is responsible for initiating the full loading of a model, page template and corresponding components. Going back to global state we've introduced roots. We can talk about where to get your data from and where to keep it. Vue provides no official guidelines on this encouraging you to use whatever you want. If you need something like weight, you'll probably just using Vuex stores and some plain old javascript objects, bojos. If you need more than that you might be using some GraphQL client or some other ORM package. In Ember Ember data is the default approach for the community. You can use it as a front layer for several different data layers like Firebase, Orbit and it's a feature reach ORM. Ember Apollo is another alternative for GraphQL if that's your case. If you only need to use a few pojos though, remember that services are singletons and they can keep that data for you. About testing Vue again provides loose official guidance. There's a few official packages like Vue testutils and Vue testing library but they only provide you unit tests and component tests. More than that, there are other services and packages that you can bring in. Ember on the other hand it ships with generators that create tests for you and you can create tests for models, components controllers, whatever pretty much every piece that you put into an Ember application. Finally, I want to leave you with one of my favorite features from Vue transitions. The cool thing about it is this transition tag that you can use to wrap elements that will come in or out of the DOM. You can give it the name of a transition and whenever the wrapping element shows up or disappears Vue will automatically apply certain CSS classes based on that transition name. In simple terms you define your transitions in plain CSS, you set them with the correct selectors and Vue does the heavy lifting for you. When you want to use that in several elements of your transition group instead. This is one of the few things that Ember doesn't have built in here but they are powerful add-ons that you can bring the same functionality. I'm just going to highlight two here. Ember CSS transitions allow you to port your exact transitions, your exact Vue transitions as they are keeping the exact same CSS and replacing the transition tag with the CSS transition helper. Second, you have Ember Animated which provides you with a rich set of helpers and imports to articulate powerful animations even between different pages. This gift for example is from Edward Faulkner's talk of 2018. Finally I want to provide you with a few links where you can read more about this. Ember Atlas is a great resource. They even have a specific page for Vue developers. Ember Observers to track add-ons and popular packages for Ember and then you can reach out to the community on Twitter and especially Discord. Thank you so much for this talk. I hope you had a good time.