Podcast appearances and mentions of sam selikoff

In today's episode, we go to war with Sam Selikoff, co-host of the Frontend First podcast, and specialist on everything Frontend related. We have an amazing conversation where we discuss Sam's journey, as he also did some backend work in the past, we talk about abstractions, what JavaScript is doing differently from other languages and frameworks, why the frontend should be driving the backend and not the other way around, and finish it off with a discussion about RSCs (React Server Components). Learn back-end development - https://www.boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm Frontend First: https://frontendfirst.fm/ Sam's X/Twitter: https://x.com/samselikoff Sam's Youtube: https://www.youtube.com/samselikoff Timestamps: 00:00 Intro 00:51 Who is Sam Selikoff 02:12 Abstractions - Should you go a level deeper? 06:37 What was Sam's talk about 10:51 What is JavaScript doing differently? 19:10 Do you want the frameworks to push more features out of the box for backend work? 24:04 Strong opinions on a library level 30:29 Shipping more standardized interfaces 37:06 The frontend should be driving everything in the backend 39:12 Your types should flow from the database to the frontend, but not the product decisions 46:53 React Server Components 58:49 Where to find Sam

In today's episode, Sam Selikoff, educator and consultant in modern UI development, explores the depths of React and its place in the ecosystem. He talks about React's evolution, compares it with other frameworks, and discusses the innovative potential of server components and new React primitives. Links https://samselikoff.com https://twitter.com/samselikoff https://www.youtube.com/user/samselikoff https://github.com/samselikoff We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Sam Selikoff.

Sam Selikoff, cofounder of BuildUI, returns to the show and we talk all about NYC! New York City, one of my favorite places.  Brian and Sam's conversation was recorded on December 15th, 2023.Brian's update was recorded on March 8th, 2024.(00:00) - Software founder life in NYC with Sam Selikoff (04:45) - What is the crowd like? (06:54) - New York's downfall - sports teams (08:42) - Working remotely in NYC (13:16) - City life vs. Suburb life (15:08) - NY energy (crazy and all!) (16:56) - Cost of living   Brian's Product StudioMy product studio, Instrumental Products, is where I partner with SaaS companies, creators, and founders to take product ideas from concept to launched.  Got something to ship?  Let's talk!Brian's YouTube channelSubscribe to my YouTube channel where I'm building products and showing the process.Brian's NewsletterSubscribe to my newsletter where I send my best ideas and stories from working on products.This Podcast on YouTubeThis podcast is on YouTube!  You can watch full episodes on video by subscribing to the FSF Podcast Channel on YouTube.

Sam Selikoff, cofounder of BuildUI joins me for a wide-ranging (and sometimes technical) conversation about his journey as a software engineer, and his business teaching UI development with video courses and YouTube.  Brian and Sam's conversation was recorded on December 15th, 2023.Brian's update was recorded on March 8th, 2024.(00:00) - Teaching User Interface Development with Sam Selikoff (BuildUI) (06:33) - Sam's elevator pitch (08:02) - Marketing as front end only (at first)z (11:36) - BuildUI courses and staying up to date (20:03) - BuildUI's UI (...and UX) (23:22) - Sam's time at TED (28:06) - Transition from TED to BuildUI (31:31) - BuildUI origin story (34:41) - Pivoting moments for BuildUI   Brian's Product StudioMy product studio, Instrumental Products, is where I partner with SaaS companies, creators, and founders to take product ideas from concept to launched.  Got something to ship?  Let's talk!Brian's YouTube channelSubscribe to my YouTube channel where I'm building products and showing the process.Brian's NewsletterSubscribe to my newsletter where I send my best ideas and stories from working on products.This Podcast on YouTubeThis podcast is on YouTube!  You can watch full episodes on video by subscribing to the FSF Podcast Channel on YouTube.

Sam Selikoff is the founder of Build UI, Inc. They unpack a myriad of discussions surrounding JavaScript and its applications. They delve into topics such as RPC resurgence, React server components, and the challenges and solutions around integrating design and components. A variety of technical concepts, tools, and frameworks, including Tailwind, Redux, and Remix, are also explored. Additionally, the episode touches upon important mental health conversations, personal experiences, and the pitfalls of fragmented media subscriptions. SponsorsChuck's Resume Template Developer Book Club Become a Top 1% Dev with a Top End Devs MembershipSocialsTwitter: @samselikoffPicksAJ - No BackendAJ - Home AssistantAJ - CloudFreeAJ - AmeriDroidAJ - Chaos WalkingDan - Blue Eye SamuraiDan - Samurai JackSam - Lessons in ChemistrySupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacy

Ian & Aaron are joined by Sam Selikoff to discuss React Server Actions & Server Components, why it's important to have one set of opinions, and yes, the infamous SQL Injection Slide at NextConf.Sponsored by LaraJobs & Screencasting.com.Sent questions or feedback to mostlytechnicalpodcast@gmail.com. (00:00) - The Most Memed Man on the Internet (09:06) - High Floor vs. High Ceiling (19:20) - What the Hell Is Next? (23:22) - The Third Phase of React (29:09) - Your App Is Not Unique (35:23) - Server Actions & Server Components (51:33) - CallYourMom.Com (01:00:56) - Fat Models, Skinny Controllers (01:14:16) - One Set of Opinions Links: Sam's talk at NextConf - 'How Next.js is delivering React's vision for the future' Ember.js BuildUI Turbo (formerly Turbolinks) Next Next.js Conf 2023 Radix UI Remotion 'React is a programming language for UIs' (YouTube) AdonisJS

Even though we're missing Andrew today, Chris and Jason keep things lively, kicking off with a fun chat about candies, and unusual dislikes. Then, they dive into the professional world where Jason shares insights from his Job Boardly project and talks about the challenges and tools he found useful, such as Imperavi's, Article. Chris and Jason have a discussion on various text editors, focusing on Basecamp's Trix, we hear the difference between Redactor X and Article, and the Revolvapp, which is Imperavi's email templates editor.  Chris and Jason go deeper into the world of JavaScript development, and they discuss their struggles with customizing elements using CSS and Tailwind.  They also share their thoughts reminding developers to view themselves as Ruby developers, recognizing the broader capabilities of Ruby beyond what Rails offers. Stay tuned for a fun episode and hit download now to hear more! [00:00:31] Chris and Jason discuss the absence of Andrew and have a conversation  about specific candies and personal preferences. [00:02:22] The conversation shifts to Jason's project, Job Boardly, where he's been actively working on giving users more control over their job board's appearance, and he shares all the secrets and talks about Imperavi, a website editor, and Article. [00:07:03] Jason acknowledges the potential pitfalls of storing HTML but praises the user experience offered by the editor, enabling users to directly see the impact of their edits. [00:07:56] Chris and Jason debate the complexity of using Trix, and comment on the lack of progress seen in public updates.[00:09:50] What's the difference between Redactor X and Article? Jason explains Redactor X is a pure WYSIWIG editor, while Article incorporates both text editing and content layout functionalities. [00:11:35] Jason talks about the Revolvapp, discussing its advantages, including having all the functionality from a single source and it's not a subscription.  [00:13:00] Chris discusses using the EL transition library for Tailwind CSS stimulus components, noting the library's simplicity but highlighting some complications when animations overlap due to quick mouse movement.[00:18:21] Chris talks about simplifying his codebase and moving away from certain older features.  He discussed his decision to discard bundle and compile using the esbuild for modern imports and CommonJS, and he mentions Adam Wathan's keynote at Tailwind Connect with Sam Selikoff showing off some amazing stuff.[00:25:55] Jason and Chris converse about their struggles with customizing the look and feel of elements using CSS and Tailwind.  They talk about the benefits and challenges of using Tailwind with Rails, particularly as it relates to component-based projects. [00:30:42] Chris discusses the implementation of getters and setters in a single method. He points out that if additional functionality such as sidecar or JavaScript isn't necessary, and a lot can be accomplished using pure Ruby. [00:36:04] Chris and Jason discuss the possibility of using pure forms or creating custom tools instead of relying solely on Rails provided tools.  [00:40:05] They remind developers to view themselves as more than just Rails developers, highlighting the importance of understanding and utilizing the broader capabilities of Ruby beyond just what Rails offers. [00:41:05] Jason brings up his experience with earlier versions of Laravel that had a form builder which later got phased out. He praises Laravel's way of handling inline errors. Chris expresses his views about the tendency of developers to over-engineer forms. [00:44:54] Chris adds his thoughts on “conceptual compression,” discussing he balance between abstracting processes and maintaining the ability to drop a lower level when needed.[00:46:23] They discuss theirs experience and observations from using Adam's browser tools and watching his keynote, and they mention how the early days of Tailwind were challenging due to configuration issues. Panelists:Jason CharnesChris OliverSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterImperaviArticle Imperavi Article & Redactor XRevolvappTrixTailwind Connect 2023-Keynote (YouTube)Ruby Radar TwitterRuby for All Podcast

