Technically Included (The Best Kind of Included)

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
SlidesGithub
Rate this content

The design-development gap hurts your React projects: slower timelines, compromised quality, and repetitive handoffs. This talk explores the origins of this problem, the differences in language and environment, and offers solutions through processes, tools, and collaboration. Discover how including designers throughout the implementation process helps developers reduce friction, speed up

development, and deliver exceptional UIs.

This talk has been presented at React Summit 2024, check out the latest edition of this React Conference.

FAQ

Incorporating other team members into your projects and code helps achieve better results and better UIs by leveraging cross-functional collaboration.

The speaker started as a web developer, helped found the Wix R&D Academy, organized community efforts and conferences, and led the development of Styliable IO. Currently, the speaker is the head DevRel for Codex.

Codex is a visual development environment designed to work alongside your existing IDE. It integrates with your local environment and supports React and TypeScript code.

Cross-functional teamwork is important because it brings together multiple personas from different aspects of the project, such as design, UX, product, business analysis, and testing, leading to a more holistic and efficient development process.

In the past, developers and designers faced challenges like browser compatibility, limited APIs, and gaps between design tools and web capabilities, which made it difficult to create feasible designs and maintain consistent cross-browser functionality.

Web development tools and processes have evolved with standardized browsers, package management, modern frameworks like React, and faster feature releases. Additionally, there has been a shift towards more collaborative tools and environments.

Staging environments allow stakeholders to access work-in-progress versions of the project, enabling earlier feedback and adjustments, which helps catch issues sooner and improve the final product.

Recommended tools include design systems like Open Props, Tailwind CSS, and Fluent by Microsoft, which help create a shared language and reduce miscommunication between developers and designers.

Designers can be integrated into Agile processes by involving them in sprints, encouraging them to open pull requests, and treating them as partners working towards the same objectives.

Behavior-driven development helps close the communication gap by providing a structured way to define and test the expected behaviors of the application, which can improve understanding and collaboration between team members.

Tom Raviv
Tom Raviv
30 min
14 Jun, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Being technically included leads to better results and UIs. Incorporating multiple team members comes with challenges and compromises. The evolution of tools and technologies has standardized industry practices. Closing the gap between developers and designers requires collaboration and a common source of truth. Embracing change and building trust can improve collaboration between developers and designers.

1. Introduction to Being Technically Included

Short description:

I'm going to talk about being technically included and what that means, how incorporating other team members into your projects leads to better results and UIs. I have over a decade of experience at Wix and have been involved in various community efforts and open source projects. I'm currently the head devrel for Codex, a visual development environment that integrates with your local environment. Working in cross-functional teams is the best way to achieve success.

Hello there, everyone. I am so happy to be here. Thank you for joining me in the illustrious 4.20 time slot here in Amsterdam. I'm going to be talking about being technically included and what that means, how by incorporating other team members into your projects, into your code, you're going to be able to reach better results, better UIs.

So just a quick word about me. As mentioned, over a decade at Wix feels like I found my tribe. I started off as a web developer, did that for a couple of years, then moved on to help found the Wix R&D Academy dealing with internal trainings, but also with building the engineering brand for Wix where I got involved with a lot of community efforts, a lot of open source, and helped organize You Gotta Love FrontEnd, a major conference back home. After that I found myself missing the code just a little bit so I came back to that side of things, helped lead styliable IO, our own open source CSS preprocessor. I would love to talk to you about that at another time.

These days I'm the head devrel for Codex, which is our mandatory plug for this part of the discussion. Here you can see Codex is a visual development environment. It is an application you download and install just like any other IDE but it is meant to run on your React and TypeScript code. It fully integrates into your local environment and is not meant to replace your IDE but rather work side by side with it. If you scan the QR code, you'll find the demos that I'll be running later on, the presentation, as well as all the links to all the Codex stuff. But all this is just to say that I really love building things, and I really love the web. The openness of it, the inclusivity, the ease of getting to visual results, and the best way that I found to work in that regard is to work in cross-functional teams. Working in small tight knit units that involve multiple personas from different aspects of the project, representing the design, the UX, the product, the business, analysts, testing, and so on.

2. Challenges of Incorporating Multiple Team Members

Short description:

Incorporating multiple team members comes with challenges and the constant need for synchronization. Time constraints often lead to compromises, and designers' efforts may not always meet their expectations in production.

