DEV Community: Michael Darasimi Jace

If Your “3D Website” Is Just an AI-Generated Video in the Hero Section, Stop Calling It 3D Development.

Michael Darasimi Jace — Thu, 22 Oct 2026 19:45:12 +0000

I'm probably going to offend a lot of portfolio developers with this one, but somebody needs to say it.

Putting an AI-generated video of a futuristic object in your hero section, adding some text animations, and calling the result an immersive 3D website doesn't automatically make you a 3D web developer.

You generated a video.

You embedded it.

You animated some text around it.

Congratulations. But what exactly did you engineer?

Where's the actual 3D scene?

Where's the camera control?

Where's the interaction between the user's scroll and the object's position?

Where's the ability to manipulate the object, change its state, or explore the scene in real time?

If the entire experience is a pre-rendered video playing inside a section, the user isn't interacting with a 3D world. They're watching a video designed to LOOK like one.

And before somebody jumps into the comments with "but the result looks good," that's not my argument.

A website can look incredible without containing a single real-time 3D object. There's absolutely nothing wrong with using video, either.

The problem starts when developers confuse visual output with technical implementation

There's a difference between creating an illusion of depth and engineering an interactive 3D experience.

There's a difference between prompting an AI to generate a futuristic product render and building that product in Three.js, setting up its materials and lighting, controlling the camera, and making the scene respond to user input.

One approach primarily involves generating and presenting media. The other involves engineering a scene that can be rendered and manipulated dynamically.

Both have their place. They are NOT the same skill.

And honestly, I'm getting tired of seeing portfolios where every other developer has the same cinematic AI-generated hero, the same floating futuristic object, the same scroll-reveal animations, and the same claim of building "immersive 3D experiences."

Change the generated video and half these portfolios would look interchangeable.

If your entire 3D identity disappears when you remove the AI-generated media, maybe you don't have a 3D skill set. Maybe you have a good eye for visual presentation.

And there's nothing wrong with that. Just be honest about what you actually built.

Now, before the Three.js developers start celebrating, using Three.js doesn't automatically make you creative either. You can build a terrible, generic experience with real-time 3D just as easily.

My point is simple: tools don't determine creativity, and visual similarity doesn't prove technical skill.

But if you're presenting yourself as a 3D web developer, I expect to see evidence that you can actually build and control a 3D experience — not just embed one someone or something else rendered for you.

Let's settle this.

If you use an AI-generated video as the centerpiece of your website's hero section, do you consider that 3D web development, 3D-inspired web design, or simply video-based web design?

And if you disagree with me, explain exactly where you draw the line.

I'm genuinely interested in the arguments.

Most Senior Developers Are Just Junior Developers Who Learned More Syntax.

Michael Darasimi Jace — Thu, 22 Oct 2026 19:40:10 +0000

Let me explain.

Years of experience don't automatically make you a good software engineer.

I've seen developers with 10+ years of experience who can build almost anything as long as the requirements are clearly written, the architecture is already decided, and somebody else has figured out the difficult parts.

But ask them to design a system from scratch, challenge their architectural decisions, explain their trade-offs, or debug a problem they've never encountered before, and suddenly those years of experience don't look so impressive.

Knowing more frameworks doesn't make you a better engineer.

Knowing 15 design patterns doesn't make you a better engineer.

Writing code that looks sophisticated doesn't make you a better engineer.

Even knowing how to build scalable systems means very little if you can't explain WHY your solution is appropriate for the actual problem.

The real difference between a junior and a senior engineer shouldn't be the number of years they've spent coding. It should be the quality of their technical judgment.

A senior engineer should be able to look at a problem and understand what doesn't need to be built.

They should know when an abstraction is unnecessary, when a database is the bottleneck, when a system is overengineered, and when the simplest solution is actually the best one.

More importantly, they should be able to defend their decisions with reasoning instead of hiding behind phrases like "industry best practices" or "that's how it's done in production."

And here's the part that might upset people:

