Taz Singh is the Founder of Guild. It is an all-in-one platform for Events, Presentations, and Discussions designed to reduce the burden as communities scale. He joins the show to talk about Guild and React Native. He begins by discussing his journey toward how he was able to create his company. He talks about their goals and what sets them apart from other platforms.  Additionally, they tackle developing applications using React Native. 

 

Hey, welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapir.

 

Hey from Tel Aviv!

 

We also have AJ O'Neill.

 

Yo yo yo, coming at you live from Snowflakes are Real and I never knew this!

 

I'm Charles Max Woods from Top End Devs. I grew up here, AJ. They've been here for a long time.

 

I've never seen- I've lived here for a decade. I've never seen a snowflake before. I didn't know they were real. I- I thought they were microscopic, but they're real.

 

Uh-huh. We also have a special guest

 

Thank you.

 

this

 

Bye.

 

week, and that is Taz Singh. Taz, do you wanna introduce yourself? Let us know who you are and why you're famous.

 

Well, I certainly hope I'll certainly be famous after this one. I'm Taz, yeah, I guess I'm South African, Canadian, now British, now living in London, UK. So I grew up

 

Oh

 

without

 

cool.

 

any snow, went to a whole lot of snow, and then went back to very little snow. So I can certainly relate that snowflakes are real. So I guess,

 

Nice.

 

last time I saw Dan, good to see you again, first of all, was back in Australia. We're both down there for Web Directions Conference. And so, yeah. snow either.

 

Yeah. Oh, actually, when we were in Tasmania during our tour around the country, there were, it was actually snowing a bit at one of the places that we were at, even though it was supposed to be summer. There you go.

 

Oh, well.

 

Yep.

 

So yeah,

 

I-

 

I was

 

I-

 

down

 

I-

 

there in this. I'll go ahead. Sorry.

 

No, I was gonna say, I've seen snow in the summer too, but that was in Alaska, so.

 

But yeah, we were both down there, Web Directions Conference, Sydney, I was speaking about kind of our exploration using React Native, React Native Web, React Native on every platform and kind of how we're building that for what I'm working on now at Guild. So yeah, happy to dive into that.

 

Yeah, that'd be awesome. To be honest, I think it might be interesting to kind of get into Guild and what it is and what problems you're trying to solve. And then that way we can understand what you're doing with React Native and React Native Web, if that makes sense.

 

Yeah, absolutely. So I guess to tell a bit more about that, I need to kind of rewind a little bit and tell you a bit more about

 

storytime.

 

myself and my passion. And so as I mentioned, I'm from South African, Canadian, British. I mean, I'm kind of three continents in one. And so I've been traveling around for quite a while. And kind of the thing that's grounded me has always been community and kind of people

 

Mm-hmm

 

and elevating each other through people and all of that. And so after I dropped that brought me back was the technical community. And I attribute a lot of my current success to that. And so 2010 Toronto, back in the days when backbone was just becoming a thing, jQuery was still relevant. Sorry, Dan.

 

Ha ha ha!

 

Ha ha ha 

And we're

 

Ha!

 

all making more and more. We're all adding more JavaScript to the web platform. Again, sorry, Dan.

 

Ha ha.

 

Back in those days, JavaScript was getting complex. I was often kind of looked at as, oh, you're a JavaScript developer. You aren't the real developer. You know, real developers program in C sharp and dot net and Java and all these types of things.

 

I feel

 

You're

 

this

 

just

 

so

 

a JavaScript

 

much.

 

developer. You know, yeah, like I'm sure I'm sure I've you gone through similar things, Charles. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

 

Yeah, yeah, with that or with Ruby.

 

yet.

 

Wait a minute, Ruby? Is Ruby supposed to be a real programming language? I forget.

 

Yeah, yeah, yeah, yeah.

 

It's

 

Rails

 

academic?

 

doesn't scale.

 

Ha ha.

 

Anyway.

 

Like the best part about Ruby is you can make it into whatever programming language you want.

 

That is true.

 

It's true.

 

Message

 

Ha ha.

 

Yeah,

 

Passing

 

the same,

 

and DSLs.

 

I think that that approach was innovated by LISP, which can literally be any programming language you want, as long as you like parentheses.

 

Yeah, well that's what Lisp stands for, right? Lisp stands for lost in secret parentheses.

 

Yes, exactly.

 

So that's kind of the ecosystem that I was often getting told back in 2010 as a Ruby and JavaScript developer. That's what I did back then. And

 

Mm-hmm.

 

so I said, you know what, like essentially we know how to make applications using JavaScript. We've made very complicated things. In fact, in my opinion, the front end really matters because if you have a bad front end, nobody's going to use your back end anyway. So even if you had

 

Right.

 

the best back end in the world, if you have a terrible front end, it doesn't matter. And so front end engineering really matters. Let's get everyone that's doing cool front-end stuff in Toronto together. Let's get us talking and let's discover and learn together amongst what we're doing. And so I started the Toronto Jobs Community way back then.

 

Thank you.

 

And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then. And so I started the Toronto Jobs Community way back then.

 

Yep.

 

Um, and yeah, and long story short, uh, over the years, you know, uh, tech talks, workshops, code clubs, um, hack days, um, you know, you name it from 2010 all the way up, um, just growing that community, learn the hard way of what it takes to run a community. All of the moderation concerns, funding concerns, finding venues, finding content, um, you know, it's tough. I'm sure, I'm sure for, for your podcast, um, I don't think there's any shortage these days, but maybe in you know, it's always tough to get something started, right?

 

So by community

 

Thank you. Bye.

 

you're talking like what meetups, events, conferences, get-togethers, what does running a community in this context actually mean?

 

Yeah, I think all of the above. So primarily a meetup group and kind of community events where folks would get together, yeah, I mean, socials where they just literally get together and hang out and kind of talk to each other, just obviously very socially. Tech Talk nights where there'd be someone on stage presenting about a talk or a concept they had workshops of someone in front of, I don't know, 30 to 50 developers, walking them through step by step where it takes to build something. And then Code Club nights You could just kind of show up informally, have a general idea when a hack on and then kind of drum up interest from other people there to hack on it. So Toronto GS had those four types of events on rotation. So you can imagine all the organizational overhead and challenges of running such a type of organization. But thankfully again, because we're community first, community run, it's just drumming up interest from the community and you know, fortunate Toronto is a big city. So it wasn't so bad doing that.

 

Thank you. Thank you.

 

Through that as well, also organized conferences. I think I think we I organized the largest JavaScript conference in the world at its time Which was back in

 

Ha

 

2014

 

ha.

 

a 700

 

Oh

 

developer

 

wow.

 

conference, which was the largest at its time. Yeah jQuery Toronto back when jQuery was still relevant in 2014,

 

Thank you.

 

of course

 

Jake where we will never die Jake where we will always be relevant

 

You know what's funny? We actually didn't have a single jQuery talk. Like

 

Although,

 

all the talks

 

although

 

were Ember,

 

I've moved,

 

Angular, everything else. Go ahead.

 

I've moved from jQuery to a jQuery.

 

AJQ.

 

Yeah, AJ knows what I'm talking about. We

 

It's

 

can

 

a

 

talk

 

real

 

about

 

thing

 

it.

 

I'll put a link in.

 

I love

 

Yeah, it's jQuery in two lines of JavaScript.

 

it.

 

Anyway, moving on. Ha ha. So, that's it. I hope you enjoyed this video. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed

 

So I'm not sure if you know like Tomasz Lachemi from Poland, from Poznan. Very good friend of mine. We used to do a touring JavaScript comedy for it with a group called Smusz. So started in London, we toured in Berlin, Helsinki, Finland as well. But our show in Berlin, it had Tomasz Lachemi there. And he gave a comedic talk on how he's DJ query. And through that whole process, we've come to learn that there's apparently a radio presenter in Chicago called DJ Query.

 

Ah, the guy's suit here or something? Ha ha ha.

 

Ha

 

Ha ha ha

 

ha ha! Yeah, and now they're going to see this podcast too. I'm so sorry, Dan.

 

okay

 

Ha ha ha!

 

Ha ha.

 

that's Chuck's problem not mine

 

Right? So, yeah, so you're kind of putting together guild for these groups of people that want to get together and do code

 

Yeah, so

 

stuff.

 

I guess jumping to that, skipping ahead to that, basically, yeah. The incentive with Guild is to build a platform to help people run communities. So all those troubles I had, finding content, fundraising, stitching together a platform, finding sponsors, etc., etc., selling tickets. Guild does that out of the box. We find sponsors on behalf of these communities, and we take a commission off that. So we're aligned with the success of the community, as opposed to other platforms, which you know, charge the community to run, therefore, kind of sapping away from their sponsors

 