But it's not that that goes without any sort of challenges or struggles, right? When you're incorporating that many people, you're facing that constant need to sync things. There are handoffs and meetings and documents and specifications. And as you're kind of going, you end up reaching the state of this endless back and forth of implementation, review, and fixes. And you keep doing that over and over again with your designers, with your product managers, to make sure that things are aligned correctly. But eventually, usually, time runs out, right? And the compromises start to happen. To steal a joke from our designer friends, this is kind of how they feel about it sometimes, right? They put all that effort into creating a bespoke experience, a bespoke design, and in production, their expectations are being let down. But I think it wasn't always like that.

3. Evolution of Tools and Technologies

Short description:

In 2007, developers had a simpler toolset, focused on browser compatibility. Designers faced gaps between legacy tools and web capabilities. Over time, browsers became standardized, package management introduced dependencies, and modern frameworks like React standardized industry practices. The evolution also brought changes to programming languages, such as TypeScript.

So I'd like to invite you to go back in time with me a little bit. Let's go back to 2007. This is back when Britney Spears was still in vogue. This is when YouTube redesigned their homepage to this sexy new layout. And this is when the iPhone came out, which would end up changing a lot of things for us as well.

So what did we do back then, right? Essentially, we had a browser, we had a notepad, plus plus, and with that, you could go really far. Developers were kind of in this together, getting to a visual result was simple, there was a lot less to do. And our focus at the time was also different. We were busy handling browser compatibility, right? Making sure that Internet Explorer and Chrome and Firefox and all the rest are playing nicely together. And of course we had a lot less to work with out of the box. Less APIs, less capabilities. But we did have memes back then as well. So if you've ever had to support Internet Explorer, you're probably going to feel that one. And at the same time, our designer friends were also trying to figure out this new frontier. What can they do? What is possible? What is this strange web and what is it all about? And as they were doing this, they were finding out the gaps between their legacy tools that designers would use and what the web offers and supports. And it was really easy, for example, with Photoshop, to create designs that are simply not possible to create on the web. But despite all of that, the distance between us was a lot smaller. We shared the language, we were playing in the space, the same playground, and we were exploring this new frontier together.

So things continued to evolve. And with the technology and with the time, all sorts of things started to manifest. Browsers became a lot more standardized, right? These days, it's a lot less of a problem. You don't usually have to close that gap. And yearly, they have the interop process that they do in order to make sure that even all of the new features that are coming into HTML, CSS, and so on, are being supported in all of the browsers. Package management entered our world and suddenly we had dependencies. We were able to incorporate code from other developers, from other projects, into ours in a fairly easy way. Modern frameworks like React came and standardized how we do things across the industry. It was easier to jump across projects, across companies, and make sure that you're finding a familiar ground. And lastly, the working groups themselves and the tech committees kind of changed their approach and started releasing a lot more features a lot more fast. And for us, on our side of the development world, the languages and the runtimes drastically changed. Suddenly we have TypeScript and we're writing statically typed code.

4. Closing the Gap: Developers and Designers

Short description:

We had Node.js, which means we are server developers now. Responsibilities grew to include tests, server-side, and responsive accessibility. The technical complexity increased with the introduction of build pipelines. Design tools evolved, but none are native web tools. As roles professionalized, a gap formed between developers and designers. Understanding the medium's capabilities and limitations helps tailor the message and experience. Code is truth.

We had Node.js, which means we are server developers now. And these days, things like Benno and Bun and many other runtimes are coming around in order to try to close various gaps in the technology. Our responsibilities also kept growing. All of a sudden, there's tests and server-side and responsive accessibility. All of those things started to creep into our domain and were part of what we were doing.

All of a sudden, we had a build pipeline. You had to wait for things to happen before you could see things. All of those increased the technical complexity of what we were working on. Our designer friends were not left empty-handed. For them also, all sorts of things started to happen. The professions themselves were shaping up. Trends, themes, usability, responsive, touch capabilities, mobile devices, all of that suddenly became a lot more of a concern for them too. Design tools evolved.

That was definitely a good thing. And I think it's still happening. So if we started off with Photoshop, somewhere along the way we got Sketch. And Sketch was already being kind of mindful about what CSS and the web actually enable and actually support. These days, Figma, Framer, even more modern solutions are coming out there with plugins, with dev extensions, with all sorts of capabilities to try and narrow the gap between the designers and the platform that they're designing for. But none of these tools are native web tools in and of themselves. And so, it always leaves something to be desired. As each role professionalized, this gap kept growing.

