Podcasts about create react app

Play Episode Listen Later Feb 23, 2025 50:35

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 15/02 a 21/02.

Fim do Create React App; Novo framework Brasileiro em Dart; Microsoft tem Chip Quântico Revolucionário; Ex-CTO da OpenAI cria nova IA [Compilado #187]

Syntax - Tasty Web Development Treats

Play Episode Listen Later Feb 23, 2025 50:35

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 15/02 a 21/02.

AI is stifling tech adoption (News)

The Changelog

Play Episode Listen Later Feb 17, 2025 8:06

Declan Chidlow proposes that AI is stifling tech adoption, Ariel Salminen shares 17 pieces of advice she's learned about leading successful product teams, Benj Edwards tells the story of WikiTok, the React team sunsets Create React App & Ruben Schade says boring tech is mature, not old.

ai tech adoption react stifling create react app jerod santo benj edwards

AI is stifling tech adoption

Changelog News

Play Episode Listen Later Feb 17, 2025 8:06

Declan Chidlow proposes that AI is stifling tech adoption, Ariel Salminen shares 17 pieces of advice she's learned about leading successful product teams, Benj Edwards tells the story of WikiTok, the React team sunsets Create React App & Ruben Schade says boring tech is mature, not old.

ai tech adoption react stifling create react app jerod santo benj edwards

AI is stifling tech adoption (Changelog News #132)

Changelog Master Feed

Play Episode Listen Later Feb 17, 2025 8:06 Transcription Available

Declan Chidlow proposes that AI is stifling tech adoption, Ariel Salminen shares 17 pieces of advice she's learned about leading successful product teams, Benj Edwards tells the story of WikiTok, the React team sunsets Create React App & Ruben Schade says boring tech is mature, not old.

ai tech adoption react stifling changelog create react app jerod santo benj edwards

833: Next Gen Fullstack React with TanStack

Play Episode Listen Later Oct 11, 2024 62:33

Scott and Wes talk with Tanner Linsley, creator of TanStack, about the React ecosystem, and the evolution and futue of TanStack's suite of tools, including TanStack Router and TanStack Start. Show Notes 00:00 Welcome to Syntax! 02:59 What is TanStack Start? UnJS Nitro Vinxi 06:17 What is the Vite Environment API? 07:21 Was it always the plan to use Vite? 08:02 TanStack Router and client-side vs server-side 16:18 How TanStack Start will work 27:26 Moving from Create React App to TanStack 30:42 Brought to you by Sentry.io 31:15 Will TanStack Router ever support other frameworks? 33:54 How will TanStack Start handle forms? 36:13 TanStack Virtual 39:41 What is the future of TanStack? Convex 42:49 How Tanner writes documentation 47:55 Server functions and middleware 54:41 When will TanStack Start be in beta? 57:00 Sick Picks + Shameless Plugs Sick Picks Tanner: LG C4 Ultra Slim Fit TV Wall Mount Shameless Plugs Tanner: TanStack Blog @TKDodo Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

moving react next gen socials server vite sentry fullstack syntax convex create react app

CSS in React Server Components with Josh Comeau

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Jul 10, 2024 42:14

Josh Comeau, an indie hacker and educator, delves into CSS in React Server Components, shares his journey in web development, offers insights on server-side rendering, and provides tips on mastering CSS for JavaScript developers. Links https://www.joshwcomeau.com https://twitter.com/joshwcomeau https://www.linkedin.com/in/joshwcomeau https://github.com/JoshWComeau https://css-for-js.dev 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 provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Josh W. Comeau.

ai ux online courses javascript vite hooks css php concordia university tailwinds parcel user experience design comeau interaction design performance optimization mdx create react app react server components styled components

Microsoft lança linguagem para IoT; Docker é Pop; Vercel investe em IA; Apple libera SDK do visionOS; Opera One inova com IA; C++ 26; 30 anos do FreeBSD; Modo readonly no VS Code [Compilado #106]

Play Episode Listen Later Jun 24, 2023 67:13

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 10/06 a 23/06!

Microsoft lança linguagem para IoT; Docker é Pop; Vercel investe em IA; Apple libera SDK do visionOS; Opera One inova com IA; C++ 26; 30 anos do FreeBSD; Modo readonly no VS Code [Compilado #106]

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later Jun 24, 2023 67:13

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 10/06 a 23/06!

476: OpenSauced with Brian Douglas

Play Episode Listen Later May 25, 2023 41:23

Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source. Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project. OpenSauced (https://opensauced.pizza/) Follow OpenSauced on Twitter (https://twitter.com/saucedopen), GitHub (https://github.com/open-sauced), Instagram (https://www.instagram.com/opensauced/), YouTube (https://www.youtube.com/opensauced), Discord (https://discord.com/invite/U2peSNf23P), and Dev.to (https://dev.to/opensauced). Follow Brian Douglas on LinkedIn (https://www.linkedin.com/in/brianldouglas/), Twitter (https://twitter.com/bdougieYO), or visit his website (https://b.dougie.dev/). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today. BRIAN: My pleasure. Thanks for inviting me on the podcast. VICTORIA: Just tell us a little bit more about OpenSauced. BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found. WILL: I love it. BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so... VICTORIA: Right. So maybe tell me what led you to start this company? BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate. So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information. So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner. And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest. WILL: [laughs] BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that." So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today. And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company. VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs] WILL: [laughs] Yes. VICTORIA: I have so many questions. [laughs] WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it. So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer? BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is. But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in? And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that. So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on. Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects. A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list. And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that. So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive? Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you. And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so... VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO. But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills. BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother. And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it. So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks. So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016. But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this? So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one. But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after. So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead. But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year. WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post. Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did. So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now? BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start? And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos. Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career. With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project? Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects. VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it? BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable. And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well? And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year. And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen. WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project? BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding. WILL: [laughs] BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy. And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today. It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience. When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically. By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using. So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it. WILL: That's really good advice, yep. VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role? BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so. But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing. So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem. As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience. And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon. WILL: I love, love, love that. MID-ROLL AD: Now that you have funding, it's time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on. BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs. And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that. But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff. So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you. And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work. Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity. So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market. VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves? BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to. We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description. And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge. And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school. So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups. What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career. VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on. BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks. And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path. WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning? BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem. I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down. I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation. So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah. WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down. And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice. VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian? BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today? VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well. So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well. And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs] And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs] BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that. But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem. But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena. VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot. BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them. VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive. BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that. Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing. I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience. But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it. And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation. So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it? And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity. But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested. VICTORIA: Very cool. Thank you for that. WILL: I'm just processing on the whole conversation. It has just been great. VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian? BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch. VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me @will23larry This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brian Douglas.

ceo director netflix california black google ai disney apple pr san francisco seattle microsoft ireland write kanye west taylor swift espn mba beyonce mvp managing directors discord ios oakland albert einstein juneteenth swift react crm openai babel rust ignite hilton open source aws github walgreens dev marriott devops javascript contributing vmas s3 kubernetes relativity liftoff cloudflare sdks mandy moore product strategy sre stack overflow grunt ruby on rails zig gulp terraform cli mission control ionic react native will you readme giant robots netlify rsvps objective c black girls code right it cdns webpack black engineers repl brian douglas github universe will will github pages brian yeah brian you create react app github issues brian no alberto savoia browserify rubymine will larry victoria well

#159: Ny spalte, Star Wars-konsert, Java, Fast Candy

kode24-timen

Play Episode Listen Later Apr 20, 2023 72:12

Vi har premiere på den splitter nye spalta Lytterkontakt - send oss tilbakemeldinger, spørsmål, kjeft, hva som helst, på hei@kode24.no eller et helt annet sted - hvor som helst! Jørgen har vært på TikTok-butikken Fast Candy. Ole Petter har vært på Star Wars-konsert. Vi ser på norske utvikleres lønn. Create React App fortsetter å dominere. Java blir enklere. Kontortvang. kode24-klubben vil gjerne bli utvikler. Jørgen advarer mot ting han har kjøpt på Fast Candy. Ole Petter nekter å slutte å snakke om den nye høyttrykkspyleren sin. Vitsespalta nekter også å slutte. See omnystudio.com/listener for privacy information.

tiktok star wars java konsert spalte create react app ole petter lytterkontakt

The Launch Pad with Lindsay Wardell and Tejas Kumar

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Feb 17, 2023 41:07

We're back with episode three of the Launch Pad with Lindsay Wardell and Tejas Kumar, as we cover the latest acquisition of Gatsby, what we should do with Create React App, and what we think of the Astro 2.0 release. Links Lindsay Wardell https://twitter.com/lindsaykwardell https://www.lindsaykwardell.com/ https://www.linkedin.com/in/lindsaykwardell/ https://github.com/lindsaykwardell https://dev.to/lindsaykwardell Tejas Kumar https://tej.as https://twitter.com/TejasKumar_ https://github.com/tejasq https://www.youtube.com/c/tejaskumar Netlify acquires Gatsby, composable architectures, and the future of Jamstack Netlify announced that it would be acquiring Gatsby (https://thenewstack.io/netlify-acquires-gatsby-its-struggling-jamstack-competitor/) Biilmann cited Gatsby's recently released Valhalla platform (https://thenewstack.io/netlify-acquires-gatsby-its-struggling-jamstack-competitor/) Netlify Acquires Gatsby Inc. to Accelerate Adoption of Composable Web Architectures (https://www.netlify.com/press/netlify-acquires-gatsby-inc-to-accelerate-adoption-of-composable-web-architectures/) Netlify Acquires Gatsby, Its Struggling Jamstack Competitor (https://thenewstack.io/netlify-acquires-gatsby-its-struggling-jamstack-competitor/) Replace Create React App recommendation with Vite Replace Create React App recommendation with Vite (https://github.com/reactjs/reactjs.org/pull/5487?ck_subscriber_id=1866525605&utm_source=convertkit&utm_medium=email&utm_campaign=%E2%9A%9B%EF%B8%8F+This+Week+In+React+%23133%3A+Astro%2C+React+dying%3F%2C+Qwikify%2C+CRA%2C+Next.js%2C+Remix%2C+Redux%2C+Storybook%2C+Redwood%2C+Nextra%2C+React-Native...%20-%209971987#top) Twitter resoundingly agreed about using CRA (https://twitter.com/t3dotgg/status/1616933234478309378) CRA's inability to support PostCSS configurations and recommending Vite, Parcel, Next, or Remix (https://twitter.com/adamwathan/status/1616938902966640641?s=20&t=u1lqs5T5L2Yu05PFL8NfCWjoe5xI8FgWvRhXO6tY34w) Dan Abromov's response (https://github.com/reactjs/reactjs.org/pull/5487?ck_subscriber_id=1866525605&utm_source=convertkit&utm_medium=email&utm_campaign=%E2%9A%9B%EF%B8%8F+This+Week+In+React+%23133%3A+Astro%2C+React+dying%3F%2C+Qwikify%2C+CRA%2C+Next.js%2C+Remix%2C+Redux%2C+Storybook%2C+Redwood%2C+Nextra%2C+React-Native...%20-%209971987#issuecomment-1409720741) Release of Astro 2 and “hybrid rendering” Astro 2 released in mid-January (https://astro.build/blog/astro-2/) Hybrid rendering alternative API considerations (https://github.com/withastro/roadmap/blob/main/proposals/0029-prerender-api.md#alternatives) Unlock New Possibilities with Hybrid Rendering (https://astro.build/blog/hybrid-rendering/?ck_subscriber_id=1866525605&utm_source=convertkit&utm_medium=email&utm_campaign=%E2%9A%9B%EF%B8%8F+This+Week+In+React+%23133%3A+Astro%2C+React+dying%3F%2C+Qwikify%2C+CRA%2C+Next.js%2C+Remix%2C+Redux%2C+Storybook%2C+Redwood%2C+Nextra%2C+React-Native...%20-%209971987) Introducing Content Collections: Type-Safe Markdown in Astro 2.0 (https://astro.build/blog/introducing-content-collections/?ck_subscriber_id=1652256478) Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) 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 Guests: Lindsay Wardell and Tejas Kumar.

remix hybrid api astro kumar valhalla vite gatsby launchpad cra parcel tejas create react app postcss lindsay wardell

#151: Hvit skjorte på jobb, kode24-dagen, Remix og tebriks

kode24-timen

Play Episode Listen Later Feb 9, 2023 65:38

Jørgen har hatt på seg hvit skjorte på jobb, til Ole Petters store forferdelse. Ole Petter gruer seg til kode24-dagen i dag. Bjarne Stroustrup er sinna på Rust. Netlify har kjøpt Gatsby. Create React App får kritikk og drømmer om framtida. Kristofer Selbekk sier han bruker Remix til alt. kode24-klubben krangler om en knapp. Jørgen savner å lese nettaviser og tester og sånt. Ole Petter savner å spise mer tebriks. See omnystudio.com/listener for privacy information.

remix rust dagen gatsby jobb netlify hvit create react app ole petter

[Weekend Drop] Developer Experience & the Coding Career Handbook with Corey Quinn on Screaming in the Cloud

The Swyx Mixtape

Play Episode Listen Later Oct 22, 2022 34:12

Listen to Screaming in the Cloud: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/learning-in-public-with-swyx/Episode SummaryToday Corey sits down with swyx, head of developer experience at Airbyte, and so much more! They begin by chatting about swyx's career history, professional motivation, and an industry taboo: following the money. Then Corey and swyx move into a discussion about the surprisingly challenging nature of developer experience and what it means to “learn in public.” swyx talks about expertise and how to quantify and demonstrate learning. Corey and swyx discuss swyx's book “The Coding Career Handbook” and career coaching. swyx shares about his most recent foray into management in the era of zoom meetings, and conclude the conversation by talking about data integration and swyx's latest job at Airbyte.Links Referenced: “Learning Gears” blog post: https://www.swyx.io/learning-gears The Coding Career Handbook: https://learninpublic.org Personal Website: https://swyx.io Twitter: https://twitter.com/swyx TranscriptCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Some folks are really easy to introduce when I have them on the show because, “My name is, insert name here. I built thing X, and my job is Y at company Z.” Then we have people like today's guest.swyx is currently—and recently—the head of developer experience at Airbyte, but he's also been so much more than that in so many different capacities that you're very difficult to describe. First off, thank you for joining me. And secondly, what's the deal with you?swyx: [laugh]. I have professional ADD, just like you. Thanks for having me, Corey. I'm a—Corey: It works out.swyx: a big fan. Longtime listener, first time caller. Love saying that. [laugh].Corey: You have done a lot of stuff. You have a business and finance background, which… okay, guilty; it's probably why I feel some sense of affinity for a lot of your work. And then you went into some interesting directions. You were working on React and serverless YahvehScript—which is, of course, how I insist on pronouncing it—at Two Sigma, Netlify, AWS—a subject near and dear to my heart—and most recently temporal.io.And now you're at Airbyte. So, you've been focusing on a lot of, I won't say the same things, but your area of emphasis has definitely consistently rhymed with itself. What is it that drives you?swyx: So, I have been recently asking myself a lot of this question because I had to interview to get my new role. And when you have multiple offers—because the job market is very hot for DevRel managers—you have to really think about it. And so, what I like to say is: number one, working with great people; number two, working on great products; number three, making a lot of money.Corey: There's entire school of thought that, “Oh, that's gauche. You shouldn't mention trying to make money.” Like, “Why do you want to work here because I want to make money.” It's always true—swyx: [crosstalk 00:03:46]—Corey: —and for some reason, we're supposed to pretend otherwise. I have a lot of respect for people who can cut to the chase on that. It's always been something that has driven me nuts about the advice that we give a new folks to the industry and peop—and even students figuring out their career path of, “Oh, do something you love and the money will follow.” Well, that's not necessarily true. There are ways to pivot something you'd love into something lucrative and there are ways to wind up more or less borderline starving to death. And again, I'm not saying money is everything, but for a number of us, it's hard to get to where we want to be without it.swyx: Yeah, yeah. I think I've been cast with the kind of judgmental label of being very financially motivated—that's what people have called me—for simply talking about it. And I'm like, “No. You know, it's number three on my priority list.” Like, I will leave positions where I have a lot of money on the table because I don't enjoy the people or the products, but having it up there and talking openly about it somehow makes you [laugh] makes you sort of greedy or something. And I don't think that's right. I tried to set an example for the people that I talk to or people who follow me.Corey: One of the things I've always appreciated about, I guess, your online presence, which has remained remarkably consistent as you've been working through a bunch of different, I guess, stages of life and your career, is you have always talked in significant depth about an area of tech that I am relatively… well, relatively crap at, let's be perfectly honest. And that is the wide world of most things front-end. Every time I see a take about someone saying, “Oh, front-end is junior or front-end is somehow less than,” I'd like to know what the hell it is they know because every time I try and work with it, I wind up more confused than I was when I started. And what I really appreciate is that you have always normalized the fact that this stuff is hard. As of the time that we're recording this a day or so ago, you had a fantastic tweet thread about a friend of yours spun up a Create React App and imported the library to fetch from an endpoint and immediately got stuck. And then you pasted this ridiculous error message.He's a senior staff engineer, ex-Google, ex-Twitter; he can solve complex distributed systems problems and unable to fetch from a REST endpoint without JavaScript specialist help. And I talk about this a lot in other contexts, where the reason I care so much about developer experience is that a bad developer experience does not lead people to the conclusion of, “Oh, this is a bad interface.” It leads people to the conclusion, “Oh, I'm bad at this and I didn't realize it.” No. I still fall into that trap myself.I was under the impression that there was just this magic stuff that JS people know. And your tweet did so much to help normalize from my perspective, the fact that no, no, this is very challenging. I recently went on a Go exploration. Now, I'm starting to get into JavaScript slash TypeScript, which I think are the same thing but I'm not entirely certain of that. Like, oh, well, one of them is statically typed, or strongly typed. It's like, “Well, I have a loud mechanical keyboard. Everything I do is typing strongly, so what's your point?”And even then we're talking past each other in these things. I don't understand a lot of the ecosystem that you live your career in, but I have always had a tremendous and abiding respect for your ability to make it accessible, understandable, and I guess for lack of a better term, to send the elevator back down.swyx: Oh, I definitely think about that strongly, especially that last bit. I think it's a form of personal growth. So, I think a lot of people, when they talk about this sending the elevator back down, they do it as a form of charity, like I'm giving back to the community. But honestly, you actually learn a lot by trying to explain it to others because that's the only way that you truly know if you've learned something. And if you ever get anything wrong, you'll—people will never let you forget it because it is the internet and people will crawl over broken glass to remind you that you're wrong.And once you've got it wrong, you will—you know, you've been so embarrassed that you'll never forget it. So, I think it's just a really good way to learn in public. And that's kind of the motto that I'm kind of known for. Yeah, we can take the direction anywhere you want to go in JavaScript land. Happy to talk about it all day. [laugh].Corey: Well, I want to start by something you just said where you're doing the learning in public thing. And something I've noticed is that there are really two positions you can take—in the general sense—when you set out to make a bit of a reputation for yourself in a particular technical space. You can either do the, “I'm a beginner here, same as the rest of you, and I'm learning in public,” or you can position yourself as something of an expert. And there are drawbacks and advantages to both. I think that if you don't look as wildly over-represented as I do, both of them are more fraught in different ways, where it's, “Oh, you're learning in public. Ah, look at the new person, she's dumb.”Or if you're presenting yourself as an expert, you get nibbled to death by ducks on a lot of the deep technical nuances and well, actually'ed to death. And my position has always been and this is going to be a radical concept for some folks, is that I'm genuinely honest. I tend to learn in public about the things that I don't know, but the things that I am something of a subject matter expert in—like, I don't know, cloud billing—I don't think that false modesty necessarily serves me particularly well. It's yeah, I know exactly what I'm talking about here. Pretending otherwise it's just being disingenuous.swyx: I try to think of it as having different gears of learning in public. So, I've called this “Learning Gears” in a previous blog post of mine, where you try to fit your mode of learning to the terrain that you're on, your domain expertise, and you should never over-represent the amount that you know because I think people are very rightly upset when there are a lot of people—let's say on Twitter, or YouTube, or Udemy even—who present themselves as experts who are actually—they just read the docs the previous night. So, you should try not to over-represent your expertise.But at the same time, don't let your imposter syndrome stop you from sharing what you are currently learning and taking corrections when you're wrong. And I think that's the tricky balance to get which is constantly trying to put yourself out there while accepting that you might be wrong and not getting offended when or personally attacked when someone corrects you, inevitably. And sometimes people will—especially if you have a lot of followers, people will try to say—you know, someone of your following—you know, it's—I kind of call this follower shaming, like, you should act, uh—invulnerable, or run every tweet through committee before you tweet after a certain sort of following size. So, I try to not do that and try to balance responsibility with authenticity.Corey: I think that there's something incredibly important about that, where there's this idea that you either become invulnerable and get defensive and you yell at people, and down that path lies disaster because, believe it or not, we all get it wrong from time to time, and doubling down and doubling down and doubling down again, suddenly, you're on an island all by yourself and no one respectable is going to be able to get there to help you. And the other side of it is going too far in the other direction, where you implicitly take any form of criticism whatsoever as being de facto correct. And I think that both paths don't lead to super great places. I think it's a matter of finding our own voices and doing a little bit of work as far as the validity of accepting a given piece of feedback goes. But other than that, I'm a big fan of being able to just more or less be as authentic as possible.And I get that I live in a very privileged position where I have paths open to me that are not open to most folks. But in many respects so to you are one of the—easily—first five people I would think of if someone said, “Hey if I need to learn JavaScript for someone, who should I talk to first?” You're on that list. And you've done a lot of things in this area, but you've never—you alluded to it a few minutes ago, but I'm going to call it out a little more pointedly—without naming names, let's be clear—and that you're never presented as a grifter, which is sort of the best way I can think of it of, “Well, I just learned this new technology stack yesterday and now I'm writing a book that I'm going to sell to people on how to be an expert at this thing.” And I want to be clear, this is very distinct from gatekeeping because I think that, “Oh, well, you have to be at least this much of an expert—” No, but I think that holding yourself out as I'm going to write a book on how to be proud of how to become a software engineer.Okay, you were a software engineer for six months, and more to the point, knowing how to do a thing and knowing how to teach a thing are orthogonal skill sets, and I think that is not well understood. If I ever write a book or put something—or some sort of info product out there, I'm going to have to be very careful not to fall into that trap because I don't want to pretend to be an expert in things that I'm not. I barely think I'm an expert in things that I provable am.swyx: there are many ways to answer that. So, I have been accused a couple of times of that. And it's never fun, but also, if you defend yourself well, you can actually turn a critic into a fan, which I love doing.Corey: Mm-hm.swyx: [laugh].Corey: Oh yes.swyx: what I fall back to, so I have a side interest in philosophy, based on one of my high school teachers giving us, like, a lecture in philosophy. I love him, he changed my life. [Lino Barnard 00:13:20], in case—in the off chance that he's listening. So, there's a theory of knowledge of, like, how do you know what you know, right? And if you can base your knowledge on truth—facts and not opinions, then people are arguing with the facts and not the opinions.And so, getting as close to ground truth as possible and having certainty in your collection of facts, I think is the basis of not arguing based on identity of, like, “Okay, I have ten years experience; you have two years experience. I am more correct than you in every single opinion.” That's also not, like, the best way to engage in the battlefield of ideas. It's more about, do you have the right amount of evidence to support the conclusions that you're trying to make? And oftentimes, I think, you know, that is the basis, if you don't have that ability.Another thing that I've also done is to collect the opinions of others who have more expertise and present them and curate them in a way that I think adds value without taking away from the individual original sources. So, I think there's a very academic way [laugh] you can kind of approach this, but that defends your intellectual integrity while helping you learn faster than the typical learning rate. Which is kind of something I do think about a lot, which is, you know, why do we judge people by the number of years experience? It's because that's usually the only metric that we have available that is quantifiable. Everything else is kind of fuzzy.But I definitely think that, you know, better algorithms for learning let you progress much faster than the median rate, and I think people who apply themselves can really get up there in terms of the speed of learning with that. So, I spend a lot of time thinking about this stuff. [laugh].Corey: It's a hard thing to solve for. There's no way around it. It's, what is it that people should be focusing on? How should they be internalizing these things? I think a lot of it starts to with an awareness, even if not in public, just to yourself of, “I would like advice on some random topic.” Do you really? Are you actually looking for advice or are you looking—swyx: right.Corey: For validation? Because those are not the same thing, and you are likely to respond very differently when you receive advice, depending on which side of that you're coming from.swyx: Yeah. And so, one way to do that is to lay out both sides, to actually demonstrate what you're split on, and ask for feedback on specific tiebreakers that would help your decision swing one way or another. Yeah, I mean, there are definitely people who ask questions that are just engagement bait or just looking for validation. And while you can't really fix that, I think it's futile to try to change others' behavior online. You just have to be the best version of yourself you can be. [laugh].Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: So, you wrote a book that is available at learninpublic.org, called The Coding Career Handbook. And to be clear, I have not read this myself because at this point, if I start reading a book like that, and you know, the employees that I have see me reading a book like that, they're going to have some serious questions about where this company is going to be going soon. But scrolling through the site and the social proof, the testimonials from various people who have read it, more or less read like a who's-who of people that I respect, who have been on this show themselves.Emma Bostian is fantastic at explaining a lot of these things. Forrest Brazeal is consistently a source to me of professional envy. I wish I had half his musical talent; my God. And your going down—it explains, more or less, the things that a lot of folks people are all expected to know but no one teaches them about every career stage, ranging from newcomer to the industry to senior. And there's a lot that—there's a lot of gatekeeping around this and I don't even know that it's intentional, but it has to do with the idea that people assume that folks, quote-unquote, “Just know” the answer to some things.Oh, people should just know how to handle a technical interview, despite the fact that the skill set is completely orthogonal to the day-to-day work you'll be doing. People should just know how to handle a performance review, or should just know how to negotiate for a raise, or should just know how to figure out is this technology that I'm working on no longer the direction the industry is going in, and eventually I'm going to wind up, more or less, waiting for the phone to ring because there's only three companies in the world left who use it. Like, how do you keep—how do you pay attention to what's going on around you? And it's the missing manual that I really wish that people would have pointed out to me back when I was getting started. Would have made life a lot easier.swyx: Oh, wow. That's high praise. I actually didn't know we're going to be talking about the book that much. What I will say is—Corey: That's the problem with doing too much. You never know what people have found out about you and what they're going to say when they drag you on to a podcast.swyx: got you, got you. Okay. I know, I know, I know where this is going. Okay. So, one thing that I really definitely believe is that—and this happened to me in my first job as well, which is most people get the mentors that they're assigned at work, and sometimes you have a bad roll the dice. [laugh].And you're supposed to pick up all the stuff they don't teach you in school at work or among your friend group, and sometimes you just don't have the right network at work or among your friend group to tell you the right things to help you progress your career. And I think a lot of this advice is written down in maybe some Hacker News posts, some Reddit posts, some Twitter posts, and there's not really a place you to send people to point to, that consolidates that advice, particularly focused at the junior to senior stage, which is the stage that I went through before writing the book. And so, I think that basically what I was going for is targeting the biggest gap that I saw, which is, there a lot of interview prep type books like Crack the Coding Career, which is kind of—Crack the Coding Interview, which is kind of the book title that I was going after. But once you got the job, no one really tells you what to do after you got that first job. And how do you level up to the senior that everyone wants to hire, right? There's—Corey: “Well, I've mastered cracking the coding interview. Now, I'm really trying to wrap my head around the problem of cracking the showing up at work on time in the morning.” Like, the baseline stuff. And I had so many challenges with that early in my career. Not specifically punctuality, but just the baseline expectation that it's just assumed that by the time you're in the workplace earning a certain amount of money, it's just assumed that you have—because in any other field, you would—you have several years of experience in the workplace and know how these things should play out.No, the reason that I'm sometimes considered useful as far as giving great advice on career advancement and the rest is not because I'm some wizard from the future, it's because I screwed it all up myself and got censured and fired and rejected for all of it. And it's, yeah, I'm not smart enough to learn from other people's mistakes; I got to make them myself. So, there's something to be said for turning your own missteps into guidance so that the next person coming up has an easier time than you did. And that is a theme that, from what I have seen, runs through basically everything that you do.swyx: I tried to do a lot of research, for sure. And so, one way to—you know, I—hopefully, I try not to make mistakes that others have learned, have made, so I tried to pick from, I think I include 1500 quotes and sources and blog posts and tweets to build up that level of expertise all in one place. So hopefully, it gives people something to bootstrap your experience off of. So, you're obviously going to make some mistakes on your own, but at least you have the ability to learn from others, and I think this is my—you know, I'm very proud of the work that I did. And I think people have really appreciated it.Because it's a very long book, and nobody reads books these days, so what am I doing [laugh] writing a book? I think it's only the people that really need this kind of advice, that they find themselves not having the right mentorship that reach out to me. And, you know, it's good enough to support a steady stream of sales. But more importantly, like, you know, I am able to mentor them at various levels from read my book, to read my free tweets, to read the free chapters, or join the pay community where we have weekly sessions going through every chapter and I give feedback on what people are doing. Sometimes I've helped people negotiate their jobs and get that bump up to senior staff—senior engineer, and I think more than doubled their salary, which was very personal proud moment for me.But yeah, anyway, I think basically, it's kind of like a third place between the family and work that you could go to the talk about career stuff. And I feel like, you know, maybe people are not that open on Twitter, but maybe they can be open in a small community like ours.Corey: There's a lot to be said for a sense of professional safety and personal safety around being—having those communities. I mean, mine, when I was coming up was the freenode IRC network. And that was great; it's pseudo-anonymous, but again, I was Corey and network staff at the time, which was odd, but it was great to be able to reach out and figure out am I thinking about this the wrong way, just getting guidance. And sure, there are some channels that basically thrived on insulting people. I admittedly was really into that back in the early-two-thousand-nothings.And, like, it was always fun to go to the Debian channel. It's like, “Yeah, can you explain to me how to do this or should I just go screw myself in advance?” Yeah, it's always the second one. Like, community is a hard thing to get right and it took me a while to realize this isn't the energy I want in the world. I like being able to help people come up and learn different things.I'm curious, given your focus on learning in public and effectively teaching folks as well as becoming a better engineer yourself along the way, you've been focusing for a while now on management. Tell me more about that.swyx: I wouldn't say it's been, actually, a while. Started dabbling in it with the Temporal job, and then now fully in it with Airbyte.Corey: You have to know, it has been pandemic time; it has stood still. Anything is—swyx: exactly.Corey: —a while it given that these are the interminable—this is the decade of Zoom meetings.swyx: [laugh]. I'll say I have about a year-and-a-half of it. And I'm interested in it partially because I've really been enjoying the mentoring side with the coding career community. And also, I think, some of the more effective parts of what I do have to be achieved in the planning stages with getting the right resources rather than doing the individual contributor work. And so, I'm interested in that.I'm very wary of the fact that I don't love meetings myself. Meetings are a means to an end for me and meetings are most of the job in management time. So, I think for what's important to me there, it is that we get stuff done. And we do whatever it takes to own the outcomes that we want to achieve and try to manage people's—try to not screw up people's careers along the way. [laugh]. Better put, I want people to be proud of what they get done with me by the time they're done with me. [laugh].Corey: So, I know you've talked to me about this very briefly, but I don't know that as of the time of this recording, you've made any significant public statements about it. You are now over at Airbytes, which I confess is a company I had not heard of before. What do y'all do over there?swyx: [laugh]. “What is it we do here?” So Airbyte—Corey: Exactly. Consultants want to know.swyx: Airbyte's a data integration company, which means different things based on your background. So, a lot of the data engineering patterns in, sort of, the modern data stack is extracting from multiple sources and loading everything into a data warehouse like a Snowflake or a Redshift, and then performing analysis with tools like dbt or business intelligence tools out there. We like to use MetaBase, but there's a whole there's a whole bunch of these stacks and they're all sort of advancing at different rates of progress. And what Airbyte would really like to own is the data integration part, the part where you load a bunch of sources, every data source in the world.What really drew me to this was two things. One, I really liked the vision of data freedom, which is, you have—you know, as—when you run a company, like, a typical company, I think at Temporal, we had, like, 100, different, like, you know, small little SaaS vendors, all of them vying to be the sources of truth for their thing, or a system of record for the thing. Like, you know, Salesforce wants to be a source of truth for customers, and Google Analytics want to be source of truth for website traffic, and so on and so forth. Like, and it's really hard to do analysis across all of them unless you dump all of them in one place.So one, is the mission of data freedom really resonates with me. Like, your data should be put in put somewhere where you can actually make something out of it, and step one is getting it into a format in a place that is amenable for analysis. And data warehouse pattern has really taken hold of the data engineering discipline. And I find, I think that's a multi-decade trend that I can really get behind. That's the first thing.Corey: I will say that historically, I'm bad at data. All jokes about using DNS as a database aside, one of the reasons behind that is when you work on stateless things like web servers and you blow trunks and one of them, oops. We all laugh, we take an outage, so maybe we're not laughing that hard, but we can reprovision web servers and things are mostly fine. With data and that going away, there are serious problems that could theoretically pose existential risk to the business. Now, I was a sysadmin and a, at least mediocre one, which means that after the first time I lost data, I was diligent about doing backups.Even now, the data work that we do have deep analysis on our customers' AWS bills, which doesn't sound like a big data problem, but I assure you it is, becomes something where, “Okay, step one. We don't operate on it in place.” We copy it into our own secured environment and then we begin the manipulations. We also have backups installed on these things so that in the event that I accidentally the data, it doesn't wind up causing horrifying problems for our customers. And lastly, I wind up also—this is going to surprise people—I might have securing the access to that data by not permitting writes.Turns out it's really hard—though apparently not impossible—to delete data with read-only calls.swyx: [crosstalk 00:28:12].Corey: It tends to be something of just building guardrails against myself. But the data structures, the understanding the analysis of certain things, I would have gotten into Go way sooner than I did if the introduction to Go tutorial on how to use it wasn't just a bunch of math problems talking about this is how you do it. And great, but here in the year of our lord 2022, I mostly want a programming language to smack a couple of JSON objects together and ideally come out with something resembling an answer. I'm not doing a whole lot of, you know, calculating prime numbers in the course of my week. And that is something that took a while for me to realize that, no, no, it's just another example of not being a great way of explaining something that otherwise could be incredibly accessible to folks who have real problems like this.I think the entire field right now of machine learning and the big data side of the universe struggles with this. It's, “Oh, yeah. If you have all your data, that's going to absolutely change the world for you.” “Cool. Can you explain how?” “No. Not effectively anyway.” Like, “Well, thanks for wasting everyone's time. It's appreciated.”swyx: Yeah, startup is sitting on a mountain of data that they don't use and I think everyone kind of feels guilty about it because everyone who is, like, a speaker, they're always talking about, like, “Oh, we used our data to inform this presidential campaign and look at how amazing we are.” And then you listen to the podcasts where the data scientists, you know, talk amongst themselves and they're like, “Yeah, it's bullshit.” Like, [laugh], “We're making it up as we go along, just like everyone else.” But, you know, I definitely think, like, some of the better engineering practices are arising under this. And it's professionalizing just like front-end professionalized maybe ten years ago, DevOps professionalized also, roughly in that timeframe, I think data is emerging as a field that is just a standalone discipline with its own tooling and potentially a lot of money running through it, especially if you look at the Snowflake ecosystem.So, that's why I'm interested in it. You know, I will say there's also—I talked to you about the sort of API replication use case, but also there's database replication, which is kind of like the big use case, which, for example, if you have a transactional sort of SQL database and you want to replicate that to an analytical database for queries, that's a very common one. So, I think basically data mobility from place to place, reshaping it and transferring it in as flexible manner as possible, I think, is the mission, and I think there's a lot of tooling that starts from there and builds up with it. So, Airbyte integrates pretty well with Airflow, Dexter, and all the other orchestration tools, and then, you know, you can use dbt, and everything else in that data stack to run with it. So, I just really liked that composition of tools because basically when I was a hedge fund analyst, we were doing the ETL job without knowing the name for it or having any tooling for it.I just ran a Python script manually on a cron job and whenever it failed, I would have to get up in the middle of night to go kick it again. It's, [laugh] it was that bad in 2014, '15. So, I really feel the pain. And, you know, the more data that we have to play around with, the more analysis we can do.Corey: I'm looking forward to seeing what becomes of this field as folks like you get further and further into it. And by, “Well, what do you mean, folks like me?” Well, I'm glad you asked, or we're about to as I put words in your mouth. I will tell you. People who have a demonstrated ability not just to understand the technology—which is hard—but then have this almost unicorn gift of being able to articulate and explain it to folks who do not have that level of technical depth in a way that is both accessible and inviting. And that is no small thing.If you were to ask me to draw a big circle around all the stuff that you've done in your career and define it, that's how I would do it. You are a storyteller who is conversant with the relevant elements of the story in a first-person perspective. Which is probably a really wordy way to put it. We should get a storyteller to workshop that, but you see the point.swyx: I try to call it, like, accessibly smart. So, it's a balance that you want to make, where you don't want to talk down to your audience because I think there are a lot of educators out there who very much stay at the basics and never leave that. You want to be slightly aspirational and slightly—like, push people to the bounds of their knowledge, but then not to go too far and be inaccessible. And that's my sort of polite way of saying that I dumb things down as service. [laugh].Corey: But I like that approach. The term dumbing it down is never a phrase to use, as it turns out, when you're explaining it to someone. It's like, “Let me dumb that down for you.” It's like, yeah, I always find the best way to teach someone is to first reach them and get their attention. I use humor, but instead we're going to just insult them. That'll get their attention all right.swyx: No. Yeah. It does offend some people who insist on precision and jargon. And I'm quite against that, but it's a constant fight because obviously there is a place at time for jargon.Corey: “Can you explain it to me using completely different words?” If the answer is, “No,” the question then is, “Do you actually understand it or are you just repeating it by rote?”swyx: right.Corey: There's—people learn in different ways and reaching them is important. [sigh].swyx: Exactly.Corey: Yeah. I really want to thank you for being so generous with your time. If people want to learn more about all the various things you're up to, where's the best place to find you?swyx: Sure, they can find me at my website swyx.io, or I'm mostly on Twitter at @swyx.Corey: And we will include links to both of those in the [show notes 00:33:37]. Thank you so much for your time. I really appreciate it.swyx: Thanks so much for having me, Corey. It was a blast.

Learning in Public with swyx

Screaming in the Cloud

Play Episode Listen Later Jun 9, 2022 34:55

About swyxswyx has worked on React and serverless JavaScript at Two Sigma, Netlify and AWS, and now serves as Head of Developer Experience at Airbyte. He has started and run communities for hundreds of thousands of developers, like Svelte Society, /r/reactjs, and the React TypeScript Cheatsheet. His nontechnical writing was recently published in the Coding Career Handbook for Junior to Senior developers.Links Referenced: “Learning Gears” blog post: https://www.swyx.io/learning-gears The Coding Career Handbook: https://learninpublic.org Personal Website: https://swyx.io Twitter: https://twitter.com/swyx TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Some folks are really easy to introduce when I have them on the show because, “My name is, insert name here. I built thing X, and my job is Y at company Z.” Then we have people like today's guest.swyx is currently—and recently—the head of developer experience at Airbyte, but he's also been so much more than that in so many different capacities that you're very difficult to describe. First off, thank you for joining me. And secondly, what's the deal with you?swyx: [laugh]. I have professional ADD, just like you. Thanks for having me, Corey. I'm a—Corey: It works out.swyx: a big fan. Longtime listener, first time caller. Love saying that. [laugh].Corey: You have done a lot of stuff. You have a business and finance background, which… okay, guilty; it's probably why I feel some sense of affinity for a lot of your work. And then you went into some interesting directions. You were working on React and serverless YahvehScript—which is, of course, how I insist on pronouncing it—at Two Sigma, Netlify, AWS—a subject near and dear to my heart—and most recently temporal.io.And now you're at Airbyte. So, you've been focusing on a lot of, I won't say the same things, but your area of emphasis has definitely consistently rhymed with itself. What is it that drives you?swyx: So, I have been recently asking myself a lot of this question because I had to interview to get my new role. And when you have multiple offers—because the job market is very hot for DevRel managers—you have to really think about it. And so, what I like to say is: number one, working with great people; number two, working on great products; number three, making a lot of money.Corey: There's entire school of thought that, “Oh, that's gauche. You shouldn't mention trying to make money.” Like, “Why do you want to work here because I want to make money.” It's always true—swyx: [crosstalk 00:03:46]—Corey: —and for some reason, we're supposed to pretend otherwise. I have a lot of respect for people who can cut to the chase on that. It's always been something that has driven me nuts about the advice that we give a new folks to the industry and peop—and even students figuring out their career path of, “Oh, do something you love and the money will follow.” Well, that's not necessarily true. There are ways to pivot something you'd love into something lucrative and there are ways to wind up more or less borderline starving to death. And again, I'm not saying money is everything, but for a number of us, it's hard to get to where we want to be without it.swyx: Yeah, yeah. I think I've been cast with the kind of judgmental label of being very financially motivated—that's what people have called me—for simply talking about it. And I'm like, “No. You know, it's number three on my priority list.” Like, I will leave positions where I have a lot of money on the table because I don't enjoy the people or the products, but having it up there and talking openly about it somehow makes you [laugh] makes you sort of greedy or something. And I don't think that's right. I tried to set an example for the people that I talk to or people who follow me.Corey: One of the things I've always appreciated about, I guess, your online presence, which has remained remarkably consistent as you've been working through a bunch of different, I guess, stages of life and your career, is you have always talked in significant depth about an area of tech that I am relatively… well, relatively crap at, let's be perfectly honest. And that is the wide world of most things front-end. Every time I see a take about someone saying, “Oh, front-end is junior or front-end is somehow less than,” I'd like to know what the hell it is they know because every time I try and work with it, I wind up more confused than I was when I started. And what I really appreciate is that you have always normalized the fact that this stuff is hard. As of the time that we're recording this a day or so ago, you had a fantastic tweet thread about a friend of yours spun up a Create React App and imported the library to fetch from an endpoint and immediately got stuck. And then you pasted this ridiculous error message.He's a senior staff engineer, ex-Google, ex-Twitter; he can solve complex distributed systems problems and unable to fetch from a REST endpoint without JavaScript specialist help. And I talk about this a lot in other contexts, where the reason I care so much about developer experience is that a bad developer experience does not lead people to the conclusion of, “Oh, this is a bad interface.” It leads people to the conclusion, “Oh, I'm bad at this and I didn't realize it.” No. I still fall into that trap myself.I was under the impression that there was just this magic stuff that JS people know. And your tweet did so much to help normalize from my perspective, the fact that no, no, this is very challenging. I recently went on a Go exploration. Now, I'm starting to get into JavaScript slash TypeScript, which I think are the same thing but I'm not entirely certain of that. Like, oh, well, one of them is statically typed, or strongly typed. It's like, “Well, I have a loud mechanical keyboard. Everything I do is typing strongly, so what's your point?”And even then we're talking past each other in these things. I don't understand a lot of the ecosystem that you live your career in, but I have always had a tremendous and abiding respect for your ability to make it accessible, understandable, and I guess for lack of a better term, to send the elevator back down.swyx: Oh, I definitely think about that strongly, especially that last bit. I think it's a form of personal growth. So, I think a lot of people, when they talk about this sending the elevator back down, they do it as a form of charity, like I'm giving back to the community. But honestly, you actually learn a lot by trying to explain it to others because that's the only way that you truly know if you've learned something. And if you ever get anything wrong, you'll—people will never let you forget it because it is the internet and people will crawl over broken glass to remind you that you're wrong.And once you've got it wrong, you will—you know, you've been so embarrassed that you'll never forget it. So, I think it's just a really good way to learn in public. And that's kind of the motto that I'm kind of known for. Yeah, we can take the direction anywhere you want to go in JavaScript land. Happy to talk about it all day. [laugh].Corey: Well, I want to start by something you just said where you're doing the learning in public thing. And something I've noticed is that there are really two positions you can take—in the general sense—when you set out to make a bit of a reputation for yourself in a particular technical space. You can either do the, “I'm a beginner here, same as the rest of you, and I'm learning in public,” or you can position yourself as something of an expert. And there are drawbacks and advantages to both. I think that if you don't look as wildly over-represented as I do, both of them are more fraught in different ways, where it's, “Oh, you're learning in public. Ah, look at the new person, she's dumb.”Or if you're presenting yourself as an expert, you get nibbled to death by ducks on a lot of the deep technical nuances and well, actually'ed to death. And my position has always been and this is going to be a radical concept for some folks, is that I'm genuinely honest. I tend to learn in public about the things that I don't know, but the things that I am something of a subject matter expert in—like, I don't know, cloud billing—I don't think that false modesty necessarily serves me particularly well. It's yeah, I know exactly what I'm talking about here. Pretending otherwise it's just being disingenuous.swyx: I try to think of it as having different gears of learning in public. So, I've called this “Learning Gears” in a previous blog post of mine, where you try to fit your mode of learning to the terrain that you're on, your domain expertise, and you should never over-represent the amount that you know because I think people are very rightly upset when there are a lot of people—let's say on Twitter, or YouTube, or Udemy even—who present themselves as experts who are actually—they just read the docs the previous night. So, you should try not to over-represent your expertise.But at the same time, don't let your imposter syndrome stop you from sharing what you are currently learning and taking corrections when you're wrong. And I think that's the tricky balance to get which is constantly trying to put yourself out there while accepting that you might be wrong and not getting offended when or personally attacked when someone corrects you, inevitably. And sometimes people will—especially if you have a lot of followers, people will try to say—you know, someone of your following—you know, it's—I kind of call this follower shaming, like, you should act, uh—invulnerable, or run every tweet through committee before you tweet after a certain sort of following size. So, I try to not do that and try to balance responsibility with authenticity.Corey: I think that there's something incredibly important about that, where there's this idea that you either become invulnerable and get defensive and you yell at people, and down that path lies disaster because, believe it or not, we all get it wrong from time to time, and doubling down and doubling down and doubling down again, suddenly, you're on an island all by yourself and no one respectable is going to be able to get there to help you. And the other side of it is going too far in the other direction, where you implicitly take any form of criticism whatsoever as being de facto correct. And I think that both paths don't lead to super great places. I think it's a matter of finding our own voices and doing a little bit of work as far as the validity of accepting a given piece of feedback goes. But other than that, I'm a big fan of being able to just more or less be as authentic as possible.And I get that I live in a very privileged position where I have paths open to me that are not open to most folks. But in many respects so to you are one of the—easily—first five people I would think of if someone said, “Hey if I need to learn JavaScript for someone, who should I talk to first?” You're on that list. And you've done a lot of things in this area, but you've never—you alluded to it a few minutes ago, but I'm going to call it out a little more pointedly—without naming names, let's be clear—and that you're never presented as a grifter, which is sort of the best way I can think of it of, “Well, I just learned this new technology stack yesterday and now I'm writing a book that I'm going to sell to people on how to be an expert at this thing.” And I want to be clear, this is very distinct from gatekeeping because I think that, “Oh, well, you have to be at least this much of an expert—” No, but I think that holding yourself out as I'm going to write a book on how to be proud of how to become a software engineer.Okay, you were a software engineer for six months, and more to the point, knowing how to do a thing and knowing how to teach a thing are orthogonal skill sets, and I think that is not well understood. If I ever write a book or put something—or some sort of info product out there, I'm going to have to be very careful not to fall into that trap because I don't want to pretend to be an expert in things that I'm not. I barely think I'm an expert in things that I provable am.swyx: there are many ways to answer that. So, I have been accused a couple of times of that. And it's never fun, but also, if you defend yourself well, you can actually turn a critic into a fan, which I love doing.Corey: Mm-hm.swyx: [laugh].Corey: Oh yes.swyx: what I fall back to, so I have a side interest in philosophy, based on one of my high school teachers giving us, like, a lecture in philosophy. I love him, he changed my life. [Lino Barnard 00:13:20], in case—in the off chance that he's listening. So, there's a theory of knowledge of, like, how do you know what you know, right? And if you can base your knowledge on truth—facts and not opinions, then people are arguing with the facts and not the opinions.And so, getting as close to ground truth as possible and having certainty in your collection of facts, I think is the basis of not arguing based on identity of, like, “Okay, I have ten years experience; you have two years experience. I am more correct than you in every single opinion.” That's also not, like, the best way to engage in the battlefield of ideas. It's more about, do you have the right amount of evidence to support the conclusions that you're trying to make? And oftentimes, I think, you know, that is the basis, if you don't have that ability.Another thing that I've also done is to collect the opinions of others who have more expertise and present them and curate them in a way that I think adds value without taking away from the individual original sources. So, I think there's a very academic way [laugh] you can kind of approach this, but that defends your intellectual integrity while helping you learn faster than the typical learning rate. Which is kind of something I do think about a lot, which is, you know, why do we judge people by the number of years experience? It's because that's usually the only metric that we have available that is quantifiable. Everything else is kind of fuzzy.But I definitely think that, you know, better algorithms for learning let you progress much faster than the median rate, and I think people who apply themselves can really get up there in terms of the speed of learning with that. So, I spend a lot of time thinking about this stuff. [laugh].Corey: It's a hard thing to solve for. There's no way around it. It's, what is it that people should be focusing on? How should they be internalizing these things? I think a lot of it starts to with an awareness, even if not in public, just to yourself of, “I would like advice on some random topic.” Do you really? Are you actually looking for advice or are you looking—swyx: right.Corey: For validation? Because those are not the same thing, and you are likely to respond very differently when you receive advice, depending on which side of that you're coming from.swyx: Yeah. And so, one way to do that is to lay out both sides, to actually demonstrate what you're split on, and ask for feedback on specific tiebreakers that would help your decision swing one way or another. Yeah, I mean, there are definitely people who ask questions that are just engagement bait or just looking for validation. And while you can't really fix that, I think it's futile to try to change others' behavior online. You just have to be the best version of yourself you can be. [laugh].Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: So, you wrote a book that is available at learninpublic.org, called The Coding Career Handbook. And to be clear, I have not read this myself because at this point, if I start reading a book like that, and you know, the employees that I have see me reading a book like that, they're going to have some serious questions about where this company is going to be going soon. But scrolling through the site and the social proof, the testimonials from various people who have read it, more or less read like a who's-who of people that I respect, who have been on this show themselves.Emma Bostian is fantastic at explaining a lot of these things. Forrest Brazeal is consistently a source to me of professional envy. I wish I had half his musical talent; my God. And your going down—it explains, more or less, the things that a lot of folks people are all expected to know but no one teaches them about every career stage, ranging from newcomer to the industry to senior. And there's a lot that—there's a lot of gatekeeping around this and I don't even know that it's intentional, but it has to do with the idea that people assume that folks, quote-unquote, “Just know” the answer to some things.Oh, people should just know how to handle a technical interview, despite the fact that the skill set is completely orthogonal to the day-to-day work you'll be doing. People should just know how to handle a performance review, or should just know how to negotiate for a raise, or should just know how to figure out is this technology that I'm working on no longer the direction the industry is going in, and eventually I'm going to wind up, more or less, waiting for the phone to ring because there's only three companies in the world left who use it. Like, how do you keep—how do you pay attention to what's going on around you? And it's the missing manual that I really wish that people would have pointed out to me back when I was getting started. Would have made life a lot easier.swyx: Oh, wow. That's high praise. I actually didn't know we're going to be talking about the book that much. What I will say is—Corey: That's the problem with doing too much. You never know what people have found out about you and what they're going to say when they drag you on to a podcast.swyx: got you, got you. Okay. I know, I know, I know where this is going. Okay. So, one thing that I really definitely believe is that—and this happened to me in my first job as well, which is most people get the mentors that they're assigned at work, and sometimes you have a bad roll the dice. [laugh].And you're supposed to pick up all the stuff they don't teach you in school at work or among your friend group, and sometimes you just don't have the right network at work or among your friend group to tell you the right things to help you progress your career. And I think a lot of this advice is written down in maybe some Hacker News posts, some Reddit posts, some Twitter posts, and there's not really a place you to send people to point to, that consolidates that advice, particularly focused at the junior to senior stage, which is the stage that I went through before writing the book. And so, I think that basically what I was going for is targeting the biggest gap that I saw, which is, there a lot of interview prep type books like Crack the Coding Career, which is kind of—Crack the Coding Interview, which is kind of the book title that I was going after. But once you got the job, no one really tells you what to do after you got that first job. And how do you level up to the senior that everyone wants to hire, right? There's—Corey: “Well, I've mastered cracking the coding interview. Now, I'm really trying to wrap my head around the problem of cracking the showing up at work on time in the morning.” Like, the baseline stuff. And I had so many challenges with that early in my career. Not specifically punctuality, but just the baseline expectation that it's just assumed that by the time you're in the workplace earning a certain amount of money, it's just assumed that you have—because in any other field, you would—you have several years of experience in the workplace and know how these things should play out.No, the reason that I'm sometimes considered useful as far as giving great advice on career advancement and the rest is not because I'm some wizard from the future, it's because I screwed it all up myself and got censured and fired and rejected for all of it. And it's, yeah, I'm not smart enough to learn from other people's mistakes; I got to make them myself. So, there's something to be said for turning your own missteps into guidance so that the next person coming up has an easier time than you did. And that is a theme that, from what I have seen, runs through basically everything that you do.swyx: I tried to do a lot of research, for sure. And so, one way to—you know, I—hopefully, I try not to make mistakes that others have learned, have made, so I tried to pick from, I think I include 1500 quotes and sources and blog posts and tweets to build up that level of expertise all in one place. So hopefully, it gives people something to bootstrap your experience off of. So, you're obviously going to make some mistakes on your own, but at least you have the ability to learn from others, and I think this is my—you know, I'm very proud of the work that I did. And I think people have really appreciated it.Because it's a very long book, and nobody reads books these days, so what am I doing [laugh] writing a book? I think it's only the people that really need this kind of advice, that they find themselves not having the right mentorship that reach out to me. And, you know, it's good enough to support a steady stream of sales. But more importantly, like, you know, I am able to mentor them at various levels from read my book, to read my free tweets, to read the free chapters, or join the pay community where we have weekly sessions going through every chapter and I give feedback on what people are doing. Sometimes I've helped people negotiate their jobs and get that bump up to senior staff—senior engineer, and I think more than doubled their salary, which was very personal proud moment for me.But yeah, anyway, I think basically, it's kind of like a third place between the family and work that you could go to the talk about career stuff. And I feel like, you know, maybe people are not that open on Twitter, but maybe they can be open in a small community like ours.Corey: There's a lot to be said for a sense of professional safety and personal safety around being—having those communities. I mean, mine, when I was coming up was the freenode IRC network. And that was great; it's pseudo-anonymous, but again, I was Corey and network staff at the time, which was odd, but it was great to be able to reach out and figure out am I thinking about this the wrong way, just getting guidance. And sure, there are some channels that basically thrived on insulting people. I admittedly was really into that back in the early-two-thousand-nothings.And, like, it was always fun to go to the Debian channel. It's like, “Yeah, can you explain to me how to do this or should I just go screw myself in advance?” Yeah, it's always the second one. Like, community is a hard thing to get right and it took me a while to realize this isn't the energy I want in the world. I like being able to help people come up and learn different things.I'm curious, given your focus on learning in public and effectively teaching folks as well as becoming a better engineer yourself along the way, you've been focusing for a while now on management. Tell me more about that.swyx: I wouldn't say it's been, actually, a while. Started dabbling in it with the Temporal job, and then now fully in it with Airbyte.Corey: You have to know, it has been pandemic time; it has stood still. Anything is—swyx: exactly.Corey: —a while it given that these are the interminable—this is the decade of Zoom meetings.swyx: [laugh]. I'll say I have about a year-and-a-half of it. And I'm interested in it partially because I've really been enjoying the mentoring side with the coding career community. And also, I think, some of the more effective parts of what I do have to be achieved in the planning stages with getting the right resources rather than doing the individual contributor work. And so, I'm interested in that.I'm very wary of the fact that I don't love meetings myself. Meetings are a means to an end for me and meetings are most of the job in management time. So, I think for what's important to me there, it is that we get stuff done. And we do whatever it takes to own the outcomes that we want to achieve and try to manage people's—try to not screw up people's careers along the way. [laugh]. Better put, I want people to be proud of what they get done with me by the time they're done with me. [laugh].Corey: So, I know you've talked to me about this very briefly, but I don't know that as of the time of this recording, you've made any significant public statements about it. You are now over at Airbytes, which I confess is a company I had not heard of before. What do y'all do over there?swyx: [laugh]. “What is it we do here?” So Airbyte—Corey: Exactly. Consultants want to know.swyx: Airbyte's a data integration company, which means different things based on your background. So, a lot of the data engineering patterns in, sort of, the modern data stack is extracting from multiple sources and loading everything into a data warehouse like a Snowflake or a Redshift, and then performing analysis with tools like dbt or business intelligence tools out there. We like to use MetaBase, but there's a whole there's a whole bunch of these stacks and they're all sort of advancing at different rates of progress. And what Airbyte would really like to own is the data integration part, the part where you load a bunch of sources, every data source in the world.What really drew me to this was two things. One, I really liked the vision of data freedom, which is, you have—you know, as—when you run a company, like, a typical company, I think at Temporal, we had, like, 100, different, like, you know, small little SaaS vendors, all of them vying to be the sources of truth for their thing, or a system of record for the thing. Like, you know, Salesforce wants to be a source of truth for customers, and Google Analytics want to be source of truth for website traffic, and so on and so forth. Like, and it's really hard to do analysis across all of them unless you dump all of them in one place.So one, is the mission of data freedom really resonates with me. Like, your data should be put in put somewhere where you can actually make something out of it, and step one is getting it into a format in a place that is amenable for analysis. And data warehouse pattern has really taken hold of the data engineering discipline. And I find, I think that's a multi-decade trend that I can really get behind. That's the first thing.Corey: I will say that historically, I'm bad at data. All jokes about using DNS as a database aside, one of the reasons behind that is when you work on stateless things like web servers and you blow trunks and one of them, oops. We all laugh, we take an outage, so maybe we're not laughing that hard, but we can reprovision web servers and things are mostly fine. With data and that going away, there are serious problems that could theoretically pose existential risk to the business. Now, I was a sysadmin and a, at least mediocre one, which means that after the first time I lost data, I was diligent about doing backups.Even now, the data work that we do have deep analysis on our customers' AWS bills, which doesn't sound like a big data problem, but I assure you it is, becomes something where, “Okay, step one. We don't operate on it in place.” We copy it into our own secured environment and then we begin the manipulations. We also have backups installed on these things so that in the event that I accidentally the data, it doesn't wind up causing horrifying problems for our customers. And lastly, I wind up also—this is going to surprise people—I might have securing the access to that data by not permitting writes.Turns out it's really hard—though apparently not impossible—to delete data with read-only calls.swyx: [crosstalk 00:28:12].Corey: It tends to be something of just building guardrails against myself. But the data structures, the understanding the analysis of certain things, I would have gotten into Go way sooner than I did if the introduction to Go tutorial on how to use it wasn't just a bunch of math problems talking about this is how you do it. And great, but here in the year of our lord 2022, I mostly want a programming language to smack a couple of JSON objects together and ideally come out with something resembling an answer. I'm not doing a whole lot of, you know, calculating prime numbers in the course of my week. And that is something that took a while for me to realize that, no, no, it's just another example of not being a great way of explaining something that otherwise could be incredibly accessible to folks who have real problems like this.I think the entire field right now of machine learning and the big data side of the universe struggles with this. It's, “Oh, yeah. If you have all your data, that's going to absolutely change the world for you.” “Cool. Can you explain how?” “No. Not effectively anyway.” Like, “Well, thanks for wasting everyone's time. It's appreciated.”swyx: Yeah, startup is sitting on a mountain of data that they don't use and I think everyone kind of feels guilty about it because everyone who is, like, a speaker, they're always talking about, like, “Oh, we used our data to inform this presidential campaign and look at how amazing we are.” And then you listen to the podcasts where the data scientists, you know, talk amongst themselves and they're like, “Yeah, it's bullshit.” Like, [laugh], “We're making it up as we go along, just like everyone else.” But, you know, I definitely think, like, some of the better engineering practices are arising under this. And it's professionalizing just like front-end professionalized maybe ten years ago, DevOps professionalized also, roughly in that timeframe, I think data is emerging as a field that is just a standalone discipline with its own tooling and potentially a lot of money running through it, especially if you look at the Snowflake ecosystem.So, that's why I'm interested in it. You know, I will say there's also—I talked to you about the sort of API replication use case, but also there's database replication, which is kind of like the big use case, which, for example, if you have a transactional sort of SQL database and you want to replicate that to an analytical database for queries, that's a very common one. So, I think basically data mobility from place to place, reshaping it and transferring it in as flexible manner as possible, I think, is the mission, and I think there's a lot of tooling that starts from there and builds up with it. So, Airbyte integrates pretty well with Airflow, Dexter, and all the other orchestration tools, and then, you know, you can use dbt, and everything else in that data stack to run with it. So, I just really liked that composition of tools because basically when I was a hedge fund analyst, we were doing the ETL job without knowing the name for it or having any tooling for it.I just ran a Python script manually on a cron job and whenever it failed, I would have to get up in the middle of night to go kick it again. It's, [laugh] it was that bad in 2014, '15. So, I really feel the pain. And, you know, the more data that we have to play around with, the more analysis we can do.Corey: I'm looking forward to seeing what becomes of this field as folks like you get further and further into it. And by, “Well, what do you mean, folks like me?” Well, I'm glad you asked, or we're about to as I put words in your mouth. I will tell you. People who have a demonstrated ability not just to understand the technology—which is hard—but then have this almost unicorn gift of being able to articulate and explain it to folks who do not have that level of technical depth in a way that is both accessible and inviting. And that is no small thing.If you were to ask me to draw a big circle around all the stuff that you've done in your career and define it, that's how I would do it. You are a storyteller who is conversant with the relevant elements of the story in a first-person perspective. Which is probably a really wordy way to put it. We should get a storyteller to workshop that, but you see the point.swyx: I try to call it, like, accessibly smart. So, it's a balance that you want to make, where you don't want to talk down to your audience because I think there are a lot of educators out there who very much stay at the basics and never leave that. You want to be slightly aspirational and slightly—like, push people to the bounds of their knowledge, but then not to go too far and be inaccessible. And that's my sort of polite way of saying that I dumb things down as service. [laugh].Corey: But I like that approach. The term dumbing it down is never a phrase to use, as it turns out, when you're explaining it to someone. It's like, “Let me dumb that down for you.” It's like, yeah, I always find the best way to teach someone is to first reach them and get their attention. I use humor, but instead we're going to just insult them. That'll get their attention all right.swyx: No. Yeah. It does offend some people who insist on precision and jargon. And I'm quite against that, but it's a constant fight because obviously there is a place at time for jargon.Corey: “Can you explain it to me using completely different words?” If the answer is, “No,” the question then is, “Do you actually understand it or are you just repeating it by rote?”swyx: right.Corey: There's—people learn in different ways and reaching them is important. [sigh].swyx: Exactly.Corey: Yeah. I really want to thank you for being so generous with your time. If people want to learn more about all the various things you're up to, where's the best place to find you?swyx: Sure, they can find me at my website swyx.io, or I'm mostly on Twitter at @swyx.Corey: And we will include links to both of those in the [show notes 00:33:37]. Thank you so much for your time. I really appreciate it.swyx: Thanks so much for having me, Corey. It was a blast.Corey: swyx, head of developer experience at Airbyte, and oh, so much more. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice or if it's on the YouTubes thumbs up and subscribe, whereas if you've hated this podcast, same thing, five-star review wherever you want, hit the buttons on the YouTubes, but also leaving insulting comment that is hawking your book: Why this Episode was Terrible that you're now selling as a legitimate subject matter expert in this space.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

god love amazon head learning google zoom public started reddit cloud consultants senior terrible oracle crack saas meetings longtime react slack salesforce api screaming doordash python aws snowflakes google analytics devops javascript azure temporal pretending udemy dns sql js irc json typescript etl postgresql redshift hacker news developer experience devrel debian netlify airflow corey quinn two sigma chronosphere coding interview metabase create react app duckbill group forrest brazeal enterprisedb chief cloud economist last week in aws humblepod

#285 Where we talk about UIs and Python

Python Bytes

Play Episode Listen Later May 25, 2022 50:54

Watch the live stream: Watch on YouTube About the show Sponsored: RedHat: Compiler Podcast Special guests Mark Little Ben Cosby Michael #1: libgravatar A library that provides a Python 3 interface to the Gravatar APIs. If you have users and want to show some sort of an image, Gravatar is OK PyPI uses this for example (gravatar, not necessarily this lib) Usage: >>> g = Gravatar('myemailaddress@example.com') >>> g.get_image() 'https://www.gravatar.com/avatar/0bc83cb571cd1c50ba6f3e8a78ef1346' Brian #2: JSON to Pydantic Converter Suggested by Chun Ly, “this awesome JSON to @samuel_colvin's pydantic is so useful. It literally saved me days of work with a complex nested JSON schema.“ “JSON to Pydantic is a tool that lets you convert JSON objects into Pydantic models.” It's a live site, where you can plop JSON on one the left, and Pydantic models show up on the right. There's a couple options: Specify every field as Optional Alias camelCase fields as snake_case It's also an open source project, built with FastAPI, Create React App, and a project called datamodel-code-generator. Mark #3: tailwindcss, tailwindui Not python, but helpful for web UI and open source business model example tailwindcss generates CSS Used on the Lexchart app Benefits of tailwindcss and tailwindui: Just-in-Time makes it fast. Output includes only classes used for the project. Stand on shoulders of design thinking from Steve Schoger and Adam Wathan. See also refactoingui.com. Use in current projects without CSS conflicts. Custom namespace with prefix in tailwind.config.js. Bonus: custom namespace prefixes work with the tailwind plug-ins for VS Code and PyCharm. Works well with template engines like, Chameleon. We use tailwind for our app UI. Toolbar template example. Another example of docs and tutorials being a strategic business asset. Resources tailwindcss.com tailwindlabs on YouTube, great tutorials from Simon at Tailwind Beginner friendly tutorials: Thirus, example of tailwind install methods Michael #4: PEP 690 – Lazy Imports From Itamar Discussion at https://discuss.python.org/t/pep-690-lazy-imports/15474 PEP proposes a feature to transparently defer the execution of imported modules until the moment when an imported object is used. PEP 8 says imports go a the top, that means you pay the full price of importing code This means that importing the main module of a program typically results in an immediate cascade of imports of most or all of the modules that may ever be needed by the program. Lazy imports also mostly eliminate the risk of import cycles or crashes. The implementation in this PEP has already demonstrated startup time improvements up to 70% and memory-use reductions up to 40% on real-world Python CLIs. Brian #5: Two small items pytest-rich Suggested by Brian Skinn Created by Bruno Oliveira as a proof of concept pytest + rich, what's not to love? Now we just need a maintainer or two or three…. Embedding images in GitHub README Suggested by Henrik Finsberg Video by Anthony Sottile This is WITHOUT putting the image in the repo. Upload or drop an image to an issue comment. Don't save the comment, just wait for GitHub to upload it to their CDN. GH will add a markdown link in the comment text box with a link to the now uploaded image. Now you can use that image in a README file. You can do the same while editing the README in the online editor. Ben #6: pyotp A library for generating and verifying one-time passwords (OTP). Helpful for implementing multi-factor authentication (MFA) in web applications. Supports HMAC-based one-time passwords (HOTP) and time-based one-time passwords (TOTP). While HOTP delivered via SMS text messages is a common approach to implementing MFA, SMS is not really secure. TOTP using an authenticator app on the user's device such as Google Authenticator or Microsoft Authenticator is more secure, fairly easy to implement, and free (no SMS messaging fees and multiple free authenticator apps available for users). TOTP works best by making a QR code available to simplify the setup for the user in their authenticator app. Lots of easy to implement QR code generators to choose from (qrcode is a popular one if you use javascript on the front end). TOTP quick reference: import pyotp def generate_shared_secret(): # securely store this shared secret with user account data return pyotp.random_base32() def generate_provisioning_uri(secret, email): # generate uri for a QR code from the user's shared secret and email address return pyotp.totp.TOTP(secret).provisioning_uri(name=email, issuer_name='YourApp') def verify_otp(secret, otp): # verify user's one-time password entry with their shared secret totp = pyotp.TOTP(secret) return totp.verify(otp) Extras Brian: PyConUS 2022 videos now up A few more Python related extensions for VSCode black, pylint, isort, and Jupyter PowerToys Work has begun on a pytest course Saying this in public to inspire me to finish it. No ETA yet Sad Python Girls Club podcast Michael: PyTorch M1 Mission Encodable PWAs and pyscript Michael's now released pyscript PWA YouTube video cal.com (open source calendly) Supabase (open source Firebase) Joke: Beginner problems

Vite, czyli szybsza alternatywa dla Webpack i Create React App

Przeprogramowany podcast

Play Episode Listen Later Mar 16, 2022 15:04

Vite to najpopularniejszy tooling frontendowy nowej generacji. Na tle konkurencji, Webpacka i Create React App, wyróżnia go niesamowita szybkość serwera deweloperskiego oraz skalowalne HMR. Vite nie wymaga dodatkowej konfiguracji, aby współpracować z React, Vue, TypeScript, Lit oraz Svelte. W najnowszym filmie zobaczysz jak działa to narzędzie, jego zalety oraz wady. Patronem dzisiejszego odcinka jest Future Processing, polska firma technologiczną zajmującą się rozwojem oprogramowania: https://kariera.future-processing.pl/ Film Przemka o Webpacku i Snowpacku: https://www.youtube.com/watch?v=96NCyI-goJY Zapisz się na cotygodniowy newsletter Technicznie-Rozwojowo-Bonus: https://przeprogramowani.pl/newsletter 00:00 - Wprowadzenie 00:19 - Vajt czy Vit? 00:54 - Szybki serwer developerski (ES Modules, esbuild) 03:04 - Skalowalny HMR 04:06 - Future Processing 05:35 - Wsparcie TS, React i pozostałe zalety 06:42 - Konkurencja (Vite vs Snowpack) 8:23 - Porównanie szybkości Vite i Create React App 10:03 - Wady Vite 12:23 - Czy Vite to Webpack killer?

react lit vit vite czyli vue typescript snowpack svelte webpack szybki hmr create react app

Migrate to Remix - Girish Venkatesan

The Remix Podcast

Play Episode Listen Later Jan 7, 2022 30:49

In this episode, Girish Venkatesan talks about how he heard of Remix and what moment captured his interest. With Remix officially released, Girish has convinced the business folks at his company that it would be worth their while to migrate their "Create React App" over to Remix for the user experience and developer experience improvements they would see. Kent and Girish discuss why Next.js wasn't enough of an improvement to justify a migration and why a migration to Remix was obvious.

web remix kent software development software engineering web development migrate girish venkatesan create react app

Когда документация — просто космос

YaTalks 2021: ReRun

Play Episode Listen Later Dec 27, 2021 54:51

Вы написали библиотеку. Но чтобы ей начали пользоваться, к ней должна прилагаться хорошая и понятная документация. Как её писать? Что делать, если нужна многоязычность? Как создать понятную навигацию по документации? Как поддерживать её в актуальном состоянии? Обсудим эти вопросы на примере React, Vue и Доки. О спикерах: Наталья Теплухина — член основной команды Vue.js и Staff Frontend Engineer в GitLab. Выступает в качестве спикера на профессиональных конференциях, является автором статей на различные темы, связанные с Vue.js. Благодаря этой деятельности Наталья получила звание Google Developer Expert в веб-технологиях. Дэн Абрамов — разработчик в Meta, работает над React. Поучаствовал в создании Redux, Create React App, JustJavaScript.com. Любит делать презентации. Алёна Батицкая восемь лет занимается фронтендом на фрилансе. Преподаёт на онлайн-курсах по разработке, а также регулярно выступает на конференциях и митапах. Пишет и переводит статьи, в том числе для официального русского блога Google. GDE по веб-технологиям.

google react redux vue gitlab google developer expert gde create react app

Episode 5: 少年，你掉的是这个空格缩进，还是这个 Tab 缩进？

Echo.js

Play Episode Listen Later Oct 15, 2021 67:46

时隔两个月的更新，我们迎来新的官网 (https://www.echojspodcast.com)、新的会员计划 (https://www.echojspodcast.com/member) 和新的话题。从这期开始，我们拥有新的固定栏目：开源项目与文章摘要（暂定）；之后我们将大家写代码时的习惯、工具等等都拿了出来，看看究竟哪种最好用。节目索引 00:00 开场 00:22 厚脸皮地来说说这两个月里的公告 03:20 新固定栏目：开源项目与文章摘要 15:53 大乱斗话题的由来 18:01 代码习惯大比拼 35:57 有 Lint，当然少不了 Linter 41:31 说脚到手架，两位 JS 程序员可就不困了 49:05 终于开始聊编辑器 01:01:16 最后来聊聊 GitHub Copilot 相关链接 06:07 - WeKan 开源看板工具 (https://wekan.github.io/) 07:42 - draw.io (https://draw.io) 08:50 - 数据绘开源绘图工具 (https://github.com/zxhm001/DataDraw) 12:25 - How to win on CORS (https://jakearchibald.com/2021/cors/)：CORS 跨域限制机制是怎么来的，到底该怎么解决？ 19:05 - 维基百科中对「制表键」的定义 (https://zh.wikipedia.org/wiki/%E8%A3%BD%E8%A1%A8%E9%8D%B5)：键盘上俗称的 Tab 键正式名称叫「制表键」（tabulator key），它可以提供最大 4 长度（有些是 8 或是其他长度）的可变长度空格，在需要跨行进行列对齐（制表等场景）时非常好用而得名。白羊说「Tab 键本身就是做这种事的」是这个原因。 25:55 - JavaScript Map, Reduce, and Filter - JS Array Functions Explained with Code Examples (https://www.freecodecamp.org/news/javascript-map-reduce-and-filter-explained-with-examples/)：JavaScript 中操作数组常用的 map、reduce 和 filter 三个函数的解释。 29:26 - PureScript (https://www.purescript.org/) 30:17 - 中文编程了解一下 (https://www.echojspodcast.com/2)：我台以「在编程中使用中文」为话题的一期节目。 36:22 - EditorConfig (https://editorconfig.org/) 41:37 - Vue CLI (https://cli.vuejs.org/) 41:50 - Create React App (https://create-react-app.dev/)：两位主播都忘记叫什么名字的 React 脚手架。 44:07 - WebPack (https://www.webpackjs.com/) 44:12 - Next.js (https://nextjs.org/)（React）和 Nuxt.js (https://nuxtjs.org/)（Vue.js） 47:16 - Parcel (https://parceljs.org/) 01:01:16 - GitHub Copilot (https://copilot.github.com/) 01:02:37 - What does Copilot Mean for Open Source (https://opensource.org/copilotimpact)：开源组织在 GitHub Copilot 推出之后针对 AI 补全代码的合法性发文。关于 Echo.js & 联系我们 Echo.js 是一档关于编程与开发的播客节目。官网地址是 www.echojspodcast.com 。我们推荐使用支持 RSS 方式订阅（即「泛用型」）的播客客户端收听。有话想说？你可以：发到官网评论区来小宇宙 app 订阅 Echo.js 并给节目发评论加入听众反馈 QQ 群 (https://www.echojspodcast.com/qq)（白羊说进群可以教学编程，包教包会）发邮件至 hello(a)astrianzheng.com 关注我们的：Telegram 频道 (https://t.me/echojspodcast)、Twitter (https://twitter.com/twitter) COPYRIGHT DISCLIMER 开场/尾声音乐： Track: TOKYO MACHINE & Guy Arthur - GET UP [NCS Release] Music provided by NoCopyrightSounds. Watch: https://youtu.be/HV7mLcsUp5U Free Download / Stream: http://ncs.io/GetUp Play the Flappy Duck game: http://ncs.io/GetUp 奏间音乐：来自北京干燥文化传媒有限公司。

ai reduce telegram echo react get up open source javascript tab js vue parcel qq github copilot cors nocopyrightsounds webpack create react app vue cli purescript

Ian Sutherland Chats About Getting Involved In Open-Source

Chats with Kent C. Dodds

Play Episode Listen Later Oct 4, 2021 31:12

"I should really get more involved in open-source" is something that's always on the back of our minds. You are fully aware of how rewarding it could be but that perfect opportunity to contribute never comes up. Ian Sutherland, a maintainer of Create React App and contributor to NodeJS, used to be in that position. He had always struggled with getting into open source, he wanted to do something substantial but nothing ever came up. One day, he noticed a tiny bug in create react app. Ian quickly fixed it and put in a PR. Once he was past the first PR barrier, making additional ones was so much easier. Fear is a big barrier to entry. People are maybe afraid they're going to do something silly, make a silly mistake and look foolish, but you really have to get over that as well. To get over it try to start small. When you start small, what was once a mountain to climb is now a hill. The stakes are much lower and success is still extremely rewarding!Sometimes, getting involved can happen organically through opportunities from people you meet. Ian got involved with Node randomly at the Vancouver Node Interactive Conference during a collaborator summit. And an open-source raid group was formed in Kent's discord where they collaborate on helping out with various open-source projects. So remember that you don't have to do it alone, and look out for opportunities with others.HomeworkNext time you are hesitant to try something new, try starting smaller!ResourcesHow to get experience as a software engineerNodeJS Tooling GroupKCD DiscordGuest: Ian SutherlandTwitter: @iansuGitHub: @iansuWebsite: iansutherland.caHost: Kent C. DoddsWebsite: kentcdodds.comTwitter: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsEpic React: epicreact.dev

fear pr tech code kent open source dev node getting involved nodejs create react app ian sutherland

[Weekend Drop] Miško Hevery: Qwik, PartyTown, and Lessons from Angular

The Swyx Mixtape

Play Episode Listen Later Oct 3, 2021 85:06

This podcast involves two live demos, you can catch up on the YouTube verison here: https://youtu.be/T3K_DrgLPXMLinks Builder.io https://www.builder.io/ PartyTown https://github.com/BuilderIO/partytown Qwik https://github.com/builderio/qwik https://dev.to/mhevery/a-first-look-at-qwik-the-html-first-framework-af Timestamps [00:01:53] Misko Intro [00:03:50] Builder.io [00:08:31] PartyTown [00:11:41] Web Workers vs Service Workers vs Atomics [00:15:02] PartyTown Demo [00:21:46] Qwik and Resumable vs Replayable Frameworks [00:25:40] Qwik vs React - the curse of Closures [00:27:32] Qwik Demo [00:42:40] Qwik Compiler Optimizations [00:53:00] Qwik Questions [01:00:05] Qwik vs Islands Architecture [01:02:59] Qwik Event Pooling [01:05:57] Qwik Conclusions [01:13:40] Qwik vs Angular Ivy [01:16:58] TED Talk: Metabolic Health Transcript [00:00:00] Misko Hevery: So the thing that I've learned from Angular.js days is make it really palatable, right. And solve a problem that nobody else has. Doing yet another framework in this state of our world would be complete suicide cause like it's just a different syntax for the same thing, right? So you need to be solving a problem that the other ones cannot solve. [00:00:22] swyx: The following is my conversation with Misko Hevery, former creator of Angular.js, and now CTO of Builder.io and creator of the Qwik framework. I often find that people with this level of seniority and accomplishment become jaded and imagine themselves above getting their hands dirty in code. [00:00:39] Misko is the furthest you could possibly get, having left Google and immediately starting work on the biggest problem he sees with the state of web development today, which is that most apps or most sites don't get a hundred out of a hundred on their lighthouse scores. We talked about how Builder.io gives users far more flexibility than any other headless CMS and then we go into the two main ways that Misko wants to change web performance forever: offloading third-party scripts with PartyTown, and then creating a resumable framework with Qwik. Finally, we close off with a Ted Talk from Mishko on metabolic health. Overall I'm incredibly inspired by Misko's mission, where he wants to see a world with lighter websites and lighter bodies. [00:01:23] I hope you enjoy these long form conversations. I'm trying to produce with amazing developers. I don't have a name for it, and I don't know what the plan is. I just know that I really enjoy it. And the feedback has been really great. I'm still figuring out the production process and trying to balance it with my other commitments so any tips are welcome. If you liked this, share it with a friend. If you have requests for other guests, pack them on social media. I'd like to basically make this a space where passionate builders and doers can talk about their craft and where things are going. So here's the interview. [00:01:53] Misko Intro [00:01:53] swyx: Basically I try to start cold, [00:01:55] assuming that people already know who you are. Essentially you and I met at Zadar and, I've heard of you for the longest time. I've heard you on a couple of podcasts, but I haven't been in the Angular world. And now you're no longer in the Angular world. [00:02:11] Misko Hevery: The child has graduated out of college. It's at a time. [00:02:15] swyx: My favorite discovery about you actually is that you have non-stop dad jokes. Um, we were walking home from like one of the dinners and that you're just like going, oh, that's amazing. [00:02:27] Yes. Yeah. [00:02:28] Misko Hevery: Yes. Um, most people cringe. I find it that it helps break that. It does and you know, the Dad jokes, so they're completely innocent. So you don't have to worry. I also have a good collection of, uh, computer jokes that only computer programmers get. [00:02:47] swyx: Okay. Hit me with one. [00:02:48] Misko Hevery: Um, "How do you measure functions?" [00:02:51] swyx: How do I measure functions? And the boring answer is arity, [00:02:55] Misko Hevery: and that's a good one! "In Para-Meters." Uh, [00:03:03] swyx: yeah. So for anyone listening like our entire journey back was like that it just like the whole group just groaning. No, that's really good. Okay. Well, it's really good to connect. I'm interested in what you're doing at Builder. You left Google to be CTO of Builder. I assumed that I knew what it was, from the name, it actually is a headless CMS and we can talk about that because I used to work at Netlify and we used to be very good friends with all the headless CMSes. And then we can talk about Qwik. How's that ? [00:03:34] Misko Hevery: I can jump into that. Sorry. My voice is a little raspy. I just got over a regular cold, like the regular cold ceilings [00:03:42] swyx: conference call, right. I dunno, I, I had it for a week and I only just got over it. [00:03:46] Misko Hevery: It was from the conference. Maybe it wasn't from the other trip I made anyways. [00:03:50] Builder.io [00:03:50] Misko Hevery: So let's talk about Builder. So Builder is what we call a headless visual CMS. Uh, I did not know any of that stuff. Would've meant. So I'm going to break it down because I assume that the audience might not know either. [00:04:01] So CMS means it's a content management system. What it means is that non-developers, uh, like typically a marketing department think like Gap. Gap needs to update .... If you're showing stuff on the screen, you can go to Everlane. Everlane is one of our customers. Okay. And so in Everlane case, the marketing department wants to change the content all the time. [00:04:22] Right? They want to change the sales, what things are on the top, what product that they want to feature, et cetera. And, um, this is typically done through a content management system. And the way this is typically done is that it's like a glorified spreadsheet where the engineering department makes a content. [00:04:39] And then it gives essentially key value pairs to the marketing. So the marketing person can change the text, maybe the image, but if the developer didn't think that the marketing person might want to change the color or font size, then there is no hook for it, and the marketing person can't do that. [00:04:54] Certainly marketing person won't be able to add new columns, decide that this is better shown in three columns versus two column mode or show a button or add additional text. None of that stuff is really possible in traditional content management systems. So, this is where the visual part comes in. So Builder.io is fully visual, right? [00:05:13] Drag and drop. You can add it, whatever you want in the page. And the last bit is headless, meaning that it's running on the customer's infrastructure and we don't host the website. If you are, if we are hosted CMS, then it's relatively easy to make a drag and drop editor. [00:05:28] But because we don't host it, it's not on our infrastructure. It's actually quite a head-scratcher. And the way we do this, which I think is pretty cool, is, we have this open source technology called Mitosis, which allows us to give one input to Mitosis and it can produced any output in terms of like, whether you use Angular, React, Vue, Svelte, Solid, it doesn't matter what you use on the backend. [00:05:50] We will generate a component for you. And because we're generating an actual component, it drops into the customer's backend infrastructure, right. And everything just works there. Server-side rendering works. Everything that, that the customer might have on a backend, it just worked because it's a full-on regular component, whether it's Angular, React, or whatever the company might use. [00:06:13] So that's the unique bit that nobody knows how to do. And it's also the bit that attracted me to Builder.io and joining them. And the reason for that is because it is really easy for them to create new technology. So one of the things we're going to talk about later is this thing called Qwik. [00:06:30] What's super easy with Builder.io is that they can easily produce new output. So if you have a customer that already has their content, let's say on react or Angular, and they decided they want to move over to something different, like Qwik, and I will talk about why that might be a reason, it is super easy because with a push of a button, because we generate the content, we can generate the components in a different framework. [00:06:55] swyx: Got it. It's interesting. Have you seen Tailwind? [00:06:57] Misko Hevery: So Tailwind is more of a CSS framework with my understanding is correct for [00:07:01] swyx: building, but they had to build something for doing this essentially like having different outputs, uh, we have one central template format that outputs all these different [00:07:11] Misko Hevery: things. [00:07:12] So this is what Mitosis would do. Right. But Mitosis can do this across all of them, not just Vue and React, right? Every single one. Like, I don't even know what the list is, but there's a huge list of possible outputs that uh, Mitosis [00:07:25] swyx: can do. Yeah. You have, Liquid and JSON. [00:07:30] Misko Hevery: There's more, I mean, this for ones that you see over here. [00:07:33] Yeah. You can see pretty much everything's analyst here. We can import from Figma, given some constraints. Cause it's not a one-to-one thing kind of a thing, but we can import from Figma. So the idea is that people can design their site in Figma provided that they follow a certain set of guidelines. [00:07:49] We can actually import them and to turn it into HTML and then serve it up, whether it's React or whatever. One of the things is that's actually important. For example, for us is Liquid, right? Liquid is a templating system on Shopify. But it's a server side templating system and it cannot be done on the client side. [00:08:05] So if you pre-render on Liquid, how do you get a component to bind to it on the client? Because you would need to have the same component. Right? One of the things we can do is we can present it on a liquid and then produce an, a equivalent react component on the client and they automatically bind to it on a client. [00:08:21] Right. So we can do these kinds of tricks which are normally quite difficult. [00:08:25] swyx: So you went from building one framework to building all the frameworks. [00:08:29] Misko Hevery: You can think of it that way. [00:08:31] PartyTown [00:08:31] Misko Hevery: But my real thing, the real passion is that I want to get all sides to be 100/100. Yeah. Okay. Uh, on mobile, not on this stop, you know, a lot of people claim on desktop that they can do 100 out of a hundred mobile, that's the bar. [00:08:46] So I want to figure out how to do this. And in order to do that, you really have to get super, super good at rendering these things. And it turns out that if you just make a blank page and blank, white page with nothing on it, and you add a Google tag manager, that alone puts you essentially on the cusp of a hundred, out of a hundred on mobile. [00:09:08] So that alone, that, that act alone, right, he's kind of uses up all your time that you have for rendering. And so the question becomes like, how do we make this as fast as possible? So you can get a hundred out of a hundred on mobile. And it's very little processing time that you get to have and still get to have a hundred. [00:09:25] And so we do two things. One is be introducing a new framework called Qwik. little later. But the other thing we're talking about is introducing this thing called PartyTown okay. And I absolutely love PartyTown. So the person behind PartyTown is Adam Bradley, who you might know him from, making the Ionic framework. [00:09:43] The guy is absolutely genius. And this is a perfect example of the cleverness of it. All right? So you have, something like a Google tag manager that you want to install on your website. And that thing alone is going to eat up all of your CPU time. So you really would like to put it on a WebWorker, but the problem is you can't because the WebWorker doesn't have DOM API. [00:10:02] It doesn't have a URL bar. It doesn't have just about everything that the Google tag manager wants to do. Right? Google tag manager wants to insert a tracking pixel on your screen. It wants to register a listener to the, to the, uh, URL changes. It wants to set up listeners for your mouse movements, for the clicks, all kinds of stuff. [00:10:21] So running it on a Web Worker becomes a problem. And so the clever bit of geniuses that Adam came up with is that, well, what you really want is you want to proxy the APIs on the main thread into the web worker thread, and you can proxy them through, you know, we have these, these objects called proxies. [00:10:39] The problem is that the code on a Web Worker expects everything to be synchronous. And our communication channel between the main thread and the web worker thread is async. And so the question becomes like, well, how do you solve this particular problem? And it turns out there is a solution to this problem. [00:10:56] And the solution is that you can make a XML HTTP request, which is synchronous, on a Web worker. And then you can intercept that the request using a service worker and then service worker can talk to the main thread. Figure out what exactly did you want to do? So for example, let's say you want to set up a, uh, you want to know the bounding rectangles of some div, the Web Worker thread can make that request, encode that request inside of a XML HTTP request, which goes to the service worker. Service worker calls the main thread, the main thread figures out what the rectangle boxes, and then sends the information back to the web worker thread, which then doesn't notice anything special. As far as it's concerned, it's just executing stuff, synchronously. It's like, you're laughing, right? Because this is hilarious. [00:11:41] Web Workers vs Service Workers vs Atomics [00:11:41] swyx: So I'm one of those. Okay. You're, you're a little bit ahead of me now. I'm one of those people I've never used web workers or service workers. Right. Um, can we talk a little about, a little bit about the difference and like, are they supposed to be used like that? Like, [00:11:54] Misko Hevery: uh, so we did these two because they are supported under the most browsers. [00:11:59] There's a different way of making synchronous call and that is through something called Atomics, but Atomics is not available on all browsers yet. [00:12:07] So web worker is basically just another thread that you have in the browser. [00:12:12] However, that thread doesn't have access to the DOM. So all DOM APIs are kind of gone from there. So you can do a lot of CPU intensive things over there, but, , with limited abilities and this is what PartyTown solves is it proxies all of the API from the main thread into the Web Worker thread. Yeah. [00:12:32] Now service worker is kind of a safe thing, but the difference is that a service worker can watch HTTP requests go by and it can intercept them. And so think of it as almost like a mini web server in your browser. And so what the service worker does over here is intercepts the request that the web worker makes, because that's the only way we know how to make it blocking call. [00:12:56] swyx: Uh, this is the one that we use for caching and Create React App and stuff like that. [00:13:00] Misko Hevery: Yeah. And then, because we can make a blocking call out of a web worker, the service worker who can use the blockiness of it to make an asynchronous call to the main thread and get all the information that you need. [00:13:12] swyx: that's pretty smart. Is there any relation to, uh, I know that I think either Jason Miller or Surma did a worker library that was supposed to make it easier to integrate, um, are you aware of, I think [00:13:25] Misko Hevery: all of these worker rivalries are in heart they're asynchronous, right. And that's what prevents us from using it, right. [00:13:31] Because the code as written assumes full asynchronicity, and that is the bit that's. Different. Right. That's the thing that allows us to take code as is, and just execute it in a, Web Worker. And so by doing that, we can take all of these expensive APIs, whether it's, Google tag manager, Analytics, Service Hub, I think that mispronouncing it, I think, all of these libraries can now go to the main thread and they have zero impact on your Google page speed score. And we actually talked to Chrome and we said like, Hey, we can do this. Do you think this is cheating? Right? Like, do you think that somehow we're just gaming the system and the message was no, no, because this actually makes the experience better for the user, right? [00:14:17] Like the user will come to the website. And because now the main thread is the thing that is running faster and none of this stuff is blocking. You actually have a better experience for the user. The other thing we can do is we can actually throttle how fast the Web Worker will run because when the Web Worker makes a request back to the main thread to say, like, I want the bounding box, or I'm going to set up a tracking pixel or anything like that, we don't have to process it immediately. [00:14:43] We can just say, well, process this at the next idle time. And so the end result is that you get a really high priority for the main thread and then the analytics loads when there's nothing else to do. Which is exactly what you want, right? You want these secondary things to load at a low priority and only be done when there's nothing else to do on the main thread. [00:15:02] PartyTown Demo [00:15:02] swyx: That's amazing. Okay. All right. We have some demos here if we want to [00:15:05] Misko Hevery: So if you, let's pick out the simple one, the element, right. And what you see in the console log is this is just a simple test, which performs, uh, synchronous operations. But what you see on the console log is that all of these operations are intercepted by the service worker. [00:15:22] Right. And we can see what particular API on the web worker is trying to do and what the result is, what the return code is, you know, how do we respond and so on and so forth. And so through this,you can kind of observe what your third party code does. By the way. The nice thing about this is also that, because you can observe, you can see is ECP. [00:15:43] If you're a third-party code, because we essentially trust them, right. Fully trust this third party code on your website and who knows what this third party code is doing. Right? So with this, you can see it and you can sandbox it and you can, for example, say like, yeah, I know you're trying to read the cookie, but I'm not going to let you, I'm just going to return an empty cookie because I don't think it's your business to do that. [00:16:04] You know, or any of those things we can do. So you can create a security sandbox around your third party code. That is kind of, as of right now is just implicitly trusted and you can, you have a better control over it. [00:16:18] swyx: I could filter for it, I'm basically, I need HTTP calls and then I need any cookies. [00:16:23] Right. So, [00:16:25] Misko Hevery: yeah. So in this case, there will be nothing because this is just showing off element API, but I think you go to previous page [00:16:33] swyx: Before we go there. is there anything significant and? It says startup 254 milliseconds? [00:16:38] Misko Hevery: Yeah. So the thing to understand is that it is slower, right? We are making the Google tag manager slower to start up. [00:16:46] Right. So it's definitely not going to be as fast as if it was on a main thread, but it's a, trade-off, we're doing intention. To say like, Hey, we want to give the CPU time to a user so that the user has a better experience rather than eagerly try to load analytics at the very, very beginning and then ruining it for the user. [00:17:04] So while in theory, you could run a react application and the web worker, I wouldn't be recommended because it will be running significantly slower. Okay. Um, because you know, all of these HTP requests, all these calls across the boundary, uh, would slow down. So it is a trade-off. [00:17:23] swyx: So this is really for the kind of people who are working on, sites that are, have a lot of third-party scripts for, [00:17:30] Misko Hevery: well, all the sides have third party scripts, right? [00:17:32] Like any kind of a site will have some kind of third-party whether it's analytics ads or just something that keeps track of what kind of exceptions happen on the client and send them back to the server, right. Standard standard things that people have on a website. And instead of the standard things that are making, preventing you from getting a hundred out of a hundred on your score. [00:17:52] Right. Okay, amazing. So this is a way of unloading stuff from the main thread Got [00:17:58] swyx: What's the API? I haven't seen the actual code that, Party Town. Okay. There's a, there's a adapter thingy and then [00:18:05] Misko Hevery: you stick it. So we, those are just for react components. There is also vanilla. Just go a little over. [00:18:14] So do [00:18:16] swyx: you see how we have to prioritize, React above Vanilla? [00:18:20] Misko Hevery: Even lower? This just shows you how you get the PartyTown going. Oh, here we go. Text to pay. We go right there. [00:18:25] You're looking at it right there. So notice what. We asked you to take your third party script, which, you know, if you go to Google on an exit, it tells you like, oh, take this script tag and just drop it inside of your head. Right. Or something like that. So what we do is we say like, do the same exact thing, except change the type to text/partytown. [00:18:43] And that basically tells the browser don't execute it. Instead, PartyTown will come later, read the stuff, ship it over to the web worker and then do it over there. [00:18:54] swyx: So the only API is you, you just change this, that's it? Yes. Yes. [00:18:58] Misko Hevery: So you drop a party down script into, uh, into, which is about six kilobytes. And then you go to all of the third-party places and just add, type text/partytown, and that ships them off to the other place. [00:19:10] swyx: So, um, it feels like Chrome should just build this in like script, script type third party. Right. And then just do it. [00:19:20] Misko Hevery: Yeah. I mean, we're having chats with them. You never know. Maybe if this shows up to be very useful technique. It might be something that Chrome could consider. Well, certainly we need a better way of making synchronous calls from the web worker thread to the main thread, not from the main ones of the web, right. [00:19:37] That's clearly a bad idea, but from the web worker, the main, it would be really nice to have a proper way of doing synchronous calls. [00:19:44] Atomics [00:19:44] Misko Hevery: Atomics might be the answer. And so it might be just as simple as getting all the browsers to adopt Atomics because the standard already exists. [00:19:51] swyx: And I see what, what is this thing I've never heard of it? [00:19:55] Misko Hevery: Atomics is basically a shared memory array buffer between two threads and you can do, atomic operations like locking and incrementing and things of that sort on it. And they can be done in a blocking way. So you can, for example, say, increment this to one and wait until whatever result is three or something like that. [00:20:14] So then you're giving a chance for the other thread to do its work. I [00:20:18] swyx: mean, this is like, so I'm writing assembly, like, [00:20:22] Misko Hevery: It's not assembly it's more, you know, semaphore synchronization. [00:20:26] swyx: Um, okay. Yeah. I see the, I see the locks and stuff, but this is, I can't just like throw in a third party script here. [00:20:33] Misko Hevery: No, no, no. This is something that the PartyTown would use to get synchronous messaging across. Right. Because currently it is kind of a hack that we create an XML HTTP request that is blocking that stuff with a service worker. Like this is craziness, right. So Atomics would definitely be a nicer way to do this. [00:20:51] swyx: I think the goal is definitely very worthwhile that the underlying, how you do it is a bit ugly, but who cares? [00:20:57] Misko Hevery: Yeah. So the goal is very simple, right? The goal is, for us, we think we can have the best CMS, if we can produce websites that are a hundred out of a hundred on mobile, right? [00:21:07] That's the goal. And if you look at the current state of the world, and if you go to e-commerce websites, it's pretty dismal. Like everybody gets like 20 something on their scores for their sites, right? Even Amazon that has all the resources to spend, will only get 60 out of a hundred on their score. [00:21:24] Even Google website themselves gets it only about 70, out of a hundred. Right? So the state of the world is not very good. And I feel like we are in this cold war in a sense that like everybody's website is equally bad, so nobody cares. Right. But I'm hoping that if you can build a couple of websites that are just amazingly fast, then the world's going to be like, well, now I have to care. [00:21:46] Qwik and Resumable vs Replayable Frameworks [00:21:46] Misko Hevery: Right? Because now it is different. And so now we're getting into the discussion of Qwik. So what is clicking and why do we need this? So, um, the basic idea behind Qwik, or rather than, let me back up a second of why existing websites are slow. [00:22:04] And so there's two reasons, right? One is third party scripts, and we just discussed how we can solve this through PartyTown right? I mean, we can move all of their party scripts off. [00:22:12] However, even if you move all the third party scripts off, your problem is still going to be that, uh, the startup time of your website is going to be pretty slow. And the reason for that is because all websites ship everything twice. First it's a server side rendered HTML, right. [00:22:30] And the page comes up quickly and then it's static. So we need to register listeners. Well, how do we adjust your listeners? Well, we download the whole site again, this time they came to in a form of TypeScript or JavaScript, and then we execute the whole site again, which is by the way, the server just did that. [00:22:49] Right? Yup. Yup. And then we know where to put up listeners and, that causes, you know, this is a perfect graphic for it, right. That causes double loading of everything. So we, we download everything once as HTML and then we load everything again, as JavaScript and then the execute the whole thing again. [00:23:07] So really we're doing everything twice. So what I'm saying is that the current set of framework are replayable, meaning that in order for them to have the bootstrap on the client, they have to replay everything that the server, literally just did, not even a second ago. And so Qwik is different in a sense, because it is resumable. [00:23:27] The big difference with Qwik is that the Qwik can send HTML across, and that's all. That's all it needs to send across. There's a little tiny bootstrapper, which is about one kilobyte and about one millisecond run, which just sets up a global listener and alert for the system. And no other code needs to be downloaded and it can resume exactly where the server left off. [00:23:48] So you need to have some formal way of serializing, the state, getting the state to the client, having a way of deserializing the state. More importantly, there's an importance to be able to render components independently from each other, right? And this is a problem with a lot of frameworks, which is - even if you could delay the startup time of a, uh, of an application, the moment you click on something react has to rerender the whole world right now, not rerender, that might be the wrong term, but it has to re execute its diffing algorithm from the root, right. It has to build up the vDOM. It has to reconcile the vDOM, has to do all these things, starting at the root. [00:24:26] There's no real way to not make it from the root. And so that means that it has to download all the code. And so the big thing about Qwik is, how can we have individual components be woken up individually from each other in any order? Right? I mean, people tend to talk about this in form of micro components or microservices on the client, right? [00:24:46] This is what we want, but at like the ultimate scale, where every component can act independently from everybody else. [00:24:54] swyx: Yeah. Yeah. I think, we should talk a little bit about that because basically every single component is its own module and separately downloaded. So you're really using the multiplexing or whatever you call it of HTTP/2, right? [00:25:05] Like you can parallelize all those downloading. Right. The main joke I made, because I saw this opportunity and I was like, immediately, like, I know this will be the most controversial part, which is essentially. Uh, the way you serialize is you put everything in HTML, right? Like, like that. [00:25:23] So, so I, I immediately feel that, and it will stir up some controversy, but like also, like, I think the, the interesting, I mean, we should talk a bit about this. Like, obviously this is not handwritten by, by, by people. So people should not be that worried. Um, but also like there are some legitimate concerns, right. [00:25:40] Qwik vs React - the curse of Closures [00:25:40] swyx: About how I think basically Dan Abramov was, was also the, the, you, you responded to Dan. Um, so Dan said something like this, okay. So it wasn't a direct response to Qwik but Qwik serializes all state in HTML, and that's something that we considered for React Suspense. And he says, basically the question was, have you considered allowing server components to have serializable state using equivalent? [00:26:03] it's been proposed somewhere earlier. This doesn't work generally state is in reaction arbitrary. Payloads would get huge essentially, like, "does it scale?" Is the question. Uh, and he said that this was done before and I went and looked it up and he was like, yeah. And it's actually what we used to do for ASP .NET WebForms. Right. [00:26:18] Misko Hevery: So if you will look at react the way to React does things. And so I want to pull this up on one of the dev, uh, dogs. I actually talk about it and it might be useful to kind of pull it out. Yeah, the one you are on right now, the answer adoptable fine-grained lazy loaded. The point is that if you have a react component, react components take heavily, closures, right? Closure is the bread and butter of react components and they rely on closures everywhere and it's beautiful. I it's absolutely nice. I really like the mental model. However, it doesn't serialize, right? [00:26:50] You can't take a closure and serialize it into HTML. So what Qwik is trying to do is it's trying to break this up into individual functions. Clearly functions cannot be serialized, but functions can get a URL , a globally known URL, uh, which can load this. So if you scroll a little lower, you will see a, uh, Qwik component , and the difference is, in a Qwik component, we'll have these declaration template, which is which points to a location to where this particular thing can be loaded, if you scroll even further, it talks about how this particular thing can be served up in pieces to the client, if you do this thing. Right. So while it's maybe true that like, oh, it's been tried before and we didn't do it right. [00:27:32] Qwik Demo [00:27:32] Misko Hevery: Have people really tried to solve every single one of these problems. Right. And there's a huge myriad of them that Qwik is trying to solve and kind of get over. And so maybe I can show it to you as a demo of what I kind of have a to-do app working. So let's let me, let's talk about this. [00:27:50] One of the things. So by the way, the screenshot you have on your Twitter account, that is the old version of Qwik, I've been chatting with you and bunch of other people at the conference, I really got inspired by lots of cool things. And this is a kind of a new version I'm working on, which has many of the issues fixed up and improved. So the thing I'm going to show you is standard todo example, right? I mean, you've seen this millions of times before. [00:28:15] swyx: By the way. I did not know that, uh, I think Addy Osmani made this original to do yes, he did. He did. And it's like the classic example. That was a classic example, [00:28:24] Misko Hevery: right? [00:28:27] So remember the goal for us is to serialize everything and send to the client in a form that the client can resume where the silver left off. Right. And then everything can be downloaded in pieces. So there's a lot of things to talk about. So let's start with, with how this works first, and then we can talk about how different pieces actually fit together. [00:28:46] So, you know, first thing you need to do, is, standard, define your interface for an item and define your interface for Todos, which is the collection of items, which contains , number of items completed in the current filter state, and just a list of items like so far, nothing. [00:29:02] Now the special thing comes in that when you declaring a object that you want to serialize, you will run it through this special function called Q object. And it's a marker function and does a couple of things to an object. But you're just basically passing all the stuff in and notice the individual items on Q objects as well. [00:29:20] The reason I did it this way is because I want to serialize individual line items separately, because I know that I'm going to be passing the individual items into separate components individually. Right? So what this basically says to the system is like, there is a top level object. Which is this guy right here and it can have rich state, but remember it has to be JSON serializable. [00:29:43] Therefore it cannot have cyclical things inside of it. It has to be a tree, but inside of it, it can have other objects and those can form cyclical things. So using the combination of those two, you can actually get cyclical graphs going inside of your application. But individually, each Q objects doesn't have that. [00:30:02] So that's a bit of a magic. If I scroll over to the actual running application, what you will notice is these Q objects get serialized like right here. So for example, this one has some ID and you notice it says completed zero and the inside of it has individual items. And notice these items are actually IDs to other locations. [00:30:22] So this ID ending in Zab is actually pointing to this object right here, which has other things. So the whole thing gets serialized. And unlike the demo I showed in Zadar, I have moved all the serialized content at the end, because I don't want to slow down the rendering of the top part. And so if you go, let's go back to our application. [00:30:41] So if you have Todo app, the Todo app is declared in a slightly more verbose way than the way the one would be declared in React. But if we do it this way, then we can serialize the closures, right? The closures don't have the issue with non serialized. By the way, the regular React way of doing things still works here and you can do that is just, they become permanently bound to their parents. [00:31:05] They cannot be lazy loaded. So you can think of it as having two mental models here. You can have lightweight components, which are essentially the same as react components, or you could have Q components, which are slightly more heavyweight, but they get the benefit of having the whole thing, be composable and get lazy a little bit so on and so forth. [00:31:24] So in this particular case, we're saying that there is a Todo app component and the QRL is this magical marker function that tells the system that this content here needs to be lazy. Or rather let me phrase it differently, it says the content here can be lazy loaded. The beauty of Qwik is that it allows you to put a lazy load of boundaries all throughout the system. [00:31:48] And then an optimization phase later decides whether or not we should take advantage of these lazy loaded motor boundaries, right in normal world, the developer has to put dynamic imports and that imports that asynchronous and a pain in the butt to work with, it's not simple. Right? So instead, what Qwik wants to do is say like, no, let's put dynamic imports everywhere, but do it in a way where the developer doesn't have to worry about it and then let the tooling figure out later whether or not we should actually have a dynamic import at this location or not. [00:32:18] Yeah. So even though this file, this there's two applications is in a single file in the tooling. We'll be able to break this file up into lots of small files and then decide in which order the things should be shipped to the client in order to get the best experience. You know, if there's a piece of code that never runs in the client will then put it at the bottom of the, of the chunks, right? [00:32:38] If there's a piece of code that is going to be most likely, you're going to click on it and put it up to the top. So, anyway, so that's kind of a diatribe here with a little bit of an off the rails here, but what this produces is a to-do and it turns the code, right? This QRL function, it says on render, it gets turned into a URL. [00:32:58] And this is what allows the build system to rearrange the code. And so this URL basically says, if you determine that Todo needs to be re re rendered, uh, then you can go download this piece of code. And that will tell you how do we render the Todo, right. [00:33:14] You know, you're using a header and we're using main, notice we're binding Todos in there. So it looks like a regular binding, but the system has to do more work. So in this particular case, the main has to see if it has Todos, it has to refer to a object. So notice this, this ID here matches the ID here. And this is basically how the system knows that this component here, because if you look over here, the main and foot are, both of them want to know that you do this right? [00:33:42] So both of these components need to have the same object. And so, yeah, exactly. So this main here, as well as the footer, they both have a same ID passed in here. And that's how the system knows like, all right, if I wake you up, I have to make sure to provide you with the same exact ID. Now, not only that there is also this particular thing, which is just a copy of it, but, but in this particular. [00:34:08] What it does is, is the list, all of the objects that could potentially affect the state of this component. And when you go and you modify one of these, state objects, the state, these objects actually keep track of each other and they know which components need to be woken up and affected. So I think there's an example of it somewhere here later, uh, like right here, right in here, it says, Hey, if you, uh, you know, do a key up on the input right here, if I type here over here, something, then the key up runs and then eat, enter runs, you know, add a new item, which is just the function that the function right here, which just pushes an item and new item into the list. [00:34:54] And it sets my current state to text me. And so the system knows that in this political case, in a header, this input right here, Has its own state right here. So let me refresh this again. Um, this header has its own state one eight, whatever, right? Which if you look over here is right here. It's text blank, right? [00:35:16] So we find typing here. I'm going to change the state over here. And then if I set the state to blank, then the system knows, oh, that's object 1 8, 7 1, or whatever. I can run a query. I can run document DOM, querySelectorAll. And I can say, give me, uh, all the queue objects, remember how the selector for this start something like this. [00:35:44] Anyways, there's a way to run a selector that will allow me to whatever, whatever the code is, right? I'll run the selector and this selector will then return this header back to me saying this is the object or rather, this is the component that is, has interests registered into this object, which means. [00:36:04] Because I've selected this thing. I have to find the Q render message and send the Q render message to download its template and we render the object. And so what this allows you to do is have a completely distributed set of components that can be awoken only when a relative, you know, appropriate data is changed rather than having this world of like, well, the state has changed and I don't know who has a reference to what? [00:36:30] So the only thing I can do is we learn that the whole page. Well, that's kind of a, it doesn't help you, right? Cause if you run the, the whole page, then there's the whole, the code has to come in here. Right. So that's not helpful. We want to make sure that we only download the code is actually needed. And so you need to have some mechanism by which, you know, like if I change this piece of code, if I change this object, which component needs to be awoken, right. [00:36:54] And normally like if you have Svelte, Svelte does through subscription, this particular trick, the problem is subscriptions cannot be serialized into the DOM. And so we need a mechanism where the subscription information is actually DOM serializable, right? And this is what the Q object is, or the subscriptions that the individual components have to undo to other things. [00:37:18] And so the other thing I kinda want to point out is that we can then bind a complex object. Like in this case, it's a complicated state that'd be assigned to reduce yet. It turned into a binding that's serializable into the bottom, right? So if I go back here, see I'm jumping around. So we have our footer. [00:37:38] If we have our main, the main is declared over here, you know, standard, uh, JSX in here where you, you want to iterate over a bunch of items. There's a host. Okay. So one of the things we need to do is, um, in react, when you have a component, the component is essentially hostless, or I would say it's life component in the sense that it doesn't have a parent, right. [00:38:02] Uh, and that is wonderful in many, many situations, but sometimes it isn't. The problem we have is that we need to have a component. We need to have a DOM element for each component that can be queried using querySelectorAll so that we can determine if there is a listener on it, or if there is a subscription on a particular object or a single back. [00:38:24] So we have this concept of a host element, and this is one way in which the Qwik Q component is more heavyweight than the react component. You can still use react components if you want, you just don't get the benefits we talked about. And, and so a host element is, is a way of referring to the, the host element and adding an attribute to it. [00:38:47] Right. And saying like, oh, I want the host, I'm going to have a classmate. And so if you go into, let's see Maine, uh, right. So it's supposed to be a classmate, right. So it's the component that, that adamant. So normally, uh, the way you do this normally in react is that the main would be a object that the JSX of the re. [00:39:07] The child react component, right? In this particular case for a variety of reasons, we need to eagerly create this particular thing. So then it's a placeholder for other things to go in. And so we need to do an eagerly and then we need a way of like referring to it. So that's what host is, sorry for the, uh, diatribe anyways, but this is how you create your items, right? [00:39:31] And notice the way you got your items is you just got it from your prompts and you can iterate over them. Right? You can reiterate and run the map and produce individual items. And for each item you will pass. And the key. So if you look at the item here, it's prompt says like, I am going to get an item in here. [00:39:50] And my internal state is whether an I am not, I am an editable state. So these are you, basically your props. And this is the components state in here. And, uh, you know, on mound, we create a component states that we're not, we're not an editable state. And then when the rendering runs, uh, it has both the information about the item as well as about whether or not you are currently editing. [00:40:13] Uh, and if you look at the UL, so here's our, one of our items that got generated, notice that the item that passed in as a ID here, right? So if you go to the script at the bottom and see this one ends in PT six, so we should be able to find, here we go, this is what actually is being passed in to that particular component. [00:40:34] But notice there's a second object. Not only is there a, um, a PT six objects, there's also the secondary option. That's the state of the components. So if the state of the component, we're basically saying here is like, if this object changes or this object changes, I want to know about it and I need to be. [00:40:52] So these objects form a graph, right? The presents, the state of your system. And then the Qwik provides a mechanism to serialize all this information into the DOM in such a way that we know which component is to be woken at what time. So if I start typing in one of the things you're going to see is that on the first interaction, this script that will disappear, because what actually happens is that when you interact with the system, it says like "I need to rehydrate myself". Right? And so it goes to the script tag and, uh, reads it. Let me give it back over here, read it leads to the script tag and figures out. You know, these utilizes all these objects because takes this object, puts them inside of this object to build up the graph and then goes back into the DOM tree and say like, okay, so I need to put this one over here. [00:41:40] I need to put this one over here, this one over here and so on and so forth and puts all these objects back. What are they supposed to be? And now you are, your state is back in a, in these components, but the components aren't present yet. They're not awoken, right? Because none of their, uh, Mount or their render functions actually got called. [00:41:59] And because the functions didn't get called, uh, the code didn't have to get downloaded. So everything is super lazy. Right. So when I go and I hit a key over here, the state gets de-centralized, but the only piece of code that gets downloaded is right. It is, it is right. This thing right here. [00:42:18] Nothing else. [00:42:19] swyx: Can we show that the network actually, ah, [00:42:22] Misko Hevery: I would love to, but that part is mocked out right now in the old demo, in the demo that I have, that I did for the conference, that one actually had it properly working. But the feedback was that the D as a developer, there was a lot of things I had to do. [00:42:40] Qwik Compiler Optimizations [00:42:40] Misko Hevery: And so I wanted to simplify it. So one of the things I did is I figured out a way, or rather I spoke with Adam, uh, the same Adam that did PartyTown. And we figured out how to make it, make the tooling smarter so that the developer doesn't have to do this. So what actually happens is that when you have the QRO over here, what actually happens is you, the, the code automatically gets refactored. [00:43:06] And you will get a new function with factor like this. The system will put an expert on it. And what gets placed in this location is a string that says something like, you know, ABC. Uh, hash you local, right. Or something like that. Right? So by doing this transformation and that piece of code is not working in this transformation, um, the, uh, the system can then, uh, lazy load, just the spirit physical code, nothing else. [00:43:39] But in order to do this transformation, we have to make sure that this code here doesn't have any closures. Right? I cannot, it cannot close over something and keep that variable because if it does the whole thing doesn't work. And so the nice thing is that we can still write it in a natural form, but one of the constraints here here is that you can't close over any variables. [00:44:01] Now there's no variables to close over them. The system is designed in such a way that it doesn't need it. Instead of things like props and state are explicitly passed into you, as well as to the thing of the child, whether they're halo as well. So you don't have a needs to create these kinds of closures, but it is a constraint. [00:44:19] And this is what allows the optimizer to go in and rearrange your code base in a way where we can then determine what things are used. So, so in this particular case, we can, for example, determined that you're likely to go and interact with the input box, but you are very unlikely to actually call this on render, because this is the kind of the Chrome, the shell of the application, and wants to show them the applications loaded you will never, ever interacted. [00:44:46] Right? So what you can do is you can take all these imports and you can sort them not alphabetically. You can sort them by the probability of usage. And then once you haven't sorted by the probability of usage, you can tell the optimizer like, okay, take the first N ones so that I have a chunk that's about 20 kilobytes because we think 20 kilobyte chunks. [00:45:08] And then the system can be like, okay, let me add a whole bunch of them until I have 20 kilobytes. Let me add a nice chunk, then underline about 20 clubs. And I kind of do these chunking all the way on the end. And then the last chunk we'll probably end up with a bunch of stuff that never ever gets loaded. [00:45:22] Right. But the problem is the current way we design applications. You can't do that. You just can't right. And so we have this mentality of like, we have frameworks that have amazing developer experience, but they set up the overall experience down the path of monolithic code base and any kind of, um, lazy loading that the Builder can add after the fact. [00:45:50] It's just like kind of a kloogey workaround. Right? And that's the thing that the Qwik solves it says like, no, no, no, let me help you design an application that has still nice developer experience, but let me structure things in a way so that I can later rearrange things, right? Let me keep you on this guide rails of like, make sure you do it in these ways. [00:46:12] And so everything is in the quickest set up in a way where it keeps you in this guide rails. And the result is, is a piece of code that the optimizer, then the Qwik can rearrange, right? It can go and pull out this function. It can pull out this function. It can pull out all of these functions and turn them into a top level functions that are exportable. [00:46:31] And it can then, um, tree shake the stuff that's not needed and produce chunks that can then be lazy loaded into your application. [00:46:41] swyx: Like four or five years ago, I think there was some, uh, I think even at the Chrome dev summit or something like that, there was a effort to use Guess.js to basically use Google analytics, to optimize all this, intelligent pre-loading or loading predictions. [00:46:58] Um, is that how I think I missed the part about how, like, how you pull in the statistics for, for optimizing. [00:47:05] Misko Hevery: So the first thing to talk about, I think is important to understand is that unless you can take your application and break it up into lots and lots and lots of chunks, I do that. Yeah. There's nothing to talk about. [00:47:15] Right? If your application is one big chunk, there's nothing to talk about. You would have to load the chunk end of discussion. [00:47:21] swyx: Well, so the chunk goes page level, and now you're doing component level, right? So they were, they were saying we split it by page and we can predict the next page. So, [00:47:30] Misko Hevery: so look at Amazon, right? [00:47:34] Most of this stuff, you will, I mean, you can click on stuff and there's a menu system up here and let's pick a random component here. How do I, let me just go to something. Oh, come on. Just give me a detail view of something every day. Uh, you know, most things here never have to be rendered. Like, for example, there's a component here. [00:47:52] This component never, ever changes. Nothing here. We're render nothing. We'll run it there, here. Uh, yes, these are components and I can click on them and they update the UI over here. But if I'm interacting here, why am I downloading the menu system? Right. And so the point is, if you have a page like this, there is huge number of components in here, but most of them either never update, or in my current path of interaction, I just don't need to update them. Right. If I'm using the menu system, then I don't need to download this thing here. And if I'm interacting with my item then I don't need the menu system, and I'm not, unless they put something out to car, do I have to worry about my shopping cart? [00:48:33] Right? And, and this is the problem is that we currently bundle the whole thing up as one giant monolithic chunk. And yes, there are ways to break this out, but they are not easy. And everybody knows how to do route level break up. But like even on rough level, it's, it's not, it's not fine grain enough. [00:48:53] Right. And so the magic of Qwik is the magic of writing the code in this particular style. Is that for a typical size application, I can break up the application in literally thousands of chunks. Now that's too much. We've gone way too far. I do. These, these chunks are too small and we don't want that. [00:49:13] Right. But when I can break things up, it's easy for me to assemble bigger chunks out of it. But the opposite isn't true, right? If I have a big chunk and I want to break it, well, good luck. You know, no amount of tooling is going to do this. As a matter of fact, the best AI system we have, which is right here in our brains. [00:49:31] Right. Even if you give it to the developer and say, go break this thing up, it's a head-scratcher that takes like weeks of work. Right? And so we are in this upside down world of like build a humongous thing and then have this attitude of like, somehow tooling will solve it. Tooling can solve this problem. [00:49:52] Right. You have to do it the other way around. You have to design a system which breaks into thousands of little chunks. And then the tooling can say, yeah, but that's too much. It's too fine-grained. And let me glue things together and put them together into bigger chunks because. Through experience. We know that an optimal chunk size is about 20 kilobytes, right? [00:50:11] And so now the thing you want is to get a list, the order of which the chunks are used, and that's easy, right? If you're running your application, you can just keep statistics on what, how users interact with your application and that's that the sticks can be sent back to the server. And so once you can get back on a server is just a ordered list of the probability by which you're going to need individual chunks. [00:50:35] And that sort of lists that sorted list is all you need to tell the optimizer, like start at the top of the list, keep adding items until you get to a correct chunk size, they'll start a new job, right. And you keep doing this over and over. Okay. Now the reason I get excited about this, the reason I talk about it is because we completely ignored this problem. [00:50:57] Right. We, we have these amazing frameworks, whether it's Angular, React, Svelte or whatever that allow you to build these amazing sites. But on the end of the day, we all have horrible page speed scores, because we're not thinking about it from the correct way. And the attitude for the longest time has been, the tooling will solve it later. [00:51:18] And my argument here is no, the tooling will not solve it later. If you make a mess of this code base, there's nothing that tooling can do. Yeah. [00:51:27] swyx: Um, there's so many directions. I could take that in. So first of all, uh, the React term for this is a sufficiently smart compiler, which has been in the docs for like four or five years. [00:51:36] Yeah. That's an exhibit, [00:51:39] Misko Hevery: but that's my point. Like you cannot make a sufficiently smart compiler [00:51:43] swyx: so is, I mean, is there a compile step for this because of the QRL section. [00:51:47] Misko Hevery: So right now it's actually running without compilation whatsoever. So one of the things I want to make sure that it runs both in a compiled and uncompiled state, and that's why it comes up with these bogus things like mock modules, et cetera. [00:52:01] Uh, and I think if you go to the network stab, it loads the mock module, and it just re-exports it. I can't really show you, but basically all of these things are kind of just in there. So currently this thing runs as a single monolithic application, but the, the way this thing would work is that as I pointed out everything, every place that you see QRL is a hint to the compiler to go and extract this. [00:52:26] The compiler, literally, we would just think. Ctrl+Shift+R extract here and then gives it a name which will be a header pull on a key up. Right. And then it repeats the same exact thing over here. So Ctrl+Shift+R extract. This is a header onMount. I mistyped it. It's okay. I get it right. And the same thing here, controls have to go Ctrl+Shift+R [00:53:00] Qwik Questions [00:53:00] swyx: what if I need to do like conditional loading because the competitor doesn't know which branch I need to go down. [00:53:09] Misko Hevery: So I'll answer the question in a second, did you want to point out, so notice what ends up here? The header is super, super lightweight. There's nothing in here. Cause these things, these two things will get converted into these URLs, right? Yeah. And because of that, this header is permanently bound to the onRender of the to-do app. [00:53:28] Right? If you load a to-do app you're also loading the header and of Main and a footer, but the thing we've done over here is we made this super lightweight, and this is what allows the lazy loading to happen. [00:53:41] Now you're asking what about other components? Uh, easy. I mean, uh, if you want it to conditionally include the header, you know, standard stuff. [00:53:51] Uh, true. Right now the, the header itself will always be permanently bound into the, on render of the to-do app. Right. However, because we did the trick when we extracted everything out of it had already super, super lightweight. It doesn't contain anything. Right? So the only thing the header really contains if you go in here is the what to do on this URL was the only thing that's in there and also this vendor, right? [00:54:18] So these two URLs are the only thing that is contained inside of the header by itself. Okay. It's only when we decide to render the header, do we go into the header? And we say, okay, we're doing a rendering. So what's your URL. And we look at this URL right here, we download the code. And so now the rendering pipeline has to be a synchronous. [00:54:38] We download the code and then we go and execute the content. And we basically fill in the content the better now in the process, we also realize, oh, we also have to download this piece of code. And this is where statistics would come together. And we basically tell us that this URL and this URL always get downloaded together. [00:54:57] And therefore the optimizer will be smart enough to always put them together in the same file in the same chunk. And, uh, you know, we rented the content. Got it. [00:55:09] swyx: Okay. So, uh, one small piece of, uh, API feedback slash questions. Uh, yeah, you have, the tag name is optional there. I guess that's a hint to what to store, right. [00:55:18] Misko Hevery: So right now it says to-do right here. If I have a [00:55:22] swyx: out, [00:55:24] Misko Hevery: it becomes, uh, just the div. Um, so the system doesn't care. What the thing is, it means eight element. Um, it could be any element they will do just fine. It's easier to kind of on the eyes if it actually says to do right. So that's the only reason for okay. [00:55:42] Got it. [00:55:43] swyx: the bigger piece is okay. It's like a lot of HTTP requests. Every time I basically, like every time I make a request, every time I interact with the app, I essentially need to do a whole new handshake, a whole new network transfer. There's some baseline weight for that. [00:56:00] Right. Chunking links that helps, um, is there a preload essentially? Is there a less programmatically say like, okay. And by the way, uh, this is important for offline capable apps. So I like, let's say like, I'm going offline. Like it's five things. I know I don't need it right now, but like as an app developer and [00:56:18] Misko Hevery: I know. [00:56:19] Yes. So, uh, we can totally do that. Um, we, uh, there is a level worker that will be set up and the web worker will get a list of all the chunks in the woodwork who will try to go and download them and set up the caching for you, uh, in these chunks of time. So that Y when you interact, the only thing that the browser has to do is execute the code now, because these chunks are small, the execution code, if we don't, we're not worried about it, right. [00:56:46] In the case of like on typical framework, that's replaceable. The problem is that the first time you interact with this thing, you have this huge amount of code to download parts and execute. But this isn't the case here because every interaction really only brings in the code that's strictly necessary for this interaction. [00:57:04] So again, we go to like Amazon, right? If I hover over here over these things, and it changes the image on the right side, the only code that gets downloaded and executed is the code for this. Now it's already pre downloaded because their web worker would go and pre fetch it for you. So the only thing that the browser has to do is parse the code and execute the code for the on hover, a callback that goes and updates this components URL. [00:57:27] Right. That's it? No other code needs to be downloaded in a presence. Yep. [00:57:31] swyx: Got it. anything else that we should cover real Qwik? [00:57:35] Misko Hevery: I feel like I have talked your ear off and you have been such a good and gracious host. Uh, happy to answer questions. I don't want to overwhelm people, but I am super excited as you can talk. [00:57:46] I'm super excited about this. I think it's a fundamental shift about how you think about a framework. So like, if you look at all the existing frameworks, they're all arguing about, like, I have a better index, I can do this better or that better and et cetera. Right. But fundamentally they're not the same, like essentially the same buckets they can all do about the same thing Qwik. [00:58:05] I think it's a whole new ballgame because the Qwik thing is not about like, oh, I can render a component just like, you know, 50 other frameworks can do as well. The thing that Qwik has is I can do it. I can give you microservices for free. I can give you this micro component architecture for free and I can produce a bundling. I am the sufficiently advanced compiler. Okay. Let's put it this way. This thing that you thought you could have and solve for you, doesn't exist unless you have the current guidelines. Right? So the thing with Qwik is that it is the thing that allows you to have a sufficiently smart compiler to give you this amazing times to interactivity, right? [00:58:48] At the end of the day, is the, there's nothing faster than downloading HTML for your website. I mean, that's the cake, right? Yep. So the reason why Qwik is fast is not because Qwik is clever in the way it runs JavaScript or anything like that. So no Qwik as fast because they don't have to do anything. [00:59:04] Right. When you, when you come to a Qwik website, there is literally nothing to do, right. We're fast because we don't do anything. And that's [00:59:13] swyx: your baseline is like a one kilobyte bike loader, right? [00:59:16] Misko Hevery: One come on loader with all the loader, does it sets up a global list? Right. So let me, let me go back. Sorry, let me share one more thing. [00:59:22] So here's your input, right? So if you go to a header, here's the input, right? The reason we know how to do something on it is because we serialize this thing called on:keyup, and there is a URL, right? So when this thing is first executed, nothing is done. Like this content shows up and it said we're done. [00:59:41] And the only reason why we know to do something next is because when I do a key up here, the event, bubbl

covid-19 jesus christ amazon learning europe google ai business technology lessons mexico service dna drop dad abc web airbnb figure maine id oz ted talks dom analytics drag solid cto mount elder oil react gap shopify api builder conf closure chrome liquid ui astro server apis cms vanilla javascript atp html ids backbone cpu closures css u s kb js urls figma vue tailwinds ul angular asp sesame jason miller json typescript tooling jquery ionic ivs widget marionette chunking zab service workers everlane netlify tsx htp svelte ecp surma mitosis zadar jsx hygienic adam bradley gwt dan abramov atomics qwik even google misko service hub qrl create react app qro addy osmani even amazon hevery web workers webworker react suspense misko hevery cmses vdom angular ivy

Next.js or create-react-app

The React Show

Play Episode Listen Later Jul 23, 2021 41:18

Just getting started with React? Or maybe you have built React apps for years but want to learn a better way of creating React projects? Next.js is a React based framework designed to improve the developer and user experience. In this episode we discuss Next.js, how it compares to Create-React-App, and when you might benefit from using Next.js instead.

react create react app

Potluck - Svelte × Bleeding-Edge Tech × Git Process × Screencasts × Government Jobs × Permissions-Based APIs × Rescript × More!

Syntax - Tasty Web Development Treats

Play Episode Listen Later Jul 21, 2021 59:51

It's another Potluck! In this episode, Scott and Wes answer your questions about Svelte, bleeding-edge tech, best Git processes, Create React App, screencast software, FitBit API, government jobs, Syntax sponsors, and more! .TECH Domains - Sponsor .TECH is taking the tech industry by storm. A domain that shows the world what you are all about! If you're looking for a domain name for your startup, portfolio, or your own project like we did with uses.tech, check out .tech Domains. Syntax listeners can snap their .TECH Domains at 80% off on five-year registration by visiting go.tech/syntaxistech and using the coupon code “syntax5”. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Mux - Sponsor Mux Video is an API-first platform that makes it easy for any developer to build beautiful video. Powered by data and designed by video experts, your video will work perfectly on every device, every time. Mux Video handles storage, encoding, and delivery so you can focus on building your product. Live streaming is just as easy and Mux will scale with you as you grow, whether you're serving a few dozen streams or a few million. Visit mux.com/syntax. Show Notes 03:15 - I was wondering what you guys think about using the latest of Svelte (svelte-next) in serious projects? Does the improved devEx makes up for the small (but growing) community and lack of libraries? Do you think svelte-next is here to stay or maybe we will get a revamp that breaks backward compatibility in a couple of years, like svelte 2 -> svelte 3? 8:48 - Git question: My process is often that I want to be able to use my last project as a starting point for my next project, with the new project having absolutely no connection or relationship to the old project. What steps can I take to completely sever any ties to the old project? Bonus question: In the new project I would love to eliminate all commits from the old project and start the new project having just one commit, the initial commit with all the code from the old project. 11:05 - Is CRA still useful for building actual production-level web apps these days? People seem to be reaching for Next or Gatsby most of the time, and I feel CRA is mainly used for actually learning React/building personal small websites. Your thoughts? Also, for normal CSR, I feel it is better to use something like Next, and fetch data inside your component (eg: for a dashboard) rather than building one with CRA. Am I wrong? 19:40 - What are your favorite screencast tools? (Linux? Mac? Windows?) 25:53 - Is it a bad trait for beginners to “give up” easily? By that, I mean instead of taking the time to think of the answer to a problem, they would instead rely on googling the solution and try to understand how it worked afterward. 27:55 - In pursuit of better health I want to track my weight daily using a smart digital scale. The idea is to automate the process of logging my own weight (e.g. stepping on the scale will update my Apple Health and any other integrations I have). After some searching around I landed on the Aria Air (mostly because I like the design and it has the coolest name). One small problem - it does not sync with Apple Health as it is a product from FitBit. They have an API so I'm thinking about running a serverless function daily, around 8 a.m. after I weigh in, to hit the FitBit API, get the data and push it to Apple Health. This way I can stay in the Apple eco-system whilst happily getting this nice, aesthetic digital scale. Any thoughts on how you would personally implement something like this? P.S. My girlfriend thinks I'm crazy, but I know the tinkerer inside Wes will love this. 30:26 - I work for the government with good pay and benefits and love where I work, but I feel like I'm missing out. Working in government we are not always working on the bleeding edge of technology. I do try and learn on my own, but it's hard sometimes if I don't put it into practice. I do peek at other job openings and get excited about the tech stack and the things they're doing. I'm just afraid if I leave I won't have the stability and benefits I would get from working in government. Any tips or thoughts would be appreciated. 34:24 - Unpopular opinion: Authentication isn't that hard, but authorization is! What systems have you built to handle when users with specific permissions are allowed (or disallowed) to take actions within your system? What advice would you give to other developers developing permissions-based APIs, assuming their users can have 5-10 different levels of permissions? 40:21 - What are your thoughts on ReScript as an alternative to TypeScript? 44:43 - How come you guys moved to two sponsors on a Hasty and three on a Tasty? Not that it's a big deal - was just curious of it was to keep up with costs or just because you could and then you'd make more? Either way, the show is awesome and really appreciate your opinions on everything! 48:01 - Have you tried Angular 12? I'd think you'd be pleasantly surprised if you gave it a chance! 52:20 - I have to copy and paste hundreds of products with six rows of details from a spreadsheet into a web interface because there is no API or CSV upload function for this program. Any recommendation on how to automate data entry into web inputs, navigate pages / click buttons, and toggle between applications? BTW, I scored my first web developer job and have to give you guys credit for steering me in the right direction. Links Svelte Create React App Next.js Vercel iShowU Descript Screenflow Aria Air FitBit Apple Health https://www.gov.uk/ Keystone rescript TypeScript Angular Syntax 359: Hasty Treat - Making a Vaccine Bot with JavaScript Puppeteer uses.tech wes.tech ××× SIIIIICK ××× PIIIICKS ××× Scott: SvelteKit Wes: Wyze Sprinkler Controller Shameless Plugs Scott: Svelte Components Course - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

4 | What Stack Should You Use on a New Dev Project in 2021?

COMPRESSEDfm

Play Episode Listen Later Apr 13, 2021 39:15

James and Amy discuss different categories of sites and the best tools and tech stacks to reach for. Categories include brochure and marketing sites, eCommerce, Applications, and Membership sites.SPONSORSPathwire / Mailgun / MailjetPathwire is a powerful email API and intuitive email marketing solution that delivers over 250 billion emails a year for 400,000 companies around the world.You can sign up now and try Mailgun or Mailjet for free today. Mailjet offers a trial that allows you to send 6,000 emails per month for free, forever. Mailgun offers a 3 month trial for 5,000 emails per month after which you only pay for what you send.For more information, simply visit Pathwire.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comZEAL is hiring!Zeal is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.Zeal believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, Coding Zeal looks for collaborative, object-oriented, and organized individuals to apply for open roles.https://www.codingzeal.com/hiringShow Notes0:00 Introduction2:42 Asking a lot of questionsWhat does this thing need to do? - Determine the hopes and dreams for the app o the app will be able to grow as the site grows.Working on an MVPWho's going to update it?5:36 Jot things down on paperWhat's it going to look like?7:23 Holotypes - fancy word for categoryA holotype gives a framework for being able to ask the right questions and know what tech to reach for.8:34 Brochure or Marketing SitesMostly informationalExamples: restaurants, stores, moving company9:39 eCommerce SitesCollecting credit card information10:11 Membership SitesManaging usersAbility to Log inDetermining what a user can do once they've logged inCollecting information on your users10:49 Difference between authentication and authorization11:40 Difference between a web site and a web applicationInteractivity13:00 Sponsor: Vercel13:17 YouTube video: I don't use Create React App anymore13:42 Technologies for Brochure and Marketing Sites13:57 WordPressPowers 1/3 of the InternetPowers 14.7% of the top 100 websites16:39 Webflow* No Code Solution* Writes and exports clean code19:40 James's personal site is on Gatsby* Can be difficult if you don't know GraphQL21:01 Other options, apart from ReactNuxt.js is the Next.js Vue equivalentScully for Angular21:26 Platforms eCommerce sitesEasy Digital DownloadsStripePayPalShopifyGravity FormsSnip CartPodiaGumRoad26:14 - Refactoring UI27:17 Sponsor: Pathwire / Mailgun / Mailjet28:58 Membership SitesCompressed.fm is using Auth0 and the API folderMembership plugins within WordPressPodia has a membership component30:05 Grab Bag Question #1: When is a good time to start freelancing?What is your tolerance for risk?Do you have a partner that can help contribute additional income or provide health benefits?Talk to your employer. They may be willing to negotiate.Talk to local stores, build a networkCan start right away, not all or nothing.33:15 Grab Bag Question #2: What are your thoughts on not code tools for developers?No code tools will not put developers out of work. They will just enable developers to focus on more interesting problems.Conversation around no code should be a safe space.35:53 Sponsor: ZEAL36:46 Amy's Pick: Roost StandPerfect laptop stand for mobile or remote working.37:23 Amy's Plug: SelfTeach.me on YouTube channelSeries on SVGsGetting ready to release a series on building the custom audio player, used on the Compressed.fm site.37:42 James's Pick: BenQ LightHelps with eye fatigue38:20 James's Plug #1: The Learn Build Teach Discord Community (free)38:42 James's Pick: James Q Quick on YouTube Channel

PodKit #65: Big Borg Cliffhanger

PodKit

Play Episode Listen Later Apr 12, 2021 49:07

Brian's starting a new job, standing desk mats, Create React App 4 Upgrade, Tailwind JIT, and shoutouts!

upgrade borg cliffhangers create react app

Using patch-package to workaround a create-react-app issue

3 Minutes with Kent

Play Episode Listen Later Mar 18, 2021 2:57

Hey friends. So today I was working on a little problem that I had with Create React app. So if you don't know Epic React is a combination of a bunch of React workshops that I have given many times in a life setting and it's a recorded version of kind of a live workshop that's kind of the feel. Anyway, all of the workshops there are powered by create react app under the hood and I've got a abstraction on top of that to share a bunch of code between all these different workshops.So I am in the process of moving everything over to TypeScript and I want to be able to have two different versions of TypeScript or of texture configuration for the exercises versus the final version. So I want to make sure that as we're moving everything over to TypeScript if you don't want to do TypeScript, it's as like easy as possible or if you've got very limited experience or no experience with TypeScript, you should still be able to get a lot of out of the workshops without having to have a bunch of red squigglies all over the place with their messages that you don't understand. And so,I don't want to have strict mode on of course for the those exercises because that would be against that goal. But I do want to have strict mode on for the final version of all the the exercises so I you know, because there's good reason to have strict mode and and it kind of helps me as I'm working on it to make sure that I'm doing everything the way that you probably should in a real application. And so, unfortunately with Korea react app if you don't have the TS config set up proper well here let me back up so.You can do this by having using project references and so you have just your main TS config that references other TS configs and then those can include an exclude different files. So I can get that set up but the problem is that in create react app if you're root TS config isn't doesn't have all the right properties then it will fill those in automatically for you and that messes up the references stuff. So, it just doesn't support references which is a big bummer. I made an issue about this. But what I did for,The foreseeable future unless create react to app ad support for references is I used this package on NPM called Patch Package and it allows you to install all of your dependencies and then you make a change to one of the files in your node modules and then you run the script and it will generate a patch for you and then you just set a post-install script in your package JSON and it will after your people install it it will apply that patch. And so, I was able to make a small change to create react app to support this. So give patch package a look it's pretty cool. It's kind of interesting. IHope that was interesting to you and I'll talk to you later.

korea react package patch ts json typescript i hope workarounds npm create react app

Dan Abramov of React Core Team Interview

FINOS Open Source in Fintech Podcast

Play Episode Listen Later Jan 14, 2021 32:56

Season 3, 1st edition of 2021 of the FINOS Open Source in Fintech Podcast: Dan Abramov of React Core Team Interview. So… welcome to 2021. We’re looking forward to a better year overall, even with some “interesting” beginnings. To start you out this year, while we’re working on our 2021 meetups and interviews, we want to highlight a few great discussions we’ve had within the community over the past couple of months. Our first of the year is an interview / fireside chat between Dan Abramov and James McLeod, recorded at the Open Source Strategy Forum (which is FINOS’s annual open source in financial services conference). Dan is a software engineer at Facebook, member of the React Core team, co-author of Create React App - and well regarded in the javascript community. James is our Director of Community for FINOS, and host for many of our Open Source in Fintech Podcasts and Meetups. During this interview we learn whether a project like React would work without backing from a large company like Facebook, whether Hacktoberfest raised issues for the React Core team, and how Facebook promotes InnerSource projects to open source, and more. So please enjoy this interview, check out our previous episodes, and subscribe to the podcast for some great upcoming discussions on open source, financial services, fintech, and how they all fit together. Dan Abramov's Bio Facebook Software Engineer, Member of the React Core Team, and Co-author of Create React App Dan Abramov is a software engineer at Facebook, member of the React Core team and co-author of Create React App. Prior to joining Facebook, Dan co-authored Redux, a predictable state container for JavaScript applications, which catapulted Dan as an influential conference speaker and successful Twitter commentator. Follow Dan on Twitter -=-=-=-=- About the Open Source in Fintech Podcast The FINOS Open Source in Fintech Podcast celebrates open source projects and interesting topics at the cross section of financial services and open source. So far, our industry experts have discussed practical applications of and their real-world experiences with a range of open source projects including desktop interoperability, low code platforms, synthetic data, and data modeling. They’ve also discussed best practices for inner source, common myths about open source and why commercial companies choose to introduce open source offerings. Tune in and subscribe to hear what comes next. ►►Visit here for more FINOS Meetups ►►Visit the FINOS website - and Get Involved ►►Join us for the FINOS & Linux Foundation Open Source Strategy Forum (OSSF).

director community member react redux open source javascript meetups core team hacktoberfest finos dan abramov fintech podcast create react app james mcleod react core

JS News 17

DevSpresso Podcast

Play Episode Listen Later Nov 4, 2020 15:06

A w tym odcinku w JS news: - Next.js 10 - Create-React-App 4.0 - Face ID and Touch ID for the Web - Kite AI - inteligentne snippety - Ankieta: state of CSS: https://stateofcss.com/ ### Prowadzący Juliusz Jakubowski https://www.linkedin.com/in/juliusz-jakubowski/ Aleksander Rakutska https://www.linkedin.com/in/arakutska/ ### Słuchaj jak Ci wygodnie Spotify http://bit.ly/devspresso_spotify Google Podcast http://bit.ly/devspresso_google_podcast iTunes http://bit.ly/devspresso_itunes Youtube http://bit.ly/devspresso_youtube SoundCloud http://bit.ly/devspresso_soundcloud ### Źródła https://nextjs.org/blog/next-10 https://github.com/facebook/create-react-app/blob/master/CHANGELOG.md https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/ https://venturebeat.com/2020/10/21/kite-ai-code-completion-python-javascript-typescript-java-html-css-go-c-kotlin-scala/ https://stateofcss.com/

css js face id touch id prowadz changelog ankieta create react app

42 выпуск 08 сезона. RuboCop 1.0, React v17.0, Node.js v15.0.0, Create React App 4.0, Ruby Perf Myths, JSDB, Fingerprintjs и прочее

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Oct 25, 2020 44:06

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby RuboCop 1.0 Ruby Perf Myths: GC and Concurrency How We Estimate The Size of a Rails Application Performance Benchmarks & Considerations between create_or_find_by & find_or_create_by Read-Only Mode For Better Rails Downtime Soft delete records with Paranoia Web React v17.0 Node.js v15.0.0 is here! Create React App 4.0 Introducing Microsoft Edge preview builds for Linux Introducing JSDB Fingerprintjs - modern & flexible browser fingerprinting library Pikaday - a refreshing JavaScript Datepicker - lightweight, no dependencies, modular CSS

myths considerations css node nodejs perf create react app

S1:E2 - React 17, Ruby, Chrome DevTools, Mozilla Layoffs, and Hello Weather

DevNews

Play Episode Listen Later Aug 13, 2020 39:12

In this episode, we cover Ruby 3 typing, GitHub running Ruby 2.7 in production, and Chrome DevTools CSS overview. We also speak with Jonas Downey, design lead at Basecamp, and co-creator of the Hello Weather app, about a Twitter thread he wrote titled, “Here’s a little tale about what it’s like to be an indie iOS developer working under Apple's 800-pound gorilla rule." Finally we chat with Dan Abramov, software engineer at Facebook, creator of Redux, and co-author of the Create React App. We’ll chat with Dan about React’s decision to release React 17 with no new features. Show Notes DevDiscuss (sponsor) Triplebyte (sponsor) CodeNewbie (sponsor) Vonage (sponsor) GitHub React Basecamp The State of Ruby 3 Typing Ruby 2.7 GitHub running Ruby 2.7 in production New in Chrome: CSS Overview Changing World, Changing Mozilla Here’s a little tale about what it’s like to be an indie iOS developer working under Apple's 800-pound gorilla rule... Hello Weather

apple weather ios react redux layoffs github basecamp mozilla vonage dan abramov codenewbie triplebyte chrome devtools create react app

EP5 JAMStack：Web开发更新鲜的工作流

Terminal

Play Episode Listen Later Jul 15, 2020 58:24

第五期！欢迎回来。2020年的Web开发是怎样的？以我们的前端工程师Perry带路，展开对静态网站生成器的回溯以及当下新鲜的JAMStack工作流的学习讨论。你们的Host： Perry，阿潦，李松联系我们可写信至 terminal.podcast.cn@gmail.com 或加入telegram听众群组 (https://t.me/joinchat/Gnvz6xnAtqRBnqIbjmuskg) 剪辑：阿潦音乐： Pulse 23 from Compassion through Algorithms (https://algorave-tokyo.bandcamp.com/) Show notes Part 1: 静态网站和JAMStack是？静态网站生成器(Static Site Generator) (https://www.staticgen.com/)：设计用来创建静态网站的软件包。 JAMStack (https://jamstack.org/)：JavaScript, APIs, 和 Markup的首字母缩写，一个近几年（可能是3年？）在Web开发快速火爆的热词。 Jekyll (https://jekyllrb.com/): 来自Github合作创始人之一Tom Preston-Werner的静态网站生成器，Github官方支持的选择。 Org mode for Emacs (https://orgmode.org/): 始于2003年的Emacs编辑模式，主要用来日常效率管理和文档记录。 Gatsby.js (https://www.gatsbyjs.org/): 基于React JS的静态网站生成器，用短短的时间已入住前端开发的工具箱之一。在2018年成立公司来支持项目继续发展，推出Gatsby Cloud (https://www.gatsbyjs.com/about/)。 Part 2: 静态网站的优势共享主机(Shared web hosting service) (https://en.wikipedia.org/wiki/Shared_web_hosting_service) Heroku (https://www.heroku.com/): "最元祖的云平台之一" - 中文维基百科高可用性(High availability) (https://en.wikipedia.org/wiki/High_availability): 计算机系统特性常用到的术语，“指系统无中断地执行其功能的能力”。 "IT公司为求产品上线顺利要求全体员工烧香拜佛" (http://www.chinanews.com/cul/2016/02-18/7762292.shtml) Create React App (https://create-react-app.dev/docs/getting-started/): React社区的官方脚手架工具。 "Webpack配置是世界上最难的编程语言" (https://twitter.com/horse_js/status/1266393469590867968) CDN(内容分发网络) (https://zh.wikipedia.org/wiki/%E5%85%A7%E5%AE%B9%E5%82%B3%E9%81%9E%E7%B6%B2%E8%B7%AF) Part 3: JAMStack 适合各种网站吗最终一致性 (https://en.wikipedia.org/wiki/Eventual_consistency) LAMP (https://en.wikipedia.org/wiki/LAMP_(software_bundle)): 曾经很流行的Web服务架构。 Wordpress (https://wordpress.org/): 超流行的开源博客/内容管理系统，世界上最流行的Top 一千万的网站中有1/3基于Wordpres (https://w3techs.com/technologies/overview/content_management)。 wp-graphql (https://www.wpgraphql.com/): 让你的Wordpress 实例拥有一个GraphlQL API。 Headless CMS (https://en.wikipedia.org/wiki/Headless_content_management_system): 无头的CMS（内管管理系统），通过暴露API供客户端使用。 NoBackends (http://nobackend.org/): 一种美好的无后端开发模式，任何功能幻想可以在Javascript中的一行函数实现。 Part4: 上手的选择 Gatsby.js (https://www.gatsbyjs.org/): 基于React JS的静态网站生成器，用短短的时间已入住前端开发的工具箱之一。在2018年成立公司来支持项目继续发展，推出Gatsby Cloud (https://www.gatsbyjs.com/about/)。 11ty (https://www.11ty.dev/): Node.JS写成的更简单的静态网站生成器。著名案例包括Google的web.dev (https://web.dev/) 和 v8.dev (https://v8.dev/)。更正: 开发者来自Netlify而非Google Vercel (曾用名 ZEIT) (https://vercel.com/): 另一个流行的托管平台。可以看看最近官方的更名Post：ZEIT is now Vercel (https://vercel.com/blog/zeit-is-now-vercel)。 Netlify (https://www.netlify.com/): 2016创建于旧金山，专注于静态网站托管的服务。深受独立Web开发者喜爱。免费量大，具体团队价格可参考 (https://www.netlify.com/pricing/)。 Github Pages (https://pages.github.com/): 整合在Github仓库的静态网站服务，数不过来的流行开源项目的主页host在此。 strapi (https://strapi.io/): 基于Node.JS的开源Headless CMS，设计为与静态网站设计结合使用。 Picks: 李松 wptools (https://github.com/siznax/wptools/) by Steve Sisney，为人类设计的维基百科工具。 Perry 《金字塔原理》 (https://book.douban.com/subject/1020644/)，关于整合思维逻辑的书。阿潦最后生还者：第二幕 The Last of Us Part II (https://www.playstation.com/en-gb/games/the-last-of-us-part-ii-ps4/), 峰（反）回（复）路（横）转（跳）的剧情向大作（或是25小时泰勒吉他广告片。

86: Testaaminen ei ole helppoa. Ei edes Cypressillä

Webbidevaus.fi

Play Episode Listen Later May 31, 2020 64:45

End-to-end testaus Cypressillä on kivaa aina niin kauan kun asiat menevät putkeen. Mutta aina (koskaan) näin ei ole. Tässä jaksossa sekoittuu sopivassa suhteessa Antin CD-kokoelmien nostalgisointi ja armottoman tiukka tekkianalyysi. Onko Snowpack 2.0 seuraava Create React App, ja onko buildityökalulla / devausympäristöllä enää mitään merkitystä? Onko jo aika jollekin uudelle?LinkitHTML5 BoilerplateCypressSnowpack 2.0Jakson valinnatAnttiVegaaninen soijarouhelasagneOld Man's WarRikuFlowers for AlgernonOta yhteyttä!@webbidevauswebbidevaus.fi

onko mutta edes create react app

Jenn Creighton on Gatsby, SPAs, conference speaking and more

That's my JAMstack

Play Episode Listen Later Feb 25, 2020

Quick show notes Our Guest: Jenn Creighton What she'd like for you to see: Her Twitter feed | React Day NYC | Thinkster React Component Course (coming soon) | useReactNYC Her JAMstack Jams: Gatsby | Netlify Her musical Jam: Halsey's You Should Be Sad Our sponsor this week: TakeShape Transcript Bryan Robinson 0:04 Welcome, welcome everyone to a new episode of that's my JAMstack the podcast where we explore the deepest parts of the developer psyche by asking, what's your jam in the JAMstack. On today's episode we're chatting with Jenn Creighton, Jenn is a conference speaker and the organizer of useReact NYC. She's also the front end architect for The Wing. Bryan Robinson 0:23 Also, this week, we have our amazing sponsor TakeShape. Find out more about their JAMstack content platforms stick around after the episode or head over to takeshape.io/thatsmyjamstack. Bryan Robinson 0:36 All right. Well, thanks for joining us on the podcast today, Jenn. Jenn Creighton 0:38 Thank you for having me. Bryan Robinson 0:40 Thanks. So tell us a little bit about yourself. What do you do for work? What do you do for fun, that sort of thing? Jenn Creighton 0:45 Sure. So I am a front end architect at a company called The Wing. We work on building out co working spaces that are really geared towards women. So we're thinking a lot about what women need in those spaces, and also there's a lot of networking events and things like that in our spaces. Jenn Creighton 1:03 So I'm the front end architect there, I lead all of front end. I help ensure our system stays healthy. I work on our technical decisions there. You can already tell I'm a lot of fun because I really love tech. And honestly, like what I do for fun, I'm usually at a conference. I'm usually speaking at a conference, I really, really enjoy giving technical talks. So you will find that I'm often at a conference, I travel a lot to do that. I did 14 conferences last year, which I won't be repeating but it was a lot of fun. I had a good time. And if I'm genuinely not doing any tech related things, I am probably with my cats or my puppy or I am sewing. I really enjoy sewing. Bryan Robinson 1:53 So I saw and I think this is on like your Noti.st profile, is your dog's name really Sailor Moon because that's amazing Jenn Creighton 2:00 Her name IS Sailor Moon. She is named after the you know, Sailor Guardian Sailor Moon and she's a little blonde dachsund and, and I grew up watching Sailor Moon. I loved that show. I would watch it so much. And when I was thinking of names for her, I really want something kind of fun. So I picked out that it's really great too, because when you tell people her name, you can tell if they watch the show or not. Because they're either That is amazing. Or they're Wow, that's a lot of a name. Bryan Robinson 2:35 I'll be honest, do you just call her Sailor Moon all the time. Jenn Creighton 2:39 We usually call her sailor or if she's being a bit sassy Miss moon. Bryan Robinson 2:43 That works that work. And any fun sewing projects that you're working on. Jenn Creighton 2:48 I actually haven't sold in a long time because of the mentioned 14 conferences. So actually did not so I think anything last year. No, that's not true. Wait, I took a sewing class in November as my like, you're gonna do it and I sewed a pair of pants for the first time I took a sewing class to like force myself into a non tech hobby, which is a good thing to do once in a while. Bryan Robinson 3:17 Yeah, especially 14 conferences in 12 months. How many how many months were filled with more than two conferences? Did you did you group together and how exhausting was that? Jenn Creighton 3:28 Some months were grouped together. Um, let's see, I think I know at least I did, in September, I did two. And I traveled really far for them. So I did JS Conf Korea, and Components Comf in Australia together. And I think I had some some weeks and breaks there but a couple of them were like, in the same month and so I would knock out like two or three in the same month and then have like a little bit of a break which usually Wasn't a break. Like between Components Conf and React Conf. I actually had to write my React Conf talk. Bryan Robinson 4:09 The glamour of being a conference speaker! Jenn Creighton 4:11 It's so not glamorous, it's so exhausting. And yet, we can like people who enjoy it can't stop doing it. I don't know if you remember this, but there was a survey that came out many many years ago that said that people are more afraid of public speaking than they are of death. And so conference speaking is actually like a near death experience. As you get like this ridiculous rush, you're terrified you feel great afterwards. You're like, I'll just do it again. Bryan Robinson 4:44 I just watched the the Imagineering story the the story of all like the Disney theme park building and all that. And it talks about all the all the rides and how the goal is to make people feel like they're about to die without getting them actually all the way to death. So it's the same basic principle just with public speaking. Jenn Creighton 5:01 I think that happens with code too, Like, I just spent two days solving this issue of my tests failing on circle ci when they weren't failing locally. And I wanted to die. I want to lay down and die. I was like, take me, Lord, now and then I figured it out. I felt great. Bryan Robinson 5:20 So this is a JAMstack podcast, let's talk about the JAMstack a little bit. What's been kind of your introduction into that world or into static sites or wherever you kind of came to it from? Jenn Creighton 5:30 I think with static sites, the first time I remember seeing like a static site generator was Jekyll. And this was back at a startup many, many years ago. I remember we used it for I believe our marketing site, which was like pretty typical. And I really didn't know that there would be static site generators. It was kind of surprising to me. But I also didn't really play with it because I was just trying to learn JavaScript. I was like, this is where I'm like, trying to figure things out. The actual JAMstack, you know, JavaScript API's and markup, my introduction to that has come a lot later than I think a lot of people I actually just started, I'd say late last year getting interested in the concept and starting to learn about it. We use it at work for our marketing website. And then personally, we've used it for a meetup that I run here in New York called useReactNYC. Bryan Robinson 6:28 What's sort of technology stack are you messing with right now? Jenn Creighton 6:32 So both of them are using Gatsby, but the marketing site is Gatsby plus Contentful. So that of course, our marketing people can make their own changes to the site, and we don't have to be, you know, nudged. "Hey Can you do a thing?" Bryan Robinson 6:48 "Please deploy, please, deploy!" Jenn Creighton 6:49 "Please make this change." So it gives them the freedom to do that without having to wait on us to make changes. It gives us the freedom not to think about the marketing site, very much. Then for useReactNYC, we wanted to create a website for the meetup so that people could learn more about us what we're about, and also join our community, both by attending the meetups, but also by joining our slack community, and also by helping us to build the site. And since we're a React meetup, it made a lot of sense that this would be a static site, and that we would make it with Gatsby. Bryan Robinson 7:27 Very nice. And any sort of ... Is there any sort of like API integration? Are you pulling in like meetup information from a third party? Or is it all just manual entry into into Gatsby? Jenn Creighton 7:37 Right now let's just manual entry. We definitely want to expand it at some point. We're just not sure that we have the time right now between the five organizers that there are, we actually took on another organizer this year to make five of us Yuraima joined us and we have just all been really stretched thin. So even with the fifth organizer, we're still like "huuu", but we're hopefully gonna start recording the meetup soon and hopefully we'll also host them there so that people can view the content. Bryan Robinson 8:08 Pretty cool. I definitely understand that. That meetup organizer life where you're like, hey, PRs are accepted, and then no one submits a PR. Jenn Creighton 8:16 Yeah, we did have a particular member of the community, Nick, who came in and helped us really do a lot of work on the site, when we were all stretched very thin. And my very good friend Melissa, helped us actually by creating the design of the site, and it's really beautiful. She did a wonderful job. She also designed our stickers. So really, like all community events, it is really like we wouldn't have done it without the community like helping us out. That's was important. Bryan Robinson 8:45 Cool. So uh, are you You said that the marketing site at The Wing is currently built on Gatsby. What other sorts of projects do you work on at The Wing other than obviously getting the word out about these kind of co-working spaces? Jenn Creighton 8:58 So what what I personally work on is that I work on our single page application. So Gatsby is for our marketing site. But we do have a single page application that is for our members. That's our members portal as well as an admin site for us to handle things like applications or members, information, adjusting settings for them, so on and so forth. But our members portal is where everything really happens for them, they're allowed to find other people in the community and chat with them. There are job postings on the site as well. And there are a lot of events at The Wing that are very specific to what our members want to hear and see. And so they can RSVP for those as well on the site, as well as just the general thing of like adjusting settings or registering guests. So I work on all of that and as we try to build out new features that are going to help our members connect more and forum like real in life connections are putting a lot of those in this single page application. Bryan Robinson 10:01 Very cool. And so just like -- I have a degree in philosophy, so I have to sometimes dive into philosophy on the podcast -- So where would you kind of consider kind of breakpoint, because you said, you know, I'm using the JAMstack for the marketing site. And for the meetup site, I've always kind of thought of any SPA as having JAMstack asked qualities. Where do you kind of draw that line? Like, what what's JAMstack versus non JAMstack for you. Jenn Creighton 10:28 So the reason that I qualified as a single page application instead of anything to do with the JAMstack, is because it's built using create react app. And so it actually has a server. So nothing's actually served by CDN, which I think is an important component of JAMstack sites, you know, they have to be served statically through CDN or some means of static. So they're not pre rendered. They're not static. It's it's an actual serving of just an index.html, and then we fill in the JavaScript for everything. Bryan Robinson 10:59 I gotcha. Cool. That's the the kind of fun thing about running this podcast is that I hear lots of opinions. And they literally run the full gamut of like, everything's the JAMstack to like, even smaller like subsets. And it's just yeah, it's awesome. Jenn Creighton 11:15 Yeah, I mean, and when you hear like that it's JavaScript API's and markup, you're like, well, how is this not every single page application? And that totally makes sense. Definitely. I think the JAMstack has some really specific qualities to it, though, that are very different from something built with like create react app that actually does have a server that you're not actually serving at statically. And you're relying on the JavaScript to do all the heavy lifting of creating all the page. It's not pre rendered. You know, we certainly don't have the ability for... One of the things I really like about the JAMstack is that it closes that gap for the user, right like they get the stuff immediately. And also how your deploys go. You know, you can roll them back and there get based. But you don't have that with the single page application. And sometimes I was wondering with that I was like, does this need to be anyway, I was like, but I'm not rewriting the whole thing. And that decision was made before I came into the company. And I was like, You know what, it's, it's fine. Bryan Robinson 12:22 And still React. So you still get to work on react. Jenn Creighton 12:25 Yeah, and I love I love react. So that like, is a joy for me. Bryan Robinson 12:29 And so is there anything that you've that you've been learning based on your work in Gatsby that you're bringing back into the the server side and the Create React App side of all that Jenn Creighton 12:41 Not specifically? I think Gatsby comes with a lot of wonderful things that are not even technically part of JAMstack, right. Like I would say I would say that there is a great amount of focus on accessibility and Gatsby I really, really appreciate that. And that is something we're really focused on at work. So like many startups, so our product team is really new at the way. And like many startups, the first version of our product was built externally by a third party. And so we're now as a product team, picking it up and sort of changing the architecture and making it more of a long term scalable application. And that includes taking a look at our accessibility and realizing that we're really far off the mark right now. And we need to do something about that. I really appreciate that Gatsby, in addition to using JAMstack is actually really like moving forward with accessibility and giving you a lot of information about that along the way. Bryan Robinson 13:46 Yeah. And the great thing for me is that there's so many people jumping on Gatsby right now, just in terms of like, it is like probably one of the hotness is in the JAMstack right now. And to have that their focus so that people who might not have learned about accessibility in the are getting those tips and tricks just by having that in their code base by default. I think that's amazing. Jenn Creighton 14:05 Yeah, exactly. And that's one of the things I really enjoy about that project. And that's one of the things like, as you're working on that, you get to learn that you can bring that to all your future projects. It's not specific to the JAMstack. It is all about the web. Bryan Robinson 14:19 Best platform there is... the web. Jenn Creighton 14:21 Yes. Bryan Robinson 14:22 Cool. So So would it be fair to say that in the JAMstack, the Gatsby is your jam? Are there any other technologies that you're really interested in right now? Jenn Creighton 14:30 I think Gatsby is the main one. Obviously, we're really enjoying also Netlify and being able to like push things out really easy. So we use Netlify also for our preview links at work which is really great. So just definitely enjoying that. But yeah, I think definitely Gatsby considering that I've used it at work and now in this useReactNYC project. Bryan Robinson 14:54 Nice and so work when when people are saving into contentful, are y'all deploying Preview deploys to send them links at same time. So like they can see it live on the site before they publish it. Jenn Creighton 15:06 I think so. Yeah. I forget because I haven't worked with it in a hot second and if anyone's changed behind my back, but yeah. Bryan Robinson 15:14 You never know. Jenn Creighton 15:15 Honestly, with a startup you never know. Bryan Robinson 15:18 It's so easy to deploy, right? Jenn Creighton 15:20 Things happen in a startup that I'm like, wait a minute, you're doing what now? Can we just Can we just grab five really quickly and make sure this is a good idea? All the time. Bryan Robinson 15:30 Okay, gotta move fast, right? Jenn Creighton 15:32 Yes. Move fast break. Things. Break. ... Both of us are like "arrrrgh no!" Bryan Robinson 15:39 Yeah. Don't Don't tell QA that you broke it. It's fine. Jenn Creighton 15:44 Yeah. Bryan Robinson 15:46 Cool. So let's, let's talk about actual musical jams. Then what are you listening to right now? It's in your headphones. What's going on there? Jenn Creighton 15:53 So my number one thing right now is Halsey. Which is strange. I didn't listen to her before, but I actually so I'm a big fan of Saturday Night Live. I love Saturday Night Live. And she hosted not that long ago. And she was the host and the musical guests. And I wasn't familiar really with her music, but she had this song on there, You Should Be Sad. And I just fell in love with it. So I've actually been playing that on repeat for like a while. I love her vocals on it. It like just makes me feel really good. Bryan Robinson 16:28 Yeah, so specifically that song but then kind of the whole, her whole artistry. Jenn Creighton 16:34 I let I let that song play and then I'll listen to like a lot of the other ones on the album and I'm finding that I really enjoy her songs, which is really great. Jenn Creighton 16:44 And just depends on what mood I'm in. Bryan Robinson 16:47 What other moods strike you for, for other musical tastes. Jenn Creighton 16:51 And sometimes we like to go old school like country. Little little like kind of plucky banjo sound You know, really enjoy that sometimes. So I went through an Iggy Azalea phase. That was an interesting period of my life. Bryan Robinson 17:10 I think we've all been through that sort of phase. We've all been there. Jenn Creighton 17:14 Sometimes my my discover weekly on Spotify, I think is consistently confused. It's like, remember when you were sad? Well, here's all the sad songs and I'm like, oh, but Spotify. I'm not sad anymore. It's like, Okay. Here's poppy feminist music. I'm like, no, we're not in that mood. We're angry, now. Where's the angry? It's like, I cannot help you, I'm sorry. Sorry, Spotify. Bryan Robinson 17:39 The algorithm can only do so much for you. Cool. So is there anything that you would like to promote something you're doing something you want get out to the JAMstack community? Jenn Creighton 17:47 Well, first of all, if they're interested, they can follow me on Twitter. My handle is gurlcode girl with a "u". I'm also going to be speaking here in New York at React Day New York. Later in September, I'm going to be speaking about some things I have learned going from React to React Native, which is a whole new world for me. And then I'm also developing a course on React component architecture. That's my, my favorite sort of subject. I'm developing it for Thinkster. So that should be coming out, I think in a few months, if I have enough time to do all the recordings Bryan Robinson 18:24 Very cool. And also, I haven't watched it yet, but I'm super excited now that I've seen it to go watch your the "What happens next", the choose your own adventure with iterators. Like, I have to go watch that I saw that topic. I said, Okay, carving out the time for that one. Jenn Creighton 18:39 I love iterators I love them so much. They're wild. They're in so many things that we use in JavaScript, and we have no clue. And that's what that talk is about. And also it's like ridiculous and silly. You're on like an alien planet solving a mystery. And I had this artists do this beautiful work for it. So it's ridiculous, but yeah, Bryan Robinson 19:00 Ridiculous is the best way to go. Jenn Creighton 19:03 Yeah, it's like funny and weird. I enjoy it. Bryan Robinson 19:06 Well, I appreciate you taking the time to talk with us. And we'll be sure to link all those, all those amazing things that you're doing up in the show notes. And yeah, thanks for taking the time. Jenn Creighton 19:14 Thank you for having me really enjoyed it. Bryan Robinson 19:16 And as always, thank you to the amazing JAMstack community, your continued support via shares, likes favorites, and all those mechanisms is so incredible that I literally just don't have the words to deal with it. Bryan Robinson 19:29 With that it's sponsored time, and we're talking about the amazing content platform take shape. This week, I want to mention their amazing GraphQL API. It's not an afterthought, but a fully realized part of their platform. It means that whether you use their CMS or another platform entirely, you have an incredibly easy access to all your data in one simple API call. Do you want to see what that's like? Head on over to takeshape.io/that'smyjamstack to sign up. And with that, I'll take my leave of your ears. So until next week, Keep doing amazing things on the web and keep things JammyTranscribed by https://otter.aiIntro/outtro music by bensound.comSupport That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

RNR 156: Progressive Web Apps versus React Native

React Native Radio

Play Episode Listen Later Feb 25, 2020 48:47

The panel dives into the pros and cons of writing PWAs versus writing React Native applications. We work out the definition (sort of) of a PWA and having a web application that works well on mobile and the availability and complexity tradeoffs between the two solutions. Panelists Jamon Holmgren Josh Justice Charles Max Wood Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Google - Progressive Web Apps Progressive Web Apps: Escaping Tabs Without Losing Our Soul Apple's Refusal to Support PWA's Alexander Pope: ServiceWorkers Outbreak Why Was Service Worker Merged into Create React App? EmberConf 2016: Opening Keynote by Yehuda Katz & Tom Dale Picks Josh Justice: Sleeping Queens Sushi Go! Jamon Holmgren: Learn to code in 2020, get hired, and have fun along the way Charles Max Wood: Hiss King of Tokyo

amazon apple tokyo panelists refusal hiss pwa react native progressive web apps pwas opening keynote sushi go cachefly charles max wood create react app yehuda katz infinite red tom dale react native radio finding your dream developer job jamon holmgren maxcoders guide emberconf hisss

RNR 156: Progressive Web Apps versus React Native

Syntax - Tasty Web Development Treats

Play Episode Listen Later Feb 25, 2020 48:47

The panel dives into the pros and cons of writing PWAs versus writing React Native applications. We work out the definition (sort of) of a PWA and having a web application that works well on mobile and the availability and complexity tradeoffs between the two solutions. Panelists Jamon Holmgren Josh Justice Charles Max Wood Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Google - Progressive Web Apps Progressive Web Apps: Escaping Tabs Without Losing Our Soul Apple's Refusal to Support PWA's Alexander Pope: ServiceWorkers Outbreak Why Was Service Worker Merged into Create React App? EmberConf 2016: Opening Keynote by Yehuda Katz & Tom Dale Picks Josh Justice: Sleeping Queens Sushi Go! Jamon Holmgren: Learn to code in 2020, get hired, and have fun along the way Charles Max Wood: Hiss King of Tokyo

amazon apple tokyo panelists refusal hiss pwa react native progressive web apps pwas opening keynote sushi go cachefly charles max wood create react app yehuda katz infinite red tom dale react native radio finding your dream developer job jamon holmgren maxcoders guide emberconf hisss

Khaled Garbaya on Gatsby, Create React App, modularity and more

That's my JAMstack

Play Episode Listen Later Feb 4, 2020

Quick show notes Our Guest: Khaled Garbaya | On Twitter: @khaled_garbaya What he'd like for you to see: Moving from create-react-app to Gatsby Course | JAMstack newsletter | Live streaming His JAMstack Jams: Gatsby | Netlify | Contentful His Musical Jam: Eminem's Latest album Our sponsor this week: TakeShape Transcript Bryan Robinson 0:01 Hello everyone and welcome to another episode of That's My JAMstack the podcast where we asked the pressing question, "What is your jam in the JAMstack?" I'm your host, Bryan Robinson. And this week I'm excited to have on the show the amazing Khaled Garbaya. Khaled is an engineering manager at Contentful and runs an amazing JAMstack newsletter. Bryan Robinson 0:20 We're also welcoming back this week TakeShape as our sponsor, stick around after the episode to find out more about their content platform or head over to takeshape.io/thatsmyjamstack for more information. Bryan Robinson 0:34 Thanks for being on the show today, Khaled. Khaled Garbaya 0:35 Hey, thanks for having me. Bryan Robinson 0:38 So tell us a little about yourself. What do you do for work? What do you do for fun, all that stuff. Khaled Garbaya 0:43 So my name is Khaled. I'm originally from Tunisia, which is like a small country in the North Africa. And it's been I've been living in Berlin for over six years now. I am an engineering manager at Contentful And I love learning and building and public. And I also traveled for food. So that's that's usually my life. Yeah, that's, that's basically me. Khaled Garbaya 1:17 I started, I don't know if this is relevant or some people might not even remember the days of Flash. So I started as a Flash developer and moved my way there to like gaming and then now it's more like web and servers and now people debugging people instead of code, which is also a lot of fun. Yeah, and I do also like some live streaming, and I teach some web development related and JAMstack related topics over on Egghead or YouTube or I also do some streaming in Twitch so I'm all over the place. Bryan Robinson 1:57 Cool. Make sure you give me those links. I'll pop them in the show notes. You say you, you travel for food? So how much are you traveling and maybe what's your What's your favorite country or city for food? Khaled Garbaya 2:10 I mean, my favorite city is definitely Italy so far. I mean, not city but like an entire country. Yeah, my, the best city like I go there every year. We must go there at least for a week. It's Sardinia it's like a small island in Italy by the beach, and there's some great food and I want to be like always, like relax. So that's my style of vacation. I'm no hiker, or I do sometimes, but I'm just I'm lazy. I don't want to do a lot of activities. Bryan Robinson 2:45 I can definitely get that I spent a week in Italy and did way too much and would rather just relax on the beach. Khaled Garbaya 2:53 Yeah, so I visited few cities hunting for food. Napoli also I went to the Holy Land of pizza. Rome is kind of an open museum. It's an amazing country to music also my country's full of food. So it's a nice to always visit family and have some food. Whereas I went to the US few, like two times, but just San Francisco. I don't know. I mean, usually, it maybe it's not the US. Bryan Robinson 3:25 Sure. Khaled Garbaya 3:26 And yeah, traveling through Europe because it's, I mean, Europe here is like, very accessible and easy to go through. It's not like 10 hours flight. I think the furthest country was Japan. Last year, it was like magical. Bryan Robinson 3:44 Very cool, whole, whole whole different kind of plane existence in a lot of ways. Bryan Robinson 3:49 Cool. So So let's talk about the JAMstack a little bit. So what was your kind of your entry point into this philosophy, whether that's JAMstack itself nowadays or static sites? Where did you start in this Khaled Garbaya 4:00 Yeah, so I had a blog and WordPress. I mean, this is sounds like you will hear the story a lot. When I didn't have time to, like, maintain it. There was a lot of bots, hosting a lot of files on my website. And it wasn't just like, I mean, I'm getting like 100 views a month on this blog post, why why do I bother even maintaining this stuff? And also open source like, I think the when, when JAMstack started rising like two, three years ago, I got involved a lot on open source, mainly with the Gatsby. So I was I did some pull requests to help the integration with Contentful to be like a little bit faster. And then I like fixed few stuff here and there. And they were like the Gatsby team was amazing and friendly. And my wife decided to build a food blog. So I was like, Yeah, okay, I was trying to save my marriage basically. Yeah, so I built her that blog and I kind of like geek out about it I use it like as a test space to try all of these stuff and then yeah, if I'm like very powerful low maintenance and also like low costs so I went all in in there and and started to explore it more and how to go beyond the static site basically. That's more what my god what like where my curiosity went. And yeah, since then, I'm a big fan of the JAMstack. Bryan Robinson 5:42 So So obviously, if you're at Contentful, JAMstack kind of a professional thing, too. But like, yeah, how we're using it there. How are you using it maybe beyond that food blog, or even what's kind of the stack for that food blog and you're in your hat personal endeavors? Khaled Garbaya 5:57 Yeah. So In Contentful, first I joined as a software engineer, mostly maintaining the SDK, and a lot of tooling, and most of it was open source. So it was like, oh, amazing, it can be like, I can get paid and then work on open source. And from there, like the involvement of Contentful, and the integration isn't all of these stacks started to appear to help here and there and the direct people, and so on. And to talk about like, usually my stack would be Gatsby. Because I know there's like many other options over there. But that's why I got used to and kinda like my comfort zone now and I know it very well. So that's what I start with. Netlify for hosting. I used to host stuff over at S3 and cloud like cloudfront. Khaled Garbaya 6:56 But then once I learned all of that, I was like, Okay, now let's Move to something easy Yeah, I use algolia for search. That's also really nice Netlify some several as functions I recently also use the Identity Service by Netlify. There's also like some other options like Auth0 which is really great and I think it generous. They give you a generous free offer for like users and so on but I don't have like that many users so I went with Netlify like a thousand I think it's more than enough for me and because it integrates well with like the whole hosting service and they can do a lot of powerful configurations through Netlify it made it made more sense. What else? Yeah, I'm I can't remember something But I'm definitely going to use a lot more API's Bryan Robinson 8:04 Definitely. And so that's a lot of technologies. What would you say is kind of like your one jam in the jam stack? What's that technology that you're always going back to the Gatsby? Khaled Garbaya 8:13 Yeah, I think it's it's it's Gatsby and Netlify these are like the my Gatsby, Netlify and then Contentful because I can also like bootstrap my content really quickly. And I can give it to someone that they are not technical and can they can write stuff in there. And I also like geek about like, this content modeling in general, because it's like it's a big topic. And me so I that's like the my top three stack always because you need them most of the time, you will need content. So I'd rather give it to someone who knows well about content and they like they have a platform for that already. Bryan Robinson 8:54 Sure. They like the contents that they type in some stuff. They click Save, and they're good to go. Cool. So you just wrote an article at the beginning of this year right on Gatsby as a as a replacement for Create React App. Yeah. So let's talk about that a little, because I'm interested in that. Khaled Garbaya 9:10 Yeah. So I like like I told you, I was curious overall in the JAMstack, how to go beyond, like a normal use case, like a blog or a marketing website, and so on. Because I think it's over. It's like, very powerful. It's, you can do more than that. And with Gatsby, which a lot of people they get wrong is like, yeah, it's another static site generators. But it's, it's more than that. Khaled Garbaya 9:38 So it will give you like a pre rendered website. But then once it's fully loaded, it will load also react and rehydrate everything to react app. So basically, you have this powerful app that's sitting there doing nothing, just displaying, you know, and also like bootstrapping Gatsby, what site and the whole plugin ecosystem. It's really powerful. So I was like, let's try build an app with Gatsby and not like, React create react app. And what I found there is like, I built the first like, kind of small Twitter clone using react. And I was like, Okay, let's try and see how how much go they can just copy paste from here to there. And it was like, sometimes it's like, the entire component, just copy paste it there. Khaled Garbaya 10:34 A few things to consider like the window object, when you when, when the process of statically generating the website kicks in, that's like a Node process. So the, the window object doesn't exist there. But other than that, you can use all the great features of react, you can use hooks you can use a lot of things. I mean, except suspense, because It's still not ready for, I guess, for us it and I don't know how long it would take. But looking forward to that. But also, I mean, since its react and JavaScript, you can load some more data. If you have a like dynamic stuff. Gatsby also has a powerful like API for creating pages. So you can create static pages, you can create dynamic routes. And since you you're able to use dynamic routes, and you can use actually reach router, which is embedded in there. Khaled Garbaya 11:35 You could do stuff like authentications, because all these routes will not get rendered as static, like set equation, because it doesn't make sense to render dashboards for every user that you have. That's not that's not the case. So using that and the combination of different API's and if you have for example, like payments I don't know like Stripe now is a great example for that. The way it works, they give you like a public key and a secret key. So you can use the public key in your front end, and that's fine. And then if you want to capture a payment, you can get some token and send it to your API. Khaled Garbaya 12:20 In this case, it will be like a serverless function using Netlify, and you can like capture the payment and you can do a lot of that. So I was like, asking over and Twitter like, hey, like, what's what's wrong while you're not like building with with a gaspee? And it turns out like a lot of people actually, either they had like a misunderstanding about like, the whole gaspee thing, or they actually building some apps with that and so on. So yeah, so I wrote that blog post about about that. And I'm actually like building a course around the the whole thing I'll send you the link later. And we can add it to the, to the show notes. Yeah. And then I will just break down the whole thing like starting from scratch, like how do you even start the website without even like using Gatsby to generate the templates? And how simple it is, and then we can go from there. Bryan Robinson 13:23 So I'm kind of curious. So, you know, obviously Gatsby is relatively strongly opinionated. Like, there's the Gatsby way of doing react and arguably is one of the better ways of doing react. I don't have a lot of experience with create react app. Is that that opinionated or is it more of like a "Here's some bootstrapping now you go do whatever you want." Khaled Garbaya 13:41 Yeah, I think I think there's some opinion in every tool and that's sometimes good. I think most of the time is good, because if you remember the old days with react, you need to do like Webpack and like, do some configurations and then all I need this loader and that loader and so on. So both Gatsby and react create react app, they solve this problem. They remove the whole, like the whole headache of like building an app. They make you focus on just react, how to build react, create react app, like the end result will be a react app. Khaled Garbaya 14:22 But Gatsby will be like more than that. So it'll be a static site that will transform later into react app. And, and then it doesn't also like stop there. So it gives you like another data layer, which is graph QL. And you can inject any data from any source in there. And that's a really mean graph girl proved to be like a great developer experience and user experience in general. And yeah, but the Create react app I think is like makes your life simpler when bootstrapping an app, have it running. You can totally build an entire app. That's fine. But it doesn't give you like, more. Bryan Robinson 15:06 I gotcha. So if you're making this like a really small app, you might still stick with create react app, but anything beyond that a little bit, you're gonna want go gafi route. Yeah, Khaled Garbaya 15:15 yeah, yeah, I mean, it depends always, like what I say always depends on your use case. Because I'm not just I'm not trying to bash any tool. Everything's like super great. You know, like, when you start this conversation over Twitter, people, like just jump in, you're like, Oh, my God, what are you saying every time? Yeah, it depends on the use case. But I think, since they offer, like the offer, like kind of equal experience at the beginning, why not starting with with Gatsby and and then in the future, if you need to get some more data or like, integrate an API. I mean, you can you can do it. Bryan Robinson 15:57 Nice. So I I've actually I've only done like, surface layer Gatsby stuff. I've created a couple of like small static sites and that sort of thing. Are there any Is there anything to be aware of as you kind of try to take it outside of that static rendering and move it in into like that rehydration process? Khaled Garbaya 16:12 Yeah. So that's mostly kind of done by Gatsby like the Gatsby runtime. One thing is some people, sometimes I see a lot of people asking like, oh, how do I do private routes? And Gatsby, or how do I do this and Gatsby? And actually, that question should be like, how do I do this in react? Because that's actually like a react app. Like you're dealing with react components? A few things like a gotchas. And all like the like I said, the window object. Yeah, the windows object. Sometimes you might be loading some apps that rely also on the window object, but you can in the Gatsby node, you can say, hey, what if you're loading this at in the SSR Phase ignore it or make it an empty modules yeah there's few things here there to watch out for while building but mostly also like you need to think about your your structure of the website what's what's what's really need to be dynamic and what what needs to be like static, like an about page or contact page or contact page. Yeah, maybe but that's also still kind of be can be static, and then inject few stuff in there. And then what's like dynamic and what do you what stuff you don't want to do. And also like Watch out from plugins, or wise Don't be like adding plugins left and right. Because again, it will be like, sometimes painful, a little bit painful when it comes to maintaining all of that. Yeah, and then push as much as you can at build Like the work you do the data processing and stuff, give to the user like a relaxed app, kind of like don't stress the app to show some user. Bryan Robinson 18:10 Yeah, a good progressive enhancement kind of ideology there. Cool. So kind of going forward, you know, next three or four years. Where do you kind of see the tech stack going in a way that's going to keep you in the JAMstack? Obviously, you're doing a lot of stuff in it right now. What's gonna keep you coming back year after year? Khaled Garbaya 18:30 I think modularity. That's that's one thing. I like that every API and product or any company that's producing that they're only focusing on one thing, and that's proven to be always great. Like focusing on one thing and doing really great. I love like, hand handing over a lot of work to experts to do that for me. Yep, so yeah. As long as that's the idea and also also like about the community and it needs to be like an inclusive community and inviting more and more people to contribute and build nice tools in there. Yeah, that that's what keeps me there. What keeps me in the jam stack. And I'm not usually driven by hypes I love to kind of, because there's a lot of hype around like new tools and so on, I use only what I need. And jam stack allows me to do that. And I can replace some components with something else really quickly. And that's going back to the modularity. So that's what I like about Bryan Robinson 19:41 who I am when one new like hyped up thing goes from being hyped to being actually good and you know, ready for production, then you can just switch that into as you go on. Khaled Garbaya 19:50 Yeah, yeah. Yeah. I mean, I can also like, even if I like the idea behind it, I might experiment with it before. Yeah, I like to I mean us things and then I don't really like bash tools on online and I have strong opinions because I was like, yeah, it's assuming the best intention always this is probably solving a problem for someone else. Not me. So I use it if it makes sense. I can include it. Otherwise I can just move on. Bryan Robinson 20:19 Nice. So So JAMstack aside, what is your what's your jam and like in your ears right now? What's your jam in music? Khaled Garbaya 20:26 Oh, man, um, the new Eminem album is nice is on fire. I think is is passing Kanye West. Kinda. Yeah, but I also like, listen to Cardi B. I like some some sort of, you know, rap and hip hop and stuff. Sometimes. I don't know like, It's weird. Like these old suggestions from Spotify. I just listened to them. Yeah, I listened to whereas like, sometimes Ed Sheeran, there's like some some cool songs. He did one with Eminem. I mean, I'm like, I'm like from the 90s. So I listen a lot. And, like, I'm kind of a little bit of old school and yeah, whatever. Spotify tells me to listen, sometimes I was just like, ok Bryan Robinson 21:17 yeah, give the music over to the to the algorithm and say, give me what's best for me. Khaled Garbaya 21:26 Yeah, make sure to listen to few music I like and then the rest will come. Bryan Robinson 21:30 Exactly, exactly. Our robot overlords are taking care of you. Khaled Garbaya 21:34 Yeah, exactly. Bryan Robinson 21:36 Nice. So is there anything that you want promote and get out there to the JAMstack community? Khaled Garbaya 21:40 Yes. Uh huh. Let's see. So, currently, back to the topic of the Create react app, and Gatsby. I'm doing a live stream every day for like an hour, we are actually building an app called RubberGoose.dev. So you know the concept of rubber ducking? Yeah. So I think the name rubber duck is like trademark to something, so someone was like, yeah, maybe rubber goose. And yeah, the app is live. And we already made some great progress there. There's a landing page is capturing email, push it to Convert Kit. It has authentication, it has stripe billing, and plans or subscription all of that. And I didn't even build the content of the app. I was like, the stripe stuff so that you can find it over twitch.tv/kgarbaya. Or if you follow me at Twitter, which is @khaled_garbaya. Khaled Garbaya 22:56 And yeah, and if you Go over sort learnjamstack.com I'm running a weekly digest for like some nice resources I find useful. In there also, on the top, you'll find a banner getting you to like the course if you want to get some, like some info about the course of the progress, I share some nice free previews and materials already about that. Yeah, and my website is k4d.dev. So I was like, you know, the four letters and between the K and D. I was like, like the Kubernetes or something. So yeah, that's like, my main website. So yeah, I guess if you follow me on Twitter and like, look around, you can find all the other links. Bryan Robinson 23:49 Sure. Awesome. Well, I really appreciate you being on the show today and sharing your your expertise around great react app versus Gatsby and all that good stuff. And thanks for doing And all the cool educational resources you've been putting out there. Khaled Garbaya 24:02 Yeah, man. That's my pleasure. Thanks for having Thanks for having me. Bryan Robinson 24:08 Hey, everyone, it's Bryan again. And it is time to talk about this week sponsored TakeShape. They're a really well crafted content platform made specifically for the JAM stack. So what's a content platform? Well, take shape doesn't just provide a CMS, though, you can certainly just use their CMS if that's all you're interested in. They also have a static site generator, a GraphQL API. And this really cool new Mesh product just growing by the day, which you can use to combine multiple API's into one really easy to use GraphQL-based API. So if those things strike your fancy, and for me, most of them do on one level or another, head on over to takeshape.io/thatsmyjamstack to sign up. Bryan Robinson 24:48 And of course, don't forget to star heart favorite, subscribe, all those lovely things so that more people can find out about the amazing work that we're all doing in this great JAMstack community. So until next week, keep doing Amazing things on the web and keep things JAMyTranscribed by https://otter.aiIntro/outtro music by bensound.comSupport That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

Show 200!

Play Episode Listen Later Nov 27, 2019 73:54

In this episode of Syntax, Scott and Wes celebrate 200 episodes of Syntax with a live Q&A! LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It’s an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Sanity - Sponsor Sanity.io is a real-time headless CMS with a fully customizable Content Studio built in React. Get a Sanity powered site up and running in minutes at sanity.io/create. Get an awesome supercharged free developer plan on sanity.io/syntax. Show Notes 2:27 - With 2020 around the corner, what are your wild predictions for the the future of web design and development? 8:44 - Are site builders going to replace us as web developers? 13:30 - What does the future look like for Syntax? 19:01 - What emerging tech advancements most excite you for the next 5-10 years? 23:27 - What is the future of web hosting? What should hosting companies do differently? 27:40 - Why do you set your base font size to 10px? 32:40 - If you could go back in time, what would you say to yourself? 36:29 - How do you make an iFrame go 100% high? 39:10 - What’s one thing you see developers stress out about for no reason? 44:46 - Do you feel overwhelmed with creating new content when there’s so much already out there? 48:42 - How do you stay sane with your naming conventions? 51:15 - If Gatsby is best for static websites and Next is best for apps, how does Create React App compare? 54:30 - How much is too much or too little magic in a framework or library? 58:11 - Does Kait ever get tired of you buying a bunch of stuff? 61:45 - What is your office setup? 64:01 - How long until we can use Suspense for data loading with libraries other than Relay? Links Pigeonhole Keystone VulcanJS NextJS Gatsby Meteor Wix Squarespace Modulz Figma Sketch Framer Netlify dnsimple Digital Ocean AWS Heroku Syntax016: Rems vs Ems Seth Godin Notion Laravel Blaze Relay SWR Suspense Project Farm YouTube Channel ××× SIIIIICK ××× PIIIICKS ××× Scott: The Missing Crypto Queen Wes: Bosch Wiper Blades Shameless Plugs Scott: React and Typescript Wes: Beginner Javascript Black Friday Sale - Get 50% off! Scott’s Courses Wes’ Courses Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

react sanity suspense cms syntax content studio iframe create react app

Learning by building a TODO App with all the bells and whistles with Lee Warrick

Developer Side Quests: The Podcast

Play Episode Listen Later Jul 29, 2019 46:23

Guest Bio Lee Warrick is a multitasking bard with many feathers in his cap. Truly a jack-of-all trades and master of none, Lee has worked as a firefighter and nurse before changing jobs to web development where he now works as a Front-end Developer, using his Bardic charms to enchant his audience with sizzling CSS and jumping JavaScript tunes. Not satisfied with focusing only on his own quest as a developer, Lee formed a guild for fledgling developers in the form of the Project Codex Meetup in Orlando, FL, where he works tirelessly to support the membership with inspirational and educational talks and workshops. To extend that support even further beyond Orlando, Lee teamed up with Eddie Otero to spin epic yarns coding quests they've tackled, as well as those of other developers on the Tech Jr podcast. What was the quest? I wrote leewarrick.com/Goaler as my own personal todo app over last winter break in React/Firebase. I've been slowly adding tweaks and updates as my own use cases change. Basically I wanted a no-nonsense todo app with that I could braindump all the stuff I have to do instead of keeping it in my head. Then I wanted to keep myself accountable so I assigned a countdown time to each task. It sorts tasks by due time or by last added. Beyond that I added functionality to group tasks under multi-step goals, since some things are too complex to be handled in one step. Links: - Twitter: @leewarrickjr, @TechJrPodcast - E-Mail: leewarrickjr@gmail.com - Websites: - https://leewarrick.com - https://techjr.dev - https://leewarrick.com/goaler - https://leewarrick.com/babelfish - Meetup: https://meetup.com/project-code-experience - "Create React App" tool: https://github.com/facebook/create-react-app - Wes Bos: https://wesbos.com/ Special Guest: Lee Warrick.

learning interview software front developers programming websites bells meetup javascript master of none css software development whistles warrick bardic wes bos create react app

AMA: create-react-app vs Next.js vs Gatsby.js

3 Minutes with Kent

Play Episode Listen Later Apr 30, 2019 2:47

#680 (https://github.com/kentcdodds/ama/issues/680)

gatsby create react app

11. The Agony and Ecstasy of Maintaining Good Documentation

Code[ish]

Play Episode Listen Later Apr 29, 2019

With the explosive growth of people using, and contributing to, open source projects over the last decade, more and more of us are spending their time reading, writing, and understanding documentation. Heroku's Dev Center is the central hub of documentation for Heroku, covering everything from getting started, to how Heroku works, to extending the platform. It acts as a manual for the entire platform, spanning an enormous number of topics and tools. Stephen Barlow, lead strategist for Dev Center, joins Heroku designer / developer Charlie Gleason to discuss why good documentation is so important—from some of the common challenges you and your team might face while writing them, to advice for rationalising and improving your documentation workflow. Tune in to learn why good docs aren't just good—they're great. Links from this episode Heroku Dev Center Heroku Buildpacks Rust Create React App Write The Docs Conference Prettier Typescript Git hooks and Husky Runbooks Heroku Changelog Stack Overflow

maintaining rust agony ecstasy documentation husky git stack overflow typescript heroku prettier create react app runbook stephen barlow

16 выпуск 07 сезона. Ruby 2.6.3, Create React App v3, Pattern matching in Ruby, Reattempt, JavaScript For Cats и прочее

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Apr 22, 2019 46:15

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.6.3 Released, Ruby Repository Moved to Git from Subversion, Update your nokogiri gem to 1.10.3, Rails 6 adds implicit_order_column, Rails 6 allows configurable attribute name on has_secure_password, Rails 6 allows to override the ActiveModel::Errors#full_message format at the model level and at the attribute level, Ruby3 will have types и Pattern matching - New feature in Ruby 2.7 Optimizing Database Performance in Rails, Qo - Query Object - Pattern matching and fluent querying in Ruby и Awesome Types & Type Signatures / Annotations for Ruby Web Create React App v3, A horrifying globalThis polyfill in universal JavaScript, Simulating Mouse Movement и A Closer Look at React Memoize Hooks: useRef, useCallback, and useMemo useHooks - easy to understand React Hook recipes, Fading out siblings on hover in CSS, Data Structures and Algorithms in JavaScript, Reattempt - a library lets you retry asynchronous functions when they fail и JavaScript For Cats

cats released algorithms pattern javascript rails fading css git subversion data structures pattern matching ruby ruby create react app

VoV 045: Comparing the React and Vue Ecosystems with a Real-World SPA with John Datserakis

Play Episode Listen Later Jan 23, 2019 76:41

Sponsors: KendoUI Sentry use the code "devchat" for $100 credit TripleByte Panel: Divya Sasidharan Erik Hanchett Chris Fritz Joe Eames John Papa Charles Max Wood Special Guest: John Datserakis Episode Summary In this episode of Views on Vue, the panelists talk to John Datserakis, a full stack developer from North Shore Massachusetts. John has been programming for 9 years and works for Promosis, Inc. a company that develops and designs sweepstakes programs and other marketing tools. After leaving jQuery, John wrote a detailed tutorial comparing Vue and React. He felt that there weren’t enough tutorials available that show the issues developers face while coding in real time. With this tutorial he wanted to go through all the challenges a developer can face while learning a new framework from scratch. Comparing his favorite and least favorite parts using React, he mentions he didn’t “fall in love with it” enough to leave Vue. John then compares his experiences with Create React App and Vue CLI and talks about his most recent project, Best Meta which helps pick the most popular items on Amazon. John also talks briefly about his experiences using Vuex and Redux. Writing the detailed comparison tutorial helped John sharpen his JavaScript skills but he reveals that, at the end of the day, he will use Vue for his next project. Links Vue.js React.js John's GitHub John's Twitter John's LinkedIn Promosis, Inc. https://webpack.js.org/ https://angular.io/cli/update https://cli.vuejs.org/ https://redux.js.org/ https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue John's Recent Project: Best Meta John Datserakis' Article - Comparing Vue and React John Datserakis’ open-source projects on GitHub that pertain to the article: koa-vue-notes-api koa-vue-notes-web koa-react-notes-web John Datserakis' Other Recent GitHub Projects: vue-simple-context-menu vue-cookie-accept-decline vue-programmatic-invisible-google-recaptcha Picks John Papa: A book by Chris Noring on React Chris Noring's Twitter Divya Sasidharan: Framework Summit Sarah Drasner’s Workshop Design for Developers Ghost Erik Hanchett: AWS Amplify Chris Fritz: Google Fi Referral Code Ball Lightning by Cixin Liu FrontendMasters Joe Eames: ng-conf Minified – YouTube Framework Summit John Papa - AngularConnect Charles Max Wood: Eleventy Nunjucks John Datserakis: John's Recent Project: Best Meta Netlify Anthony Gore's Website

amazon ghosts writing fall in love panel views comparing developers react real world redux github javascript ecosystems vue sentry jquery netlify cixin liu eleventy ball lightning aws amplify charles max wood john papa triplebyte create react app sarah drasner kendo ui vue cli chris fritz joe eames divya sasidharan framework summit

VoV 045: Comparing the React and Vue Ecosystems with a Real-World SPA with John Datserakis

Views on Vue

Play Episode Listen Later Jan 23, 2019 76:41

Sponsors: KendoUI Sentry use the code "devchat" for $100 credit TripleByte Panel: Divya Sasidharan Erik Hanchett Chris Fritz Joe Eames John Papa Charles Max Wood Special Guest: John Datserakis Episode Summary In this episode of Views on Vue, the panelists talk to John Datserakis, a full stack developer from North Shore Massachusetts. John has been programming for 9 years and works for Promosis, Inc. a company that develops and designs sweepstakes programs and other marketing tools. After leaving jQuery, John wrote a detailed tutorial comparing Vue and React. He felt that there weren’t enough tutorials available that show the issues developers face while coding in real time. With this tutorial he wanted to go through all the challenges a developer can face while learning a new framework from scratch. Comparing his favorite and least favorite parts using React, he mentions he didn’t “fall in love with it” enough to leave Vue. John then compares his experiences with Create React App and Vue CLI and talks about his most recent project, Best Meta which helps pick the most popular items on Amazon. John also talks briefly about his experiences using Vuex and Redux. Writing the detailed comparison tutorial helped John sharpen his JavaScript skills but he reveals that, at the end of the day, he will use Vue for his next project. Links Vue.js React.js John's GitHub John's Twitter John's LinkedIn Promosis, Inc. https://webpack.js.org/ https://angular.io/cli/update https://cli.vuejs.org/ https://redux.js.org/ https://www.facebook.com/ViewsonVue/ https://twitter.com/viewsonvue John's Recent Project: Best Meta John Datserakis' Article - Comparing Vue and React John Datserakis’ open-source projects on GitHub that pertain to the article: koa-vue-notes-api koa-vue-notes-web koa-react-notes-web John Datserakis' Other Recent GitHub Projects: vue-simple-context-menu vue-cookie-accept-decline vue-programmatic-invisible-google-recaptcha Picks John Papa: A book by Chris Noring on React Chris Noring's Twitter Divya Sasidharan: Framework Summit Sarah Drasner’s Workshop Design for Developers Ghost Erik Hanchett: AWS Amplify Chris Fritz: Google Fi Referral Code Ball Lightning by Cixin Liu FrontendMasters Joe Eames: ng-conf Minified – YouTube Framework Summit John Papa - AngularConnect Charles Max Wood: Eleventy Nunjucks John Datserakis: John's Recent Project: Best Meta Netlify Anthony Gore's Website

amazon ghosts writing fall in love panel views comparing developers react real world redux github javascript ecosystems vue sentry jquery netlify cixin liu eleventy ball lightning aws amplify charles max wood john papa triplebyte create react app sarah drasner kendo ui vue cli chris fritz joe eames divya sasidharan framework summit

Episode 52: Small, Sharp Developer Tools With Brian Hogan

Tech Done Right

Play Episode Listen Later Jan 2, 2019 41:30

Small, Sharp Developer Tools With Brian Hogan TableXI offers training for developers and product teams! For more info, visit http://tablexi.com.workshops or email workshops@tablexi.com. Guest Brian P. Hogan (https://twitter.com/bphogan): Editorial Manager for DigitalOcean (https://digitalocean.com), Author of Small, Sharp, Software Tools: Harness the Combinatoric Power of Command-Line Tools and Utilities (https://pragprog.com/book/bhcldev/small-sharp-software-tools), teacher, student, and musician. More info at bphogan.com (https://bphogan.com/). Summary Developers use a variety of tools other than their programming language to get their jobs done. This week, we talk about those tools with Brian Hogan, an Editorial Manager for DigitalOcean. Brian's a prolific technical educator, writer, and editor and he's currently the author of the book Small, Sharp, Software Tools (https://pragprog.com/book/bhcldev/small-sharp-software-tools) from the Pragmatic Press. We talk about why command line tools in particular are important, what command line tools do well, and why some people including myself often find them opaque and confusing. We talk about our favorite tools and about customizing your workflow to fit your needs. Notes 02:33 - Benefits to being comfortable on the Command Line Interface (CLI) Small, Sharp, Software Tools (https://pragprog.com/book/bhcldev/small-sharp-software-tools) Brad Urani, The Ruby Developer's Command Line Toolkit (http://confreaks.tv/videos/rubyconf2018-the-ruby-developer-s-command-line-toolkit) Noel Rappin, The Developers Toolkit (http://confreaks.tv/videos/rubyconf2018-the-developer-s-toolkit-everything-we-use-but-ruby) Developer's Toolkit Cheat Sheet (https://medium.com/@noelrap/developers-toolkit-cheat-sheet-82d98d34fde7) Create React App (https://github.com/facebook/create-react-app) A command that shows commonly used commands (https://twitter.com/samphippen/status/1017738991012114433) 09:43 - Concepts that people struggle with and don’t internalize 11:13 - ‘awk’ and ‘sed’ defined - awk (https://en.wikipedia.org/wiki/AWK) - sed (https://en.wikipedia.org/wiki/Sed) - Elixir (https://elixir-lang.org) - F# (https://fsharp.org) 14:48 - The Ethos of Cargo Culting Information - Z Shell (https://en.wikipedia.org/wiki/Z_shell) - Oh My Zsh (https://ohmyz.sh) - Makefile (https://en.wikipedia.org/wiki/Makefile) - Deckset (https://www.deckset.com/) - Noel's Deckset Editor (https://github.com/noelrappin/deckset_editor) 20:02 - Reminding Yourself to Use Tools and Shortcuts - Z Shell History Substring Search (https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/history-substring-search) - TextMate (https://macromates.com) 27:31 - Benefit to Setup/Cost Ratio - Bash prompt generator (http://ezprompt.net) - RB command line (https://github.com/thisredone/rb) 30:28 - Differences in Tools on Different Machines and Operating Systems 32:52 - Tools You Should Know Better - Rubular (http://rubular.com/) - regex101 (https://regex101.com/) - regex-railroad-diagram (https://atom.io/packages/regex-railroad-diagram) - entr (http://eradman.com/entrproject/) 37:29 - Practice as Continuous Improvement - Exercises for Programmers (https://pragprog.com/book/bhwb/exercises-for-programmers) Special Guest: Brian Hogan.

practice benefits tools differences benefit sharp concepts rb hogan ethos utilities programmers digital ocean software tools developer tools awk brian hogan editorial manager textmate create react app oh my zsh noel rappin brian p hogan

2. React med Linnéa Karlsson

UTVECKLA

Play Episode Listen Later Oct 29, 2018 36:22

I andra avsnittet av UTVECKLA diskuterar vi JavaScript-biblioteket React med vår egen expert på området – Linnéa Karlsson! Highligths: 00:26 Hej och välkomna! 04:12 Välkommen, Linnéa! 05:50 Vad är React? 20:48 Vilka typer av verktyg arbetar man med i React? 27:55 Hur ser framtiden för React ut? 31:09 Tipsa oss gärna! Ta gärna del av Linnéas länktips: Reactjs.org Getting started - Create React App Kontakta oss gärna på utveckla@consid.se och glöm inte att joina eftersnacksgruppen på Facebook! Vi vill också passa på att rikta ett stort tack till Lars Netzel - vår eminenta kollega som ligger bakom poddens episka jinglar!

react vilka javascript karlsson hej kontakta reactjs utveckla tipsa create react app highligths

18: create-react-app eli... CRAppi?

Webbidevaus.fi

Play Episode Listen Later Oct 14, 2018 58:19

Viikon huumoripainotteisen jakson aiheena create-react-appin kanssa eläminen ja kuoleminen. Antti ja Riku vastaavat myös yhteen (1) yleisökysymykseen. Juontajien pitäisi opetella tehokkaampaa ajankäyttöä. T: Shownotesien kirjoittaja. Eihän näitä ees lue kukaan. Pitäisköhän sitä kouluttautua uudestaan vaikkapa merisiilien kouluttajaksi. facebook/create-react-app wmonk/create-react-app-typescript Jakson valinnat Riku: Lambda Calculus https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=3VQ382QG-y4 Antti: Smashing Book 6

pit antti riku viikon eih create react app

RRU 014: Razzle with Jared Palmer

Play Episode Listen Later Jun 5, 2018 48:05

Panel: Nader Dabit Special Guests: Jared Palmer In this episode of React Round Up, the panel discusses Razzle and other projects with Jared Palmer. Jared is the lead engineer at The Palmer Group, where he spends his time building apps and services for companies that have been underserved by the recent technological changes. They talk about what Razzle is, the benefit of server-side rendering, and the difficulties he faced putting this project together. They also touch on why he chose to create Razzle and some of his other projects like Backpack and After.js. In particular, we dive pretty deep on: Jared intro How he got into programming Fell into programming by accident What is Razzle? Create React App with server-side rendering Gatsby Goal of Razzle What are the benefits of adding server-side rendering? The power of React Next.js React can hydrate once it renders on the server Razzle is thin layer around 2 Webpack watch tasks How do you handle routing? React Router After.js Performance pros to server-side rendering Is an app built in Razzle still considered a single-page application? React Resolver What were the technical difficulties putting Razzle together? Why made you want to create this? Wanted direct control over the project Backpack And much, much more! Links: The Palmer Group Razzle Create React App Gatsby React Next.js Webpack React Router After.js React Resolver Backpack The Palmer Group GitHub Jared’s Medium Jared’s GitHub @jaredpalmer Sponsors Kendo UI Digital Ocean FreshBooks Picks: Nader Proton Native Jared Guess.js Garden

performance gardens goal medium panel wanted react fell special guests github backpack gatsby nader freshbooks digital ocean webpack razzle nader dabit create react app react router palmer group kendo ui react round up jared palmer

RRU 014: Razzle with Jared Palmer

Play Episode Listen Later Jun 5, 2018 48:05

Panel: Nader Dabit Special Guests: Jared Palmer In this episode of React Round Up, the panel discusses Razzle and other projects with Jared Palmer. Jared is the lead engineer at The Palmer Group, where he spends his time building apps and services for companies that have been underserved by the recent technological changes. They talk about what Razzle is, the benefit of server-side rendering, and the difficulties he faced putting this project together. They also touch on why he chose to create Razzle and some of his other projects like Backpack and After.js. In particular, we dive pretty deep on: Jared intro How he got into programming Fell into programming by accident What is Razzle? Create React App with server-side rendering Gatsby Goal of Razzle What are the benefits of adding server-side rendering? The power of React Next.js React can hydrate once it renders on the server Razzle is thin layer around 2 Webpack watch tasks How do you handle routing? React Router After.js Performance pros to server-side rendering Is an app built in Razzle still considered a single-page application? React Resolver What were the technical difficulties putting Razzle together? Why made you want to create this? Wanted direct control over the project Backpack And much, much more! Links: The Palmer Group Razzle Create React App Gatsby React Next.js Webpack React Router After.js React Resolver Backpack The Palmer Group GitHub Jared’s Medium Jared’s GitHub @jaredpalmer Sponsors Kendo UI Digital Ocean FreshBooks Picks: Nader Proton Native Jared Guess.js Garden

performance gardens goal medium panel wanted react fell special guests github backpack gatsby nader freshbooks digital ocean webpack razzle nader dabit create react app react router palmer group kendo ui react round up jared palmer

RRU 009: Hot Reloading in Create React App with Dave Ceddia

Play Episode Listen Later May 1, 2018 53:54

Panel: Charles Max Wood Tara Manicsic Special Guests: Dave Ceddia In this episode of React Round Up, the panel discusses hot reloading with Create React App with Dave Ceddia. Dave is a React developer, blogs about React, and recently wrote a book called Pure React. They talk about what hot reloading is, when you would want to use it, and how you can set it up in your code. They also touch on ways to customize Create React App, the disadvantages to customizing, and the key points to understand about Create React App before modifying it. In particular, we dive pretty deep on: Dave intro What is the big picture behind hot module reloading? Create React App Webpack How do you set this up? You don’t need to eject Is there a certain point when you need to start taking advantage of hot reloading? Helps to use hot reloading from the beginning Resources to help with using hot reloading Dave article React app rewired Are there any changes you can make that won’t hot reload? Full page refreshes Why did Create React App not have this from the beginning? Having a skeleton that you can break Webpack HMR vs React-Hot-Loader by Mark Erikson Event handlers Are there other ways you can customize Create React App? Sass Key points to Create React App to understand Try to avoid modifying it if you can And much, much more! Links: React Dave’s Blog Pure React by Dave Ceddia Create React App Webpack Dave article React app rewired Webpack HMR vs React-Hot-Loader by Mark Erikson Sass @dceddia Dave’s GitHub DevChat.tv Patreon DaveCeddia.com/RoundUp Picks: Charles Star Realms Vail If you have an idea about a podcast, he is willing to hear them out JavaScript YouTube videos to come at DevChat.tv YouTube Tara Patreon Dave React Boston Indie Hackers

event blog helps panel react special guests github roundup sass vail reloading indie hackers star realms webpack devchat charles max wood create react app react round up mark erikson pure react react hot loader

RRU 009: Hot Reloading in Create React App with Dave Ceddia

Play Episode Listen Later May 1, 2018 53:54

Panel: Charles Max Wood Tara Manicsic Special Guests: Dave Ceddia In this episode of React Round Up, the panel discusses hot reloading with Create React App with Dave Ceddia. Dave is a React developer, blogs about React, and recently wrote a book called Pure React. They talk about what hot reloading is, when you would want to use it, and how you can set it up in your code. They also touch on ways to customize Create React App, the disadvantages to customizing, and the key points to understand about Create React App before modifying it. In particular, we dive pretty deep on: Dave intro What is the big picture behind hot module reloading? Create React App Webpack How do you set this up? You don’t need to eject Is there a certain point when you need to start taking advantage of hot reloading? Helps to use hot reloading from the beginning Resources to help with using hot reloading Dave article React app rewired Are there any changes you can make that won’t hot reload? Full page refreshes Why did Create React App not have this from the beginning? Having a skeleton that you can break Webpack HMR vs React-Hot-Loader by Mark Erikson Event handlers Are there other ways you can customize Create React App? Sass Key points to Create React App to understand Try to avoid modifying it if you can And much, much more! Links: React Dave’s Blog Pure React by Dave Ceddia Create React App Webpack Dave article React app rewired Webpack HMR vs React-Hot-Loader by Mark Erikson Sass @dceddia Dave’s GitHub DevChat.tv Patreon DaveCeddia.com/RoundUp Picks: Charles Star Realms Vail If you have an idea about a podcast, he is willing to hear them out JavaScript YouTube videos to come at DevChat.tv YouTube Tara Patreon Dave React Boston Indie Hackers

event blog helps panel react special guests github roundup sass vail reloading indie hackers star realms webpack devchat charles max wood create react app react round up mark erikson pure react react hot loader

JSJ 304: React: The Big Picture

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Mar 13, 2018 51:00

Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

lack panel reason react special guests big picture redux javascript elm angular pluralsight hunting hitler charles max wood create react app mobx aimee knight javascript jabber joe eames using react react round up cory house framework summit react dev summit

JSJ 304: React: The Big Picture

Play Episode Listen Later Mar 13, 2018 51:00

Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

lack panel reason react special guests big picture redux javascript elm angular pluralsight hunting hitler charles max wood create react app mobx aimee knight javascript jabber joe eames using react react round up cory house framework summit react dev summit

JSJ 304: React: The Big Picture

JavaScript Jabber

Play Episode Listen Later Mar 13, 2018 51:00

Panel: Charles Max Wood Aimee Knight Joe Eames Cory House AJ O'Neal Special Guests: None In this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components. In particular, we dive pretty deep on: What is React: The Big Picture course? React The frameworks work with each other Reason and Elm How to decide when using React is the best option? React tradeoffs JavaScript React expects you to do a little more typing and work React is very close to JavaScript React pushes you towards a single file per component React Round Up Are the Code Mods as wonderful as they sound? Angular Create React App What are Code Mods? Lack of opinionated approach in React Using React in a more consistent way MobX and Redux Start off using just plain React When wouldn’t you want to use React? And much, much more! Links: React: The Big Picture Cory’s Pluralsight Reason Elm React JavaScript React Round Up Create React App Angular MobX Redux Framework Summit 2018 Angular: The Big Picture React Dev Summit Picks: Charles Hunting Hitler The Greatest Showman: Sing-a-long Aimee “Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin “How to understand the large codebase of an open-source project?” blog post Joe Marital Bliss Card Game AJ Pplwink.com

lack panel reason react special guests big picture redux javascript elm angular pluralsight hunting hitler charles max wood create react app mobx aimee knight javascript jabber joe eames using react react round up cory house framework summit react dev summit

34. Styles (CSS + JS)

The Rabbit Hole: The Definitive Developer's Podcast

Play Episode Listen Later Oct 31, 2017 30:22

Today on the show we welcome Ian McNally. Ian is a Software engineer specializing in the web. He currently works at Schoology as a UI architect, where he is helping shape and deliver their design system. Ian also actively writes on his blog, Ianmcnally.me, and contribute to open source projects like Create React App, Webpack, Storybook, and other personal projects.

software styles ui storybook webpack schoology create react app

MJS #022 Cory House

My JavaScript Story

Play Episode Listen Later Jun 21, 2017 46:31

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

MJS #022 Cory House

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jun 21, 2017 46:31

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

MJS #022 Cory House

Play Episode Listen Later Jun 21, 2017 46:31

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

Using ES6/7, create-react-app, and Electron! (JS Party #12)

Changelog Master Feed

Play Episode Listen Later Jun 1, 2017 65:05 Transcription Available

Mikeal Rogers, Rachel White, and Alex Sexton discuss how they’re using ES6/7 with and without a compiler, updates to create-react-app, and the beloved Electron.

web programming animation robotics iot javascript html css node backend frontend electron changelog rachel white es6 create react app mikeal rogers using es6

Using ES6/7, create-react-app, and Electron!

JS Party

Play Episode Listen Later Jun 1, 2017 65:05 Transcription Available

Mikeal Rogers, Rachel White, and Alex Sexton discuss how they’re using ES6/7 with and without a compiler, updates to create-react-app, and the beloved Electron.

web programming animation robotics iot javascript html css node backend frontend electron changelog rachel white es6 create react app mikeal rogers using es6

The React Universe - RRU 214

universe react dev typescript sveltekit create react app

Play Episode Listen Later Jan 1, 1970 48:17

Jack, Paige, and TJ join this week's panelist episode to tackle all things React and their take on different frameworks. They start off by talking about the pros and cons of "Create React App". They also discuss the Typescript 5.0 features and the SvelteKit, which was just released.On YouTubeThe React Universe - RRU 214SponsorsChuck's Resume TemplateDeveloper Book Club Become a Top 1% Dev with a Top End Devs MembershipLinksCreate React AppAnnouncing TypeScript 5.0 BetaSvelteKit@astrojs/react Astro DocumentationGatsby: The Fastest Frontend for the Headless WebNetlifyI Was Wrong About Nested React Components | YouTubePicksJack - Logitech MX Vertical Ergonomic Wireless MousePaige - Only Murders in the Building (TV Series 2021– ) - IMDbTJ - The Sixth Sense (1999) - IMDbAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

Jumpstart Your React Career With Collin Pfeifer - RRU 208