Soon enough, Divooka is almost here. Let's go back to the problem that got us started: practical data analytics at scale.
We're not trying to completely replace Excel. Excel serves its purposes extremely well, and we envision a world where tools are more specialized depending on the needs. On the other hand, many of the problems Divooka aims to solve - particularly in data analytics - stem from overuse or misuse of Excel in situations it was never designed for. That's why Excel naturally becomes a benchmark for evaluating how well Divooka addresses these challenges - and in turn, how effectively Divooka can substitute for Excel in those contexts.
In general, the future we're building toward is one where people only use Excel occasionally - for working with legacy systems or exchanging files with external clients. For all other practical, internal, and repeatable analytical tasks, organizations and individuals shouldn't have to open Excel at all. That's the vision for Divooka in the data analytics space.
P.S. If you're wondering why we compare ourselves to Excel when talking about "data analytics" rather than Python - it's because we're focusing on where actual work gets done by everyday professionals in finance, retail, consulting, etc. - outside of data scientists and machine learning engineers, who typically work within well-defined infrastructures or theoretical environments.
Overview
Excel offers the following main functionalities and use cases:
- Using worksheets/workbooks as informal databases – enabling data entry, filtering, etc.
- Applying formulas for analytics – calculating sums, performing aggregates, lookups.
- Plotting and reporting – generating charts and formatted reports.
- Automating results and, to some extent, content – via templates for repeated use.
A Note on Learning
Some claim Excel is easier to learn than Python or Divooka. In our experience, that perception usually comes from people who've been using Excel for 10+ years. That certainly wasn't my experience when I first tried to learn it - by then, I was already an experienced programmer.
Excel has a lot of quirks. Fortunately, it also has a wealth of online resources - forums, tutorials, and StackOverflow answers - that help users troubleshoot specific needs quickly. But that doesn't necessarily make it easier to learn.
Meanwhile, its automation and extension system (VBA, VSTO) and DOM model are far from elegant. They can be powerful - but they're also idiosyncratic, outdated, and hard to scale or maintain.
Identifying Veteran Use
For veteran users - those who've worked in finance, consulting, banking, or retail for over a decade - it's crucial to identify what matters most to them so we don't waste time trying to rebuild everything from scratch.
For these professionals, usually in management roles, key priorities tend to be:
- Simple data entry
- Basic formulas (especially VLOOKUP and IF logic) and pivot tables
- Minimal plotting
- Extensive styling, including conditional formatting
Veterans rarely write VBA or build complex automated spreadsheets themselves - that's what interns and junior staff are usually tasked with.
The Solution Plan
Divooka already outperforms Excel in areas like analytics and automation (points 3 and 4), but matching Excel's GUI experience for basic data entry and formulas remains a challenge.
The Challenges
The problem can be broken down into two fronts:
- We must provide a familiar interface and usage pattern - even though Divooka is not Excel - to reduce resistance from long-time Excel users.
- Divooka is a visual programming language with its own design principles. While we want to be similar to Excel where needed, we must stay true to what makes Divooka powerful and unique.
The Approaches
To address the GUI/database usage pattern, we're exploring a few possible approaches:
- Create a custom visual node that replicates the structure of a standard Excel worksheet - though it might look more like a clean, modern take similar to Apple Numbers.
- Encourage users to adopt API-driven or externalized databases and foster a mindset of separating data, computation, and presentation. While we offer SQL and database API integration out of the box, we also recognize that many users resist this - even if they're already managing convoluted Excel formulas.
- On that note, there are two directions we're exploring:
- Provide a visual interface (like MySQL Workbench) for common database operations.
- Offer a high-level, node-based API that avoids manual SQL writing, while gently encouraging users to become more familiar with what's happening under the hood.
A Combined Use Case
The most common (and most problematic) Excel use case is when people combine:
- Data entry,
- Basic automated calculations,
- Fancy styling,
- Plots and form updates for reporting purposes.
This is where Excel shines - and also where it often gets abused. It enables incredibly compact and self-contained workflows: enter numbers, add formulas, apply some styling - and voilà, you have a polished report.
But this convenience comes at a cost: poor scalability, maintainability issues, and a lack of clear separation of concerns. A single cell can simultaneously serve as a data source, a computed result, and a styled report element. This makes downstream changes, automation, and collaboration extremely hard.
The traditional software engineering solution is seen in the web: HTML (structure), CSS (style), and JavaScript (logic). By clearly separating concerns, we maintain flexibility and clarity. So what if creating an HTML/CSS/JS-based dashboard was as easy as building an Excel sheet? That's one possible angle - and something Divooka could eventually support through node APIs or higher-level content editors.
But that's not the most elegant path forward.
The Real Solution
The better question to ask is: what is the actual end goal?
People want to build interactive dashboards or reports that auto-update, look professional, and live within a single workspace where they can easily edit data, adjust formulas, and customize visuals - all while staying clean and maintainable.
Wait a second - doesn't that sound like App Mode in Neo?
(Screenshot coming soon when the time is right.)
Conclusion
Divooka was never about "replacing Excel" outright. That was never the goal - and still isn't. What we set out to solve was broader and deeper: making practical, scalable data analytics accessible to professionals who are otherwise stuck with brittle, overextended workflows. Excel simply happens to be the dominant tool in that space, so it naturally became both our benchmark and our foil.
In a sense, replacing Python is an easier problem - just design a better language, with better libraries and ecosystem. Julia is doing that, so are many others. When we started tackling "The Excel Problem," it felt vague and enormous. We only had instincts: "There must be a better way," and "Visual programming, like Divooka, seems right." Back then, we didn't yet see the full shape of the solution.
But as Divooka matures, as our libraries evolve, and as our design principles solidify, the picture becomes clearer.
It's becoming evident that:
- Data entry can be streamlined through a combination of high-level APIs and dedicated GUIs.
- Dedicated graphical editors are not just useful - they're the future. We'll share more on this next year.
- Divooka's graph-based mindset is not only powerful but practical. Neo will serve as the reference implementation and the litmus test for what a modern visual programming platform can achieve.
Of course, there are still many UX and ergonomics problems to solve - and we must proceed with care.
But we're getting close.
Top comments (0)