Like two ships in the night, we started drifting apart, each group kind of centering in on their own silos. So how can we bring back the love? How can we get that relationship back up and running? I'm not sure a bubble bath and some candlelight are going to do it. And so I'd like to suggest a different approach. I think we're starting off in a really good place, right? This handsome fellow, Marshall McLuhan, coined the phrase, the medium is the message, back in 1964. And essentially what this means is that it doesn't really matter what sort of message you're trying to convey to a person, to a user, to a customer. Whatever that message might be, it is severely impacted by the medium on which you're delivering it. So, for example, an ad to sell a car in a newspaper, or on a TV channel, or on the web, would need to be fundamentally different in order to reach the desired result. And the better you know the capabilities and the limitations of your medium, the better you're able to tailor that message and that experience. The way I see it, code is truth.

5. Closing the Gap: Collaboration and Source of Truth

Short description:

Other stakeholders need to handle their part in the project. Implementing the code is the only source of truth. Developers are the keepers of this truth and decide who has access to it. Collaboration and building on each other's work in real time is essential.

What do I mean by that? Well, it's nice, and some would say imperative, that other stakeholders in the project also handle their stuff. So, let's say the designers have created impeccable designs, the product managers have covered the specification from end to end, and everything is perfect. If it's not implemented in the code, it's not going to reach any user. And so that is the only source of truth that matters at the end of the day. And you, dear people, you're the keepers of this truth. You decide what goes into it, you decide which persons have access to it, who can even see it, and you get to include, or not include, whoever that might be. And you know how annoying it is when you're relying on a different stakeholder, like a server developer to open up an API endpoint, or a designer to fix something before you can actually implement it, and you're left kind of in this place where you're struggling, and you want to do the thing but you're waiting. And so, you don't have to be this Gandalf. You want to let them pass. You want to bring them closer, not create those sort of annoyances. You want to be this Gandalf. You want to be about collaboration. You want to be building on other people's work in real time, and across time.

6. Reconnecting Developers and Designers

Short description:

Developers and designers need to reconnect through a three-part process: tools and process, building a common language, and embracing change. Incorporating staging environments and local development environments can facilitate feedback and collaboration. Using GitHub projects and issues can keep stakeholders close to the reality of production. To build a common language, it's important to avoid misaligned internal names and be mindful of naming pitfalls in design tools. Consider adopting established design systems like Open Props.

So how can we welcome them back into our world? How can we bring them back closer to the realities of the code, and the realities of our production? Well, I think it's a three-part process. We're going to talk about tools and process, we're going to talk about how we can build a common language again, so that we're not talking about different things, we're not using different semantics, and we'll discuss how to embrace change and rebuild that trust. This relationship is not meant to be adversarial. It's meant to be symbiotic. When they succeed, you succeed, when you succeed, they succeed.

So in regards to tools and process, ideally, you want to find the shortest feedback loops as possible, right? If you end up finding that the design is wrong, that the behaviour is not matching your expectation, in production, that's too late. You want to catch that a lot sooner. One of the ways you can do that is by incorporating staging environments, right? So if you have work in progress, as you're kind of going through the process of developing something, you can start creating these staging branches, staging environments, this is an example from Netlify, but Vercel and other companies offer similar capabilities, to let other stakeholders, the less technical perhaps, access to the thing as you're building it. This allows you to get feedback much, much earlier, and to tweak the experience and what you're expecting to receive. Now, you can go further than that, and even set up local development environments for each member in the team, that's what we do at Codex, but it's important to state that it's not just about access to the code itself, it's also about the management of it, right?

