Nadav Abrahami Co-Founder & Head of Innovation at Wix. Tom Raviv is Head of Developer Relations for Codux.com & Team Lead on Stylable.io. They join the show to talk about the recent release of, "Codux", the first visual IDE for React. They begin the episode as they talk about how they came about building the tool and their experience. Moreover, they talk about its features, components, and impact on users 

Hello, everybody. Welcome to another thrilling episode of JavaScript Jabber. I am Steve Edwards, the host with the face for radio, but the voice for being a mime, but I'm still your host. With me on my panel today, on our panel, excuse me, not just my panel, we have AJ O'Neill with a full mouth. How you doing, AJ?

 Aj:

Yo yo yo, coming at you live with a bowl full of egg.

Egg. Is that real egg or like egg whites? Like I...

No, it's real egg, I think. I mean, if they're still selling that at the store, if it's cheaper than synthetic. 

 Steve:

Okay, but they come from a shell mine comes from a carton a lot of times so that's why I ask so

 Aj:

Yeah, yeah, these ones are, whether real or not, it's from a shell, I think.

 Steve:

That's good.

 Aj:

Actually, I didn't do it, my wife did it, so how do I know?

 Steve:

So you're taking

 Aj:

I don't know. 

 Steve:

your word for it, in other words. Okay, good. Also, coming live from Tel Aviv, Mr. Dan Shapir. How are you doing, Dan? I'm doing

 Aj:

Mm-hmm.

 Steve:

great. I'm doing great.

 Aj:

Yeah

 Steve:

I'm doing great. 

 Dan

Today I'm a traveling reporter today on site with our guest at the WICS Development Offices.

 Steve:

All right, so before we get to the guests, we are talking about Codex. Codex is a new code editor that the geniuses at Wix have come up with. And I so wish I had a duck sound effect, but I don't. So you're gonna have to imagine the quacking. So Dan will throw it to you. Why don't you introduce our guests and take it from there. I'm gonna show you the code. I'm gonna show you the code. I'm gonna show you the code.

 Dan

Sure thing. So like I said, I'm here at the Wix offices and we're going to be talking about this great offering that they've come up with. It's important to note though that this is something that's wholly separate and distinct from the Wix offering, the Wix platform, the Wix service. This is a tool aimed specifically at React developers. And I'll let our guests talk in more detail about it. But first I'd like to introduce them. let them introduce themselves. So please go ahead. I am Madad O'Rami, I'm one of the co-founders of Wix and basically I'm the guy that keeps building visual editor after visual editor after visual editor. With increasing complexity. Golly, started from no code, no code and now it's your code. And I'm Tom, I've been with Wix for close to 10 years now. I started as a script kitty doing components and applications on our internal frameworks, then I'm kind of hopped around the company doing different things. These days I lead development on our open source project called Stylo, which is a topic for another day. And I lead developer relations for Codex. So I'm very glad to be here talking about it. I'm very glad to be here talking about it. I'm very glad to be here talking about Codex. I'm very glad to be here talking about Codex.

 Steve:

All

 Dan

Let's

 Steve:

right,

 Dan

go guys.

 Steve:

so let's get, I'm sorry, go ahead, Dan. Dan.

 Dan

No, basically I guess we were going to say more or less the same thing, which I guess is, what is this thing called, and why should our listeners care about it? Well.

 Steve:

Exactly.

 Dan

I think I'll try to answer that. Maybe I'll start with how we came to build this thing. We've been building visual editors for the last 16 years or so at Wix. And as Tom said, of increasing complexity. But we've always, whenever we're building this editor and the components to show in the viewer, we've always been using the main technologies that frontend developers use today. And we're missing out a visual editor So that's pretty much the main reason we started building this. Because we keep seeing the rift between UI, UX people, and the developers, and the broken cycle of work that they have between them. And we see it for ourselves, and we see it outside. And we just wanted to take what we do with visual editors and take it to the same world of our work. So basically, if I'm understanding you correctly, what you're saying is that there's disconnect between the work that designers, let's say, or UX experts are doing with tools like, I don't know, Figma or something like that. And the JSX code that so many developers are using these days, that there's like a lot of manual effort at the end of the day involved in taking a design that the designer created tool it happens to be and moving it manually into code. Is that an accurate description? Told it. As long as you're using common web practices and frameworks, you don't have a visual editor and it means that the designer has to work in Figma and you have to translate it into whatever it is you're building as a developer. And I think that's the Rift we're going to be talking about. trying to solve here. It's still very early, there's a lot to do, but that's where we're aiming to start to solve. And also I think like there's another thing here where, you know, even if you're talking about the work of the front-end developer by their selves, they're using text, they're using HTML, React, CSS, whatever technologies they've chosen, to represent visual things. And of course we all work with the browser, and we work with the dev tools and all the things that we have to kind of make sure that the things do what we think they should do or what we want them to do. But every developer is, every frontend developer is probably very familiar with like applying a background red to something just to see where it is on the screen to understand where that element has gone to. So even there between the code and the actual visual output that we're producing, that we're building, there is a disconnect there. And a lot of time we would find ourselves jumping between DevTools and code and DevTools and code, kind of in this loop to try and build the thing that we want. Codex lets you do that in one place, because you have both your code running, but all of the insights from running it at the same time. So if I'm thinking about developers, for example, at the company where I work, which is Next Insurance, very often I see them using, let's say two monitors, Visual Studio open on one monitor, usually the browser open in the other, and basically just leveraging hot code reload to make changes in the code and see how it impacts the UI that they're working on. I think you forgot the DevTools in the third window, half of one of them. But apart from that, it's very accurate. We'll try to solve all of those together and give them a good experience together. On top of that, something that it really makes sense to edit visually, we want to give you the tools to edit your code visually. And we are giving you, we want to expand it. And if I understand correctly, this tool is currently targeted at React developers, correct, that what you're, the basic building blocks that you're working with are React components and JSX code. Yeah, in terms of the supported stack Beyond that, it's React and TypeScript. We gain a lot of insights from projects using TypeScript that let us actually do some of the magic that we do. And on the styling side, we currently support CSS, SAS, both in their modules variants as well, and Styliable. With Tailwind support coming up, ever since our launch, the community has let us know everywhere that they want Tailwind for this. So hopefully very soon. We'll have some exciting news on that. But yeah, it's code, it's React, it's TypeScript, it's CSS. So obviously it's a bit difficult to describe something like this in a podcast without actually showing a video or anything, although there are videos on YouTube so our listeners can easily check what it looks like. And they can also, I understand, go to your website, download it for free and try it out. They can download it for free. can try and play with the demo that we have online. It's not fully featured, like it doesn't have the Git integrations and some of the things that have more to do with your local environment, but it definitely gets you the feel of Codex. So essentially, it's

 Aj:

