 All right, everyone. It's a Christian. Nope. Nope. Nope. Nobody. Yeah, it's just this one. Yeah, it's the room. There we go. I'm in your speaker. Yes. Okay, um, now I just need to get this out of the way. Oh, no, no. Why is this like suck on the screen? You can scroll it down and you should be, there should be a close-up on the top. At the top? There you go. Yeah. Wait, wait, wait. Wait, wait, wait, wait, wait, wait. There we go. Such great software. All right, everyone. So thank you so much. I'm so glad we have a packed house. Um, this is really exciting and I'm like super nervous. So I'm just like full disclaimer. Um, I, this is like my first time attending this conference and it's very humbling. Um, I think being with, um, people who I think who have like shaped and influenced my experiences on the web. Um, so I just really wanted to say thank you. Um, and yeah. Uh, so my name is Malhussain. Um, I am the senior open web engineer at Boku and I'm going to be, uh, talking to y'all about rethinking, Transpillation and JavaScript package distribution. Oh yeah. Anybody else excited? Yeah. Oh, I look no hands on the right. We did like a right East, East versus West. West one. No. Uh, oh, sorry. That was, that was classic. Not the intention. Okay. Cool. Well, um, so, um, So today's kind of, uh, uh, is what we're going to be, um, just, uh, I'm going to try to be as quick as possible, uh, to, um, get to the fun part. So I have a quick presentation to kind of outline and break out the problem statement. Uh, we have a surprise group activity that's going to be led by my co-facilitator here, Valerie Young. Yeah. Can we give it up for Valerie? And we, if we have time, we're going to do, uh, report, uh, report facts because I really want to hear from the problems, your voices, uh, and, um, and Valerie will also be helping, uh, facilitate that up on with, uh, some other awesome folks that are here today. And then, um, and then we have some closing thoughts and like feel good next steps. What's the future? Yeah. Yeah. And so, so a bit about me. I'm a first-generation, uh, American child Somali immigrants, uh, senior, uh, open web engineer, Boku and multi-lingual, a world traveler, I'm a technology community organizer and co-host of the web platform. And I guess I'm busy, right? That's the other synthesis. Um, so the problem that I'm excited to be talking to y'all about today, uh, is, uh, on distributing, uh, packages, uh, like we're distributing JavaScript packages that contain unnecessary flow and polyfills from TransFile code. Uh, and so would, would anyone, uh, would we all agree with that statement? Yes? NPM? No? Okay. Okay. I'm seeing, I'm seeing some conflicted people here. Uh, so let me, let me share my story. So how does my story intersect with this problem of bloat in our dependencies? Uh, so I recently, uh, actually that's yesterday, just a project that I've been working on for a while. I just launched, uh, it's a embedded video game console. Uh, so I've been working on a resource constrained, tiny single board, um, computer, uh, where I, you know, it's an electron based project and I have a luxury of like only targeting Chrome 74 and you know, I'm ready to like use all of the modern JavaScript. Um, and when kind of doing some performance and budget, budget analysis work and trying to figure out where is this bloat coming from? Uh, looking at my dependencies, you know, I found a lot of bloat. Uh, and it was really frustrating to me because I'm trying to, you know, I only need to target Chrome 74, which has a wide support for ES5 and a bunch of, uh, sorry, um, extra 15 and a bunch of other cool features beyond, beyond that spec spec here. Uh, but my dependencies, which are actually majority of my application were stuck in 2014. And so it was a really painful thing for me and I had to jump hoops and, uh, you know, uh, everything from like just, you know, use a source from GitHub and get around and PM ignores, uh, try to kind of monkey catch a solution for myself so that I could, um, just cut the bloat, uh, and, and save my, you know, uh, and improve performance for my, for my board. Uh, and so that was my problem, but why should you all care about that? Right? And, and I think you should care as kind of shepherds and stewards of the web platform. Um, most, this isn't a new problem that, uh, you know, most, uh, open source, uh, most projects that rely on open source, uh, uh, packages, uh, actually leverage them to a very large extent. Which means that, you know, the code that we write that's actually unique to our application is actually a pretty small fraction. Uh, I think, uh, there's a report that came out, uh, for JavaScript in 2019 and the stats were around 10 to one. You know, every 10 lines of code is someone else's and one line of code is yours. And so, uh, if you kind of take that metric and you look at the scale of the web and, you know, how obviously ubiquitous monitor applications are, um, that's a pretty big, big size of the web. Um, so it's a pretty big problem that we should all care as people who love and care about the web. Uh, so how does this affect web, uh, a web platform user experience, right? So the obvious answer blow, which is the company's first. Um, uh, uh, what it means to, uh, be a new internet user in emerging markets, working off, you know, uh, resource constraint devices, not necessarily a fancy work, like, like I had, but, you know, maybe a $10 phone or $30 phone, you know, data, your mobile data is currency, you know. So, so bytes matter in emerging markets, not only do they matter, but web experiences can be, like they're just detrimentally crappier with all that JavaScript load, right? And, you know, for, for, I love the web, it's in my, it's like, you know, I'm sitting over by my engineer, right? And I know you all love the web. And in emerging markets for people coming online for the first time, you know, they haven't had the luxury of ever owning a desktop device or not, or ever having any other way to get online, right? And so we have these, we have these, these experiences of what it means to be on the web that are shaped in these really constrained, on these really constrained devices. And we're competing with, you know, native Android apps that are already, like on the device that are in their language, that are, you know, that have pre-cached files that are faster to use and easier to use. You know, so why would a user in the emerging market like want to use this universal VM that's like not in their language that's slow and bloaty and like cost some money, right? And so take them a little step further, right? So as, you know, there's user-land experience of the web and as folks who understand, you know, the underlying mechanisms of the web and we're very privileged in small community, let's take a look and kind of examine, you know, what this means for the health of the web and why this is bad for all of us. And we want to first start with, again, our dependencies are a huge part, the majority of our web application code that we ship and they're stuck in 2004, a 14. We also have native platform features that are not getting used or that are underutilized, right? And so there's opportunities, there's missed opportunity here for kind of hardening the platform and really like robustly testing new features at scale, you know, which is like really unfortunate and very sad. Have you ever tried to debug, transpiled code anybody? Not fun, right? So there's, you know, there's a bunch of native debugging tools that we don't have access to in an easy way. You know, everything source maps to be able to kind of step through, you know, an ASAP function, cleanly, insanely, you know, and lastly, you know, all of the unnecessary bloats, it's not just the bloat, there's a bug factor that's actually pretty serious and distributed at scale. So, and lastly, unreadable code and all of that last kind of author intent, which is like just an unfortunate thing, you know, so the days of use source are definitely gone in modern drugs or toilet, right? So who's like, you know, so I kind of want to double click into the bug problem because I think this is one that's not often talked about in our community. And I have invited Henry Sue here, one of the big maintainers in Babel who I've been kind of workshopping a lot of stuff with as I've been getting invested in trying to fix this problem and what do we do to make this better? I've been talking to him and lots of other people and it's kind of, it's unearthed this world of like cryptic bugs at scale and, you know, and we're shipping code that's heavily transpiled, heavily polyfilled and we're building up upon that infrastructure, which now means that we're also relying on these bugs at scale, which, you know, which means, you know, library authors that like, even if they want to publish a native, like untranspiled polyfill, you know, real JavaScript, right? Like stage for JavaScript, they don't even feel comfortable doing it because people have come to rely on bugs and the implementation of various kind of polyhills and bugs that we've exported throughout our cooling system. And so I just want to kind of walk you through this matrix a little bit. Can everybody read this as I'm here for folks in the back, can I get a thumbs up? Yeah, fantastic. So this is, there's subtle differences in these little boxes but they're all very important to understand. So we have transpiled code. I'm going to start like one, two, three, four. So transpiled code and polyfills can never, can sometimes never, ever, ever, ever, ever, ever, ever equal native implementation. Can we all agree on that? Right, so that's problem number one. Problem number two, if that's interesting, transpiled code and polyfills have been implemented and they work, but everybody knows software has bugs. There's bugs you know about, bugs you don't know about. And there's bugs that we do know about and bugs that we also sometimes don't know about until much later that we're kind of shipping and exporting on scale. So that's bad, right? And so there's this weird responsibility matrix of like who's bug is it anyway? And so let's look at the table to looking at browsers. So one of the problems is, you know, we have transpiled code and polyfill code, sometimes it's for different targets that we're shipping for different browsers. But another problem in kind of trying to unify interoperability here is that we have variable native support for features. Additionally, we also have browser bugs, right? So is it a browser bug? Is it transpiled or bug? Is it like a half-baked feature? Is it, you know, so it's pretty complicated. And when you talk to folks in the bundler and transpiled compiler community, and you talk to kind of library authors that are publishing at scale, you'd be surprised that the number of kind of cryptic issues that pop up that really hold the web back, yeah. Oh, fantastic, yeah. Okay, I'm gonna talk faster. Okay, so, and lastly, I just kind of want to put it out there as a public service announcement. You know, transpiled code and the use of a polyfill is meant to be a stopgap, right? It was never, ever, ever, ever been to be the status quo. It was never meant to be something that we just stuck with forever. And they kind of become these fixtures, these permanent fixtures that we just happily install and don't often question. And so there's an interesting case that I'd like to point out here because we talked about two kinds of code, right? There's like the code that you've authored and there's the code that came from, you know, our wonderful contributors from all around the world. And web developers, I think, have solved this problem for their application code by creating a dynamic way for us to be able to pick our compile targets and therefore kind of ship like the minimally transpiled version of our code that's gonna uniformly work for the browsers that we're targeting. And so this case that he's kind of called web developers stage less than four JavaScript and our level of proposals and battle presets. So it's a really simple slide that kind of demonstrates our first familiar with battle preset M and assuming most people, some will have people, can I get hands? Are you familiar with this? Okay, okay, so for those who are not, so when we first kind of began our six to five, like, you know, a shift of code bases, we can have these yearly presets where we say, okay, you know, you can transplant down to a baseline of 2015 and then 2016 roll around and we said 2016 and then 17. We just kind of push the baseline forward and forward and forward and forward. And then we realize, oh, no, no, no, actually, you know what, that was a bad idea. This really isn't scaling well. We created this awesome way of basically dynamically kind of adjusting our compile targets. And that's great. So this is kind of fixed in some sense for web application code, but there's a serious cost to like iterating scale because those presets that I showed you 2015, 16, 17, they still have really wide scale usage on the web. And it doesn't matter. Henry's right here, he can tell you like, it's been deprecated for years. 2015, as of this week, was still 1.2 million weekly tablets, like, which is kind of insane. So as web developers, there's a pretty large cost to kind of some of the four sites that we make even with good intentions. And I think for me, you know, in thinking about this problem, I've learned that like this is a pretty multifaceted problem. And multifaceted means this is something that touches every single element of our distribution pipeline. It starts all the way, like it starts when, you know, a library author decides they're gonna publish and it ends when the last quite of JavaScript has been parsed and like downloaded by the user on a given target. And so in thinking about the scope of this distribution pipeline, I've identified these kind of nine stakeholder groups as interesting and not actually, sorry, as kind of critical to coming up with a solution for this problem. Because I think we've kind of tried to solve it from certain angles and that's not really gonna work because this isn't something that's going to ever just be solved by the node community or by like Webpack or by Babble. Like, no, this is like a full, like an ecosystem wide thing. And so I'm just gonna read out all of these and helps you to synthesize it. JavaScript library authors, NPM engineering, NPM being our kind of de facto package distribution for modern one. Babble, TypeScript and other compiler maintainers, bundle maintainers, Web developers. And Web developers here is kind of a big frame because for me it's Web developers that are working at scale. Web developers that are working kind of at an intermediate scale and really for me it's about low floors, you know, keeping in mind that not everybody has a fancy engineering team and can spend hours tweaking their Webpack config files, right? So we have content delivery network folks. I couldn't decide whether to call them engineers or infrastructure people. So maybe somebody here can help me come up with a better word after this session. I just called these CDN folks. No governance, Web platform engineers and Web specification authors. Almost done, yeah, yeah, literally we're almost done. Perfect, so I'm being like ushered off the stage. So these are the people that I think are important to this conversation. That's what you need to know. And what I'm asking you today, why I came here today, I see this summit as a really interesting opportunity to kind of get a snapshot of data from people that are, like that fit a lot of those buckets. I also think it starts here, right? That the front-end community is kind of high-trapped NPM. We all know that. Hour is dead, no more tweaking, right? So for better or worse, you know, we've hijacked your ecosystem for lots of good reasons too. And so I think starting here for me is actually a very important first step in kind of understanding better understanding the landscape and better understanding what we need to do and how we can move forward. And so we're gonna do a really quick facilitated discussion next where all I want everybody here to do is kind of think a little bit about, we're gonna think about hopefully you know what group you belong to. And if you don't belong to anyone, like I'm just gonna do like a math not random, this big one. And also tell me after this, if you think that there's a blind spot here. But with your stakeholder hat and keep in mind that you can have multiple hats, how does this problem affect you, right? And I told you how it affected me, somebody who's trying to compile or trying to ship a product on a resource constraint device. And I told you how I fixed it in a hacky way. And for me, the requirements to any solution is definitely gonna be I need source. And that's not gonna be the same requirement for everyone, but that's mine. And so all I want to know today is how does this problem affect you and how does it intersect with your workflows as of years and what are the requirements? And what the non-goals are, right? We're not gonna come up with a solution in 30 minutes. Like that's just not gonna happen. And I don't want that to be the focus of the conversation. And so we're not designing a solution. We're not driving consensus, right? And we're not gonna discuss implementation details. So this is just a rapid fire brainstorming session. And with that, we're gonna have some facilitators. So Valerie's gonna be leading the facilitators and I'll kind of be jumping in and out. We have Valerie Young, Tara Minixic, I apologize. Philip Dunkel and Adam Mills actually just about stand up so that we can see you and the faces. Philip, Jory, here's Jory, story of Jory. All right, Jory, Tara, Philip, I'll adjust the slides for posterity data. Adam and Valerie and myself and Mel. And so, okay, so we're actually breaking up into groups. So you need to sit closer to each other. So everyone who's participating in this discussion, which I think is over in the room, does someone secretly go and work for work instead of hanging out at the conference, laptop. But actually bring your laptop with you because you're gonna need it. So everyone in the room, if you can fill into tables of six, these first four tables here and the four tables over here along this wall so that there's space, but everyone come up and sit in the seat, one of those four tables, so that we could all work out. So you have eight groups of six. So bring your laptop if you want. So this four table, you can stay there if you're in one of these four tables, but if you're not, come over and sit down in one of these four tables and the two first four tables. Yeah, these four tables? Four tables. Yeah. I would highly encourage everybody to move around. Please don't sit near a friend, please. Just kidding. That's impossible. I don't want to be bothered by this. I don't want to be bothered by this. I just want to go back to the slide. Oh, someone, you'll be more sensitive. He'll give instructions once you're sitting in groups of six. This is great, this is great, this is great. Please, can you guys, We actually have five groups, I guess, right, one, two, three, four, five, okay, so next slide. You're now getting instructions about what to do. So if I have a bird's attention, please. All right, if you can hear me clap once. If you can hear me clap twice. If you can hear me clap three times. Okay, so next slide. So here's two steps. There is a mail created a form for you guys to give the feedback to her so that she can get all of your insight and ideas. The form, there's a, you know, one of those things QR codes and also a bit that you are out so you can go to it. Well, if you want just a few people in each group could be a scribe and write down people's ideas in the form or you can submit the idea yourself in the Google form on your phone or on your computer. So that's the computer phone part of this. Yeah, and the form has three questions. One is your group number. That was just so you could look at your response later if you wanted to search for it in the, it will publish the responses. So this is group one, two, three, four, five. Counterclockwise. So there's a group number. There's also for the idea that you're submitting and that form, you'll submit the form multiple times each time you feel like you have an insight that you need to, you want to tell them L or the group that's going to be working on this problem. So you submit it multiple times with your group number. Also what you kind of, what perspective you're bringing? Like what stakeholder hat you have on? And then answers to the questions that Amel was asking before. Like how is this problem affected you in the past? How have you encountered it? How does it affect your work? That's one question and the next question is what are some constraints you have on the solution to this problem? So now in your little groups, because hopefully you don't know someone in it, go around and introduce yourself and maybe a little bit about what you do or maybe just your stakeholder hat if you have one. And then discuss or record the problems in the URL link. We have these lovely facilitators, raise your hands. Some of them have already claimed the group so you two each get that group. Tara, do you want to join this group here at the end? Yeah, enjoy over here. They're just here to help kind of like help keep you on track and maybe point out ideas when you should be spending them in the farm. And you guys will get an facilitator half of the time. So everyone else gets a facilitator. Okay, great. So go ahead, introduce yourselves, discuss. Okay, so that's, uh, yes. This actually took me almost like 24 hours. Yeah. Hello, Berlin. Can anybody hear me? Hi. Hi. Rick here from the internet. I'm wondering if there's, uh, all the discussion group numbers I've been accounted for. And if not, can I use number eight to do a remote submission? Thanks, Valerie. And this is not exactly the plan. And so if you happen to know, there's a lot of terrible networks that are trying to access to you, but you're not going to be able to do that. But anyway, that's the truth. But anyway, so Jayne, problem. Next question is, what are your actual streets for the solution that you find in these streets in the United States? And we're not just sending support, we're going to work with them. Yeah, yeah, yeah, yeah. So yeah, so that's why I'm pushing ahead. Yeah, yeah. Everybody. Okay. So that's why I'm giving you so many video ads. Okay. So that's why I'm giving you so many video ads. All right. So All right. So All right. So Okay, so Okay. That seems to be the next thing we can do. Okay, enough of that. Okay. That's it. Super crazy question. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. All right, everyone. So just like one more minute or like, yeah, okay, we're good. Okay. So we're going to bring you guys back to focus. So. Okay. You can hear me have once. So, So, how, how, what, like, can I get a general like, how was this for everyone? This is interesting. It's helpful. Yeah. Like I like to go over there. Yeah. Cool. All right. So I think what we want from you now is we don't have time to obviously hear from everybody individually. The data set will be published. We'll link it to the, to the issue as well as like, science and stuff like that. But what I really like is if we could just go around like each table, just kind of you can, if you all want to summarize a few points that you kind of, that kind of came up in that you discussed and then everyone else can like, check out the data. And then we can, you know, So I'll just ask for a volunteer for me to summarize a few points so that everyone gets to hear what I'm saying. So table number one. Anyone? All right. So, answering how does this problem affect you? You had a number. Oh, right. Yeah. We had actually for both participants. Oh, text in the chat. Right. Um, a number of points about trans, violence and stuff like that. So, yeah. So, I'll just ask for a volunteer for me to summarize a few points so that everyone gets to hear what other people are talking about. So table number one. Anyone? Yeah. So, I'll just ask for a volunteer for me to summarize a few points about transpiler fatigue. Learning curve is hard, especially if you're building projects that require typescript and babble at the same time. Just training developers. And those tools are just challenging. Bundler fatigue is also hard to debug. Problems have happened when you're. Updating an agency tree or seeing any changes in that tree. And the problems are not 10x because you get a trace information. Another interesting point is like when, when big, big websites have multiple applications like single page applications are served from the same domain. All of a sudden you have, you know, and level complexity of all the different packages and what you're doing on the same domain. And that affects the user experience as well. In terms of constraints or requirements. We can go a couple of interesting ones. The platform in the map structure should facilitate separation of concerns of whatever the developer experience needs, i.e. tooling and transplanting and so on. So, versus the user experience needs, i.e. the browser rendering or the server cyber running process. There's a mechanism for. Allowing both of those things to operate independently. And not believing that that context. And also tooling that provides. Deterministic bundle sizing choices during the development process. You're going to clap. The bar step really high table number. Also for those of you leaving, there's a really important part of the presentation lab. So I would highly encourage you to say. Like one tiny little. That doesn't work. So. This is actually a group decision. So. With our, I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. I'm a speaker. So. Like I said, we actually reject the actual premise. We believe that transpiling is very good. We examine the number of things to hide from the difficulties of doing it. A code load. And the reasons why we actually transpile. There's some difficult edge cases we have. Using types and being forced down the transport to an exact motion. No. This is a big enterprise. We're very restricted. We do have latest version, but we only get one version of latest version. Because that's all we get. So as a whole, we agree with the minimalist approach to the package is going out. But we do not believe there is a problem to be solved. Can I ask you a follow-up question? This is fascinating. So this is how complicated it is to solve this problem of drive consensus. And was everybody at your table typescript, like from the typescript community? No. So I'm curious for the folks who. That was an edge case. Interesting. That's fascinating. Okay. That's cool. Thank you. Group number three. Has a lot of JavaScript. Library authors and Babel. We felt that this made us not very representative of a typical JavaScript using population. Babel. We decided is both a problem and a solution. The library maintainers among us are very happy that we have Babel to allow us to address. I think that's interesting. When we go out and look at the wider JavaScript audience, we find that people often have tool chains that they inherited or perhaps set up for own cookbooks. And there's a lot of complexity there that they're not necessarily ready for. They go off the path. They end up feeling resentful of this complexity that they didn't sign up for. Sometimes bounce out of transpilation, even though it could benefit them because they best in learning the tools. So we point to toolchain complexity as one of our problems. Not many of us use TypeScript, but we also find there's complexity in missing documentation there that make it more difficult to use than we would like it to be. I would uh, so I think we kind of bashed on Transponder here. I'm going to stay and it really just comes down to a number of factors that most people don't take the time to understand what the code has been transpiled to and then end up with a number of issues when they need to solve up the performance or functional issues. Some of the other issues is when you have multiple libraries that are three easy transpiling that use competing polyfills, you know some different versions of the promise or any promises or you've seen a few others where they end up conflicting with one another trying to play the same polyfills to the same intrinsics. Yeah, I would be talking about some of the comparisons that I've made it out on and some of the same kind of issues there. So we went a little afield a bit of the topic, but Oh microphone I love it. So I have no idea what other people said and so I guarantee I'm just going to repeat what the other table said but I was at seconds but the two things that came up we submitted three forms there's really two basic problems and I hope I can remember yes I can. One is that debugging experience is awful with transpilation which is not surprised anybody I think you said that I'm sure everybody else said that awful both in the browser and awful awful error for in node on the server because node does not support source maps and then the other thing that came up is that people transpiled their code browsers and stats and benchmarks show that that code is faster than using idiomatic JavaScript. So browser you know people people who are working on optimizing VA and other jobs don't bother optimizing for the idiomatic JavaScript because people aren't using it it's kind of a chicken and egg problem people aren't using the idiomatic JavaScript the browsers aren't going to prioritize optimizing for it so it never gets optimized and people never stop transpiling. That's a huge phenomenal drop dude you should be doing this talk. If I didn't know if I had any idea how expensive this was and it wasn't a lot I totally might drop. So can I ask is that the last proof knowledge and did everybody else submit the feedback that they just verbally shared like fantastic so first of all thank you thank you thank you this was an exercise in trying to understand take a snapshot of the landscape drive requirements get constraints understand where people disagree understand where they agree so that I can kind of shepherd this this forward throughout the community and so what's next how do we keep this conversation going I'll be here at day two this this data set will be published we can have lots of holly conversations tomorrow if folks are inspired and want to like grab a room and have a you know unconference session or what a breakout session on this I'm happy to do that as well but I kind of want to be a little bit more directed in my description of this of this problem so I think it's obvious it's going to take a cross-functional group to do this this is a problem that spans both the node and the web communities as well as all the referral infrastructure that makes the web happen and I am putting forward an initiative after just talking to lots of stakeholders in this community it's kind of actually been it's a little bit it's been an informal initiative already but it's as of like today like literally like New York just created and to basically solve this problem so it's an independent job script package distribution community group whose sole focus is to drive a solution and and figure out how how we can solve this problem throughout our ecosystem interested in contributing feedback if you're interested in kind of helping shepherd a proposal whatever like we want it and please combine me and that's an order that's created so I think if you're what I ask is if you're interested in just like uh keeping abreast of the conversation issue number 170 is my issue on the node repository just thumbs up it and I will combine you or combine me as well which node repository oh I apologize thank you um I meant the summit repository thank you thank you very much for asking me to clarify that uh issue 170 170 yeah and yeah and so um and then I'm going to publish the results of this so you guys can all synthesize it and like and whatnot and I kind of this is a huge problem right you guys agreed that this is a massive problem we're unfurling ourselves from all this kind of complex technical debt but I want to leave you this with this quote never doubt that a small group citizen of concerned citizens can change the world indeed it is the only thing that ever has and so with that I say thank you for your time and let's go have dinner