Episode 22
Yang: you essentially want to empower your editors to be able to tap into these. And so that's ultimately what code components do is they're a way for you to register these like react component from your code base and let them be dragging droppable and visually manipulable on the canvas.
Andrew: Hello, welcome to the dev tools, FM podcast, this a podcast about developer tools and the people who make them I'm Andrew. And this is my co-host Justin.
Justin: Hey everyone!
Andrew: Our guest today is yang Zang. He is the founder of plasmic, a no-code visual editor for react and other front end frameworks. It works well for devs designers and even marketers yang. Would you like to introduce yourself a little more?
[00:00:46] What is Plasmic?
Yang: Hey guys, thanks for having me. So I'm yang, I'm one of the co-founders here at plasmic and we're actually a very early stage startup working on essentially this visual builder for the web. You can think about it as it looks and feels kind of similar to design tools that you might be familiar with, like, Figma, et cetera.
So you can, you know, plot boxes on a screen, essentially visually and drag and drop things But behind the scenes, it's it's actually based in code. So it's continuously able to generate for instance, react code. And the main use case for this tool is developers basically plug it in to their Next.js code base or react code base, or, you know, we actually support also Vue an angular and even plain HTML. And essentially then they can hand over this visual editor to their non-developers and and non-developers can go to town and create new landing pages on the website and new marketing content.
And basically this this kind of use case of serving as this content management system, that's entirely visual and doesn't require developers to be in the loop, creating a templates and schema and modules and things like that. So, yeah, that's a very high level summary. Yeah.
Justin: Interesting. How does it, how, how are you sort of like differentiated from some of the other sort of big no-code providers? I'm trying to think of what's what, webflow that the, the,
Yang: Yeah.
Justin: the sort of big one in this space,
Andrew: Modulz, framer.
Justin: I feel like modulz Is, is like a different target though. Cause they're like, I kind of sort of still in the code, but kind of not.
But yeah, anyway, just, yeah. Curious as like what's the, what's the sort of differentiator?
Yang: Yeah. Great question. So there's a bajillion website builders in the world. Yeah, Webflow even like Wix and Squarespace. These are actually what we refer to as end-to-end platforms. So they take care of basically everything for you, you know, hosting infrastructure, deployments all that good stuff and integrations, et cetera.
And what you do, if you're, if you're like a small business you know, you want to get your website up and running or if you're like a freelance agency just cranking these out, this is like, these are great platforms for that purpose. But there's also a lot of companies and entities in the world that don't use these platforms.
So they have their own code base running on some JAMstack uh, using Next.js. They have a team of developers and they have their own customer requirements et cetera. And so it's really these environments that were a lot more focused on. So basically getting them this, this visual editor that does bring a lot of like the, the, the niceties that you might be familiar with from other no-code platforms into your specific environment.
And and that way, you know, developers can empower the non-developers on their team that they collaborate with to just go to town.
Justin: How does it plug into a code base? So, there are a few like different mechanisms for doing this, obviously, but are you like approaching it from like the perspective of, are you generating like React components or angular components or, you know, the other artifacts of that?
Or is it a little bit. Higher level. It's like, you're actually just behind the scenes generating HTML. That's just like, sort of plugged in and rendered in the app, you know, as like you would, any normal sort of CMS is like, how does, how what's your technical approach?
Yang: yeah. Yeah, really good question. So, I think the way they think about us is that we try to be really versatile in how it plays in. So yeah, you can actually on one level generates like just react component code. Physical source files along with CSS and various dialects into a file system, like your code base your repo sitting on local hosts, et cetera.
So we have this CLI that you can run to actually do that sinking down of this generated code into your code base continuously. So like you could be making changes in the visual editor and have those actually live synced into your code base. So that's kind of like, the like one low level way of getting code out of plasmic.
And that's actually really useful for if you are actually a developer using plasmic as a UI builder for yourself. We actually do this with plasmic itself. So we, we build plasmic in plasmic and like a lot of the surfaces, the toolbars, the, you know, the shared dialogue, et cetera, all of these things are basically designed and built out visually in plasmic.
And we use this client to sync down those modules as source files. And so that's, that's one way you can use it. It's like the lowest level control and these components that you sync down, they actually provide you this this kind of props interface where you can pipe in the props that you want to, the various elements inside of that component.
You can pipe it in like, you know, states event handlers, all the usual stuff. So the philosophy there is that you're doing all this presentational crafting in the visual tool, but all the logic and all the behavior is still you know, specified in code because we're not trying to reinvent programming or anything like that.
We like code. We like, you know, the tools like TypeScript, et cetera, that we have today to express these ideas. And it's more about it's probably more about CSS than anything. You know, CSS is kind of a beast CSS layout to this day is like, for me, you know, I've been doing building web apps for a very long time.
And I still feel like I know nothing about lay out on the web. And anyway, so, so the idea here is that plasmic in that use case, it serving as a developer tool is there to accelerate kind of, you know, your ability to quickly slap together and express these ideas just on a visual canvas.
But the other use case that I was mentioning, which is kind of our, our main like, bread and butter use case is where developers themselves are not the ones using it. They actually basically install this API client for plasmic into their code base. So you have your react or Next.js or Gatsby code base or Nuxt or Vue code base.
And you install this client library and what that does. It's it does the same thing of grabbing this generated code from plasmic. But that's all happening at runtime over an API, as opposed to, as you know, pulling that down as source files into your code base. And you know, it's kind of a like a subtle thing, but what that does, what that means is that now when you go into the visual editor or anyone goes into the visual editor and makes changes those changes can be pulled in dynamically live.
And when I say over an API, it doesn't necessarily mean at render time. Like when a visitor is visiting your site, it can mean at build time for the static site generators. Right. And and so that way the users who are crafting these experiences they don't require a developer to then take that and commit it to their code base, do a, git push, go through code review, et cetera. It will just be able to publish and show up, live in the, in the website. So, and in that way, the shape of it is almost more similar to like a headless CMS where you're pulling in data like structured data on data over the wire.
Except here it's not structured based on data. It's actually the final presentational result that you're trying to render. So it doesn't require them going through a layer of rendering through components that you've handwritten. It, it already self renders, if that makes sense.
Andrew: one interesting, really, really interesting thing. You said there is use plasmic to build plasmic. I'm a, I'm a huge fan of dogfooding this podcast is is a great example of that. So like, do you just build out your design system components in plasmic or do you build like full pages? Like what level of atomic design does plasmic fulfill for you in that and that's situation?
Yang: yeah. Good question. So, with our own use case, we actually use it for for some subset of our design system components as well as these screens that compose the components together. So, the design system components this There's a, there's actually a bunch of components that formed the design system that are kind of like display only and not, you know, stateful interactive things.
But then there's a slice of them that are these, like, you know, drop downs and slacks and you know, things that can be a lot more complex where you have to worry a lot about accessibility as well as the functionality. And for those there's this this subsystem within plasmic where you can essentially design your own interactive components like this.
So, we have basically a number of fixed set of different types of components, like, select you know, checkbox for instance. When you drop into plasmic and you create one of these components, it provides you with the starting template that just has some default look and feel.
But you can actually then visually kind of edit what that looks like. And the interesting thing about this is that it doesn't it's not about like tweaking variables in a in a theme or anything like that. It actually you can completely change the layout and Dom structure, et cetera, of these components.
As long as you still have like certain key named elements in them that satisfied like the requirements of a select or have a check box. And as long as you have certain variants of that component that satisfy that, then it will continue to be functional and accessible. And the way that works is when you do generate the code, it actually goes behind the scenes, we wire up those those elements and those variants.
To the functionality using react-aria which is this great library of of just a headless, basically headless behavior for components like this. And they, you know, the team there has put in so much thought and time into crafting this very high quality set of primitives that you know, if you go and look at the series of blog posts that they put out on, just, you know, the amount of thought that goes into a button, which I've learned so much just from following that, that that that work.
Justin: Yeah, for sure.
Yang: That's kind of like the design system piece of, of plasmic. So it's it's cool. It's, it's something that we've never seen elsewhere in terms of like, being able to just visually craft a fully functional and accessible design system. If you want to, I mean, you can also just, you know, use the, the built-in styles and run with that.
And just like tweak a few colors or something like that. But if you, you know, if you think about like a slider for instance, there's, there's actually a lot of, a lot of ways you can design a slider. And it's, it's fun. It's, it's fun to to try and like design, you know, internally come up with various, like, you know, retro themed design system components for for these common like, yeah, selects and whatnot.
Outside of the design systems. Yeah, we then can compose these together into the overarching screens and larger components. And yet the story is always the same that you can just sync these down to the code and interface with them through this like prop overrides, API, and that way attached to the behavior that you want.
[00:11:28] Why create Plasmic?
Justin: So this kind of tool is, is hard to build and it's hard to get. Right. And, and the big problem, or my conjecture, and you probably can speak more to this than I could, as my conjecture about the problem in the space is that it's, you're sort of in this weird in-between state where you're doing something highly technical, you're doing something that like needs sometimes some technical know-how like, you know, for integration into your site or whatever, but it's not, you know, it it's meant to be sort of, non-technical like more approachable for designer marketing.
And there's a lot of constraints and like what you build, who you target. And I mean, I think that gets to the root the matter it's like figuring out who your audience is, is really hard. So could you just talk about like, what, what inspired you to sort of build a tool to solve this problem? And like when you're, when y'all were sort of thinking about starting this business, what was it, what was sort of the impetus of like, Hey, this is the kind of customer that we want to hit.
And like, this is the kind of tool that we can envision. It's like what, what was the sort of like formulation of that?
Yang: Yeah, really great question. And this is actually something that you know, we spend a lot of time thinking about. So, it is a hard problem. We, we I guess the, the initial you know, way this got started was. My co-founder and I, we, you know, we've spent many years prior to that just working at companies big and small and building lots of different products working on various especially, you know, web apps surface areas and, you know, through that, working with designers and other functions on a team and, and also working with design tools.
And it was really through that process that we kind of, started formulating these ideas around. I don't think it's actually a, you know, any, anything super novel. I think, you know, this idea is, you know, something that is talked about a lot actually, but just how, how do you really streamline that workflow where, you know, designers essentially are using these design tools, these vector drawing tools to create these drawings of how something should look and feel, and that's really valuable in and of itself.
It's really the thought process, right? And the time you spent iterating on that that that's the most important you know, job of the designer while incorporating all the feedback from the rest of the team. But then you have this artifact at the end of that, that's this drawing. And then that gets handed off to a developer who hopefully has been in the loop through that whole process.
But ultimately then the developer has to take this drawing throw it away recreate it from scratch by hand using code and inevitably that process results in a ton of discrepancies where things just you know, slipped through the cracks. Right. And so there ends up being more back and forth with the design team on this and just a lot of communication around it.
So the, and, you know, there's, there's like these step improvements to that workflow where if your design tool supports like snippets of CSS, it might elucidate some things. Or if you have like, you know, system of design tokens, et cetera, like that can also help streamline some things.
But ultimately a lot of, a lot of work goes into just that, that process. And a lot of time goes into that process. So, that's kind of how the you know, initial idea was born. And and we started working on this, this tool that essentially our intention for it was for developers to to be able to plug this into their their code base start generating code from these designs and, you know, invite designers to jump in and, and make changes make refinements to design.
And from there maybe designers would ease in more and more into the tool. And the idea was you could build any sort of app product with this like that. You know, and, and we started actually building out this this like early community of, of creators startups small teams, essentially working this way, building, building along with ourselves, you know, building these sometimes sprawling apps mobile apps, mobile web apps et cetera using plasmic.
It was just awesome to see. At the same time we also learned like, you know, we were, we were trying to, you know, basically promote this with some of the larger teams. And and one of the challenges that we saw was basically it, it could be hard to convince you know, everyone on team of like of a single way of doing things, right. And especially one that was such a radical departure from, you know, the way that things are done now. So, and these are usually, you know, the, the, the place that we were raised, the bar, like the core product that the team is working on, which is like, you know, tends to be more risk averse, right.
To bring in random new tools that change the workflow like that. So, you know, for designers the problem was like, okay you know, a common frustration and pain point that we heard from designers was like, Hey you know, getting the actual final product to better reflect and capture the intent of their designs is always like a constant struggle, but then you know, investing in and buy into a new tool for giving them that control.
It puts a lot of responsibility on them that they weren't necessarily ready to take on in terms of like, thinking about the production layout and, and getting things correct like that. And then you know, and then for developers assumptions preferred writing CSS by hand. Right. And so, that was actually one of the initial struggles that we came up against.
However also through our early users you know, we actually learned that a lot of them were just using this to build websites and pages and I mean, that made a lot of sense to us. It's it's these websites that were, yeah. Typically embedded in these code bases like for instance, Next.js code bases commerce websites and marketing websites, et cetera.
And the, the, when, you know, when we were talking to these users, a lot of them were doing this kind of integration so that they could enable the non-developers on their team. Not just designers, but folks in marketing, et cetera, to actually just you know, take the reins. And that also made a lot of sense to us.
So, you know, we saw that that was actually the quickest, the fastest growing use case for us. And so we doubled down on that and and, you know, as, as what I mean, when I say we doubled down on it was we actually started changing a lot of the product to make it a lot more approachable and easier to use and you know, less technical so that it was more inviting for these non-developers to, and, you know, non technical designers to jump in.
And you know, I don't think we're done by any means. I think there's actually where this is like one of the big ongoing projects that we have right now. But I think we made a lot of progress and you know, it's a. It's fun to see.
[00:17:59] Design with Code
Andrew: Yeah, so it's, it seems like it really can fit into many different types of workflows. You've created a very flexible tool. While I was reading through the docs, it mentions that you can import your current design system components. Was it, was I reading that right?
Yang: yeah, yeah. So this is actually one of the probably most important features of this particular use case was you know, on your website, you, you might have a very specific design system or you know, set of interactive components, like, you know, sliders or et cetera. You know, these are very common on various websites.
And you essentially want to empower your your editors to be able to tap into these. And so that's ultimately what code components do is they they're a way for you to register these like react component from your code base and let them be dragging droppable and visually manipulable on the canvas.
One of the challenges with this was figuring out exactly how to do that.
Like, you know, there is a lot of I think a lot of tools in the past that have had various attempts at this, like, you know, framer had their whole code components system where you can essentially repackage your component library in this separate NPM managed project and kind of expose it like that.
There is you know, tools like I forget the name of it. There's this plugin for Figma that lets you essentially take snapshots of your react components, et cetera. So there's these uploading workflows which you know, we. We thought that that actually introduced a lot of friction into the workflow where you have to then think about managing the separate publishing process and keeping those in sync.
And and so it said we were thinking about a much more tightly integrated approach where you essentially what we landed on was this concept called application hosted plasmic. So what that means is you can turn your application into a, a quote-unquote host for the plasmic editor.
And so that means when you start open startup the plasmic studio you it actually starts communicating with this kernel. That's actually running inside of your app. So you, you, you know, NPM installed this kernel you're running it inside your app, and then there are now communicating.
And so from that point on when you are looking at the studio and all the all the art boards that are inside of that studio, those are actually just your app running. So you're actually directly manipulating you know, your real components within your real app, running with your real session, data and production data and whatever.
So that that, you know, remains like I think the most interesting and powerful facet of the, of plasmic, because what does that actually enable you to do? It enables you to bring your design system components. Yes. But also like your real you know, real production data, your real interactions and effects.
And essentially like even things that are not yet built into plasmic. So, you know, animations, et cetera, that we don't support natively. You can just adequate. That essentially exposed to this like react, awesome reveal or what had, and so then you you can essentially essentially extend the platform and it feels hackable in this way that I think is pretty novel.
So,
Andrew: Yeah. That's that seems like an amazing way to like prototype. Your designers can take what you already have in mix and match it to their heart's content. That's really cool. Does a plasmic handle pulling in things like design tokens or anything like that?
Yang: So it lets you define design tokens and there is a way to basically programmatically define a bunch of these tokens in your plasmic project. But there is no similar. The way that there is a register component function for exposing these components directly in plastic.
There's no like similar registered color or something like that. So, assuming your tokens don't change too much, there is you can, you can import them, but it's, it works a little differently than the way that components are
Justin: Going back to that, like being able to sort of use your own maybe sandbox and inside of the product. This is pretty neat because it's like an, it's like the inverse of storybook, right? So the storybook, you have to rebuild your, or like make a fake version of your environment sort of inside of their thing.
And it leads to these weird cases. Like, you know, it's like, I don't know our, our products uses Vite these days. Vite I'm sorry. Sorry. I always say that wrong. Our product uses Vite these days and you know, it's really fast and you know, it's got its own thing. Storybook still uses Webpack there's, you know, a Vite builder, but that's a whole thing to try to configure and get working.
So it's like, you're constantly have this like, drift that you have to sort of mitigate. It's like, okay, now I got to keep this like sandbox environment open. So it was like being able to mitigate that drift by saying, just use my system and like plug it into the tool is incredibly powerful. So that's, that's neat.
Yang: Yeah. I mean, I think that we, you know, this particular use case of letting you build landing pages using the tool is is kind of the main one that we've been seeing so far, but I, I am actually you know, it's basically what you're saying. I, I feel like we, we could take this in a lot of directions and expose a lot more interesting depending on like the exact shape of the components that you expose in the tool and how you expose them.
I think you can take this pretty far. Like we actually use this as our primary vehicle for letting letting users build visually builds dynamic data bound elements on a screen. So, for instance, if you want to display a a gallery roducts from some Shopify collection you could drop in a component.
That's just like a Shopify collection provider that exposes a prop. That's like name of the collection, you know, they choose a collection. And then inside of that it'll just repeat the, the elements that you pass in you know, and times, and being the number of products. And so, then inside of that, you can just start dropping in, you know, product title, product image, et cetera.
And those are just displayed, you know, all that data being passed down through react context. So, you know, this is like one, one example of this. We actually just had a hackathon, a company retreat and, and a little hackathon where you know, one of the projects was putting together a like, in very quickly this like retool Where you know, if you, if you squint, essentially retool is a collection of components that let you specify props that are like expressions data bound expressions, and there's like a central data store. So, yeah, in about like 500 lines of code, mostly just like registering Material UI components you can essentially replicate this like same user experience of like I'm gonna drop in a component that is a rest query for my list of users.
Now I'm going to drop in a table a Material UI table whose value is, you know, that that query dot value. And now I'm going to drop in a text box and I'm going to make that table update its value to be the set of users dot filter and then the contents of the text box. So like, I think it's really interesting to kind of, it was just for fun.
It was just like a you know, a hackathon throwaway projects. But I think it's, it's, it was interesting enough that you know, w we'll probably like, publish a blog post about it as, as you know, just a fun, little dive into how code components work and what you can do with them.
[00:25:12] Import from Figma
Andrew: So switching to another type of import that you can do through plasmic. I was also reading that you can import components directly from Figma, like, and they, they, you can use them as production components. How how'd you get that to work? That seems like magic.
Yang: Oh yeah. It's that one is it's complex it's so, yeah This kind of goes back to our very earliest, you know, angle for the product, which was more as like a tool to help the handoff process for building products and you know, there, yeah, a lot of the teams that we talked to we ourselves you know, we use Figma for a lot of our mock-ups and design iteration.
And yeah, I mean, the idea was really to just give you a leg up, get, get you to a further starting point when it comes to actually building out the real production surface by starting with the imported vector graphics, essentially from, from Figma. So like all the complexity there is this there's this gigantic impedance mismatch between the, this like, proprietary document representation that, you know, Figma uses for for how they, you know, represents essentially rectangles, ellipses all sorts of different primitives.
Right. And then and then you've got the Dom so, a lot of the work that goes into that plugin is essentially doing kind of this reconciliation between these two different representations. And sometimes that can be really complex. Like, you know, a really simple example is in, in Figma you can have what was it borders that are inner or outer borders or, or centered borders and you know, there's no centered borders in, in CSS.
So yeah, there's. Places like that, where we just have to make a best effort kind of, you know, educated guests about, okay, like maybe here we should use inner shadow or outer shadow or, you know, whatever. And so that, you know, so that doesn't puttered like the layout of the rest of the stuff.
And and just a hundred small things like that. Sometimes bigger things like with when you're, when you start dealing with like vectors and vector graphics and groups of them, and that are transformed in various ways. You know, like there's a heuristic we use around when do we want to treat this collection of vectors as a bunch of different SVG objects or a single unified SVG object?
Or when do we even want to treat a rectangle as a div versus an SVG object, et cetera. So like, you know, there's just a bunch of heuristics that we employ to help with that process. But The philosophy that we try to approach in this plugin is to prioritize pixel perfection and trying to make the result that you get after you paste it into plasmic look as close as possible on a pixel, the pixel level. And that may, you know, mean that instead of using border you're using inner shadow. But I think that's like a trade-off that we were you know, willing to, to make. And then from there you're not done, you still have a bunch more work to make this into a production surface.
So this is something we actually try to slap a giant warning onto the Figma plugin to let users know that, Hey, this is not, this is not like magic. This is you know, we try to aim for predictable results instead of instead of magic. And so, You know, we're not going to try and guess like, which of these elements is semantically a button, which of these is semantically and input, et cetera.
You still have to go in plasmic and actually do that manually. So, but I think that already just taking a swath of these, like, the, the pixel pushing and the layout setting, et cetera, off the table can be really valuable, especially if you kind of, follow these the set of guidelines around how to structure your Figma designs to make that process easier.
Like, if you are very rigorous about using auto layout throughout your Figma designs that can, you know, really ease a lot of like the translation, as opposed to just like having free floating, rectangles all over. Right. Now you have something that is fluid with respect to, you know, your viewport size and you know, just a whole bunch of other things too.
So, yeah. But I think the, you know, the thing we'll plug in is definitely. A very it's like, I think there a lot more ideas that we have there as well about how to improve it and how to make it go, I think the next level of depth in this is to think about how to actually preserve component structure in that import and bring these in as well.
But anyway. One one step at a time,
Justin: Yeah, that definitely seems like a really, really hard use case. And, and it's interesting cause like the, the sort of mental modality, like how you think about accomplishing a task in each of these tools is probably very, very different., And especially, you know, as a, as a designer coming in and like working with a design tool, trying to like design something, it's like, you know, whole different beast than like I'm trying to build something that is like production ready.
[00:29:55] Intergrating with your Code
Justin: Which is something else I wanted to ask about. So much of, there's a lot of work beyond just building the UI for a site to get it production ready. So it's like talking about like, Hey, you know, one of the users might be marketing people. One of the things that that a marketing team might want to do is like, understand how people are engaging with this page.
Is that something where. Hey, you know, you should bring your own tools and sort of like couple them with what we provide to be able to, you know, have this learning experience. Or do you have like recommendations for that? Or do you provide like tools under the hood that are easy to hook into or whatever?
So like, I don't know for like A/B testing or for analytics or whatever people might need to accomplish.
Yang: Yeah. A really, really great question. So I think that so far Yeah, we're we've mainly been focused on getting this visual editing experience to a point where you know, for folks coming from a marketing background who are not you know, designers used to staring at Figma or or developers who know HTML, CSS layout making it really welcoming for them.
The direction that actually that we've been trying to push plasmic is making it more and more like a structured almost like a text editor essentially I think that's, that's kind of, a lot of the, you know, when we first started building plasmic just to take a step back, we, because we wanted to keep it really familiar to designers who are used to Figma, et cetera.
The, the initial experience that we dropped you in was one where you could just freeform draw boxes on a screen and did that kind of dragging around. But actually this is a really poor kind of direction to nudge users in when you are trying to build things that are like clean surfaces for the web
Justin: Yeah, you're just making it harder for yourself.
Yang: Yeah. Yeah. It's, it's, it's really hard to, to try and make that into something that's like really nicely responsive, et cetera. And and even just at a practical level, like, you know, having to drag everything down, just because you entered some more text into some higher level div, like it's there's a lot of like these things that while it may on the surface seem, seem like it's simpler to just draw boxes like it's actually harder a lot of ways.
And you know, if you think about how a word doc, like. a word processor works. Like it's not like that. It's it's very blocked. Like, so we actually kind of, you know, changed our default experience to be more block like, and to encourage that as a default. You can, you know, always eject or, you know, take cert specific elements and turn them into a freeform canvas or pop them out of its slotted position.
But that's kind of like the direction that we want to nudge users in and have them fall into this like pit of success when it comes to to lay out. And and that, you know, we've been doing a bunch of work around making that easier. I think the next step for us is, yeah, exactly what you're saying, going beyond the visual editing experience and still focused on, you know, non-developers and even very non-technical users letting them kind of, get more insight.
I would actually break this down into two things there there's more to do on the creation side. So a lot of these folks that are, that are working in growth or marketing, et cetera. They you know, A/B testing personalization scheduled content, this kind of dynamic this level of dynamism to the content that they're creating can be important.
And then there's the, the other side of this, which is the, the feedback. And so, currently, because we kind of integrate so deeply into it and, and essentially you just plug into your existing code base if you have any kind of analytics provider that you're currently using, like, you know, you should see stuff, just show up.
They're kind of no different than any other you know, landing page on your site, but but there are actually some interesting things. We could possibly provide for free just because of how, you know, the shape of the code that we actually generated and how we integrate. And so, you know, this could be things like deeper heatmap analytics on the page, et cetera, but this would be kind of a next step for us.
Andrew: is, Is any type of like version control involved. You mentioned that you can create components with plasmic and then pull them into your code base. And that there's also this live updating mechanism. Does that mean that those components are also live updating components?
Or do you pull in like a version of those components?
Yang: Yeah. So there is a versioning system in plasmic where you can essentially it's taking snapshots of the the element structure that you you've crafted within plasmic. So components that are coming from outside of classmate are not like snapshotted as part of that. We, we actually don't upload any of your code to ourselves or, you know, do anything like that.
So if you're basically reverting to an earlier version it would be just like the layout and stuff that you're, you've created in plasmic. But like, if you have like specific, I don't know YouTube component or something like that, that was from your code base, then it'll still be the latest version of that.
And then but yeah, this, this versioning system it's pretty simple right now. It's, it's just a linear version of history where you essentially whenever you hit publish we kind of nudge you to take a snapshot version of that. So, and this, this history is also actually what powers our cross-project imports.
So, there is this ability to like share components across different projects. But whenever you import a project, it has to be from a specific version of an upstream. So that's another place where the version history interacts with the rest of the product.
[00:35:14] Looking to the Future
Justin: What's what's next for the product? What are the, the big things that you have planned? What are you excited?
Yang: Yeah. I, I'm excited about a lot of things on the product roadmap, but right now our, our immediate goals are you know, there's this set of so there's a system for registering components from your code base. And right now that requires you as a developer to basically do all that upfront work.
It lets you bring whatever you want. But what we've seen actually from a bunch of projects now is that there's also like a very common set of components that people tend to reach for. And and so, you know, being able to provide some of these out of the box would be pretty interesting. So the way we've actually been thinking about how to structure this is actually just having a central NPM namespace, where we basically publish a bunch of these registrations for various common components like reacts slick is a very popular slider library, right.
Slideshow thing. And so, just publishing a very small set of proper registrations for that. Well then let you be able to see that show up automatically in, in plasmic studio for any projects just globally. And then when you sink down this into your code base you can actually pull in that respective bundle from the, you know, from as part of the code that we're generating.
And you know, we're also thinking about how do you, how do you How do we make this more community-driven and sensible so that anyone can kind of add to this pool. But yeah, that's like one of the things we're working on.
And another thing that we're very excited about is is react server components. So a lot of our users building upon these frameworks, like Next.js or on platforms like Shopify or both they you know, one of the draws of these platforms is the performance. So, if if you know, direct to consumer brand goes headless, they you know, one big reason for that can be control and other can be performance.
And so I think that just this this general industry move toward smaller bundles and less JavaScript is, is really good one. And we're, you know, we're actually working right now on how do we how do we make plasmic integrate nicely into that into this kind of second age of of, you know, react and these other frameworks?
I think it's it's really exciting to see, you know, Next.js they're moving in this direction, but also, you know,Shopify's own new framework hydrogen is just starting there. And there's a lot of challenges actually with that with, you know, how do you yeah, not to, not to get too in the weeds, but like, how do you make sure that your components are are loading and fetching data correctly across the boundary and how do you How do you make sure that you can dynamically load components over the wire and then dispatching them as either a client components or server components?
These are all interesting challenges. Another, another related one is like just the move to edge compute infrastructure. So, you know, with CloudFlare workers and also Shopify oxygen these were anything based on V8 isolates, basically. So, you know, one of the restrictions there is you have no more eval
so I think we need to think about like how what shape of integration makes the most sense for these kinds of environments.
Justin: Yeah, that's awesome. It's pretty cool.
Huh?
Andrew: So one question we commonly asked, almost everybody that comes on the show now is what excites you about the future of the web? Do you think no code tools are gonna take over everything? I think I know your answer to that now, but w what's your view?
Yang: Oh I, I think that no-code is, is very interesting, very powerful for a whole class of users. I think, you know, the thing that is the most motivating to me when I hear it from our users is just the theme of empowerment and you know, being able to kind of democratize how and make it possible for users to essentially apply this kind of super power that you and I, and we've we spent years of our lives, you know, training in and, and acquiring.
It is it's I think that's, that's probably like the the most motivating facet of no-code generally across kind of the whole, the whole spectrum, whether you're talking about, you know, tools like like bubble, is that around on one hand or Zapier for automation. And it's so, I mean, I I'm just saying like, it, it kind of goes a step beyond improving efficiency in the workflow on a team. But actually enabling you know, granting this kind of super power to users is, is it's it's off, I think just an intrinsically very motivating drive for me personally. So yeah, no code, I, I do think it there's, we're, we're still at just the very beginning of, of seeing what what is coming out, but at the same time, you know, as, as a developer in the trenches who's, you know, running tons of tons of TypeScript, et cetera, to build these functional accessible components.
It it's also like, I don't see it as being a code killer by any means. You know, I like code, I think code is here to stay. And and I think the, the trick is. The, the shape of that interface between no-code and code and how do you bring these worlds together? Rather than, you know, I think the easy thing to do is build no code products in kind of an island and not think about how to integrate with the rest of the world and you know, interface with code.
Justin: I think to sort of expand on, on what you're saying there and like a bit of a broader sense. One of the things about this, this podcast is really talking about tools and the reason why it's such a joy is because. Like what tools really provide they're the fulcrum that give you leverage to be able to do something that was like impossible to do before.
And, you know, it's like, it's really hard. Like, you know, we know building accessible, performant web apps is hard and you get shit from so many sides because they're like, oh, you're, you're using too much Java script, or you're not doing it this way. Or like, oh, your site's too slow. Or, you know, there's, there's like all these things that come into play and you're like, okay, you know, I want it performant.
I want to use as little code as possible. I want it to be as simple as possible, but I want it to be a good user experience. And I want to do all these things. And it's like really hard. It's really hard to do that. And that's why, you know, I'm sort of, I'm excited about, about tools like plasmic, because it gives you that, or it gives people the leverage to be able to sort of move something that they couldn't before.
Yang: Yeah. I would actually also be really curious where you guys wouldn't want to see these kind of this class of tools, no code visual tools. Go.
Andrew: I liked the space that you guys are occupying, like being, being so in the mix of all of the things we're already doing is really powerful, I think, and it keeps my job safe. So I'm happy about that.
Justin: Yeah, there's, there's this area that I have a particular fondness for marketplaces from a product perspective. I think anytime you can get creative people together and let them sort of like monetize these small movements or these small tools that like gives them a great way to sort of make revenue, but also a great way to share this, this amazing innovation.
So, you know, you look at something like Shopify and Shopify stores or You know, w whatever, there's like, there's a ton of great marketplaces out there. I think there's still really good room for like component marketplaces or like page marketplaces, or, you know, you have people who will build like a, you know, premium set of tailwind components.
Like the Tailwind team did. And that's wonderful, but it's like, you know, sometimes it's just like, here, let me give you this really, really good sort of, you know, small, subset of react components to do this, like one little like niche thing or, you know, whatever it may be. It's like, I, I think that when I was thinking to sort of plasmic and, and where you all like occupy the space, it was like, you know, the, the ability to say, look, I need to build a marketing page.
That's kind of the shape. I just want to like, buy it template for this thing, you know, that has like all this stuff. And then maybe I can customize it or whatever, or buy a theme. Like those, those sorts of things start becoming very powerful and. Again, the reason why I like marketplaces, cause it like fits this really broad need where you give creative people the ability to make money by doing these things that they have the skills to do, you know, like building components or building like really nice layouts or whatever.
And then you give the people on the other side who just really want to solve their problem and move on the leverage to be able to say, you know, I'm just gonna, you know, spend some extra, a little extra money, saved me a lot of extra time, have something that looks a lot better than what I could do. And just like put that in place and sort of move on.
I'm all for.
Yang: Nice.
Andrew: Cool. And with that, I think it's time to move on to tool tips.
[00:43:48] Tooltips
Andrew: So my first tool tip of the week is a react component library. This popped up on my feed a few weeks.
And it looks like just a bunch of really nice react components that are simple to use. And they cover a whole range of things. They even got hooks to do common things. So it's a pretty full featured design system. You get even a rich text editor. So, it's definitely ties into what we were talking about.
It'd be super cool. If you could just have a marketplace where you could see all these different libraries and installed them right into your plasmic app, that sounds, it sounds awesome. Like, I think it's really cool that you guys are trying to leverage the NPM ecosystem in that way and like bring all of these things, like react slick straight into a design tool like that.
I feel like that's going to be one of the superpowers of plasmic for sure. I don't have much to say about it. That it's just a cool little library I found.
Justin: And what's it called Andrew.
Andrew: Oh, I've forgot. Wow. I, yeah, I do it every time. It is called Mantine. Yeah, you shouldn't have, let me run a podcast. It was a bad decision.
Yang: I feel like you guys are so plugged in. How do you, how do you hear about this or learn about this one?
Andrew: oh, I just spent all my day on Twitter. I don't do my job.
Justin: That's that's that's me too. Yeah. Yeah. Twitter is a great source of all things, you know? Interesting. It's very shiny. I actually have the problem of, I have too many tool tips. Like there's so many that just go to waste because they find so much cool stuff is happening on Twitter. Okay.
So. A while back, we did an interview with the fig founders. So fig is a, is a tool for providing auto complete for the terminal. It was, I was talking to one of the founders a while back and they said their eventual vision is like, one of the things that you'd like to do is build a terminal. And I was kinda like, ah, well, you know, there's a lot of terminals out there and people feel pretty strongly attached to their terminals.
I was like, I don't really know how I feel about that. It's like the auto-complete experience would be nice, but like providing it in their own terminal is good. Yeah. And then I stumbled across this tool called warp a warp.dev is the, the site it's is a terminal that's written rust. So it's like pretty performant.
But like it's got some really interesting usability traits to it. It's like your commands are all in these little blocks and you can like, copy the output or copy the command, or like rerun the command with like some prefix. I dunno, it gives you a lot of really nice, nice, like usability improvements.
And I'm actually sort of sold on the idea that actually having a newer better terminal is, is a great idea. Anyway, I found a blog from one their, their engineers this week. So it's Michelle what's, what's the name at the top Andrew?
Andrew: Michelle Lim.
Justin: Michelle Lim so, so Michelle wrote this wonderful and very beautiful article about how they actually do rendering inside of a warp. So warp is a native rust app and it's rendering on the GPU. So it's like, they can't take advantage of like HTML layout stuff. Now it's like, they're doing this with like shaders and like doing a lot of manual rendering there's math that happens, you know, it's like, this is all pretty native and this article is just so it's, it's just such a joy to read and I really highly recommend anybody who's listening to this, just check this article out and have it to share notes.
It just like, you know, how they handle border radius or, you know, like all these like really interesting problems. Anyway, it just, yeah, definitely.
Andrew: Yeah, the, that terminally looks pretty cool too. I'm a big fan of this style of terminal layout, where you have like your more full featured prompt. And then the history is really easy to read. You can see like where it was run and what command was run very easily. So I'm all for that. I was like how they render this air where like just the whole block becomes red.
That's that's a neat little trick right there.
Justin: Yes. When you're navigating back up, you actually navigate in blocks. So you like it like highlights a whole like block and then you have keyboard shortcuts. He's like, you know, do you want to copy the command? Do you want to copy the output? Do you wanna copy both? You know, it's like gives you like really fast ways of doing that.
It's it's, it's I'm really excited about what this team is doing.
Yang: So there's this wasn't on my list originally, but this made me think about this thing that I saw from the Chrome developers recently around how they basically are at the end of this multi-year effort to overhaul the Chrome rendering engine and this rendering engine this current one that we're in is rendering NG.
And and you know, I was recently just like, doing a little bit of digging into this and it's really fascinating kind of learning. I mean, it's, you know, at this point and effort that's been going on for quite a while, but you know, they just, they just kind of, concluded it. And so, you know, I'm, I'm learning, I was reading, they actually, one of the leads on the team published this kind of book.
Let me, I'm trying to, I'm trying to find the link. That book, it was a book on a browser rendering.
Andrew: It's a very important graph right here without rendering NG frustration goes up.
Yang: there is this, this might be the one Roger Dunn engineering. It's like it's work in progress book that overlaps in its topics with just the content that you'll find on the section of the Chrome developers sites on rendering NG. And they're, you know, they, they both talk about like a similar set of concepts around like, display lists and the key data structures that go into rendering. So this, you know, when you were talking about that, you know, made me think about the specific very interesting and very deep rabbit hole around how do you make this, you know, very modern GPU accelerated you know, I think of the browser as like in anything display, you know, how do you make that work?
And yeah, it's, it's just a fascinating book, so I think besides that, that linked to the browser, not engineering, very just I think this might be the content on rendering NG. Here.
Andrew: It's incredible what browsers have to do. It's it's a lot of work. It may kind of like it's sad, but it also kind of makes sense that browsers have kind of consolidated again because what users expect out of a browser has become so much more complicated than what it was in the nineties. You can't just have like 20 different browsers having their own implementations of everything.
Like eventually it's going to move towards consolidation.
Justin: I mean, you know, people complain about slow websites. Sometimes the fact that it works at all is just a, nothing short of a modern day miracle. It's like the sheer amount of engineering hours that is like, you know, been put in. So you can render that five megabytes of JavaScript, you know, it's, it's a lot,
Andrew: Yeah. It's a, that's a thought I've had a lot during my development career of I'm I'm surprised anything works.
Okay. So for my second tool tip I am going to talk about planet scale. Planet scale is an easy way to get up some, my SQL databases, but what's cool about it to me, at least I, I'm not really a database guy is that you could have branches.
And when you propose a migration, it's a lot like making a PR you can have comments on it. So I've been using this to spin up my database for project I've been working on lately called Pitchforkify and I'm just scraping all of Pitchfork, a music review site and putting in a database. And I've been using this to do migrations and learn Prisma also.
So if you need something like this, I'd I check it out.
Yang: Very cool. I've been very curious about this one, actually. And I know that they have this branching as kind of a, a central feature. Is there such a thing as merging branches?
Andrew: So, you basically request I forget what the, yeah. You do a deploy request and you have like, you have a branch locally of your database. It's actually not local. It's also remote. And then you say, I want to deploy this, and then there's a UI in the plant scale UI where you like, can go review them and it'll show you like how the database schema has changed.
And then when you merge it, it'll run all the migrations and everything will be up to date.
Justin: So a lot of this is powered by this engine called Vitess or, yeah, Vitess V I T E S S Venus Vitus. I don't know. Anyway it's an open source project, which powers a lot of this, so it's sort of one of the core parts of their business, but it's super, super interesting technology, you know, it's like, how do you, how do you sort of instantly clone
a database and like do migrations, like interactively and, you know, it's, it's, it's super fascinating.
Yang: Yeah. One of the things that I do wish was in a better state in the Postgres ecosystem which is what we use. And I, I, you know, I, I love Postgres there's a ton of things to love about Postgres. But you know, one thing that I wish were better in that ecosystem were just the state of tooling around online online migrations, essentially, especially online schema migrations you know, there's a whole host of tools available in the, mysql ecosystem for doing zero downtime evolution.
But yeah, it's still, it's still waiting for it in the Postgres world. I think that operationally yeah, my general impression is like my SQL operations tends to have the nicer tooling
Andrew: Yeah. I tried to set it up with Postgres and I spent a while banging my head. I'm like, And this is working. I'm like, oh, Prisma supports Postgres and not plant scale.
Justin: Yeah. I mean, I think the, the underlying under the hood, one of the big things is like Postgres actually just has like supports more data types and it has more hooks into it. So you, you have things like supabase, which could not be built on my SQL, you know, because of all the, all the sort of under the, under the hood things.
My second tool tip of the day is just this little like joyful web app that I stumbled across. I don't know about. You folks out there, but anytime I have a reg ex problem or need to verify regex I'm often going to regexer or which is like very common tool that I refer to.
But sometimes it's just like, you know, I'll pop open, you know, pop up in the debug menu, wherever I'm at the dev tools. And then just like put something in the console. It's like, okay, does this, does this thing work? I was like, is my replace working is my match working anyway. So there's this, there's a site called regexly.js.org.
Which is this really, really simple web app. So you like putting your regex, you put it in a string and it will just show you like what various JavaScript functions will output but it's like, well, we'll test up. What will search output. What will match output. And I think the thing that's like, just so lovely about this, this is just like, it is extremely minimal, extremely simple and very straight to the point.
And it's like, it's a, it's a purist tool. I love it. It's good.
Yang: Oh, I love that already.
Andrew: Yeah, that that's definitely the missing step in my regexer or workflow is actually is not having to run the code. I usually just open up the console.
Justin: Yeah. Same.
Andrew: you got, oh, you got one more or a Zed. It for you, yang.
Yang: Oh, yeah. I do you have one this one is called suspend react, just a little tool library that I came across recently and
Andrew: Uh, from, pmndrs, that guy does a lot of good stuff.
Yang: Yeah. Yeah. That's, that's the one. So, it's a very small low-level library for just doing arbitrary async operations, like the one I'm showing here in kind of a suspense world. So you just say suspend whatever your async operation is. And the reason I I found this library interesting is just because this is like a, this set of primitives is one that I've found myself just writing over and over In a more bespoke way.
As I've been, you know, doing more work within the, this like suspense and react server component world. So, yeah, it's, it's probably one that I would be reaching for a lot more.
Justin: this isn't actually from a singular person it's from a collective. So the the they have a lot of very, very popular, especially react libraries that are sort of under their umbrella. You know,react-spring, react-three-fiber lots of state management libraries and stuff, but it's, it's just a whole group of people that work on open-source stuff together.
Andrew: Cool. Well, I think that wraps it up for tool tips. Uh, Thanks. Coming on yang, this was a, a fun talk always loved talking about front end stuff, and it seems like you're creating a tool that is in its own unique niche. That's very, very flexible and really meets a lot of different people's needs. So thanks for coming on and talking about it.
Yang: Yeah, thanks for having me guys.
Justin: yeah, thanks again Yang that was, it was, it was fun.
Andrew: Well, that's it for this week's episode of devtools.fm, be sure to follow us on YouTube and wherever you consume your podcasts. Thanks for listening.