This conversation covers: Mirage's role as an API mocking library, the value that it offers for developers, and who can benefit from using it. How Mirage empowers front end developers to create production-ready UIs as quickly as possible. How Mirage evolved into an API mocking library  How Mirage differs from JSON Server  Sam's relationship to Mirage, and how it fits in with his business. Sam also talks about open source business models, and whether Mirage could work as a SaaS offering. One interesting use case for Mirage, which involves demoing software and driving sales. Links Mirage Sam's teaching site Follow Sam on Twitter Subscribe to Sam's YouTube Channel TranscriptEmily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Emily: Welcome to the Business of Cloud Native. My name is Emily, I'm your host, and today I'm chatting with Sam Selikoff. Thank you so much for joining us, Sam.Sam: Thanks for having me.Emily: Yeah. So, today, we're going to do something a little bit different, and we're going to talk about positioning for open source projects. A lot of people talk about positioning for companies, which is also really important. And they don't always think about how positioning is important for open source. Open source maintainers often don't like to talk about marketing because you're not selling anything. But you are asking people to give you their time which, at least for some people, is actually more valuable than their money. And that means you have to make a compelling case for why it's worth it to contribute to your project, and also why they should use it, why they should care about it? So, anyway, we're going to talk with Sam, about Mirage. But first, I should let you introduce yourself. Sam, thank you so much for joining me, and can you introduce yourself a little bit?Sam: Sure. My name is Sam Selikoff. These days, I spend most of my time teaching people how to code in the form of videos on my YouTube channel, and my website, embermap.com. Most of it is front end web development focused. So, we focus on JavaScript. I have a business partner who also works with me. And then we also do custom app development, you know, some consulting throughout the year.Emily: Cool. And then tell me a little bit about Mirage.Sam: Yeah, so Mirage is the biggest open source project I've been a part of since falling into web development, I'd say about eight years ago, I got into open source pretty early on in programming, kind of what made me fall in love with web development and JavaScript. So, I was starting to help out and just get involved with existing projects and things that I was using. Eventually, I made my way to TED Talks, the conference company where I was a front end developer, and that's actually where I met my business partner, Ryan. And we were using Ember.js, which is a JavaScript framework, and we had lots of different apps at TED that were helping with various parts of publishing talks, and running conferences, and all that stuff. And we were seeing some common setup code that we were using across all these apps to help us test them, and that's where Mirage came from. There was another project called Pretender, which helped you mock out servers so that you could test your front end against different server states. And we first wrapped that with something called Pretenderify, and then it grew in complexity. So, I was working on it on my learning Wednesdays, renamed it to Mirage, and then I've been working on it basically ever since. And then, the other big step, I guess, in the history is that originally was an Ember only project, and then last year, we worked on generalizing it so that it can be used by React developers, React Native developers, Vue developers, so now it's just a general-purpose JavaScript API mocking library.Emily: So, we would say that the position is an API mocking library. And—does that sound right?Sam: Yeah. If I had to say what it is, I would say it's a mocking library that helps front end developers mock out backend API's so that they can develop and test the user interfaces without having to rely on back end services.Emily: Why does that matter?Sam: It matters because back end services can be very complicated, there can be multiple back end services that need to run in order to support a UI, and if you're a front end developer, and you just want to make a change and see what the shopping cart looks like when it's empty. What does the shopping cart look like when there's one item? What does it look like when there's 100 items, and we have to have multiple pages? All three of those states correspond to different data in some back end service, usually in a database. And so, for a front end developer, or anyone working on the user interface, really, it can be time-consuming and complex to put that actual server in that state that they need to help them develop the UI. That can involve anything from running, like, a Rails server on their computer to getting other API's that other teams manage into the state they need to develop the UI. So, Mirage lets them mock that out and basically have a fake server that they control and they can put into any state they need. So, it's like a simplified version of back end services that the front end developer can control to help them develop and test the UI.Emily: And when you first started Mirage, did you think of it as an API mocking library?Sam: Not exactly. We used it mostly because of testing. So, in a test, it's usually a best practice to not have your test rely on an actual network. You want to be able to run your test suite of your user interface anywhere, let's say on an airplane or something like that. So, if your user interface relies on live back end services, that's usually where you would bring in a mocking library. And then you would say, okay, when the user visits amazon.com/cart, normally, it would go try to fetch the items in your cart from a real server, but in the test, we're going to say, “Oh, when my app does that, let's just respond with zero items. And then in this next test, when my app does that, let's respond with three items.” So, that's the motivation originally, is in a testing environment, giving the UI developer control over that. And then what happened was that it was so useful, we started using it in development as well, just to help during normal times, just because it was faster than working with the real back end services.Emily: Do you think there are any other projects that do something similar?Sam: Yeah, for sure. I think the most popular one is called JSON Server, which is a popular open source library that lets a front end developer put some data in a file, and then you point JSON Server to it, and then it just gives you an instant mock server you can use to help develop your app.Emily: So, what's the difference between Mirage and JSON Server?Sam: The difference is that JSON Server is made—it's really optimized for giving you a development—kind of a fake server as fast as possible, but it comes with a certain format that it gives you the data in. So, what ends up happening is that it can help you get feedback and build your UI faster, but eventually, you're going to need to point your app at a real API server, whatever you planning on using in production. And so the way JSON Server works might not correspond—in fact, often doesn't correspond with your actual API. So, Mirage fills that gap because Mirage is designed to be able to faithfully reproduce any production API; there's ways to customize how the data comes back so that it matches so that as you're developing your actual user interface against Mirage, you can have confidence that it'll work once you switch over to production.Emily: Is Mirage slower than other options?Sam: Not performance-wise because they're all JavaScript code that runs in the browser, but JSON Server is really optimized for just getting started as fast as possible because it comes with all of those pre-baked conventions about how the data is going to be moving back and forth. So, with Mirage—it can be faster, it depends—but with Mirage, you need to learn a little bit more in order to understand how to faithfully reproduce your production API. But I think it's faster because in the long run, if you're writing code against a mock server that doesn't match the interface of your production API, then you're just going to be having to change that application code that you're writing.Emily: How much do you talk to other people in the Mirage community, and talk about how they're actually using it?Sam: I felt more in touch with the users when it was an Ember project only because Ember is a more niche-type community. Whereas now, there's folks using it in React and Vue, like I was saying, and Angular. And so, we get issues almost every day on the project. It's not like a mega-popular project, but it does have enough people using it that people will ask questions, or open an issue almost every single day. And so I try to stay in touch with the users through that, basically. And then when I went to conferences—you know, before 2020—I would love to talk with people about it, or people would just bring it up. That's kind of how a lot of people know me on the internet. So, I would say that I do it in kind of a passive way. I haven't actively gone out to talk to them, partly because it's an open source project so it doesn't contribute to our revenue. We have some ideas for how that might happen one day, but as of right now, we can't justify doing proper product development on it in the sense of spending time doing customer interviews and stuff because it's a free project right now.Emily: That is my next question, which is, how does it fit in with your business in the larger sense? You know, how you put food on the table? And what are your goals for the project?Sam: A good question. I mean, it's really aligned with our overall mission of, of everything that we do because me and my business partner, Ryan, we really want to just help people get better at UI development, we want it to be easier, we want to help empower more people to do it because we think it's powerful tool in the world, and it's just too hard right now; there's so many things that are hard about it. So, that goes back to our consulting and our teaching; mainly our teaching. That's our main mission. And then Mirage is really—the purpose of Mirage is to enable front end developers to do more kind of with less, so they don't have to run a Docker container or get an SQL database up just to change some CSS for a given server state. So, it fits into that mission. I've been doing open source long enough to know the pattern, and it happens over and over again, where people work on something, it gets popular enough that they start opening issues, and it becomes a maintenance burden for the maintainers, and then they try to stay up late closing issues, they get burned out, and then the project kind of rots. So, that's something that happens a lot in open source. And so, over the last five years or so of working on Mirage, I've been more involved, or sometimes step back if I need to spend more time on other things, but I'm really interested in making it sustainable, and I know some people in the open source community who have made their projects sustainable financially, other with a pro plan, or support plan, or different related services. So, if we could snap our fingers, that would be what would happen, and that's what we're working on now.Emily: Which one of those open source business models do you think is most appropriate?Sam: At this point, we basically are trying to not guess that answer because we think the way to find out which one it is, is to get a critical mass of users and listen to what they're saying. So, on our podcast, we interviewed Mike Perham from Sidekick, who runs Sidekiq and Sidekiq Pro in the Rails community for about 10 years, and he makes really good money. Sidekiq Pro came about because the enterprise customers of Sidekiq were asking for more robust job servers and all this kind of stuff, so there was a natural path for him to making a pro version that he could sell to enterprise clients. And so that's worked out really well for him, and the rest of the community gets to use the base version for free. And I love that because I do love this zero-cost to entry to open source. And then my other friend, Adam Wathan who works on Tailwind, he's made money to help Tailwind be sustainable through education and courses, and then more recently, a project called Tailwind UI, which is pre-built UI components with Tailwind. And that, again, came about from people asking for that after he was working on Tailwind. So, I think the best way to do it is to get that critical mass of users to the point where you know what they're asking for, you hear over and over again, and then it makes sense to go forward with that.Emily: There's also a third option, which is a cloud service, and I'm just curious—like a complete SaaS offering—have you ever considered that?Sam: Absolutely. There's a really cool opportunity there for Mirage because your Mirage server usually lives alongside your front end code so that when every individual front end developer pulls the project down, starts working on it locally, they're running their own Mirage server. But some of the things that people have done organically with Mirage is, create a certain configuration of a server state—let's say for a demo—so let's say they create a shopping cart, or let's say they're working on a financial piece of software, and they need to show what it looks like with three clients and four contracts, and here are the products that we sold and how much money they are. People will make up a Mirage scenario with that specific set of data that their salespeople take and use on sales calls. And that way, again, the user interface looks fully realistic, it's a fully working UI that is talking to Mirage, but now you don't have to worry about the actual back end servers going down or anything like that. And so, we've had this thought of a hosted Mirage, basically like a Mirage cloud, where even non-technical people could tweak the data there, and then again, they don't have to get involved with ops people or anything like that. And that could be really powerful. So, there's a ton of ideas there. I think our hesitation with our company, Embermap, it's worked to some extent, but it's not grown to the point where it can sustain us, and so that's partly because of the market issue, Ember being a little smaller. So, we're nervous to jump into any particular solution before we feel there's a proven market need for it. And so that's why, even though we have a lot of these fun ideas that I think could really work out, we first want to wait until we get that critical mass, the audience size that we'd feel comfortable could sustain a business.Emily: How many people is that? What is the audience size?Sam: That's a tough question. Let's say Mirage cloud was the goal. I think instead of waiting to a certain point, and then trying to build Mirage cloud, we would do a few things in the interim that would be little experiments and lower risk. So, I think the first thing would be, let's say, a Mirage course. And if we can sell a course on Mirage—or even we make a free Mirage course—that gets enough attention, that would tell us that there is enough of a need there, that the positioning resonates, that people are seeing it's a valuable thing, and that would tell us, okay, let's try the next thing. So, we've been trying to do that. I make some YouTube videos over this last year, and I've been tweeting more about it and the work we've been doing, and so all of those are little experiments that I'm trying to pay attention to what resonates. Again, we have users who really love Mirage, and it's changed their workflow, but it's not at the point where I feel like it's a slam dunk and it makes sense to go on the next phase. So, I think there's been some frictions with Mirage, as we've brought it out to the wider JavaScript community. So, we have some things we want to tweak, and then ship a 1.0, and then I think maybe a 10 video course, would be a good next step, and just see the response to that, and basically take it from there.Emily: Yeah. It's always interesting to think like, how will that you have reached the critical mass?Sam: Yeah, I mean—Emily: Hard. Sam: It's really hard. And there's other strategies. I mean, a lot of businesses just have an idea and go try it out. There's this book I read, called Nail It and Scale It, and they talked about finding a problem. And we've have had some users of Mirage who use it at big, bigger companies, and it's really a big part of their workflow. And we've thought about, “Hey, what if we were to build something for them that we could generalize?” They actually have a need for something like a Mirage cloud because every time they develop a feature, they have to sit down with their product people, and their front end developer will basically run through all these different Mirage scenarios to show them how the feature works in every case, and they would love to be able to just send a link to a hosted version where they could do that. So, we've thought about building that kind of thing. But again, it's just a big risk. And then the market risk is there. So, what I've seen, I feel like, working in the past few years with a small circle of small business people and open source that I hang out with is this audience-first approach. So, it's like, if you're delivering a lot of value in the form of open source, and education, and talks, and you build an audience that believes what you have to say, and likes your opinion on things, likes your point of view, and again, resonates with the value of your work, then it becomes more and more obvious. You have a lot of people giving you feedback, you start seeing the same thing over and over. And that's just what we do with developing Mirage itself. We know a lot of what we work on next is driven by the same issues that come up, the same problems that come up in the issues, over and over again. So, I think it is hard to know, but it's one of those lukewarm things. And basically, right now, it feels too early. You know?Emily: And do you feel like, when you say to somebody, let's say, somebody who isn't involved with Mirage at the moment, maybe you're at a developer meetup or something, and you say, “I created Mirage. It's an API mocking library.” Do you have an aha moment? Are they like, “Oh, yeah. I know what that is. I know why you would use that.”Sam: Mm-hm. Sometimes yes, and sometimes no. There is a form of position I feel like, sometimes, really resonates well with people, which is like, “Don't get blocked by your back end developers.” So, if you're a front end developer, and the API is not ready, you can still build your app, including all the dynamic parts of it which would normally require a real server to be running. So, you're the front end developer, and you're trying to wire up the interface, and what happens when you click save on a cart, and it saves it in the back end, and then you show a success message. But your API is not ready, and you're working with another team that's working on the API, so you're kind of frustrated because you're stuck and you feel like you can't do anything, well, that's where Mirage can come in because you don't have to wait on them at all. You can just build it out yourself with Mirage. It's much simpler because it abstracts away all the complexity of a real server enough that you can actually build your UI against this kind of faithful reproduction of the back end. So, people really like that. And then people really like the testing use cases as well. They get confused about the best way to test user interfaces in this new distributed world we're living in where you're maybe working on a React app, and the back end is a separate API that's also serving up iPhone clients and things like that. So, there's really multiple apps involved with running a website like amazon.com. So, the question is, how do you test the front end? And Mirage is a great answer for that as well. And that's where it originally came from, so.Emily: Yeah. I can definitely see the positioning is sort of like a way for front end developers to decrease their dependence on their back end colleagues.Sam: Yeah, exactly. It's hard because there's a lot that it helps you with. And the people who use Mirage the most and have used it the most, it's really transformed their workflow because it lets the front end developer just move so much faster. So, it's really just, like, the fastest way to build a front end. That's really what the whole point of—every change we make to the library, every decision that went into it, it's how to empower a front end developer to build a production-ready user interface as fast as possible. And that includes accounting for all these different server states that are usually a pain in the butt to get.Emily: I'm just taking notes. I mean, that that actually sounded really powerful. Like, “Mirage lets front end developers work as fast as possible,” basically. It's fairly high level, but ultimately, that is a pretty compelling value statement.Sam: Yeah. And I believe it to be true, too. And I mean, that's how—I mean, I've been working on apps recently, and I still use Mirage because it's just faster than using a real server because it's right there in your code. It's right alongside your front end code, so you don't have to switch over to another process running, or open up a browser and see it; it's all right there. If you want to switch from being an admin to being a user, it's like you just uncomment a line alongside the code that you're already writing. So, I truly believe it is the best way to build a user interface. I think the positioning question is interesting because that is high-level. Sometimes developers in open source, they just want to know what it is, so there are some people who would see, “Just tell me what it is.” “It's an API mocking library.” “Okay, got it.” And that's what they want to know. “And what makes it different from other API mocking libraries?” Okay, we can talk about that. But then there's other people I think, who could stand to benefit from it, and if they saw, “Mirage is an API mocking library,” they're going to be like, “I don't really need that.” But then they go back to their job, and they have to work on their app, and they find themselves spinning up a Docker container, going to auth0 to sign in just so they can run their app in an authenticated state, and it's like, Mirage would actually be perfect for this. You could just mock all that stuff out in Mirage once, all your front end developers could use it. And now anytime you want to just work on your app in an auth state, it's just right there in Mirage, you don't have to deal with any of the complexities of the production services.Emily: Yeah. I mean, I also like the idea of sort of the fastest way to build a front end app.Sam: Yeah.Emily: Or to build a UI. The fastest way to build a UI.Sam: Yeah. That is, that's nice. I mean, it's interesting. It's a pretty interesting thing to say, and it's pretty compelling, and it's like, if you can back it up, that's a pretty strong claim.Emily: Yeah. And I mean, one of the things that I also talk to clients about—so I work with all technical founders, usually, and we're often really focused on features, all the cool features, but—you don't have to ignore the features, but you sort of use them to prove that the thing that you're talking about, that the value you say you provide is not BS. But you still want to connect the dots. Like you were saying, sometimes even the most technical person is like, “Oh, a mocking library. But I don't need that.” They're not going to necessarily connect the dots that, like, “Oh, that's going to make my workflow way simpler.” Sam: Right.Emily: Does everybody know what a mocking library is? Like, everybody who needs one?Sam: Mm, depends. If you're a front end developer. I mean, these days, people are becoming more and more specialized, so there's some front end developers who don't even deal with the data fetching side of an app at all. They're working on a part of the app that already has the data, and they're just working on maybe styling, layout, things like that, but they're never writing code or refactoring code that actually interacts with the server. And then even if you are doing that, you might not be writing tests. So, a lot of people just do the lowest friction thing, which is, just point their local UI at whatever server they can. Maybe their company has a staging server or maybe they run one locally in development and they just build it like that. But again, that's the lowest friction, but it's slow because now you're running a Rails server. If you want to change the data, you have to know how to do it in Rails, and you have to run different commands. And then it comes to testing, it's really hard, too. So, I think most people would know, if you were to say, “Yeah, it mocks out the API.” Most people would know that. But people might have different conceptions of what that means. So, there are some approaches to mocking—or stubbing, or faking, there's some technical difference between those terms, but for the purpose of this conversation, it's just faking out that functionality—there's some people who would hear that and say, “Oh, okay, I get it. A function that my code calls when it normally goes to the server, I'm going to replace it with a different function that returns this fake data.” But Mirage works differently because it operates at the boundary of the app. So, when you mock your API with Mirage, you don't have to change anything about your application because it intercepts the network request before it goes to the server. So, that's another big benefit of Mirage, that Mirage has over other solutions for mocking out network functionality is that your application code stays exactly the same. And that's an important point because the whole goal with Mirage is to be the fastest way to build a production-ready user interface. And by production-ready, I mean an interface that can be plugged into your production API and you'll have confidence that it works. So, that boundary thing is another important point of Mirage. So, that would maybe be the one thing that people could mean different things when they say ‘mocking.' But by and large, I would say most front end developers would understand if you said ‘API mocking,' what they mean.Emily: And do you think they generally are also able to figure out what that's used for, why they should care?Sam: Yeah, that's the thing is that that's where I think the real opportunity is because I think, if you were to say ‘API mocking,' people are going to immediately go to testing because that's the kind of environment where you would want to mock the API so you have control over it. But people who haven't used Mirage or something like Mirage, don't realize how powerful it can be, to mock it just during your normal development flow. So, again, once people use it and get it, they use Mirage for everything; it's just part of their workflow. I just start up my UI, I'm running Mirage in a specific scenario, and if I need to see the UI in a different state, I just changed my Mirage scenario, or put some new data in there, or empty out the database there. And so it totally affects your whole workflow because now you're just disconnected from the back end services. So, I think a lot of people aren't doing that. They are just stuck—you know, they're just used to the hassle of getting these three services up and running just so that they can run their UI, and it's a pain in the butt. I mean, I was just talking to someone on another podcast, and he was saying it's the same thing. And it's really hard when they onboard new people because they have to get them set up with all these auth keys just so they can run the front end, even though they don't really care about the auth setup, they just want to start working on this page. So, again, the companies that have used Mirage and adopted it don't have any of those problems because the Mirage server is right there with the user interface, and they don't have to worry about it. So, I think that is a big gap that we could probably do a lot better job of closing with information on the homepage, or examples, or something like that.Emily: So, Mirage also helps new hires get up to speed a lot faster, or get productive, I should say?Sam: So, yeah. If you were hired by Facebook, and you're a front end developer, and your first task is to update the way the colors look on the home feed, to get that running on your computer so you can make changes and see how it looks in the code, at many companies—probably most companies—it's going to involve a lot of moving pieces because you have this React app on the front end, but it has to fetch data from somewhere so you can see how it works. Maybe they have a server that is just used for development that the person can point to. But again, if you have this shared hosted server, you only get what's on there; maybe you don't have an easy way to change what data it gives you. So, usually, front end developers need to see a dynamic user interface in all these different states. But if you're using a shared server, you don't get all those different states. But it's easier to set up because it's already set up. So, the alternative is to say, “All right, Sam, you're new here. Let's get you set up so that you can run a copy of Facebook locally.” So, that usually involves a ton of steps. I mean, I've seen that take, like, a week just to get all the pieces that are required to run the back end up so that you can actually power your front end. So, yeah, companies definitely, definitely have a problem with this. They have a problem with shared staging servers, I've talked to tons of people over the years who hate their staging servers, the back end teams, the ops teams hate them because everyone's always trying to change it for the salespeople to go take demo calls or for people to test. And so basically a shared server like that is just a nightmare because it's basically another production server to maintain that your internal team is trying to use and people want it to do different things. So, that's why Mirage is nice because it's just local to the code, and every front end developer can just tweak it in exactly the way they need for what they're doing at that time. So, I think that's a big opportunity as well.Emily: One of the most interesting things, I think, about this conversation is that you've touched on this idea of salespeople doing demos, and I really like that because it's so different. It's such a different use case.Sam: Yeah. We had a thought about that, actually because we were talking to a handful of companies—did interviews with them, actually, a couple years ago—and we're like, this could be a cool product. And it's like, just the easiest way to show off your software. And again, we've even done consulting for companies that have had basically another server, just for the purposes of a demo. And again, it's just a pain in the butt because it's another production server to manage, you have to reset the database after each call you do, and with Mirage is not like that; it just restarts with the app. It's just heavier, it's a real server to manage, where again if you just need to show off the UI, you can do it with Mirage. So, we thought about doing that. It's an interesting use case, for sure.Emily: I think it's a really good illustration of how you can take the same technology, and reposition it, basically, to do something totally different, have a totally different set of value proposition. The people who would be actually benefiting from its use would be totally different. I mean, you have salespeople versus front end developers.Sam: Yep. We've thought about that. What would that look like to market to those people? And maybe one way you could do it would be, you know, the salespeople get frustrated because they want to just change the numbers in this part of the app on the spreadsheet summary because they know it's going to help them communicate the value to the people that they're talking to, but now they have to go and ask some back end developer or someone on the ops team, “Hey, can you change this database column so that my demo works better?” What if they had a Mirage-powered demo and they could tweak the Mirage data, maybe in some interface themselves, without having to involve anybody. And that's pretty compelling because Mirage, again, is designed to work with any API. So, no matter what your tech stack is on the back end, Mirage works for the front end team. And so now the back end team can do all their stuff, they can be switching from Rails to Elixir, they can be switching to Go or microservice architecture, and they have all this stuff going on, so they're the only ones who really know how to actually get this number from 100 to 200 in the system. Like, it's complicated. And so that's, again, a benefit of just having Mirage because, on the sales calls, the people are just wanting to show what it looks like when the data is a certain way. So, yeah, that was definitely a use case that we didn't anticipate at all.Emily: Yeah. And even you could have five salespeople trying to do calls at the same time and—Sam: Exactly.Emily: Wanting to have different data reflected, and I'm sure that's just like—Sam: A nightmare. I mean, people have told us just, it's the worst. Basically, the shared staging server is a—yeah, it's a huge problem for a lot of teams.Emily: It's so interesting. Well, anyway, taking us back from the rabbit hole, although it—I mean, it really is interesting, and just fascinating how you could change this to be something that's targeted at that totally different market.Sam: Right.Emily: To wrap up. I mean, I was thinking about how you're saying that the fastest way to build a production-ready UI, that possibly is the most powerful thing I think you've said.Sam: Yeah. We actually—I think that's how we had it when we first did the redesign of the site. And it was like, I don't know if that stuck in the sense of, what does production-ready mean? “Oh, I'm already writing production-ready code.” But then it's like, you have to—like you said, connect the dots and explain how you're not writing production-ready code unless the way you're mocking your API is matching your production API, so we kind of switched it to what it says now, which is, “Build complete front end features, even if your API doesn't exist.” Which basically came from the mouth of someone who was using it, and when they had their aha moment that was what they were saying. I've been thinking if we get to the 1.0 launch, I think I would want to go back to something like that because I do think it's compelling. So, “It's the fastest way to develop a UI, test it, and then share a working demo of it,” because that's is really the motivation for the library. So, yeah, it might be interesting to think about doubling down on that as the unique value proposition.Emily: Yeah. I'm curious what your immediate plans are.Sam: So, we've been working on this REPL playground area of the site where people can learn Mirage and see examples, and we can share them and stuff. So, that will hopefully—you'll see a lot of that kind of thing in the JavaScript community. If you go to Svelte, which is another front end framework, you can create little sandboxes and play around with Svelte and learn it. So, it's a really good way to learn things and just see how it works quickly right in the browser without having to install anything. So, we're about wrapping that up. And then I think it'll just be a matter of carving out the time to go through some of the issues and bugs that people have found, and getting it to a point where we feel good about slapping a 1.0 on it. At which point, we can take a look at all the feature requests and all the issues that people have run into and figure out okay, where do we want to focus our time? Again, considering, like, is there a story here where we can make it sustainable, and hopefully, dedicate more of our time to it? Because that's really, again, I think it's the biggest impact work I've done in my career so far, but it's just, sustainability in open source is tough. So, it's a matter of not jumping too early on any particular idea for how to sustain it and monetize it: if it's a pro version, if it's a support plan, people have asked for all these things, but not maybe in the strongest numbers that would make me feel comfortable diving in on that. But I do believe that it can work because I believe it's a really good idea and I know a lot of companies have gotten a lot of value from it. So, that's what our short term plan is.Emily: Well, fabulous. Thanks so much for talking about Mirage. This has been really interesting.Sam: Yeah, thanks a lot for having me, and I appreciate your input. It was fun to revisit the positioning stuff. It's been a while, so it's always good to be thinking about that.Emily: All right. I have one last question for you, which is what is an engineering tool you can't live without?Sam: These days, it's got to be Tailwind. It's a styling framework. And it's just really excellent. So, I would not want to work on a site without it because it would just be painful. So, [laugh] I love Tailwind. Yeah, it's a really good library.Emily: All right, cool. Well, thank you so much. And—oh, what—the very last thing it should be, how can listeners find you, follow you, keep up with you?Sam: Yeah, best place is Twitter, at @samselikoff. And I'm also making YouTube videos more and more these days: youtube.com/samselikoff. So, those would be the places to go.Emily: Right. Excellent.Emily: Thanks for listening. I hope you've learned just a little bit more about The Business of Cloud Native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier—that's O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

