Why an HTML List Outperformed a GPU Visualization Engine

By Hicron Software Engineering Team

CTOs often aim to keep software solutions simple. This is where strong software partnerships add real value. For one of our clients, we turned a complex request into a simple, effective solution. This story is especially useful for software companies scaling their products. It’s even more relevant in PropTech, where usability must mirror physical spaces. By focusing on what mattered most, we delivered a solution that worked, and still does.

We were asked to build a GPU-powered visualization engine for an enterprise IoT platform. The kind that calculates widths, heights, renders nodes, the whole heavy machinery. Instead, we shipped a solution built on HTML lists and CSS. The client loved it. A year later, it's still in production, unchanged.

The Brief That Started It All

The client, an IoT solutions provider, needed a way to visualize building structures within their web application. Think floors, rooms, zones. Users needed to see the hierarchy, navigate through it, and manage configurations at each level. The client's existing application already had a version of this feature, but it required users to manually arrange elements on a canvas, tedious and unscalable. They wanted something better for their new web platform: structured, elegant, and easy to navigate.

The initial idea on the table was a GPU-accelerated rendering library. A powerful tool designed for complex visual computing, the kind that taps into your graphics card to calculate and draw elements on screen. For serious data visualization, it's a reasonable choice. But for displaying a building's room hierarchy? It felt like bringing a tank to a parking lot.

Rethinking the Problem

When the task landed on our frontend engineer's desk, the first instinct wasn't to start configuring the rendering engine. It was to step back and ask: what are we actually displaying here?

The answer was a hierarchy. A building contains floors. Floors contain rooms. Rooms contain sub-zones. That's a tree structure, and the web has had a native way to represent trees since the very beginning: nested lists.

As our frontend engineer put it: "You don't actually need to draw it. In HTML there is such a thing as lists, and they lose no information about how the structure looks."

The idea was almost too simple. Instead of calculating pixel positions and rendering nodes on a canvas, the team used plain <ul> and <li> elements — the same building blocks used for navigation menus and bullet points across the web. CSS handled the visual transformation: the first level of children displayed horizontally, nested levels vertically, creating a clean tree layout. No JavaScript-driven rendering. No GPU. Just the browser doing what browsers already know how to do.

There was one more piece to the puzzle: navigation. A building structure can get large, and users need to zoom in, pan around, and move through the visualization fluidly. Rather than reaching for yet another library, the developer studied how popular collaborative tools like Miro handle canvas navigation — the smooth zoom, the intuitive panning — and recreated a lightweight version of that behavior from scratch. The result was a familiar, intuitive UX that users already understood from tools they use daily.

Where Simple Meets Real-World Messy

Of course, no solution is without trade-offs. The interesting technical challenge appeared at the data layer. The backend sends data as a graph, nodes, and connections, where any element can reference any other. But the frontend renders it as a tree, which is strictly hierarchical. That mismatch creates a specific risk: circular references.

Imagine a data model where Building A contains Room B, and Room B references Building A as its parent. In a graph, that's a valid connection. In a tree rendered as nested HTML lists, it produces an infinite loop. The team caught this early and is working with the client to define data constraints that reflect physical reality, because in the real world, a room doesn't contain the building it's inside.

As our frontend engineer noted: "There is no rocket science here. The idea was to do it as simply as possible. And they actually liked it."

"Liked it" might be an understatement. The project has been running for over a year, and there has been no need to revisit the core visualization approach. The solution that was meant to be a quick alternative to the heavy rendering engine became the permanent one. As the developer reflected: "The project has been going on for a year, and there was no topic to change the solution, so maybe we will stick to the simplest one."

Why It Worked: More Than Just Code

The technical choice mattered, but it only worked because of the team's and the client's collaboration. The client didn't prescribe a solution and hand over a spec. They described the problem, shared an initial design concept, and told the team: propose something.

That openness made all the difference. From the developer's perspective: "They are open to proposals and they say to propose. This is the biggest plus from the programmer's perspective, a bit of a free hand."

The project also benefits from a quality-first culture. Requirements change frequently; this is enterprise software, after all, and the client understands that the first solution isn't always optimal. When new requirements reveal a better approach, the team has room to refactor. There's no "deadline, deadline, deadline" pressure overriding technical quality. That's what keeps the codebase clean and the team motivated to keep improving it.

The tech stack reflects this mindset, too. The project runs on the latest version of Angular, and the team actively experiments with newer patterns like Signal Store for state management. It's not just about delivering features; it's about keeping the technical foundations modern and learning what works along the way.

The Takeaway

Next time you're faced with a visualization requirement, resist the reflex to reach for a rendering library or canvas-based framework. Ask yourself: what data structure am I actually displaying? If it's hierarchical, HTML and CSS might be all you need. Nested lists give you accessibility, semantic structure, and styling flexibility for free. Save the heavy tools for when you genuinely need them: pixel-level control, animations, or truly non-hierarchical graph layouts.

The simplest solution isn't the lazy one. Sometimes it's the one that ships faster, performs better, and lasts longer.

What's the most surprisingly simple solution you've shipped in production? We'd love to hear your story.

Hicron Software is a software development company specializing in custom solutions.

Simplicity is often the best solution. Instead of creating a complex GPU-powered visualization engine, the team built a lightweight solution using HTML lists and CSS. This approach met the client’s needs, was scalable, user-friendly, and efficient. The success shows the value of understanding the problem, working openly with clients, and focusing on practical solutions. This is especially relevant for PropTech software companies, where usability must reflect real-world spaces. Read the case study that contains this success story.

#FrontendDevelopment #WebDevelopment #SoftwareEngineering #IoT #TechLeadership