Uh huh.

 

and creating more funding pressures. So that's kind of the goal of Guild is to help incentivize community growth and community scale and kind of be there as your partner, as you scale upwards and onwards.

 

Right, makes sense. So...

 

When did you start Guild?

 

Uh, so it's been kind of in the back of my mind since I think 2010 when I started Toronto JavaScript, you know, like back, you know, like, like, essentially we're all software developers, we're all, you know, have that kind of idea in the back of the mind that, hey, I like, essentially, I can build a better thing, you know, whatever, whatever the thing is you're using. And so it's been at the back of my mind, I could build a better community platform since then, but it wasn't until COVID hit that I was glued in front of, you know, Twitch and YouTube all day that it dawned on me that, hey, this business model applied to communities is an actual better platform. I mean, you can go technically build something better, but is anyone going to use it? You know, like, I think that's debatable. It wasn't until I got those two concepts together, business model and a technical platform together as one that actually produced something that's actually 10x better. So I would say more actionably on guild for the past two years or so.

 

Very

 

Cool.

 

cool.

 

How many people do you have working in Guild these days?

 

Oh, we need more.

 

Gah.

 

So we're currently currently fundraising

 

That's always the issue.

 

to hire a few more. Yeah, yeah. But yeah, got some really heavy hitters. So the former CEO used to work with 11 years ago. We sold a company ticket master live nation. Working with him for about 11 years. He's on board the design lead at pitch.com for busy Rosa Marquez insane interactive designer. He's on board. I have a few developers I've been scaling with for the past seven years. They're on board. I like to describe it that we can all see into each other's blind spots. So, you know, I have my own blind spots, you know, other members of the team have their own blind spots. We have someone that can see into each other's blind spots. We have pretty good coverage and really good synergy, but yeah, we could always use more.

 

So Guild is already at the place or point where you're actually offering a service. There's a website where I can go and actually start using Guild.

 

Yeah, absolutely. So if you go to guild, guild.host, gild.host, you can click on the link and view our beta on there. We just launched that beta about 11 months ago now, so being used by communities around the world, which is fantastic, validating product direction. And so this year, what we really want to focus on is kind of the next stage of that. So conferences, kind of larger communities, and really building out kind of, as I mentioned before, that sponsorship really helping communities, essentially at the next level.

 

Very nice,

 

That's

 

very

 

cool.

 

cool.

 

So

 

So you're a successful

 

how does-

 

entrepreneur. Ha ha.

 

Yeah.

 

I think TBD. Ha ha ha.

 

I kind of want to see how React Native plays into this, right? Because it's one thing to have sort of the data, CRUD, operational application, right? It's another thing where you've got interactive stuff. You want people to get on your website. At the same time, you also want people on your mobile app. And so it seems like you're going to have this interesting juxtaposition of problems to solve.

 

Yeah, absolutely correct. And it's tough knowing what to pick because, yeah, and I think React Native in particular, it's a tough sell for so many reasons. It's a great sell for lots of reasons, but a tough sell for other reasons. And so obviously it's a great sell as a no brainer for lots of folks building mobile apps, you know, like build once

 

Right.

 

and deploy to iOS, deploy to Android. I think that that makes a ton of sense. But often when I say, react native to the web. People just look at me a bit odd and say, what, you know, like, I think it was

 

Yeah.

 

the other way around, like not not the way you're doing it. Like, like, what are you doing? You know,

 

Yeah,

 

and so

 

is it like React Native for the web just react?

 

Exactly, right? Exactly.

 

Yeah.

 

So there's this odd look that they give me in this kind of exactly what Dan said, like, aren't you just writing react? Like, why are you making things more complicated? And yeah, I mean, I think that's been a much harder sell. So for me, I've been writing react native for web and for and for mobile for about six years now. So I started back in 2017. And I mean, if I'm honest with you, back then I was equally skeptical. If you told me, hey, Taz, we're writing react native for web. and like, why not just write React? It works fine, it works well. But I worked with a team that really convinced me that React Native could work on web. And I think the main part that I understood at that point was what React Native basically is, it's a component system and a method of defining those components. That's really all it is. If you're working

 

Mm-hmm.

 

with a design system, you could arguably just make those equivalent with React Native components and bam, you're basically writing a React Native application. platform itself, the host itself doesn't really matter as much because you're writing within this component system and what's hosting it is kind of up to the platform. It's not what you're actually writing itself. So in building a fully functional application using React Native Web and React Native for mobile, I was sold. I was like, okay, this actually works. I

 

Right.

 

can see this actually functioning. I can see the value of this. And around the same time, Twitter actually rewrote their entire front end using React Native Web. So if you use Twitter for web using React Native Web already, and a ton of other companies as well are actually using React Native Web today that you probably wouldn't even know is React Native.

 

That's interesting because Twitter is one of the only websites that works on mobile. Twitter, Twitter experience on mobile is, I think, bar none, the best experience that I've ever, ever, ever, ever seen.

 

Yeah, yeah, yeah. And it's interesting because they launched their web experience with mobile.twitter.com first. So they launched it mobile web, which was a React Native web, and they found that that experience, I think the performance benchmarks of that, like the usability, you know, benchmarks, like all the different analytics they had, proved that that was a superior experience to Twitter.com. So they made mobile.twitter.com the main experience. And so that's actually what you're using when you use Twitter.com today.

 

But going back

 

Oh, interesting.

 

a second to what you just said, because that kind of surprised me, maybe threw me off a little bit. So are you effectively saying that React Native for Web is just React with a collection of certain components? That's it, because it was kind of my understanding that React Native has this whole runtime concept of separation. between the logic thread and the rendering thread and stuff like that. And you know, I was kind of curious how that would work on the web where you mostly just have one thread. And you're saying all this thing doesn't really exist or does it or like, like, what's the story here?

 

Yeah, great question. And so, like, there's, there's, there's Sebastian Markboga, the main architect of one of the main architects of the React platform. And he gave a talk a while back, I'm going to misremember the talk, but it was essentially, you can think of React as layers, right? And so the more layers you add to it, obviously, the more abstraction you have. And at some point, you're dealing with this higher level thing, that it doesn't really matter what's because you're only interfacing with this higher level thing. I know it's obviously a generalized concept. It's a generalized concept of abstraction that I just described, and he goes on in his talk to describe it much more eloquently than I just did. So I'd recommend checking it out, his talk. But essentially, it's that. It's you as a developer, which part are you interfacing with? Me as a developer, I'm interfacing with a component library. If I'm building an interface and React, I'm writing a bunch of components. Maybe I'm writing a bunch of hooks these days, but that's the level that I'm interacting at. What's from that level lower? So you're absolutely correct Dan that like the the reactive runtime on mobile. There's a there's a logic thread There's a rendering thread. There's you know, all these different pieces working together On a web browser. I mean, of course, you're writing to DOM and you're writing to CSS and that's being parsed by a browser but but but that's not what I'm working with what I'm working with is that is that component system and if I can author An application using that component system Arguably I can get that to run on any platform because components and abstract away the actual runtime.

 

And what about styling? You kind of touched on that in your explanation. I mean, obviously when you're building for actual mobile, then you don't have CSS, but when you're

 

Ha

 

building

 

ha ha

 

for

 

ha

 

the

 

ha

 

web, then you do. So when you're using React Native for web, are you or are you not using CSS to style things?

 

Yeah, it's a great question. It's kind of a funny one because on React Native for Mobile, you're right, there's no CSS. However, React Native provides styling constructs that resemble

 

Mm-hmm

 

CSS and actually has a Flexbox implementation. So when you're writing React Native at its very core, you style with property names that basically look the same as CSS, and

 

Mm-hmm.

 

everything is Flexbox. So if you have those two primitives, you can arguably build UI and since you have those primitives and it works so closely with the web platform, it maps very nicely as well. The main thing you don't have is the cascade. So you have style sheets, you just don't have cascading style sheets. So all the different styles are scoped to the component and you don't have that type of cascade that you would normally have on a web platform and you know there's pros and cons to that of course, but

 

Yeah.

 

as long as you're cognizant of that you can build an application around it.

 

Ironically, most users of JavaScript frameworks tried to get away from cascading as much as they can. We had Tracy Lee and Adam Bradley, I think his name is,

 

Thank you. Thank you.

 

on our show to talk about Svelte, when they emphasize how Svelte does magic in order to scope CSS to its components rather than have them entire page. So yeah, it's amusing. So you're basically saying if you're using React Native for the web, effectively that is what it is.

 

Yeah, yeah, it's essentially a set of components like like react native set of components and that's standardized across every platform. And because the react native styling system is essentially web based CSS property names on top of flexbox implementation, all of that continues to work in the web platform. Therefore, it just works. It works on on every platform works on mobile works on web, it can work on desktop as well TVs and so on and so forth. So as long as the platform can understand it can effectively render to any platform.

 

