 Okay. Hi, Rob. How are you? I'm doing so good. It hurts. How are you? Awesome. So busy. I can't breathe, but that's a good thing. I have started. Sometimes it is, I guess. Yeah. Well, to that end, I have started to clear out my to do list a little bit, and I hope to actually be able to take a little time off starting in June. But we'll see. So dear. So I'm off as lovely. Yes, it is. And I miss it very much. Okay. So for today's AMA, I thought what we do is a little warm up kind of like quick fire. Just to get our conversational, you know, ideas flowing mostly because I haven't seen you in a while. How have you been? It's been a minute. Yeah, doing, doing good, doing good. I was actually out on vacation last week. The kids had kids up here in the northeast had spring break. So that's, that's why I was, I was in weird surroundings when we chatted at Emercon. Yeah. So pandemic, right? Where I don't know, are we still in it coming out of it, getting through it? I'm not sure yet. Time is, you know, that is not a question I am qualified to answer. Well, we've all had our survival mechanisms. So I thought I'd ask you some quick fire questions. Did you dot dot dot? Did you learn how to grow plants? No, but I learned how to kill some. Oh, well, that's, I'm an expert at that actually, if you ever need advice. We had some, we have some invasive plants that were kind of like encroaching some of the, I want to say it's kudzu, but I can't remember exactly what it is. But anyways, it was like doing some, some encroachment that we had to, we had to construct a flamethrower to get rid of. Wow, that sounds ambitious. Did you learn how to, did you learn how to bake bread? That's a popular. So this is a strange question. So I do bake bread. I did bake bread during the pandemic, but I have learned, I've known how to make bread for a long time. I generally make most of the bread that we eat for a family. Now I got much better during the pandemic. I, but because I had been sort of a baker for a long time, I had like a pound of yeast that I just had, which a pound of yeast is a lot of yeast. And so, and at the time I made mostly non sourdough. And so if you recall, there was a great yeast shortage. It was mostly about not being able to get the packaging, not about the yeast itself, but anyways, but I had a bunch. I started sending batches of yeast to, to friends, like to, to my brother, for example, I gave him like a whole, like a, I think a half a cup or a cup, which is again a lot of yeast, but not that much in terms of the grand grand scheme of a pound, I guess. So I was lucky in that regard. And oh, and we also had 50 pounds of flour due to that buy it in 50 pound bags. So we had a lot, we were, we weren't like hoarding beforehand, but it just turns out we had, we had a nice supply. So, but since then, I've really amped up my sourdough game. Now I'm primarily baking with sourdough. So man, both sandwich breads and sort of like a country mesh type. Yeah, yeah, yeah. That sounds lovely. Oh, I'm gonna, you're gonna have to open a shop or something. Send me some. Did you, okay, here's some more. Did you buy a peloton? Um, also complicated question. I have a peloton, but I don't, but I think we got it in October of 2019, not. So, so I think the answer is, so I don't know, does it count? Maybe you set the trend. I don't know. Yeah. Did you color sort your books? No. How about reorganize your cable management system? I took everything apart and put it back together again a couple of times. Yeah. Okay. Okay. What about an air fryer? Did you try out one of those? Well, an air fryer is really just a convection oven, which I do have, but I use, my toaster oven is not a convection oven, but I did switch from a toaster, like a slot toaster to a toaster oven. So I'm going to say yes. Yes. Okay. That's a, that's an acceptable one. Now I know you play the ukulele and very well. Do you, did you learn a new instrument? No, I did not. I did not. I did. I've been, I don't know, playing the ukulele off and on for two or three, four years. I don't know, a long time now-ish. I don't know. It's been a while. I can't remember. Time dilation, I guess, is in effect, but I still, I still take lessons. I still try to get better, but mostly now I just play for fun, just to noodle around and as something to do with my hands while I'm thinking about other stuff. But I didn't learn any new instruments specifically now. I tried. I bought myself a cello and then I discovered that I have very short fingers. So that's not the best for cello playing. Is that a feature or a bug on the cello side? I think it's a bug on the cello side. Yeah. Yeah. No, you really need the long fingers to get the notes right. So I own a very beautiful instrument, but I went back to the ukulele because it's small and fits in my hands. So. Yep. Yep. Oh, right. Because everything you make with it sounds happy. Yes, that's true. And just cheers you up all the time. Is there anything new that you did pick up that you want to tell folks about? I don't know. I've done a lot of stuff. I started running. I did my first half marathon in February. I did not die as evidenced by my presence here. Done. Congratulations. I did better than I expected to do, but still got room for improvement. I did it in two hours and 18 minutes, plus some seconds. I can't remember right now, but I'm doing my next one will be in November and I'm going to shoot for sub two hours. So that's a bit of time-shaving, but we'll see if I can get there. Incremental progress, right? Yeah, exactly. Yeah. So what have you been working on lately? Well, so. Yeah, so I think the biggest thing internally is LinkedIn is sort of helping push forward, embroider adoption and try to ready things for our apps. Trying to get things sort of in good order for internal things. We have some differences from like a normal and wrap. For example, we don't tend to use broccoli asset rev for fingerprinting. So we had to implement patches and workarounds for our fingerprinting solution and whatnot. Now, thankfully, Ed's been helping a bunch. We have another couple of folks that work on the team and they've been doing all the work. I just talk to people. Mostly is my job now, apparently. So yeah, the Convincer, the Kajolar, the, you know, the shoulder to cry on, I don't know, all of the things. Yes. Awesome. So you've been working on the web for how many years now? I ran out of fingers, so more than 10. So I got socks on so I can't count them. Yeah. So a long time. I don't know exactly how long. But in that context, have you seen anything lately that is exciting to you or interesting? Well, so it's a bit, so yes, but I think that the thing is that it tends to go in cycles and or it seems to me a lot of the stuff that is exciting to me now is the same stuff that was the same to me 10 years ago, not to say it went away in the middle there, but things like focusing on experience and, you know, getting up to having tooling like do like the right thing instead of having to have the person sort of figure a bunch of stuff out. A lot of really awesome stuff coming through on the TypeScript front. I think especially in, especially in Ember apps, though I know that was a more general question, especially in Ember apps, it's like massively more convenient to use TypeScript in Ember today than it was even just two years ago. And I think we're only going to be better. I think a lot of that is Ember's alignment with more normal JavaScript, you know, TypeScript is getting better. I'm not saying that that's not true, but the fact that it's just less of pain in in our dev's hands is a lot because we just stopped doing stuff that was painful. Like TypeScript is a wonderful tool and a lot of times when you migrate to it and you feel pain, it's really telling you that your API is what kind of crap to begin with. So that's a that's a thing. Yeah. So I was looking at the PR for the interactive mode implementation in Ember CLI. I know that we originally design, wrote the RFC with accessibility in mind, but there's other purposes that can serve. What do you think the good defaults or the right defaults look like for that? Well, I think the, you know, the original, the original RFC, I think was largely framed in terms of like the language flag in one. At least that was the impetus. I know when we were chatting about it. But I think that two things. First of all, I kind of, as I mentioned before, like the experience of using command line tools is like important. And it's often the case where you'll invoke the command line tool, it'll be like, but you don't know exactly what arguments it needs or something to that effect. And you end up getting like, did you mean X? And you're like, yes, just do that, man. Come on. What are you doing? And so I actually think that just Ember New Enter is already a massive improvement, even if it doesn't prompt me for anything other than an app name. Like it's still way better. I can't tell you how many times I forget to put an app name or I forget some flags or whatever. I think the number of questions that we ask and prompt people for is really important to stay quite small or the app generation experience becomes kind of trash, in my opinion. I think that we have a pretty reasonable sweet spot right now where we only have a couple of questions I think we ask. And I think we default everything. Like you can basically call Ember New Enter a bunch of times. With the exception of an app name, we can just do the thing. The things that I think are important are deciding whether you want to use Yarn or NPM as an example. I can imagine the prompt for that, although I think it shouldn't just be those two. It should be arbitrary, like PMPM or Yarn two or three, those kind of things. I think also, but again, sorry, the other one was CI providers. I think CI provider is a new flag that you can already give, though I don't think the wizard yet does that. But we added the flag as sort of the path off of being tied to Travis Yammel. As Travis CI was sort of, I'm going to say going to funk, though, I don't know exactly if that's the right terminology. But for us, for open source purposes, it became basically not useful. And we need a migrate to GitHub. And yes, that took way longer than it should have taken. But I guess that happens sometimes. So we added the CI provider flag. And right now, I think the only options are, I think, are Travis and GitHub. Though, in the thread when we're chatting about it, I think the long term goal is it can be somewhat arbitrary. It can be anything. It could be another package name that provides the provider. I think a lot of folks probably are using either an in-house CI solution where they're not using GitHub actions, but they're using some other thing and the configuration is different. And I think it's kind of annoying that they're going to continue to get a GitHub actions file when they can't use it, for example. So I think we should continue flashing that or lots of folks use Circle CI, right? There's nothing wrong with that. It works good. I think GitLab has a nice CI setup. I forget what the name of it is. But there's lots of different options. I think if you sort of put on your way back hat and you think about the genesis, why did we pick Travis? The answer is it was basically the only one that worked. It was the only one that offered open source. It was effectively bootstrapping the whole concept. And now there's just a lot more options. So I want to continue flashing. I think that is a reasonable prompt in the wizard as well. Yeah, definitely. I remember when we had to call ourselves full stack developers, because you just had to be adorned to put something on the web. You had to know how to set up servers and do all that stuff. And now you can just not. It's great. Anyway, I started with server stuff and then moved to frontend. And I can tell you, I'm not sad to not be doing a lot of server side stuff right now. Yeah, I remember a particularly tricky multi-wordpress site, a multi-site installation on a window server. That was particularly not fun. So I'm definitely glad to be where I am today. Do you have any kind of, when you think forward to CLIs, like Ember CLI has been so inspirational for other CLIs and that's pretty cool. I know I worked recently with a tool that didn't, with a framework that didn't have any generators in their CLIs. And I definitely missed, you know, Ember generate component, my component. What do you see the like the future of CLIs? Have you thought about that at all? Like what do you envision people will add next or? Do you mean in the Ember CLI space or just more broadly? Either, both. I think on the Ember side, I think we have a bit of work to do to recruit and bring in more contributors, newer contributors. Not necessarily newer, but as you might have noticed, I've been doing less overall maintenance these days. I talked about it at the core team panel a little while back, but I'm just doing somewhat less. And I think it's been great to see other folks jump in and pick up. And we need to continue to be, to get better at enabling other contributors and other people to sort of step in and start picking up the torch. I think in Ember CLI space specifically, I think we really were at the forefront of at least front end framework experience there for a long time. And I think, unfortunately, we've lost a bit of ground there. And not in the sense that it's gotten actively worse, but it's just not gotten better and others are getting better. And I think we need to continue to, you know, hone our experience, remove customizations, remove sort of bespoke stuff in favor of more, I'm going to say normal, but more popular packages that already exist in the node space. Again, if you put, if you think about it in terms of when we did it, like a lot of those things didn't exist or certainly weren't popular then. And now they just, now the world is different. And just like Ember sort of learned in the same exact way and made octane, Ember CLI needs to probably go through a nontrivial factor. For example, all of the objects there in that system extend from a thing called core object. And core object was trying to emulate Ember's core object or Ember object base class with extend and create functions. But also bend the curve on how native classes work with super and whatnot. And when I added the supering ability that I just did it in a complete, it's just bad. The reason you have to call this underscore super dot like thing that applies just because I didn't do it right. But because people subclass those, those objects, they, they necessarily have to continue to work. So we need to, we need to do a bit of work to sort of massage our way off of them, much in the same way that Polaris is trying to do the same thing for Ember object derived things as well. I think there's only a path, but that's the kind of work that I'd like to see happen in CLI. Also like dependency upgrades and getting things up to sort of more modern depth versions. I would like to see, we need to be getting to embroider by default, hopefully soon, at least for add-on generation. I know embroider as an add-on blueprint that you can totally use and it works good for generating a v2 add-ons. But we need to continue the work to solidify that and get that nailed down in an RFC so we can make it default for the Ember add-on command. So I think those are the kinds of things that I'm really looking forward to. On the other side, the non-Ember side, because you did say either. I'm personally quite excited about things like the GH command, the GitOps CLI basically, and their cost of extension support where you can write your own custom extensions. They can be native code as well. I've been playing with writing some in Rust, for example, mostly as a mechanism to learn Rust because I'm a long-time dynamic language person. So it's going to take a while to really nail the idea of the static compilation and all that jazz. But it's a fun experience. And writing Rust CLI is generally speaking, writing them is fairly quick and also their startup time is much, much faster than node setup time. So for things that are quick, like just munging of data or using pipelines or something, you can end up doing stuff a lot quicker. And I know, so I'm personally in the terminal all the time. I don't use VS code personally. I use terminal Vim and sometimes Emacs as well. And so terminal experience, like the command line experience is quite important. And I think making things not take forever, like every time my prompt reloads, it shouldn't take 500 milliseconds, which is what it took for like NVM to re-execute itself, stuff like that. So I think those are areas where things are going to continue getting better. And I am learning and trying to improve my skill set there too. Awesome. You were talking a little bit about getting some contributors to help out with Embers CLI. What kind of characteristics do you look for in potential core contributors? Do you have any tips for engineers who might watch this and think, oh, I want to level up. I'd like to contribute to Embers CLI. What should they keep in mind while they do that? So a few things. So first of all, I think Embers CLI is a great code base to jump into because it is constrained. The constraints are much clearer. It's like a quote-unquote normal node CLI. Whereas in Embers itself, there's things you have to know to understand some of the details of why things are structured the way they are. A lot of that's getting better. It's like way better than it was before. But I still think Embers CLI, if you're familiar, if you work in node, if you're familiar with that Dev pipeline using Mocha for tests, that kind of stuff, I think it'll be easy to jump into. As far as what folks should do, I think the first thing is just do it. Find something that is wrong or needs work and dive in and try to figure it out. I think a big thing that we're struggling with on the current CLI core team and other core teams is exactly how to get that maintenance done, like basically get the PR reviews done, get the issues triaged, at least to get a comment back to someone to say a path or direction, or we don't think this is a bug. It's pretty frustrating to be in a position where you're willing to do work on fixing something, but you're not sure where even to bootstrap. Anyway, so I think just diving in and fixing something that's troublesome for you or a pain point you have, I think that is a great way to start. I think personally, I think another really big important thing to do is write up a good description. Whether it be for an issue or a pull request, either way, in both, you want to really explain what's going on. You don't want to just fire off a pull request with a poorly worded title and no body or whatever. I'm not trying to say that the description needs to take longer than the PR itself, but it should be really, really clear the intent and the point of why you sat down to do some code and from reading the description. A lot of times it's not. You're stuck reading the code to figure out what was the real user problem here that they're solving. I see they added a guard in this nested place over here, for example, but they don't really always talk about like as user, I sat down and did X and it did Y, but I expected Z, right? That's the kind of thing. It doesn't have to be quite so formal as, you know, my ruby is going to come up, but like cucumber specs basically, but it can be, it should be very clear what the broken expectation you had was and why the, either the fix needs to exist or what you've tried if it's an issue, what you've tried, you know, hopefully concrete reproduction stuff, which includes cloning a repo and installing depths instead of like I had this snippet of code and good luck. I don't know. Yeah, definitely. I remember Joseph's PR for the Ember New Lang flag and that was a really well, I don't know, I think he does better than I do at his PR descriptions and you kind of sort of answered my next question, which was what makes a PR easier for you to merge and do you have some tips? But I think making sure folks really have that great description in there to reduce the mental load of the reviewer and the context, give the context for the reviewer, it really helps. Yeah. And I think like other things like make sure there's a test, right? Yeah. There are cases there are impossible or the difficulty of adding a test are so high that it may not be worth it. But if you think that's the case, you should say that in your description and explain why and ask the maintainers, do you think that's okay? Or do you have an idea of how to do a test? Or do you know of another test where I might be able to copy this setup from or something to that effect? Instead of just saying it's impossible to test or not testing and not saying anything about not testing and thinking that's fine. I think, especially for Ember CLI, and it's like quite important that the thing actually works. People are using all the time onboarding experience for Ember goes through that pipeline. People read the guides, the main guides and onboarding and whatnot. And just it needs to work, you know, and there have been a times hopefully short duration overall, because hopefully we jump on them pretty quickly, but there've been times when it's been broken. And that's a pretty, I don't know, it's pretty bad. It's pretty, it's a pretty rough experience when someone sits down, I want to learn Ember. And then they do Ember new foo and things blow up, right? Like that's that sucks. You know, so anyway, so explaining, tests are important there explaining what the test cases do and having a test cases be as close to the real life user thing that you ran into as possible, I think is good. Outside of the Ember CLI space, the the other thing that's quite important to to try to do is try to avoid mocking in the tests, if at all possible, construct the units such that they can either take, you know, a fake collaborator or some other mechanism. But when you reach in to some third party object and replace methods, and you're just asserting those methods are called, that doesn't really prove that your case that you care about actually works anymore. It just means that you call some method. What if that method goes away on the collaborator, you know, like those those tests will still pass and real life is broken, right? So it's just a it's a way to think about like you want your tests to be as close to the real problem flow that you ran into as possible. That's a good point. So one of the things we have in our build tool is how all of our CSS comes together. And I'm kind of observing lately that reacts becoming a little more the rack ecosystems becoming a little more opinionated when it comes to CSS and how stuff gets all built together. Why do you think it is that Ember has kind of avoided having opinions about CSS? Given that we're pretty opinionated about everything else? Yeah, this is, this is a good question. I don't have a solid answer. I can tell you, from my personal perspective, I'm just not a CSS expert. I have mostly been doing JavaScript for a long time. Even when I was writing app code, not info code, I had a group of amazing devs that would write the HTML and CSS for us and hand it off for the like the sort of interactivity implementation. And I think, I think the no Godfrey I did not avoid a question on opinion. I am just not there yet haven't gotten to the answer yet. The I think the short version is I think we are considering styles broadly. Some of the designs, for example, the template tag are going to their for like having a template tag in a class is is probably something you should also will have some sort of way to specify styles in the same way. I think it's probably reasonable to do something to the effect and CSS modules though I don't know that that's a panacea either but something to that effect. But having having a way to have your styles in your component they're scoped to your component properly that that feature which you can get in other other ways. But having that sort of integration would be really good. I think part of the problem is parsing styles like what kind of do you want to write SAS is it less is it stylus is that even a thing still like I don't know whatever. But the all of that stuff is is a bit rough to sort of assume I think if we assume CSS in a sort of quote unquote post CSS world then that I think that's probably like a reasonable thing. I think we probably should do something like that. I think as we get further on the gjs and gts implementation side, I think we should absolutely consider adding style but for what it's worth I don't think it should be limited to that. I think there are other cases that are reasonable to have that are also associated to components you could imagine queries you can imagine GraphQL queries that are for a component that are co-located. Anything where useful co-location for a different language type you know could apply. But I do think style is a great example because I think there's some really useful things that we might want to do. You know you might want to just style p tags and not have to worry about the fact that you're going to be scoped properly to your own template as an example. And now that we have the template tag that goes inside the class body that scoping becomes much more logical. Yeah I think one CSS thing I'm looking forward to is layers which I think it's just going to add a whole new level of CSS complexity to our lives but I think one CSS thing that I'll never get on board with is probably CSS and JS. Like that's one that just seems you're just asking for a nightmare from the start. Oh we have a question from one of our viewers. Any thoughts on Ember or Ember data working with non-standard REST APIs or web sockets? Today it feels like fighting against conventions but it's not an option to use a JSON API backend. Yeah I think it's a good question. I think like I'm of a couple of minds here and first of all as with all the rest of the things is you're my personal opinions and aren't in official position by the Ember core team. But the I think Ember data is actually quite good in the case that you described of JSON like a backend you control that is well formed JSON API. It actually works really good and it's out of the box it's a good experience. If you're if you're ramping out a project and you're controlling both server the backend server API server stuff and the front end it's a great choice. I think unfortunately I am never in that situation these days always in a situation of working with a non-JSON API API, non-JSON API TM API because they're all JSON APIs. I really think those guys are really trying to troll us with the names but the the I think the answer for us probably needs to be that we make it clear that Ember data is a good solution a good solution to you to start with but isn't the only solution I think going with something like Apollo if you're using a GraphQL side of things it's going to work fine it's going to be it's going to be pleasant and the experience will be good and and it should be it should be clear in the Ember ecosystem that that kind of thing is totally safe and it's not like other things where you're like going down this weird path that is away from the herd you know which is a thing that we tend to frown them because you know we we we tend to really like being in the the sort of default stack normal setup for Ember developers so I think there's some nuance that we have to deal with there I think personally it wouldn't be surprising to me if in the next while Ember data itself wasn't just wasn't part of the default blueprint unless you opted into it but the guides will talk about it the we'd still walk through it but you know that that's obviously an RFC there's a lot of discussions to kind of happen there and that's not something that will will be doing lightly again I do think Ember data plus jc api is a delightful place to be but when you're not there it's it's like a salmon swimming upstream it's cool it's very very painful and and we can get better at that I think there's other things in Ember data itself even for jc apis that we can continue to hone and get better on like the debugging experience of when your requests sort of run afoul now that's not all like a lot of people blame Ember data for that but it's not all Ember data is fault like I think some of the shanigans that we're doing with back burner and run loop stitching and whatnot is ultimately causing it to be very difficult to debug when you have a rejected like a rejected response or something to line up back up with the original call site that's really hard today and I think that's something that Ember needs to provide better apis for something that something possibly to actually eliminate the run loop I know we effectively eliminated the run loop from the mental model of most developers in like three four and higher we remove the auto run assertion we we've done a lot of work to move away from having to use the run loop at all manually but it's still sort of in your face with rsv promise resolution and route route hooks and whatnot and I think we probably need to rethink some of that stuff to leverage some of the built-in dev tools that are gonna natively stitch your promise stack traces and your async stacks there's ways to opt in to better debugging in back burner but you shouldn't have to know magical hoops like some turbo button to push to figure out how to debug stuff so that makes sense in the ember survey which we just finished going through the results to and one of the biggest pain points for users was error messages or they didn't feel like they got the right error message or enough error messages they just sort of had to figure out what was going wrong and that was really hard so that sounds like a good analysis yeah I think it's pretty it's pretty unfortunate though um because I think we consider bad error messages to be a bug like fundamentally it's just a bug it's not it's not like we don't care it's not we don't want to make good ones um we they should be good they should be actionable they should have links to source code or at least include in as much possible context as is available um and um you know I I kind of hope that folks um you know folks that watch this we'll see that and and hear that I mean sorry and uh and in file issues for a bad error message like I know it's possible to find where their message is coming from in ember or ember ci or pick your tool ember tepelet maybe or whatever tool it is um file a bug say uh if you have to say uh rwj blue said that the error bad error messages are bad uh I found this one and I didn't understand it like that's fine if you if you want to do that um and um the the um we should we should make them better some cases are really hard like I'm not saying it's always simple there's always an answer um but it should be it should be able to be better I think one thing that we probably should do better about is linking more fleshed out docs on the like for deprecations you get the deprecation which I know is not an error but you get a deprecation and there's almost always a link to a a place to go read about the thing um I think we should start fleshing out the that same thing for assertions where you can go that would be a great idea at the very least as an infrastructure I'm not saying every assertion must have a documentation link or something but right for cases where there's common questions or common problems from folks we should totally be able to use the tooling that we have that already will print a url for deprecations and the the internal tooling is roughly the same so we should totally do that a good point a request welcome though um in all of your time working on the framework have your ideas maybe shifted or changed or I'm assuming they have because they all do for all of us how to have your ideas shifted or changed about what a framework should do or should not do yeah I think uh this is this is a good question I think the um the the main area that I'd say my thinking has sort of changed and evolves over time is the the exact balance of convention over configuration um I still absolutely believe that um we should have a nice conventional out-of-the-box experience and um you shouldn't have to have a bunch of boilerplate in your app code that you don't ever touch and that is only framework level um so I haven't changed positions on that but I do think that that doesn't mean there can't be a way for you to figure that out so um older ember like ember early days of ember um there was a lot of magically generated stuff that like can stuff would get met like uh instantiated for you that weren't ever in your project where do they come from who knows um uh stuff like that um I think um also exactly where can you bootstrap uh how things are wired together how do you how do you um how do you wire together the router and the um the the um the resolver and all that stuff like today you have app slash app.js and you import both things and then you set them on your application like that that's fine that's great um but I think um I think we we should go further in that direction um where you know it's still not in your app but uh but there could be an import from a shared location and if you wanted to you could step into that import and you could go see what's going on and it should be easy to understand um I think uh the testing were factors that we've been through I mean I know it's not recent now but uh over the last couple of years um have really uh sort of highlighted the way I like to think about these things um in the test side now you import from the thing that's actually providing functionality so in the case of set up set up tests or set up rendering tests or whatever you import a name that describes the type of test and that import comes from the thing that provides the functionality and if you step into it you'll see it's composed of other lower level parts and you can go step into those from ember test helpers um when you want to use click and other interaction uh helpers you import them from ember test helpers they're not magically available on window um because how do you even know where they come from what where do you go read documentation so I think that sort of um wiring is the kind of thing it is my is much closer to my current line of thinking here um again it is is far from your app must have lots of boilerplate though I know some people probably dislike having four or five imports in their files um like versus before where you had one and it was all these globals were present so I know that's a trade-off but um but I think uh broadly speaking it is a good one because now you can you can logically say oh this comes from member test helpers and guess what we have actually pretty good api docs or a number of test helpers if you go look at them yes like if you know that they don't look at them and you can see what's going on um and I think ideally you can also step into the code and it's it's not crazy land it's it's actually reasonable and understandable and you can figure out what's going on um those are all sort of the the the style of things that we want to do and I think um broadly you'll see that is also the thing that we're doing on ember itself um octane is a good example we got rid of at least in the mental model a lot of the custom shanigans that were replaced by normal jazz classes um and I think polaris can get even further by removing like magical air quotes dot get and set methods and you know evented details and whatnot if you want evented that's great it's a good pattern to use sometimes um but like there is a hundred evented pattern packages on npm go use one of them we don't have to make it like we're not going to be original in that space um and there's no there's no reason for it to be an ember right um yeah you know speaking of wiring things up I was looking at a new framework called astro which supposedly it allows you to use like some view components and some react components and whatever features you like from whatever framework and kind of stitch them together and I was watching a q&a with dan abramov um the other day and and he gave an interesting kind of response to the trade-offs that you could kind of encounter something like going outside of your ecosystem to maybe pull in something like a component from react or a web component itself um what are some of those trade-offs in an ember app like what would we lose by using say a web component instead of an ember component or a react component instead of an ember component uh can you talk us through some of that um I can although I am far from the best person to talk about it but the the web component case is the easiest uh because web components are um specifically limited in the date the way you pass data um I think ember users would find it to be very frustrating to be limited to only passing essentially JSON string of viable data as attributes um you can work around some of that by setting properties but every web component defines its own mechanism for reading those properties um the the way you interact with them is is uh you know you'd have to provide callbacks and whatnot like it just it would feel um less great for higher level components I think it I think they are a good choice for in a lot of cases for like leaf components like UI only components or something with that effect um but but I think um broadly I think that the the case where you you know you're building a you know a post editor or something where you're gonna have data passed into you and it's a high level thing and you want to be able to call save and it's got interaction ability and whatnot I think those cases are quite frustrating and you could totally author a web component that does it and does it well but the web components general spec doesn't really give advice on how to do that um so you're basically just making your own sub version of web components anyways um but to talk about react uh or spelt or view or whatever arbitrary like x framework interaction in ember I think it's totally a thing that we should uh we should continue fleshing out it is totally possible to embed um react in ember app and have either you can do it a bunch of different ways but you can that's definitely a thing and you can interact with the react components um passing high level data and back and forth uh I think that's that's totally a thing you can do now um should we have that be like a default officially supported thing I'm not sure um I do think that there's absolute cases especially at like larger companies where you've got um you've got applications that want to leverage the same underlying code and you don't really want to write it four times and you don't control what they wrote the other thing in so like yeah I get it like that's that's a thing you know you might want to use the shared messenger widget but you don't really want to um you want to be an ember there written in react and you know you don't you don't want to rewrite and you don't want to duplicate their UI um you know so that that's a thing like that that does make sense um the but I think I think in that case I think we should have just a better embedding story um and I mean I think what we we should we should work on there's an rfc open that I just was reviewing the other day about um avoiding globals and making embedding easier um and I think hopefully we can we can push that forward uh that that helps out a lot of a lot of these edge cases um there's there's another problem in this space of wiring multiple frameworks together and that's that the semantics of the various frameworks are all different yeah now they're similar but different um and um I don't think every combination of every framework is is going to be a good fit together some will work well some won't um I do think that we should continue pushing forward some of the ideas that uh you who was talking about with star beam I think in his uh fireside chat I think it was um but um but we should continue flashing that out in terms of how does that work in ember um because the the spirit here is that star beam can provide an easy way to opt into the type of reactivity that we're used to in a react world with hooks and I think we can all see the same thing in view um and etc so we can so it's not quite the same as what the question was but um uh included in the question is well if you had all these frameworks how the hell does data flow work uh how do you force re-rendering how does how does that stuff work and when you go through each layer do you have to wire up the data flow at each level like that would suck right anyway so I think I think it's all intertwined and I think it's um actively sort of the kind of thing that we're pushing on good to know um I always wonder like at what point will we not have components at all we'll just be using web components um but I really like ember's component story and um I don't think I'm looking to switch anytime soon until it's just easy well we use components and we host them on the web they're web components oh I've missed your puns man all right um um what is the thing that everyone thinks is hard and ember but isn't maybe we just don't explain it well or we don't have good error messages but what's the one thing everyone's like oh my god so hard and you're like no I think uh I well I don't know I think there's a hard one let me let me think so um there's a few things that I think are are in that realm um but I think lots of them have had good explainers now um for example uh um Chris Garrett wrote a series of blog posts talking about the reactivity model he also gave a talk at the last years I think last year's ember confer maybe it was two years I don't know um but the about the octane reactivity model and how it worked and all that jazz and I think that um the a lot of people can see I think that is very very difficult like the you know how does tract work how do we reinvent how do we validate all how's all that work and ultimately that's pretty straightforward um I just suggest you could read it blog posts um the other thing is um a lot of people think there's like this sort of black box around how the router works and how things uh go in that realm um the router micro-lib code is not super simple to read but um the conceptual thing that it does is pretty straightforward um and I think the that that library will be massively cleaned up once we can once we refactor it oh now that we don't support it I don't we can just use a single weight and it'll actually make it a lot easier to reason about native promises an async weight probably um and um I think uh I think that'll that'll help there as well um what else I think the the run loop itself is also like surprisingly simple the whole thing is what a thousand lines of code or something it's not that complicated reason about it's just dealing with anything around evented and asynchrony is annoying and hard so like you end up talking down a hard path yeah I've always thought that we need to add more diagrams to our documentation like conceptually visually explain what we're doing and then the code uh but you know time the last time to do that oh that's a PR idea yeah exactly yeah all right um let's see well we have one more question from the audience and I think that will wrap it up for us um do you have any thoughts on packaging agnostic plugins right now if a v2 add-on author wants to provide some build time stuff they need to provide a webpack plugin or some other bespoke transform uh what's this look like when embroider supports multiple packages oh multiple packages do add-on authors need to rewrite their plugins for each packager uh good question okay so there's uh so first of all the short answer is yes right now um I think until we have um the ability to serialize or synthesize the things that those plugins are doing in terms of things that we already provided agnostic tooling for like things you could do with embroider macros for example um you uh you're gonna be forced to write n plugins now uh and that that does feel bad but also um it's not that bad we don't really expect terribly large number of um of folks to have to write these custom plugins um there's a handful of really specific cases they're common that we think will probably exist things like graph ql um hooking in and compiling your graph ql um and whatnot um so that's totally a thing that you you would need a plugin for if you had any sort of customizations the but uh but I think um we don't expect the number of people that have to opt to those to be a massive uh sort of lift uh or sorry a large number we think lots of apps will use them but everyone won't be writing them um so in those cases factoring those things to be able to provide shared interfaces that can be shared amongst the plugin for the various packages they care about I think is is a thing that's it's fine um I don't think it's great but it's fine um I think the ability to support multiple packages is quite important and we need to quickly get there um in my opinion um so that we we don't um accidentally solidify ourselves and be stuck with just webpack for example um I would love to see us uh go to mo or vit or whatever but I think the the broad the broad problem is um we are intentionally decoupling which means some category of problems are harder and those category that category of problems ends up um uh ends up still being a somewhat difficult lift and we need to make rfcs to make those things better for example you can imagine um you can imagine writing a thing uh at least for at least a couple of these um you could write a library that wraps roll up and webpack and provides the interfaces needed for both of them and you I mean largely the sets of hooks that exist for these plugins are basically the same you know there's like do the thing here's your source go do the translation for example um so you could totally do that um and in heck I'm not even saying that doesn't exist so much should look I I bet someone wrote this uh it probably does exist it's not like I'm it's unlikely to be a unique thought that I had um the um yeah I just I think I think that's that's all path again that's gonna have pitfalls too and not pitfalls it'll have uh gaps uh as well because every packaging doesn't support every combination of hooks and style of intercepting activity um you know so there might be uh gaps in in like a general purpose wrapping thing but um if the point is the the simplest lowest level functionality I think we could probably write a like a shared wrap my transform function in a in a frame in a sorry plug-in wrapper thing that works um I think that's probably possible awesome well we're just about at time um or as much time as we said we'd do this for so thank you so much Rob for um being willing to do this AMA and it's been awesome to chat and catch up and think about the future I hope you have a great day and thanks to everyone for watching um hope to see you soon I hear y'all