This course has been updated! We now recommend you take the Ember Octane Fundamentals course.
Transcript from the "Philosophy of Ember" Lesson
[00:00:00]
>> [MUSIC]
[00:00:04]
>> Mike North: Without further ado, let's jump in. So, Ember's designed for ambitious apps. If you go to their website, you'll see this is their tagline. And I wanna elaborate on what that means. And part of understanding that is understanding where Ember came from. So one of the first two commits to the framework was the source code of another framework.
[00:00:26] And that is SproutCore 2.0. SproutCore was built at Apple, and later spun off into another company. But it's what Apple used for MobileMe and iCloud. And, in fact, if you go to icloud.com today, and look at the source code, you will see it is still SproutCore 2.0. And one thing that's notable about these applications if you look at them, it's a very, very rich experience, and there's a lot of functionality there.
[00:00:53] It's a lot of complexity to manage. And it's important to understand that these are Ember's roots, and as a result, you're not gonna find that your app is becoming too complex for Ember to handle. It's designed to make managing complexity easy. The abstractions that you deal with in the Hello World app, the patterns you follow, will scale up as your app gets bigger, as you add more to it, as more users start coming in, as you have to customize it more.
[00:01:25] Everything holds up because it was designed for the complicated case, and then we make sure that the simple case is not too difficult. And when picking a framework, at least from my point of view, I care about that. I would rather build something that is optimized for where I'm going than optimized for how I'm starting out in the very beginning, because ultimately that's where you are going to hit problems.
[00:01:51] That's where snags are going to start biting you. So Ember's also focused on productivity. All of these framework communities in it. Anyone who's building a library or a piece of software of any kind, you have to pick what your most important goals are. And in the case of Ember, it's not something like performance or making it as light weight as possible.
[00:02:16] The focus is on making sure that developers can get off the ground and move fast and leverage other people's code effectively. If you want to think about other web technologies that have a similar alignment, Rails. Very similar alignment. And the idea is developers are expensive. Leverage their time more effectively and you're gonna have a good experience.
[00:02:46] Another aspect of Ember's focus on productivity is its convention over configuration nature. And what this means is if you've worked on one Ember app you can shift and take a look at someone else's code in their app. And within a couple minutes, you're gonna know where everything is, how to diagnose a problem.
[00:03:08] The structure's very much the same, the idioms are the same. As opposed to if you use a stitched together jQuery and Flatiron Director, and picking micro libraries and assembling them together. Everything is custom. You may be used to Grunt and they're using Gulp and you may not know how their deployment process works and it takes a while to get spun up.
[00:03:33] The idea here is everyone should be on the same page. Let's not make those individual little decisions on a per app basis. Let's reduce the number of decisions and make the task of building an app simple without sacrificing capability. And so you sort of have patterns and you have a happy path that you can go down.
[00:03:56] And if you can stay aligned with the happy path, you have to write way less code and things kind of just work out of the box. So Ember's also aligned with web standards. Why is this important? So we're writing rich applications for what essentially is still a document viewer.
[00:04:20] That's what the browser is. That's our programming environment. And if you compare that to writing an app for iOS or Android as a platform, the primitives we have to work with are divs and functions and objects. They're not map widget and navbar and icon. We use frameworks to bridge that gap to give ourselves a reasonable platform to build on top of.
[00:04:46] And at the same time, the browser's getting better. New JavaScript language features were officially adopted as the new language standard this year. The browser's getting better. The language is getting better. And the hope is that if we look at these frameworks as shims, you wanna have alignment with these web standards.
[00:05:06] So eventually, as native promises become way more performant than native JavaScript promise libraries, you want to take out that part of the shim, and then rest neatly on the native functionality, and everything should just work. You don't want to have to rethink everything. So that's why it's important to me.
[00:05:27] In addition, it helps interoperability between different apps. So if we're all on board with, this is the way a promise works, that a library that has to use promises can be used in Angular and Ember and React and wherever you need to use it, because we've adopted this singular idea of how this problem should be solved.
[00:05:52] Ember aims to be a complete solution, and I will compare Ember to a library like React. So React is a great view layer, it's great for keeping data and DOM in sync. But if you look at ten different React apps at random, they are all very different. They all may have different build pipelines, they may have their code structured differently.
[00:06:19] And as a result, you have to have a lot of knowledge of how everything fits together. It's the developer's job to make sure they take this island of excellence that Facebook has created, and get a complete cohesive single page app setup working. And the idea with Ember is that we focus on not only the framework itself, not only the library that you use to persist data to an API and to read data from the API.
[00:06:48] But the build tools, even the process of deploying, we wanna have a good story around that, so that this happy path is a comprehensive happy path. From how you write your code to which transpiler you're using, to how things are minified, and even now, deployment and animation. These all have an advised approach, and as a result you can rely on things working together very nicely out of the box.
[00:07:21] And this is a big problem to solve, this is a huge problem. And you're gonna see today that even as we start touching on these areas and going deep, there's so much to know, and there are things we're gonna not cover them, because you can't do it in two days, or four days, or six days.
[00:07:38] But it's a big problem to solve, and the framework is a moving target. It keeps growing, it keeps improving, every six weeks there's a new release. And usually they're a significant performance improvement, or new features coming out. The list of things we want to do to the framework is steadily outpacing the ability to get them done.
[00:08:03] And this is a good thing. This means that there is adoption, and that there are new use cases being brought to our attention. And so it's constantly growing and improving, and you just need to be aware of that because I don't think Ember's going to be done at any point in the near future.
[00:08:22] It's gonna keep trying to solve the problem better and evolving to meet today's needs and tomorrow's.