Yeah, it all goes

 

So.

 

back to that, some of that idea of the layers, right? Because the styling and the components, I used to host the React Native podcast on this network and, you know, talk to all kinds of people about this stuff. But what's interesting is, yes, you have React DOM, which is what you're used to with your React development on the web. Then you have React Native, which is the rendering engine for the mobile. And yeah, like you said, the components kind of sit neatly on top of it. And, And the styling approach to React Native also sits neatly in there. I don't know exactly how it fits in. But anyway, so once it, once it does its thing with your layout, it knows how to convert those base components, you know, React Native knows how to turn it into React UI components, and React DOM knows how to turn it into web, web, not web components, but you know, components on a web page. And so at the end of the day, what you wind up with. with is you wind up being able to write the same code and then the engines just handle it properly so that it gives you the right thing depending on what platform you're on and it's really slick. I never really did quite get React working but it's been a year or so since I have really done much with it so I was like this is gonna be fun because maybe you're making it work now so.

 

Yeah, and admittedly, like, like since I started working on this six years ago, I had to do so much manually back then, I can figure all the web pack manually, get

 

Mm-hmm

 

the file, file names manual, figure out the override, yada, yada, yada. I mean, back then it was a pain. These days, it's so much better. I mean, these days, you can basically go to Expo, Expo's website, download what

 

Oh

 

they

 

yeah,

 

have.

 

Expo's

 

They have been

 

awesome.

 

working across platform. It's so good. Yeah, it's incredible what they're doing. And so in the talk I gave actually in Australia, sorry, go

 

Do you want

 

ahead.

 

to explain real quick what XBOE is for folks?

 

Yeah, for sure. So essentially, they're a so it's funny, it depends who you talk to, like there's a good friend of mine that

 

Ha

 

works

 

ha

 

a

 

ha

 

lot

 

ha!

 

with React Native that that I think has described it the best and maybe controversially, which is while while while while repeated here. So Facebook meta, they basically released react native and said, Hey, here's a thing that we have internally today, like here's exactly

 

Mm-hmm.

 

what we have, you know, I mean, this is what it is. Essentially, what expo has done very much directed at Meta's internal usage and made it usable for the rest of us. They've kind of bolted on the additional build tooling, they've made it approachable, they've kind of packed it up in a really nice way that we can all use. So that's the way that I think of it at a very high level. And kind of a tier below that, they have a service that'll do all the builds for you. They're a kind of managed solution that'll make it easy to write applications iOS, Android, web. They have great documentation. You know, they have like a notification service, a way to install any sort of native module, you know, etc, etc, etc. So they kind of, they kind of taken that, you know, kind of kind of raw piece of rock, if you will, that meta's given us and they've kind of chiseled away all the rough edges, smoothened it off and kind of, you know, presented in a way that we can, we can all kind of just take and, you know, use as we want to.

 

So I have two

 

Yep.

 

questions. I'm kind of thinking which one to start with. Okay, so my first question is this. You were talking about a set of components and about the fact that you can obviously use React Native to write, to develop applications for iOS, for Android, and now also for the web. When you're developing for these three platforms, will you be using and will you end up with exactly the same UI? It kind of seemed to me that kind of the point is that you maybe you do but then maybe you don't. So what is it?

 

Yeah, fantastic question. So I think like six years ago, I had the same thought because I've never used a good cross platform framework that that actually respected each platform. You know, they kind of glossed over the differences and you'd build in this kind of higher level thing that didn't work well anywhere, you know. And so that

 

Java

 

was the thing that impressed me exactly, exactly.

 

or it would

 

Other

 

work

 

thing that

 

on

 

impressed

 

the one

 

me

 

they

 

with

 

initially

 

React Native.

 

designed it for, and then not anywhere else.

 

just be janky and weird and like, yeah,

 

Yeah.

 

like I was using an app the other day that was a repackaged web app for desktop. And like whenever I, I dragged over a piece of text, it would select the text, it wouldn't like click the text, you know, small things like that.

 

Mm-hmm.

 

When you try to repackage an application meant for one platform onto others. React Native was the first cross platform tool that I've used that actually respected every platform. So essentially to go, to go back to your, to your question, Dan, like the way that I is which parts of the UI are common, which parts of the UI are shared, and then write those in a common shared manner. And then which parts of the experience are different and actually respect each platform. And what React Native allows you to do quite well is drop down to that platform and write those in a platform-specific unique way, just through file extensions. So you might have like some sort of user component.ts file, and that'll be the same for everyone. You can write user component.ios.ts, and that'll be unique for it'll be unique for web and so on and so forth. That's a very basic example, but as it makes sense to differentiate, you can differentiate, as it makes sense to consolidate, you can consolidate. And I think that's the one thing I really like about React Native is that it allows you to actually respect each platform's differences and build for it in a nice way, as opposed to what I've seen done elsewhere where it's often very much of like an afterthought or not even thought about in a sense in a lot of cases.

 

Yeah, one other

 

No,

 

thing

 

I...

 

that I would add is that if you want to pull in libraries or things from the different ecosystems, it does that fairly seamlessly too. I think the one that I've seen most often grabbed is Coco pods and you can pull Coco pods in and there are a lot of adapters that are written so that when it talks over the JavaScript bridge to native iOS. It can call into those libraries and do what it needs to do and you know, a lot of that is pretty clean. made it pretty easy to use that stuff. And so it's, you can find what you need without having to go to a ton of trouble to figure it out.

 

So I get the benefit then that basically you're saying, if I'm understanding correctly, that if I want to target two or all three platforms, then using React Native makes a whole lot of sense because based on what you're describing, I can mostly write once and then run everywhere. My question is, if I don't need to, you know, write native code, or if I don't need a native app, do I still want to consider React native for web or should I just go with React?

 

Yeah. And so for us at guild, I mean, like, like that's something that we know we want to build. So right now we're building react native only for webs. They were only shipping to one platform right where the very early stage of our company and want to iterate fast. Um, you don't want to go through app store and release cycles and all those complications that you get from mobile. Um, so we are actually building an app for a single platform that is web. However, we're still using react native. Um, the main things that have kind of been developed over the years that have, go with this approach has been, I think, the rise of design systems. So like, if you're building an app these days, you know, it's recommended that you use a design system, maybe at a very early stage you don't, but, you know, it's going to do you a few favors to use a design system. I mean, these days, I mean, Tailwind has gotten a lot of wind in its sails. And you know, there's actually native wind as well for React Native so that you could argue that is kind of a system of design.

 

Yeah, I was curious

 

Thank you.

 

about

 

Bye.

 

that. Should I or should I not consider Tailwind to be a design system?

 

Yeah, I think that's another rabbit hole that we can go

 

Yeah,

 

down.

 

that's that's another whole podcast.

 

Thank you.

 

I

 

Bye.

 

like tailwind though.

 

Yeah, I think

 

Well,

 

Tailwind's

 

wait,

 

really

 

I thought

 

cool.

 

design system had to do with literally the design and Tailwind is, I mean, I think this is an important question if we're talking about a design system. Tailwind is just a specification for how to basically a naming convention for CSS classes. It's not a system of design in terms of components.

 

Yeah, like, like you can compose tailwind into a set of components, for example, but tailwind

 

Hmm.

 

and isolation is not that. Yeah. Yeah. Yeah.

 

Right.

 

Yeah. But I guess for like for for the type of example that I'm illustrating, it is like tailwind or a set of components abstract away over the underlying platform enough that you can kind of build off of that. And so, for example, tailwind, obviously for web, it's tailwind for native, it's native wind. And that provides a styling consistency across both. So you can effectively just write using either and it works on whatever platform. Similarly, exactly like a set of components that are from a design system, you're writing in that set of components, you know? And if that set of components works anywhere, it doesn't really matter what's underneath it, you're just writing in the set of components. So in that sense, like that's how I think about it, is what am I actually writing? And if that thing can work anywhere, then really what's underneath it doesn't really matter. So what we've done we've used a React Native design system and just built that for web. And so in the future, whenever we wanna launch an iOS or Android app, we just have to build it for iOS or Android and we're basically done. I mean, of course, you know, you might need to write that five or 10% code that's unique to that platform, but it's much easier writing five or 10% code than writing 100% code. So that's kind of the way that we're approaching it. And so we're gonna start with the first one. We're gonna start with the second one.

 

Can you give examples of some of the components that you got out of the box from React Native and some of the components that you had to build yourself on top of them?

 

Yeah, and I'm going to be that guy that said I rewrote our app three times.

 

Ha ha.

 