So if we're talking about how we manage our code and our tasks and our to-dos, we personally in the Codex team use GitHub projects and GitHub issues. Not because GitHub is the most robust task management system. There are others that have a lot more capabilities, but this keeps all of our stakeholders close to the reality of production, close to the bugs, close to the successes, close to the work in progress. Okay. Next up, how can we build a common language? The first thing I think is important is to avoid misaligned internal names, right? This component can be called a drop-down, or perhaps a select? Maybe the project manager calls it a combo box. That's already a small snag in communication, so maybe we're using a different name. What happens if in two months or three months we decide to add a combo box? We have a collision in terminology, in established understanding, and so that is crucial to avoid. Also, there is the aspect of naming pitfalls in the tools themselves. On the left side, you can see a screenshot from Figma, and on the right side, the developer tools from the browser. The closest thing that Figma probably has to a div is a frame, so already there's some disconnect there in what do you mean, and what does it, what sort of semantic meaning it might carry as well. Even when we're talking about the capabilities within those tools, right, so on the left side, this is the stroke controller from Figma, and on the right side, an MDN screenshot of some border examples. Not everything that you can create and make with the border radius as the spec defines it, as the browser supports it, is reflected in Figma. Not even close. Designers are left not knowing what they can do. Perhaps there's a better design there. Perhaps there's a better way. Some suggestions. First off, you can think about adopting an alphabet, right? Building a design system from scratch is a lot of work and a lot of effort, and sometimes it's easier to take something that's already well established. One example is Open Props. How many people here have heard of Open Props or used Open Props before? Please raise your hand. Okay.

7. Design Tokens and Component Libraries

Short description:

Open Props is a set of subatomic design tokens that can be used in projects. Tailwind CSS uses atomic design tokens. Fluent, a design system by Microsoft, provides tools for both designers and developers. The code and design versions may have slight discrepancies.

Great. Then I'm super happy to tell you about it. So Open Props is a set of subatomic design tokens, essentially CSS custom properties, CSS variables that you get to use in your project, in your code. Side note, there's an excellent video here by Adam Argyle and Jason Langstorf, a tutorial, one and a half hour session that kind of takes you through the ropes. Really, really good. But the building blocks of this are these atomic units, right? So I have these properties, these custom properties, and I have colors, I have gradients. All of these were already fine-tuned to work really well together with each other. Light theme, dark theme, all of that goodness, including some things that you might not usually find in a design system, like easing functions, like all sort of complex borders, and you don't have to use all of it. You can find the pieces that you like, and only adopt those parts.

Moving back. So if Open Props was our alphabet, so to speak, what happens if we're trying to think bigger? Well, we can go further and adopt a vocabulary. Let's think in words, let's think in larger design tokens, so to speak. So Tailwind CSS I'm sure needs no introduction to this audience. But let's think about what we actually can see. One thing I remember, sorry, and that's for the Open Props, if you're using it, it's really important to have both sides of that discussion, the designer and the development, both being reflected, so that if, for example, you have something like this being developed, being worked on, this is Codex running in the background and showing us this example, then I can very easily just select the node that I want, find, let's say, the colour property, the designer can come and look and say, oh, this feels wrong, this looks wrong, perhaps a lighter colour, a higher contrast.

With Tailwind, you're doing a similar thing, but this time instead of using these subatomic units, you're using atomic design tokens, right? So each Tailwind class would have a number of different properties that you're seeing within it and that you can play around with. So once more, if you give access to your designer earlier on, then they can take a look at this component and say, you know what, this part right here, I'm not so sure about, something about the contrast, something about the look and feel, and they can start playing around with it, and they have the Tailwind documentation, sites and examples, all of those, so they can say, OK, maybe that sort of shade, no, that's probably too dark, let's try something in the middle, yep, and they'd reach the result. And the idea is to let them figure that out. You don't want to be the person who's shoving pixels around on the screen just to move a button five pixels left, five pixels right, and have that process happen over and over again. So bring them in, bring them closer, let them do some of that for themselves. So if we've adopted a vocabulary, now we can think even bigger. Perhaps entire sentences. That would probably be something like a component library, a design system, fully baked, ready-made, things like React Spectrum, Mui, Chakra, but in this case, let's talk about Fluent, a design system by Microsoft. You can see that from the get-go, right, from the very first moment, they are talking to you and to designers at the same time. They're making sure that both ends of that process have tools that they can use. So if, for example, we'll jump into this Figma file, and we'll zoom in just a little bit so you can see this nice message component over here, then we can, the designer already has these building blocks, right? They can take them, they can play around with them, and compose them as they like. And then when you get to the code, they are no longer surprised. They know what they're expecting to see. Now, the keen-eyed amongst you might have noticed that the version that we see here in the code and the version that we see here in Figma are not exactly identical, and that's that gap that I mentioned earlier, right? There's always going to be some gap there if the design tools are not native themselves.

8. Embracing Change and Building Trust

Short description:

Design tools may have discrepancies, but they allow designers to experiment and understand how things behave. Embrace change and build trust by supporting, encouraging, and mentoring designers. Include them in technical discussions and invest in their skills. Establish a shared language and consider adopting cross-domain solutions for better collaboration.

