 Hello everybody and welcome to a fireside chat with two leaders of the Ember project You who the cats and Ed Faulkner. My name is Lea Silver. I am on the Ember core team and one of the folks working on Ember comp And we're so glad that you could join us today If you don't have your ticket yet for the 19th go ahead and grab one at Ember comp calm There is a ton of amazing content headed your way and we're excited to see you there Today, we're gonna hear from Ed. We're gonna hear from you Huda and they're gonna talk a little bit about What happened in the past what's happening in the future? and some of the thoughts and conversations that go on behind the scenes to Help make ember what it is today and what it's gonna be in the future And so with that I'm gonna hand it off to you two folks take it away All right. Hello. Hello Nice to see you. Yeah, yeah trying times Yes Do you want you want to start by telling me what you're working on today and lately? Sure So right now I'm still working on the keynote, which is basically all Polaris all the time, which we should talk about I am also the other thing I'm working on in the background is a project called star beam, which Is a funny thing. It's it has two different stories depending on which audience. I'm talking to I'll start with the ember audience, which is you. Hi guys. Hi ember in us The ember story is that it's basically like glimmer 2 or it's like glimmer 3 in the sense that it is a extraction of the reactivity model From what ember does right now to make it more general make it less coupled to ember specific details and in general to take the lessons that we learned from from ember and Reenvision some of the details The that always sat whenever I say that the first time people like I don't understand what the point of any of that is The point is basically that but the process of extracting something into a more platonic the ideal starting point Helps clarify some details and in particular One of the things that we really get out of this is a better a starting point for a unification of all the APIs the helper API Class-based helpers modifiers all those stories that Resources that which are coming all those stories have slightly different APIs or very different APIs There's third-party packages that have yet even more APIs, but they all are really talking about the same thing Which is it's a reactive Computation of some kind that has a value maybe has some cleanup code or something like that and there's no reason for them To all be so different The good news is ember has some we have a manager Pattern in our architecture, which allows us to like not have to care if we radically change the API surface And that's how glimmer components was able to exist So that like that means it's not a big deal in some sense on the other hand. It's like really I've been working on it for like three or four months now and We have gotten to the point where it really works like I've this morning I was like for a few minutes was writing Database library like a like not ember data exactly but more like a redux flavor like ember data library Just built on the primitives and like all the tests are just passing right and so it's it's basically a Update of what and of what glimmer tracking is to encompass more parts like the modifiers all those parts of the story And also encompass set up and tear down in a way that Is is more rationalized. That's the ember story The bigger picture story is that unlike glimmer where which was really focused on just that part of the story The star beam story is really focused on trying to make sure it really does work in other Ecosystems that doesn't mean that other ecosystems are going to be are going to be prioritized over ember I and I work on ember and I care about ember and that is like that most important thing but maybe we'll talk about this later a theme of Polaris in general and which started from octane is Figuring out how to make the stuff that we use stuff that everyone else uses, right? So we're where glimmer in some sense glimmer can't really be used inside of react except as like an iframe, right? logical iframe It is much easier to imagine using our reactivity library inside of react But there's a lot of details and so part of the work I've done if you look at the repo a big chunk of the work is like actually getting things to work with react React has a lot of like as weird strict modes It has like react will just randomly run your teriton functions at unknown times and a lot of different hooks and stuff like that So figuring out how to model directivity model in a way that would feel natural and react is just a project and we're gonna do the same thing about for view and for Svelte, I think Svelte when we start doing next week The we is me and Chirag and Tom Tom who worked on me on ember with me in the first place And Chirag who has been like behind the scenes glimmer contributor for a few years So we're like we're gonna start working on Svelte Svelte compatibility next week and just the general idea here is We want to be able to say just like we can say about package V2 Which we often ask you about in a minute like just like just like we could say this is something that makes sense for everyone to use The star beam story is like front loading in some sense the MVP includes it really does work It really does fit into the reactivity models of other systems and one last point is I Have a I now have a pretty like I care for this is like my non-academic academic project is like understanding reactivity better And I think that star beam has closed a lot of the gaps for me in like explaining What is reactivity and and we actually want to make we should talk about this as a dedicated topic soon But I'll just plant a seed which is like there's a meme going around that like react is not really reactive And I disagree with that meme and I think I would talk about it. Mm-hmm. Yeah, okay. Yeah, and I have plenty of questions I'd like to ask you every activity. Yeah, I mean like so Sounds like this is a nice attempt at standardizing what what we need for you know, not just You know Reactivity goes beyond a function call right like a function call has a beginning and an end and there's a return value And then you're done reactivity goes beyond that and enhances that to something that has Has incremental update right and that's really important foundational piece of what it's got when I think about a standard like web components I feel like that's the missing piece right for people to actually like use web components in anger They need reactivity that isn't there in the standard or any kind of data flow that is not based on strings I think like there's just no way to pass that around the web components Yeah, you can build a thing on top of it that lets you try to do that for web components themselves only let you pass values as strings Or imperatively there's no the desired way to pass that up exactly, right? So it does seem like a gap in Like just like broader ecosystem whether de facto standards or formal standards It seems like a gap and be great to close. I think I would I want to reframe what you said about incremental updates a little bit. Yeah, which is I think I think that This is an ember innovation, but I think it is applicable broadly a better way to think about it Is that you have input Input storage mutable input cells or something like that like think about the Excel model right in Excel You have a spreadsheet you have some things that are just like cells You're allowed to edit and some things that are formulas that you can you can change the formula But you can't you shouldn't edit the formula, right? And that whole thing I call the data universe and that's so implying calling in the keynote and that that data universe has no Tear down there's no clean up there The cleanup is the garbage collector and also there's no output other than like you could ask what the Values of the formulas are and the reason I'm gonna say what the other side is in a second But the reason I'm putting the cut there is that the data universe can be understood without understanding reactivity at all because Like you how do you fucking look at a value to ask for it? Yeah, and the value should just be the value, right? It's timeless, right? It's it's time for you programming. It's purely referentially transparent Exactly. That's what functional programming means, right? So that's what people mean So that's like the data universe, but then there's a problem which is okay Well, the output is not a person the output is a thing that needs to be kept up to date and We what we if we don't have reactivity an answer to that question This goes back to the old backbone spinning circles demo a thing that you could totally do is just like keep Executing the program every single time and every single time you execute the program to get a new dawn and maybe do some tricks there but that Sorry, so that that's like That's equivalent to what the reactive system is doing other than it like breaks your selection state and stuff like that however what people mean by reactive is that you're doing better than that somehow and In like in my opinion the way you're doing better than that is that you you your data universe is described in terms of mutable cells and it's described in terms of formulas or computations and then you You have a declarative system for saying how to take those computations and turn them into output nodes, right? So the out in my work my reactive model output is a very important thing. It's not just it's not just a It's it's first of all, it's not an effect. It's like a lot of people model Oh, it's like it's so different than console all along. It's not that I think if you mall as an effect You end up having to do a lot of work for no reason, right? so it's an output data structure, which is the Dom is is something that is semantically equivalent to polling the all the inputs all the computations that need it but also doesn't do doesn't do that and Is declarative, right? And I think in this case JSX counts as declarative, right? The declarative means it's it's you say the what and not the how and in this case The what is what it should look like in the output and the how is how you get from state to state And JSX is a perfectly good answer to that, right? So if you look at like so that's the model if you look at JS React, right? React has used state and use I'll just say you stay and use reducer are Ways of getting beautiful state and then there's like you could either write computations or you can use use memo to make like computations with the invalidation rules and then the output is JSX and The framework like in all I think every single framework works like this But the framework is modeling. How do you take that declarative system and actually turn it into an incrementally updating Dom, right? The the important the reason I said I want to quibble here is that a lot of people think of the computations in the middle as the same thing as output Right the computations in the middle you could literally remove It's hard to do it in react and this is a design principle of ember in ember The rule is you're supposed to be able to remove the annotations You can move that track if you had a unit test on that class Everything would work because the unit has can't actually be an reactive output The unit has can just ask what the values are of the computations and you use getters or use functions or use methods or whatever, right? And so that the annotations are a layer and on top of a normal functional model Yes, which might might have to use classes. That's like a confusion. The fact that class keyword exists to me It's not it's that oriented, right? You're you're using functions and methods to get data You're not using them mostly to mutate things when you're not knowing that right? so so so there's that basically that and Then there is another part of the system, which is an output data structure that that is Logically doing what the unit has is doing but it's supposed to be doing it automatically in a way that is imperceptible to the human being Right and that is an interest that is a different thing That is the output data structure and the reason I'm keeping on hoping on this is because it really narrows down what that has to Do right in like for example solid jazz just said everything is about Right and that means that even the output data structure is a very generic thing whereas In when I did all the the analysis in star beam the only effect that like everybody ever talks about the effect is log Right log is and it log is a special case. It is an ember also the reason log is a special case is because Normally your ski it doesn't what happens in between state transitions doesn't matter Right normally if you go from a to b to c Yes, you're allowed to like we have I think old action in ember and we have something like that in star beam Which is like when you click on something you could just make a lot of mutations You can look at the output right away react doesn't let you get up a ember and star beam do right? You make a bunch of changes if you look at the mutable cell that you mutated it's changed That's the that's the unit test rule, right? So you you did all that and then I'm losing my own trend but Basically you you you have these actions you mutate the data universe right and then the Then you then at some point that the thing has to be updated that has to at some point There's been a lot of transitions in between right you get a lot of mutations But none of them matter and this is also a thing RxJS doesn't handle that well Right, like you basically any stream-based thing is seeing all the intermediate states whereas this is saying Accept for the output the output is eventually going to reduce all that computation down to a text the string Because the DOM is made out of strings, right? So except for the output we don't care about intermediate states and that the all the reduction of all the things that you did in between into a type of string is a very epic reduction right and Log doesn't want that. Yes, right. A lot of actually wants to be seen All the implicitly point in time. Yeah. Yeah, I mean I think You know functional programming gets a lot of it means a lot of things to a lot of people It gets a lot of cultural cache because I think there's a certain stage in our development as programmers Where it's extremely appealing and it looks like a silver bullet to a lot of problems Well, I think just be more explicit about inputs and outputs that were caught the bane of your existence is a thing That's I find it exactly. Exactly. I mean like I think Excel is a really instructive model that I use as a strong analogy a lot of The time it's definitely the most successfully broadly accessible programming environment in the world And there's a lot of good lessons there and it's a lot of it comes from it being timeless And yet you can't sweep under the rug though that problem of in like as soon as your program meets The real world you can't be timeless anymore. You have to deal with Mutation and like there is just mutation in the world. You you are not copying your computer every time you write a bite It's it's mutating something right? I mean you can literally make an Excel UI in either Ember or star beam That is literally like a tractor a of tractor is and like renders and it will be fast. Yeah, right? I think that's like a notable. It's pretty cool. Yeah, right I also Very last thing I want to say on the this topic is that I think the life cycle has caused a lot of confusion in that In Ember react and everybody else is like 10 life cycle methods or five or whatever and it makes it seem like they're all equally important The there is really only one that really matters which is to clean up and that is in my opinion, that's why hooks are successful is that they give you a way of composing clean up and That that is like one of the last frontiers for me is Making us is like making the reactivity system able to handle clean up because the thing That's important about cleanup compositions. You have to link things together, right? Normally the garbage was good enough, but now you have a you'll need to tear down a website or something So you need to connect that thing to something that's gonna get torn down Which is probably component and that thing needs to be connected to a parent component, etc And glimmer does that already but making that more generic So it's not coupled to like the glimmer template model is important And I think if you go back to the Excel model that would be imagine that you could have a type of cell That's like a Web socket or something, right? So the cell is actually getting its data from Web sockets Yeah, that has to be implemented as something that sets of a Web socket if you delete that cell you really want it to tear down Yeah, yeah, I think connecting this back to like day-to-day experience of ember developers I could think of some very specific examples to relate it, which is that You get so much you get so much nice reactivity when you do things in templates that sometimes sometimes we don't have a way Historically to always dispel the same reactivity in JavaScript and it causes a disconnect right you end up Not being able to slice your logic between HBS and JS exactly how you would have wanted to because the reactivity story Wasn't always unified right and I used to have a slide about this point in the keynote Like making it easier to refactor and it is in the Polaris sketch document that is gonna eventually become the Polaris RFC But it would just it ended up being like at some point you have to it's like all object oriented hierarchies You have to figure out how to slice it and it was it didn't end up being a slice that yeah the flow But it's an important point that right now exactly like there's not a good way that it refactor easily between those two Context and like goal for us is to close that gap. Exactly. Exactly. Yes, spelling out the you know It touches on other other areas that are interesting to me and exciting We know like the glint support the really first-class typescript support All of that really requires us in a deep way to rationalize What is the type of the things we say in the handle of our side way, you know, all the things that you can invoke in a template Where is that what's their commonality? What's the shared signature? How are you model and once you've done that work? You really can model everything as you know that you're unifying the worlds, right? It's not a hard split anymore and I think people think like people very superficially tend to think that Well, like JSX just has a JavaScript expression here and handlebars doesn't so like what is that what does that mean? and I think like ironically handlebars picked a much restricted subset in intentionally to make it map very nicely onto simple JavaScript expressions and not to allow you to do things like X++ which wouldn't make any sense in a reactive context So it may be in the perfect world We would have a subset of JavaScript that you could use there that doesn't include things like plus plus or Simon Expressions But it's just not that hard to map the the template expressions the parentheses syntax onto JavaScript calls And that's more or less what we have done with Like both template tag and being able to put helpers in line is just like making that mapping explicit And that and the glue to space is like between all those things the rubber meets the robe yet We don't have a lot of spaces to hide cheats anymore. Exactly. Yeah. Yeah Yeah, I got I got to definitely use glint with all of the latest In an actual project to where it was worth it to kick the tires on that on that stuff and it was it's great I've also been we turned on the You know just little things also like turning on the polyfill for Like help for having a helper manager playing functions. Now. It's just very it confuses very elegantly Yeah, I think it's also worth noting that like one of the things that's nice about the manager concept Which is basically like a helper is like The union of all the help for apis and all of ember, but there's only one that exists right now That system allows us to do things like just turn functions developers and have a good like it doesn't require huge changes in the whole system It requires Having a default helper manager. Yep, but that's the whole architecture of that and I think that's exactly nice Yeah, exactly and the implementation story works out nicely then right like it was all it was all straightforward to implement third party and Yeah, you don't have to go into glimmer vm and do anything right exactly exactly. That's yeah, yeah Okay, I should ask you about embroider. Sure. Tell me about embroider. Yeah. I mean, so that's definitely my open source focus Embroider's come really far. I'm really happy with how the level of contributors we have now and the level of apps adopting You know embroider is the next gen build system for ember It's really a It's a it's big. It's a big project because we really are doing a Kind of push and pull me in the middle thing here. What I mean by that is We were we put a lot of work into getting as much compatibility as is as is reasonable But there's at the same time the whole point of this is to get the ecosystem onto Better patterns stricter patterns. And so there's a bit of a give and take in terms of inverter adoption And like It's always pretty fascinating when I get a new app adopting the kind of bugs that we find right away Stuff that you just missed because like the older system wasn't as strict and now you're dealing with more strictness And you get immediate feedback on things that were missed before Things like what kind of strictness do you mean? Well, like for example Some of it is the silly stuff like for historical compatibility reasons. Um, you can mix up your module import with your default import and get away with it in the classic build and All of a sudden inverter starts pointing out all the places where you violated the module spec, right or um, you know even just stuff like People using patterns where they're deliberately mutating a module from the outside And that's a spec violation But inverter will catch that Yeah, so, you know stuff like that where there's definitely I say it it's a give and take because purely as an as an app author if you just like wanted to try it out all of a sudden It's telling you there's all these problems and it seems like why is my app broken? Well, it's it's really trying to help you get onto standards get on to stricter patterns get more correctness And all of that is in the service of letting us analyze and optimize the app much better Right, that's why it can split all your code on the routes and all that sort of thing So can can you talk a little bit about the difference between? The Inboarder used as a as a drop in replacement for embersialized current bundler and the strip mode approach sure Yeah, so we definitely the way we have it set up is when you just install it and follow the instructions in the read me you're starting out in the most compatible mode that we've got and um That covers an awful lot. It's usually not too big a stretch for apps to adopt Um, because we've we've tried pretty hard to keep a lot the lot of the legacy behaviors behind Do you think by the time Polaris you think by the time Polaris lands we will be able to Close enough of the gaps that we just say that that's the default mode the compatibility mode is the default mode for everybody Yeah, definitely, uh, that's my goal is to get to there. I mean, there's just it's a consensus thing, right? We have to um, like go through the process Get every like get all the legitimate feedback from the community We've we've done a few rounds of that already like there was an rfc saying Hey, let's make this the default for new apps and there was some good feedback there and We could look at that again and say how much of that is addressed and how much of that is in scope or not Um, there's gonna be a definitely a long tail of add-on behaviors that are not going to come across um Some of them are just things where you could spend more effort and get compatibility Some of them are just like things we have to say are a bad idea. Um What's an exact what's one example of that? so um A big one that people hit is the um, there's a there's a hook in broccoli that add-ons like to use the post-process all-tree uh, which effectively lets them rewrite anything at all about the whole application at the end of the build, right and um When that's in so for one thing We can't really give them a backup compatibility over on that because the app doesn't look the same anymore The the input that hook would see After embroider has built the app is different because we don't generate exactly the same output anymore That was all implementation detail that was kind of a bad idea to rely on uh, and the kind of thing I mean by implementation detail is that like There's the assumption that there's going to be one file called vendor j s and a file called your app jet j s And that's exactly where all the JavaScript is and it has this very fixed relationship The whole point of being able to go to birders. You don't want that anymore You want to be able to dynamically split code. You want a way import to work You want all these modern JavaScript features to work and if that's true You can't just assume that you know that what exactly what all the JavaScript bundles are right There's got to be a bit more flexibility there At some point in the future we could imagine having like an optimize a pluggable optimization step that people can implement But that's like very has nothing to do with the thing people are doing now right like you can imagine having a Way to plug in something that actually sees some representation of the tree that we did standardize At the very end. So like for example, maybe you have a css optimization step or something Sure. Sure. Yeah. I mean, I think you could design a new step to satisfy that. Yes, exactly And you would want that to be you would want that to be happening at the chunk like the per route level You wouldn't be like the definition of what is the whole app actually has changed and stuff like that Yes, exactly. Exactly. And you'd want that that step to happen before the final bundling right the final the whole app optimization What you want it or just an example another is that embroider really because of the Because of this the embroider really goes all in on html as your entry point. So Historically, it's just very implicit is what are the pieces of an mbr app and how do you boot it? It's like You just expect that your build is going to spit out a certain couple of JavaScript files that you then are responsible for Putting in script tags in your indexed html A way to think about this is the when you write app slash indexed html in an mbr app classically That file is when it addresses other files like you know script source equals It's addressing output files of the build and whereas every other kind of inter file reference you author in your app folder is an input file Right, your imports in your JavaScript are all talking about input world of the files I authored And they're not talking about output world of what chunk did it end up in or is it in vendor js or not That file wasn't consistent. It's it classically. It talks about output world I really should be talking about input world, right? So if you think about Expressing an app that way now we don't need to have any implicit knowledge about what is an mbr app The rule literally is here's some here's an html if you executed it following the browser standards That's the mbr app, right? So it's for example, like I think we haven't formalized yet and published a v2 app format Like how will you author an app completely natively with no compatibility of accurate story? We've been focused more on the compatibility story yet, but that native Embroider experience you expect to see for example in your next html, you know script type equals module src equals dot slash app js, right? Like Logically, that's what you're saying. You're you're expressing the intent Run my app here. And then what about app.ts? Sure. I mean, I think that would be acceptable to say that That's not a browser thing. How does that work? Well, I think that in practice every and whatever build tool we adopt And a big piece of embroider is not tying our mbr architecture to one but to make it so that we are able to express our apps in in standards ways Whatever final bundler JavaScript based tooling you're going to hand off to I don't think any of them can really take off today if they don't have a story of script support a story for You know extensibility. So it's true that You we want it's deliberate that we want to be able to lean on that Existing ecosystem investment for these kind of tooling right like for example, if we had to have the story of if us and our ecosystem have to do like You know an order and work to support and popular things that are out there That's expensive and bad. But if what we can present is An api that is almost entirely expressed in terms of standards and de facto standards an example of the de facto standard would be something like node modules resolving Then when it's time to do all of those integrations all that glue work, it's not ember specific glue work, right? Is it correct to say that there's basically two options for index ts one of them is It turns out that there's a de facto standard that a directory containing ts files does something and we'll just therefore it's fine to treat that as the As the output format that we're going to hand off to The bundlers that we support and option two is It turns out that that's not true. So we need to do a ember specific pre-processing step first To turn ts into js and then we end that off to the bundlers, but we would prefer not to do that We would lean in the direction of doing the first. Yeah, we'd lean in the direction of the first one Right. I think because that's where the sweet spot is in terms of Getting the most bang out of the rest of the java scheme, but for example handlebars templates have to do the second one Yeah, although even there, right? I think if a lot of the refactoring we've done to make embroider happen Makes it much easier to implement The handlebars pre-processing under multiple different environments, right? Like the classic way it's done is deep inside of a bunch of broccoli transformations that are hard to translate logically into Okay, we'll now do it invite and now do it beat and now do it in webpacker and now do it in snowpack Whereas the transformations Embroidery uses are much easier to just drop into those contexts because they're aligned with that way of thinking like effectively Customizations, okay, like going I'll say two things about extensibility. One is that It's really important that it's an app author concern And it's not imposed on app authors by the ecosystem of their add-ons. So for example if If every add-on gets to bring its entirely own custom build tool Then you're never going to be able to like evolve like or if it If one add-on use webpack and one add-on use roll up and how do you make it app? How does the app do any kind of optimization? Exactly exactly And that's not to say that some at some advanced add-ons that want to offer build time integrations won't like if you Want to do a fancy stuff you may very well be Expected to Offer your user some kind of utility that makes it easy to plug into the packages that you choose to support right like Trying to be completely agnostic There's certainly like we can keep pushing in that direction to standardize things But I but I think there's a there's a difference between i'm trying to do something in webpack and I have a transformation that is a one file at a time transformation from the hbs file to js Which is like really every logically every single correct bond there supports exactly exactly so and that's what that's kind of what I was going to say as the first does the second part so the first part was You like extensibility and customizability of the build pipeline is okay But it's an app author concern that you don't want to get imposed Imposed magically by the the add-ons because otherwise it's very hard to evolve it and the second is Is what you were saying about like thin transformations, especially file to file transformations Very like are much more low stakes and not a big deal right because All of the existing stuff that's gets popular Kind of has to have them and nobody can really get popular unless they have a story for how they're going to do these things Because if you can't You know if it can't compile spelt templates and it can't compile jsx and you can't compile typescript Nobody's going to use it So like it's just expected that like loader as a concept not necessarily anyone any specific api But like you know rollups api versus webpacks api But um the general concept of just like what do I do to this file to make it be a javascript module? It's like a thing that takes an entry point and then like uses es imports to Follow the next ones and then uses whatever you configured it for file transformations to process them Exactly, it's it's there's a relatively natural interleaving point there of like okay. I've decided I want this file Please give it to me as a javascript module right and that's I think that's a low stakes spot to allow customization at the level of apps So people still get that it's just that we don't want to You know what we have today is much more that every single add-on package can just Have a completely different idea of how that happens and bring their own like you know add-ons Today when I say today like there's plenty of v2 add-ons already the classic add-ons Um They aren't really libraries. They're programs that emit libraries right and we would like them to just be libraries so that they're much more amenable to Tools that understand javascript Yeah, it seems to me to correct me. I'm wrong here. It seems to me that the ecosystem has been evolving a lot towards Isolated module like what types you call isolated module mode in the sense that I think a few years ago It was pretty normal to have tools like typescript that would try to do fancy things between modules But that intrinsically is hard to Plug in the way that we're describing so every bundler has to do like pretty complicated things to support For example concy enums and typescript Again, correct me if I'm wrong, but it seems to me that Everybody has moved away from making that mandatory and more and also eco the ecosystems have been Shying away so like on balance a type 2 developer is less likely to use concy enums now And more likely to think that it's a good practice to use isolated modules mode Then before and and that means that like the One at a time plug like Plugging plug in story is pretty viable. Yes, exactly. And I think it is definitely a trend across all javascript I think it's pushed. I think the web standards themselves are pushing it right because I think I think everybody who works on es module handling systems is aware that like browsers do more and more of that natively now and it's nice to lean on that when you can and once you're doing it in browsers You know, you're not gonna you're you're you've given up your Your control over the big Graph traversal step, right? You can still you can still do one to one stuff and there's a bunch of strategies for that and You know One is that if you just have a web server that serves files that go through a thin transformation one by one When they're asked for and use and the browser is the loader that does all the module traversal You get that's your demo from last year's. Yeah. Well, I mean, that's like the that's like the beat snowpack story And then I mean I would In my what I took it to last time that I demoed and I've gotten to push a little further on some of those kind of things I'm I'm still I'm still very bullish on service worker as a dev tool. That's 100% Yes, as you know, that's the next piece, right, which is not even having a web server but having a service worker and now you know, I just um put together working on some Some spike ideas the the the project where I was using glint and all of that nice new stuff I implemented All of glint and the compilation it needs in service worker so that you can like interactively make Gts and gjs components and run them in the browser And edit them and edit them in a monaco editor and and live preview them You know, I think the critical thing there is If you want to run stuff in service worker, you are going to get requests one at a time And and you will need your transformations to run in universal JavaScript. So you need you first of all can shed all the ecosystem That is forcing on you Whole app transformations other than for an optimization step, right? It's still fine to do that But you don't need to do it. Exactly. Yeah, and then you you also need to Make sure the ecosystem isn't like we're too listening relying on fs or something. Yeah, you definitely still find quite a bit of that Yeah, right. I mean that's that ecosystem is a is a good it's a natural consequence of all this and hopefully will happen Right, right. Yeah, and it's not it's definitely getting easier You know, it's like I think not the ecosystem wants to support it even though they don't know that yet totally Yeah, no, I mean, I think it's I think it's getting on more people's radars and in like the general you gave the example of typescript Using isolated like per module compilation more. I think another example is just how I think The sass community has recognized that they need to go to sass modules Not the classic sass architecture and I don't know if you've followed that story, but it's it's a similar story, right? It's that Classically, I followed it but I'm very confusing. I yeah as a user do not know what's going on Yeah, so like classically sass is a bundler, right? It wants to do the its own traversal of all of the sass modules and Effectively do a build its own parallel build of all the styles separate from the application and That's really intention with a world where apps are You know automatically sliced and diced and delivered incrementally because you really do want You want your styles participating in the same dependency graph as your code as your javascript And the the classic sass model doesn't really do it that way, right? It's a whole separate build with its own graph traversal and if you try to use that mode and Like actually build separate mini entry points for all of say say every component getting its own styles And you're going to treat those as separate entry points sass will do very bad things if you're using the classic mode if you adopt sass modules It works more like he has modules where you can express dependencies on things and like common dependencies won't get duplicated they'll be split correctly and so It's another example. I think of the trend and It's there like it's a If your dependencies haven't adopted modules, it's you know, you got to kind of push them to or wait for help could help them to Because today it's not always easy But yeah, it's another example Okay, I think if uh We've been talking a lot about typescript so we could maybe move on to talking about typescript Which is another big theme of all the work we're doing it came up in both of the things we're saying Yeah, yeah, definitely So, what do you want? How do you want to talk about it? Well, yeah, I mean just like I guess I'd say the high level Kind of filling people in on the basic story of where like what's been going on lately because we did just merge Successfully get consensus on a bunch of useful rfcs around typescript in ember as a first-class thing um I think that um like it has worked in ember for a long long time, right? Ember CLI typescript is very widely used. I think it's like one of the Kristen had a talk last year at ember conf about tilde already Migrating to using it and successfully by and by last year. So yeah, this is one of the top add-ons Yeah, exactly. And so like people have been using it. Um, I mean typescript I think is popular for good reasons I think there's a lot of benefits typescript if people are um, You know unsure it I would say it's worth investigating your time into learning. I would also say like don't panic It's not mandatory. Um, like uh To something you said to me earlier, uh, like I think we are careful to design javascript apis first and type them And that that is really that is really the typescript model of how typescript thinks about the world is that It takes takes your javascript apis as they are and then explains them and as opposed to saying we're going to make a thing That's like where the javascript is a is an implementation detail and it's I think it's worth saying like people have experienced typescript through typescript users a lot And not as much through the typescript design designers themselves. I think it's worth saying that And therefore you experience a lot of like you are doing a bad thing you like for example I would never tell someone that they should make their development server not run not run the code if there's red lines But it's like super common thing and in fact it's super common for people to ask the question of How do I run get blocking the build my depth server shouldn't run? Is like a common thing the answer of course is you shouldn't do that You should strip types in your development server You should run it in the browser and your editor should give you red lines And also you should have ci and test it For me, right? But it's super common for people to want that because they're used to like the rust or java model And it is not a coincidence that that's not required in typescript, right? Basically typescript has a bunch of design decisions including you can run the code when it's it's Has red lines including That a ton of investments they made in making things like add event listener taking a string parameter do something or object that Assign or object that entries is like possible to make a type for that Those are things like rust cannot even Where it says that rust in high school whichever advanced type systems like really can't even dream of The that kind of thing because they they just said string literals are not important Right. We don't need like we have a very advanced type system, but we don't need to care about string literals and Um, that is the impossible You cannot do that. You can't write the dom dot d dot. Yes If you have that opinion other than by making it you like you let to be put a very fine point on it You really want um some element that add event listener Uh submit so form that add an listener submit take an event that has the form on it Right and the only way that that works is because it knows that the submit event is a special string That does something special, right? Yeah, and so there's a ton of work like that that typescript has put into Modeling javascript apis and and that's it's not just for legacy compatibility reasons It is to enable people to make javascript apis first that makes sense to javascript user and or idiomatic And not don't have a bunch of extra stuff That is just for typescript. I personally I find that a lot of other ecosystems there's a lot of ecosystems that Don't care about that and they end up doing stuff like making you write type assertions everywhere the angle brackets You say like use foo angle brackets some type Instead of trying to make the inference system do the right thing and in general the typescript inference Inference system is very powerful and with a little bit of Your javascript pad on you can figure out how to make an api that feels nice in javascript and gives the typescript inference Or enough information to do the right thing and in my like if you look at my tests for any Apps like working on the typescript is almost no types in them because the inference or is going to do a good enough job um That another example is like can there's like the Asserts and the predicate functions where you can basically have a function that you call and it tells typescript This is a this is an element or you have a function that calls That tells typescript i'm going to throw inception if this is not an element right and then typescript can just care about that right so these are all Details that you could fit into your api design and typescript wants that and so like in the sense that typescript has But probably like the vast majority of the work that typescript has done in terms of brainpower has been to enable these kind of things and therefore I think it is That's the right way to do it and so Basically all that is to say to a job if you're a javascript user who is not yet using types and you have not listened to Ed's exhortation that you should look into it. Um, you still get a lot of value out of the fact that the types exist and I didn't make that point yet. So there's first of all the the first Point that I have been making is it doesn't it doesn't make the api worse intrinsically you have to do work But you should do that second of all why you should do it is because javascript They have also done a ton of investment into making the javascript language server In vs code and other editors use typescript under the hood Which leans on the fact that red lines aren't breaking the build right so basically Yes, we might not have all the information in javascript and you might not even get red lines in your editor But if if you just may say like document that create element div or or or form Then in a javascript file typescript knows or job vs code knows Without any kind of type annotations at all that that is a html form element And if you say that thing that add event listener Submit comma and you make an arrow function with an e Tab completion on that e in a jas file in vs code without any special added anything Will know that it has e dot form on it and stuff like that Yeah, so yeah, basically that is like a huge that is a huge investment that they made That is not like a thing that falls out of having a type system And that what that generally means is that if you take the time to make your api design map on to good idiomatic j s and and there because basically here's a problem If you don't do that and you force people to put the angle brackets in their code a javascript person can't do that Right, so the javascript person is going to get an api That just has a bunch of n's or unknowns in it But if you took the time like in this example document that create element to figure out how to teach typescript How to get the information out of the javascript values, which you can usually do Then when you're in pure javascript mode, you actually get the right behavior And so that is all why it is our philosophy to do that Yeah, exactly and so it's a huge benefit Even if you don't use the typescript yourself like your editor is smarter now about what's what's going on And with glint if you like hover over a block program, it will tell you the type Yeah, right. That's like that is a fault in in a non like nothing new typescript You're you're using glint in javascript mode. You hover it over it works. Yeah, exactly. It's very nice. Yeah, totally Okay Yeah, so um I guess We didn't there's one little point to make about ts users We just spent a lot of time which is basically what do you get? Like what is the point of for ts users like we already have ever see like typescript? So what are we getting out of this? The answer the answer is basically that right now there's a separate project which is it's not definitely typed. I don't think But It but it's a separate project Which means that if you have if there's a new beta of ember It doesn't have the types in it if there's a pull request you want to try out doesn't have the types in it and so There's a one major benefit is like including the types with ember means that whatever However, you've got the ember source pull request. It's a branch. It's a beta. It's a canary. It's a alpha build Has the right types the updated ones. Yeah, um, and and that's and the second important thing is sember Which is that typescript itself does not have sember And and for that reason ember side typescript does not have sember other than like trying very hard Um when I say types doesn't have sember what I mean is every single minor release has a breaking changes section That tries to convince you that it's okay But it will actually break your build and sember just means if there weren't red swig lines before there shouldn't be any now Right, like so like not that it won't run. It will still run But now you have to think about a restructure code when I upgrade typescript. So one of the biggest intellectual exercises of the Uh typescript r of c's you're talking about is defining a definition of semantic versioning for typescript types That narrows what you're allowed to do a little bit From what typescript lets you do But it means that we can say that the no screwy line rule to a first approximation applies if you upgrade from ember Something to something else and use a version of typescript that we didn't already have When we made the first version of ember the upgrade will not cause screwy lines That's actually a hard project and it involved the r of c had a lot of comments from the typescript team Um, and we are planning on making ts sember.org its own thing that is useful for people who are not ember per previous conversation, but that that project basically If you like ember's stability story Then it is not then us telling you to use typescript And by the way that means every time you upgrade ember or typescript it might create red lines Is not it's not compatible, right? So we have to figure out a solution to that and and like if you're thinking Has nothing to do with ember you're right with just that we did it Okay, yeah, I mean, yeah, so if we're ready to switch gears to another topic I I wanted to ask me so Shifting gears quite a lot and I'm deliberately so as a contrast with some of this stuff, uh, you know high level vision level stuff Definitely is something you expect to hear at an ember con But I know that lots of people also focus on the the day-to-day nitty-gritty of you know, um, just like basic maintainership You know, how do I get? Like when will this but why isn't why isn't that bug fixed yet? Why isn't that featured in yet? How do I get prs merged faster like? The questions of maintainership and like how do you keep open source projects moving forward and the tensions there? Love to get thoughts on you know that basically like that reconciling the different perspectives of a maintainer A kind of more casual contributor a user You know, I think there's a tension I think there's sometimes a frustration on either side of that that gap There's a thing you said to me earlier that I think might be good to lead in with which is The why do people want their pull requests merged in the first place? Yeah, I think if you want can you talk? Yeah, I know exactly like I think because sometimes You definitely hear the question of like why isn't this merged yet? It seems good and um I would often ask the question back is like well Remember why you care that it's that isn't merged and that's because the code is sitting right there and you could run it If you like it Right, uh, but I think a lot of people Instinctively real didn't want to do that And the reason they didn't want to do that is because they realize it now becomes their problem, right? It's free as in kitten it's Something that you have to now take care of and they recognize that that's a hassle and there's work involved And so the whole reason you want the pr merged is because you recognize that there's a lot of value in Getting other people to buy in with this idea And support it over the long run And so If it was just about getting the code in place you wouldn't care so much about the pr merging You would just reply it to your own fork and go happily on your way Um, the the the long-term value in this stuff comes from the fact that it's being supported And so The that's why you care, right? That's why you want your pr merged But that's the flip side of that is you care because you're asking for something You're asking other people to adopt and maintain that thing forever Um, which and I think I think right and just to be clear like one way to imagine doing that is There's just the ember adopted add-ons repo is just grows without bound And you just keep putting things in there and ostensibly people claim that it's being supported but of course, that's not true and that is a way to Claim that you are moving the responsibility to the ecosystem without actually doing it, right? Another way to do it is to try to Synthesize the thing you're trying to do with the thing everyone else is trying to do Um, in some cases the thing you're trying to do is a bug fix or a Small behavior change that most people would agree with and would be willing to pay the migration cost Right and that happens a lot in that case your job as a person You're trying to get the thing to try to try to make it not just your thing Is to convince everyone that it's either a small thing or it's worth the migration cost And and work with other people to figure out what the migration strategy actually is If there is any necessary Another thing that you could do is make things more sensible So that the thing that you're trying to do isn't as the like is going to change out of slower cadence, right? So maybe like I think liquid fire historically is a good example of this where Initially it was highly coupled to ember internals and over time we work to make enough ember api So you don't need it that doesn't mean that embers breaking changes don't ever affect local fire But they happen like every few years instead of every release, right? So that that's these are all they're basically Your framing is is I like it Which is basically you're trying to shift responsibility from You also think it's yourself But it's really like your company or the project that you might not work there anymore by the time it matters, right? So you're trying to shift responsibility from yourself to the community And it that is not a trivial operation is not it's Basically it it simply doesn't work to do that by just moving it somewhere else Right because you have to convince people to maintain it once you did that So now the question is what is a general purpose structure that we can have in a project that will allow people to Take things that are local to their concern and make other people Maintain them for them and that better or not involve force or something Right, it better involves like yeah convince people of something And that and now you like need to work very hard to to make Most people like the the savings has to be worth the cost, right? So you have to make an environment a community and also a project that focuses on There are some things that other projects like that some ecosystems can't do at all because it's like there is not a good mechanism in our project for Making the cost be worth Making the savings be worth the cost. There's just no way to do it, right? So like that's why things like component manager or modifier manager, right? Those things are about taking a look and saying, okay It is very costly for everyone to people to maintain a fork of their own component system It is also very costly for us to internally maintain four component systems. So What can we do that if we take a look at everyone what everyone wants like what everyone wants is to have Um Interoperable components that they could share with each other But also the ability to customize them in some obscure cases And if since that's what everyone wants You will get actually pretty big savings by not making people have to fork And you will also But you it's it's not worth if you have to make like five different components in your system That savings is not going to be worth the cost for a lot of maintainers, right? So if you again if you look at the whole thing what you have to do is you have to make an Extensibility thing that lets the maintainers off the hook from having to maintain five different things and the combinator exposure to that But also would get leaves everyone else off the hook from having to make a fork Right and that that's just in trends. Like it's I think it's very cool. I like work It's like some sunset the cause of my career um It's like why I work on package managers and like composition, right? But I think that is how you have to think about it and therefore when you are thinking Why is this pull request not getting merged? It might sound like I'm just trying to talk you out of the thing like obviously You shouldn't the answer to why my pull request not merge is not this story, right this story That's very unfair. Yes to force out people, right? But the reason that the pull request is hard to merge sometimes in a way that's not obvious Is this story, right? Which is you're trying to merge a pull request and the maintainers And sometimes maintainers are overly conservative and just need some pushback, right? But yeah a lot of the time the maintainer is saying you are asking me to add a new link rule Here but that link rule is I can tell is a comment or explosion with these other link rules And even though work work for me, which is one of the worst the thing I hate the most in any get-up comment is I Someone says here's the solution and then 20 people say I try to patch it to work for me As if that is supposed to mean that you should merge it. Yeah, it is not you have to check if it actually works Right and so so basically you end up like you have it is important when you submit a pull request If it's supposed to work for everybody You need to check that it does work for everybody And and also not only and that's that's the easy part the hard part is like it has to work for people in the future We are not there yet and ecosystem doesn't exist yet. So you have to have a thought process about how to balance all that and In some sense, there's overhead that's unavoidable in the consensus and pluralism process Yeah, exactly exactly smaller better get smaller over time or people won't have to pay those costs Yes, I any given three month period people who don't have to pay the cost are going to go faster And if you can like this is a problem with democracy also, right? You have bogged down too much in the process of coming to consensus And it doesn't help you that you have a process coming to consensus So that is extremely important and I think we do a okay like okay as Let's say we do a best in class job Where best in class just means I don't know of a better answer Of balancing all that and I am not willing to accept for probably emotional psychological reasons The answer of like it's it's authoritarianism. Someone just decides. Yeah, I think like that just does I hope my my in my head every time. So I think someone says that's an answer to something. I'm like, how do you know that person's right? You you don't right? So like you basically need a system that lets more inputs in Then the benevolent like benevolent dictator still means dictator. It just means the person has to benevolently listen to you Right, you need a system that doesn't require benevolence to get information into the system And that I'm just not willing to accept in any sphere of life Parenting democracy like government like my projects. I'm not willing to accept an axiom of oh, so I'm just the answer is whatever that person decided That's just bad science doesn't work like that, right? So you just don't do that and I think that Yeah, yeah, mechanisms of self-correction, right? It's making sure that they're making sure that there are mechanisms of self-correction and You know, I I think that it's a very healthy thing in open source for everybody to actually Be comfortable with the idea of Of forks in the sense of temporary and soft and proving things out I think a lot of organizations make it too difficult. They add a lot of friction and a lot of It's actually quite helpful to um Just because of cadences and and priorities and organizations with different priorities and budgets and timescales Um, it's totally fine. And this is this it's not unlike the same reason why we have LTS releases that are a slower cadence than our every six week releases, right? Like lots of changes and lots of projects are going to happen on different timescales And that's totally okay And one of the one of the aspects of that is that if there's some like if you made a pr that's critical to you You should run that pr until it gets merged But you should also not leave it forever, right? Like you should be Working in good faith through the process to get it is to consensus so that we can you can stop being a fork and you can get But I I think there's an extremely important thing here, which is the you can squeeze down these costs by having primitives It is frequent if you have a fork that you're maintaining and your fork Mostly is in terms of a logical primitive that is easy to convince people of But the logical primitive is not in ember. So now it's leaking into your whole code base It's pretty easy sometimes to convince people to get Getting at least ember has tried to structure it in the last few years So that there's less emphasis on the ergonomics of the primitive and more emphasis on whether it's could be stable and Compositional and stuff like that And that means that you could do some of that for like yes to a first approximation you just do forks, but The truth is that this whole system only works if you keep pairing down the Costs of yes consensus and that this is one mechanism that is very important that has proved well for us Yeah, yeah well I mean there is always some cost to consensus and that's actually important It comes back to the why do you care that people are merging your ps in the first place, right like Because there's a value that comes with the value consensus has a big value to it that you're going to now not be alone Support but you want to pair out like basically there's two consensus in this case It's like what is the composition and there's what should the high-level API be and there's a bedlock if you try to solve them at the same time There's irreducible. Yeah, that's right. That's right. We can often do that. I mean, but this this comes up even at the smallest scales, right of just like you know relatively simple bug fixes sometimes There could be a whole lot of reasons why The upstream time. Yeah, the upstream maintainer is not going to ship it on the time scale that matters to you, right So you should totally ship it first But then, you know, keep working with the community to get it landed and And I think by the way the typescript the the typescript changes will help here because your forecast types in and out Yeah, that's a good example of what's nice about first-class types. Yeah. Yeah By the way, I want to say like I've been noticing as a parent that like I have a five year old kid in almost one year old I've been noticing that like the world teaches the concepts of like compromise and decision making not the concepts of negotiation and consensus Even though they are logically the same thing like consensus and negotiate if you even think about it in your with the emotional part It sounds Harder it's that now it is harder, but it's not like in the work of it But it's not as more abstract content consensus is like we like in a good day You say the right thing you say, okay You guys should work together to figure out what works best for both of you, right or And negotiate leah at like started saying to Jonas it's based instead of saying we just like some grown up Is going to eventually make the decision here and you like you just tell us what the story is and we'll figure it out There's like an actual process of the two people discussing their Concerns and trying to figure out what is a good solution and we are just not teaching that to anyone ever And therefore it's not surprising to me that the process of consensus doesn't feel natural It feels like like the number of times in a standards body people like why don't we just vote? It's like well We don't vote we if we voted that would mean that one side wins and one side loses Even though there might be a solution doesn't require it. Yeah So why don't we first continue looking for the solution a little bit before we and and yes It takes a while but guess what the people who lose didn't lose that so that's that seems good Like not not not good in a moral sense, but good for the process of making consensus useful Yes, right because it's a repeated game too like you're going to do it again next time and Exactly every time you lose you are not actually getting what you need out of this outcome So that basically over time the outcome is full of things that didn't work for you even though that wasn't necessary Right. So you Okay, uh, sorry and now you're getting me all worked up. Um, no that I wanted to that that's high quality clickbait right there Is there anything else to talk about? Um, I mean, I know we're getting we're getting a little long a time. We've got other things we could do I mean, I was curious you were talking about um You were talking about a shift in performance measurement strategies toward actual real telemetry on real mobile devices As opposed to like the what google.com used to measure Yeah, sure. Um, so I this is like a thing that is true, but also I discovered it by talking to people who are encountering it um For better or worse, like I think everyone is forced into google's view of performance because of google search Which frankly should be the subject of antitrust and is but like should like it's not legitimate that google Is allowed to define the performance metrics for the entire industry simply because of google.com Like that is a messed up thing and and amp literally which is one of their attempts Is literally in the antitrust lawsuit filed by the doj Like in detail not like as a sentence because it's like not good, but anyway for better or worse They do get to do it. Um, I uh I I want to say what is good like so so what they started to do now Finally is instead of having an Uh ideation inside of google google headquarters to figure out what they think is a good proxy for performance, which is usually wrong Um, and it's wrong in a whole lot of ways. They are now using android telemetry to So there's a lot of android phones And they are using android telemetry to say, okay, how long did it in practice take for this website to load on these things? Or if we care about things like interactivity, how long you think for the page to come interactive on actual devices? um The reason that this there's a there's a few reasons why this matters I think the most the abstract point is what I already said, which is that it is it means that Being faster slow is based on reality not based on a google metric you have to hit but in concrete terms one of the things that i've been disappointed in around the investment in is in my There's not a lot of investment in warm Cash in making the second time someone goes through a website fast um, and what I mean by that is so There's a lot of things people what I mean by that is basically if someone finds uh, linkedin.com on google and goes to it The first time it's slow like it's gonna be slow For some definition is slow But the second time it doesn't have to be slow Okay Now there's two factors that are making people not work on it One of them is people look when people try to measure whether it matters They look at warm versus cold cash But warm versus cold cash is is not a good proxy for first versus second view Because the browser will evict your cash for no reason right so basically whether or not The whether or not the cash was there or not is a much smaller Warm cash is a much slower percentage of second hit basically is one issue I'll explain a minute why that matters, but the second thing is that Both your it's both easier to measure your so google already Historically has used mostly first first hit metrics But also when you are trying to make your own measurements internally You are like trying to avoid confounding factors and what does that mean? It means get rid of the cash right because the cash is a confounder So what you end up doing is you write a script that is testing your performance And it is only ever looking at cold and then you say out loud in your company. Oh, well, it's would be really bad It's in first cash was very slow. So we should so like too bad It's like not that's we have to focus on but then like but then you have the the measurement problem where It's like good hard floor or something where now that you measured it That's the only thing anyone invested right even though like you can see logically There's no point in time where It is good to make this user's experience after the first time faster is disproved It's not it's probably there But for reasons that sound reasonable along the way The only thing we're actually measuring and convince ourselves is the only thing that's important Is first cash and people will say stuff like well if you make the first time faster We'll make all the things faster and that's true as far as it goes But also you could do much better on the second hit than the first hit for reasons that nothing to do with the first hit And that might even slow down the first hit in marginal ways right and in particular service workers a thing and service worker allows you to Cash things more aggressively and for better or worse While the browser happily evicts things that are used far future expires because everyone does that technique Service worker is tends to be used more Intentionally It's less likely to be used by a cdn or something and for for better words right now What that means is that browsers are not evicting the service worker cash very aggressively Which means that if you use a service worker that tends to be there not only that but service worker has background CK capabilities which means that you can not you don't have to wait until you the user comes back to your website In the background you can get the new version So by the time the user comes so those are those are techniques that have nothing to do with like offline mode Or anything else that people think is the reason every time I bring this up including the clued in people They're like, oh, we thought about that But we didn't see the point for offline mode or whatever and i'm not even i'm not talking about offline mode The thing i'm talking about only works if you're online right But it allows you to more it allows you to implement the browser's cash in a way that makes more sense And it has huge impacts on second hit right has huge impacts Now the reason i'm saying all that is the good news is when you use android telemetry instead of like Whenever somebody in google cooked up the second hit will matter Right, it will actually be part of your statistics. Yes, right. It's part of you can't avoid it It's actually there right and so and now I don't have to make that argument philosophically so the frustration I have is I don't like it's There's a sense in which sometimes you're just surprised that things capitalism doesn't do And sometimes you're surprised at things like the open source community doesn't do like there's really no reason service workers old now There's really no reason why A very simple service worker that just caches your assets and then in the background since it is not a thing that everyone uses It doesn't have any caveats Right Every the reason that we use this gap service worker is because they have in their head a big list of caveats But those caveats don't apply to this use case To the extent that they do apply it's because people didn't work hard Like didn't work on it enough to iron out the bugs Right, like maybe there's a lot of details at service worker. You have to get right and you might accidentally Get stuck in an old version, but that's not intrinsic Right, those are things that happen to be true the first time something random person in your company Yeah, definitely another thing where you don't again, it's much better to have a consensus implementation than to try to build it all yourself Right, so anyway, the point of that is to say I'm just generally disappointed that this doesn't exist Yeah, but I think there's a very And I should talk about embroider which I think was the really the original motivation probably why you asked But I think getting real android telemetry is just an extremely good improvement to the baseline of what's going on here I really wish it wasn't Happening because google gets to tell you what to do and I really because android telemetry is like its own problem But I'm not the doge, right? So I think I'm going to take the win here Um, I'm going to take the win here and I'm going to say that it is good that we're doing android telemetry And concretely that will help here. I think the other the other relevant thing is um It is now possible to say so that's a good positive improvement It is now possible to say to somebody who is concerned about that Um, in broad Sweep getting on embroider and using embroider code splitting is the fastest way to make a huge impact And I think people don't really appreciate this size of the impact here because we're not good at thinking exponentially, but Basically, there is a huge difference between My app is just app.js and vendor.js this I have slides on this mic, you know There's app.js and vendor.js is what my app is made out of so if I add an admin section My admin section is included in app.js if I add a settings page is included in app.js and Even very very good develop. There's ways to hack it, but almost no one does that even very good people Right and that in practice means that your critical path can't be like even if you're like, oh, maybe I should not use load That's my critical path. It doesn't matter. There's no point in caring about that whereas like Just a sentence you should get on embroider and get on like the embroider strict modes Is enough information to get You have a critical path. You can optimize as a real thing Just using idiomatic ember like the guides the things that the guide tell you You know, this is the thing we have to do in the pliers time frame, but that's I It's hard like it's one of these things that I wish I could say Like I wish I could mind meld and make people realize like This is the thing that's good about ember. It makes the thing you thought about ember two or three years ago Not true about today, etc But for some reason it's hard, but but I think it is true and it will make a difference when it lands Yeah, no, I mean you've definitely talked about some of the challenges of communicating you know the difference between uh Like incremental progress and like high volatility change, you know A lot of the the stuff we ship Like when you when you actually look at when when the work starts when the work ships There's I don't I'm finding that I'm not finding the right words Maybe you could summarize better like this challenge of explaining like Like it's slow and steady wins the race. Yeah kind of my my thinking on it. It's like you can avoid a whole lot of high volatility missteps that cost an awful lot and you like going Like trying to go fast doesn't always make you get there faster, right? I think people have to do have the intuitive sense of that in a lot of areas of life, right? Like if you take the time to do things properly you finish on schedule. You're not slower. You just avoided a lot of mistakes Yeah, so I think the thing that I find difficult to communicate here Like every year when I'm working on the keynote. I'm like I find this so hard to communicate and Let me I want to lay out. What is the the paradox then I want to you started to hint at what I think is the answer um So the paradox is if you look at a one-year time frame For ember it always looks like basically nothing of note is happening Right, so it's like okay. We started working on embroider three years ago a year later I guess we have a prototype of it a year later Okay, I guess like somebody could use it in an app. I guess maybe and that like two years went by in the meantime Like in every one of those years It's like web pack six has come out with new code splitting special static and asm is not like a lot of things are happening Right, and so it feels like like well, it's cool that ember is doing this cool consensus thing But it seems like it's making ember go extremely slowly compared to everyone else However, there's a paradox which is another year goes by you're in year three and now embroider exists and every ember app has it and it's on by default and in the meantime you went from web pack five to web pack six to web pack seven and Probably a lot of apps that were on web pack five are still on web pack five and can't use any of the new features And probably a lot of the like rack routers a good example where it's like Okay, we have nested routes because we copied the ember now. We don't have nested routes. Okay. We have nested routes again Right. There's these wild that Each instance of it seems like news But but then i'm sort of getting into this dance But but basically there's this paradox which is that we don't think in three-year time frames Nor should we make plans in three like we're not going to do the soviet five-year plan That's an extremely bad idea, right? So it seems like there's a problem here. How could like It seems like it's easy to think. Oh, it's a coincidence that octane worked out Well, it's a coincidence of tolerance is gonna work out Well, it's the truth is we could go faster if we just didn't do these like like what we're doing is these big five-year plans And it's like my coincidence is working out. Okay, but it's a stupid idea because everyone knows a stupid idea And what we should instead do is to think what back is doing or react, right? I think that's the paradox it feels like and any given when I write my one-year keynote I always have except for the one year where we landed the addition Yeah, the things i'm saying are very boring And in the meantime there's increasing frustration that like some other ecosystems look like things are happening So why is it so slow? But then every so often there's like a thing that is so Huge that it surprises even like me and you are very keyed into this Point and we're still like shocked at how much octane got done, right? So you like you look at pre-octane. It's like ember knowledge about extend. It's like nfn if you look at the output modules. It's like it's like It's like The weird component api where you have like class in bindings. It's Inner html. So you have elements. It's like all everything's on lifecycle So many things and then you look three years later and it's like A thing that we felt good about like the ember the glimmer jazz thing is like it seems Competitive you might not like it aesthetically, but it's not like ridiculous, right and But and I do like it aesthetically by the way and we also made like auto tracking system That's like pretty advanced compared to whatever right? So so there's this weird thing where Along the way people are getting more and more antsy and need to get some answer for what's going on and yet after three years it seems like by coincidence by miraculous By miraculous conception somehow we have these big switches and also like somehow miraculously The transitions work out. Okay, right even though we have like octane is much different than classic ember somehow like a lot like most ember apps actually transition and get the benefits octane and basically that is like I already know how to talk like in some sense I want to talk about that if i'm telling you the abstract answer What I find very hard to do is to talk about it, you know one-year time frame because that is the problem I do I the I think the the breakthrough I had today talking to you earlier Was an explanation. I don't know if it helps in my keynote, but it's an explanation that Answers some questions, which is a volatility explanation you were Pointing towards yeah, like if you look at the stock market, right the stock market If you if you look there could be a starting point an ending point And you could have one stock market that smoothly went from the starting point to the ending point And one stock market that wildly gyrated from up and down it would have high volatility You could look the volatility index would be very high So first of all I think volatility index is generally considered a bad thing in the stock market If volatility is high something bad is happening And the reason for that is that volatility causes a lot of changes to happen in the world that are Then going to be reversed the next day, right? So it's not good for volatility that there's a lot of reasons for volatility It's bad right you would for given the same starting ending point you would like the volatility to be lower if possible and in the stock market you for the whole stock market, we can't really engineer that but It's important to look at ember so ember is So ember is social same thing. We have a starting at any point. I think I was give using classes as an example, right so ember Decided that we need to worry about native classes the same time as reacticide needs to worry about native classes And then a few years went by And then react in between react landed experimental classes and then abandoned experimental classes more or less like native Like I don't know what to say here other than you're not really supposed to use native classes And they don't really work. They don't have you can't use data classes with all the ember react features You can't use hooks in them, right? So basically that is an abandoned work of react that a lot of people adopted in the meantime And before react actually landed hooks in a stable version of react. We actually landed full support for native classes Which happened incrementally like a little at a time We got rid of that get in that set of replacing with guidance setters We made we defined what the constructor is supposed to be. What is the owner parameter? We thought we figured out how to do all the track right so we did all those steps but then we actually landed native classes not as an aborted fork but as a Actual direction for the framework that you could migrate to with a migration strategy and code mods and everything in the same time frame right so The paradox the answer the paradox in that context is You thought that react lines in native classes was a useful important fact and it looked like ember was going slower But in that particular context it was not correct Like it doesn't in retrospect is not true because they didn't end up doing that They ended up doing hooks instead and you would have been better like What ember was doing was slowly and steadily smoothly going from not having native classes to have native classes And what react was doing was ball was with volatility going from not having hooks to having hooks Right, so the classes in between didn't matter the classes between aren't even part of react going forward for the most part But they mattered when people were looking at what ember was doing in that time frame And and it's and it's not a coincidence not about consensus not about making nice for people The consensus process is making our design actually something that we can sustain going forward Right, so the reason react didn't end up with classes is because they didn't want to support it going forward So the version of classes that landed before ember's version of classes Which was experimental was a version that was not the future It was not it was you could land it faster because you weren't willing to commit to it The second anyone's willing to commit to it ember is just as fast. That's that's a weird paradox As soon as as soon as you account for be willing to commit to something Ember is just as fast as everyone else Yes, and I think the problem is that being willing to commit to something as I said before you don't teach the kids It's not part of your cost analysis at all Even though you could convince someone to think hard about it But but it's not purely philosophical. It makes a big difference like star skylight, which is the app I work on started In about 10 years ago with ember and is currently using ember with glint and type script and whatever and there is Literally no app that is not ember that was created during the same time that is using like npm packages and and type script and what and like Modern classes and modern reacting like that. That's not a thing outside ember and every to every one of these examples feels like oh I'm just cherry picking or something but as a system the system is is is saying we like to move smoothly and smooth the smoothness just like in the stock market has a value And the value the value in terms of your own momentum Your own app not philosophical or nice to have or plain nice those are all mechanisms that we get to make your apps momentum stable and And we and if you look empirically, it's there's only the mist the cases where you can talk about I guess is one last point I want to make which is you can point to things that we did wrong Historically because it was self correcting mechanism. For example, my unification was in state We we spent a lot of time on it. We didn't land it incrementally and we ended up aborting it Now we didn't actually ship it we we didn't commit to it. However That is an example of something where we the process of trying to find consensus In the way that we did that ended up slowing us down inappropriately. Okay, that is the thing that happened However, if over you also need to look over time. How many times do we make that mistake? Right and that the the process is self correcting in some sense. So embroider is not making that error Right. So and and it's not like we it's not a one-time thing. Oh modification to embroider. It's like Like the reactivity like glimmer one was worse than glimmer two, which is going to be worse than star beam, right? And in general there are just There's just a question that you have to answer for how do we make this? How do we make the stability? I guess I'm saying two things one empirically over a big enough time horizon If you take a starting point and an ending point and compare ember to anyone else Ember is competitive Like that like and and people don't sometimes want to go far enough in the past And and you decide that that's not justifiable, but you don't have to go that far in the past. That's right That's right. Well, you know, I think this is it's always it is always a messaging challenge it's particularly in the javascript ecosystem just because With javascript ecosystems growth rate You always have a very large fraction of developers who don't have that history who don't who have not Who have never worked on who've never been responsible for an app for five years And they want a special case they want to say oh that you have to do weird things because of ie If they don't realize that it's it's bad consensus and and commitment So keep going. Sorry. Yeah. No, so it's just like It's hard to tell people you can't you have to you it's hard to give people the answers to problems They don't have yet, right? And so, um, yeah, there's definitely in the first year of an application There's a different set of constraints than in the sixth year as the set of as the whole set of developers So if it turns over there are the same set of constraints, but you didn't realize them. Yeah Yeah, that's right. I mean that's a good commitment. Don't matters. Yes, exactly if you if you knew And that's why there's such as often a disconnect. I think I you know as fast as and I think I'm not trying to suggest that Folks all across the javascript ecosystem don't learn these lessons. I think they absolutely do It's just that by the time one crop of developers has learned it There's now six times as many developers behind them in the pipeline who haven't yet and there's just and uh And some of the business models of software development also just encourage this kind of behavior, right an awful lot of software gets Written tried and thrown away in two years Uh, I mean the news. I think the news model of the world in like Prioritizes volatility. Yeah, right now. I'm saying very abstract thing But like they see something as follows. I have news stories about it, right It's easy like there's only one new story about Polaris. Yes, which is it might it's easy to draw attention to to volatile stuff Yeah, right and like nobody like you it even isn't that big of a deal that some of the volatility is in a down direction It's just like it feels exciting, right? But but I think like I think what I want to say about the distant past is It is relevant that with enough of a time scale from like No matter how like once you get past like two years or something every chunk of time Has like a starting and ending point that looks like if you draw this straight line, it looks competitive, right? I think it's just like the problem is that if you draw a particular straight line like classes Somebody will have an answer to that and I'm what I'm trying to claim here is that the end where our process makes that happen It's not a coincidence, right? And so it's useful to note that if you go back 10 years The line is more than like in the 10 year line is hot is like exponentially competitive, right? And if you go I think approximately something like a three-year time horizon For any three-year window you think any three-year window and any feature Basically, and you have to look at our starting point at any point and then look at somebody other framework starting at any points Sometimes you can't do that because the other framework didn't exist Right, so some of the three-year time horizons like you can't do the analysis But for any place where you could do the analysis and you want to say like what was like ember's story around Um reactivity what was ember's story around modules? What was ember's story around promises? What was ember's story around? um native classes what was ember's like what was ember's story around bundling Right, like what is the story ssr? Right basically any of these things if you do it honest to god Starting an ending point over a three-year time horizon for any of those topics And you compare it to a starting any point of something someone's willing to commit to So next jazz counts, but I am able to use make ssr work manually with reactives does not count Right and next jazz is important because it's a real thing, right? If you look at something someone's willing to commit to Which means your app could still use it four years from now or even three, right? Then ember always looks I'm staying competitive, but I think ember typically looks better Right. It's just in the one-year time frame. There is always The volatility of of people who are not aiming for stability Makes it like the line goes up our line doesn't go up our line is Their line goes up super fast our line is going up slowly and their line goes down and our line keeps going up slowly Right, and I think that the reason I keep bringing up the three-year time horizon is It sounds like I'm making a philosophical point, but I'm not yeah I'm it's very practical because we we can't think that big enough time horizons Yeah, right practically speaking the the proof is in the pudding and you can't find examples really like you can find mistakes that I will just Own up as mistakes and will tell you why how we have avoid making them again in the future But other than those kind of things which are actually quite rare even even in emu. It's like, okay Well, like what is the story with esm in node right now? Like we're we're gonna have ended up having Like basically Invader is gonna have basically esm Supporting node that is like work with x4 mass and everything more or less before anyone else is willing to commit to it Or at least at the same time horizon and so the fact that everyone else have like webpack the whole time it is relevant like I actually think something around the bundler story is a mistake that deserves Thinking in the sense that we've probably done something in between But I still like it doesn't take It's not a fighter. No. Yeah, I mean, I think it's actually a great example of some decisions that we we took Early on before we had the process that we've honed since you know some of the decisions that got locked But we got locked into around add-ons in particular Um, they didn't go through the consensus process they chipped fast because somebody wanted them and there was just an energy in a certain area and um, we didn't have the the process we have now where we would do a better job of Getting consensus around them because I don't think they they weren't the quality of the designs we shipped now Right, we would not have got consensus around them. I think we would have seen We would foreseen a lot of the things that lay locked in that were behaviors that we regret I have a closing analogy to make here. Yeah, which is that when I was back in the day in es6 time frame Uh, there were two features that people were working on there was web components and there was promises There are more features, but those are the ones I want to focus on and promises we needed promises because we were Adding modules to javascript. I think we didn't end up in retrospect needing them But we were like we need async and javascript. There's some it's like important to have it And so we were going to do it and also like the chrome team wanted web components Okay, so what happened with like what happened with promises is tc 39 has this crucible like consensus process that feels very painful But in a one-year time span we went from having no promises at all to having promises shipped in every single browser So the equivalent of the that there's different reasons to have a consensus process But in the web standards the consensus process is so that you have it in every browser Yeah, yeah, and that happened that really happened at the same time frame. What was happening is the chrome team was saying tc 39 is a total failure the consensus process is a total mess We're going to show you by shipping welcome phone is faster We're going to we're just going to be the chrome team We're going to as an authoritarian calm down and we're going to land this thing and if you say you don't like it We're going to tell you you can wait until later. We're doing it now. We know what we're doing They did that and five years later Maybe maybe now so it's more than five years later now, but when I looked at five years later It still didn't land they went from web components. What actually became v0 to v1 That took like four years In the meantime that was supposedly in service of moving quickly and yes You can move quickly if you don't care about other people That's the thing you can do But you don't only care about other people because it's like a like I think the chrome team because their consensus processes in service of Browsers has the opinion. Oh if everyone was chrome, we'd be fine But that but no that's actually incorrect now They're missing the there's other people involved in the web world that have opinions that are being represented by things Like safari and firefox that are now missing and that will come up because web developers including their own team My polymer angular are going to tell them. Hey, this doesn't work out. Yeah, right? So so basically You there's always this like feeling that you have Some people have more than others that if you could just put your foot down and get rid of this Pointless talking that you can move faster and it's not again. It's not just about being nice and having a kumbaya It's about actually getting all the information in And tc 39 and ember are both like actually pretty fast at doing that even though it seems slow That's that's the analogy, right? I like it a year they were like a year way too long Like a year is crazy because it's shipped in three months Well, yes chrome could have shipped in three months and then changed to five times in the meantime safari would have refused to ship Right. What is the point of that? And I know I think that's a really good Summary to land on Okay All right, I will see everybody I'm gonna do my I'm gonna have my keynote Up as the first talk and hopefully some of these themes will come through in some way All right, that's it. I think we have long wide-ranging long conversation. Hopefully it was useful for somebody Yeah, thank you both so much We appreciate it Uh, we'll see you all uh on the internet next week reminder that there are nearly free tickets for Students and anyone who's unemployed. So if you just have some free time and you want to Ramp up your skills a little bit hear more from some of these folks We would love to have you See you all at ember comp. Thank you. Thanks