And so it's

 

And you still haven't gotten it

 

not

 

right.

 

a great example. Exactly. And I think we have rewrites

 

That's how it

 

four

 

always

 

and

 

feels,

 

five coming

 

yeah.

 

up as well.

 

Yeah.

 

Yeah. Yeah. Yeah. So like, I mean, like, the basics are like things like view, things like select, things like scroll view, you know, so like a view can be like a div, for example, you could think of it in the same way. A select is just a select box. You know, a scroll view is just a view that can scroll. Those types of basic UI primitives, React Native has them defined in literally those component names. And you can very easily think of how that maps to a web platform or to any other platform. It's just a box. It's just a select drop down. It's just something you can scroll. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

 

Those,

 

Yeah. Yeah. Yeah.

 

incidentally, so when I was hosting the React Native show, I also hosted the iOS show for a long time, speaking, you know, Objective C in the Swift. And a lot of the way that React Native names its components is how iOS thinks about a lot of its components.

 

That's funny.

 

So that's where that structure comes from.

 

See,

 

Wait.

 

like for me, I didn't even know that.

 

Yeah,

 

It shows you how much

 

but...

 

of the underlying platform I actually end up using, right? Yeah, yeah.

 

Well, and that's the whole point. That's exactly the point. That's why you pick a React Native is because you don't want to have to worry about that stuff, right? You just want to

 

Exactly.

 

get something out there that people can use this well structured so that you can change it easily. The. Yeah, makes sense for the problem you're trying to solve.

 

Yeah, yeah.

 

Now I'll finally get to

 

I'm

 

my other question that I had. And that one is these days people don't really write or use React anymore. They use Next.js or they use remix. They use some meta framework or now the popular term is rendering framework on top of React because they want the server stuff like SSR, the deployment, they want the routing, you know, most of these frameworks implement file name-based routing or file structure-based routing. Does React Native also come with a meta framework or does it just use one of the React meta frameworks? What's the meta framework story for React Native?

 

Jeez, just killing it with a fantastic questions these days, Dan.

 

Ha ha ha!

 

Ha ha ha

 

I love all this. He's this was all awesome. I need to start writing this down. And I think I got the subject for the next talk I'm going to be giving. It's just it's just react native featuring Dan Shapir.

 

That's

 

Love

 

If

 

it.

 

you

 

right.

 

bring me along for the conference just to sit on stage alongside with you, that's good enough for me.

 

Yeah,

 

But

 

Dan's

 

yeah,

 

React

 

I guess...

 

Native questions are darn questions.

 

Hehehe.

 

Yeah, you'll bring me along to your conference talk. I'll just ask questions and then you'll spend the rest of the time answering them.

 

Well, like honestly, those are the best talks. Like those are the best because

 

Yeah.

 

we had a, I hosted an event earlier this month. The video is gonna be out soon actually. If you go to the TRPC Guild, you'll find it on there. But it was just the creator of TRPC and the creator of a GraphQL client. And I just sat down and just asked them questions and got questions from the audience the whole time. So we'll do the same thing, but with Dan and myself.

 

Yeah.

 

But yeah, I guess to answer, actually answer your question just try to avoid it, try to change the topic.

 

Ha ha ha!

 

You can kind of do both. So for Next, as you mentioned, they have their own very particular way of doing service-side rendering and routing. So there's a library called Solito that allows you to write in Next and also write a React Native application. So you're kind of writing two navigational structures, one for Next, one for React Native, and then trying to stitch together common components.

 

interesting.

 

that if you want. For me, I like to share more of my code. So I don't, I'm not a huge fan of that approach. I can see the value of course, you're, you're leading on the values of the next ecosystem. But for me, I would like to share more code. So I sat down, I had a chat with Evan Bacon from the expo team. It's actually recorded on YouTube. So if you go to the guild YouTube channel, check out Evan Bacon on there, you'll find our chat. And I kind of spoke to him about exactly this. I said, Hey, Evan, you know, one of with with with the React native right now across every platform is navigation. How do you build a navigator that works across web and mobile? Where on on web, we obviously have URL based routing on mobile. It's often stack based routing where you can also have multiple stacks on a same screen, each with their own individual routing inside of that. Kind of a different navigational paradigm. How do you consolidate that and building every platform navigators? So I had a chat with him about that react Miami last year. I think that was April. If it was August or September, off the back of that chat, he came out with a new router called Expo Router. And that is fully set to kind of consolidate every platform navigation. And in my opinion, that serves as the underpinning for kind of a new React Native first, essentially framework, React framework. Now, you can also use that same router anywhere else should you desire. But the way that I look at it personally you know, Next, Remix, Redwood, you know, any of those kind of lovely React frameworks, they're all built very web-first. And in my opinion, the main thing that you need to consider when building mobile or desktop even is the navigational difference, where you don't have URLs as kind of your leading navigational paradigm anymore. You have interaction with the UI. And when you have interaction with the UI navigating you from place to place to place, you need to consider navigation slightly differently than kind of just having a more centralized, like serializable URL. So I look forward to seeing what they work on next. Well, sorry, essentially what they work on subsequently. And so

 

Hehehe

 

they'll, and

 

Ha ha ha!

 

kind of how they make that work into a framework.

 

Yeah, just as an anecdote, I work at a company called Next Insurance, and we also use Next.js. So just think how confusing that gets. But going back to

 

All

 

your

 

right.

 

point, so if I'm understanding you correctly, what you're saying is that currently you're not really using a meta framework, but you're hoping that Expo effectively introduces sufficient tools that kind of provide framework experience, whether or not it's defined as being an actual meta framework.

 

Correct. Yeah. Like for us at GIL today, like I've just written a server side renderer with that height, with hydrating styles and data and all that fun stuff. We're using that on Lambda right now that renders ours, our, our reactive application. It all works fine. So we've built, we've built that just in the house. But for someone that desires to use such a framework, I mean, I think the best solution right now is probably Solito where you can write your next navigation and then separately write a reactive navigation. It's probably the best right now. If you want to use, something like Next.js. But yeah, for me personally, I'm really looking forward to seeing what Expo does because I think that'll be truly the future.

 

That's really interesting because you kind of preempted my follow-up question, which was going to be about server-side rendering because, you know, even with all the problems around server-side rendering with React, and we've had several episodes about this, the cost of hydration, why it exists, why it's such a problem, you really need server-side rendering. If you want to be, to have good performance, start-up performance on the web, and to be really friendly for SEO. And you're kind of like this, I'm not familiar with many companies that actually implemented SSR on their own, because even though React inherently is conductive to that, what with the virtual dorm and whatnot, the reality is that for most developers, it's kind of challenging. familiar with two companies that created their own custom SSR type implementations, one of them being you and the other one being Wix, my previous employer, where we effectively implemented an SSR framework because we did it back when there were no SSR frameworks out there and also given the scale of Wix, they really needed a custom solution. Because it's not trivial to do it. properly and also to keep up with the various advances that are being put out by the React Core team, like server components and streaming and whatnot. So first of all, kudos for doing it. And basic what you're saying though is that if I'm using React Native and I for web, because server-side rendering is wholly irrelevant for native. Then if I do need server-side rendering, I either do it myself or again, wait for Expo to come out with some sort of platform that does it for me, correct?

 

And you could also use Solido on Next.js right now. And you get all the benefits of using Next.js server-side rendering pipeline. I think that's been largely to your point about essentially what frameworks like Next.js provide out of the box and all the value that they provide to developers. I think that's been a large reason why Solido's since they've seen such a rise as well is because people want to go every platform and that provides them a great tool to do that by just leveraging Next.js, server-side rendering capabilities, et cetera, et cetera. But even that approach, they have a bit of challenges with Solito running on Next.js, running a React Native application. For example, we spent a lot of time server-side rendering into the proper viewport. So if you open beta.gill.host on a mobile app, it will server-side render a mobile app viewport. If you open on a tablet, it'll render into a tablet viewport. Open desktop, it'll render into a desktop viewport. And that matters because you might have different columns, different pieces of the UI, displaying

 

Mm-hmm.

 

in different ways, et cetera, et cetera. And so server-side rendering into the right viewport, something that we spent a lot of time with in our build. But for example, Next.js and Solito will not be able to do that. It will default to one viewport, and it cannot render into all of them

 

I'm curious

 

as an example.

 

about that because let's say I'm using a phone but I'm holding it in landscape mode. You know, if you're just doing it off of user agent sniffing, then you lay it out great but for portrait mode. So what do you do?

 

Yeah, I mean, you're correct. It's, so we're using Cloudfront's client hints to do that. And

 

Hmm.

 