it

 Dan

downloading a client-side application and installing it and using it as a visual editor. Yes, AJ.

 Aj:

It is really important that people know that it is not spelled duck because we were making that joke earlier. It is CODUX. Like what

 Dan

3

 Aj:

I won't say because you said it's not like that.

 Dan

Okay, okay. That's true. We're thinking of changing it though. We really like the two Ducks connotation. So again, but going back to the user experience, or in this case, the developer experience. So I go to the Codex website, I download this as a development tool, I install it on my local computer, I use it in a way that's similar in a lot of ways to, let's say, VS

 Steve:

Thank you.

 Dan

Code. Yeah. It actually does let me edit the code itself in that's built into it. But in addition to that, I also have what I guess you call a board or a stage where I actually see the visual representation of let's say a particular component in a way that's very reminiscent of a storybook, I guess. Yes, plus the fact that you can edit it. Well, it's similar and dissimilar in a way because storybook does not let you edit code. You can create knobs and stuff like that that let you edit create a board that is dynamic. Codex basically reads the TypeScript information of your components and then when creating a board you can just compose it in Codex and you don't need to create it outside. So in our experience we use Codex internally for building Codex. RUX teams build a lot of boards and components in Codex that we then later use in the code.

 Steve:

If I could interrupt a couple quick questions, what is Codex written in? What is it? Rust? Is it go? Is it see? Is it what is what is the tool itself actually written in?

 Dan

uh, TypeScript, React, Stylable, and a handful of third-party libraries, but the core of it is TypeScript, React, and Stylable. Oh, and Electron,

 Steve:

Okay.

 
Aj:

Is it electron or

 Dan

of course. Yeah, Electron, yeah.

 Aj:

what opens it?

 Steve:

Okay, so it's electron.

 Dan

And it looks on

 Steve:

Okay.

 Dan

actually is an interesting fit for us because I know Previously some applications have gotten a lot of lack for choosing electron due to performance reasons or

It's

 Dan

cross-o-s

 Aj:

huge. It's like downloading an operating system.

 Dan

True, true. But for our specific case, I think it kind of works out because if you imagine the parts that kind of bring codex together and the experience that it provides. So we need node because we're going to run your JavaScript and your node code. We need a browser, like a real browser because we actually need to render things as they would be seen on a browser. We're not just using that as some sort of way to deliver like a very rich app. the same way that you would during your development process. And we're wrapping all this together, kind of in a nice cross-OS cross-platform way. So in other words,

 Aj:

Well...

 Dan

electron might be huge, but you're using a lot of the aspects that electron gives you, basically. Yeah.

 Aj:

Well, I think the problem with Electron is that it's unnecessary in terms of, we don't have better tools that are readily available, and I think that's why people still use it. Because if we had something better that was easy to use, then I think people would hop on that bus. But every browser is Chrome now, right? So except for Safari, and Safari is close enough to Chrome that it doesn't matter. And so if you just use the operating system web view, We would ship something that weighs in at kilobytes rather than at hundreds of megabytes. But

 Dan

Yeah,

 Aj:

again.

 Dan

but AJ, this is a development tool. So we're talking about developers downloading a one-time download or something to developers workstation. You know, we are talking about people who download Xcode. So, yeah.

 Aj:

I get

 Dan

Yeah.

 Aj:

it. I get it. I'm just saying that I'm in the camp of I would love to see something like Tori, or that's the one that's in Rust, and there's another one that's in Go that I'm, I think it's called Wally. I can't remember the name of it right now, or Whale, or something like that. But no, that's different. But I would love to see something come along and make it easy for us to just use browser web views. Because it is obnoxious to sit and wait for that download. And I mean, unless you're on gigabit fiber, but I think that's still not. most people. It's

 Dan

Yeah.

 Aj:

a side thing. I'm just saying it's out there. I'm looking forward to it.

 Dan

