Choosing a JavaScript Framework
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51706 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 20169 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Computer configurationSoftware frameworkTrigonometric functionsArtistic renderingView (database)Library (computing)Software frameworkCategory of beingSystem callCentralizer and normalizerConnectivity (graph theory)Type theorySoftwareNumberSoftware developerRevision controlOrder (biology)QuicksortGoodness of fitExtension (kinesiology)Pairwise comparisonDifferent (Kate Ryan album)Perfect groupAxiom of choiceInformationTemplate (C++)Cartesian coordinate systemProjective planeCollaborationismTerm (mathematics)Control flow1 (number)Process (computing)CodeElectric generatorBitFront and back endsMilitary baseCore dumpNatural numberDecision theoryMobile appEndliche ModelltheoriePoint (geometry)Latent heatContext awarenessComputer configurationCombinational logicView (database)Source codeExterior algebraException handlingInformation technology consultingServer (computing)SequelArithmetic meanGroup actionMultiplication signVideo gameDemo (music)AngleShape (magazine)Basis <Mathematik>Web 2.0Flash memoryWindowComputing platformVariety (linguistics)Degree (graph theory)Scripting languageProduct (business)Set (mathematics)UML
08:06
CuboidLimit (category theory)FreewareDemo (music)Revision controlMultiplication signSoftware frameworkMathematicsPoint (geometry)BuildingResultantEndliche ModelltheorieCodeText editorWeb 2.0Ring (mathematics)Right angleCross-platformComputer animation
09:18
Game theoryGame controlleroutputWechselseitige InformationContent (media)Error messageMereologyMaizeElement (mathematics)Connectivity (graph theory)BitTemplate (C++)Latent heatWeb pageWeb 2.0Mobile appResultantKeyboard shortcutFormal languageMathematicsDifferent (Kate Ryan album)Function (mathematics)Visualization (computer graphics)Game controllerCodeModulare ProgrammierungInitial value problemConstructor (object-oriented programming)Computer clusterContrast (vision)Attribute grammarDemo (music)Materialization (paranormal)Social classCategory of beingSubject indexingFunctional (mathematics)Scripting languageRight angleView (database)MereologyoutputDifferential (mechanical device)Computer fileProduct (business)Revision controlType theoryBootingTerm (mathematics)Poisson-KlammerCASE <Informatik>ParsingOrder (biology)Standard deviationSymbol tablePhysical systemOptical disc driveDirection (geometry)Uniform resource locatorEndliche ModelltheorieAxiom of choiceSoftware frameworkSimilarity (geometry)Point (geometry)String (computer science)Electric generatorConfiguration spaceModule (mathematics)Uniqueness quantificationForm (programming)2 (number)InterpolationBootstrap aggregatingInterpreter (computing)Run time (program lifecycle phase)Real numberVideo gameSineLine (geometry)Modal logicDiscrete element methodNeuroinformatikGastropod shellProfil (magazine)Data miningLetterpress printingRow (database)QuicksortSource code
18:45
Very long instruction wordoutputRouter (computing)RootMaizeStatisticsEvent horizonCategory of beingExtension (kinesiology)Pattern languageMobile appCASE <Informatik>Endliche ModelltheorieCartesian coordinate systemState of matterConnectivity (graph theory)Local ringProcess (computing)Different (Kate Ryan album)CuboidOnline helpPoint (geometry)MathematicsSpectrum (functional analysis)BitElement (mathematics)CodeScripting languageJava appletEvent horizonSubject indexingType theoryLink (knot theory)Similarity (geometry)Direction (geometry)Optical disc driveoutputSampling (statistics)Template (C++)Product (business)Web 2.0Natural numberView (database)InformationRoutingSlide ruleReverse engineeringDoubling the cubeKeyboard shortcutInterpreter (computing)Game controllerFormal languageGeneric programmingRouter (computing)Programming paradigmInstance (computer science)Data storage deviceRevision controlQuicksortSoftware frameworkGreatest elementMaxima and minimaDataflowSpeech synthesisOrientation (vector space)Social classPlanningString (computer science)Multiplication signMereologyProjective planeSign (mathematics)Order (biology)Cycle (graph theory)Functional (mathematics)Video gameVolumenvisualisierungLine (geometry)NeuroinformatikComputer fileModule (mathematics)Equivalence relationFocus (optics)InterpolationInitial value problemMatching (graph theory)Attribute grammarDivision (mathematics)Computer animation
28:12
BenchmarkStatisticsSoftware frameworkLibrary (computing)Presentation of a groupMaizeCore dumpPartial derivativeFacebookPattern recognitionInformation technology consultingCore dumpTemplate (C++)Projective planeFacebookSocial classLibrary (computing)Direction (geometry)Demo (music)Pairwise comparisonConnectivity (graph theory)CASE <Informatik>CodeLine (geometry)Pattern languageCombinational logicFlow separationRevision controlTime zoneComputer fileComputing platformSoftware developerStandard deviationQuicksortParallel portMobile appMixed realityMultiplicationComputer programmingRouter (computing)Physical systemDependent and independent variablesEndliche ModelltheorieField (computer science)Focus (optics)Game controllerAxiom of choiceMereologyNetwork topologyWeb 2.0Goodness of fitView (database)Visualization (computer graphics)Process (computing)BenchmarkOrder (biology)Web browserVirtual machineMechanism designFeedbackProduct (business)Software frameworkGreen's functionFormal languageStability theorySet (mathematics)Decision theoryEvent horizonClosed setReal numberPattern recognitionBitDifferent (Kate Ryan album)Group actionNumber1 (number)Open setSoftware bugTelecommunicationPlanningMaterialization (paranormal)Wave packetInformation technology consultingTerm (mathematics)Point (geometry)Open sourceSource codeSoftware design patternBuildingGraphical user interfaceTotal S.A.Multiplication signCorrespondence (mathematics)Flash memoryPresentation of a groupPerspective (visual)FrictionImplementationEntire function2 (number)Electronic mailing listPlug-in (computing)RamificationReading (process)Greatest elementWebsiteInformationArithmetic meanSlide ruleElement (mathematics)VirtualizationMetropolitan area networkThread (computing)MathematicsContext awarenessBasis <Mathematik>Functional (mathematics)Acoustic shadowCodeOptical disc driveParsingCategory of beingAreaFilm editingCollaborationismBeta functionModule (mathematics)Alpha (investment)outputScripting languageRepresentation (politics)Sound effectSoftware maintenanceDemosceneJava appletDampingSemiconductor memoryGoogolRight angleArtistic renderingElectronic program guideArmTouchscreenExtension (kinesiology)VideoconferencingDisk read-and-write headCycle (graph theory)Sampling (statistics)SineFluxParsingForcing (mathematics)Maxima and minimaState of matterProgramming paradigmSemantic WebLogic gateFamilyConfiguration spaceCompilation albumMonster groupWordInclusion mapCausalityArithmetic progressionClient (computing)InjektivitätComputer clusterSystem callFrequencyService (economics)Computer animation
Transcript: English(auto-generated)
00:05
Good afternoon. How's everyone doing today? Enjoying the conference? Great. Well, thank you for coming. This talk is obviously titled Choosing a JavaScript Framework, a Look at Six Popular Options.
00:23
My name is Rob Eisenberg. I have a pretty extensive history in front-end frameworks across a variety of platforms, including Windows, Unity 3, Flash, Flex, Silverlight, and the web. A bit more about my history. I actually worked on Angular 2 as a core team member and
00:43
also on Angular Material Design Project as developers on both and also a designer on Angular 2. Long story short, I left that project due to various differences and began working on a new alternative to
01:02
Angular 2.0 called Irelia, of which I am the lead architect. Now, what are we going to be talking about in this talk? Well, we're going to look at six frameworks, very simple examples of each frameworks. Because we don't have a lot of time, we can't go very
01:20
in-depth technically with each framework. So we're going to look at a very simple Hello World type app, but we're going to look at six versions of it, one with each of our major frameworks. So you'll get a feel for the development methodology and the philosophy behind each of those different approaches. Then we're going to do a comparison, a technical
01:41
comparison, a comparison on project and team and community and collaboration and business and a whole bunch of different aspects of these projects, many of which you may not have looked at before. And then we'll conclude the talk very briefly with my own recommendation to you in terms of how to approach these frameworks and which to use.
02:01
And I'll break that down into three categories, the yes, the maybe, and the no. Now, having said all that, I want to make two quick points before we really get deep into this here. The first one is I want you to keep in mind my obvious bias. Clearly, I worked on the Angular 2.0 team and left a
02:23
high-paying, very visible job to create an alternative framework to Angular 2.0. So obviously, I'm biased against Angular and for my own product, Aurelia. You know that. I'm exposing that bias to you ahead of time. So you just keep that in mind as we
02:40
proceed through this talk. Especially if I happen to get on my soapbox and go off. Number two is another call to action for you, not only now during this talk, but going forward in your careers. And that's really a call for us all to be professionals. As software developers, we're just as susceptible as anyone
03:02
else in the world to get wrapped up in hype, to be swayed by marketing and branding and logos and all these sorts of things that work on our emotions and our insecurities and all these sorts of things. As professional developers and architects and team leads and CTOs, our job is to really understand
03:22
the business first. We need to understand what are the business needs. What is the real problem we're trying to solve? Understand our team, our company culture. And then with all these things as a context, then we want our technological solutions to fall out of that naturally. And in fact, when we do understand these things, it
03:42
makes it much easier to make technology decisions. So often, we start a new project, and before thinking about all that, we say, well, I'm going to use MS SQL Server, .NET, and Angular. But we haven't even identified the problem yet. We haven't even thought about what the app is that we're going to build. So I think this is just a general call.
04:03
As a consultant, I work with a lot of companies, and this is kind of a systemic problem, I think, in our industry. We need to think about the businesses that we're working for. Think about our teams. Think about our corporate culture. Think about the real problems that we're trying to solve. And then in light of that, we choose the technologies that
04:20
fit best for that particular context. So keep that all in mind, and let's move forward. So what do we want to talk about? What frameworks? Well, we're going to be comparing six frameworks. AngularJS, 1.x. This is a framework, obviously, that a lot of
04:40
people are very familiar with. So this is going to provide a foundation, I think, a lot of common understanding for people in a frame of reference. We're going to talk about Angular 2.0. We're going to talk about Aurelia, Ember, Polymer, and React. I've done my best to, I'm trying to be non-biased, if I can help it. So the frameworks will be appearing in alphabetical order
05:05
wherever you see them, unless I'm explicitly ranking on a particular feature. And with that in mind, please don't get angry at me if I call your baby ugly. There's no perfect framework except for Aurelia. And so obviously, there's criticisms to be made of
05:24
everything. So please don't take it personally. Hopefully, this will all be edifying for you. You want to take this information, and it's now resources that you have to help you make choices in the future. Whether you agree with my own opinions or not, I hope that there's a lot of information in this talk. Now, the next thing I want to say about these six
05:42
frameworks is that they're not really all of the same sort. In fact, they're not all frameworks. The first thing I want to point out is that AngularJS is what you would call an all-in-one framework. It doesn't just do, say, templating and binding, but it also has routing and HTTP and animation and a bunch of things. When you use AngularJS, you get kind of a whole package deal.
06:01
So that's a particular category of framework. The other thing that's important to know about AngularJS is it's pretty much deprecated. There's literally a fixed number of months left on the lifetime of that framework. I'm pretty much including it in this talk, not so much because I'm going to recommend it to you. In fact, I'm showing my hand a little bit. I'm obviously not going to recommend AngularJS 1 because of this one fact that it's deprecated.
06:21
And so that's not to say that you're in big trouble if you have an existing AngularJS code base. But it's probably to say that you shouldn't start a new project in AngularJS right now. And you should be thinking about how you might migrate in the existing code bases. So this is in a little bit different category because it has a fixed number of months left on it of life, and then it's kind of gone.
06:42
But this is going to be a good frame of reference for us as well. The next set, Angular 2, Aurelia Ember, and Polymer, are also all-in-one frameworks that provide pretty much all the pieces you would need to build an application. And they're more modern. These are ones that are using modern JavaScript.
07:00
They're using the modern DOM and more modern techniques, as opposed to AngularJS, which is more of a previous generation framework. So these are ones that are all-in-one and then modern at the same time. And then finally, React is a little bit different because it's not a framework per se. It's more of a view rendering engine or a component model.
07:20
So it does that one concern specifically. And typically, when you use React, you're going to use it in combination with a host of other third-party libraries. And you're going to sort of build your own framework with React being a central component of that. So keep that in mind. Not all these things are really the same shape, if you will, as we proceed. And I'll try and call that out as we progress.
07:43
All right. So from here, I want to just get straight into some demos. I'm going to show you the same exact app, six versions of it. I'm going to run it once because they all look the same, so we don't need to keep running it to prove that it works. But we'll look at the source code of all six versions. And then you'll hopefully get a feel for the different approaches that these libraries and
08:02
frameworks take. OK. So with that, I'm going to jump into the demo, which I've got running in Firefox. This is the AngularJS version, actually. And this is a really super simple demo. I mean, this is just about as simple as we could get, because we only have a limited amount of time.
08:20
But the demo basically just has three labels, first name, last name, and full name, and two text box, one for the first name, one for the last name, and then a computed full name that is the result of bringing together the first name and the last name. And as I type in one, the full name, of
08:41
course, updates below. So it's pretty simple and straightforward. And that's how it works. That's the whole demo. I know it's not terribly impressive, but the point is that we're going to look at the different approaches. Because even in a simple demo like this, across the frameworks, you can see some extremely different approaches
09:03
to how to build something like this. All right, so hopefully you have that in mind, a couple of labels, a couple of text box, some auto-updating stuff based off of changes in those text box. So let's see how this is put together across our different frameworks. So I'm going to bring up Visual Studio Code here, an
09:21
excellent new cross-platform editor, interestingly enough, written with web technology itself. So if you haven't checked out this editor, I'd definitely recommend it. We're going to start with the AngularJS 1.x demo. Now, with each demo, we're going to start kind of in the index HTML file.
09:40
It's a nice, good starting point for us. So with Angular, you would reference, typically, the script file for Angular and then the script files for your app, however you built those. And then you would declare templates. And those templates would be controlled by a controller. So you can see that Angular 1 uses something called directives. And here's the directives and controllers.
10:03
And in this case, we're declaring a controller called ng-controller. That's pointing to a person controller, which I'll show you in just a minute, in the JavaScript file. And it's being named, basically, as person controller. This uses the controller as syntax from Angular. Now, I realize with Angular 1, there are a bunch of different ways to do the same thing.
10:21
So if you're a big Angular user and you don't see the approach that you like here, just be cool, all right? So this is using the controller as syntax. And let's look at that controller. Let's actually jump into AppJS. Now, you can see from the get-go, this is a little bit of a throwback to what I would call the previous generation of frameworks. So we're using a specific API that's Angular-specific for
10:43
declaring modules rather than ES2015 modules, because this dates to before the standard. So you see that we're declaring this app module. And then we're calling an API to declare a controller. We're giving a name of person controller. And then we supply a function to that, which effectively becomes like a constructor function for
11:01
that person controller. And so we set up the first name, the last name, and a function called getFullName that calculates the full name from those two other properties. So pretty simple, pretty straightforward. But if you looked at modern frameworks, you can see how this is a little bit dated now, not using ES2015 modules. It's using something that's kind of like a constructor, but
11:22
it's not using classes. There's a lot of strings happening here. So you can kind of see those sort of previous generation techniques. But what happens in the index is we bring in that person controller that's identified there, and it's named. And then we can reference the properties on it, first name, last name. And there's that getFullName method. And in Angular 1, there's an ngModel attribute which handles
11:43
two-way data binding. And so what we can say is, let's connect the input's value basically through this model directive to the first name of the person controller. And the same thing for the last name. And then let's just output in line, using this double curly syntax, the result of getFullName. So this is called an interpolation.
12:02
And you'll see this throughout a lot of the frameworks, these double curlies. And that's going to output the result of that function right there. And you saw in the demo how this just works. As I type in the first name, it updates the full name below. As I type in the last name, it updates the full name below. And that ngModel is pushing the data in two directions. It's pulling it from our initial values in the model,
12:23
or in the controller in this case. And then it's also pushing it back there as the input changes it. So this is AngularJS 1. Again, it's a simple app, but you can kind of see the approaches. And you can see how it's maybe looking a little bit old, but it's actually still quite simple, and it works. So that's Angular 1. Let's contrast that with Angular 2.
12:42
I think that's a reasonable follow-up to Angular 1. And it's mostly alphabetical, right? So in Angular 2, things are a little bit different. We've shifted over to using modern JavaScript. And in particular with Angular 2, it really focuses on TypeScript. It's not that you can't use JavaScript with Angular 2, but it is much more difficult to use plain JavaScript. So most people are going to be pushed down the TypeScript
13:03
road, necessarily, with Angular 2. We're going to start by looking in the index. And first off, this is based off of some of their tutorial materials for getting set up. So they have a lot of scripts that you need to include. In a real production app, it would probably look a little bit different than that. You'd be doing some bundling and some concatenating and all that kind of stuff.
13:22
You also need to configure the module loader. Because we're working in a truly modular system now, with ES2015 modules, you need a module loader to load those modules. And so this is just code that you see right down here that is just configuring the module loader. This stuff right here, even though it looks a little bit more complicated, this is very common across the
13:41
modern frameworks. So don't take that as an idiosyncrasy necessary of Angular 2. You'll see it in a bunch of other places as well. And then in the body, we simply have a MyApp custom element. And now let's look and see a bit how that kind of brings the app to life. And you can see it's importing this app main through the module system down here.
14:01
So let's go ahead and let's look at app main. Now app main, we're going to be looking at TypeScript, is the way that, in this case, that you bootstrap Angular 2. So here we're just bringing in the Angular 2's bootstrapper. And we're bringing in this app component, which I'll show you in a minute. And then we're just telling the framework, or Angular 2, please bootstrap the page with this app component.
14:22
So let's look at app component. Again, you can see the TypeScript here and the import syntax. So we're bringing in the component decorator from Angular 2. Decorators are something that are part of a future spec for JavaScript. And they're also implemented today in TypeScript.
14:41
And the decorator decorates the app component class. So you can see the app component class is declared down there with two properties, first name and last name, and you can see the full name computed property. And this right here looks a lot nicer than the Angular version in terms of standards compliance, because now we're looking at a pretty normal class.
15:00
The difference you can see here is that there's this Angular 2 still requires the same kind of configuration that Angular 1 did. That didn't go away. It just kind of changed form. So in Angular 1, you would call APIs to declare a controller and to declare a module and do all this kind of stuff. In Angular 2, you still use their APIs to declare this stuff, only it looks a little bit different.
15:21
So it looks like a decorator. So here we're just declaring that this class is, in fact, a component. The CSS selector that's going to control what element this component applies to is the my-app selector. And then we're providing the template for this component.
15:41
And in this case, it's done inline through a template string, it can also be done through a URL. But this is, again, an example that they show a lot in the docs. Now you can see, looking at a template, how the syntax has changed. Let's look at the similarities first with Angular 1. The double curl is still the primary way to do the string interpolation. But you can see that now we're using getters instead of
16:04
functions, which is kind of nice. That's just the benefit of using the new class syntax for getters. And you can see how ngModel has changed. Now, instead of it being ngDashModel, we see lowercase ngCapitalModel, and then we see brackets and parentheses in here. And the brackets and parentheses designate two-way
16:23
data binding. The brackets indicate one directional from the model, and the parentheses indicate one directional from the view. So combine them together, and you get two directional data binding. I think there's something that's worth noting here. The symbols are a little bit odd.
16:40
That is technically HTML spec compliant, though it is a bit odd, but the thing that is not expected is the capital casing of the model. If you know anything about HTML spec, you know that HTML is case insensitive. So this is really an important note of differentiation here with Angular 2, where they're deviated just a little bit
17:00
by using mixed casing and some of their attribute names. And so the Angular 2 runtime, of course, does support this, but it needs to implement its own HTML parser which preserves casing in order to do that. So some of the use cases actually that were supported by Angular 1 are not supported by Angular 2 because of some of the design choices that were made
17:21
around how HTML is handled. So you might not have noticed that if I didn't point it out, but these are some details I just want you to see because they are kind of important. All right, so that's Angular 2. Let's move on to looking at the best framework. No, Irelia. And it starts out in a similar way.
17:41
It brings in a module loader, and then it imports something as well. In this case, it imports the Irelia bootstrapper, which is responsible for starting up Irelia. And Irelia is very convention-based, so you'll see that, in fact, the component is just a plain class with no configuration whatsoever. And this is a bit unique in this sense because there's no
18:03
framework there. So you just write a plain class, and you can see it's got the same properties and the same getter, and that's all there is to it. And then in the view, you have app.html, and this is the first example we're seeing of a framework that's beginning to use web component technology. So here you see HTML template element being used to
18:21
declare views, and that is from the HTML web component specification actually backported into HTML5. And so you can see that Irelia uses web components to do templates, and you can see that its data binding language is a bit different. It simply allows you to take any HTML attribute and append dot bind to data bind that attribute.
18:41
So here we're two-way binding the values of each of those. And then we're using a slightly different syntax for string interpolation in the full name. This syntax, if you know ES2015, is actually borrowed from modern JavaScript. It also uses the dollar sign curly syntax for string templates or string interpolation in JavaScript. So that's been borrowed in Irelia.
19:01
And that's the whole of the Irelia sample, just a plain class and a template with dot bind on a couple attributes. From there, let's move into Ember, and you're going to see the first framework that really takes a big difference, I think, between Angular 1 and Angular 2.
19:20
There's some similarities between Angular 2 and Irelia. We're going to look at Ember, and you're going to see some similarities between Ember and Irelia. But you're also going to see how Ember takes a bit of a different approach. With Ember, it also uses a lot of conventions like Irelia. Those are the two frameworks that try and maximize productivity through conventions. But Ember is a very strict MVC model.
19:40
So when we look at their code, you're going to see the model, the view, and the controller all very explicitly. And in fact, I don't think you can sort of get away from that. But a lot of people do like that. So first, again, looking in the index, we brought in some script tags. You can see that here, we've got a script tag in the body for declaring our template with a special type.
20:01
Notice the data template name equals index. That's going to be important in just a minute when I show you the JavaScript code. You can see the templating syntax also a little bit different. Still, it's completely spec-compliant HTML. But Handlebars has some nice helper methods for generating tags. So you can see that that input helper is generating an input tag there.
20:20
And it's setting the binding up on first name and last name for you. And then you can see the double curly syntax below, just binding the model's full name. Now let's look in AppJS. And here's where you're going to see the model view in the controller. First, at the top, we're creating an Ember application with ember-application-create. Then we essentially define our model from
20:41
the MVC pattern. So you see app.person equals ember.object-extend. And you see it's declaring some properties, first name, last name, and full name as well. Now here, I'm not showing the ES2015 version of Ember. There are some equivalences of that. If you're using Ember, I would love to talk to you and have you help me update my code.
21:01
I had a bit of problem with the CLI when I was preparing. So there's probably a slightly different approach you can take today. But essentially, the important thing is that you're declaring a model. And then here, we're instancing that model, so creating an instance of the person. So that's our model instance. And then down here, we're setting up the router.
21:20
Now I haven't showed you routers on other frameworks, because the other frameworks don't really require a router for the basic app. But with Ember, like I said, it's a very strict MVC paradigm, so you have to have a router involved. So here, we just set up the router's map, and we create this generic index route. Again, this is based off convention. You can see that naming convention of index route. That's going to be the index route that it goes to,
21:42
and it doesn't match any other patterns. And you can see how by declaring that route, we're creating it, and then we're specifying what model is associated with that route. So you can see the very explicit MVC design here. And notice the name is index route. And the view, of course, was called index. So you can see those conventions of hooking things
22:00
up based off of naming. And that's how Ember looks. Now let's move on to Polymer, which is a very different approach. Polymer is based exclusively on web components, and actually attempts to do almost everything in the DOM. So if we look at index HTML, again, we're going to see the script component to bring in the basic web component's polyfills.
22:21
And then we're going to see an HTML import link, which brings in the app itself as an HTML manifest, basically. And in here, you can see the my app element being declared. So where does the behavior from that my app element come from? Well, again, let's look in the my app HTML. And again, you can see that it's that that links in the
22:41
actual Polymer framework. So Polymer's layering on. It first starts with the polyfills. That bootstraps the process so that it can then load the whole framework in. So that's where Polymer framework comes in. Now, notice the very different approach here. Everything is done in HTML. In fact, there's a DOM module. And so components are used to create other components.
23:02
Very different from the other frameworks. Completely different methodology. Notice the DOM module has an ID of my app. And also, this Polymer script says is my app. And over here in index, we have my app. So you can see how things are linked together. In Polymer, you have the template that's, again, using a Web Components template, just like Irelia did.
23:23
It's got its own binding language. It uses the double curlies for the interpolation. And you'll notice that for two-way data binding has a bit of a different syntax. So you'd have to declare the property first name that you want to bind to. And then you use this double colon syntax to indicate the name of the event that is going to trigger the reverse
23:41
binding update. So you can see in first name, we need to say that it's the input event. And last name, the input event. That's triggering the bidirectional update of the binding. And then you can see that rather than having a computed full name down here, it simply does it in line using spans. So that's a little bit different as well. And then finally, you have the script tag that uses the
24:03
Polymer API to declare the link between the pieces with the is property. And then a ready function, which is part of the Polymer component lifecycle, that sets up the initial values of the component. So you can see this is very, very different in nature and philosophy than Ember and very different from Aurelia and
24:22
very different from both the Angulars. Completely different approach. I think a strange thing to note about this is it's very, very web component focused. And everything is done in DOM like this. So this is a little bit actually concerning for me,
24:40
because it doesn't entirely make sense to do everything in HTML. But there it is. That's my opinion. I have seen some things like this done in the past. Does anyone remember Microsoft Acropolis project? Nobody remembers this. It was like 2008. This was in the early days of Microsoft XAML when they attempted to do everything in XAML.
25:00
And that project died. That's why you've never heard of it. So I kind of worry about this approach a little bit, because it hasn't been tried in the past, and it's a little bit odd. For example, Polymer has Ajax elements. HTML elements for Ajax. HTML elements for local storage. And that maybe works for simpler apps, but it seems a
25:21
little bit not quite right perhaps for more complex applications. So this is a very, very different approach. Very web component oriented. Finally, let's look at React. Again, React is going to take an extremely different approach from everything else. In index, I'm just setting up a bunch of scripts. Don't really worry about that.
25:40
The important part is this div with the container ID. In app, I'm going to jump down to the bottom first so you can see how the framework actually gets things started off. We use the React API to render the app into that container that I just showed you. So where does that app come from? Well first, I'm basically writing JSX here, which is a
26:02
custom language that combines JavaScript and HTML together in the same file. In React, we can create components by creating a class that inherits from component. We declare our state, so you can see this is kind of like the model. We have our first name and our last name, that's our state. And then that state gets rendered into the DOM.
26:22
So we can see the render function, how it has HTML, and it's rendering out an input. And that value of that input, it's getting its value from the first name. Now this brings up an important point. Every framework we looked at so far has a two-way data binding. It could flow data automatically back and forth.
26:42
React doesn't really do that. Instead, it has this one directional data flow for everything. And so it looks like a binding, but what it's actually doing is it's only getting the first name out of that state and rendering it into the input's value. If you want to go the other direction, you need to manually wire up the events. So you can see here I've got this on change event.
27:02
And whenever the on change fires, then I'm going to call this first name change method, which is up here. It's going to get the event. From that event, I'm going to pull out the value of the text box and update my state so that my first name is now updated. I'm then going to tell it to recompute the full name. Once that whole process finishes, the component is
27:21
then going to re-render itself with all the new values. Same thing goes for last name, which you can see here and here. And of course, the full name is just rendering out that state. So you can see that, at least in the case of data input, there's a much more manual process that one has to go through in order to handle that. Now, there are other things on top of React that will make this easier.
27:40
But out of the box, this is the kind of flow that you deal with when doing kind of input-based stuff. All right, so I think with that, we're done looking at this. This is obviously really fast. I just threw a ton of information at you, six frameworks, and we spent about four or five minutes per framework.
28:01
So now you have a bit of a foundation for understanding what these frameworks look like, how they're used, what their philosophy is, kind of the different ways that they do the same thing. From that, I'm going to jump back into my slides, and let's get into the nasty part. Don't hate me. We're going to start comparing things now.
28:22
We're going to start with a technical comparison. The first comparison I want to make is the size of the framework. The clear winner in this case is React. I didn't talk about Redux, but a popular combination of React is combining it with Redux. And so you can see that Redux plus React comes in as the smallest framework.
28:40
These are all minified sizes, not gzip, but minified. And so you can see that React is the smallest framework. If you add some of the optional plug-ins, that's where you get 167k from. The question marks there at the end for that size represent what I stated at the very beginning, which is that React isn't really a framework. It's more of a view rendering engine. So you have to remember that if you're going to use React,
29:01
you're going to have to add things to it. So that's the question marks representing the size of your custom-built framework, if you will, using React is very dependent on the project. So that's really kind of an unknown. If you move up the line into what I call this middle
29:20
zone here with Angular 1, Polymer, and Aurelia, you see things get a little bit larger. But Angular 1 was still small. The 158 is the minimal version. The 240k is basically a more typical configuration, which includes the router, the HTTP capabilities, and the animation system. When you move up the Polymer, it's
29:40
getting a little bit larger. 222 is sort of their minimal version based off of their light polyfills. 302k is using a more extensive spec-compliant polyfill. And the question marks in this case indicate the fact that this doesn't include a router, an HTTP client, or an animation system. So you can see how we went up in size from Angular 1 to
30:01
Polymer, but we went down in feature set. So these are things that are important to realize with the frameworks. When we move up to Aurelia, we're slightly larger. 255k is the minimal size. And then 323k is the framework plus the normal standard plug-in. So that includes a router.
30:20
That includes animation. And that includes an HTTP client. Moving out of that mid-zone, we start to get into things that are definitely a bit larger. Ember has done a lot of work to bring their size down, but there's still a good chunk larger than the next kind of size down. So they're at 435k. That includes the router, as you know, because Ember
30:41
requires the use of a router. So that's going to include the router. And I believe that's also HTTP, but I don't think there's an animation system in there. With Angular 2, you see a bunch of sizes that are, again, quite large. That 698k is the minimum framework. 919k is the framework plus RxJS, which is a highly
31:01
recommended extension, because Angular 2 is very based on RxJS in a lot of ways. So they kind of recommend you drop that in there. 1023k includes the router and the HTTP client, but does not include animation. So you can see at this point, we're actually more than twice
31:21
the size of Ember for the same features. And actually, Ember can do some more things that Angular 2 can't do. So Angular 2 is clearly out in left field somewhere here. Now, an important note about Angular 2 is they have been working a lot to get their size down. And one of the things they're doing is called tree shaking, which allows them to remove parts of the
31:42
framework that you're not actually using. The problem with that is the only way to get your app small is to not use much of the framework. And in real world apps, you typically use a lot of the framework, especially if you bring in a third party component library, like a Telerik suite, any kind of data visualization. These libraries make extensive use of the core framework
32:01
capabilities, oftentimes doing dynamic compilation, which means you can't tree shake those capabilities out. So you're going to be left with a large framework there. So just bear that in mind. Even though Angular 2 is the largest, it still has less features than some of the frameworks in the middle zone, which are a third smaller.
32:22
How about performance? How fast can these frameworks draw on the screen? Using an independent benchmark called dbMonster, which basically regenerates lists as fast as the frameworks can do it, I ran these benchmarks on this machine with the same browser. So this is a Macbook from three years ago, and I ran
32:44
them in Chrome. And these are the numbers that I got. I don't have a number for Ember, because I couldn't find an updated implementation of this benchmark for Ember. There's one out there, but it's very, very slow, but it's also very old. And I know that Ember has done extensive work in
33:00
performance, which I believe makes it definitely as fast as Polymer, but maybe up there with Angular 2 and Irelia as well. But you can see that Irelia and Angular 2 are pretty much head-to-head in terms of performance here. They're really, really close. On my machine, Irelia was a little bit faster, but it's kind of negligible in that first number. They're both very, very fast.
33:22
To be honest, all these frameworks are very, very fast. That's 50, even on the React, which is on the low end in this benchmark, 50 paints per second is faster than you can see. So this is pretty fast still. That's how fast it can repaint the entire list per second.
33:43
You'll notice that Irelia and Angular 2 have secondary numbers, which are higher. That's because both of these frameworks have plug-ins which allow you to opt into other features that improve rendering performance in certain scenarios. With Irelia, we have a virtualization plug-in, which only draws elements of the list which are actually visible. So if you have 10,000 items in a list, but only 20 are on
34:03
screen, it'll only draw 20. So that makes a lot of sense. By dropping that into this benchmark, we get 130 to 150 paints per second, which is far above everything else. In Angular 2, they also have a web worker-based multi-threaded renderer, which can be turned on as well, and that also improves their performance.
34:21
One caveat with that is that it only works in Chrome and Firefox, because that technology isn't implemented everywhere just yet. But it's coming. But bear in mind, you won't be able to get that upgrade on older browsers at all, as opposed to the other upgrade. So how about standards compliance? How close are these frameworks staying to web standards?
34:43
Well, at the top of the list, you've got Irelia, Polymer, and Ember, which are all using standards compliant HTML, all focusing on ECMAScript 2015. And then also Irelia and Polymer are also using parts of the web component spec. I ranked Irelia higher in this case, because Irelia also implements the Shadow DOM v1 slots, which Polymer has not
35:02
updated to yet. If you don't know what that is, don't worry about it too much. It's just one of the web component specs. But I imagine Polymer will be updating to that very, very soon. But clearly, Irelia and Polymer do the best job at standards, with Ember being a very, very close behind. When we get down to the second half of the list,
35:20
things get a little bit odd. As I mentioned when we looked at the Angular 2 code, we have something that looks like HTML in Angular 2, but it begins to use casing that makes it impossible to use with the built-in parser of the browser. So they've deviated just enough from the spec to require their own parser, which preserves casing. So that's a little bit odd.
35:40
Also, they write part of their code base in Dart, which maybe it's an issue, maybe it's not. But a lot of people don't know that. Angular 1, actually, in some ways, more spec compliant than Angular 2. Very good job of having standards-compliant HTML. I used ES5, but that was the cutting edge, of course, at the time. The place where it wasn't as compliant was in modules
36:02
and the way it handled dependency injection, because it's just an older framework. It was just before these things got standardized. So in some ways, Angular 2 improved on that by using a better pattern for modules in DI. In some ways, Angular 2 kind of regressed in terms of how they're handling HTML and some things. React is very, very different.
36:20
It's using ECMAScript 2015, but it's also using this JSX thing. Now, your opinion, you can kind of think of this in multiple ways. If you think of this as a view rendering language, then it's not such a big deal, really. But it is a bit odd that it looks kind of like HTML, and it's mixed with JavaScript, but the HTML that's in there isn't actually HTML.
36:40
There's mixed casing, and there's event names that aren't the real event names, and different things happening in there. So it's maybe not a huge deal for you, but the important thing that you should note is that if you have a new developer coming in that's learning, say, React First, and then they go and try and just write HTML, they may have learned things wrong, because the HTML in the
37:02
JSX isn't precisely HTML. So it's a bit of a non-compliance issue there. Maybe a big deal, maybe not. Depends on what you're doing. Separated presentation. Things like MVC, MVVM, MVP.
37:20
How well does the framework or platform allow you to have a clean design by separating the model, the view, and the controller or the view model? How good does it do separated presentation? Well, you saw that Aurelia and Ember did a pretty good job with those demos. Very clean template in one file, class in another. Ember had a very strict MVC pattern, so those pieces are
37:41
very clearly differentiated. Angular 1 actually does a pretty good job as well. The syntax isn't as clean. Like I said, it's a bit dated, but it keeps those pieces pretty well separated. Angular 2 actually gets worse. And you can't see this in the demo that I showed you, because it didn't use a lot of external directives. But when you build a component in Angular 2, whatever
38:02
directives you use in the HTML, if you use a repeater or an if or a switch, those have to be declared in the JavaScript. So your controller or your component code is strongly linked or strongly coupled to your view, which means that those two things can't vary independently of one another very easily without a maintenance problem.
38:22
It also means that it's hard for two people to work on the same component. If you've got a designer that wants to work on the HTML and CSS, they can't do that without messing with the JavaScript. And if you've got a JavaScript developer that's maybe working on the advanced behavior there, they're going to be stepping on one another. Remember that things like separated presentation, these patterns. And in fact, most design patterns are not primarily
38:44
about technical issues, but about human issues of how we collaborate and how we work together and how we achieve productivity. If everything's in the same file or if concerns from this thing mix into concerns from this thing, then we can't have two people work on it at once. We now get less parallelization of our work.
39:02
Now only one person can work on it. And this is the same problem that Polymer has also. If you saw everything was done in DOM, but now every single piece is in that same file, and it's not really a good way to split that out. And so that causes a problem if you want to parallelize work with multiple people working on the same component or
39:20
subcomponent of the system. Now separated presentation doesn't apply to React. Because remember, React, in fact, in some ways, it uber-applies. Because React does the view. And that's all it does. You are responsible as a developer to figure out how you're going to do separated presentation yourself in every React app that you built. So you need to take
39:40
responsibility for doing a good job with that. But React focuses on the view. And so this criticism, if you will, or this way of comparison doesn't necessarily apply to React. Because it doesn't care about view models or controllers or models or any of that. How about obtrusiveness? How much does the framework get in your way?
40:02
The framework APIs, how intermixed with your code do they get? Aurelia is probably the best at this. In fact, no framework is quite like this. If you remember, I showed Aurelia. It's just a plain class. There was no framework in the JavaScript. Ember and Polymer actually do a pretty good job of this.
40:21
You can see that Ember lets you, for the most part, create simple models. In fact, it's much better in ES2015, if you look at the way you do it in ES2015. Polymer does a pretty good job. But Angular 1 and Angular 2 were actually both very obtrusive. One of the ways you can see this with Angular 1 is you go look at all the plug-ins for Angular 1.
40:40
There's thousands and thousands of them. Is that just because Angular 1 is popular? Or is it because you have to wrap every third-party library in order to make it work with Angular 1? And the reason is because the design of Angular 1, the way its dirty checking mechanism worked, is any time you wanted to use a third-party library that might touch the DOM, you had to wrap it and call some
41:00
special Angular APIs in order to make it work. So that's very obtrusive. There's a high friction that's involved in that process. Also, Angular 2 is fairly obtrusive as well. Although it improves on that issue from Angular 1, it now still has those component directives everywhere in your code. You have to declare the directives from your HTML in your JavaScript.
41:21
And in general, if you look at more advanced Angular 2 apps, you'll see that you have to configure the change detection mechanism a lot more, and deal with a lot more of the nitty-gritty details of how Angular works, ultimately making you write more and more Angular code in the real world. And React is fairly obtrusive as well, because there's no escaping the React APIs. When you write a React app, you're using the React APIs
41:42
to render. You're typically using JSX, so React is just kind of infused in most of your view code, at least. And again, it's up to you as a developer to take responsibility to isolate those things appropriately as you know how to do. How about interoperability?
42:00
Well, interoperability is typically a function of standards compliance and obtrusiveness. So the things that stay closer to the standards are going to interoperate better with other things. The things that stay out of your code and out of the way of other codes are going to interoperate better with the other things. So Aurelia, Ember, and Polymer are much more interoperable than, say, Angular 1 and React, which are on the other end.
42:22
As I mentioned before, with Angular 1, you typically had to wrap every third-party library that you used. With React, most of the React developers I've talked to tell me that they don't use anything like JQuery, for example, typically instead that they would just rewrite the thing. So there's a lot of writing stuff from scratch, because it's more difficult.
42:41
It's not impossible, but it's more difficult to smoothly interoperate with somebody's third-party plug-in, because those things work with the DOM, and React works with a virtual DOM. So there's a bit of an interoperability issue that needs to be solved there. Angular 2 improves in this category because of the way it's changed its dirty checking mechanism. But there's still a certain amount of pain that's involved
43:01
in interoperating with things because of the extra syntax that's involved. Let's move on from technical comparison, and let's talk about the project and the team. Again, a lot of people think only about the technical stuff. But I've got three or four other categories that we need to go over, because there's a lot of things you need to think about when you pick a platform.
43:20
So let's look at the project itself. The project here, you can see they all have websites, which is great. They all have their own websites. They're all open source, and they have their source code available on GitHub. They all have pretty decent open source licenses, MIT for the first four, and then BSD for the second two, with a note on React.
43:40
I'll come to that in a minute. Status is worth mentioning, because the way that these frameworks handle releases is quite different. Angular 1 is on the 1.x release, but it had breaking changes in its minor releases. So it didn't really follow a semantic version. It's more like it's on version 5, to be honest. If they were semantically versioning Angular 1, it would
44:01
be like Angular 5. So keep that in mind. Angular 2 is in a release candidate now, though the release candidate wasn't really announced on the blog or on the website, and they just recently added a note onto the GitHub. So it's sort of like a soft release candidate. It's still undergoing breaking changes.
44:20
In fact, just today, they announced a brand new implementation of a router that's in an alpha state. Even though it's called release candidate, it's not really a release candidate. We have to be honest about that, if you look at what's actually happening there. With Irelia, we're in beta, but we've been in beta for six months with a stable API for six months. So we're not RTMing yet, but it's more
44:42
stable than some RTMs. With Ember, mega props to the Ember team. Really impressive the way that they've handled their move from 1.0 to 2.0. They had a very strategic way in which they versioned the framework, in which they migrated developers and slowly deprecated features. So they're on an official 2.0, semantically versioned, and
45:02
have done a really fantastic job with how they've transitioned the community over time. Polymer just recently hit 1.0, and it's a real 1.0, so good job for them. And also props to the React team. The React team was on 0.14, 0.15, and then they realized, you know what? We're really on version 14, and we're
45:22
really on version 15. So let's just say that, because everybody's using it that way anyway, and now let's properly semantically version our library. So they switched over to the 15x version, and that's an accurate representation, I think. So props to them for recognizing that and switching that. All these projects have a lot of stars. If you look at GitHub, anything with more than 3,000
45:41
or 4,000 stars is a pretty successful project, to be honest. Clearly, the ones backed by Facebook and Google have more stars, because it's Facebook and Google. You can also see the open issues. This is, again, as of a couple days ago, so these numbers obviously change, all these numbers here. But the smallest number of issues goes to Ember.
46:02
Now, this isn't bugs. This is bugs, features, all kinds of different things. I looked across the tags of all these projects, and the way bugs are categorized are quite a bit different, so it's difficult to get an existing number of reported bugs across there. But what seemed, from my looking at it intuitively, is that the number of bugs was correspondent with the total number of issues, at least.
46:22
So keep that in mind. But props to Ember on this. They have the smallest number of open issues, second by Irelia, and the most open issues is Angular 2. And a really important note here, and if you don't know this, I'm sorry to be the bearer of bad news, but the
46:42
React license has a patent clause in it, OK? If you're using React or considering using React, you should not unless you talk to a lawyer. Because of the patent clause, it means that you cannot do anything that in any remote way could be construed as competing with Facebook.
47:01
You're actually not licensed to use React in those cases. You also, your license is revoked if you have any kind of IP dispute with any other company that happens to be using React. And there are a bunch of caveats to this. If you don't know anything about patent law, it's crazy. I'm just telling you, it's crazy. The ways that these problems can arise.
47:23
So I'm getting on my soapbox here, but I'm saying I would never touch a framework with a patent clause in its license. I don't think that open source and patent clause is mixed. I don't want to make that decision for you. You need to have a lawyer and talk to your lawyer and think about your business and what it is you're doing before you use React. Because there is a patent clause in there, and that
47:41
does have serious ramifications. That's why Google employees are forbidden from using React. That's why Microsoft employees aren't allowed to use React. All these kinds of things. Not a lot of people know this because they don't scroll down to the bottom of the read me, then look there and read the license and see all this stuff. But it's in there. It's right there. So please keep that in mind.
48:01
That doesn't mean you can't use React, but it means that you need to consider this carefully from a legal and a business perspective. How does the core team work out for all these frameworks? Well, each framework here has a sizable core team. I couldn't determine the exact size of Angular 1 because they're shuffled in with the Angular 2 on the website.
48:22
But all these frameworks have a team. And this is really important for a framework like this. You don't want a one man show that's not really going to be good as a platform. If it's a smaller JavaScript library that does one little focused thing, it's not a big deal if it's only one person. But if you're picking a platform to build your app on,
48:41
you probably want there to be a team. Now the teams are located mostly in Silicon Valley because, really, four out of the six frameworks here are made by Google or Facebook. So they're like next door neighbors. So Angular 1, Angular 2, and Polymer are all the teams are located basically on Google's campuses. And React, they're basically right at Facebook.
49:01
Now here we get into something really interesting here. Take a look at this. One of the most important things you need to consider when picking an open source framework is do the people who design the framework use it? And this is actually quite surprising, especially to a lot of people who use Angular, which is the answer is no with
49:21
respect to Angular 1 and Angular 2. The people who actually design and implement Angular don't use it on a day to day basis. From what I could tell, some of them may have never put an app in production with it, or at least not in maybe multiple years with respect to Angular 1. This is really important for open source.
49:41
If you adopt open source, you want to make sure that people that are writing this library are actually using it themselves. They should feel the pain you feel. They should understand what works from their own experience. This is just an aspect of, I think, us as humans, that when we're using our own tools, we understand how to make them better.
50:02
And so you can see actually that Angular 1 and Angular 2 didn't really do such a good job of this. Polymer, they partially use it, especially at big events, so they do some stuff with it. React, at least, they initially did. I'm not sure if the same team is using it now, because now they've got this framework team. I would love to hear information whether the
50:20
actual React developers are actually building Facebook products with it or not. It definitely came out of a Facebook product, which is a really good starting point. So that's important. Or not a Facebook product, but what was that company? That other company. Anyways, the other thing is training. Do the core team members actually train? And this is actually really important, because often, not
50:43
just the best source of information, but the best way to understand the mentality of a framework is from the creators of it. So can you actually get access to the people who build the framework to go to a workshop with them, or to have them come to your company and train you? And that's also an area where none of the Facebook or
51:04
Google-oriented things succeed. So Irelia and Ember really do very, very well in both these categories. How about community and communication? Well, on the community side of things, there's a lot of contributors for most projects.
51:21
This is the number of developers from the community that have committed code to the project. So you can see Angular 1 is the biggest there. It's also been around the longest, followed by React. And then you can see then it's Ember, Irelia, and Angular 2, and then Polymer. And Polymer has the smallest number of community contributors. How well does this team collaborate with the
51:43
community, invite them, and take their feedback? And Angular 1 did a great job with this. Angular 2, not so much. They kept a lot of things in private documents and sort of behind closed doors. Even though it was open source, it was kind of not really talked about publicly, at least for the first year or so. So they didn't do a good job with that.
52:02
Irelia and Ember do a really great job with this, involving, in fact, Ember has an official process by which it does this. Polymer was very close in the beginning. And they weren't making any progress with web standards that they wanted to see adopted. So they finally loosened up on that and started collaborating with other groups. And so that's good.
52:21
And of course, React does a really good job of collaborating with the community. How often do they communicate with their community? If you want to find out the news of what's happening with this platform, how often are they talking to you? Now, Angular 1 and Angular 2 combined only have one to two posts in a three month period. So they're not very good at communicating openly.
52:41
Ember and Irelia both have at least one post per week through the official channel. So you can stay up to date. Polymer and React both do a pretty good job of having a regular, at least once a month, update on the project. And this kind of communication is really important when you build your business or product on top of that. You want to know what's going on, what's coming, what
53:01
the plans are, all these sorts of things. Public appearances is do the core team members actually appear at public events? Do they actually come out to events like this and talk? Do they go to code camps? Do they go to meetups? Do they go to events that aren't their event sponsored?
53:20
In other words, do the Angular core team, do they actually speak at events that aren't AngularConf? Does the React team actually speak at events that isn't ReactConf? And the truth of the matter is you don't really find them out there doing much in the community like that. Very different from the Irelia and Ember teams that are speaking all over the place, all over the world, from the smallest meetups to big conferences like this.
53:42
I think that's really important. How about learning materials? You want to learn a framework, you need good materials. Well, the great thing is that this is mostly a bunch of yeses. For every one of these frameworks, there's API docs, articles, guides, videos, Pluralsight courses, books, starter kits, command line tools, samples, everything. There's just one little detail.
54:02
If you want official training directly from the people that build the framework, you can only get it for Irelia and Ember. So that's not something you're going to be able to get from Google or Facebook. This really brings us into the business side of things. Does the company that produced the framework buy in?
54:23
Well, this comes as a shock to a lot of people, but Angular 1, Angular 2, and Polymer are not Google products. They're open source side projects of teams inside of Google. They're not productized. In fact, one of the surprises I had when working on the Angular 2.0 team is that nobody ever used the term customer, and nobody ever talked about product.
54:44
In fact, I found myself being one or two or three consultants that were the only people advocating for the Angular community during the design of Angular 2.0, and that really troubled me. And the reason is because there's not an official product going on. There's not an official customer relationship.
55:01
As we go down, you'll see a few other things here. Polymer also, I asked them point blank. Is Polymer a Google product? Am I a customer if I'm a developer that uses this product? And they said no and no. Same thing with React. It's not a product of Facebook. Facebook is not committed to React as a product. Can you get commercial support? Well, again, it's only for Irelia and Ember.
55:22
Can you get consulting directly from the people that built this, directly from the companies that build these things? Well, only for Irelia and Ember. Are there official customer relationships? Again, for both versions of Angular and React, there's no product there. There's no official customer relationship. That infrastructure does not exist.
55:42
Again, it does for Irelia and Ember. And that comes down to, and same thing goes with official partners for the most part. Angular 2.0 has a couple. But for motivation, this really comes down to motivation. Why does Angular exist? Because of green tea. Who knows what green tea is? You don't know what green tea is? That's the app that drives everything that
56:02
happens with Angular. It's an internal app. This is not private knowledge. You can go Google this and you'll find it. It's just not talked about a lot publicly. But if you look through the design documents, if you look through the GitHub issues, you'll see GT, GT, GT. You'll see this all over the place. Or maybe spelled out green tea and you can Google this. Occasionally at a conference, you'll hear that phrase mentioned.
56:20
And that's because it is the product that Brad Green and his team works on. And it's the sole reason for Angular 2. And it trumps every other design decision. When I worked on Angular 2, I got really frustrated because the feedback I was providing didn't seem to matter because it was always trumped by this green tea project that was internal. So you need to understand what the business motivators
56:40
behind these things are. The only companies that are actually building a platform for developers are the companies behind Irelia and Ember. Polymer, mostly built kind of as experimentation with web components. React was originally built with apps. But you'll also hear the React team use the language of experimentation. We wanted to experiment with this.
57:01
We wanted to experiment with that. Only Irelia and Ember have, from a business perspective, decided to build a platform as a stable platform for developers. Brand recognition, well, obviously Google and Facebook. They have the best brand recognition. All right. Now, just pointing that out.
57:21
Thank you. So what are my recommendations at the end of this highly biased talk? You can probably figure out what they're going to be. But I hope you see why. I'm not trying to pull one over on you, OK? These come in three categories, the yes, the maybe, and the no. So clearly, I think the yes is Irelia and Ember.
57:42
Obviously, like I said, I'm biased. I include Ember in this because you see a lot of the same values on the Ember team as we have on the Irelia team. Standards compliance, stability, the business side of things, all these different things that I talked about, which are secondary or tertiary concerns of the other
58:02
frameworks. Really, really important. Maybe is Polymer and React. This really depends on what you're doing. React is much better for read-only apps. It's more difficult for input-intensive apps. But remember the patent's clause, OK? You cannot ignore that. If that's a problem, then React is
58:20
probably a no for you. But if you really like the React programming model, you should look at Riot. It's an alternative very similar to React, but without the patent problem. In fact, it's smaller as well. So again, maybe React, but probably if you're leaning in the React direction, you might want to look at Riot instead. And Polymer, maybe as well.
58:43
Polymer is less app focused and more component focused. So if you want to build a set of reasonable components across multiple apps, Polymer might be a good choice. But again, nobody wants to include another framework just for components. So what I recommend is instead of using Polymer, you consider using Web Components JS, which is just the
59:01
polyfills for the standards upon which Polymer is built. And then you can just build spec compliant web components to share across apps, and then pick one of these other frameworks as the app framework that helps you bring those pieces together. So those are in the maybe. And clearly, you knew this from the beginning, right? You knew it.
59:21
Sorry. Angular 1 and Angular 2. Well, I told you Angular 1 up front mainly because it's deprecated. It's basically going away. If Flash and Silverlight are dead, Angular 1 is more dead, because you know now that it's not actually a product at Google, and there's no reason to actually support it if green tea isn't built on it anymore.
59:40
So it's going to die faster than anything from Google's perspective. And Angular 2, you just saw that it has the same motivational and business problems as Angular 1. It's also very large and very complicated. It requires a lot of ceremony to work with in the code. Standards compliance has kind of gone backwards.
01:00:00
with respect to that, and a number of other things. Now obviously, these are my opinions. But hopefully, at least the slide deck has given you a bunch of information and encouraged you to think about a lot of different aspects of what it is that is guiding your decisions. And remember that all this data influx, the team, the collaboration, the communication, the technical aspects, the business motivators, those all need
01:00:22
to be considered within the larger context of your company, your product, your team, your corporate culture. So I just want to encourage you to think very clearly about these things when you're making decisions. Don't just pull something off the shelf because you know the logo. There may be more things under the hood there than you expected, which aren't quite
01:00:41
perhaps what you assumed. So do your research. Consider all these facets. Take everything into account, and try and make the best decision that you can for your business going forward. Thank you for being with me. Really, thank you for humoring me and understanding my bias and bearing with me through this presentation. I am the worst person to give this presentation,
01:01:01
clearly. But I wanted to give it because a lot of this information just wasn't out there and aggregated. So I think even if you can see through my bias, then you can see that there's some very valuable information here. So I hope that helps you. Thank you again for coming. And please don't forget to press the green button on your way out. Thank you.