On this week's episode, Chris introduces a new segment called "Good Idea, Terrible Idea?" as he considers introducing a read-only mode to avoid interrupting users during scheduled downtime. Steph has started a new project and explores the idea of merging separate, but similar, applications into one codebase. They also dive into micro-service environments to discuss the difficulties of integration testing and potential strategies. This episode is brought to you by: ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post Earth, Wind & Fire - September (https://youtu.be/Gs069dndIYk) ActiveRecord Persistence (https://api.rubyonrails.org/files/activerecord/lib/active_record/persistence_rb.html) Amazon SQS (https://aws.amazon.com/sqs/) Swagger (https://swagger.io/docs/) GraphQL (https://graphql.org/) VCR (https://github.com/vcr/vcr) The Bike Shed VCR episode - 189: It's Gonna Work, Definitely, No Problems Whatsoever (https://www.bikeshed.fm/189) Capybara Discoball (https://github.com/thoughtbot/capybara_discoball) React Podcast Episode - 110: Sam Selikoff on Finding a Full Stack React (https://spec.fm/podcasts/reactpodcast/X1swadgC) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

News!We have a YouTube channel for React Podcast

In this episode, Adam is joined by Sam Selikoff to talk about some of the interesting technical challenges he faced building Tailwind UI, and how working on the project has influenced how he will build layouts in the future. Topics include: What Tailwind UI is and why we decided to build it How odd numbers can wreak havoc on a user interface, and how to avoid them Crafting the perfect form control Unexpected benefits of working with CSS Grid Abusing single column grids just to use gap, and why we desperately need gap support in Flexbox Links: Tailwind UI Supporting the show: I decided to stop taking sponsors for the show because I think advertisements are annoying and no one wants to listen to them. If you do want to support the show, the best way to do it is to purchase one of my products: Tailwind UI, a collection of professionally designed, fully responsive HTML components built with Tailwind CSS Refactoring UI, a book and video series I put together with Steve Schoger on designing beautiful user interfaces, without relying on a designer. Advanced Vue Component Design, a course on designing simpler, more flexible Vue components that are both more powerful and easier to maintain. Test-Driven Laravel, a massive video course on designing robust Laravel applications with TDD. Learn how to build a real-world application from scratch without writing a single line of untested code. Refactoring to Collections, a book and video course that teaches you how to apply functional programming principles to break down ugly, complex code into simple transformations — free of loops, complex conditionals, and temporary variables.

On this week's episode, Chris and Steph respond to a listener question about the complex tradeoffs between craft, preferences, and business needs. They also revisit Steph's recent work with mirage factories, Chris's struggles with test failures, and discuss Steph's recent use of the actsasparanoid gem. This episode is brought to you by Clubhouse (http://go.thoughtleaders.io/1658420200225). Click through to get 2 free months on any paid plan. Mirage.js (https://miragejs.com/) Creating Ember Data models on the client with Mirage (https://www.ember-cli-mirage.com/docs/testing/integration-and-unit-tests#creating-ember-data-models-on-the-client-with-mirage) FactoryBot (https://github.com/thoughtbot/factory_bot) Sam Selikoff (https://twitter.com/samselikoff/) Babel (https://babeljs.io/) Browserlist (https://github.com/browserslist/browserslist) actsasparanoid (https://github.com/ActsAsParanoid/acts_as_paranoid) Default scopes in Rails (https://guides.rubyonrails.org/active_record_querying.html#applying-a-default-scope) Braintree hosted fields (https://developers.braintreepayments.com/start/hosted-fields)

In this episode, Adam talks to Sam Selikoff about Mirage.js and how to use it to build production-ready front-end applications, even if your back-end API isn't ready yet. Topics What is Mirage and how does it work? What makes Mirage better than a dummy JSON server you run on another port? What makes Mirage better than running your actual API locally? Using Mirage for actual development, and not just for your test suite How Mirage's internal ORM works, and how it can help you mirror your API's behavior more quickly Managing the risks of maintaining a complex stub of your real API with Mirage and keeping them in sync What's next for Mirage Links Mirage.js Mirage.js on GitHub Supporting the show I decided to stop taking sponsors for the show because I think advertisements are annoying and no one wants to listen to them. If you do want to support the show, the best way to do it is to pick up one of my books or courses: Refactoring UI, a book and video series I put together with Steve Schoger on designing beautiful user interfaces, without relying on a designer. Advanced Vue Component Design, a course on designing simpler, more flexible Vue components that are both more powerful and easier to maintain. Test-Driven Laravel, a massive video course on designing robust Laravel applications with TDD. Learn how to build a real-world application from scratch without writing a single line of untested code. Refactoring to Collections, a book and video course that teaches you how to apply functional programming principles to break down ugly, complex code into simple transformations — free of loops, complex conditionals, and temporary variables.

Topics include:- 2:31 – Tailwind, PostCSS, and low-level vs. high-level tools- 13:12 – Mirage JS and Cypress- 13:55 – Ember 3.13 and Octane- 15:28 – Ryan's experiencing upgrading EmberMap from 3.4 to 3.12- 20:19 - ES Modules, and learning that imports are not code- 42:12 – React and useEffect, and the difference between reads and writes vs. rendering and event handlers- 1:00:50 – Object-oriented vs. functional programming in JavaScript Links:- [Ember 3.13 Release (Octane Preview)](https://blog.emberjs.com/2019/09/25/ember-3-13-released.html)- [How to upgrade an Ember App or Addon](https://embermap.com/video/how-to-upgrade-an-ember-app-or-addon)- [Rich Harris and Edward Faulkner Twitter thread about ES module design](https://twitter.com/Rich_Harris/status/1176509180951322624)- [Twitter thread about ES module execution order](https://twitter.com/samselikoff/status/1182485014815993856)- [Sam Selikoff on Twitter](https://twitter.com/samselikoff)- [Ryan Toronto on Twitter](https://twitter.com/ryantotweets)

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max Wood Joined by Special Guest: Sam Selikoff Episode Summary Sam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics. When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career. Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently. Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics. Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter Picks Charles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max Wood Joined by Special Guest: Sam Selikoff Episode Summary Sam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics. When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career. Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently. Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics. Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter Picks Charles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max Wood Joined by Special Guest: Sam Selikoff Episode Summary Sam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics. When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career. Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently. Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics. Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter Picks Charles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

In this episode, Chris and Brandon talk about the myths surrounding entrepreneurship in the tech industry. They start out by talking about the terms "entrepreneur" vs "business owner" and then go on to examine why those myths might exist in the first place. Thanks to friend of the show Sam Selikoff for prompting this discussion with his followup questions. Notes: Sam's original tweet https://twitter.com/samselikoff/status/1129009653021519873 The "demon dogs" approach https://twitter.com/tehviking/status/967812859131564032 https://twitter.com/tehviking/status/261627304134983680 Antonio Gramsci https://en.wikipedia.org/wiki/Antonio_Gramsci Cultural Hegemony https://en.wikipedia.org/wiki/Cultural_hegemony Superstructure https://en.wikipedia.org/wiki/Base_and_superstructure Derrick Reimer's blog post https://www.derrickreimer.com/essays/2019/05/17/im-walking-away-from-the-product-i-spent-a-year-building.html Patrick McKenzie's tweet https://twitter.com/patio11/status/504304015455555585 That's True https://youtu.be/NMvl_bTGGzY

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly Panel AJ O’Neal Joined by special guest: Sam Selikoff Episode Summary In this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks. Links Sam’s website Sam on Twitter Sam on GitHub Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter. Picks AJ O’Neal: Good Mythical Morning - YouTube Sam Selikoff: The Man In the High Castle   Tailwind CSS

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly Panel AJ O’Neal Joined by special guest: Sam Selikoff Episode Summary In this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks. Links Sam’s website Sam on Twitter Sam on GitHub Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter. Picks AJ O’Neal: Good Mythical Morning - YouTube Sam Selikoff: The Man In the High Castle   Tailwind CSS

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly Panel AJ O’Neal Joined by special guest: Sam Selikoff Episode Summary In this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks. Links Sam’s website Sam on Twitter Sam on GitHub Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter. Picks AJ O’Neal: Good Mythical Morning - YouTube Sam Selikoff: The Man In the High Castle   Tailwind CSS

In this episode, Adam continues his discussion with Sam Selikoff about building single page applications, this time focusing on strategies for keeping your API layer as simple as possible, so all of your complexity lives in your client-side codebase instead of being spread across both. Topics include: Building an API without writing any controller code Thinking of your API like a database as much as possible Modeling everything on the server as a resource, including things like S3 upload signatures Using tools like Firebase to avoid writing an API entirely Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio and install Rollbar in your app to receive a $100 gift card for Open Collective Cloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for free Links: EmberMap, Sam's Ember.js training site JSON:API, the API spec Sam uses to build his SPA backends JSONAPI::Resources, the Rails gem for declaratively building a JSON:API compliant API Firebase Vuex Apollo GraphQL

In this episode, Adam talks to Sam Selikoff about single page application architecture, and why you should think of client-side applications like desktop applications. Topics include: Why you should think of SPAs as desktop apps instead of web apps Strategies for pushing complexity out of your backend and on to the client Building optimistic UIs Best practices for storing and retrieving data Why you should design your SPAs with an "offline-first" mindset Sponsors: Cloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for free Rollbar, sign up at https://rollbar.com/fullstackradio and install Rollbar in your app to receive a $100 gift card for Open Collective Links: EmberMap, Sam's Ember.js training site Cruddy by Design, Adam's talk on modeling with resources Progressive Enhacement is Dead, Long Live Progressive Enhancement, a talk from Tom Dale that talks about building offline-first web applications Ember Data JSON:API Ember-Orbit

In this episode, Adam talks to Sam Selikoff about how Ember fits into the JS framework landscape in 2018, and why it might be the right choice for your next project. Topics include: Why has Ember stuck around when other frameworks from the same era haven't? What do you get when you choose Ember that you don't get with other frameworks? How does Ember's UI layer compare to React/Vue? What choices does Ember make differently than frameworks like React and Vue? How does Ember do state management? Why Ember is a great choice if you value stability Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Codeship, check out how they performed in Forrester's latest Continuous Integration Tools report Links: EmberMap, Sam's Ember.js training site Ember.js Documentation ember-cli-tailwind, Tailwind CSS add-on for Ember Handlebars, Ember's templating language "Should we use controllers?", on how controllers fit into Ember when also using components Ember Data Ember's release cycle embercasts, Ember.js training for beginners

How do we ensure a high level of quality and maximize the refactorability of our code? Frontsiders, Wil and Charles, talk about their battle tested techniques for testing web applications, not only in React JS, but in any JavaScript framework. Links Acceptance Testing Integration Testing jest Cypress.io Assertion Ember CLI Mirage mirage-server react-trigger-change Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 90. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Wil Wilsman. Wil, who just got back from Nodevember just walked straight into the office and is ready to podcast with us on a very, very, very interesting subject, I think, today. We're going to be talking about acceptance testing in JavaScript applications, especially some of the techniques that we've developed here around testing React applications based on the lessons that we learned from the Ember community. But really, more than just React applications. Really, testing any JavaScript application from the inside out, making acceptance tests for that. So, I think we're going to talk about some of the challenges that you encounter and some of the really novel solutions that are out there that we had nothing to do with. And I guess we really didn't have, just more of cobbling together of various techniques for a powerful witch's brew for acceptance testing. Anyway, so Wil, just to round out the problem space or explore the problem space, what are some of the challenges that you encounter with an acceptance test? Actually, let me back it up even further. What is an acceptance test in a JavaScript application compared to what people normally encounter? WIL: Acceptance testing or end-to-end testing is just a problem that every JavaScript app should face. Not everyone does, but they definitely should. And basically, it's how the user interacts with your app through the browser. And every part of that we want to test, from the browser triggering browser events, interacting with the app, not calling functions or clicking buttons, and we're pretending we're a user. CHARLES: Yeah. You know, I know that when we showed up in the React space, that was not really the way that most people tested their applications. WIL: No, not at all. they're all about unit testing. Make sure every small piece of your code works, and to some degree integration testing, making sure your components work with other components. But, nothing is out there really for those big acceptance tests that you want the user to click a button and expect them be brought to a page or these fields to be filled out, et cetera. CHARLES: Mmhmm. Yeah. And there certainly was a very high level of maturity around unit testing, like you said. There are tools like Enzyme and… WIL: Jest. CHARLES: Yeah, Jest. But I was actually shocked to find out that Jest didn't even run in the browser. WIL: Yeah, it's all virtual. CHARLES: It's all virtual. It's completely and totally simulated and stubbed. And that presents some problems. WIL: Yeah. The main problem is cross-browser testing. Some people might consider that to be separate from their acceptance testing but you should be able to just run your acceptance tests in multiple browsers and be able to also test cross-browser support. CHARLES: Mmhmm. Yeah. And so, if you're using something like Jest, you're never actually running the code inside Safari. You're never actually running it inside Internet Explorer. You're actually running it in NodeJS. WIL: And you know, your user is not going to run it in Node. [Laughter] WIL: They're going to use a browser. CHARLES: I don't know about your users. WIL: [Chuckles] CHARLES: [Laughs] You know, we like to stick to the pretty advanced. It's like, go to getNodeJSBrowser.com. WIL: [Laughs] CHARLES: Enough of this Firefox BS. But not seriously, it was certainly a problem. We were looking around, because we never like to build anything ourselves if we can avoid it. But it really just seemed like there was not an off-the-shelf solution for writing these big style acceptance tests in JavaScript. There are some services out there. There's a couple now. What was the… WIL: I think the main one here is Cypress. CHARLES: Cypress, yeah. So, there's Cypress now. I've watched the instructional videos but never actually tried to integrate it into my application. WIL: Yeah. I think at its core it takes the same approach that we've been doing with how we're interacting with our tests. CHARLES: Mmhmm. Okay. The main difference is, is it that it's a service? Like you have to edit your tests through… WIL: Yeah. CHARLES: Their web browser, their web interface, and use their assertion library? WIL: Yeah. I'm not sure about the editing part. But yeah, it's their assertion library. I'm pretty sure it's their test runner and it's their testing environment. Really, the only control through that is through their UI, or through settings, basically. And you're stuck with those. You can't use other… I don't think you can use Mocha with Cypress. CHARLES: Right. WIL: Although it's very much like Mocha… CHARLES: Right. WIL: It's not. CHARLES: Right, right. And I also noticed, we'll touch on this later, the assertions, most of the side effects that were happening were happening right there inline inside your assertions. And that might be an opaque statement, but we will actually get into that later. WIL: Yeah. And I think one of the things about their side effects so to speak is everything leading up to a side effect is a promise with Cypress. CHARLES: Mmhmm. WIL: So, when you select a button and click it, Cypress is going to wait for that button to actually exist before it clicks it. CHARLES: Right, right, which is actually pretty cool. So, that's actually a perfect into into one of the primary challenges with doing acceptance testing in general in a JavaScript application. This is a problem when you're doing it in Ember. It's a problem in React. It's really a problem anywhere. And that is, how do you know when the effects of a user's interaction have been realized? Right? WIL: Yeah. And in Ember you take advantage of the run loop. Once that action happens, you wait for the run loop to complete and then your tests run. CHARLES: Right. So, the idea is that I've clicked some button or I've typed some key or I've moved the mouse. And then I listen for the run loop and when it's “settled” then I can now run my assertions because I know that the side effects that I was looking for have now been realized. WIL: Yeah, hopefully, if you're... CHARLES: Hopefully. WIL: Writing your app right. [Chuckles] CHARLES: Right, right. But that actually presents some problems in itself because it requires visibility into the internals of the framework. WIL: Yeah, so Ember is built with testing in mind. CHARLES: Mmhmm. WIL: And other libraries like React just being a view library might not be built with testing in mind. So, we don't have those hooks to wait for this loop to complete, wait for all of these things to be rendered before you continue. CHARLES: Exactly. And so, this is, I think it's actually kind of both a blessing and a curse. Because there are such strong conventions in Ember, they were able to build this wonderful acceptance testing regimen from the get go. WIL: Yeah. CHARLES: But like you said, that doesn't exist at all in the React ecosystem. And so, what do you do? There's no run loop. You're cobbling together a bunch of different components. And maybe you're using Redux, maybe you're using MobX, maybe you're using… you're certainly using React. And all of these things have their own asynchronies built-in. And there's not one unifying abstraction that's keeping track of all the asynchrony in the system. And so that presents a challenge. So, the question is then, if you're trying to not actually check and observe the state of a system until the right moment, how do you know when that right moment is? WIL: Yeah. And in early testing of a side React project I had, I would basically wait for a state to be complete before I continued my ‘before each'. And in the testing we're doing now, it's essentially what we're doing except the state is what the browser sees, or what the user would see in the browser. CHARLES: So you were actually querying the... WIL: Yeah. So, I was using Redux. So, in my app I was saying, when the Redux app is done loading... CHARLES: Mmhmm. WIL: The instance is set to true or false, then continue the test. CHARLES: Mmhmm. And so, what that means, what we're doing, is doing the same thing except observing at the DOM... WIL: Yeah, exactly. CHARLES: Level. And what it means is we actually… I would love to set this up and have a big reveal but I guess we'll just have a big reveal, is that essentially what we do is polling. WIL: Yeah. CHARLES: Right? So, when we run an assertion, let's say you click a button and you want the button to become disabled, there's an inherent asynchrony there. But what we will do is we'll actually run the assertion to see if it's disabled not one time. We'll run it a thousand times. WIL: Yeah, as many times as needed until it passes. CHARLES: Right, exactly. As many times as needed until it passes. And I think that is, at least to most programmer instincts, an odious idea. WIL: Yeah. CHARLES: [Laughs] WIL: It's like, “Oh wait, you're just looping over every single assertion how many times?” CHARLES: Yeah, exactly. And it feels, yeah, it feels weird as an idea. But when you actually see the code that it produces, it just sweeps away so much complexity. WIL: Yeah. And… CHARLES: Because you don't worry about asynchrony at all. WIL: Yeah. And it's pretty genius. If I'm a user and I click a button, it's loading when I see that it's loading. So, our tests are going to wait until that button says it's loading. And then the test passes. CHARLES: Right. And so, what we do is we essentially, we use Mocha but you could do it with QUnit or anything else, is that when you run your assertion, you declare, you have an ‘it' block or I guess, what would it be in QUnit? WIL: A test? CHARLES: A test? WIL: I think it's just a test. CHARLES: You have your test block. And so that function that actually runs the assertion and checks the state will actually run, yeah it could run three times. It could run a thousand times. It's just sitting there waiting. And it will time out. And it will only fail if that assertion has failed a thousand times or it has failed through, I think two seconds is our default. WIL: Yeah, yeah. I think we default to the runner's default timeout. CHARLES: To the runner's default timeout, yeah. WIL: Yeah. Or you can set that yourself with how we have it set up. And the other thing that comes from that is if your tests are only failing when they time out, how do you know what's actually failing? And our solution to that was we catch the error every time it fails and right before the timeout actually happens we throw the real error. CHARLES: Yeah. Exactly. But the net effect is that you're able to write your assertions completely and totally oblivious of asynchrony. You don't, we don't have to worry about asynchrony pretty much at all. I mean, we do, and we'll get into that. So, I made a global statement and then immediately contradicted it. WIL: [Chuckles] CHARLES: But hey, you got to be controversial. But for the most part, asynchrony just disappears because asynchrony is baked into the fabric. So, rather than thinking about it as a one-off concern or a onesie-twosie, it's just every single assertion is just assumed to be asynchronous. And so, that actually means you don't have to deal with promises. You don't have to deal with run loops. You don't have to deal with anything. You just write your assertion and when it passes, it passes. And there are some really unique benefits for this. And there are some challenges. So, I think one of the first benefits is that it's actually way faster. WIL: Right. CHARLES: Which is counterintuitive. WIL: It's incredibly fast. CHARLES: It's very fast. WIL: Yeah, for all the loops that's happening you might think every loop is going to slow it down slightly. But it really doesn't. Our tests, each test, even though it asserts five or six times, it takes milliseconds. CHARLES: Mmhmm. WIL: The test itself might only loop twice. CHARLES: Right. Exactly. Whereas if you're waiting for a run loop to settle, you might have some… you click a button, it disables, it also fires off an Ajax request and does all this stuff. But if all my assertion wants to know is “Is this button disabled?” then I only need to assert until that has happened. I don't need to wait until all the side effects have settled... WIL: Mmhmm. CHARLES: And then do the assertion. I just know, “Hey, my assertion, the thing that I was waiting for - that happened. Let's move on.” Yeah. And so, it's so, so fast. And that was actually, I didn't predict that. But I was definitely pleasantly surprised. WIL: Yeah, that was a very nice surprise. And all of our tests ran so much quicker than they would have in a run loop environment with Ember or something. CHARLES: Right. Yeah, yeah. That was, we actually had just come off a project where we were having that thing, that exact problem, which was that yeah, our animations were slow. Or, the animations were fine. They were perfect. [Laughs] But there were slowing down the tests. WIL: Yes. I think in that project, it was like, 30-minute tests... CHARLES: Mmhmm WIL: For the whole suite to run. CHARLES: Yeah. To which I'll add a public service announcement. I think this is a conjecture but I do believe that animations are best applied not to individual components but by the thing that uses a component. So, I shouldn't have an animation that's like, implicit to a dialog. It should be the thing that's showing the dialog that gets to decide the animation to use. Anyway, just throwing that out there. WIL: [Laughs] CHARLES: Because animations are about context. And so, the context should provide the animation, not the individual atom. Anyway, moving on. WIL: Some other podcast. CHARLES: Yeah. [Laughter] CHARLES: That's another podcast right there. But there's also, this does present some challenges or requires code to be structured in a way that facilitates this. So, there are some challenges with this approach, some things you need to be aware of if you're using this kind of system. We've kind of settled on a name for what we call these types of assertions and these types of systems. WIL: Yeah. We call them convergent assertions, because you're converging on something to happen. It's going over and over until it happens. CHARLES: Right. WIL: And yeah, a lot of these challenges that we've come across are things that you might not think of, like there are a few instances of false positives... CHARLES: Mmhmm. WIL: That happen with these convergent assertions. CHARLES: Right. So, what would be an example there? WIL: So, the most common example that I'm seeing so far is when you're asserting that something didn't happen. CHARLES: Mm, right. WIL: That would immediately pass. But if it takes your app... CHARLES: [Laughs] WIL: A few seconds for it to actually happen, then you could still have an actual failure but your test passed immediately. CHARLES: Right, right. So, what's the countermeasure then? WIL: We invert our assertions. So, we make sure they fail for a certain amount of time. CHARLES: Right. So, the normal case where you just want to say, “I want to make sure that my state converges to this particular state.” WIL: Alright. I said fail at first. I meant, pass. We have to make sure it passes for a certain period of time. CHARLES: Right, exactly. WIL: So yeah, the normal way is it fails until it passes, and then it passes. When you invert one of these convergent assertions, you're just making sure it passes repeatedly and if it fails at any point, you throw a failure. CHARLES: Right, okay. And so, that's like, if I want to check that the button is not disabled, I need to check again and again and again and again. WIL: Until you're comfortable with saying, “Alright. It's probably not going to be disabled.” CHARLES: Yeah, exactly. And so there, it's kind of weird because it is dependent on a timeout. WIL: Mmhmm. CHARLES: You could go for two seconds and then at the very end it becomes disabled. So, you just kind of have to take that on faith. But... WIL: Yeah. CHARLES: In practice, I don't think that's been much of a problem. WIL: No. CHARLES: It's more indicative of, if your button disables after... WIL: A few seconds. CHARLES: A few seconds, what's up with your... WIL: Yeah, what's up with your app? CHARLES: Yeah, exactly. WIL: If you're waiting for an Ajax request or something, an example, then you should be using something like Mirage Server. CHARLES: Right. Which is, man, we got to get into that, too. There are a couple of other things that I wanted to talk about too, with these convergent assertions. And that is, typically when you look through the READMEs for most testing frameworks, you see the simple case of the entire test, the setup, the teardown, and the actual assertions, are in the actual test. WIL: Yeah. The ‘it' block in Mocha or the test block in QUnit. You click a button, and then make sure it's disabled, and it moves onto the next test. CHARLES: Mmhmm. WIL: Then you click a different button or the same button and you assert something else in the next test. CHARLES: Mmhmm. Right. WIL: And yeah, you can't do that with convergent assertions because they're looping. So, if you click a button in a loop it's going to keep clicking that button over and over and over again. CHARLES: Yeah. [Laughs] Right, right. So, it means that you need to be very conscientious about separating the parts of your tests that actually do the things that actually act the part of the user from the part of your test that's about observation. WIL: Yeah. So, our solution to that is we move out all of our things that have side effects like clicking a button or filling in a form, all that stuff happens in ‘before each's. And all of our actual assertions happen in these convergent ‘it' blocks that loop over and over again. So, our ‘before each' runs and clicks the button and then we have 10 or so tests that will loop and wait for various states to... CHARLES: Yeah. WIL: Be true. CHARLES: Right. That means that yeah, all these assertions do is they read state. And you just have to, you do have to be conscientious. You're not allowed to have any side effects inside your tests, your actual assertion blocks. WIL: Mmhmm. CHARLES: But that's actually, it's a good use case for the whole Act-Arrange-Assert, which has been around way, way, way before these techniques. But here, we're doing Act and Arrange in our ‘before each'... WIL: Mmhmm. CHARLES: And then we're doing Assert later. And I think it actually leads for more readable... WIL: Yeah, definitely. CHARLES: Things. WIL: And it also opens the door to something that we can't really take advantage of yet but if you have 10 assertions with one ‘before each' side effect, you could run all of those assertions in parallel. CHARLES: That's right. WIL: And your tests would be 10 times more faster. CHARLES: Mmhmm. Yeah, exactly. Or you could run them in parallel or you could just run them one after the other but you wouldn't have to run that ‘before each' 10 times. WIL: Yeah. But something with that, that I found, is if we move all of our side effects to ‘before' blocks instead of ‘before each' blocks, sometimes a test three tests down that's waiting for something to happen... CHARLES: Yeah. WIL: That thing might have already happened earlier... CHARLES: Yeah. WIL: And it already went away. A loading state is the best example of that. CHARLES: Mmhmm. WIL: You show the loading state, the loading state goes away. So, if you move that button click into a ‘before' and that loading state test is three tests in, that loading state is already going to be gone. CHARLES: Yeah, so I think the long story short is we've kind of come to the conclusion that we would have to write our own runner. WIL: Yeah. CHARLES: Essentially to take advantage of this. But that said, we've done some sketching about what we would gain by writing our own runner. And the speed, we're talking about exponential speedups. WIL: Yeah. CHARLES: Maybe taking an entire acceptance test suite and having it run in five or six seconds. WIL: Yeah. We're talking about these tests that are already extremely fast. CHARLES: Mmhmm. WIL: Each test takes a few milliseconds or tens of milliseconds to complete. But then if you can run all of those at the same time, all of your tests for that entire ‘describe' block just ran tens of milliseconds. CHARLES: Right. Yeah. So, it's really exciting and pretty tantalizing. And we would love to invest the time in that. I've always wanted to write our own test runner. But never had, [chuckles] never really had a reason. WIL: Yeah. CHARLES: Certainly not just for the sheer joy of it. Although I'm sure there is joy in writing it. But that, yeah, we'll have to wait on that. But I am actually really excited about the idea of being able to maybe bring this back to the Ember community. WIL: Yeah. CHARLES: Because acceptance tests getting out of control in terms of the speed is I think a problem with Ember applications. And I think this would do a lot to address that. WIL: Yeah. CHARLES: I think, how long, if we were just using a stock Ember acceptance testing setup for this, I think we have about 250 tests in this React app... WIL: Yeah. CHARLES: How long does it take to run? WIL: Right now I think our tests take something like 20 seconds. And that's also somewhat due to they have to print the tests on the screen on Travis so that takes a little time. In an Ember setup, that could maybe take a few minutes. I mean, that's not that big of a deal, a few minutes. CHARLES: Right. WIL: But compared to 20 seconds. CHARLES: Right. you're still talking about an order of magnitude... WIL: Yeah, exactly. CHARLES: Difference. And using this, I think you could get a 30-minute test suite... WIL: Yeah. CHARLES: Down to the order of 3 minutes. WIL: Now when we're talking about those times, we're talking about the tests themselves. Of course, the CI would have to download stuff and set up the [inaudible]. CHARLES: Mmhmm, right, right. WIL: And that of course all adds to the time. CHARLES: Yeah, mmhmm, yeah. Earlier you mentioned, we talked about Ember CLI Mirage. This is actually something that is having now been using it for what, 2 years or something like that, it's just… it's impossible... WIL: To go back, yeah. CHARLES: To go back. It is. It's like [chuckles] you come outside the Ember community and you're like, “How is anybody ever dealing without this?” WIL: Yeah. CHARLES: [Laughs] WIL: A lot of the mocks are usually mocking the function that makes the request and it returns it in that function. That's what's out there currently, minus the Mirage stuff. CHARLES: Mmhmm. WIL: But once you use Mirage, you're mocking the requests themselves. CHARLES: Yeah. And you've got such great support for the whole factories. I love factories. It's something that is very prevalent in the Ruby community, and maybe not so much elsewhere. But the ability to very, very quickly crank out high-fidelity production data... WIL: Yeah. And you don't have to have files upon files of fixtures. CHARLES: Yeah, exactly. And you can change, if something about your schema changes, you can change the factory and now your test data is up and running. So, Ember has this tool called Mirage which is just, like I said, it's so fantastic. Oh yeah, it's also go support for running your application. Not just in your tests, but you can actually run your application with Mirage on and... WIL: Oh right, yeah. CHARLES: And you've got now the most incredible rapid prototyping tool. WIL: Yeah. You don't need to connect to a server to see fake data. CHARLES: Right, right. And we were even talking about this yesterday to a potential client. they're trying to, they've got to present something to investors. And how wonderful is it to just be like, “You know what? We just don't want to invest in all, we don't want to move the inertia, invest the money to generate the force to move the inertia of a backend.” Especially in this particular use case, the backend was going to be really, really heavy. WIL: Yeah. And there were some questions about the backend that we couldn't address quite yet but we wanted to start working on something that we could show, something demo-able. CHARLES: Right, exactly. And so, Mirage is just so wonderful for that. But again, Mirage is, it's an Ember-specific project. WIL: Right. CHARLES: So, the question was, “How are we going to use that?” WIL: And you actually took this on yourself. CHARLES: Mmhmm. WIL: I just saw this pop-up one day and boom, you converted Ember Mirage to vanilla JavaScript. [Chuckles] CHARLES: So, I did extract it. But the lion's share of the credit goes to the developers of Mirage themselves. Sam Selikoff and the Mirage community, they built Mirage not using much of Ember. There were some utilities that they were using, but mainly things like string helpers to convert between camel-case and dash-case, and using a Broccoli build, or using an Ember CLI build. WIL: Yeah. That was one of the challenges that we came across using Mirage outside of Ember, was how do we autoload this Mirage folder with all this Mirage config and Mirage factories and models, et cetera. CHARLES: Right. The internals were all just straight up JavaScript classes, for the most part. And so, extracting it, it was a lot of work. But 90% of the work was already done. It only took three or four days to do it. WIL: Amazing. CHARLES: Yeah. So, it was actually a really pleasant experience. I was able to swap out all of the Ember string helpers for Lodash. So now, it's good to go. It shares a Git history with Ember CLI Mirage, so it's basically a fork. WIL: Mmhmm. CHARLES: Like, a very heavily patched Ember CLI Mirage. But I keep it up-to-date so that it doesn't... WIL: Good. [Inaudible] CHARLES: Yeah, so I think the last time I merged in from master was about a month ago, something like that. Because it's got all the features that we need but it's not a big deal to rebase or just to merge it on over in. Because yeah, it's a really straightforward set of patches. WIL: Was there any talk with the creators of Ember Mirage about getting this upstream? CHARLES: So, I've talked a little bit with Sam about it. And from what I can tell, his feeling on it is like, “Hey, my goal right now is to focus on this being the best testing and data stubbing platform for Ember. Anything that happens out there, outside of that scope, that's great. And I certainly won't get in the way of it. But I'm pretty maxed out in terms of the open source credits that I have to spend.” WIL: [Chuckles] CHARLES: And there hasn't been much motion there. I'm happy where it is right now. I would like to see it merged into upstream. I think it would be great to have basically this Mirage Server and then have Ember CLI bindings for it. WIL: Yeah, yeah. I was going to say, either another Ember CLI specific package for Mirage or maybe to make it a non-breaking change or something. CHARLES: Yeah. WIL: Just like an Ember-specific entry point. CHARLES: Right, exactly. And I think that's definitely doable, if someone wants to take it on. I will say, we have been using this extracted plain vanilla JavaScript Mirage Server now for what, almost six months? WIL: Yeah. CHARLES: And it really hasn't... WIL: Yeah, I don't think I ran into one issue with that. CHARLES: Yeah. It's solid. It's really, really good. So, kudos to the Mirage team for doing that. And if anybody is interested in using Mirage in their projects, it's definitely there and we'll put it in the show notes. WIL: Yeah. We call it Mirage Server. CHARLES: Mirage Server, yeah. So, I don't know. Maybe it's time to reopen that conversation. But it has become a very integral and critical piece of the way that we test our JavaScript applications now. So, what are the foundations of it? We've got, we're using Mirage. We're using these convergent assertions. We're using Mocha, although that's really... WIL: Yeah, we have jQuery and Chai jQuery just to help us out with interacting with the browser as a user would. And I think one of the big challenges with that actually, I just remembered, was triggering changes in React. CHARLES: Yeah. WIL: I think this is pretty specific to React. You might run into problems with the view. I don't know how to mess with view. But in React, at least I think 15 or React 16, one of them, they changed the descriptor of the value property on an element so that they can appropriately interact with it, make changes, watch for changes, et cetera. So, when you set this value property using jQuery or just straight up ‘.value()', that change event isn't triggered in React. Your on-change handlers are never called. CHARLES: Wait, they actually update the JavaScript property descriptor of the DOM element. WIL: Yes. CHARLES: Boo. WIL: Yeah. So, there's a nice little helper out there called React Trigger Change. I dug through it and I've stripped some of it down to just be for more modern browsers, more modern React. But there's a lot of good code in there. And basically, it just caches that descriptor, updates the value, triggers the change, and then adds the descriptor back. And that ends up triggering that React element. CHARLES: Okay. [Laughs] WIL: [Chuckles] Yeah, so that calls your handlers and that's how we get around that. CHARLES: Right. There's a few fun little hacks there. But I think it is good to tie that into a larger point, is that the amount of touch that you have with the framework is actually very low. WIL: Yeah. CHARLES: So, the amount of affordances that we've had to make just for React, there's that, that you just mentioned. And is there… there's not much else. We had to write a test harness to mount the app. But that's like... WIL: Yeah, yeah. Our describe application helper is pretty React-specific. CHARLES: Right. WIL: So, you'd have to render it and set up a Mirage server, et cetera. CHARLES: Right. But that's application-specific setup. WIL: Yeah, that's one file. CHARLES: Right. WIL: So, your goal for acceptance tests is you want to be able to have a refactor and your acceptance tests still pass. CHARLES: Right. WIL: So, what if that refactor involves switching libraries? CHARLES: Right. WIL: If you're writing Ember acceptance tests, you're going to have to rewrite all your acceptance tests. CHARLES: Right. WIL: That's a huge downside. CHARLES: Right. WIL: So, with this method of interacting with the actual library very little, we have that one file that sets up our app and then we have that one trigger change helper, we remove those, we can use whatever framework we want underneath this. And our tests would still work. CHARLES: Yeah, exactly. And I think that we actually could theoretically, and honestly I have enough confidence in this style that we're developing the tests now, we could refactor this application to Ember and not have to rewrite our tests. WIL: Yeah, exactly. CHARLES: In fact, the tests would be an aide to do that. WIL: Yeah, and the tests would be faster than Ember testing with that run loop problem. CHARLES: Yeah, exactly. that's really something to think about or to think on, is like, “Wow. You're really at this point completely, not completely, but very loosely coupled to the actual internal library code.” Which is one of the goals of a nice, big acceptance test, is to be able to make major changes, break big bones, and be able to set them and have your acceptance test suite be the bulwark that holds it all together. WIL: Yeah. CHARLES: So, I actually don't know what a bulwark is. WIL: [Laughs] CHARLES: I just know that it's a really strong thing. [Laughter] CHARLES: Maybe we could put that in the show notes. [Laughter] WIL: A link to what that is. CHARLES: [Laughs] So, alright. Well, I'm trying to think if there is anything else that we wanted to mention. Any challenges? Any next things? WIL: So, one of our next steps is something we mentioned that Cypress does, is they wait for elements to exist before they interact with them. And we're actually not doing that in our app currently. And we don't have helpers out there for it yet. CHARLES: Right. WIL: But that's very much the next step. When we go to click an element in our ‘before each', we have these describes that are nested. Say, you have nested describes and you get down three levels into a ‘before each' when you're clicking a button. That button might not exist yet. CHARLES: Right. WIL: And especially since we're using jQuery, if you trigger a change on an empty jQuery element, it's not going to throw an error. It's just not going to tell you that it triggered anything. CHARLES: Right. WIL: So, we get those skips where that button's not getting clicked and we should really be waiting for that button to exist. CHARLES: Right. So, what we've done right now is we're converging on our assertions at the backend of a test. But at the frontend of a test we need to also be converging at some state before we can actually interact with the application. WIL: Right, yeah. CHARLES: So yeah, so that part is missing. And that actually brings up, we are very slowly but nevertheless doing, we're collecting these convergent assertions and convergent helpers in a repository on our GitHub account. We're going to be adding these things so that you can either use them out of the box or use them to make your own testing library. WIL: Yeah. And one of the other next steps that goes along with waiting for the element to exist is when you need to chain convergences. Like, wait for this element to exist and then click it and then wait for this thing to happen before actually running a test. And that presents the problem of our convergences are waiting for that timeout and those timeouts will accumulate. So if you have three chained convergences, that's now a six thousand millisecond timeout as opposed to a two thousand millisecond timeout. CHARLES: Right. WIL: So, one of the next steps is getting that tracking under control so if you chain three convergences together, they're smart about it and they still fail under the two thousand millisecond timeout. CHARLES: Right, right. So yeah, so we're going to be collecting all this stuff that we're learning into some publicly available code. We have a repository set up. I don't know if I want to announce it just yet, because it's really early days. WIL: Yeah. CHARLES: But that definitely is the plan. And that way, whether you're using Mocha or whether you're using QUnit or whether you're using Chai or jQuery, you've got these underlying primitives that help you converge on a state, whether that state is to interact with some piece of the DOM or to just assert some observation is made about that state. We'll be continuing on that. But by all means, get in touch if this is something that is of interest to you. Let's make something happen, because it's something that we're pretty excited about. And honestly, it's pretty comfortable living inside the four walls of this test suite. WIL: Yeah. CHARLES: It feels pretty good. WIL: It does, yeah. They're very fast. And some places in the test might need a little reworking, but for the most part all of our tests are very well-written, very well-readable. And you can just open up a test and know exactly what's going on. CHARLES: Yeah. Alright. Well, I think that about does it for Episode 90. Wow, Episode 90. WIL: Man, coming up on that 100. CHARLES: Yeah. We're going to have to have a birthday cake or something. WIL: Do we celebrate Episode 100 or Episode 104? CHARLES: What's 104? WIL: 104 would be 2 years. CHARLES: Oh really? WIL: Well, I mean 2 years' worth of podcasts. CHARLES: Oh, right. 2 years' worth of podcasts. Yeah. WIL: Yeah, like if you go every week. CHARLES: Maybe we should celebrate a hundred hours or something like that. WIL: Oh yeah. CHARLES: We can add up the thing or celebrate… I don't know, be like, “You've literally wasted 2 years of your life.” WIL: [Laughs] CHARLES: “2 weeks of your life listening to the podcast.” Anyway, so that's it for Episode 90. and thank you so much, Wil. WIL: Thanks for having me. CHARLES: It's always a pleasure to talk about these topics with you. And as always, if you need to get in touch with us, please reach out to us on Twitter. We are @TheFrontside. Or you can send an email to contact@frontside.io.

Chase and Jonathan are once again joined by Sam Selikoff to discuss Ember marketing strategies, the state and future of Ember CLI Mirage, and EmberMap

This week, we talk with Sam Selikoff, the mastermind behind Ember CLI Mirage. He shares how he got started with programming, some tips for avoiding burnout, why he created CLI Mirage, some tips for using it, why it's important to write great documentation, and more. Show Links: Sam Selikoff Follow Sam on Twitter Ember CLI Mirage Pact (ruby) Contract-driven Design by Martin Fowler EmberMap Practical Object Oriented Design in Ruby by Sandy Metz

Chase and Jonathan speak with Sam Selikoff about the Ember Community, Consumer Driven Contracts, and his project Ember CLI Mirage.