I totally agree. We were looking for options ourselves. We don't like the weight of Electron. We don't like the time that it takes to build an Electron app. We were looking at Tauri as one of the options. But again, it's something we didn't get time to change yet. And the alternatives are not that ready yet. StackBlitz might be an interesting technology to look at in this context, especially with our new web containers. It could be an interesting match. Anyway, but going back, so it's a tool that you download and install once. It's not something that you need to download or open in the browser each and every time you launch it. You run it as an application and we said it's an editor. So do you envision people using this instead of VS Code alongside VS Code interchangeably with VS Code? Like what's the common use pattern that you envision? I think I can tell you how I use it. First of all, I use it with VS Code and we're the people behind it. I use it with one screen I have codex and another screen I have VS Code. We just added the functionality to go directly to VS Code from a lot of the panels and a lot of the places. There's so many, the ecosystem of VS Code, plugin-wise, is so rich that I don't see anybody changing their ideas soon, and I really don't think that that's what we come to solve. I think the main thing here is that a lot of times it makes sense to see the things visually and to edit them visually, and it's something that needs to live alongside your idea. So talking about plugins, you know, why isn't it just a plugin inside VS Code. Why does it even need to be a separate application that you run alongside it? There's two use cases we're seeing, and already in the users we're seeing, we just launched a couple of months ago, but already we're seeing a lot of places where you have developers that collaborate with UX. And there it a lot of times makes sense for them, for the UX or the product designers, they like to be called these days, for the product designer to edit the pins visually and he doesn't need the escort. So we're definitely looking at adding a VS Code plugin for opening it, opening Codex for a developer. I'm not sure if it will be in place in VS Code because we really need the real estate for a visual editor. So it's not something that I can see as a small panel in VS Code, but we are looking at an extension for opening Codex on a specific file, on a specific project, very fast from VS Code. Now, if I give like a quick of what I recall Kodak's looking like. You have effectively like a stripe on the left, a stripe on the right, a center top part and a center bottom part. Obviously each one can collapse. The part on the left as I recall is like the component hierarchy. Yeah, that's what we call the element streak. And it provides you with, sorry, it provides you with a visual representation of the structure and to a degree, is the state of your application. So it's just sex as a tree, bottom line. But it also includes like logical properties that result during your runtime. So if for example, you have conditionals in your code, right, you have a branching of your component that can render two things, we would represent that branching as a visual indicator. If you have a repeater, something that generates multiple items through a function call, through maps, something like that, and signify all of those color codes. So you actually look as it were at the output of the JSX rather than at the JSX itself. We're looking at it all. We're looking at both. We're synthesizing a view that basically takes a lot of stuff from static analysis of your code, at looking at the JSX, and another part that reads from the actual state in the viewer currently, which what is the rendered JSX as you said. And then we're synthesizing a view from both because if you're looking at the, it's okay to read a repeater, you'll manage to do it in some cases, if you're looking at it from a code, you can see a map statement and assume that it's a repeater inside the J6, but you wouldn't know how many items are rendered and in what states, and if you want to look at computed styles, they won't have the same computed styles that of the time. So you really want to be able to select the three instances and know that they're connected to the same node in the code. That's really cool. I'm thinking about it as you're describing it. That's a tough not to crack. That's a difficult challenge. So anyway, so on the left hand side, we said we have like a tree of the elements or components. On the center top, we have a visual representation of the actual component. Like I said, kind of like storyboard but interactive. Yeah, the state. center bottom part is the actual code like you might see in VS code when you're editing the the the TypeScript or JavaScript code of the component and on the right hand side if it's open you have like a panel for editing styling the CSS and stuff like that. You have three panels on the right side. Okay. You have styles panel for editing styles, computed styles for seeing what's the current panel that basically shows you the properties of the component or element that you're selecting. And of course for each of these panels we're attempting to provide like the best visual experience for it. So the right, so if I'm looking at the properties it's kind of I guess similar to what I might see in the React panel inside the Chrome DevTools. does that is interesting here, even if you look at the architecture wise, the architecture level of it, is that if you look at IDEs, they usually give you information from static analysis of the code. And if you look at DevTools, they usually give you information from the running of the code. And Codex connects both of them. And that means that if you're looking at the you're going to see a method caller, not the value of the method caller. You're going to be able to edit the arguments of the method caller. You're also going to see the computed value of what the method caller has done because we get that from the rendered side. Interesting. So if for example, you have, I don't know, some component that receives like a user object as one of its properties, um, then our visualizers in the panel will automatically from the static generation, pick up the types and the schemas for these properties. so you will have nice visualizer for them. And from the runtime, from the actual code that's being run, we'll extract all the values and kind of show you what's really there so that if you want to change it and edit it, you could do so simply. So I can obviously, I guess, well, obviously, I'm assuming, I can edit the properties of the React component that's currently on the stage and you know their types, like you said, from the TypeScript. So you know that something is Boolean or string or and you validate that and enforce it. And you can also create an appropriate UI like a toggle for Boolean and stuff like that. Exactly. And whenever I change something, I guess it's automatically reflected in that top part that's kind of like a storyboard. And I and I instantly see those the changes that I'm making. That's cool. But the other aspect. is that it's wholly editable, which means that I can add stuff, for example, into it. So I can drag additional child elements or components into the component that I'm currently editing. What's that experience like? As best that you can describe it. So right now we have what we call the add panel, which kind of provides you with overview of all the various HTML elements that you can add, all of the local components that were picked up and discovered automatically in your project so that you could reuse those, as well as third-party components or libraries that you might be using. And then adding them is as simple as searching for the component you want and dragging it over to the element street. So I could theoretically, I don't know if you support it now exactly or not, but I could import what's it called design system and then get all the components in the design system as things that I can add into my components like building blocks. Yep, exactly. Corrulously, you need to basically give us a JSON file that says where the components are. From that point on, we know how to read them and their properties. In a lot of ways, this kind of reminds me of some of the things, if you guys recall Steve the conversation that we had with Steve from Builder. I know that the purpose is really different and the environment is different, but there are definite similarities in that you edit React components using other React components as child components. It's really interesting. Cool. And you said that it works with React. about other frameworks. You know, Steve I think would love to have something like that in view, for view I'm guessing.

 Steve:

Yes, for those of us that are design challenged and CSS challenged, the more visual tools, the better.

 Dan

We'd love to support as many frameworks as we can. We can see how we'll add, we're hoping to add a new JSIX based framework soon. I can't tell you a date yet, but Codex is not built to work on there. The idea is that we're gonna add, at the very least the second framework ourselves and then open it for plugability and hopefully, whether one can add another framework and another framework. So view is a bit unlucky that for some reason it insists on not using JSX

 Steve:

That's a good thing.

 Dan