Now, the keen-eyed amongst you might have noticed that the version that we see here in the code and the version that we see here in Figma are not exactly identical, and that's that gap that I mentioned earlier, right? There's always going to be some gap there if the design tools are not native themselves. They are mocking the web. They are trying to copy its behavior. And so here, very easily, the designer can come in, play around with the various interactivities, play around with the responsive behavior, and see kind of how things behave and what they do.

Alright. Last part, embracing change and building trust. So if we've sort of drifted apart over time, it's really, I think, crucial to dedicate some effort to kind of ease that learning curve, right? Every learning is an investment. We learn now so that later we can do something with it. Support your designers. Encourage them. Mentor them. Let them be a part of the discussion. And they're not coming for your code. They're not going to replace you. That super complex infinity grid component that you're developing, that's going to stay with you. You're going to get to focus on the things that perhaps drew you to this profession in the first place. The complexity, the interactivity. They're coming to the code. They want to be part of this technical discussion. And you've seen the evolution in the tools themselves. It's kind of where the industry is leading us. As we're professionalising, we're starting to bleed into each other's profession. To wrap this all up, I call for you to include them technically, meaningfully, in a real manner. Invest in their technical skills. Help them learn. Enable easy access for all team members throughout the entire process of development. Not just as a final step. Work together to establish your shared language, both in your tools and in your processes, so that miscommunication is avoided, mistakes are avoided, and you can build that trust between you both. And lastly, consider adopting tools that offer cross-domain solutions that cater to both of your needs. As mentioned, if you scan this QR code, you will see all of the examples, the presentation itself, links to Codex for you to take an interest in.

QnA

Bringing Stakeholders to GitHub

Short description:

We have tutorials on our YouTube channel. Thank you for joining. Let's start with the first question: How did you bring stakeholders to GitHub? Start with a small project to convince them of the value. Keep voices down for better hearing. Pause for design questions.

We have an assortment of tutorials on our YouTube channel for you to check out.

Thank you so much for joining me today. We've got a few questions that are coming in. Make sure you keep your questions coming in as well.

So let's start with the first question. You talked about shared languages and slowly ramping that up to shared tooling. And a question is asking Tom, how did you manage to bring stakeholders to GitHub? For them it's always hard, onboarded, and it failed and sent them back to JIRA. I feel your pain, whoever you are, when you go to JIRA. I'm sorry I felt that in my soul. But what was your experience? I've felt that pain too. We didn't start off with GitHub. We went through JIRA, we went through other solutions. We were constantly in this chase of finding the tool that best reflected our work. And as we were kind of trying out various solutions, we found out that they all miss that certain part. They all miss the connection to the code and to the reality of production. And I think if you need to convince other stakeholders within your project that that's worthwhile, start with some sort of demo, some sort of small project. Don't jump directly into the biggest, most complex part of your project. Take it step by step. And I believe that just like in our cases, they will see the value. You will have less conversations about stuff. They will be more updated and more connected to the real thing.

Awesome. Thank you. I've just got a quick request for those of you in the back. If you are switching rooms, that's totally fine. Do you mind just keeping your voices down so that everyone and maybe some people in the back can hear the speakers as they are answering questions?

Alright. We've got a lot of Kodaks questions. We are asking about Kodaks, the products. What I'm gonna do is I'm gonna pause. We're gonna do some of the design questions from your talk.

Including Designers in Scrum Sprints

Short description:

Incorporating designers in Scrum sprints. Documenting a shared language. No support for React Native in Kodak.

Sure. And then we'll give you some time to answer the questions about Kodaks.

So the next one's about Scrum. We all kind of know about sprints or these methodologies we use. How do you fit designers into them? So this person's asking, how would you fit a designer into a Scrum sprint? So I think if you're kind of helping them go through that hurdle, that initial learning phase, they become a partner. They become someone who's kind of swimming in your lane and trying to get to the same objective. And we use HL to a certain extent. We do sprints. We work with product teams. And our designers are opening pull requests. I get to approve a designer's fix for a part of Kodaks that was broken. This is incredible. It's so much fun.