Some developers aren't becoming better engineers with experience. They're just becoming faster at repeating the same mistakes.

Ten years of experience can mean ten years of growth.

Or it can mean one year of experience repeated ten times.

So let me ask the senior developers here:

What specific engineering skill separates a genuinely senior engineer from someone who has simply been coding for a long time?

And please, don't just tell me how many years you've worked or how many technologies you know. Explain what makes the difference.

Clean Code Is Overrated. Most Developers Don't Even Know What Clean Code Means.

Michael Darasimi Jace — Thu, 22 Oct 2026 19:36:21 +0000

I'm going to say something that will probably annoy a lot of developers.

Clean code is overrated.

Before you start quoting Clean Code by Robert C. Martin, hear me out.

I've seen developers spend more time trying to make code look clean than trying to understand whether the code itself is well designed.

They extract every repeated line into a function.

They create abstractions for logic that only exists in one place.

They introduce interfaces for implementations that will probably never change.

They split simple operations across multiple files, then call the result "maintainable."

And somehow, the more complicated the codebase becomes, the more proud they are of its architecture.

But here's my question:

If I need to jump across seven files to understand a simple operation that could have been expressed clearly in one place, what exactly have you cleaned up?

The indentation?

The file structure?

Or your own conscience?

I'm not arguing that readable code is unimportant. I'm arguing that readability, simplicity, and maintainability are not automatically the same thing as following every clean-code principle religiously.

Sometimes duplication is better than the wrong abstraction.

Sometimes a longer function is easier to understand than five tiny functions with vague names.

Sometimes the simplest architecture is the one that solves today's problem without pretending you're already operating at Google's scale.

And sometimes, in the pursuit of "perfect" code, developers create complexity that didn't exist before.

Good engineering isn't about making code look impressive to other developers.

It's about making the system understandable, reliable, testable, and easy enough to change when requirements inevitably evolve.

So here's my controversial question:

Have we reached a point where some developers write code to impress other developers instead of writing code to solve problems?

I want to hear from people who disagree.

When does clean code become overengineering, and how do you tell the difference?

Why I Still Build sometimes With Vanilla JS.

Michael Darasimi Jace — Wed, 29 Jul 2026 10:10:46 +0000

I get this question a lot: "why aren't you using React for this?" And honestly, for a good chunk of what I build, I just... don't need it.

Take Vestro Trade, the trading platform I built — client dashboard, admin panel, live BTC charts, realtime deposit approvals, the whole thing. No React. No Vue. Just HTML, CSS, and JavaScript, talking to Supabase. People assume that means it's simpler or less "real" than a framework-based app. It's not. It's just more direct.

Here's the thing nobody tells you when you're learning to code: frameworks solve a specific problem — managing complex, deeply nested state across dozens of components that all need to talk to each other. Most projects I take on don't have that problem. A dashboard with a few dynamic sections, a landing page, an admin panel with some forms and tables — that's not React's problem to solve. It's just JavaScript's problem, and JavaScript is honestly pretty good at it now.

The other thing — and this one's more personal — is that I got tired of debugging build tools instead of debugging my actual app. I've lost hours to webpack configs, dependency conflicts, "it works on my machine" nonsense that has nothing to do with the feature I was trying to ship. With vanilla JS, I write code, refresh the browser, and I'm looking at the actual bug, not a build pipeline issue standing in front of it.

There's also a selfish reason: when I'm debugging someone else's messy code — and freelance work means you inherit messy code constantly — understanding the DOM and events directly makes it so much easier to figure out what's actually happening, instead of trying to reverse-engineer whatever pattern the last dev decided to use.

I want to be clear though — I'm not anti-framework. If a project genuinely needs heavy state management, or there's a team that benefits from shared conventions, I'll reach for React without hesitation. It's a tool, not a religion.

But I think a lot of developers reach for a framework out of habit before they've actually asked if the project needs one. And most of the time, when I actually stop and ask that question honestly, the answer is no