but yeah so additional JSX frameworks that would be solid, quick, I'm pre-act, is there anyone I'm missing? I don't know I'm not sure. Anyway and what about the meta frameworks? Can I use it and Next.js or remix? So if I said that with Tailwind, we heard a lot of community like enthusiasm and support and requests for codecs to support, then Next is even beyond that. The Next community has definitely let us know that they are interested in this and that they want to see this working with that framework. And we're looking into it. We're definitely deep into the exploration there. And it's with Meta Frameworks, it's a question of kind of like how much magic they do behind the scenes, right? Because their mission is, depends on how you state it, but they want to make their users' lives as easy as possible, so they will try to have things be accessible or easier to use even if, like, it changes the code a bit or it requires some voodoo from them when doing the building of the project. like that. Can you give practical examples of what you mean? What like an example of some magic that next year might be doing behind the scenes in order to streamline the development process? They're like the Wizard of Oz. They're like all the magic. There's forms. There's forms. There's even the building of the images. So next gives you something out of the world. By the way, saying I'm not against the magic, I'm just saying we're struggling to support it. But one of the amazing examples of magic is that when you want to include an image in your project, you're always of the question of different sizes and qualities that you want to use. And they basically, one of the things of magic they did is that they simplified this all for you. You can just request it from a into a convention and they bill it for you. Now another example is one we just saw which is amazing in my eyes as a concept is a method that you write in your model called inter that is there for loading fonts and although you write it and it seems in your code like it's gonna run in runtime when the model is evaluated, a loader just removes it, imports file according to the parameters of the function. Now it's a great time saver, don't get me wrong, it's just a hassle to find all these things and support them. Yeah, because for us if we like at the end of the day we take your component, we render it and then we want to have it be selectable and have it be editable and all those things, the further your component is from like the standard behavior of the technologies that we're supporting and that we're using, React and that has some other process or some other bit that is responsible for processing it or building it is another step for us to support. Understood. So basically you're saying that, for example, the magic of bundlers can get in the way, that bundlers move things around, they modify it. We know that a lot of frameworks are using all sorts of transpilation tricks. Like you said, the further away it gets you from that original code, the more challenging it becomes because you effectively need to kind of reverse engineer it and be able to deal with it. Interesting.

 Steve:

So I have a question. You've mentioned React and TypeScript. If you are, is your code required to be written in TypeScript for Codex to be able to work on the code?

 Dan

Well, it's not required, but we don't support Babel plugins at this time. And the biggest, bigger question here is what you're going to see in the property panels. Cause we rely on typescript types a lot. If you have react pop types, it will also work. Or even just docs that specify type, but you have to have some type information for us to show meaningful property panels. React props types even still a thing. It seems like TypeScript has kind of killed the need. The only reason we actually supported is that TypeScript supports. Okay. So we took what TypeScript had to offer and whatever was easy to support there saying, okay, it's easy. Why not support it here? I agree. I don't see why. I think TypeScript won that role. Yeah, for sure. I would not go back. Yeah, well, you know, we all still remember working in React in JavaScript. The interesting thing is that today, even when you're working in JavaScript, it feels like you're effectively working in TypeScript, because TypeScript is running in your developed environments. You get the type bindings for all the APIs that you're using, for the framework, for what not. And it's also trying to infer as much as it possibly can from your own code. So even when you're using JavaScript, even without something like a J-stock, you're half working in TypeScript anyway. Yeah. All the hands, all the suggestions, it's all there. That's when we build on top of that. So basically even if you're working in JavaScript Steve, but the third party you're using uses TypeScript, you'll see amazing property problems. Now, how long has this tool been out? So about a year ago, we started like a closed alpha with a number of hand-picked partners that kind of were our initial test group, you could say. Then we had a bit of back and forth with that, trying to see that we're actually on target with what we want. And on December 5th, just two and months ago, a little bit more, we released our free public beta. Cool. So currently it's a free public beta Now again, to stress this has nothing to do with the Wix service. So I don't need to register a Wix account. I don't need to do anything with Wix or is it somehow associated with it? A Wix account is required at this point. But I don't need to build a Wix website. No, no, no. It's a completely standalone product meant to run on local development projects, on your machine, and does not currently integrate into Wix or it's offering in any substantial way. So the Wix. Down the line, there are some really interesting options for us there as well, because Wix has a pretty big basket of offerings for users, not just developers, like all of the various systems, all of their integrations that the company has developed and added. So basically what you're saying is that in some ways it's kind of like a Vercel's attitude towards Next, that you can use Next, without any of the Versailles services, but there's obviously bindings which can make it easier for somebody who wants to deploy if they, their next JS application to use Versailles. So you're like kind of saying that I can use Redux wholly independent of Wix, but in the future, it might be that I'll get some benefits from using the tools together. If I'm understanding correctly what you're saying. Yeah, yeah, that's definitely a possibility for towards in the future. For right now, our focus is definitely on gaining adoption, getting codecs in front of as many developers as we can to get their feedback, to kind of see that this serves them well, that it solves a problem, that it increases their efficiency, that it's fun to use. And once we have that, and we can see that our core of the product is stable, then we can start opening up Plugability and opening up additional services and kind of see where the road takes us and what the community wants. And like you said, for now the beta is free to use. And basically what you're getting is just straight on React code, so there's no like any sort of tie-in or something like that that let's say tomorrow I decided I don't want to use codex anymore. It's I just have React code. It's not that something that's in any way tied back to anything proprietary. I think more than that. of the users will think don't create a new project in Codex. They load the existing React project into Codex and edit that. Okay. And in that place, the only thing that we're doing is we're adding one very small dev dependency that's used to render the boards, right? Okay. So that's kind of the integration point for that. Beyond that, there's no telling if a project has used Codex. There's no project and then decided that you didn't like it or wanted something else and you removed it, nobody should be able to tell that it was used. So going back again to our discussion of let's say Next.js, what you're saying is currently I can't easily just open my Next.js project as a whole using Kodax, but I can certainly take part like individual components of that project, and forth from that next JS project. Exactly. The first user we actually the chaired his project with us and showed us what he did based in China he converted his next JS project from using the Muay component library to the Radix one using Codex and it's an existing project it's a next that is the specifics of next like font loading, image loading, some of that stuff we still need to support but whenever it's just a React TypeScript component inside the next project there's no issue. Yeah, there's also going to be other magics like their link component, the way that they handle forms, stuff like that. There's definitely going to be some magic involved. We're probably going to start there with something relatively basic. to kind of start getting, again, feedback and seeing that people find this appropriate for their needs. And next time, as we move forward. Now, Nadav, I remember that when we talked about this, the work that you were doing a few days ago in preparation for this interview, you told me that you had an interesting situation. You didn't go into details where you tried to go down certain paths. into interesting challenges along the way, which kind of caused you to rethink the architecture of the solution that you came up with? Yes, we tried to build a very similar project in weeks, a few years back, but I think the main difference was that instead of relying on open source solutions, some of them were not there yet, we tried to build everything. We basically tried to build the framework for the user, the styling solution for the user, management for the user and on top of that on editor and while doing that what we found out is that the open source just exploded and just we looked at our solutions and we said we wouldn't want to use them at that point. So basically because we were also split up in the work between building these open source solutions and building the editor it was just too much. we fought and we came back to build Codex saying we want to edit what's out there. We don't want to create our own proprietary solution, even if it's open source, it's still going to be ours. We'd rather edit whatever solutions are out there in the industry. So which open source things did you bring into the Codex project, for example? First of all, I'm talking about the stack of the user. In that last solution, in that try we did before, we try to build the stack the user is going to use. I understand. So you kind of were looking, if you want to use our tool, you need to build your things this certain way. Yeah, with this styling solution, with this state management, with this component rendering scheme, it's all. Okay, now you're going the other route, which is kind of trying to be as agnostic as possible and work with whatever the user might have. Exactly. I think that trying to compete with the open source here was the biggest mistake we did here because first of all it moves fast. There's a lot of people in it and they know what they're doing a lot of the times, which is sometimes surprising, but they really, really know what they're doing. So when we realize that and when we realize that the as easily additable to us as the things we were planning to build. Because anyway, it's a code framework. It has to be. If you want to get to real expression, to unlimited expression, you have to have code. And the second that you have code, that the ability becomes harder. You have to read stuff from the rendered result. You have to read stuff from the code using static analysis. And that we're both building the stack of the user and having the same issues, building the editor that we would have if we didn't build the stack. I understand. I'd say we're very much like standing on the shoulders of giants here, primarily with TypeScript. We really like TypeScript. Like we like just about everything that team does and how they communicate and how they iterate and how they make TypeScript. Like TypeScript has improved so much over the years that it has provided us with an incredibly rich set of tools that we can build to actually have and gain meaningful insights. Yeah, I think it's pretty amazing what type, in terms of implementation, I'm not even talking about the language specification, I'm not talking about the tooling, it's pretty amazing what has been happening with the tooling, the language, what's it called, the language server, that you can actually talk to via an API, have it analyze your code and get back from it information VS Code talks to it and I assume you kind of talk to it using essentially the same API or something like that. Oh yeah, we chat with it a lot. We use it, so many features of Codex use that. If we want to know whether to allow dragging into a component, we have to look at its API and see if it accepts JSX children. If you're looking at the property panel, it's there. If you're looking at the style panel, enable add-in classes, it's there. All that's pretty much everywhere in the product, we need to read these specific APIs of TypeScript to use them. That is really cool. This is something I really need to think about because it's a really in the fact that you can introspect code in such a meaningful way. The tooling that is happening as a result of that really interesting. I think it kind of even goes to an extent to stuff like co-pilot and stuff like that although they use you know different things but still it's you know it's all this analysis these days that's happening around code it's really intriguing. I agree I think VS Code did something very nice there for the community and for themselves a few years back when they a format for completions and diagnostics for IDs to talk with language services. And then they released a lot of open source language services for different languages. And that changed a lot of the community and a lot of the different IDs today use this API and these language services for all of the languages. So it gives you something really nice to build on top. I wanted this, basically now I can create a language server for VS code but it will also be for Atom and which others do you remember? Yeah, not often that from my head but it's the one I think also uses it. AJ, correct me if I'm wrong, I'm thinking that Vim uses it as well, no?

 Aj:

Yeah, yeah, the language server protocol is, I think, has gained quite wide adoption across many editors. If you go to their documentation page, it has a diagram that I don't know if it's only hypothetical and illustrative or if it is actual, but it shows several different editors with arrows pointing towards language server and then back out towards node and et cetera.

 Dan

 for what we need specifically. And ideally I'd love in a few years to open that as another open source format for other ready tools and other languages. Yeah, like VLSP. Oh, like a cool, like a, like a visual language tooling sort of a thing. Yeah, yeah. So if you want to do these set You want to edit properties, you want to edit children, you want to add nodes, remove nodes, move nodes, stuff like that, then that sort of thing will be reflected in the API. Although at the end of the day, JSX is still a textual format. So, you know, we're still, you know, we might be thinking in 2D or maybe in the future even 3D visual representation, but currently at the end of the day, we're still editing code. Well, it's definitely a textual format. It just depends which format. So, let's say I want to support one day, components inside codecs. Ideally, even before that, we could define an API that basically says this is the extra things you need to create on top of the LSP format for it to be visually edited. Cool. So just to see where you're currently standing, I also remember from looking at the tool that you've got integrations with Git GitHub so that obviously if you're using it alongside VS Code you can do the Git stuff from VS Code but if it's just a designer working and they don't actually need to edit the code itself they can get the automatic Git integration from Codex itself. They are going to edit the code itself, maybe not visually, but they are going to edit the code itself. Yeah, OK. And so essentially, you can imagine the designer coming to the developer for that classic, I need this moved two pixels to the right and in a different shade of red kind of request. All of those, essentially, should be done in the designer thing side. They know what they want to do. It's completely visual and not like business logic related do with the operation, let the developer review their work. Yeah, like a regular PR. But without the visual editing, most designers can't create that PR. So basically, for better or worse, you're giving the designers a foothold into the coding process. They can access the actual code, do changes in the actual code in a way that for them similar or reminiscent of the tools that they are used to working with, like Figma, or like tools like for editing the CSS, kind of like a webflow or something like that. But it actually impacts the React code directly and they can create, let's say, a pull request from it and let the developer make sure that they're doing everything correctly in terms of the coding standards. and whatnot. Exactly. And I imagine each team will need to find like the flow or the approach that works best for them, like based on the personas of their developers and their designers and how technical or not technical or willing or unwilling they are to collaborate directly on the source. For us, it has worked phenomenally well. Like our designers use codecs to build codecs. And they are able to do quite a bit of heavy lifting in terms of you and the visual aspects of the product without needing to get any of us involved, any of us developers involved. We do review it. And we do review it. And it's okay. We can go back to the designer and say, okay, so you've implemented the right thing, but you've placed this class in the wrong CSS file. So they'll change that. That's fine. And they'll learn for next time. And the entire ping pong of going back and forth, back and forth, just for two pixels, another pixel, change the shade, change the color, change the padding. just let them get it right. Review the change, make sure it's good, send it to production. We actually see that the learning curve, I think, is higher for the specific project than for products. Cause a lot of things are conventions in this specific project. As Tom said, maybe we only keep CSS variables in this project in one CSS file. Or colors and fonts are in specific CSS files and stuff like that. It are conventions of the specific project. I think we have fireworks here. The interesting thing about the Wix offices is that they're actually in the port area of Tel Aviv which is kind of a touristy place so I don't know it seems like there's a bit of fireworks going on outside. Anyway before we kind of conclude with this part is there anything worthwhile noting about the codex that that we didn't ask about that's worth I don't think that we mentioned that it's going to be free for open source forever. We're not sure like what's, how is it going to look down the line in terms of payment and stuff, but we are very clear on the fact that for open source projects it's always going to be free. And for the foreseeable future while we're in our beta that's not going to change and we're again, once more very much interested in people taking it for a spin, giving it a try. know what they think. And again, it's for hardcore React developers. It has, like you said, you need to register with Wix in order to get an account in order to be able to download. But once you download it and use it in your project, it has nothing to do with Wix. You're not hosting it on Wix. You can use it with your existing projects, wherever they run, wherever they're hosted, frameworks, well frameworks that react for now, but meta frameworks and what not, and it's wholly independent of Wix in that regard. Exactly, whatever hosting or production setup you have for your project, that's your business, and we care about the components. Steve, AJ, do you have any additional questions before we start to wrap up?

 Steve:

