3D Web-Based Experience Three.js vs Unity

When it comes to developing web-based applications, choosing the right tool can significantly impact both the process and the final product. This blog examines the costs, coding requirements, and user interface capabilities of two popular platforms: Unity and ThreeJS. While both are initially free to use, hidden expenses and additional publication fees can arise, particularly with Unity. The coding experience varies greatly between the two, ThreeJS demands a deep understanding of multiple coding languages, whereas Unity offers an environment with a flexibility to have intense levels of coding to no code at all. Furthermore, the user experience in Unity is enhanced by its intuitive editor window, providing real-time visual feedback that ThreeJS lacks. However, the trade-off comes in the form of flexibility and control, where ThreeJS excels, especially for complex, highly customized projects. Understanding these differences is crucial for developers at VAEZR Studio and beyond to select the most suitable tool for their specific project needs.

The Costs

The average person may look at the online pricing and see that both are available for free and skip this section. However, it’s not as simple as that. Yes, ThreeJS is free and right now Unity offers a personal plan that is free for them. However, as a developer, you may see some added costs for Unity that aren’t obvious on the surface. For example, here at VAEZR Studio we are building for commercial use and meet certain thresholds as a company which means we have to pay for a license for each developer. There is also a great community for Unity that consists of an “Asset store” that allows you to purchase additional resources to include in your project although these are not required. Both ThreeJS and Unity will require additional publication fees that are not directly associated with either such as hosting your web app on AWS.

The Code

Unity and ThreeJS in terms of coding are incredibly different. Unity’s development platform can have varying levels of coding difficulty. UI, static objects in the scene, and even Input systems can all be managed without the user having to code at all. However, when dealing with more complex experiences or dynamic objects one must learn a bit of the C# language to get their desired result. On the other hand, ThreeJS is severely dominated by code. To even get the application to run you have to begin coding. ThreeJS is a Javascript library and therefore you have to know the basics of HTML, CSS, and JS. Not to mention adding something as simple as a light isn’t a drag-and-drop maneuver but rather a line or two of code. Being heavily code-dominated does have its advantages. 

The control of the developer has increased exponentially as they want to do more and more complex mechanisms. For example, Unity, on its own, has a harsh stop when it comes to accessing user-specific information such as location for WebGL and has to be done either by a third-party API request or a js plugin which you commonly either have to purchase or create yourself. This can add quite a bit of complexity as it must override the system’s defaults and pass information between the two different coding languages, which is not impossible by any means, just more complex and costly.

The Dreaded Editor Window

One of the biggest advantages Unity has over ThreeJS is the editor window itself. In Unity, the developer is given a visualization of their project as they are developing. If you add a square into the scene it displays in the editor window and you can scale the object, move its position, adjust its rotation and so much more just by using your mouse. Meanwhile, to do all of this in three js you have to either do calculations to simply adjust position or do a form of guess and check or go through the process of adding variables to a Graphic User Interface (GUI) to be able to edit them in real-time. Doing this in three js makes for a much more extensive process to simply stage your environment. Even though there are extensions available to help solve this issue; very few are applicable to every situation.

In the same sense, when it comes to front-end development work such as UI Unity is also incredibly beginner friendly. With just a click of a button, Unity adds a fully customizable UI element. The one downside to this is Unity only has a limited amount of UI elements you can add. Which will be enough for the average user, but not for extremely complex cases. You may have to install extra plugins or compromise your vision for lack of UI options. When it comes to threeJS there is no lack of possibilities for UI, all of your UI can be done with HTML and CSS, react, or any number of methods. One downfall to this though, is it is not at all as easy to use as Unity is. None of it is drag and drop. All of it is, again, a form of math, and the options are limitless which many times causes a user to feel overwhelmed by the options without a clear direction of where to go or what to do next to add something as simple as a button.

VAEZR Studio

At VAEZR Studio, we began with using Unity for every AR and VR Project that came our way due to our familiarity with it and its popularity in the Extended Reality realm. As time went on and projects became seemingly more complex; we decided to search for other options. Specifically, in terms of our web-based AR experiences such as Activated Graphics. It didn’t take long before we discovered ThreeJS was an applicable solution for AR on the web. A few individuals in our team became certified to better our understanding of its capabilities. Soon we were able to add ThreeJS to our repertoire and switch some more complex projects over from Unity. By doing this, we decrease load-time and have more control over when assets become available to users. We are also able to better customize permissions access which leads to better camera quality. This doesn’t mean we have done away with Unity as a whole. We still use Unity for many of our projects. Almost all of our virtual reality applications are created with Unity as well as our apps. The biggest trade-off for us when using Unity was the load-time and permissions access that was dependent on the user’s preferred browser and settings. However, when it comes to installed applications, with the proper requests, these settings are more accessible to us as developers. The load-time on an application isn’t as strong of an issue compared to the website due to the need to install the app to the device which cuts down load-time per access. This allows us to utilize the strengths of both tools while decreasing the effects of their weaknesses.

The Conclusion

While both ThreeJS and Unity have their benefits and pitfalls, when dealing with web-app development it comes down to your capabilities and your product to decide which works best for you. Overall, Unity is better for projects with fewer bells and whistles. Since Unity has a little bit more weight to the product, limiting any load time is necessary for a clean-usable web-based experience. Unity also, is more user-friendly, and therefore if you have little coding background the tradeoff between the two may be worth it to not have to build your skills from the ground up. However, for a complicated product such as one that involves Augmented Reality, ThreeJS has proven to be easier to control load times and complex permissions than Unity has been built out for. Overall, both ThreeJS and Unity have their subject matters and should be used when the time is right. At VAEZR Studio, we will use either depending on project demands.