Claude Opus 5.5 Hands-On: Saying Goodbye to Three.js with Hand-Written 3D in Pure WebGL

Paul Ford's The Web Is More Than Enough sparked a Hacker News discussion about the "boundaries of the web's native capabilities." Simon Willison then offered a rather concrete footnote with a single weekend-morning experiment: modern large models can now hand-write Vanilla JS + WebGL directly to achieve effects that previously required a 3D library like Three.js.

An Experiment Sparked by an HN Comment

Simon Willison came across a Hacker News thread discussing Paul Ford's article, and one comment made him decide to "give it a try." His approach was straightforward: first build a small 3D piece in the browser with Three.js, then ask Claude—within the same conversation thread—to port that code into a Vanilla JS + WebGL version with no 3D library dependencies.

The design of this experiment is itself interesting—it's not generation from scratch, but a "de-dependency" rewrite on top of an existing implementation. For the model, this tests understanding of the underlying graphics APIs more than generating from nothing, because the migration must preserve the original visual structure, camera logic, and rendering pipeline.

The Result of Porting from Three.js to Vanilla WebGL

According to Simon Willison's notes on his personal blog, that morning he built a "Nudibranch themed Faberge Egg" with Three.js, weighing in at 77KB. He then asked Claude to port it to a Vanilla JS version, which produced a 98KB file.

The model he used was Claude Opus 5.5 Medium, running in the regular Claude Chat interface. The two versions are not identical, and Simon also published the conversation log, admitting he "doesn't fully understand why there are differences." But his conclusion is clear: Claude Opus 5.5 is fully capable of doing 3D modeling in Vanilla JS + WebGL without Three.js.

What the Increase in Size Means

The file grew from 77KB to 98KB after the port, and this change itself reveals quite a bit. The Three.js version is smaller because a large amount of general-purpose logic (matrix math, material system, geometry wrappers) is abstracted into the library; the Vanilla version has to write these capabilities explicitly into the code, so the size naturally increases. This isn't the model "being verbose"—it's the inevitable cost of removing dependencies.

For lightweight 3D scenes, this trade-off may not be worthwhile; but if the goal is to reduce external dependencies and simplify the loading chain, then a self-contained single-file implementation is actually more controllable.

Three.js is a JavaScript 3D library built on top of WebGL. It wraps concepts like scene graphs, cameras, materials, geometries, and lighting into high-level objects, so developers can build 3D scenes without directly manipulating shaders and buffers. WebGL, on the other hand, is the low-level graphics API provided by the browser, interfacing directly with the GPU, requiring developers to manage vertex buffers, shader programs, and the render loop themselves. "Vanilla JS + WebGL" means rendering by calling WebGL interfaces directly with native JavaScript, without any 3D wrapper library, so the code must explicitly implement matrix transformations, projection calculations, and other parts that libraries would otherwise handle.

File size here refers to the size of the packaged output. When using Three.js, the final file usually includes the library itself or the modules retained after tree-shaking, but the implementation code for general capabilities like matrix math and the material system is provided uniformly by the library, and the business code only describes the scene. After removing dependencies, these general capabilities must be inlined into the output as source code, causing the size to increase. So the jump from 77KB to 98KB reflects "moving the library's capabilities into your own file" rather than a decline in generation quality. For loading performance, a larger single file means fewer network requests and a simpler dependency chain, but the initial transfer volume is slightly higher—whether it's worth it depends on the specific scenario.

Readability: An Underrated Dimension

After eyeballing the code, Simon gave a candid assessment: he personally found the Three.js version slightly easier to understand. But he quickly added that he rarely looks at the code for these 3D projects, so this "isn't a big deal."

This detail deserves to be highlighted on its own. When AI can generate runnable code, the "human readability" of code is shifting from a primary goal to an optional one. For one-off 3D mini-projects aimed at visual effects, as long as the output runs and behaves as expected, the importance of whether the internal implementation is elegant drops noticeably. But for projects that need long-term maintenance, this dimension remains non-negotiable.

The Limits of a Single-Source Conclusion

It should be noted that the experiment and judgments above mainly come from Simon Willison's personal records and observations—a single-source experience share rather than a systematic evaluation. He himself admits he "doesn't fully understand" the reasons for the differences between the two generations, so this result should not be directly extrapolated to "no 3D scene needs Three.js."

Back to the Original Question of "Is the Web Enough?"

The question posed by the title of Paul Ford's article gets a pragmatic response in this experiment: the capabilities the web platform itself provides (Canvas, WebGL, native JS) are indeed enough to support a considerable amount of creative expression. The problem was never what the platform lacks, but whether developers are willing to write it and able to write it.

The role large models play here is precisely to lower the barrier to "being able to write it." Things that previously required familiarity with shaders, buffers, and render loops to hand-write can now be done through conversational iteration. This doesn't make Three.js redundant—it remains the more efficient and more maintainable choice—but it does change the premise that "you can't do it without a library."

For users, a more realistic strategy is to choose based on the scenario: prioritize mature libraries for rapid prototyping and team collaboration, and consider having the model produce native implementations directly when pursuing extreme lightness or a fully self-contained output.

One-line Summary

Claude ported a Three.js piece to native WebGL, confirming the web platform's capabilities are already sufficient.

Paragraph Summary

The article centers on a weekend experiment by Simon Willison: he first built a small 3D piece with Three.js, then asked Claude Opus 5.5 to port it—within the same conversation thread—into a Vanilla JS + WebGL version with no 3D library dependencies. After the port, the file grew from 77KB to 98KB, which the author explains as the inevitable cost of explicitly taking on the capabilities the library encapsulated after removing dependencies, rather than the model being verbose. The two versions are not identical, and Simon himself admits he doesn't fully understand the reasons for the differences and finds the Three.js version slightly easier to read—though he considers this of little consequence since he rarely reviews such code. The article uses this to respond to Paul Ford's proposition of "whether the web is enough": the platform's capabilities were already sufficient; what large models lower is the barrier to "being able to write it"—but this conclusion is a single-source experience and should not be over-extrapolated.