No, for sure. For sure. And then the next one as well is about documenting a shared language. How to document a shared language so it's easy to access for new people in teams? There are many different ways, I think. You can go for a straight up classic documentation solution, stuff like DocuZero artists and the likes. So you just have your documentation, simple, indexed, searchable, that sort of stuff. If you're trying to cater to designers who tend to be a lot more visually oriented, make sure you're providing them with those sort of examples. And if you're using something like Kodaks, then they're able to jump in directly and interact with the things themselves, play around and see what it feels like. Understand that behavior.

Awesome. Okay. Now, let's jump in some of the Kodaks specific questions that a lot of people really loved at all. So the first question is, does Kodak support React Native? Unfortunately, at this point, no. React Native, while sharing React and its name is still kind of far in terms of functionality, APIs and all of that. We're kind of looking for it in the background, trying to explore if there's a way there. But no promises for anything soon. Awesome.

Semi-automatic Code Generation and Testing

Short description:

Semi-automatic code generation tools and their limitations. The role of testing in bridging the gap between products and design. CodeX as a unique editing environment synced with IDEs.

And then there's another question, which is about semi-automatic code generation from design. So we're bringing designers into these tools, and a lot of these tools say, oh, you can drag things. They promised a dream that Dreamweaver tried to sell me when I first started on my web development journey. But what do you think about these semi-automatic code generation tools? I'll actually start off with Dreamweaver, because that was a really interesting point in time. I know a lot of people who got their start in front-end development by using Dreamweaver. And sure, if you peeked under the hood at the code that was generated, it wasn't pretty to look at. But it still was close enough to the web experience that from there you could take some concepts on. Now, in regards to the generative side of things, I was trying to avoid AI in this talk, but I guess there's no doing that. Those offer great solutions. For example, in Figma, you have stuff like Locify, you have various plugins that let you export CSS variables and even HTML. Those are great in order to allow designers and less technical stakeholders the ability to flesh things out. It's not necessarily going to be the production-grade code, and it's not going to replace your implementation. But if they're trying to convey an idea, or if they're trying to make a proof of concept, then those tools can get you really, really far.

And then we also have another question, which is about testing. So it's great for products and design to get closer to the code, but what happens when it comes to testing these changes? Is that something that just falls on the hands of the devs, though? I think that kind of depends on how you're structured, how your team is structured. Sometimes it will be the devs, sometimes it will be more on the QA side, and perhaps the automation side. Again, when talking with designers, I think visual testing is a big plus, right? Because you want to understand when you went too far, or when something unexpected happened. So that, I think, can kind of help close that gap. But tests are still fundamentally technical in their nature. So at least for now, until we implement some sort of visual testing in CodeX, that sticks with us.

Now, I know that CodeX, there's a few other tools out there, and maybe some people may be familiar with other tools that maybe allow people to visualize some of these components and things. What is something that CodeX, that sets CodeX apart from having maybe a storybook or something else that designers can interact with? So first of all, CodeX is an editing environment, right? We saw this. I was making real-life changes, you saw the stage being updated. And those changes were not just selecting from a set of ready-made properties or controllers that I've wired. It's just the code itself. CodeX is fully synced to the same project that you have open in your IDE, so that whatever change you make in CodeX, you see in your IDE, and whatever change you make in your IDE, you see in CodeX. Both ways, real-time.

Real-time Sync and Behavior-driven Development

Short description:

CodeX enables real-time synchronization with your IDE, allowing changes made in either CodeX or your IDE to be reflected in both environments. Behavior-driven development and domain-driven design can help bridge the communication gap and establish a shared language in testing and project setup. Developers are likened to barbarians, while designers embody a mix of cleric and bard traits.

It's just the code itself. CodeX is fully synced to the same project that you have open in your IDE, so that whatever change you make in CodeX, you see in your IDE, and whatever change you make in your IDE, you see in CodeX. Both ways, real-time.

Awesome. All right, we'll do our last question before the fun one that I've saved for last. But someone has asked, collaboration versus the communication gap and behavior-driven development promises solving it, promises to solve it. Have you had any experience or do you have any thoughts on behavior-driven development? I think we've done quite a bit of testing using behavior-driven methodologies, even within CodeX itself, and that has definitely yielded good results. I think those results are still, within the testing world, more catered toward the developers, the QA engineers, the production engineers, and so on. But that still presents quite a lot. If you want to take it perhaps a step further in establishing that shared language, you can explore domain-driven design, where you actually get to strictly define the contracts, the behaviors, the language of how your project is going to be set up.