No sir, mine have all been answered.

 Aj:

I have been playing around with this a little bit. So since we're here, I tweeted it all with a little bit of first time or feedback. But it's the. I would like it if we if we didn't have to log in. Because there's no way to log in. Quick and easy because you do Google sign on doesn't actually work because it's not in an OS Web view. The

 Dan

Yeah.

 Aj:

you don't have an email loop So, you know, and it doesn't work with my password manager. But why, why was, what was the need for the login again? Why, why do I have to log in? Cause this is running on my computer, right? So, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the, I'm going to go back to the,

 Dan

זה עוד כבר בקרוביטה שזה משהו שאתה תראה זה סגל, אני לא אוהב לתואר

 Aj:

Okay. I assume it's part of the monetization strategy. I mean, that's the first thing that cued me in is, oh, this is definitely not free open source forever.

 Dan

unless

 Aj:

But.

 Dan

it becomes one. Yeah. We're not sure yet. Tell you the truth. We know that it's going to be free for open source forever. For private projects. We're still looking at it. It

 Aj:

Well,

 
Dan

will

how

 

probably

 
Aj:

could you

 Dan

take...

 Aj:

know whether something's open source or private?

 Dan

based on license, based on, you know, licensing and public availability is probably the hit there. Yeah.

 Aj:

All right, that was it. That was my, just, I've been trying to play around with this a little bit and going down some rabbit holes as we've been talking. All right.

 Dan

Yeah, you like going down rabbit holes, AJ, don't you?

 Aj:

Well, it's not that I do as much as that I do what I must because I can.

 Dan

So guys, if somebody like AJ wants to find it and play with it and see what it's all about, where do we actually find it? So the website is at codux.com, that's C-O-D-U-X.com. And of course, you're welcome to follow us on Twitter at codux.ide. And we have a Discord community, Vibrant and Kicking. We'd love to see you there as well. There are links on the site and through our various posts and tweets. And we want all the feedback. Basically, we're at the point we just released this thing a couple of months ago and we really want all the feedback you guys can forward us. I can also say like on a personal note, this as you can probably imagine this is not a small project. This is not something that we've cooked up in a week or two or a month or two and after a significant amount of time it's it's really exciting for us to see people Meet Codex for the first time. If they get it, if they don't get it, what they try and succeed, what they try and fail, what they thought of that we, despite having endless discussions about some things, they just nailed in a single operation or a single thought. So it's really fun to kind of be in that place. Yeah, you're in a really magical time, I think, when a product actually goes or service goes live for the very first time. Yeah. You know, that's something not easily replicated this kind of a feeling. I know what you mean. It's different from updating something that's already out there. It's not the same. What about you too, if people want to get in touch with you directly, is that possible? Yeah. What's the best way to go about it? Of course. So me, you can find on Twitter as well at Revivetown. One word, Tom Reviv was taken. I'm

 Steve:

Ha ha.

 Dan

not sure. my last name but it is the company I started so make sense yeah that's by the way that's also worth a discussion sometime and you know it's it's really interesting to be a founder of a multi-billion dollar company that you literally created like with your bare hands I think that's something definitely worth the conversation it's a long one it's been 16 years now it's going to be a long conversation we start that one Yeah.

 Steve:

Yeah, for what it's

 Dan

Yeah.

 Steve:

worth, there's a great video out there on YouTube that there's a few actually that that give you a way to see the editor and, you know, put it into pictures after listening to a description that and we'll have a link for that in the show notes as well.

 Dan

Oh, definitely, definitely. We've had some really nice collaborations with Theo from T3 and with Colby and with Jesse. So like we have all sorts of good people kind of taking it for a spin and seeing, giving their thoughts on it. Yeah, and they put the videos of that spin on YouTube so people can see how they're using it and what they're doing with it. Definitely. Cool.

 Steve:

Alrighty, well thank you gentlemen for coming in and enlightening us about Codex. Quack, quack.

 Dan

You found the

 Steve:

Check

 Dan

effect.

 Steve:

it out. That's my homemade effect there. With that, we'll move on to Picks. Picks are part of the show where we get to talk about other things that we want to talk about that may or may not have anything to do with code or tech or so on. So with that, we will start with AJ. AJ always has fascinating picks. What do you got AJ?

 Aj:

All right, first anti-pick this time, but don't worry, I've

 Steve:

Thank you.

 Aj:

got some

 Steve:

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

 Aj:

good ones too. Apparently.zip is now a TLD. And

 Dan

But

