Empowering the Next Million Creators
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 |
| |
| Title of Series | ||
| Number of Parts | 28 | |
| Author | ||
| License | CC Attribution - 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/33637 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 201725 / 28
9
13
14
16
17
18
23
24
00:00
MaizeDifferent (Kate Ryan album)Continuum hypothesisPoint (geometry)ExistenceMathematicsRight angleStatisticsWeb 2.0View (database)Set (mathematics)Goodness of fitArchaeological field surveyPower (physics)Computing platformSoftwareProcess (computing)MereologyPhysical systemNeuroinformatikProgrammer (hardware)DatabaseProduct (business)Bit rateCuboidMultiplication signSound effectTask (computing)AnalogyLevel (video gaming)AxiomInterface (computing)Order of magnitude1 (number)Arrow of timeBitCategory of beingPicture archiving and communication systemState of matterAdditionMassCartesian coordinate systemCasting (performing arts)Software testingRandomizationVariety (linguistics)TouchscreenCodeWebsiteTerm (mathematics)WritingProjective planeComputer animation
05:32
Standard deviationInstance (computer science)SubsetParameter (computer programming)Decision theoryStandard deviationCuboidComputer architectureComputing platformWeb 2.0Renewal theoryTask (computing)Formal languageEndliche ModelltheoriePoint (geometry)Cartesian coordinate systemPower (physics)Message passingShared memoryProgrammer (hardware)Term (mathematics)MassNumberService (economics)DebuggerProgramming languageSoftware development kitReading (process)Template (C++)Extension (kinesiology)Right angleReal numberMathematicsProcess (computing)Table (information)Software frameworkMereologyWebsiteBoom (sailing)Server (computing)Level (video gaming)Goodness of fitSoftware developerSpacetimePosition operatorTheory of everythingBridging (networking)Stack (abstract data type)Mobile appPlastikkarteDemo (music)Shape (magazine)Set (mathematics)CodeAnalytic continuationSemantics (computer science)FeedbackXML
11:04
Chi-squared distributionDemo (music)Demo (music)Multiplication signMedical imagingStreaming mediaNumberReduction of orderHypermediaSeries (mathematics)Functional (mathematics)AreaCartesian coordinate systemMeeting/InterviewXMLComputer animation
11:57
Internet forumDemo (music)Mobile appMereologyMarkup languageContent (media)Set (mathematics)Connectivity (graph theory)Surjective functionComputer configurationWaveletElement (mathematics)Point (geometry)Right angleMedical imagingBitCycle (graph theory)Drop (liquid)Primitive (album)Computer animation
12:53
Demo (music)Right angleOffice suiteMathematicsRight angleNumberConnectivity (graph theory)Speech synthesisScaling (geometry)AreaResultantSpacetimeMobile appCartesian coordinate system
13:42
Stack (abstract data type)PlastikkarteEmailCASE <Informatik>Group actionConnectivity (graph theory)Content (media)ImplementationCartesian coordinate systemDemo (music)EmailData managementMultiplication signAdaptive behaviorPlastikkarteCycle (graph theory)Right angleCuboidLie groupComputer animation
14:40
Artificial neural networkComputer virusExecution unitWeb pageData modelComponent-based software engineeringComputer fileThermal expansionHill differential equationCompilation albumStack (abstract data type)Content (media)Default (computer science)State of matterStrategy gameSpacetimeGreatest elementOperating systemBlock (periodic table)BuildingFault-tolerant systemPlastikkarteContent (media)Stack (abstract data type)System callVolumenvisualisierungTemplate (C++)Web pageConnectivity (graph theory)Interactive televisionRight angleComputer animation
15:34
Demo (music)Web pageSocial classContent (media)MereologyEndliche ModelltheorieExterior algebraCASE <Informatik>Software frameworkVolumenvisualisierungAttribute grammarContent (media)Type theoryDescriptive statisticsState of matterContext awarenessWeb pageTemplate (C++)Right angleConnectivity (graph theory)Sound effectField (computer science)Canadian Mathematical SocietyCuboidMedical imagingPreprocessorMassPlastikkarteDrop (liquid)Stack (abstract data type)Interactive television
17:13
Type theoryCore dumpPlastikkarteMessage passingStandard deviationString (computer science)Right angleField (computer science)Inheritance (object-oriented programming)Text editorType theoryContinuum hypothesisBuildingEvoluteNP-hardOpen sourceProjective planeResultantCartesian coordinate systemClient (computing)Computer animation
18:19
Demo (music)Web pageContent (media)Digital photographyField (computer science)Mobile WebIntegrated development environmentData modelDefault (computer science)Uniform resource locatorSocial classMobile appComputer fileBranch (computer science)CodePulse (signal processing)Graph (mathematics)Overlay-NetzStylus (computing)Source codeSoftware repositorySystem programmingForm (programming)Electronic mailing listComputer configurationMultiplication signBuildingThermal expansionField (computer science)Mobile WebWebsiteNavigationEndliche ModelltheorieConnectivity (graph theory)Text editorWeb 2.0Data structureOverlay-NetzConcurrency (computer science)Right angleUniform resource locatorMereologyScripting languageServer (computing)File formatContent (media)AuthorizationSheaf (mathematics)Web pageVolumenvisualisierungCartesian coordinate systemDefault (computer science)Line (geometry)Source codeCodeCuboidLogical constantLink (knot theory)Office suiteInfinityWave packetCASE <Informatik>Bridging (networking)SurfaceProjective planeSemantics (computer science)Point (geometry)Orientation (vector space)Data storage deviceResultantNatural numberPlastikkarteSound effectCanadian Mathematical SocietyScaling (geometry)Block (periodic table)Interface (computing)Branch (computer science)Greatest elementPattern languageElectronic data interchangePlug-in (computing)Element (mathematics)Template (C++)Wellenwiderstand <Strömungsmechanik>Medical imagingDependent and independent variablesString (computer science)Subject indexingElasticity (physics)Perturbation theoryConfiguration spaceOrder (biology)Computing platformWorkstation <Musikinstrument>Control flowGraph coloringSelf-organizationBit rateMathematicsVector spaceExecution unitSystem administratorReal-time operating systemData modelRow (database)TheoremCategory of beingBasis <Mathematik>AbstractionLevel (video gaming)SurgeryCommunications protocolComputer architectureShared memoryHypermediaTerm (mathematics)Open sourceBitDemo (music)Standard deviationDigital photographyStack (abstract data type)Mobile appKeyboard shortcutAuthenticationInteractive televisionRevision controlType theoryCycle (graph theory)Regular graphTrailResolvent formalismFront and back endsClient (computing)Cache (computing)Social class
28:01
Type theoryField (computer science)Modal logicTape driveBinary fileDigital photographyRevision controlData typeHash functionRouter (computing)Default (computer science)RootUniform resource locatorFunction (mathematics)Content (media)Feasibility studyEndliche ModelltheorieServer (computing)Enterprise architectureRight angleMathematical analysisDivisorParameter (computer programming)MassCuboidWeb 2.0Natural numberState of matterCASE <Informatik>Connectivity (graph theory)Traffic reportingLie groupCategory of beingLocal ringStandard deviationRow (database)MereologyCartesian coordinate systemContent (media)InformationNumberNormal (geometry)Moment (mathematics)Replication (computing)Multiplication signBus (computing)Slide ruleIterationSound effectRule of inferenceConstraint (mathematics)Point (geometry)Link (knot theory)Physical systemDefault (computer science)Integrated development environmentTerm (mathematics)Message passingSoftware frameworkData managementVertex (graph theory)Canadian Mathematical SocietyInheritance (object-oriented programming)MathematicsGoodness of fitActive contour modelField (computer science)SpacetimeSource codeWeb pageQuicksortService (economics)Projective planeSoftware developerValidity (statistics)Branch (computer science)Arithmetic meanProcess (computing)Real-time operating systemWebsiteGodHypermediaSubject indexingCollaborationismRevision controlSoftware testingRandomizationDecision theoryGraph (mathematics)Type theoryFigurate numberGroup actionPrice indexGreatest elementElectronic mailing listComputer architectureStack (abstract data type)PlastikkarteConfiguration spaceRouter (computing)MiddlewareUser interfaceDebuggerPlug-in (computing)Software repositoryRoutingSet (mathematics)NamespaceString (computer science)BitPower (physics)outputMobile appAuthorizationDisk read-and-write headIntrusion detection systemTouch typingFront and back endsCore dumpStructural loadError messageHash functionLevel (video gaming)ImplementationXML
37:43
Personal identification numberManufacturing execution systemHill differential equationDemo (music)Graph (mathematics)Asynchronous Transfer ModeElectronic meeting systemLemma (mathematics)Interior (topology)View (database)Point (geometry)SineWikiAuthenticationAuthorizationWebsiteDefault (computer science)Free variables and bound variablesHookingSoftware testingField (computer science)Hash functionRevision controlContent (media)Medical imagingMobile WebServer (computing)String (computer science)Communications protocolBranch (computer science)Plug-in (computing)VideoconferencingComputer fileWordSoftware repositorySummierbarkeitAsynchronous Transfer ModeGraph coloringProcess (computing)AuthorizationMetadataNetwork topologyGroup actionRoutingDemo (music)MereologyMenu (computing)Connectivity (graph theory)Data structureAttribute grammarRule of inferenceText editorType theory1 (number)CodeElectronic mailing listPower (physics)Patch (Unix)State of matterLibrary (computing)MathematicsLine (geometry)Series (mathematics)InternetworkingSelf-organizationRight angleNumbering schemeVideo gameLattice (order)Physical systemMultiplication signTrailStrategy gameFormal languageElement (mathematics)StapeldateiBit rateWindowVolumenvisualisierungComputer animation
42:47
Branch (computer science)AbstractionRevision controlNumberUniform resource locatorWeb pageExtension (kinesiology)RoutingError messageRight angleGroup actionReal numberFraction (mathematics)Row (database)Supersymmetry
44:05
AuthenticationAuthorizationNumbering schemeFile formatContent (media)Data managementHypermediaType theoryPhysical systemSource codeWeb pageStack (abstract data type)PlastikkarteContinuum hypothesisContent management systemMobile appTemplate (C++)Coma BerenicesAuthorizationContent (media)SoftwareProjective planePlastikkarteAuthenticationGame theoryPhysical systemMobile appDefault (computer science)Stack (abstract data type)Complex (psychology)Limit (category theory)Source codeWeb pageBitVideoconferencingMultiplication signConnectivity (graph theory)Field (computer science)Library (computing)AnalogyWeb 2.0File formatType theoryAreaPower (physics)WebsiteCodeServer (computing)Capillary actionGoodness of fitDifferent (Kate Ryan album)Spectrum (functional analysis)DatabaseProof theoryDirection (geometry)ForceProduct (business)Software frameworkProcess (computing)Plug-in (computing)MereologySelf-organizationAxiom of choiceView (database)Query languageHand fanLevel (video gaming)Point (geometry)Rule of inferenceDrop (liquid)LoginTouchscreenImplementationBranch (computer science)Enterprise architectureCartesian coordinate systemText editorLattice (order)Interactive televisionPlanningContinuum hypothesisCurveAuthoring systemMultiplicationData modelFacebookCommon Language InfrastructureVolumenvisualisierungEndliche ModelltheorieSubject indexingRadical (chemistry)Open sourceBoundary value problemINTEGRALSQL ServerSuite (music)1 (number)ExistenceData conversionSet (mathematics)Installation artMathematicsRight angleVideo gameDialectResultantNumberInformationFlow separationTerm (mathematics)Local ringDigital electronicsTupleDependent and independent variablesBlock (periodic table)Analytic continuationPropositional formulaPersonal digital assistantState of matterSpeech synthesisElement (mathematics)Graph (mathematics)Graph coloringChainSpacetimeMessage passingFormal grammarSolid geometryRoboticsUtility softwareData structureData managementoutputTemplate (C++)Color confinementFunction (mathematics)CuboidLogical constantReal numberMobile WebElectronic program guideDivisorHypermediaForm (programming)Parameter (computer programming)Computer animation
Transcript: English(auto-generated)
00:11
It is awesome to be back up here. I hope everybody had their coffee, because I'm going to go right into it. Nothing but code. Actually, I'm going to start with some actually fuzzier,
00:23
more philosophical questions. And then I'll hit you with the code. Yesterday, we had a couple analogies between writing software and being a wizard, writing magic. And it's a very common analogy. It's kind of funny, and people say it a lot. And we kind of get why it sounds true.
00:41
But when you actually sit down and think about that analogy, it keeps looking stronger and stronger and stronger. The archetype of magic throughout cultures across history is that you can actually make things happen just by knowing the right incantation. And that's actually what we do for a living. So software really is kind of magic.
01:03
And as more and more of the stuff in the world runs software, and more and more of every aspect of our social lives is mediated by software, our magic is seeping out into everything. And so we kind of have superpowers. And our powers are growing.
01:20
And so like any good hero story with superpowers, you reach the point where you have to ask, are you going to use your powers for good or evil? Are we going to do that? And so the way I answer that question is it actually kind of depends who's the we we're talking about. Who's going to have the power to wield software going into the future where software runs everything?
01:42
Is it going to be something that stays in the hands of a tiny, elite cast of people who know the incantations? Or is it something that can grow? Is it something that we can spread so that the world stays a bit of a more even place, so that everybody has a shot at wielding the magic that runs the world to stand up for their own point of view?
02:05
So I see this as one of the most important things we can work on as technologists is to think about the question, how do we reduce that gap between where the software is today and where most of the people in the world are with respect to software? There's a big gap, right? There's some really depressing statistics
02:22
about some surveys people have done of actually conducting tests of random people off the street in a whole variety of countries on their computer skills. And the very highest level of skill was basically somebody who could switch from screen to screen three times and get through a task. And it was 5%.
02:41
And in all the rich countries of the world, 5% was the best of people who can stay on task to get through three different screens. So I think that's an indictment of the interface technologies we have and the hope for the future is that we can do better. But so the gap is large.
03:01
Now the good news is every little bit of improvement we make helps immensely, right? There's a lot of orders of magnitude between where we are now and the whole world. And going up by one order of magnitude is a massive change. It changes everything, right? So making the existence of the web and JavaScript is one example of that. It has empowered a massively broader set of people
03:22
to get into what we do. It's a good thing. And Ember itself, this should all be sounding familiar to you because Ember is about this, right? It's about empowering people to do things they couldn't do before. It's not, you know, it's about, yes, it's also about making people who are already programmers faster at their jobs, happier at their jobs.
03:41
But that's, the bigger, longer term effect is that you actually get things happening that weren't gonna happen before. Things get built that couldn't have been built before. People get involved who didn't have an opportunity to be involved before. So my topic today is how do we do that? How do we grow to empower wider audiences of people? Because we've got really special stuff here.
04:02
We've got amazingly powerful capabilities. So yesterday started with an awesome talk about the continuum from really small situations, small applications with less features, and the continuum up from there
04:20
to bigger applications with more features, right? I think we're pretty familiar with the concept. I think we have a good sense for how we fill this continuum and how you NPM install your way up from Glimmer to Ember. It's a very compelling story. I'm very excited to see what everybody goes out and builds with this stuff as the Ember community grows down this continuum into the small niches,
04:41
in addition to the big ones where we're already very successful. I wanna talk today about the other end of the continuum because if you spend all your time in JavaScript land, it's easy to forget that the web is actually still dominated by platforms that have a lot more features than any JavaScript framework, and they empower a much wider set of people to use them,
05:03
which is why they're so successful. So I'm talking about things like WordPress, like Joomla, like Drupal, right? They're each different, and they fall on slightly different parts of this continuum, but all of them are much more out-of-the-box products than programming environments, right? They are absolutely for programmers,
05:21
and anybody doing really serious projects in any of those has programmers working on them, but they're also for people who are not programmers, right? They can serve people who are themers, people who are site builders, people who are content creators, can all have a seat at the table and participate, and then because they're all participating in one ecosystem, more things can happen, right?
05:42
New things get built, and this helps people level up their skills because when you get a whole bunch of people of disparate skill all working in the same ecosystem, sitting at the same table, it's a chance for a lot of cross-pollination. So that's the real secret of success in these ecosystems, and they are huge, and they are not going away, right?
06:00
They're big and successful. What they don't have is they're not built for the modern web platform architecture, right? So also from yesterday's talk, we heard how much the web has changed even in five years, right? And we talk about needing to make sure that we keep our architecture relevant to the web, but we're a youngin' compared to these platforms, right?
06:20
Because they have an architecture that's way older and has way more legacy problems than we do. We're in really good shape. We are built for the modern web, and Glimmer is a very modern web thing. It's much harder if you have a massive ecosystem of stuff that is all locked to the server-side languages and doesn't have rationalized primitives.
06:41
So they have a challenge, right? To the extent that these platforms are shipping Ember-like features, they're doing it by doing small chunks of stuff in a front-end framework, but they can't bridge the gap with their vast ecosystem that already exists on the server. So we have a real opportunity here, and the reason Ember in particular has an opportunity here
07:02
is because of three points. One is HTML. And Ember has been, from the beginning, very self-consciously focused on the web is about HTML, users, a very large set of people can learn to be proficient in HTML. It's a good level of power for the task that it does.
07:22
Without too much power, it's not a full Turing-complete programming language. Principle of least power. It does what it does, and it does it pretty well, and it's an accepted consensus that lets you do a lot of things. Our templates are deliberately just a well-reasoned superset of HTML, and that's a really powerful thing.
07:42
It's been one of the most successful decisions about Ember, and it's what allows us to have evolved so far in terms of the underlying platform and still kept the continuity of the people, the applications, and the, you know, it's actually shocking how well templates have aged, right?
08:02
Way better than typical JavaScript code because it's principle of least power, right? They just declare what they want, they don't say how they're gonna get it. So HTML's one of our strengths. In particular, when compared to things that are just JavaScript, because that's too much power for a templating language, and it means that you're locked into everything, all the semantics of JavaScript, and you can never change them.
08:21
We have our own, we control the whole programming language in our templates, right? We can change how things work under the hood. Our second point is our add-on ecosystem, and I think everybody appreciates that that's one of the strongest things about our community, and also appreciates that it's only possible because we get enough people to agree, right, on strong standards.
08:41
This is absolutely a prerequisite to kind of dip your toes into this space of serving broader audiences of people. The biggest economic reason people use platforms like a WordPress or a Drupal is because it has a great cost to benefit, right? You need your site up, developers are very expensive.
09:01
And you're gonna need some, but isn't it great if you can only focus that expensive effort on the few things that are unique about you, and offload a whole lot of other stuff to a community. That sounds like the pitch for Ember. That's exactly what we do, right? It's just a question of thinking bigger and trying to offload more and more to the community and share more pieces.
09:22
And the third piece, of course, is that community. It's a community that actually invests in shared standards. It's not something you see everywhere, especially in JavaScript, although we are slowly dragging the world along to agreeing on more things, and it's always gratifying to see ideas and consensus efforts that come out of Ember
09:41
slipping into things like the actual JavaScript language, like our impact on things like promises and all the feedback on ECMA standards and all that. So we get the process, right? The process is important and people value it, and that's actually a really precious thing. So those are our three reasons
10:00
why I think Ember is in a position to go move up this end of the continuum and do more out of the box. So Ember, as it stands, is a perfectly clear message that it's for programmers, it's for building ambitious applications. I'm not suggesting we change that. I'm suggesting we're gonna build on top. And so I wanna talk today about introducing
10:22
the card stack application architecture. And I'm gonna take the approach to actually focus on this audience of starting with a completely stock Ember app and gradually adding capabilities up so that you get more and more out of the box that you don't have to have implemented in your application.
10:41
So that's my approach for pitching this to an Ember audience. The goal, of course, is that all these pieces that I'm showing you are things that you could actually put together into a holistic starter kit experience that's a one-click install, and you could actually say, I want a website, and boom, have a website that is interactive, that is based on Ember's architectural principles.
11:04
So I'm gonna start with a demo app here that's just based off of data scraped off the EmberConf speakers list. If you saw me talk two years ago, I did basically the same trick, only that time I was talking about animations. Oh, and incidentally, I should do a shout-out. So I wasn't here last year,
11:21
and the reason was that my son was being born literally during the opening keynote. And so he's turning one today, so I have to have a shout-out to Arthur. Hopefully he's watching on the live stream. So we're gonna take this basic app,
11:40
and we're gonna do Ember add Cardstack tools. So this is the first of a series of Ember add-ons we're gonna talk about adding to our application, and we're gonna get more functionality as we go. So the first thing I'm gonna do is I'm gonna wrap my top-level outlet in the Cardstack tools, and that's gonna give me some new things. What I've got is actually a tiny little launcher up here in the right-hand corner
12:01
that's gonna let me pull in the tool set. Now, don't panic. There's a lot going on here, but we're gonna take it apart piece by piece. And what you're gonna see is that all of these things are just components, and you already know how components work and how to mix and match them and make them be what you need in your app without the parts that you don't. So the first thing I wanna do to make this nicer is,
12:22
you may have noticed when it plays and animates, my content is reflowing. Like, I used to have three images across, and now I only have two. So, because out of the box, we're not trying to force any particular markup onto you. But I have a lot of options for how to deal with this. The primitives here are designed to be very isolatable and composable.
12:42
So just as one example, I'm gonna drop in a little bit of styling around my outlet inside the Cardstack tools to change the way that behaves. And so if my stuff has a fixed size, it's gonna react differently to the tools. Now it slides over instead of crushing. So now we lose the huda off the side, but at least we don't wrap. So, okay, minor improvement.
13:03
Let's add another off-the-shelf piece, right? So here's another completely separate add-on, and it's a completely single-purpose focused add-on that does one thing. All it is is a component that knows how to take its initial size and then scale itself whenever the available space changes. So it's just another thing you could use
13:20
right away in a number app. Drop, there we go, putting it in. So we're gonna drop our squishable container in, and we're gonna have a nicer experience of activating the tools that are gonna edit our application. So that's a pretty nice feeling.
13:43
So we'll stick with that one. Now I wanna dive, I wanna take you down deeper into what we're looking at here. This is the whole implementation template-wise of the Cardstack tools. In fact, it's basically the whole implementation because there's not really much going on in the JavaScript side. So there's not a whole lot of pieces here that you'd have to think about and manage.
14:01
There's actually components coming from two different places. There is a couple Cardstack-specific things, which is the tools launcher. That's the little button component that you can put where you wanna put it to launch the tools. And I've got a Cardstack header and a Cardstack toolbox. Those are both components. That's what you see coming down from the top, coming in from the right. The toolbar manager and the fixed-within toolbars
14:22
and the in-top, in-right toolbar, that's a whole nother add-on. And it's one you can use right away to do all kinds of very general-purpose toolbars in an application. I've got them for toolbars. It has its own little demo that shows how it works. And it knows how to adapt dynamically based on however big your content is of the components that you wanna put in a sidebar
14:41
on either side, on the top, on the bottom. They can combine. And it shows you the different strategies for how you can accommodate the space. So this is just, again, general-purpose Lego blocks that we can all build up with. So prerequisites to building sophisticated interactive experiences. All right, so let's look at my detail page,
15:03
and what the tools are telling me. Right now they say no editable content. So I wanna make my content editable by card stack. I need to annotate my content a bit so that it knows that there's some interactive stuff that it's supposed to be able to edit. And so I'm taking my template from my route, which used to just have a bunch of HTML, and I dropped in instead a call to the card stack content renderer.
15:22
And all that, and the reason for this is that every piece of content is a component. It seems like a reasonable assumption. And so I needed to make one, and there's a conventional place to put the component that represents a particular page. So I move the template over, and I invoke it, and I rename model to content, because within a content card, you have content,
15:40
and that's what it's called when you write your template. So now the framework actually sees, when this page renders, it detects that we have rendered a piece of content that is of type speaker, and it has guessed a description based on the attributes of Yehuda. So the toolbar is now context aware of that's the content on this page that it found.
16:00
It also says that this content is live and published on the site. And we'll get into the other alternatives as we get further into the talk. So the next thing I'm gonna do is actually make some of the fields in here editable by the CMS. So we'll start with the name. And so all I'm gonna do is drop in a component here called csfield, it's right for card stack field.
16:23
And so instead of saying content.name, I'm gonna invoke it as a card stack field. Now this step is one where I have ambitions to make this completely transparent. We already have great infrastructure for template pre-processing. And I think that we can do a very spartan kind of custom component that already, that does this rewriting step for you. So that simply by writing Curly's name,
16:43
you get this effect. So the effect is pretty cool though, right? When you, the animation played kind of fast. Let me go through it here. As you, the editing tools have detected in the sidebar here that there's a name field that's appearing. I can mouse over it there and it's actually gonna highlight it in the page.
17:02
I'll write the blue box labeled with name. As I move my mouse on and off, it'll highlight it or go away. Also if I go over to actually interact with the page, it'll highlight and I can open it up from there. And when I actually click on it or activate the editor, it's gonna highlight that one field for me and it's gonna bring up the field editor for that
17:22
in the right hand side. And it actually comes up with a message right now saying no such field editor for the field editor string. So geez, it seems like a field editor for string should be a standard thing that would come with a framework like this. So let's go ahead and ember add cards.core types. We're building up. We're NPM installing our way up the continuum.
17:42
So now when we do it, we have an editor there that knows how to edit strings and I can go in and edit it. Now this design has been fairly carefully thought out and this is extracted from applications that myself, Kristy, Hassan, a bunch of folks here who worked under the Cardstack banner have done as kind of projects for clients,
18:02
always with the understanding that our goal is to build this open source thing that we can take out. And what you're seeing is the result of a lot of that evolution and hard work on the design side and the technology side. So now we have this nice editable string thing. Great, let's do more. So next I'm gonna just do a simple thing for the photo.
18:25
What I'm showing here is that the CS field can be used in a block form which just gives you the pure value, right? It's not gonna render it for you. You're gonna do whatever you want with it and in this case we're gonna bind it to the source of an image. So I can, this is letting me mark up any arbitrary chunk of the page
18:41
as belonging to that field and then I can put whatever I want in there and now that is highlightable by the CMS and knows that I have a photo URL field in there and knows where it belongs and it's still a string editor so I can come in here and edit it with the string editor. This is okay, this is nice. I have not in this open source version yet. I didn't quite get there.
19:00
We've got a much more interactive image uploader media plugin, crop it right in the page kind of thing. That's on the kind of coming soon list but it exists already and so it's not a big stretch to get it into the open source version. So cool, right? We got these block form ones. What this means is now you can still use all the component toolkit you know, right?
19:21
All these values that are coming out of the CMS, you can send them into whatever component you want. You've already got sophisticated components for rendering this stuff, great. Just mark them up in the block form and what you're getting is really, that CS field component doesn't render any output, right? It doesn't alter your DOM as it appears on the page. All it's doing is letting the card cycles
19:40
when they're activated find exactly what part of the DOM your contents in so that we can know where to put it and interact with it. So let's do the body now, right? If you look at my template here actually, I'm doing something very bad and if you paid attention to Ingrid's talk yesterday, you know why it's bad, right? This is content I scraped literally from the website and the bios have links and stuff in them
20:02
so I kept it at HTML and so to render it, I needed triple curlies which means if we actually let the user edit this stuff, our site is now vulnerable. So that's bad but there's a much better way that could still let us preserve all of our rich structure that's mobile doc, right? Shout out to the guys from 201 Created who put a lot of effort into making mobile doc happen.
20:22
If you're not familiar with mobile doc, it is a format for doing rich text editing on the web and on other platforms. It's mobile because it's portable to many kinds of rendering in many places but if we add the Ember mobile doc plugin, what we're adding now is a card stack field type and here I'm gonna manually go into my model
20:42
and add a new field called bio and I'm gonna say that it's a field type card stack mobile doc. Now I can drop that in to my template and the tools are gonna pick that up. We're gonna grab some markup so that it looks like the other one and I'm still leaving the old bio there because I want the content still so I can see it.
21:04
Right, so this is a good point to point out that there's this editor on off switch in the top and that's really important. It turns out in the UX of this whole experience because your content, you actually can still navigate your site while you're editing it and you navigate like a regular user, right? You're not away on some admin page
21:20
looking through a list of content. You're actually clicking links in your content to get around the site. So you need to make a distinction between when you're clicking to move around and interact with your content and when you're clicking to edit your content. So and here we're demonstrating a really neat feature that just comes straight out of the box with mobile doc which is you cut and paste HTML from the web into mobile doc. It actually maintains things like links and italics and bold
21:40
without taking any of the stuff you don't want like the styles and the colors and the script tags. So it's very powerful. Here I'm demonstrating some of the basic stuff it can do and also the fact that we've got a nice little navigator on the right hand side that comes up when you're editing that mobile doc so that you can know where you are in the structure of a document.
22:01
This is an example of a field type plugin. Now you basically already know how to make one of those because it's an Ember add-on that provides some components. There's just some conventions around how they're named so we could find them and apply them in these situations. So there's a, this one actually uses all three kinds of components that a field can do. One of them is the field editor which is the, yeah, the field editor
22:23
which is on the right hand side which is in the case of mobile doc just shows us a list of the sections. There's an inline editor that you can use actually on top of the content. That's what gives you enough room to do the rich text editing here. And then there's, lastly there's the default renderer which is what actually renders on the page. If you don't use the block form,
22:40
if you use the block form you can get the actual document structure and do what you want with it, right? But if you just drop csfield bio here we go find the default renderer component and put it in. So lots of power, lots of flexibility and now anybody who's shipping new capabilities can ship them as field plugins and do a lot with them.
23:02
So those nice blue boxes are another general purpose abstraction that's not tied to any of the rest of this. So check out Ember Overlays. They have a nice little demo that shows how they work. They have a pretty simple protocol that lets you, there's a marker component
23:21
that you put into your DOM that places where you might want to highlight things and there's an overlay component that can target those and there's a lot of options to actually get the UX right and get the layout right so that things can flow correctly to match the size of your content and can react to motion in the right times and the right ways. There's another very powerful little primitive that just falls out of having to build
23:42
those kind of ambitious experiences, right? So this is one you can go and use right away if you want and of course it's programmatic too so if you want to have an annotated tour through your application, mark up some locations, run a script, use Ember concurrency probably, run that script, to step through turning things on and you can guide people through your application.
24:01
It's very powerful. So up until now, we've been changing our model but we haven't been saving it because we don't have a server. So my little blue button here turns blue when there's things to save and we know our model is dirty
24:21
but if you click it, it'll just try to post to non-existent place right now, right? I don't have a setup. This is just, these are Ember data models but I don't have an adapter or anything set up and I don't have a server, right? And so if we think about taking Ember out of the box and making it something that you can just use, geez, we're really missing a server, right?
24:41
So that's part of the pitch here. The goal is to have a stock server so we're gonna Ember add cardstack-hub and cardstack-git. And so, and I'll go into the architecture a little bit about why there are these two pieces. It's because hub is a,
25:01
it's a general purpose server for fusing other data sources. It doesn't actually store canonically any data of its own. It exists to be the layer that bridges together every crazy source of data that your application needs into one place that can present a pristine, beautiful, standards compliant, conventions compliant API
25:21
out to your apps and do that all in a consistent way that follows the same authentication no matter where your data's coming from. So in this example, I'm installing the cardstack-git data source plugin and that uses, as a canonical store, uses git. It turns out that's an extremely powerful way to get going and it's actually, for a certain class of your data,
25:42
like your actual config and your schema and all the things that run your server, git is a great place for it, obviously. I think we appreciate when we're working in code, like we get why we would use a git-based workflow. It's the only way we're able to collaborate at scale to be able to keep track of all the things in flight on a big project.
26:02
What you find in a lot of projects that are involved with code and content and configuration is that there are a lot of rough, impedance mismatches between the folks who are working in the code workflow, the folks who are working in the content workflow, the folks who are, and the changes to configuration
26:21
that break one or both of those things, right? When everybody's not in the same world working in the same patterns, you miss a lot of opportunities. Both in terms of just the sheer efficiency of your project and the sharing of ideas and figuring out good ways, but also in terms of leveling up people across the team and across an organization. When we use Cardstack Git,
26:43
when we post data to our JSON API server, that's a command. We get to say what branch it goes on, and we get all of the semantics of Git to make sure that it can be merged safely with other things. And if things can't be merged safely, you already know how to resolve merge conflicts, right? And so things bottom out in kind of no worse
27:01
than the world you have now, but as we build up the tools, more and more of these things get to be surfaced through nice interfaces. And I've dropped in the bottom here some of the other kinds of backends. All of these are things we've actually already shipped with client projects and want to ship as plugins to the Cardstack hub.
27:22
The general idea of writing one of these plugins is they're not that hard, and the secret to it is that the hub is a fast cache for all your stuff. So your indexers can only have to be near real time. The hub uses Elasticsearch as its ephemeral cache store
27:43
of all, as much stuff as you can suck out of all your upstream data searches as you want to, you can throw into Elasticsearch. It's battle-hardened, it's scaled out horizontally. You can stuff an awful lot of stuff in there. This gives you huge capabilities to ship new ambitious things in organizations who think their data is just horribly locked up
28:02
behind legacy systems, behind systems that are too slow, too cumbersome, too hard to access safely, right? All that stuff is what the hub was designed to solve. It's just something that falls out naturally if you try to take on enough of these projects. You realize that the decisions on, for example, who can edit what piece of stuff
28:22
end up depending on some facts that are stored in some random SQL server and some other facts that are stored in some enterprise management system, and you've got to put those all together somehow right at the front end point where you're serving data out to the web, and you need that place to exist, and that's what the card stack hub exists to do.
28:42
So now that I installed that add-on, I'm actually gonna, first thing I'm gonna do is actually hit an API end point right on Ember CLI. This is my Ember CLI app, localhost 4200 like always. In dev, the card stack hub is an Ember add-on. It knows how to mount itself into the middleware of Ember CLI, and by default, it puts itself under the name card stack.
29:01
And so what I did right here is I hit the content types end point. Now, that's a little inception-y. Oh, I'm hitting my microphone, sorry. One of the things that I think is exciting about the architecture here is that this server is JSON API all the way to the bottom. In fact, the way you configure it
29:21
is you actually make a tiny list of seed models that are just enough configuration to go find where am I supposed to get the rest of my configuration, and everything is models that are modeled, you know, resources, JSON API resources. So your schema, your content types, your fields, what their types are, which plugins are activated,
29:42
constraint rules on your data, which things can't be null, which things have a link to them. Those are all just things that you can post to JSON API to change. So that means that you already know how to build sophisticated UIs that work against JSON API. You can build sophisticated UIs to control all this stuff, and that's the opportunity we have is to build the best CMS experience
30:03
anybody's ever seen. So the content types that came back here, there's like seven of them that went by as you watch the animation. There are things like grants, right? These are the rules about who can read and write what. There's the fields themselves.
30:20
There's the default values, things you can store that are just defaults in terms of like the user doesn't set a value what goes there. Data sources, this is your actual list of whether this is like which Git repos do I use in which environments, which databases do I use, how do I talk to them, all that's configurable here. So it turns out like this is not a framework
30:41
for writing server applications. This is an application, and it's got config to drive all this stuff and a really rich NPM-based plugin system to do the rest. So let's make the content type we need for our demo app, right? We have a speaker page that we want to be able to save. We need to make a speaker content type. So if you're familiar with JSON API,
31:01
this is just a very normal-looking JSON API request. We're gonna post the content type's endpoint. I want to make a new content type. I'm gonna give it the idea of speakers, and I'm gonna give it these fields. So we'll submit that, and it won't work because the point of this is more to talk about good error messages.
31:22
So it's saying I have a broken field reference. Speakers refers to missing field name. Oh, I guess I need to define my names before I define my content type. Makes sense. These are basically dangling pointers, right? The point here is that the good error message off an API server are incredibly valuable, and so everything is designed here to try to do that.
31:41
There's nothing more frustrating than just requests that fail and don't tell you why, and then you have to continually add and remove one property at a time and try to talk to the server and see which one it's mad about. So the goal is to not have to do that. So we can define some types. Let's make a name that's a string. Now you can actually see the field type here is defined in terms of one of my plugins,
32:02
Cardstack Cortice, we saw earlier. We thought we were just adding Ember components to do field editors, but it turns out that component can do, has server-side plugin capabilities too. This is the other kind of aha piece. We know all the good things that come when add-ons have a standard way of adding capabilities to an application.
32:20
Add-ons have a standard way to give you styles, to give you components, to give you services, all that stuff that you might need. Well, these add-ons have a standard way to give you server-side validations, deep text search indexing for your type, constraints, new data sources. So think about what you can do with Ember add-on that does that.
32:41
Think about if you run a service that is an API for the developers, how you can actually ship out-of-the-box experiences that used to take custom development for people to integrate with your capabilities, or they can just drop that into an Ember app and their server will now all of a sudden know how to talk to you as a data source.
33:01
Here we are making the mobile-lock field. Again, this is referring to the card-side mobile-lock plugin. We installed it earlier to get the Ember components. It turns out it has capabilities on the server-side, too. It knows how to validate the mobile-lock. It knows how to render it down to text so that the full-text search works within it, even though it's kind of a rich structure, it's not just text. We could do relationships.
33:20
We'll say the tags are belongs to. And finally, we could post our speakers and it works. So now we have an actual content type and we could post a speaker. We'll make the first speaker. We'll give it an ID so that we know what ID it's got and it's a nice short one. That's all you can choose to manage ID's how you want to. The out-of-the-box setting actually does use, basically get like shahs as its ID's
33:43
and that has some really nice properties when we're gonna talk about branching your site. But here we are posting, making our first piece of content and it comes back with a 200 and it gives me back meta, which is a standard JSON API feature that lets you have things that aren't standard.
34:01
And I get back very git looking shahs here for version and hash. And that's enough information there for me to be able to take this record into my application, manipulate it, send it back and let git do the normal git merge thing. It knows what commit I came from and it can actually do merges the way git would normally do merges. And as long as you didn't touch something
34:21
that somebody else touched, even if lots of other stuff happened around you, you get all that merging capability happening in your server. And if it doesn't work, you get a 409 conflict, which is kind of what you want. So to show off more of these capabilities, I'm gonna jump a little bit ahead and add some more of the capability by adding the card stack routing plugin.
34:42
So this is what you do when you realize all your routes are getting really boring because all they do is call the card stack content component and all they do is load a model that has a type and an ID or a slug. Basically sometimes you want pretty IDs. A lot of time sites are designed for that so the default out of the box thing here is searching by slug and a content type.
35:03
So you realize your routes are really boring and you should just delete them and mount the card stack routes. So let's do that. So I'm gonna import card stack routes. They're just something I can put anywhere in my router map. If I just wanted to route them under, say, slash C and have all the card stack routes there, I could do that. Or in this case, I'm gonna change my mind
35:21
and I'm gonna say, let's just take over the whole router map and just use them there. Now if people are familiar with Ember engines, you might say, this looks very engine-y. Maybe we could use a mount here. And I think that's a good idea. There's a few features in engines that I want to push forward to make that more of a possibility. What engines are really great at today
35:40
is helping you break up your application into pieces like a core app and many engines, all of which are authored by you. But to make a general purpose third party engine like this one as configurable as you want it to be, we need some more features that engines don't have, particularly around ways to essentially yield back to the application so that things like your components
36:00
can show up as content inside of these routes. So but today it's actually very simple. This is the whole implementation of card stack routes, right? All I'm doing is defining these core routes. It's actually five because there's always an implicit index route and we do use it. We use that good old reset namespace feature which means now we know exactly what our routes will be named no matter where you put it.
36:20
And we've got new content, content and default content and card stack. So you just get a very straight up boring on purpose set of routes that you didn't have to think about, right? But they come with a couple extra things. And so what I'm gonna show here is that the routes are sensitive to a branch parameter.
36:40
So your whole site can render taking a branch parameter that goes through all the API requests to the server and the server understands it. The git backend will literally use a branch. So everything that powers your site, keep in mind that's not just your content that's your code, your content, your schema, your config is all work.
37:02
So now you can actually on one site change any of those things, make a new branch, run the site with that URL and you have a completely different experience. And so now this empowers whole new ways of collaborating in teams, right? All of a sudden a developer and a designer or a content author can put their heads together,
37:21
make a branch, collaborate on it in real time and have something, have an extremely flexible natural workflow for getting that stuff in front of other people, getting their feedback, getting their input in their changes, and then getting it merged, right? So right now there's not a UI for doing the merge step.
37:41
But let's, so, and I'm gonna go a little bit slow and just point out some of the things that went by fast in the animation. So our site starts out in live mode where you're just seeing what's on the site. But when I go into editing, I have this particular demo set up to forbid editing on the live branch. It always sends you over to a draft branch.
38:01
And so in this particular example it's set up with just two branches, draft and live. But of course you wanna make a new branch, that's just another JSON API code way if you've got the permissions. So we're able to switch to preview and at first the preview content says it's the same as the live version, right? We know that because of those hashes that come back off of the server and the metadata.
38:23
So this is literally, we know it's the same because Git hashes that whole tree of data to the same sum. So then I go and make some changes. And when I save them, I've saved it to my branch. So now I have, now I've got this nice red color is there. It's intended to always tell you you're in preview mode.
38:41
You'll notice we're not using the word branch here in the UI. The whole goal here is to come up with sensible design to make this really approachable. So the terminology that we're working with tentatively for users is previews, right? I wanna make a new preview of the site. Let's collaborate on a preview of the site and then let's get it merged into the rest of the site.
39:00
So now we know we're different from the live version. I could still click over to the live version and I see that the content changes, right? I'm switching between versions of my site. Between the live published and the preview that differs from published. So I can go and edit some more things. And then I'll go look at my git repo
39:23
and I have the commits that I made. I hit update two times, so I got two commits. I'm not, I don't have any auth turned on right now, so I'm labeled as anonymous coward. If you look closely at the git, it's actually using git's features around tracking both the author and the committer separately because the committer is the server
39:40
with its process ID and its host name and the author is the actual end user who was logged in after they were logged in. And here's their changes, right? And you can see that what they changed is literally files in the repo that are JSON that is actually just JSON API, right? You can actually see the structure here. It's that, you know, this was speaker zero, right?
40:04
That's the type, that's the ID. And here's the attributes. And if there were any relationships, they'd be there too. So you already know this structure. You can dive right into this repo and debug something because it's just stuff you already know. So let's merge it to master.
40:22
And now when we come to our site, we're gonna see that the live and preview both reflect our changes, right? That was the, that's the workflow. Now it's the same as the live version. Great, so now, thank you, yeah.
40:41
So now we've got, let's do some adding and removing because we want the full CRUD experience, right? We want the create and the delete too. That's part of the pitch of adding the routes, right? There's a lot of little things you have to think about when you make all these routes. In particular, there's a bunch of transitions you have to think about in a situation like this. When I make a new piece of content,
41:00
I really want to route somewhere to do it. So I need, so that little button that says add needs to know wherever that I route to when I want to make a new speaker, right? And so by using the standard routing plugin and like this, you know, this component is able to just, this menu of what types do I want to add is just powered by hitting that same API we looked at, right? It knows how to look at the list of content types.
41:22
In particular, it's filtering down by the ones that are user-created ones, not the like stock ones. So I don't have the schema editors in here. But I can go and add a speaker and it's gonna take me to the right route which is my content new route and it switched me to branch draft because that's the rule on this site. You'll notice here that my field editors are showing placeholder content. That's another thing that all those plugins can do.
41:42
So the string plugin doesn't have any special behavior. It doesn't really care. And so the default thing is that it actually just renders saying enter and field name. That's kind of important because you'll see if you turn the editor off. Oh, I can't actually click on it. It's a video. Oh, I could use some sleep.
42:01
I do have a one-year-old, yeah. So if you turn the preview off and there's blank fields, you'll notice, you'll see there's nothing in them, right? They just kind of disappear. And so to know where they are, it's really nice to have placeholder content. So that's why there's a protocol for fields to do that. Something like mobile doc needs a slightly smarter protocol because a mobile doc has a structure. You can't just throw any random thing in there
42:21
and expect it to render. So the mobile doc plugin implements a hook that knows how to test is this content empty because it turns out an empty mobile doc doesn't look empty to JavaScript, right? It's still got pojos and stuff. So it can test if it's empty. And if it is, it knows how to render that placeholder content. And you can do the same. Think about doing the same thing for things like images, right? Making sure there's automatically
42:41
the placeholder image there is just a very simple hook in the image field plugin that you want to implement. All right, so let's add a new speaker, Jen, because she's next after me. Now, just because I added a new record, I'm on the preview branch. If I switch to the live branch, oh, there's no such speaker, right?
43:01
Not on live. It hasn't been pushed there yet. You'll see the routes are also doing this for me. They're letting me have appropriate error handling so that I can actually stay on the right URL. It'll show me my 404 page. And then I can toggle back to preview and say that actually on the preview version of the site, this isn't a 404. There's stuff here.
43:20
I can actually go back to my other existing speaker here. He's on both branches. But if I delete him off preview, I get this opposite behavior. Now on live, he's still there. But on preview, he's gone. So now when we merge this change, he's out. She's in. So this is just a lot of the tiny details that chip away at your mental budget
43:44
for thinking about an application, your actual budget for how long it takes to build, things that to the extent that we can find these shared solutions and extract them from real experiences so that they're really bulletproof abstractions that work for a large number of people, like this is the pitch, right?
44:01
We wanna work on these things together and get them really solid. So I've so far kind of glossed over the authorization authentication piece. So I'm gonna go into it a little bit with the time I have.
44:22
So I'm gonna take the two pieces separately because it's important to make the distinction. So the idea being, right, authentication is knowing who somebody is and authorization is knowing what they can do. So those are two separate concerns and they're implemented by separate parts of the system. So an authentication plugin is just gonna be something
44:40
that can literally tell you which user ID somebody is based on their authenticators. So OAuth 2 is a pretty solid choice to be able to integrate and take advantage of some of the existing stuff in the community around like Ember, SimpleAuth, Tori, to expose both to the server and to the code running in the Ember app,
45:00
like who is this user? Who really wants to spend another day working on that stuff in your app when you really don't need anything that special? If there's a few special things you need, great. Extend your type and just add a couple of few fields that are unique to you. The second piece is the authorization piece and this is where a lot of ambitious projects
45:23
in larger organizations stumble because it's hard to get right and because every system wants to have its own opinions about authorization and you really want to build a holistic experience. You really want to pull together everything about a particular customer, about a particular product,
45:41
about a particular experience that was important to someone. You want to pull them all from different data sources and put them all together. The user doesn't care what database it came from and so to build those fused experiences you really need a fused kind of server that has a holistic view across it. Implementing authorization is actually a great example of that because a lot of times
46:01
you know, nobody wants to go, especially in say like, there was a screenshot I meant to take which I think I tweeted it a while ago but it was basically a shaming of a large bank for having like nine login buttons on one of their screens because they had like nine enterprise systems that never talked to each other.
46:21
So you the customer had to figure out which one to click on to login. That's, nobody wants to be there. It's really easy to be there by default unless you do something. So the authorization system here is very deliberately built into the hub and the goal is that the hub actually has to be trusted. The hub, you give it credentials to get to all your data sources and the hub implements your actual end user authorization
46:42
and if you look at the stuff that's already published out there in the crowds.org it's got a pretty good personal limitation of all the right authorities for writing to content both at the content type level and at the field level. So you can have, you can define rules about having certain fields that people can't edit or even see
47:01
and all the things that might have pushed you to say I can't really make this stock. I have a little bit of something special. The goal is to not have to have that and that when you do, the way you solve it is not to have to sit down and like spin up a whole server. It's to drop in a new plugin and the pitch of that is it's gonna be easier
47:21
to do it in a plugin anyway and now once you've been in a plugin like let's share with the community and now nobody else has to do that one. So again, it's a very familiar pitch to Ember. That's the whole name of the game and so this is all about moving up that spectrum. Now, when we talk about the spectrum of small apps and big apps and small capabilities and big capabilities,
47:42
you know, we're talking about a trade off of course, right, we know that like more features cost more code and they're harder to build but there are some really interesting ways that you can cheat or like bend the curve and one example of that is that you can build some very sophisticated applications using this kind of infrastructure to manage things like your rich library of content
48:03
but because Ember's got such great build capabilities, you can actually, as the final output, spit out very tiny focused pieces of content to be seen by your end users. So one of the things I didn't get to in the actual videos is that we have the concept
48:21
of formats for your content. We were working in a page format so there was a speaker page and the component was named speaker-page but you can have more formats and out of the box, there's a card format as well so a speaker card is a card format that you can render among many in a grid or you can, you know, style it how you want. It doesn't have to look blocky, right?
48:42
Card really just is a physical analogy that users can really get a sense for. That card that renders out of there could very well be a Ember component, right? It could render out to a web component that gets embedded lots of places. It could render out to a Facebook ad. It could render out to a text message, right?
49:01
So this is not wedded to one channel. You really want the full powers of Ember plus Cardstack to do rich editing experiences. This is the area where Ember has already shown and we want to bring that to more people but the pitch is that you can also use that to then generate content that goes out all the way down to the glimmer end of the spectrum
49:22
and we have actual proofs of concept of that. If any of you got to catch Tom Dale's talk at Wicked Good Ember, he demoed a product that does that already and Monograph, and we're very excited to be reintegrating Glimmer into that product and also working on the Cardstack. So this stuff is all actually happening and it's very exciting to be able to push
49:43
both directions on the continuum. That's the huge opportunity for Ember. So wrapping up, some coming attractions. Most of this stuff actually is code that works already and it just needs the love and care to extract it correctly. Framework thinking is very different from app thinking.
50:01
You definitely need to take your time and do it well. But all of this stuff is going through the same process of the other things I already showed that are already extracted. So Cardstack search is really critical. I haven't really talked yet about how the goal of this whole system is to be 100% search-driven sites. But the point of that is that everything is really a search.
50:24
The more traditional LAMP stack way to build websites was everything was kind of an SQL query. And you can only go, and I'm a big fan of queries and structure, but it turns out what you mostly want on the web is much more fuzzy, much more rich ways of deciding how to rank content and where to put it.
50:40
And so having that full capability of anywhere you go on your site is pretty powerful. For example, if you got a feature request to say, let's make a sidebar with the top 10 featured products from today, you say, no problem. I'll drop in a Cardstack search component there. And as an input, it takes a query. And a query's just a field. And there's a field editor that knows how to edit queries. So now the owner of the actual product
51:01
can go and change their query as they want to. You don't have to deal with that anymore. So the goal is, again, to draw more people into the experience, get more interaction happening in your organization, get more people directly participating. You can give these tools out more widely, and everybody benefits. You don't really want to be the one who has to deal with the planning meetings
51:23
and the feature requests to say, can we change the priority of this slightly higher than that? Isn't it great if you can say, guess what, I built you a plugin, and now let you edit that directly. That's the pitch. So that's the Cardstack search feature. Cardstack models is the idea that
51:41
you shouldn't have to write the Ember data models for these things because you're already defining all their schema very explicitly. We know what their types are, and what their rules are, and what their relationships are. And so the goal is to have a build time step that actually just makes sure that you have Ember data models in your app. You shouldn't, the real goal we're driving toward here is apps that are templates and plugins.
52:04
And you only need to dive into JavaScript when you're doing something that's really special. Simply rendering a model is not that special, right? Being able to just, you know, how unique are your field types, really? Maybe you have one or two that you might need to write a plugin for, but a lot of them are things that the community has already written.
52:21
And so this is all about liberating those things that are already out there and making them work. Simultaneous preview of multiple content formats. So when you're actually in the experience of making content, it's really nice to be able to see the card form, see the page form, see the phone form, see the, you know, whatever your imagination brings to you.
52:41
That's a real easy thing to do, right? You may have noticed in the card stack content component, it just takes format as an argument. You can flip it, and all of a sudden your content renders in a whole new way. Ember CLI deploy integrations, right? This thing only works if people can actually ship sites on it without diving into the code. And that's actually a whole other art. And, you know, major props to Ember CLI deploy,
53:02
because in this community we've already got codified experience on best practices of deploying all kinds of stuff. And so we absolutely need to have deploy packs that will take this whole suite and just send it out to cloud. More field types, I talked about some of those already. More data sources, some of these are also ones I've talked about. These are some that exist, like we do have SQL server integrations.
53:21
We have a Drupal integration. Whatever, what is that legacy system that keeps you up at night in your organization, right? That you hope you don't have to deal with, right? That's the one that you really want to suck in through the hub, so that you can all of a sudden liberate that data and expose it to your application in an idiomatic way on a very fast API. All you have to do is make sure you can index it near real time,
53:42
you know, as best as your requirements dictate into the hub. And finally, Cardstack desktop. The goal of that is to make, you know, all these steps that I showed you, there was a lot of Ember add steps, right? Simply by requiring people to go to the terminal to do that, you cut off a certain audience who are just not comfortable with that.
54:02
We really want to get to the point where you can download a desktop app that is running all the same stuff under it. Ember Hearth is a great example of an early pilot of this kind of capability where they can actually wrap up Ember CLI in a desktop experience. We want to push that much further. A lot of the things that I already showed you dovetail with that, because the kind of things you would need to set up that desktop tool
54:20
are the things that already exist in your site. So it's a very fuzzy boundary between when am I actually like in my site, live editing stuff on the site versus doing it locally. Awful lot of things can happen right on the site. You're not going to add new plugins that way. Maybe, maybe eventually you will. Maybe you'll actually like log into your site, tell it to MPM, MPM install new things. That's pretty powerful.
54:41
But there's still things today that you would want to do locally, especially if you're going to do like, you're going to do wholesale changes to your search index, right? Like that's a fairly expensive thing to just do on a whim on a branch. So you might want to do it locally. And we want to make that easy to do. So, eye on the goal. Happy Ember devs who can add all these sophisticated things to their apps
55:00
at much lower effort. And it just works experience for a new set of users who today can't really use Ember, right? Today would be almost irresponsible for some organizations to do it. I had a great conversation with some of the guys from 201 Created where they said, you know we did a one day hackathon for a local charity and they were going to make a website for them. And it's like really hard to say
55:21
Ember's a good choice there right now because it is a little irresponsible because they can't, they don't have the people and the skills to go and take care of an Ember app because it's too hard today, right? So what you do if you have one day is you set up a WordPress app for them, right? I want this to be something that you could actually set up for them. That's the new audience, right? And it's way bigger than just small organizations because the Drupal's of the world
55:41
and the WordPress's of the world are up and down the continuum of size from national governments to tiny schools because it's compelling, right? More features is compelling. That should be kind of a tautology. And it creates a continuum of skills that gives people pathways to level up when everybody's collaborating in one project.
56:01
So it's critical that this whole continuum exists. It's the only way you actually get one of these ecosystems rolling. When if you build a tool that's just for newbies and it feels too much like a toy and all of us in this room don't actually use it, you never get the plugins that make it fly, right? Software is fundamentally hard. This isn't about saying if you won't have to write software anymore
56:21
it won't be hard. Since like when Fred Brooks wrote No Silver Bullet in 1986 we've known software has essential complexity to it and that there's things that are always hard. So even though we try to whittle down the accidental complexities as much as we can there's a limit to how far we can go. So that's why the only cheat
56:40
around the No Silver Bullet problem which he also pointed out long ago is reuse, right? The only way to go farther in software is to have many of the pieces you need already there. And so that's the name of the game. That's the only way we over the long run make software empower more people. So it's impossible to ship all this ambitious stuff without you. It already would have been impossible
57:01
to go as far as we've had and thank you to everyone who's contributed to the hundreds of individual projects that make all this possible. We need you still and we need more of that so if you're excited by these ideas come talk to me. We've got lots of interesting stuff to work on. Let's empower the next million creators. Thank you.