Awesome. All right, last but not least, you've got 20 seconds to answer this. Developers and designers are in a D&D party. What class is the developer? What class is the designer? I'm going to go with you. The developer is definitely the barbarian in that relationship. The designer, I don't know, maybe somewhere between a cleric and a bard, somewhere thereabouts. Very spiritual, very creative. I see that. I see that for sure. Folks, can we give Tom a massive round of applause? Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Less Cruft, More Power: Leverage the Power of the Web Platform
C3 Dev Festival 2024C3 Dev Festival 2024
30 min
Less Cruft, More Power: Leverage the Power of the Web Platform
This talk focuses on the powerful features of CSS and HTML that can level up developer skills and enhance web UI. Scroll-driven animations, popover API, and anchor positioning are explored as ways to create dynamic effects, improve performance, and increase accessibility. The talk also emphasizes the benefits of building presentations with CSS and HTML, separating logic from styling, and leveraging core platform features. Wishlist features for the web platform and the challenges of pushing updates across browsers are discussed.
AI-Powered Frontend Development: Building Better UIs Faster
Productivity Conf for Devs and Tech LeadersProductivity Conf for Devs and Tech Leaders
19 min
AI-Powered Frontend Development: Building Better UIs Faster
Today's Talk introduces the use of large language models (LLMs) to enhance front-end development. LLMs can act like our brains by maximizing the good parts and minimizing the bad parts. A demo in Cursor, an IDE, showcases how LLMs can be used with the builder.io Figma plugin. The Talk emphasizes the automation of tasks, such as adding a settings button and resolving errors, with the AI agent. Feedback and manual verification are crucial to ensure desired results. Tests and continuous iteration are recommended for stronger guarantees of correctness. Monitoring and guiding the AI agents is important to stay on track. Connecting to other tools like Figma and using AI prompting can further enhance code generation. The CLI enables code base integration and parallel development. Visual prototyping and seamless updates are possible with the Builder tool. Overall, the Talk highlights how LLMs can revolutionize front-end development by automating tasks, improving efficiency, and facilitating collaboration.
JS on the Big Screen: Making TV Apps
JSNation 2024JSNation 2024
22 min
JS on the Big Screen: Making TV Apps
JavaScript is widely used in web, mobile, and backend development, and now it is also being used to create TV apps. TVs with web-based operating systems can be targeted with JavaScript applications, and React is commonly used for TV app development. React Native allows for cross-platform TV app development, except for Roku. User interactions and focus management are important considerations in TV app development. Performance optimization is crucial for TV apps, as TVs have lower device scores and limited RAM. Spatial virtualization can significantly improve TV app performance.
Nested Interactive Elements: A Nightmare in Accessibility
React Summit 2024React Summit 2024
9 min
Nested Interactive Elements: A Nightmare in Accessibility
Nested Interactive Elements in Nightmare Accessibility can cause issues with screen readers and other assistive tools, making it difficult for users to interact with websites. Mitigation strategies include unnesting elements, using CSS overlay, and being cautious when modifying roles. It is recommended to involve users of assistive tools in focus groups and share solutions online.
Canva’s App UI Kit: Empowering Developers With Modern Web Technologies
React Summit US 2023React Summit US 2023
8 min
Canva’s App UI Kit: Empowering Developers With Modern Web Technologies
Watch video: Canva’s App UI Kit: Empowering Developers With Modern Web Technologies
Welcome to the Canva Tech talk where the Canva tech stack, React component structure, and UI kit for developers are discussed. Canva uses Java, Go, Bash, TypeScript, and React for development. TypeScript, MobX, and React were chosen to enable hundreds of developers to work on the code base productively. Canva's internal component library was explored and released under a semi-open source license, allowing for quick delivery and sharing of improvements with the community. The developer community has added numerous app integrations accessible to Canva's 150 million monthly active users.
Ship Your UI Faster With Turborepo
DevOps.js Conf 2024DevOps.js Conf 2024
21 min
Ship Your UI Faster With Turborepo
The Turboverse focuses on making the development process faster and more efficient. TurboPak is an incremental bundler with function-level caching, and TurboRepo is a high-performance build system with features like incremental building, remote caching, and parallel execution. TurboRepo can optimize task runners, set up monorepos, and speed up development time. vclink-repo enables seamless integration with the Vercel remote cache, and Conformance and Codoners provide static analysis and automated code reviews. TurboPak and TurboRepo offer faster CI processes and exciting advancements in web bundling.