that concerns me, because that seems like a security vulnerability. Because now all of a sudden, links that are being auto translated, text that's being auto translated into links will look like a download to a zip file that somebody posted on a forum, or on Twitter or whatever, but will actually be a link to some site potentially that is maliciously named the name of a popular download.zip, which I guess browsers will catch that, but that unnerves me a little bit. Maybe I shouldn't feel so bad about it, but I kind of do. But good things, good things, good things, good things. Have I got good things for you today? I've got some great things for you today. So, first off, The Beyond Code course is underway. If you'd like to join in, find me and message me on Twitter or whatever. What I'm doing for this phase is live workshops. So I'm not releasing prerecorded material, but I've got material that I've actually done. One of the workshops, another one of the workshops is this Friday, which for those of you listening is probably a month ago. And so if you're interested in the Beyond Code, we're starting with the shell. And we are, And that includes how to, well, it includes basically a lot of not being afraid of things using the best tools and knowing nuances. So I've had both people who are beginners that are basically in tech support looking to get into programming and people who have 30 plus years of experience have both enjoyed and learned the workshop, the very first workshop. And I expect the same to continue because that's how it's designed. So if you want to tag me at underscore.com. or beyond code on Twitter if you wanna find out about that. And the workshops are super cheap right now. There is a price to it, but it's basically just to filter out the type of person who is willing to pay versus the type of person who's not willing to pay and to select at a low cost because there are stumbles and fumbles. And the goal is for me to get feedback to make this that high quality comprehensive course. But anyway, so there's that. That's my self-pick plug, but that's not actually what I was so excited That's just what I said first the grounding mat. There's this there's this thing called an earthing mat And if you're like me and you work in a shed Which is probably no one You but but either way you get static electricity a lot and you touch something on your desk And it goes up and I had this weird thing happen where my ethernet adapter stopped working after a rather large Static shock not only did it stop working It brought down the entire network of the whole house And it's completely scary that one device can propagate through several switches. The best theory I've got so far is that it got stuck in a loop where it was potentially sending pause messages out to the network and those can propagate across switches. So it wasn't just a simple electrical bad voltage but actually was was maybe sending a message and somebody explained the the electrical. electrical reason why this could happen. But it's the most reasonable so far, but it literally brought down my entire network. Everything, the security cameras, the Wi-Fi, every device on the network eventually got whatever this thing was propagating over the course of a few minutes. And it brought down the house and it took me hours to figure out that it was an ethernet adapter plugged into a USB hub. It was insane. So now I have an earthing mat you plug it into the ground of your electrical power, you might first want to make sure that your ground is connected correctly because there are cases where the ground is connected to the neutral wire rather than to the ground and that is could be bad for you, but you plug it in and then you sit down your hands and it's a nice leather mat And and so it feels nice. It looks nice. It doesn't look Cheaper crappy or anything and I actually got two of them. I got one for my feet and one for my hands So I sit on my desk and there's no way that I'm ever gonna statically shock ever again and it's made a huge difference the last week or two that I've had this in terms of my comfort of not being afraid of zapping my keyboard and smarting my hand every time I sit down. I also have for you a wonderful wonderful pick called video speed controller and this is a playback and it's based on the position of the keys, not what the letters mean, and there's a couple of other hot keys too. But so you can easily, without having to go into the menu, and without having, you just, you open up a video and you just hit the button a bunch of times and then you're at 2.5 speed. And most of the players will only let you play back to, you know, 2X at most, and they don't give you nice increments all the times. A lot of times it's just one or 1.5 or two, but sometimes 1.7 is the right number. And so this video speed playback plugin for Chrome, of course I don't use Chrome, not a heathen, I use Brave, but yeah, there's that. And I think those are my picks for y'all today. I'm gonna go ahead and do some editing. I'm gonna go ahead and do some editing. I'm gonna go ahead and do some editing. I'm gonna go ahead and do some editing. I'm gonna go ahead and do some editing. I'm gonna go ahead and do some editing.

 Steve:

Excellent. Thank you AJ I will go next with my picks. I actually have a legitimate pick before I get to the high point of every podcast episode my dad jokes So those of you who are watching this YouTube, I'll show you a picture of it it is a gift my wife got me for me for my birthday this week and She thought it'd be useful since I've been getting into downhill skiing again Over the past couple years. It's made by a company called Hinshark and it's a Bluetooth beanie So it's like a stocking cap beanie. And you'll see it here. And what's cool about it is that it has one on the front, it has lights that you can rotate through as two levels of bright lights and then a flashing blue and red light. So you can look like you're pulling somebody over when you're skiing downhill or something like that. And then it also has two little pieces that sit here in the thing that are speakers that sit in the rim of the hat and they connect by Bluetooth to your phone. So you can have this hat on your keeping your head warm. Any can be listening to music podcasts like JavaScript, Java, or whatever you want to listen to you on your phone while you're skiing or at least while you're keeping your head warm. As somebody that has a perfect head uncovered by hair, I wear a lot of beanies. And so this could be very, very useful. And you can also, you know, talk to it. It has a speaker. So I checked it out with my phone and you can hear it. And it's really good because you can't, unless you got it really cranked up loud, people around you can't really hear what you're listening to. So it's one

 Dan

and

 Steve:

of

 Dan

it

 Steve:

those little

 Dan

should also have

 Steve:

gifts.

 Dan

a camera.

 Steve:

does not have a camera on it I believe just the the audio so but the light is cool because

 Dan

Thank you.

 Steve:

then you can you can blind people or make them or just freak them out by coming out there with red and blue flashing lights and they don't know why it's on your middle of your forehead so

 Dan

and also maybe rear view mirrors.

 Steve:

Yes, yes, yes, that could be. I'm thinking I can have quite a bit of fun with this. So anyway, I'm sorry, what?

 Dan

Nice.

 Steve:

[???]

 Dan

You definitely need night vision.

 Steve:

Yes, yes, for sure. So moving on to the dad jokes of the week. I have decided that at my funeral, what I would like to have is a closed cap casket funeral, but then I would like somebody to take the bouquet off the casket and throw it in the crowd just to see who's next.

 Dan

Thank you. 

 Steve:

Right? Sort of freak people out. And then here's just an observation. I found that having a dog named Shark at the beach was probably a big mistake.

 Dan