however they define what the viewport to render is what we're rendering off of. So I can't recall if there's some sort of additional client hint within the user agent to define that for them within Cloudfront, but that's basically what we're using. So, but you're right. I mean, even Cloudfront's own documentation says they're not gonna be correct of the time. I think what I'm trying to highlight is that we at least make an effort, while unfortunately the next JS into Solito approach is just unable to, just because it's two different layers trying to work together. One is Solitos and one is Nex, and it doesn't have the hooks to work together as well. I'm sure it's something that'll improve in time, but for us, because we built it custom, we were able to solve

 

To

 

it.

 

be fair though,

 

So.

 

I'm not sure that it's in the context of a web, not so much in the context of trying to be cross platform across all possible devices, both native and web. If you're just looking at web, I'm not sure that it's so much a platform problem as either an application problem or design. What's the word again? design system problem. Because if you really want to be properly laid out to the whatever endpoint rather than the ideal world of the web rather than trying to do all sorts of questions, you know, imperative questions about viewport, whether it be on the client or on the server, you just want to use CSS and media queries. basically just be, what's the term, responsive or to have a responsive UI. I know various cases in React where people literally write code that, JavaScript code that checks screen width, screen height, or window inner width or whatever, and then renders the appropriate react code based on whatever response it gets and that's kind of a terrible thing to do because it almost by definition you're going to have re-renders, you're going to have a lot of JavaScript running up front and the proper solution is just use the platform, use the built-in CSS capabilities. But

 

Yeah.

 

you're saying that to an extent because you kind of need to kind of think about how it will work on native, you kind of need to go beyond that and do look at viewport-related considerations.

 

Well, I think at a very fundamental level, 100% of what you said applies still. I think the main thing to add to what you said is as long as the data requirements are the same across viewports, yeah, I mean, you could do it with media queries, not a problem at all. If the data requirements differ across viewports, like for example, you're loading in a whole different column and you're loading in a whole different piece of data, or something like that, based on viewport because you have a larger screen size or etc or different device capability. That's where you know hydrating it from a server specifically for that viewport can be advantageous because you're not you know loading a piece of data and then once the client is boot straps like on the front end is then looking for more data that's more time to interactive. So it really depends on what you're trying to render and depends on you know the type of experience essentially for that device. So, but at a very high level, I mean, absolutely agree with you. You should do as much with the platform as possible. And that's where I'm really excited about a new tool called Tamagui. So I've been working, you know, kind of back and forth with the maintainer, Nate Vinehart from Hawaii, working at Versailles at the moment. He's working on a new design system tool for React Native called Tamagui. And basically, it's three parts. one part of it is as a styling solution, another part of it is a design system built on top of that. The third part of it is a compiler that will compile that design system all the way down to basically straight platform specific code. And so the benefits of that are for web, for example, it can it can use native media queries on web to do that. So it doesn't have to hit JavaScript. It doesn't have to hit any of that. It can actually just write a CSS media query while you still write platform specific platform. React Native that works everywhere. So I'll provide a different example. So for things like viewport, we're able to find a solution for that and that works for us. It's not 100%, but it works pretty well. Something like dark mode support. Right now, that's incredibly difficult to server-side render into dark mode. And so Tamagui, for example, provides a great mechanism to enable that. So you can actually, server-side render a React Native application into dark mode, using something like Tom Agoui, because it

 

We.

 

will render away, compile away into actual platform-specific media queries. And that's it. Thank you for watching. I'll see you in the next video. Bye. Bye.

 

Okay, so the reason that this is a problem is because you're not actually using CSS, you can't use CSS variables or...

 

Yes. So, so traditionally with a React native application, um, if you're writing in pure react native, um, so platform agnostic, um, yeah, you would use the react native styling system, which would essentially the Dan's point wait for JavaScript to boot up on the page, then load, um, then detect your dark mode, then apply dark mode. So you'd have that flash of light mode, uh, in intermittently, um, exactly. So if you were to deviate from that and write in a little bit of platform You can get around it, you can write some web-specific code and load in dark mode right off the bat But then you need to maintain that code, of course You need to maintain that little bit of plot-specific code that you have and you're kind of deviating away from as much code shared as possible Atom Agui allows you to still write in complete code sharing Everywhere and and and we'll compile that down to plot-specific code as needed. So it still uses media queries still uses all that fun stuff But yeah, yeah you got it right. In a 100% React Native application, yeah, you'd need to wait for JavaScript to boot up.

 

So first of all, as a boomer, I'm really loving that Tamagui name. You know, I assume it's a playoff of Tamaguchi. But what does the syntax of something like that look like? I mean, you're talking about compiling code. So what am I coding in that gets compiled?

 

And I think that's the beauty of it is because Tamagui is a design system. Again, you're just writing using those design system primitives that basically Tamagui offers. It compiles that design system down to straight native code. So for example, before, you know, we spoke about a select, so like a select menu, for example, you know, it would compile that down to a select on web and then use like a select on React Native, for example. So it would compile that down. like a view on React Native, it would use a view component on React Native for iOS and Android and compile that down to be a div on web, for example. So it would compile it down to as close as possible from as specific as physically possible. So it would compile it down to as close as possible from as specific as physically possible. So it would compile it down to as close as possible from as specific as physically possible. So it would compile it down to as close as possible from as specific as physically possible. So it would compile it down to as close as possible

 

But I write my source code is something that kind of looks like react, which gets compiled down.

 

You write your source code exactly. You write your source code using the React design system that Tomica provides. Yeah. Yeah. Yeah.

 

Okay, and then I just run it through Tamagui, which does whatever transformative magic it performs. You know, again, it's interesting because, you know, you're looking at so many of these modern frameworks out there, you know, be it Svelte, which we mentioned before, or Solid, they're pulling off all of their magic, or quick, I think, they're pulling off all of this magic by incorporating compilation step into their built process to transform the code in weird, wonderful, and wacky ways in order to achieve, in the case of QUIC, it might be to achieve resumability and minimal JavaScript. In the case of Svelte, it's to compile away all the JavaScript and library stuff and just download the JavaScript that you need. You're saying that. is compiling it in order to achieve a platform-specific behavior with minimalist overhead.

 

Exactly, yep, exactly, yep, and

 

Thank you.

 

gain performance as a result. I mean, of course, with and react, like the less you're differing, the less you're rendering, the faster renders you can get. And so it has a lovely side effect of enabling that as well. But yeah, exactly. I mean, it's very interesting to think that all these tools are using a compiler to such a degree, while, I mean, yeah, back when I started Toronto JS, back in 2010, so many people were against a build step getting in your way or against a compilation step. If you remember those days,

 

Ha ha ha

 

they were very against it, right?

 

Well, you know, the whole selling, original selling point of JavaScript was that you don't need a compiler. You just have five to reload and, you know, so make whatever changes you want and just refresh the browser. But then, you know, we got all these compilers and obviously TypeScript is like

 

Exactly,

 

the compiler

 

yeah.

 

for our platform these days. a compiler anymore, what are we using these days for compiling TypeScript, ES build or VIT or whatever, I forget. I just use it. I'm not DevOps.

 

Yeah. I was hoping to jump in here and talk a little bit about this, just because, you know, like I said, I've done some React Native. It's been a couple of years since I tried React Native Web. I'm a little curious, why did you pick this if you're only compiling to Web right now? I mean, are you hoping to just, you know, kind of turn on the iOS and Android compilation and, you know, with minimal work? Is that the reason? Or is there some other? reason why you

 

Thank

 

went

 

you.

 

this way when you're starting with web.

 

Yeah, I think that's basically that, is that we want to just at a later date turn on iOS, turn on Android, write the 10%, 15% code that we require to support those platforms and bam, now we have a mobile app as opposed

 

All right.

 

to at a later date, you know, rewriting our whole application, redoing a whole thing, you know. And yeah, like over COVID in particular, you know, like I was looking at a lot of design systems and I was like, okay, like what do these designs have to offer, yada, yada, yada. just thought like, hey, if I'm writing this design system anyway, it doesn't matter what the design system is backed off of, why not just make it React Native and then buy into all those things. And so, yeah, so it was at the nutshell of having that kind of future kind of goal of launching a mobile app.

 

I gotcha. I guess the other question that I have is, you know, just given my experience with it, were there any gotchas, any hiccups with it? Because it is kind of a bolt-on to a system that's meant to build mobile apps.

 

with React Native in particular, I don't think so. I'm just trying to think, I think the main stuff was mainly around, as we spoke about navigation, and

 

right.

 

that was basically it. So that was kind of a key part of the talk I gave last year called React Native Everywhere, where I've seen Dan a few times during that journey of giving that talk React Native Everywhere, literally everywhere. And a big part of that was my journey through navigation with React Native. So these days I use, a React Native URL router, which is based off of React router. And so there's a lot of commonality

 

