 If it's really important to have this opportunity for the community to actually get together in real life in person. There are some people I literally just like see maybe like two or three times in a year on these conferences but it's like always great to just like reconnect. I think actually I'm just here for the merch. In Ember, most of the people I talk to try to converge on one solution essentially and not do quite different things. We're building it together. We're the together framework. I guess if you want to say that. If the community is the one that's driving us anything, it means the community decides what sort of problems are we facing. Maybe those are problems that are more or less the same. You end up having solutions that kind of solve problems for everybody else. I really like that and I really recommend that people watch that documentary because I think it captures a lot of what I really loved about the Ember community back then and again it's like a time warp in between but I feel exactly the same way as I felt in 2019 about that. Okay, so that's basically reconnecting I think. I've said what I didn't say. I'm a little distracted here but I will get back on track. So in between the time we started Ember and now I had two kids during COVID I had a kid. I think he was going to come back on stage but I think he is probably six years old and a lot of time went by. So he was on stage in 2017 and when he was zero years old. And I think one thing that's really cool about Ember is that Ember is a part of the sustainability story. We believe in not burning people out so we can't have kids. We believe in making Ember sustainable for our volunteers contributors with kids. And I think in general I really think Julia's talk is going to be awesome. Believe it or not raising kids has a lot in common with building a web framework the way that we do. And I think Julia's talk on PACSEN you should definitely go see it. But in general really the reason this slide is here is that I've given a few talks since COVID like a handful and I keep saying I should really put my kids on the slide because it's a big part of who I am. And I kept forgetting so there we go. Had kids that's a big part of who I am. It continues to be a big part of how I think about Ember and its sustainability and it's important I think to us as a community that it makes sense for kids to be part of it. Okay, so big picture. I think the glue that I got from Julia's talk. So I did a bunch of run throughs. Julia showed me her talk ahead of time and she gave me this concept of architectural building blocks and again go see her talk it's good. And it made me think that what's really good about Ember is that we have these building blocks and I'll unpack this throughout the talk like components, services, routes that are as a conceptual matter. They're like these building blocks that I brought a prop. They're like these building blocks that like you kind of if you think about what is a service ten years like eight years or seven years ago and what is it today? Sure seven years ago it said Ember dot object dot extend or something like that and now it doesn't but how you think about it as a user, as a community member, as a developer, as a beginner, as an expert all that is basically still the same and I'm going to unpack this like I said in a bit but basically the idea is that the inside of the building block that the reason it's glowing is the insides can change, the insides can like do whatever but the way that the building blocks fit together doesn't change and that is as I will unpack later a big part of what makes it possible for Ember to have a sustainability story and have an evolution over time story that works as well as it does and I think it's underappreciated but it's because of the way we architect and how we think about the concepts. So I started programming in 2004 and Ruby and Rails changed my life. I basically was programming PHP for like about six months or a year before that. I learned about Rails and the reason that Rails changed my life was at that point I was really a beginner and it was like writing raw SQL inside of PHP was not something that was getting me very far. It's not like I couldn't do it, it was just like taking me a long time to do anything and the really big deal about Rails for me and the thing that I really tried to bring to Ember and I think makes sense is Rails was not a tool that was like for beginners and then there was the more expert version of Rails. DHH should say there's no easy-make ovens, right? And the idea behind that is there should be a way of using the tool that makes sense for beginners, there should be a way of using the tool that makes sense for experts and there should be a feedback loop between those communities and so when I started I was like literally just starting and Kaz who had been programming for years and like worked with Jboss and stuff like that was using literally the exact same tools as me and any thoughts that I had about whether the tools were good or not I could talk to him as a super advanced developer and it made sense and that idea of like everybody is basically working with the same concepts is the thing that I took away from Rails, it's the thing that made me able to be a programmer because until then I was like not really sure if that made sense for me and I think that's something that I believe in and it's what makes Ember matter for me, it's why I'm still here and it's why I think we are still here. Okay, so what are we going to cover today? First of all I want to talk about Polaris so I'm going to get into a lot of like not the nitty-gritty because that's what Ed's going to do but I'm going to get into like what programming in Polaris is going to feel like and then at the end I'm going to talk about how does this story fit into Ember's story that I just told about ourselves and the challenges that we face going forward. Okay, so table contents-wise we're going to talk about template tag, talk about routing, talk about resources, talk about TypeScript, we're going to talk about modern tooling, basically it's going to be basically v stuff like that, share tooling. The reason I had that bold thing on the bottom there is because it's very easy, we're not saying like basically like SvelteKit exists today because Sapper existed before, they wanted to adopt v and they didn't migrate Sapper to v they instead created a new thing called SvelteKit. We are not going to do that, we're going to take the existing Ember tooling and migrate users over to the new system so basically existing apps will get v eventually subject to the usual migration caveats and that is what I mean by share tooling, right? Making another thing that you migrate to, it's not like well there used to be Vue CLI, now there's going to be like the Ember tooling, it's just going to use the ecosystem under the hood, again more on that at that point in the talk. Okay, so template tag, so Octane really actually made a big advance here because if you remember before Octane, you had files in app slash components and files in app slash template slash components that were really talking about the same thing and Octane made a pretty significant ergonomic improvement by putting the template alongside the JavaScript or TypeScript file. That is nice, but I think it's basically behind, it's lagging behind our peer frameworks and that is because all of our peer frameworks either use JSX which basically means you can put the quoteable template in the same file or they use a single file component system which lets you put your template and your style and your JavaScript in the same place and everybody outside like basically most Ember people also but the wider ecosystem is pretty convinced that having two separate files is not good and I basically agree with that and so we need a solution. I think just FYI the thing that really pushed us here is that we wanted to be able to import stuff into our templates and the reason we wanted that is because in order to get all the benefits that I'll talk about later in the tooling space we really need to not have weird Emberisms that are not the same thing as modules so we really needed a file that's the module and we really needed that file to be importing things from other files and that's just how the JavaScript ecosystem works now and this is basically what we landed on there's like very very long series of blog posts you can learn about why we ended up here but this is what we ended up with so basically the class part looks exactly the same as the octane class part there's still track properties etc and the only difference is that you move the template tag from yeah so the track is the same you move the template tag from the HBS file into a template tag and I think I don't get to it soon enough but basically if you import other components into the file just like you would in a normal JavaScript file and that's like the big difference but really it's just about taking the two files and putting them in the same place some benefits that fall out of this that I think are really good you can just write a function in the same file if you want to function you don't have to make a whole other file somewhere where you put your quote-unquote helper that hopefully is generic enough to justify it you can just put it in there and because it's just another module you can just use a named export I think what we exactly recommend is still going to be like Ember is going to have conventions that we encourage people to use and maybe link but there's nothing stopping us from using from using any normal JavaScript module feature like it's just really a JavaScript module and so any type script code extraction should just work that's fine so you just move into another file also the function signature is just a normal JavaScript signature this is the thing that already has landed by the way almost everything I'm going to talk about today has landed I'll tell you if it hasn't I'll talk later about if that's the case why do we have Polaris but the thing that lets you just use normal functions in a helper file is already a thing that landed and is like very easy to use in any Ember app regardless of how much you adopted GGS and GTS files but this model where it's just a function and you're using it in the same file like the programming model where you can just think of your template as having access to JavaScript functions in scope that you can move around that's of course a GTS thing and it's good that you don't have to write helper prints so I said that already so now I'm just going to repeat kind of repeat myself so modifiers and octane go in separate files and I think one thing I would say about modifiers is that the story before octane is that components had access to a root element and that meant you had stuff like class name binding attribute bindings last from the past you don't need to know if you don't know it but there was a DSL on the component that was like how you talk about just the root element and octane basically said there's no more concept of like the components element there's like that way you can just use the class equals you can use attributes anything you can do anywhere works and the way we gave you back the feature of lifecycle was we gave you modifiers we made modifiers and that is technically good but it basically means that you have the same problem with helpers where you need to like if you have some DOM logic that's very local to a component you still need to put it in another file in a different location just to use it and so that's just I would say a hole in our migration from I think there was enough benefits to justify it but it's a hole in the ergonomics of going from literally it's in the class to it's in a separate modifier concept and I think what ends up happening is people use ember render modifiers to glue it together but those things are not very composable so basically what so this is an example from the ember modifier docs this is just how you import it's a package blah blah blah it's a pretty boring example but it's the one from the docs and just like with helpers like the Polaris stories you can just put the modifier like it's moved randomly again it's from the docs but like you can put it in the same file you can access it from the same file and it works you can just write in the same file and use it directly and you don't need any like if you don't need any local state you also don't need a class like you can still use a class but you can just put a template tag in the top level and I think that's all pretty sweet Jonas if you want to come up and ask Wave at people because you missed it before I told him he could wave but he wasn't here yeah wave this is human sustainability thank you Jonas yeah I've been telling him as soon as ember conf is over I will have my weekends back so so basically modifiers just work and then I also want to point out like I already said they export work but also obviously default export work because the point of it is just the value so we already know our modules work there's nothing new to learn here we will probably have some lints about like what the conventional style is but those will be lints those won't be about how the semantics work now this is I think the point where we're talking about something that is unique about what ember is doing here so people tend to think of JSX as the slam dunk winner of the framework wars but I think that's interesting and like go check you can bet me if you want basically everybody else or a person or a framework trying to be a clone react does not use JSX okay view allows you to use JSX but their documentation is like you probably don't want to use JSX go watch talks by either Rich Harris or Evan you about why that happens but I think basically there are good benefits to using templates that is a good idea and basically everyone who is not react thinks that however there is a nice thing about JSX which is that it's very easy to have two files in the same file because it's just an expression or a function you can just like make another one in the same file and call it and that is actually a thing that SFC is loose right and that's kind of why view ends up having these having JSX for like advanced cases because the SFCs don't give you everything that you need right and so the thing that I think is really awesome about the ember story and is like unique and doesn't exist anywhere else and like makes me it's like the kind of thing that makes me want to build something on top of what everyone else is doing and not just like go off and work on next JS or something is I think this is like a genuinely awesome thing it basically means that you can have a test that has a template tag that has access to the local scope you can have a bunch of them in the same file you can like extract utility components that are not ready to be pulled out into separate files yet and all this stuff just works and I think if you just quickly look at what I've said it will be like oh template that looks like JSX but it's actually it's actually a very nice combination of of the template the benefits of templating syntax and the benefits of having expressions that you can put in the same file so basically lets you take it lets you have an SFC that you can like move around I think that's pretty nice the top I should also say the top level template tag in the one of the component that's the declaration form so like that makes it you don't have to write export the full template tag right so there's some nice forms for the cases that are like SFCs but because it's not because that's just a convenience form writing const toggle equals template tag works also and like again I think this is like I think I'm really proud of I think it's really awesome and it's very unique and like really will shine in tests I think I think the fact that you could just like write a template tag gives you a component and you can just like access local scope from the test I think that's good I think that is like a game changing thing and nobody else really has it okay so that's template tag and I think like I think that's really awesome template tag that's already landed I will say later when I say landed it filled you up to configure it and it's pretty annoying especially using TypeScript so you have to be motivated but all the underlying features the prettier support the support in the Ember language server ESLint for the most part like the implementation that makes it work at all it works in class and in border right all that stuff already landed if you install Ember template imports so I think that's like we need to finish the job and I'll get into that but I think like I think that's an example something that is well in hand that we just need to focus on getting polish over the finish line but we like really already did most of the implementation okay the next topic is basically a unification of a lot of concepts that called resources and I'll just quickly go through a bunch of examples that show you what I mean by that by the way it is I don't know if you can see it but my clocks is 15 minutes so basically I'm not I'm not wildly over it just a lot of things happened earlier okay so basically what is resources I think a way to think about it is that they rationalize class based helpers, modifiers, services and even routing and that doesn't mean like it's like this obscure concept that you need to learn or whatever it's just it's going to basically be the replacement for a lot of those concepts so let's just look at like first class based helpers so class based helpers are this weird thing that is kind of like a function but you need it if you need services or track state or something like that you have this compute method if you need lifecycle it gives you will destroy but the way it looks to you as a user is it looks like a function in your in the HBS file right if you look on the right hand side the resources side that is like resource it's the DSL here by the way is the star beam DSL which I'll talk about in a minute but basically there's going to be a class based version it's basically blocking on stage the decorators getting out of the getting done but this is like a way of getting like if you are a fan of the functional modifier or thing or like the helpers those have limits you you run into problems if you need lifecycle or services or whatever or they look different in different people's add-ons this is basically a way of pushing as far as is reasonable on the function version of things and then if you have like a lot of track state and a bunch of methods clearly then you want the class version right so anyway that is the DSL I think without getting into too much detail it's like a very it's a small DSL that gives you a way of set creating setup and tear down logic and the point is that when you say parentheses current time in your template it works the same way that it worked before with class based helpers and the important thing here is that it gives you cleanup logic right so if you just have a regular function there's no cleanup a lot of the time you want to set up some state that also gets cleaned up and that is what resources are for now if all they did was replace class based helpers it's probably like a little a little much but there's a bunch of other things that you get out of it so the first one is that a service in Polaris is just a resource that's scoped to an app right so a resource is just a reactive object that is attached to some lifetime it's not only a component but there's also a concept called the app in ember weirdly not a lot of other frameworks and so sometimes you want to attach a object like maybe you have a long live channel or something like that or a web socket right like this is a kind of thing people do with resources importantly like tear down still does exist and the reason for that is that especially integration testing you want to be able to like keep you you don't have to like boot up the whole app every single time you run a test which is how most other frameworks do it and so by basically putting a lot like by having tear down logic inside your services you can boot up the app get some app state and then tear that down run another test with the same code right and that actually does make our integration test rather fast and like uniquely so in some ways and so basically that in that sense services right now are like another concept from class based helpers and the resource concept unifies them and importantly if you already had the resource from the previous slide you don't have to do anything special to make it a service all you do is you say that you want to use that resource as a service when you use it and that basically means like only make one of them please for the current app okay and by the way like this is I spent a lot of time working on this but like the when you say like there's no types anywhere on this slide but you get the right answer when you say service current time from TypeScript and I think that's like pretty nice and I think the wider ecosystem could spend more time trying to get inference to work well because TypeScript is actually very good at inference but people are like just very willing to be like just put some angle brackets here and that is like fine until it doesn't work and you're real confused about why things are failing at one time so I I really like leaning on on inference and I think this is we made it work okay modifiers that's another thing and this is like okay how does Polaris have a story for modifiers that's built in and not like an add-on basically it's a resource that's scoped to an element and I have a bug in this slide I think but basically there should be the inner function should be a function that takes an element and returns a resource right so basically the when you say curly curly element size it basically calls a function with the arguments more or less and then when the element gets like when the element exists it calls the function that gets returned with the element and it gets back a resource and that resource has a lifetime that lifetime is attached to the element's lifetime right so again that's like probably the first time you're hearing it it sounds like I just said a lot of words but it's basically just another way that the same resource concept which is just an API and it's the API and ember for generically saying I have some reactive state I want it to be attached to some lifetime it's a way of reusing that same concept and sometimes the code because the element it usefully has a lifetime right the element the element that you attach to a directive or modifier whatever you want to call it is is a stable thing and it just gets set up and torn down so it is actually possible to give it an element it's just like if you're using a framework like React and you end up with nulls for no reason but anyway the point is that it's just a function that takes some arguments that returns a function that takes an element and gives you a resource so hopefully the moral of the story here is like resources are a concept that we're going to use as well we'll have a class based ESL eventually and like answers a lot of questions about what we're doing like about what our concepts are right I don't know why I have that slide what is this extra slide here what is happening everything is going crazy okay next slide so I have import from star beam universal here like what is that this is the one and only react slide that I'm going to show here basically star beam is like successor in some to a big part of the part but the tracking part I work on it and null box who works on ember resources also is on the core team of star beam and the main thing that's different between star beam and glimmer is that star beam is makes these concepts something that works for all frameworks we have already written a react a preact and a view renderer called the things renderers the only reason there isn't already ember renderer is that ember already has a version all these things that already work and works in people's apps so I haven't felt like I need to prioritize like the only benefit that you get from star beam is other people are using it we're not ember so I need to like make that actually happen but the point is that the universal APIs will glue in ergonomically into ember as I've been showing on these slides and the point is that you can publish libraries that just use star beam universal don't mention ember at all and then other frameworks can do like what I'm showing here on the right like other frameworks can do can say like use modifier in the react case and then like in react you have to use wrap or you have to suppose to do or idiomatically react but there's a version of it like in view will be a directive that's kind of thing so that's that's what it is it's from the if you don't care about any of that it's just it's like saying glimmer components like the thing you imported but if you do care about it it gives you a way of writing universal universally reactive things that work in all frameworks and go to starbeamjs.com there's some documentation there and that's what it is okay okay so all of that brings us to routing now this these slides are the most speculative slides because there is no rfc that describes the syntax however it is the constraints are like everybody who works on routing in ember has this clear understanding of what the requirements are and I will talk about them and they give you very little wiggle room but the of course everyone in this room and everyone watching is welcome to let me get the rfc to like I want to say bike shed but not in the negative way like to get like I don't like the word bike shed because it implies like it's not a good thing but I think making the like the concept makes sense to everybody like making that happen requires that people like see that the words are not too weird and like if you just use functional programming words everywhere that does not what happens right so feel free to come in help us refine this syntax but these slides are basically trying to show you like how the concepts fit together conceptually but don't take the exact syntax for anything specific okay so basically what on the left hand side is like what I think is probably going to end up happening in practice for most cases I think that should say articles.data.ts so basically there's going to be some kind of resource function which takes a URL and gives you back a thing that counts as a model data and I think that's mostly what will happen but I think the right hand slide I have as a rule like things need to fit on a slide right the right hand side I guess it has a tiny bit of scrolling the right hand side is basically showing you it's not that hard to write the resource it's just that like it would not be great if every single time you wanted to like fetch a URL you have to do it now you might be saying like I think you could have made this slide look less annoying if you just use fetch directly but like you probably actually do want to support cancellation as a general principle because if it takes a long time to make the fetch and then the user navigates to another page probably a good idea to cancel the existing one and not just have it keep running so I think that's a good idea and you don't have to take my word for it like it's one of the YouTube things that keeps going by which is like hey by the way you're probably doing it wrong you really should be using a board controller that's fine but we probably should just give you a thing that does that for you and that's the only reason that this slide looks like it has more things on it is because I think that's probably what we're going to do like the left hand side it's not magic pretty easy but I just don't think everyone should have to write it all okay now so far I just showed you like it's just a function that returns the thing what about dynamic segments I think that's indeed the tricky thing by the way that hash app there it's just using a Node.js feature called import map so like if you're a package JSON has an import map like TypeScript and everybody knows what it means and as part of the general feeling that we should probably stick with what everyone else is doing it's possible to get the benefit of ecosystem tooling that's probably what we're going to do I think we don't have an RCA but I think we generate an import like your package JSON when you generate an ember app has an import map in it that points hash app somewhere then you say hash app and everything works because that's how package JSON works now is probably what's going to happen okay so basically what is a dynamic segment it's a parameter to a function that returns a resource so it's kind of like the element thing I showed before right it's a function and I don't eds talk at emberfest last year like goes into a lot of detail about philosophically what's going on here and maybe he'll talk about it later but I'm just trying to show you like from a user perspective what's going on here so there's stuff like it's bad that controllers outlive the template I think that's all good stuff to understand but I'm not going to get into it super aggressively here the tops part here is probably the most speculative part of all this and basically the key point about all of this is that in Polaris and like with embroider routes are the main unit of where code splitting happens so today there is no code splitting so there's not much to say about it but the main unit of code splitting is a route and the key point there is that I guess I should say I'll say my point and then I'll say that point the main point when I say the unit of code splitting what I mean is and I have slides on this fetching data and fetching the code should not have to happen together because it's obvious that fetching the code is going to take the component tree for your route is going to take a while and you don't have to wait for that to happen before you start fetching the data so basically the structure of this API is designed to make it easy for Ember and you to think about like here's the part that's fetching the data and here's the part that's fetching the code and if you put them all in one file I think we'll support that maybe as like a very simple thing that you could do but if you put them in the same file and you're sharing the same imports and that basically ends up meaning that you can't really start running the code to fetch your data until you actually have all the code for your components and that's just wrong like that it's just it's not like about SSR or anything it's just like pointlessly expensive to do it like that I want to say like a goal for this design and I think if we can't make this work but I think we can then we won't do this but like the goal here is that if you have an ID parameter that goes function on the other side of that that this should give you an error if you leave it out or something like that and if you're curious there's something called a tag template literal type and type script that together with some other magic that's not out of the realm of what everyone else is doing we can make it work and again if it but I think I would rather if you don't have to write import friends everywhere but I think if we'll do whatever we have to do to make it make sense that this is true I think this something like this will work so I said this already a routes component and its code load in parallel I think critically this is the critical thing it has nothing to do with SSR right it just has to do with the fact that we don't want to have to wait for the parent component to render before like you can start getting its data and then like you render the child and then you can get its data like that just if you look at the react store around all this like how they have to figure it out eventually they settled they had like a few options and they eventually settled on a thing that is more or less exactly this which is like you fetch and render at the same time you're doing that in parallel and everything other than that you can make suspense the react do anything you want but anything other than that is like recommended against because of the fact that it creates the waterfall problem and I think we should just try to avoid that by default by the end okay I only have a few more concepts left so I just this is very quick I just want to say when I say that there's conceptual building blocks on the screen is pretty different from the routing story that we have today but I think it is important to reiterate that the routing story that we have can't change like what is the point of routing an ember and part the point of ember routing an ember is ember is a web framework we should have good URL support what does good URL support mean like I'm not gonna you'll go watch an old talk that we've given but it means like the back button works reloading page works you can open a new tab I can send a URL to somebody on Discord and then tomorrow it still works right all that is good and there's like a lot of other things like that so basically it should work like a static site right and more or less I okay I will if I have time for questions I will call on you first okay so the opinion he has about ember okay I'm okay even if I don't get time I'll ask you later because beginner's mind is very good okay so basically what I mean by things work is like if you were looking at a page and you reloaded it still looks the way I expected it to work which basically means that meaningful state is preserved you don't like I think you know what the bad version of this is and I even though we've been embers been talking about this like since 2012 there's still a lot of sites that do the wrong thing but I also mean like you can make permalinks with query programs whatever like I think this is all it's all boring but if you go into the whole details like a lot of frameworks a lot of routing systems today that even a claim to be inspired by ember don't get all details of these things right and I think that page more or less the URLs URLs are very important you put them on billboards you send them in text messages they should be stable they should work they should capture the state correctly etc okay so now why like why do we do all the things I just said I'm just transitioning now into the like okay what are the challenges that ember faces etc so I'm gonna play another video and then try to wrap it up and pass it off if we hadn't started Tilda if some entity like Tilda didn't exist and instead ember was a project that we were working out of some other big company there's a good chance by now that some executive from on up high would have come down and been like I don't care about this scrap it and that would have been the end but because we have these smaller people driven companies in our ecosystem that's not really gonna happen if we hadn't started Tilda if some entity like Tilda loop on a loop okay basically I think this is really true I think I feel more strongly about it now that I felt when I when we originally recorded that I think at any given point there's gonna be some important companies that are investing a lot in ember but ember is really really structured so that a disinvestment from any significant company does not actually materially affect ember's ability to make progress of course less investment less resourcing has some impact on both the short and medium term progress like what people are doing but I think as an organizational matter there no company like owns ember and no company is no company's disinvestment I think a really good example that I use is like we don't use people's internal bug trackers we don't like our roadmap is not approved by some manager somewhere inside of some company so that means that if somebody like suddenly disinvest there's no infrastructure or or or or or chart matter that like sudden has to be quickly changed like that people are part of the ember poor teams as individuals not as companies okay so why are we still here like in some sense that's a good question like okay well we'll do a lot of things that make us as good as other frameworks but like okay but other frameworks already exist so why are we still here and I think the really the answer to this question and why I am still here is that the ideas that made ember good that make people want to be in the room here and that make apps that were built literally like 10 years ago still exist today and are able to use like gjs files and typescript 5.1 like why is that even possible that's like so far out of the expectations that anybody in the ecosystem has like that is still a controversial thing to try to accomplish what everyone else does is oh V came out let's like fork everything fork the ecosystem and do something else the fact that we invest so much energy in building blocks that we work on together that like beginners and experts can work on together and iterate on that add-ons can like that don't require us to like suddenly fork the ecosystem be like okay there's the part of the ecosystem that supports octane and whatever like all that is like a hugely powerful thing about ember that means that like older apps still work today but that also means that if you start an app today that that app gets the benefits tomorrow and next year and year after that and it's just if you even rewind to take three years there's almost no framework that is not ember that didn't have some kind of big fork that would require you to do a significant effective rewrite of your code base and I think the fact that ember has been not doing that since 2012 or 2013 is a good enough reason for us to keep doing this I will talk again about the challenges in a minute but I think how I usually summarize what I am talking about here is that we other ecosystems basically it's normal to have a concept of injection which basically means like well there's the like create react app or whatever like the thing that is the nice beginner friendly thing but like in practice you like press the eject button it like explodes out into your code base and now that's the thing that doing that basically means that it's very very there's no difference between the implementation details that a very advanced user understands and the way the conceptual building blocks that beginner users are like intermediates are using and that just makes it almost impossible to do any kind of significant changes of the code base without forks right so basically what no ejection means is that it aligns the mainline APIs like the APIs that are the primary ones in the docs with the way people actually use them it also changes our APIs with the way people think about the APIs right and that basically means that when we say okay we're not going to ember dot object is not a thing anymore that's fine because the authoring format all along was import from ember slash string and just because there's an implementation detail that turned into ember dot string somewhere internally for the last three or four years changing that to be a real module doesn't affect the mainline API how you think about the API or how you use it and I think just when you eject when you have ejection as like a primary way that you think about things it leaks the low level details of how things work into the way the framework is composed and the migration strategy it's unavoidable and I think it takes some effort to make that not true to have a difference between the authoring format and the implementation strategy but it has really paid dividends it's the reason that go back three years or six years or nine years and ember didn't ever have one of those forks even though at every one of those there's a lot of things that are not true to the authoring format okay I said the word authoring format basically I just want I have to define it because no one else does it but ember is unique in defining our public API in terms of an authoring format that is separate from the way the framework is built and that means that think like I talked about before like at ember slash string becomes ember dot string that's an internal detail the authoring format which is like very not compatible with the way the ecosystem wants to do things now we can change it all the way now I am running out of time we can change it all the way to using something like me and the thing you the way you think about it the way add-ons work the way you build your own apps the way you communicate between different developers different teams doesn't change and I that's just a unique thing and I think it's a really good thing and it's it's not like we're we have a lot of we have a lot of compatibility so we must be spending a lot of time on it it's that's not really quite right I think when you account for the fact that you have to deal with people on old versions anyway the thinking about things in these terms and thinking about what like ways to give people tools that are easy to migrate and just making that part and parcel of how we operate has actually given us pretty good velocity yeah I have to figure out how to quickly go through so I just want like this is a thing that is a little speculative but also that add-on already exists I think basically I think you might like we don't have a good CSS story right now frankly and you might think oh that's yet another thing we have to do in Polaris so like clearly it's going to be impossible I think what's nice about the way we're planning on implementing it is that we can have a feature that's like this high-level feature like the scope style tag and we can use tools like that come out of the view ecosystem or the svelte ecosystem to compile that down into something that is a separate CSS file and then like existing ecosystem tools existing bundlers know what it means to import a CSS file like that is already a thing that we don't have to build so simply doing the transformation from the left side to the right side is enough with existing tools to get what you need and that also for the most part with some work includes like getting your post-CSS configs to be included and stuff like that right because what we're doing is we're leaning on the fact that importing from a CSS file has an actual meaning in the ecosystem we're not trying to reinvent it but we're still keeping the ability to define like what is the authoring format because just because you can import from CSS doesn't like that churns a lot in the ecosystem so we're keeping the authoring format stable but we're using it's like a much thinner layer now okay I'll try to go fast I already said this a bunch of times so I'm just going to skip past it but basically what we mean when we say that we're the together framework is just like there's one thing which is the component there's one thing which is a service and it's like over time across experience levels across teams across add-ons whatever ecosystem and that is basically what lets us be a framework that goes together that migrates together that builds new features together etc very like go read this thread basically this is a thread where people were like why do we need the concept of services and like me and Tom wrote a lot of words that basically amounted to it's good to have concepts it's good to have terminology that helps people understand things and I think services are an extremely good example of this paying its way in gold like basically no other framework even has the concept of like a service scope to an app because they don't have a concept of an app they have context which you have to blah blah blah and this is like every Ember user knows what this is it's obvious how to use it and it's good and it makes testing really good but you don't have to think about that okay by the way app instance is the actual real concept that ends up being true like having there's an app instance against it can be run all the while okay as an example very quick this is the thing that would work in an Ember app today you can have a Polaris component with GJS Octane component that uses the new like the new track stuff new class stuff and an Ember.component.extend and like import Ember from it and like that whole combination of things will work that doesn't mean that you want to do that but it basically means there's no like sharp dividing lines between things that force everybody to synchronize across changes right so it's hard to explain I think it actually goes into a lot of detail about why it's good but I think this is an example of what it means that it's good okay yeah I'll skip past this really I have a quick demonstration here which I will go quickly through but I'll I just want to say why I have it here basically there's a thing called introJS it's compatible Ember 218 if you look at its code it uses very old concepts turns out you can drop it into component template it works I have a little demo of what like what I mean by it works like it's this whatever it's good and then like you can move that into GJS file you you can do imports but you don't have to switch away from curly syntax where it's interleaving the old world and the new world there basically I don't I don't need you explain why but basically it just works you can add track state that also just works you are still using like the curly syntax totally fine you can switch to angle bracket invocation we actually got pretty far without doing it totally fine and like really what all this is about is it's easy to be like oh what is the point like the answer is when you are forced when you say like this is the old world this is the new world and you have to migrate across them every single change that you make that's any kind of significant at all creates like the whole ecosystem has to be like we are moving from the old thing to the new thing every single time and it just forces you to combine a whole bunch of things into one feature technically it makes add-ons all have to be like am I supporting v2 or v3 like people don't have to say am I supporting octane like you have to support octane but you don't have to say do you support octane and the old thing because supporting octane means you support the old thing by definition right I think there's a lot of the god that's talk goes into a lot of detail about why like how we do that but I think this is like really a fundamental thing that is happening in like under the hood of our design philosophy but it's like why everything is good okay that here's the challenge and then I'm done so I think everything I just said is good and I think it's why people are here like people are in the room people are believers people's apps like it's not a lie but there is a problem which is which we've described as the pit of incoherence and I think the problem with the pit of incoherence I have come to believe is that it actually grates against the actual pitch that makes ember feel good so that base that is basically like oh we should adopt ember because we can take people from team A and move them to team B like during the period of the pit of incoherence especially right now that means that like there's all this tinkering that has to happen that basically makes ember at the bleeding edge feel like not that different from the other frameworks that you're claiming ember is better than and the real kicker is that because ember is not that competitive with our peers right now you feel like part of the sales pitch that you have to make to your boss or your clients or whatever has to include and we're using the new stuff right so now you're using the new stuff and that is actually in conflict with the fact that you like that you're like you're getting these benefits of going together right I think we do need the technical strategy of additions but we have there's a problem that is beyond just a normal addition problem that abstractly exists which is we are just behind now like all the benefits are good they would be unique value propositions of ember but it's hard to make the case because of the fact that we're just frankly we have competitiveness issues right now and I think what is the point of Polaris the point of Polaris is not just like to do one more like here they go again I know people feel like that but like we've been like we haven't been like saying we're doing this all along what's happening is we've been incrementally getting here and I think Polaris is the point at which we could say okay we you know we move to V we adopt all the stuff and now we've closed the gap with our peer frameworks and now the part of ember that is good which is the working together like the sustainability story that is a thing that you could like really sell and not have to be like embarrassed about the fact that there's all these caveats that hopefully don't apply or that force you into a more tinkering kind of mode and I think critically and this is Ed is going to go into this in detail we need to do the Polaris has to involve us doing this in a way that is sustainable going forward so we're not like saying the same thing three years from now right so we need a strategy for closing the gap with the ecosystem that gives us all the benefits of having separate authoring format and like the things that are good about ember that make us that make ember unique and good in a way that does that is sustainable so that when the ecosystem does more things we can like pretty easily adopt the thing the ecosystem is doing and you still get all the benefits right so I think that is what is needed so up next the thrilling conclusion how we're going to make it happen with Ed Faulkner take it away