Thank you. Bye.

 Steve:

Shark, ah, oh sorry, that's my dog, you know. And then finally, one time I was filling out a job application and sometimes you'll notice they have, or they always wanna know, you know, your previous life experience or work experience. And so I wrote down that I was a pharaoh in 2300 BC. And so I wrote down that I was a pharaoh in 2300 BC. And so I wrote down that I was a pharaoh in 2300 BC.

 Dan

Best experiences, huh, Steve?

 Steve:

vast experience of stretching way back. Somebody wrote that I should have said I was actually a highlander, you know how they're immortal until there's only one, but I like the pharaoh disc as well. I'm not sure if you can see it, but I'm not sure.

 Dan

can be only one. No, that's actually a different thing.

 Steve:

There can be only one, that's right. The first one is the first one.

 Dan

No, that's higher. That's higher? Yeah. 

 Steve:

Yeah, that's Highlander, Sean Connery, and I forget the guy who was

 Dan

Oh, so

 Steve:

the main

 Dan

yeah,

 Steve:

character.

 Dan

that French actor.

 Steve:

Yeah, I

 Dan

Never

 Steve:

forget

 Dan

mind.

 Steve:

it

 Dan

Oh, the French.

 Steve:

too. Great movie.

 Dan

The first

 Steve:

Anyway,

 Dan

one, just a...

 Steve:

yes, the TV show is okay, but the movie was

 Dan

No,

 Steve:

pretty

 Dan

but there

 Steve:

good.

 Dan

was also a second movie, I think, which was like a bismuth.

Oh, that's unfortunate, because that was a great movie. Anyway, Dan, your turn. What do you got for us? I'm not sure. I'm just going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that I'm going to say that

 Dan

Yeah, so really I have a pick and a half. My main pick is another podcast called FedBytes. And this is the reason that I'm shouting it out is that they were kind enough to have me on as a guest in the latest episode. Well, at the time of this recording, not when this comes out, they may have additional episodes afterwards. It's called FedBytes. It's by Joav Ganbar, who was a guest on our podcast a while back, and Roman de Sardlere. They also kind of similar to JS Jabber. They talk about web development technologies and JavaScript and whatnot. And I came on to speak about frameworks, like this kind of a toasty topic of which framework is best and which meta framework will win. And it was kind of an interesting discussion. The first third was actually a conversation about submitting talks and getting into conferences and stuff like that. So if you want more of my voice, if JavaScript Jabber is not enough, then I invite you to listen to that episode in particular and to the FedBytes podcast in general. It's bytes as in biting, not as in bytes like technology, so FedBytes. And my other pick is the same pick that I pick every time, which is the ongoing war in Ukraine, which people tend to forget, but it's still very much ongoing. And a lot of people there are still suffering, so whatever you can do for the people of Ukraine, please do. And those are my picks for today. זה כבר כבר כבר כבר, זה כבר עוד, אבל אני חושב, זה כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר כבר an amazing approach. Really enjoyed playing around with it. And another thing is, I don't know how you can implement it, but I think it's really interesting is Kung Fu specifically for engineers. I think because I do Kung Fu weekly with a trainer that talks a lot while he's training me, and you learn the most amazing things. Like one of the things I noticed after talking to him that close quarters when you're fighting you have to keep an eye on the opponent because if you try to react to vision it takes you so much time compared to reacting to the sense of touch. Just as an engineer I can totally see why the visual processing is so much more resource, it's not CPU, it's not memory, I don't know what it is exactly, but so much more time consuming that if you try to react to the same punch just by vision you cannot and you try to react to it by having an end close by to the end of the opponent so you can even feel the wind of it is moving you can. I think a lot of things like that if you look at it from at Kung Fu or other martial arts just from an engineering standpoint, It's very interesting to see. I think it might be evolutionary. I mean, you know, if something like a snake is trying to bite you, you need to react really, really quickly to that. Whereas with vision, there's a lot more processing that needs to happen, I guess. I think it's the limits of the machine in that case. It's like, of course, it will be better evolutionary if you can see instantaneously. But we're not aware of that. And there's like a huge time gap. There's a huge lag between the world we're seeing the walls that's there and that's one of the places that it becomes evidently clear that it's really nice to play with. Feedback looks, feedback looks all day. And for me, my pick will be also something that I've kind of gone with for many years now. They just wrapped up their second season of the animated series, and that is the legend of Vox Machina. For those who are not familiar, it comes from the House of Critical Role, which is a Twitch stream started by a bunch of nerdy-ass voice actors, as they self-proclaim, where they stream their I don't know, seven, eight years now up to this point. And along the way, they did a Kickstarter to kind of try and get a pilot for one episode of an animated show. It completely blew up and smashed all existing records for TV projects on Kickstarter. So they were able to do a whole season. Amazon stepped in, said, hey, we like this. We're going to add another season and two more episodes to each season. So the second season just wrapped up. the third. For anyone with a bit of inkling in their heart for D&D or high magic fantasy in general, it's hilarious and it's fantastic and I love it.

 Steve:

So with that, we will wrap up. Thank you for Tom and Nadav for coming on and talking about Codex. Quack, quack.

 Dan

It's

 Steve:

We

 Dan

not

 Steve:

will

 Dan

grabbing

 Steve:

have all...

 Dan

us.

 Steve:

I'm sorry, what?

 Dan

Just said thank you so much for having us. It's been an absolute treat to be here and thanks to Ben for inviting us. My

 Steve:

Our pleasure.

 Dan

pleasure. We're going to sample the sound effects. You're the official sound effect of Kodakz for now. I'm sorry,

 Steve:

Okay,

 Dan

but you're the only one who has...

 Steve:

I

 Aj:

That'll

 Steve:

will record

 Aj:

be awesome.

 Steve:

it and send it to you. I will record it

 Dan

Thank

 Steve:

and

 Dan

you.

 Steve:

send

 Dan

Bye.

it to you. I'm so much better than the Aflac doc, believe it or not. As we mentioned before, all these links to videos and et cetera will be in the share notes so that you can peruse them at your leisure. Thank you for coming on and we will talk to you next time on JavaScript Java.