Mm-hmm.

 

there between those platforms. And so that works pretty flawlessly. But the journey to get to that solution was a big gut ya. Not gonna lie, it was clunky, it was difficult. Things like the back and forward buttons in a browser caused the whole app to get into a weird state, which caused you to refresh, which caused the URL bar to rewrite itself. Like so. I have to say where I started with this React Native journey for Guild in particular wasn't pretty in terms of navigation. Where we are now however is dramatically better. Things like React Native URL router, things like Expo router, it's just a no-brainer. It just works perfectly fine across every platform. And so that's been great.

 

If you don't mind me asking, what are you using for testing?

 

We are using Playwright.

 

as an end-to-end test system. Are you also using anything for unit testing?

 

So we find the most value in end to end using playwright. That's what the users are going to be using, and that's what we find the most value simply testing. We do more testing on our back end than we do in terms of unit testing our front end. We do more end to end testing on our front end because if we find more valuable.

 

Interesting. I also agree that end-to-end tests for front-end bring the most value. So obviously you need to have those. I think that unit tests in addition to end-to-end tests can have value. And interestingly, one of the motivations for React's architecture and the way that React is built is that it can support unit tests. All these components

 

Yeah,

 

as

 

I

 

functions

 

mean,

 

with state in UI, virtual DOM out.

 

you're talking to an old school Rubyist, and so don't know

 

Ha ha ha 

how he started about testing. I'm sure, I'm sure Charles can relate to that one.

 

Yes, definitely.

 

TDD, BDD, R-spec. I mean, oh geez. Um, no, I mean, yeah, like at the end of the day, um, testing, it's one of those, one of those lovely things where, um, my testing strategy is, is whatever helps you sleep at night, you know, if you need to get up in the middle of the night, cause something's buggy and gone to production, you should figure out your testing strategy because

 

Thank you. Thank you.

 

why, why are you not sleeping, you know, at night.

 

Yeah.

 

Um, but, but if, if you're comfortable if you're shipping good code, if comfort level is high and you know you're not having issues, I mean you're probably fine you know you don't want to rack up the CI time, like I don't want to spend any more money on

 

Ha ha.

 

CI than I need to, you know I don't want to crack up my build times, if it works for you it works for you and so if you can sleep at night that's probably fine if you can't sleep at night then probably change something but that's kind of the way I look at it.

 

So I'm guessing that between using probably TypeScript and being type safe on the one end and using end-to-end testing, on the other hand, you're able to sleep at night. So that's it. I hope you enjoyed this video. I hope you enjoyed it. I'll see you in the next video. Bye. Bye.

 

Yes, yes.

 

Cool.

 

But yeah, so I guess another reason I want to get into using React Native and every platform is embedability. So every platform embedability. And so I'd like to touch on that a little bit if you have a bit of time.

 

Go for

 

Uh,

 

it.

 

yeah, we've got a little bit of time and then yeah, we need to start what, uh, wrapping up.

 

Sounds good, cool. So something I worked on, I guess, of 2014 was embeddable experiences. And so back then I was consulting at a event ticketing company and ended up selling to Ticketmaster. And a big part of that was placing that conversion experience where the traffic exists. So if you think of a event website, you know, whatever it is, else having a conference website, you want to put that events widget on the conference website, because everyone's going to the conference website to figure out, you know, how do I get to the conference, yada, yada, yada, putting that widget on their website, that that's where the traffic exists. That's where you want to convert, you know, it just makes a lot of sense. So fast forward over COVID, I was working at another company, consulting at another company. And this was an entirely different scenario where we had a React team, and we had a Flutter team. And, you know, Flutter still relatively new compared to React. I mean, obviously, React's been around since what, 2013 or so. Flutter much newer than that. The Flutter team was still kind of figuring out how to build the infrastructure, yada, yada, yada. Their team was also just smaller, way more React developers in the market. And so we were able to ship things quite fast with React. So, like, we're basically getting ahead of the Flutter team. And so I thought, hmm, what if we could ship our React code as React Native, stitch that into Flutter. Like, is that a way that we can help both teams, you know, by simply stitching in our code into that code? And so we prototyped a way to actually stitch React Native into Flutter. And so all this got me thinking, okay, can we effectively build an app using React Native and take parts of that experience, package it up to any platform that exists. And so long story short, that's also something we're doing with Guild today. And in fact, we're just about to ship our v 0.1 of our SDK to enable that. And ship parts of our UI across every platform, whether that be web or mobile or desktop or whatever, whatever React Native supports. So you can take, let's say an event ticketing widget, put that on your conference website, put your list of presentations within your conference folio site, you know, to kind of take take parts of our experience and put it wherever wherever the traffic exists and kind of wherever you want to put it.

 

To be blunt though, is it more than just an iFrame container on the web?

 

On the web, we ship both iframes and an SDK. So it really depends on how you want to render it. Iframes have pros and cons. I remember iframes historically had different resizing contexts on web. So if you zoomed in on the parent web page, the iframe didn't zoom in the same amount as an example. So rendering natively on the same DOM might be advantageous for that. But like for us, embeddable provider. We just want to provide options for the consumer of that. We provide both an IFRAMEN and SDK, so it's up to them how they

 

Yeah,

 

want to do it.

 

for my experience, one of the main considerations of doing something like this, either as an iframe or not, has to do with which domain you need to be run, you need to or you want to be running in. Because if you're just, you know, you know, a script tag that you embed like, like a pixel within that website, then yeah, you can do anything, but you're, for good or bad, you're within the security context within the domain of the hosting website, which is something that you may want, but the hosting website may not want. Whereas if you're an iframe, then like you said, there's a lot of associated overhead, but there's also the whole separation of domains as enforced by the browser itself. So yeah.

 

Yeah, correct. And as you said, it depends on what you're building. If it's like a data aggregator thing, maybe an iframe over post message might be a fine way to isolate and then still pass data in and out where that thing living inside that iframe might be able to pass it onwards. If you're building kind of a UI experience, I found oftentimes it could be preferable to put it natively on the same page. For example, if you have a button that opens a modal, you can't really do that inside an iframe. You want to do that on the native page so you can actually else. So for example, a ticketing widget, you might say buy ticket that opens a modal, you might want that to live natively on the same page.

 

kind of like the chat widgets that people embed on their pages or maybe like what you might see as comments widget within a blog or something like that. Yeah,

 

Exactly,

 

I get

 

yep.

 

what you're saying and effectively like marketing pixels or whatnot.

 

Yeah.

 

So basically you're saying that with you it can go either way. If I've got a website and I want to integrate Guild functionality into my website, then I could basically either get a React component from you or maybe just some script that I copy and put into my web page or something like that.

 

Exactly. Yeah. So you, um, you'll, you'll be able to download like an NPM package at some point in the future, um, as well as, yeah, just an SDK script tag, you can put into your page and then render via script tag, or you can drop in an I frame and then, you know, just reference our, our experience through an I frame. And, and yeah, that's, that's kind of the various methods on the web. I think the, the crazy part for me is, is doing it on native as well. And so shipping the same experience embedded onto native is kind of, is like to me, that's just nuts.

 

That is nuts.

 

So if you asked me in 2019, I would have said, you're crazy. Ask me in 2020 after we did it and prototyped React Native running inside Flutter. After that, I was sold. It was so seamless. User didn't even know the difference.

 

Yeah,

 

It was not

 

I think the

 

how well that

 

main

 

worked.

 

hurdle there might not actually be a technical hurdle, but rather one of playing nice with the requirements of the various stores. I don't know how they would feel about, you know, one app embedded within another app and then what are they actually validating when you're being like accepted to their store.

 

So from a like Apple store or Google store perspective, it's just an application. So it's just an app at the end of the day. There's no additional kind of consideration that they would have. You can still, so for example, it's like if you ship a React Native application right now and you pull in a native Maps widget, to give you like a Google Maps or an Apple Maps inside your React Native application, it's basically the same concern. that you would have anyway. So from their perspective, it was the same. I think the way that we looked at it was more of an experiential consideration. Like does the end user, can they actually tell a difference? And I think that's where it was really interesting was they couldn't. We were able to stitch in React Native directly into Flutter's kind of data flow pipeline. We got two-way directional data flow going in and out. It was props going into React. and then a handler's coming back out into Flutter. It looked literally as if it was any other Flutter component in there, and you can do the exact same thing right now with Swift, you can do the exact same thing with Kotlin or Java.

 

Thank you.

 

It is

 

Thank you. 

 

legitimately insane, the level of native integration that React Native has, because it is fundamentally native with a JavaScript thread rendering into it. And so it was mind blowing to me, how much need of integration you can actually create with it.

 

