Hello, developers,
Today, I want to give you an exclusive look at the latest chapter in our ongoing story of innovation: the redefinition of our developer experience. Our primary goal? Empower every engineer and developer to craft, share, and employ engineering tools in the most intuitive way possible.
Beyond Simulations
When Numerous first took its baby steps, it was grounded in simulations. But as time has passed, I couldn't shake the feeling that we were just scratching the surface. The idea of integrating diagram-based modeling into our web app started brewing in my mind. While developing system modeling, a lightbulb moment happened: What if Numerous could be a sanctuary for all analytical tools and not just simulations?
The New Mission: Building a Comprehensive Engineering Toolset
Our experiences with Energy Machines were enlightening. We realized that Numerous wasn’t just about simulations. We were creating a plethora of tools, and confining ourselves to just simulations seemed, well, limiting.
This sparked a mission revision: we were no longer just about simulations. We were setting out to provide a holistic framework and platform for diverse engineering tools.
The UI Dilemma: Balancing Flexibility & Power
As our toolkit evolved, the once-intuitive user interface began to feel increasingly confining. It became evident that our developers required more than just a selection of standard elements. Having a standard UI that occupied screen space, even when irrelevant to the specific tool being crafted, added unnecessary clutter. Moreover, burdening the developer with the responsibility of ensuring consistency between the UI and the job logic code seemed inefficient and counterproductive.
The true question was, how can we offer more flexibility without sacrificing power? This was two-fold:
Syncing UI with Python Code: Developers were grappling with syncing their UIs with their Python code. The dual process of defining a data model in UI and then creating a parser for this in Python seemed redundant. So, why not let the Python code be the defining structure? This way, the data model serves as both the interface specification and the backbone, providing developers with auto-completion and project reuse capabilities in their job code. This would also enable us to give the developer an out-of-the-box UI.
UI Adjustments with a Graphical Builder: The vision is further to marry the definitions made in Python with the adaptability of a drag-and-drop UI. By retaining the original Python code as a template, developers could mold the UI without changing the underlying code structure. In the context of the UI builder the definitions from python function as a interface specification to aid the UI development in interfacing with the jobs.
Ultimate Customization: Merging Python, A Visual Builder and React
A new idea started forming on top of combining the python definitions with the UI builder: What if developers could bring in JS or React, creating their custom components and interactivity functions? Imagine starting with Python definitions, utilizing the standard UI, diving into the builder as needed, and then, for that last unique touch, coding it in React.
For our developer users who wants a highly customized UI? Why not open source a slimmed down version of our web app - just the part that can render up a tool and make it communicate with the platform? That way a development team could add more complex interactions and build custom components and add them to the mix. For those tools going all the way - Simply keep the React code that interfaces with the platform and write your own tool UI from scratch!
It’s a symphony of the definitions made in python to specify the interface between the platform and the developers job logic, the ease of drag-and-drop UI building, and the limitless customization of React and java script.
Empowering Developers: From Global to Local
In addition to creating a symphonic workflow of tools to create and customize the tools’ UI another goal was formulated. Respecting developers' rights and autonomy - living up to the ethos “We are a guest in your house”. The vision of the new development experience entails a shift from keeping UI definitions on the platform to a local experience.
To breathe life into the developers tools locally we will provide a Development Server - installed with our python SDK and fully contained in a python venv. When launched, it will serve up the developers tool and launch it in a new web browser tab, spin up a local backend which can run the tools jobs - so tools can be iteratively developed and tested locally.
In this new paradigm:
All code - Python, UI files, even modified React apps - reside in developers' local directories.
This allows immediate reflections of changes become possible, integrating smoothly with preferred IDEs.
Version control is streamlined across python and UI definitions by enabling everything to be under the same commit in the same repo.
With a local backend, developers can test tools in a localized environment, free from global state preparations and other side effects. Imagine a workflow where developers can experiment and test without mandatory sign-ups, keeping all work on their PC and git repos.
When the developer is ready they sign in, register their repository with numerous - it is the single source of truth for the tool.
In Conclusion
This is the vision of the ultimate developer experience for our framework and platform. What I'm envisioning for Numerous is not just a tool but an ecosystem. It's a platform that grows with you. Starting with the simplicity that a solo developer craves, and seamlessly transitioning into a robust framework that a diverse development team requires.
This isn't just a vision but a promise of an evolutionary leap. I’m not just showcasing a proposal but inviting you all on a transformative journey. Together, we'll shape the future of Numerous, ensuring it stands as a testament to innovation, flexibility, and power.
Stay inspired, and code away!