Code Editor and No-Code Editor Relationship
MyWebAR gives you two ways to build augmented reality experiences. The No-Code Editor lets you create AR projects visually by dragging and dropping elements, while the Code Editor lets developers write custom code for more advanced functionality.
Whether you're a creator who prefers visual tools, a developer who wants full control, or someone working in a team with both types of users, understanding how these editors interact will help you plan and build better AR experiences.
Whether you're a creator who prefers visual tools, a developer who wants full control, or someone working in a team with both types of users, understanding how these editors interact will help you plan and build better AR experiences.
The Relationship Between Editors
When you save your Code Editor project, everything you created gets packaged into a single file that’s stored inside your No-Code Editor project. This file contains all your 3D objects, animations, scripts, and logic bundled together. The No-Code Editor can display and run everything in this file, but it sees it as one complete unit rather than individual pieces.
This means the No-Code Editor won't let you select specific objects from your Code Editor scene and add behaviors to them using the visual tools. If you built a 3D character in the Code Editor, you can't later go into the No-Code Editor and use its built-in features to make that character play animation when tapped. The character exists inside that packaged file, and the No-Code Editor simply runs whatever instructions you already programmed.
If you need to change logic or function, you need to go back to the Code Editor, make your adjustments, and save again.
This separation keeps both systems stable and prevents conflicts between visual configurations and custom code.
This means the No-Code Editor won't let you select specific objects from your Code Editor scene and add behaviors to them using the visual tools. If you built a 3D character in the Code Editor, you can't later go into the No-Code Editor and use its built-in features to make that character play animation when tapped. The character exists inside that packaged file, and the No-Code Editor simply runs whatever instructions you already programmed.
If you need to change logic or function, you need to go back to the Code Editor, make your adjustments, and save again.
This separation keeps both systems stable and prevents conflicts between visual configurations and custom code.
How Your Code Editor Work Appears in the No-Code Editor
When you save your Code Editor project, everything you created gets packaged into a single file that’s stored inside your No-Code Editor project. This file contains all your 3D objects, animations, scripts, and logic bundled together. The No-Code Editor can display and run everything in this file, but it sees it as one complete unit rather than individual pieces.
This means the No-Code Editor won't let you select specific objects from your Code Editor scene and add behaviors to them using the visual tools. If you built a 3D character in the Code Editor, you can't later go into the No-Code Editor and use its built-in features to make that character play animation when tapped. The character exists inside that packaged file, and the No-Code Editor simply runs whatever instructions you already programmed.
If you need to change logic or function, you need to go back to the Code Editor, make your adjustments, and save again.
This separation keeps both systems stable and prevents conflicts between visual configurations and custom code.
This means the No-Code Editor won't let you select specific objects from your Code Editor scene and add behaviors to them using the visual tools. If you built a 3D character in the Code Editor, you can't later go into the No-Code Editor and use its built-in features to make that character play animation when tapped. The character exists inside that packaged file, and the No-Code Editor simply runs whatever instructions you already programmed.
If you need to change logic or function, you need to go back to the Code Editor, make your adjustments, and save again.
This separation keeps both systems stable and prevents conflicts between visual configurations and custom code.
Adding Custom Functionality to Your Content
If you place a 3D model of a car using the No-Code Editor and then write code in the Code Editor, that code cannot control or modify the car. You can't make the car's wheels spin, change its color, or move it around using your custom code. The car exists in the No-Code Editor's space, and your code exists in the Code Editor's space.
If you want to add custom programming to any content, whether that's a 3D model, video, image, or anything else, you need to load that content inside the Code Editor using three.js, which is a popular tool for creating 3D graphics on the web.
Imagine you have a 3D model of a product, perhaps a sneaker for a shoe company's AR experience. You want this sneaker to respond to user interactions in a unique way. When someone taps different parts of the shoe, you want information panels to appear with details about those specific features. The No-Code Editor's standard tap behaviors might not support this level of detail.
To make this work, you would load the sneaker model directly in the Code Editor rather than placing it through the No-Code Editor. Inside the Code Editor, you use three.js to import the model, and then you write code that detects where the user taps and responds accordingly. All of this logic lives together in the Code Editor, which means it all gets packaged into that single file when you save to the No-Code Editor.
The key insight is that custom code can only control content that lives in the same space. By loading your sneaker in the Code Editor, you bring it into the same space as your code, making full customization possible.
This applies to any type of content. Videos that need custom playback controls, images that need to transform in specific ways, 3D models that need complex animations, all of these should be loaded in the Code Editor if you want to control them with custom code.
If you want to add custom programming to any content, whether that's a 3D model, video, image, or anything else, you need to load that content inside the Code Editor using three.js, which is a popular tool for creating 3D graphics on the web.
Imagine you have a 3D model of a product, perhaps a sneaker for a shoe company's AR experience. You want this sneaker to respond to user interactions in a unique way. When someone taps different parts of the shoe, you want information panels to appear with details about those specific features. The No-Code Editor's standard tap behaviors might not support this level of detail.
To make this work, you would load the sneaker model directly in the Code Editor rather than placing it through the No-Code Editor. Inside the Code Editor, you use three.js to import the model, and then you write code that detects where the user taps and responds accordingly. All of this logic lives together in the Code Editor, which means it all gets packaged into that single file when you save to the No-Code Editor.
The key insight is that custom code can only control content that lives in the same space. By loading your sneaker in the Code Editor, you bring it into the same space as your code, making full customization possible.
This applies to any type of content. Videos that need custom playback controls, images that need to transform in specific ways, 3D models that need complex animations, all of these should be loaded in the Code Editor if you want to control them with custom code.
Choosing the Right Editor for Your Needs
Understanding when to use each editor will help you work more efficiently and avoid frustration. Each tool has its strengths, and the best choice depends on what you're trying to accomplish.
The No-Code Editor works well when you want to quickly build AR experiences using the standard features MyWebAR provides. If you need to place a 3D model in AR, make it appear when someone scans an image, and add a simple animation or tap interaction, the No-Code Editor handles all of this out of the box. You can see your changes immediately, experiment with different configurations, and build complete experiences without writing a single line of code.
The No-Code Editor is also faster for iteration. Making changes is as simple as adjusting settings or dragging elements to new positions. You don't need to understand programming concepts, and you don't risk introducing bugs through typos or logic errors. For straightforward projects, or for parts of complex projects that don't need custom behavior, the No-Code Editor is usually the better choice.
The Code Editor becomes valuable when you need something the standard features don't offer. Perhaps you want objects to behave in a specific way that isn't available in the No-Code Editor's options. For example, you may need objects to respond to complex conditions, like changing appearance based on the time of day or the user's location, make a 3D model appear once the video finishes playing, etc.
For developers comfortable with code, the Code Editor opens up possibilities that would otherwise be unavailable. For teams with both technical and non-technical members, it allows each person to contribute using the tools that match their skills.
The No-Code Editor works well when you want to quickly build AR experiences using the standard features MyWebAR provides. If you need to place a 3D model in AR, make it appear when someone scans an image, and add a simple animation or tap interaction, the No-Code Editor handles all of this out of the box. You can see your changes immediately, experiment with different configurations, and build complete experiences without writing a single line of code.
The No-Code Editor is also faster for iteration. Making changes is as simple as adjusting settings or dragging elements to new positions. You don't need to understand programming concepts, and you don't risk introducing bugs through typos or logic errors. For straightforward projects, or for parts of complex projects that don't need custom behavior, the No-Code Editor is usually the better choice.
The Code Editor becomes valuable when you need something the standard features don't offer. Perhaps you want objects to behave in a specific way that isn't available in the No-Code Editor's options. For example, you may need objects to respond to complex conditions, like changing appearance based on the time of day or the user's location, make a 3D model appear once the video finishes playing, etc.
For developers comfortable with code, the Code Editor opens up possibilities that would otherwise be unavailable. For teams with both technical and non-technical members, it allows each person to contribute using the tools that match their skills.
Planning Your Project Structure
Many projects use both editors together, combining the ease of the No-Code Editor with the power of the Code Editor. Understanding how to structure these hybrid projects will help you get the best of both worlds.
The key principle is simple: put content in the editor that matches how you want to control it. Content that needs custom code goes in the Code Editor. Content that works fine with standard behaviors stays in the No-Code Editor.
If you need two elements to interact with each other, they both need to live in the same editor. Usually, this means building both in the Code Editor if custom interaction between them is required.
Before you start building, take some time to think about what each piece of your AR experience needs to do. This planning will save you from having to rebuild content in a different editor later.
Ask yourself these questions about each element in your experience. Does this element need custom behavior that isn't available in the No-Code Editor? Does this element need to interact with other elements that have custom behavior? Will I need to modify this element's behavior through code?
If you answered yes to any of these questions, that element should probably live in the Code Editor. If you answered no to all of them, the No-Code Editor is likely the simpler choice.
Also consider your team's skills and workflow. If you're working alone and comfortable with code, you might prefer building more in the Code Editor for consistency. If you're working with a team that includes non-technical members, keeping as much as possible in the No-Code Editor lets everyone contribute to the project.
Finally, think about future maintenance. Projects built entirely in the No-Code Editor are often easier to update later, since changes can be made visually without diving into code. Code Editor projects offer more flexibility but require someone with programming knowledge to modify them.
The key principle is simple: put content in the editor that matches how you want to control it. Content that needs custom code goes in the Code Editor. Content that works fine with standard behaviors stays in the No-Code Editor.
If you need two elements to interact with each other, they both need to live in the same editor. Usually, this means building both in the Code Editor if custom interaction between them is required.
Before you start building, take some time to think about what each piece of your AR experience needs to do. This planning will save you from having to rebuild content in a different editor later.
Ask yourself these questions about each element in your experience. Does this element need custom behavior that isn't available in the No-Code Editor? Does this element need to interact with other elements that have custom behavior? Will I need to modify this element's behavior through code?
If you answered yes to any of these questions, that element should probably live in the Code Editor. If you answered no to all of them, the No-Code Editor is likely the simpler choice.
Also consider your team's skills and workflow. If you're working alone and comfortable with code, you might prefer building more in the Code Editor for consistency. If you're working with a team that includes non-technical members, keeping as much as possible in the No-Code Editor lets everyone contribute to the project.
Finally, think about future maintenance. Projects built entirely in the No-Code Editor are often easier to update later, since changes can be made visually without diving into code. Code Editor projects offer more flexibility but require someone with programming knowledge to modify them.
Common Scenarios and Solutions
To help solidify these concepts, let's look at a few common scenarios and how you might approach them.
Case One: You want to create an AR business card that shows your contact information and a 3D version of your company logo when scanned. The logo should slowly rotate to catch attention.
This project can be built entirely in the No-Code Editor. The contact information is just text or images, and a simple rotation animation is available through the standard features.
Case Two: You're building an AR game where users tap floating objects to score points. The objects need to move in random patterns, speed up as the game progresses, and track the user's score.
This project needs the Code Editor. The random movement patterns, progressive difficulty, and score tracking all require custom logic that the No-Code Editor can't provide.
Case Three: You're creating an AR experience for a retail store that shows products in the customer's space. When customers tap a product, they should see a buy button that links to the online store.
This project could go either way. If the buy button is straightforward, the No-Code Editor might handle it fine. If you need custom logic around the button, such as showing different prices based on the customer's location or tracking analytics in a specific way, you'd want to build the interactive part in the Code Editor.
Case One: You want to create an AR business card that shows your contact information and a 3D version of your company logo when scanned. The logo should slowly rotate to catch attention.
This project can be built entirely in the No-Code Editor. The contact information is just text or images, and a simple rotation animation is available through the standard features.
Case Two: You're building an AR game where users tap floating objects to score points. The objects need to move in random patterns, speed up as the game progresses, and track the user's score.
This project needs the Code Editor. The random movement patterns, progressive difficulty, and score tracking all require custom logic that the No-Code Editor can't provide.
Case Three: You're creating an AR experience for a retail store that shows products in the customer's space. When customers tap a product, they should see a buy button that links to the online store.
This project could go either way. If the buy button is straightforward, the No-Code Editor might handle it fine. If you need custom logic around the button, such as showing different prices based on the customer's location or tracking analytics in a specific way, you'd want to build the interactive part in the Code Editor.