Cool, we need to move on to PIX and Self-Promo, but this has been really interesting and it makes me wanna go back and start building mobile stuff again. So yeah, before we do that, if people wanna connect with you online, GitHub, Twitter, wherever else you hang out, where do they find you online? I'm just gonna go ahead and do that. I'm gonna go ahead and do that.

 

Yeah, you can come check me out on Twitter, Tazzing on Twitter, or you can check me out on Guild, beta.gild.host, slash Taz.

 

Awesome. All right. Well, let's go ahead and do the self promos real quick. AJ, what are you working on that people should know about?

 

This is my bike on.

 

Yeah.

 

Okay, good. So two things, one, we added bun to webinstall.dev. And of course, if you're already using the bun installer and bun upgrade, then, you know, the good chance that you just wanna do it that way. But, you know, if you've been using Webby for the consistency sake of still using Webby, and then you can switch between versions, you can not just upgrade, but you can also sidegrade. And it's POSIX, the Webby installer is POSIX compliance. on Alpine and stuff like that. But yeah, so we added, we added Bunda Webby and Webby itself is doing really well. So for the first year or two, we didn't do anything to promote it. We just kind of used it for our own goodwill and pleasure. And then we started to put in the output, hey, give a star on GitHub if you like it. And we're closing up on a thousand stars now. So it's been, I think about a year and a half. like we're going to hit a thousand stars about a year and a half from having something closer to 20 because we just we in the beginning we weren't focused on oh let's make this look as popular as it is um so I think that that webby is about I think this year either this year or next year webby's going to hit that hockey stick where it's going to start being more mainstream I think I still encounter a lot of people that I have no idea how they but their college professor or their bootcamp person or whatever had them using it. And I think that that's going to become much more common. And for those of you that haven't heard me talk about Webby before, it's just the best way to install your development tools. And we have a ton of stuff on there. It's mostly just me and a friend of mine have been putting it together. And we write these little install scripts. It's extremely lightweight. So when you install something, you don't have to download a 500 megabyte package manager. You don't have to wait 10 minutes to update. If you decide you want to get go or you want to get node or you want to get bond or zig or rust, or you want to be using caddy, it's literally the time it takes it to download it and untar it because it grabs it from the official GitHub repositories, it will install it in dot local opt and then it will add it to your path so that you are it's it is the most lightweight, most secure way to install just about any dev tool, modern things that are old and crafty and secure that rely on lots of shared libraries and that sort of thing. But if you're, if you're, if you've got a daily driver that is not on web install.dev, I definitely want to hear about it, open an issue, and we will, you know, get it into the pipeline. And the other thing that I was going to mention was, oh, so I'm renaming AJ script, which you've never heard of, because I've never mentioned it before. for the obvious reason, and I am actually...

 

H.A. you are evil.

 

Why

 

Ha

 

am

 

ha

 

I

 

ha

 

evil?

 

ha!

 

renaming it to GPD script? I mean...

 

Yeah, I'm renaming it to GPT script.

 

That's an evil thing.

 

Well, it makes a lot of sense because it's the, the originally the idea was make a language so simple that people can't get it wrong. But then as I started interacting with chat GPT, I was like, we need a language that's so simple that AI can't get it wrong. We need to lower the bar. And so there's a couple of things I've changed in the language spec. For example, you can only do one operation per line. This means that you have to use a lot more variables situations like multiplying some, you know, if you multiply 24 times 60 times 60 times 1000 to get a full day in milliseconds, now that's five lines rather than one, but you're not allowed to have parentheses for preference operators, I think I will be allowing addition. You can do addition together and you can do multiplication together so you can have multiple additions on one line and multiple multiplications on one line, but you can't do anything that requires the person to know what the order of operations is. So you can't do subtraction or division or mix multiplication in addition together.

 

Wasn't a whole point though of machine learning that machines will be smart enough to deal with the more higher level concepts

 

Ha ha ha!

 

rather than having us need to dumb down everything? I mean if you're going to go that route just have a simple compiler and be done with it.

 

Well, so there's also going to be macros that will expand things out. So you could do something in a way that is not valid GPT script, that it will just transpile it on the fly. So basically what prettier does, right? So

 

Bye.

 

with

 

Bye.

 

prettier, when you hit save, then it transpiles your code and then provides you correct code rather than crappy code.

 

I think this

 

And

 

needs

 

so

 

to be an episode, AJ. Ha ha ha.

 

Well, it's still just a bunch of issues of what part is going to be standard library, what is going to be syntax, what is going to be style, because there's a difference between style and language, right? So I want you to be able to do a bad copy paste and have code with bad spaces should still work, even though that's bad code, but the style format or we'll just format it. And there's some things that if you copy and paste it, it just shouldn't run. Anyway, this is a strict subset of the language that runs in browsers that have existed for at least three years. So whatever you wanna call that language, this will run in browsers, but it's not far enough along for me to do an episode about it. I don't actually have the tooling, but I am committed to it. I've made the decision that I'm not gonna do it myself. I'm gonna find somebody that's done LSP and that's done language server. protocol work and work with them to do it because I can maximize my efficiency by doing work that I'm already good at and have someone else write a language server. But yeah, it's going to become real and if you're interested in it, you can check out the axioms of AJ which I'll link.

 

Alright. Dan.

 

And those are my picks too, I think, so I'm

 

Okay.

 

gonna head out.

 

Alright,

 

So,

 

Dan. What

 

yes,

 

are you

 

I don't

 

working on that people should know about?

 

know if people should know about this, but it's kind of a funny situation. So, I'm working on improving performance, and I've talked about this in the past that whenever I do that, the first thing that I do is make sure that everything that needs to be monitored and measured is measured and monitored. And for that purpose, that I work at next, we already had the system in place for collecting a lot of telemetry data off of our web stuff. And what I did is, in addition to our collection system, putting all this stuff into a database, I also added Prometheus to the mix. Actually, Prometheus was there before to collect system level stuff, like much memories, the node process using how much heap and stuff like that. So I just added in the capability to monitor some applicative specific knowledge, and then I showed the rest of the team how to do it. The end result is that all of a sudden, our node server was going, the event loop lag was going up to like two seconds, because everybody put in their own histogram with lots and lots of labels and lots of lots of label values. And it turns out that that's not a great thing to do. So first of all, I invested effort in cleaning up the mess that was put into there, and removing a lot of duplicate metrics, and removing a lot of unneeded labels, and coalescing label values. and stuff like that probably seems like something that's worth an episode. And now I'm thinking about what can I do to enforce a set of rules besides just telling people what not to do. But how can I automatically enforce a set of rules so that this sort of thing doesn't happen again? I'm not sure if it's doable or not because at the end of the day, developers have the keys to the kingdom. If they want to, they just can allocate the ton of memory and you know I can't block that. So yeah, so I've been dealing with node performance issues due to excessive usage of Prometheus for the past couple of days which has been interesting to say the least.

 

Cool. I think I mentioned this last week, but I'm gonna throw it out again. I got a little bit derailed, but I have been doing the... totally, my brain isn't working this morning. The new podcast, the catapult your coding career podcast. And so if you're looking for ideas on how to get unstuck, you know, maybe you're working a job, you're not happy, and maybe you're feel like you should be making more, maybe you're not sure how to get from junior to mid or mid to senior or senior to architect or architect to thought leader or I call them trailblazers, right? The people are kind of finding their way interesting problems and technologies. You know, and any of those things, I talk my way through them, you know, and how to, what I did basically to get past all of those different obstacles, because I basically invented my way through a lot of them. And there are a lot of things that people can do that are kind of outside of the normal thinking that open doors for you and give you opportunities to go out and do really interesting things and enjoy your career. while you build a life. I mean, I have five kids. You know, I go to church and I participate in all kinds of things for church. I'm pretty involved in the political community here in Utah. You know, and so I have all these other things going on that my career supports and gives me opportunities to do, but that doesn't mean that I'm just working the highest paying job possible that I hate in order to do it. And so, you know, that's what I want to help you build. So come check it out, And then the other thing I'm gonna put out there is you should be able to go to topendevs.com and find a Form to get on our mailing list I'm gonna start writing daily emails and it's gonna have a lot of those same kinds of thoughts Maybe things that I can't express as well on YouTube or in a Podcast that maybe I can write out or tell more stories or you'll get you'll get different content than you'll get on the podcast But I really want to give people those those things to go by and give you opportunities to enhance your learning. And so anyway, those are the two things that I'm recommending that you do. I'm also adding lists for each of the shows. So if you go to JavaScriptJabber.com and you fill your email in there, you'll get the emails I just talked about and you'll get an email whenever we release an episode. So yeah, that's kind of the deal there and then we're getting ready to put together our TikTok account, so working on that too. Taz, what are you working on that people should know about? out.

 

Yeah, I mean, these days definitely gilded. I would say that's my core focus right now, scaling it upwards and onwards. So yeah, keep an eye on that. Other than that, I'm really looking forward this year to head off to Portland to speak at ChainReactConf over there. So,

 

Oh

 

TBD,

 

nice.

 

whatever you're speaking on, might be Tamagui, might be embeddable React Native. But yeah, hopefully

 

Thank you.

 

check

 

Thank you.

 

you out over there. And a few other conferences this year as well that I'm not a few of you there.

 

Nice. I've been to ChainReactConf twice. It's a fun time. So say hi to those guys for me. Alright, let's do picks here real quick. AJ, did you say you were good on picks?

 

So I decided that I'm going to add one more. which is

 

Okay.

 

that snowflakes are real and I have pictures to prove it. They are not

 

Okay.

 

just something that roll on the credits of movies and that you cut out on paper in kindergarten. They actually exist. You can see them with your eye. And I never knew this until today because I had literally never seen a snowflake before. I had never gone outside and actually looked at the snow when the, because apparently it's to do with temperature and humidity. So snowflakes, the way that we imagine them, the way that we popularize them, only form during at a specific temperature range with specific humidity, there's specific parameters. And I have never happened to look at the snow on a day when those specific parameters have existed. I saw snowflakes for the first time and they're freaking awesome.

 

Awesome. All right. Dan, what are your picks?

 

Okay, so my first pick is an amusing tweet by Sebastian Ramirez who wrote as follows. I saw a job post the other day. It required four plus years of experience in fast API. I couldn't apply as I only have one and a half years of experience because then that's when I created fast API. So yeah.

 

Ha

 

The

 

ha

 

guy

 

ha!

 

couldn't apply for a job. the API and the thing that he created because he doesn't have enough experience in it. I found that.

 

That's when you lie. That's when you do what you need to do to get to the interview

 

I love those.

 

and then clear it up.

 

Yeah.

 

It sounds like he needs the career catapult podcast that Charles is talking about.

 

Right?

 

Yeah.

 

Yeah.

 

Catapult your career, right? Yeah.

 

Yeah.

 

So that would be my first pick. My second pick is the fact that TypeScript 5 Beta was recently released. And a great person we've had on this show, Matt Polkak actually put out a great video, short video, only like something like six minutes explaining the highlights of this new release. to link to that. It really got me up to speed really quickly about what to look for in this upcoming version of TypeScript. So that would be my second pick. And my third pick is a video that was released by Jack Harrington about React streaming in depth. It's a great video

 

Mm-hmm.

 

because he shows how this new in React works. First, he demos it in Next.js using server components. Then he demos it in Remix without using server components. And finally, he just kind of builds it on top of React itself without any meta framework, which really kind of explains what's going on on the inside. And, you know, given the way that I like to understand things, a great video for me. So thank you, Jack, and I'll link to that video as well. And my final pick is the pick that I almost always pick. I actually did not pick it last week, which just goes to show. And that's the ongoing war in Ukraine, because it's become mundane. It's been going on and on and on. We're all kind of desensitized to it. We're used to it, but it's still going on. It's And you know so as usual I'm going to say that whatever you can do for the people in Ukraine Please do so and those would be my picks for today

 

All right, I'm gonna jump in with a few. I always do a board game pick first. The game I'm gonna pick this time is Sushi Go Party. Now, if you've played Sushi Go, Sushi Go Party plays up to eight players. It's similar, but it's not quite the same. Yeah, effectively what you do is you deal the cards and then you choose a card to keep out of your hand, you place it face down, you pass the cards to the left, and then you reveal your card and I think you do the left, the right. I can't remember, but I think you changed the rotation direction periodically. Um, or, or anyway, um, but yeah, effectively, yeah, that's what you do. So then you do the same thing until all the cards are gone and then you tally up your score, right? And so usually what happens is you have different things that stack for different values, right? Some of the cards are just worth whatever number of points on their own. Some of them you get bonus points for having the most or the least, or you don't get any points if you didn't have the most. or, you know, for every three of them you get 10 points or stuff like that. So anyway, it's pretty fun. It's all sushi-based, but it's a lot of fun. It's probably a half hour long game. Board Game Geek ranks it at 1.30 weight, so it's very easy for people to pick up, and it's a lot of fun. So I'm going to pick that. A few other things that I'm gonna throw out there. I know this is probably not of interest to too many people, but I started doing the triathlon training, the Ironman training, and I figured out that I had to eat more if I was gonna work out more. I figured that out the hard way because I just crashed and burned last week. And so I've been a big fan of the keto diet I feel better when I'm on it. I'm diabetic, so not eating as many carbs is a good idea for me. And so, I was looking for, okay, how do I do the Ironman on keto, right? Because most of the eating plans, you're eating like 65, 70% carbohydrates. And I found an Ironman guide to ketosis. It's a little bit in depth, but I dig it. And so anyway, so I'm just going to keep track of that. is my fitness pal. And so the thing that is nice is you can connect your Garmin workout tracker to my fitness pal and then my fitness pal will tell you how many more calories you can eat per day above your you know regular diet. So if I don't work out on a day right then I don't get extra calories and so I just know how many I should eat to kind of keep to maintain and then for the rest of it. Yeah. So that's the approach. The other thing is, is that I figured that I do need to eat some carbohydrates because I cut them completely out. And that helps you get into ketosis, but I need to start out and back in. So that's the other deal that I'm doing. But yeah, so really digging that. I also

 

That kind of reminds me, Chuck, that during the Olympics, it turned out that Michael Phelps was eating something like 10,000 calories a day.

 

Yeah. Yeah. And that was, you know, I kind of ran across that again, because I'd heard that too. And yeah, when you're working out a lot, you have to eat more, a lot more. And so that's, that's what I'm getting back on top of now is just, you know, adding fuel to the thing. So I don't crash and burn because I felt awful for like three days. So anyway, what else was I going to pick? I guess that's all I got. Oh, I also, I don't know if I picked this last time, but I watched 1923, the first four episodes, which is what's out. It's a spin off of Yellowstone, and I really liked it. It was, it was really good. So I'm going to pick that too. All right, Taz, what are your picks?

 

Geez, well, I think I think first of all ketosis geez. I so I tried that I'm vegetarian been vegetarian my whole life

 

Uh huh.

 

and That was very difficult for me because as a vegetarian

 

Oh, I

 

Not

 

bet.

 

eating carbs is very difficult. Yeah

 

Yeah.

 

Yeah, so so I I crash and burnt myself on the on on a keto diet, but

 

So you're just fast,

 

But yeah, if you

 

that's

 

can make

 

your

 

it work,

 

diet.

 

it's like the like the like the advantages look amazing

 

I said you

 

I think my pick-

 

just fast, your diet is just fasting. Not eating, that's

 

It's just

 

it.

 

not

 

That's

 

eating.

 

it.

 

Yeah,

 

What

 

not eating.

 

water and vegetables?

 

water and ice cubes

 

Whoa, now you're adding ice cubes and you don't know what they're putting into those things. Um, but yeah, I was with a triathlete down in Australia with Dan actually. So, um, just came off a dive trip, uh, and, uh, met up with Dan, Dan down in, down in Australia, down, down in cans. And, um, I don't remember Dan, but like someone at that, at that table, what was a triathlete? So they went down to, um, Australia down to, uh, Perth. So on the West West coast of Australia, um, and did a, did a trathel on there. So, um, yeah, it's a lot of training. I can relate to that. to eat as much as four people, Aka 10,000 calories a day in order to get

 

I don't

 

to it,

 

know

 

apparently.

 

if

 

Yeah.

 

I have to eat that much. I'm assuming that I'm probably gonna eat quite a bit more, but yeah.

 

I think my pick would be quite simple. It would be a bit maybe a Pokemon in that. I would choose, I would pick Dan Shapir to come on stage with me next time and ask me questions.

 

I'll take you

 

And

 

up

 

so

 

on that.

 

I think

 

Ha

 

that would be my

 

ha

 

pick.

 

ha. Now I'm going to fix my schedule. So just let me know where and when. Ha ha ha.

 

Yeah, well, last year I saw you in two continents. I saw you in Europe and I saw you in Australia. This time we got to make it three. So

 

Yeah, for

 

we'll

 

sure.

 

try to make it happen.

 

For sure, I'd love to. Yeah.

 

Awesome. All right, well, we're gonna go ahead and wrap it up here. We're already way over time, but thanks for coming Taz. It was awesome

 

Yeah, thanks so much for having me and it looked pleasure to see all of you again in the future.

 

Yep,

 

for sure.

 

absolutely. All right, folks, till next time, Max out.

 

Bye!