LeveloJS Went Quiet. We Were Rebuilding the Foundation.
It has been almost a month since we shared a major update about LeveloJS.
If you have been following the project, you may have noticed that we have been unusually quiet.
LeveloJS has not stopped.
Actually, quite the opposite.
For the last month, we have been working on a much bigger change than another framework feature or API improvement.
We are rethinking the architecture of LeveloJS with one long-term goal in mind:
Can LeveloJS become a true multi-platform framework?
And that question has changed a lot of things.
A New Collaboration
This work is now being done by two developers: me and Joseph, a Nigerian developer with more than 10 years of programming experience.
Joseph is not new to building software.
We previously worked together on Kivex, an icon library, where I had the opportunity to review and work with his code. That experience also gave me the opportunity to learn from the way a developer with many years of experience approaches architecture and implementation.
I have been programming for a little over a year.
Joseph has been programming for more than a decade.
That difference in experience is one of the reasons this collaboration has been valuable for me personally as well.
Now we are bringing that collaboration into LeveloJS.
The objective is simple to describe, even though the engineering behind it is not:
We want to take LeveloJS beyond the browser.
But Why Multi-platform?
This is probably the biggest question.
Why not simply keep building LeveloJS as a web framework?
The web already has extremely strong frameworks.
React, Next.js, Vue, Svelte, SolidJS, and many others have already solved many of the problems developers face when building modern web applications.
We looked at that ecosystem and asked ourselves something:
If we build another framework that mainly tries to compete with those frameworks, what new thing are we actually giving to the next generation of developers?
We don't want LeveloJS to exist simply as another React-like, Solid-like, or Svelte-like framework.
Those projects are already doing excellent work.
Instead, we want to explore a different direction.
Build on What Already Exists
Programming history has many examples where progress did not necessarily come from replacing an existing idea with another version of the same thing.
One well-known example is the evolution from C toward C++.
Bjarne Stroustrup did not simply try to create "another C."
C++ extended the ideas of C and introduced a different programming model on top of them.
Another modern example is Next.js.
Next.js did not attempt to replace React with an unrelated rendering model. Instead, it built on React and expanded what developers could build around it.
These examples represent an idea that we find interesting:
Sometimes the next step is not to replace the existing foundation. It is to expand where that foundation can go.
That's the philosophy we want to apply to LeveloJS.
Instead of asking:
"How can we build another web framework?"
we started asking:
"What can we build if LeveloJS is not limited to the web?"
And that question eventually led us to multi-platform development.
Our Goal: Write Once, Run Anywhere
The idea behind our current research is simple:
Write LeveloJS code once and target multiple platforms.
Our long-term target includes:
- Android
- iOS
- Windows
- macOS
- Linux
- Web
We are inspired by the general idea behind "write once, run anywhere" development.
But we are not claiming that LeveloJS has already achieved this.
It hasn't.
We are researching how far it is actually possible to take the idea.
There are many difficult technical problems ahead.
And we don't know yet how many of our current ideas will survive the research.
But we believe the problem is worth exploring.
But Doesn't React Native Already Do This?
Yes.
React Native already provides a way to build applications for platforms such as Android and iOS using React and JavaScript.
So why are we researching another approach?
The answer is that our goals are different.
One thing we find interesting about React Native is that developers work with platform-oriented components such as:
View
Text
TouchableOpacity
For a web developer moving into React Native, this means learning a new set of components and a different UI vocabulary.
We are exploring whether LeveloJS can take a different approach.
Instead of asking a web developer to abandon the familiar JSX elements they already know, we are researching whether the same JSX development model and familiar web-style elements can be used as the input for a multi-platform rendering architecture.
In other words:
We want to explore how far the existing JavaScript + JSX experience can travel.
This is still research.
We are not saying that every browser element can magically become a native component on every operating system.
The challenge is precisely figuring out how such a system could work.
We Are Thinking Beyond Android and iOS
Another reason we are approaching this problem differently is platform coverage.
React Native's core ecosystem primarily targets Android and iOS, while projects such as React Native for Windows provide additional platform support with platform-specific architecture.
That is useful, but it also demonstrates how difficult true multi-platform rendering actually is.
Our research is aimed at a broader question:
Can one LeveloJS architecture be designed to target fundamentally different operating systems without forcing developers to learn a completely separate application architecture for each one?
That means thinking about:
- mobile
- desktop
- web
- operating-system differences
- rendering
- platform APIs
- performance
- type safety
- security
- and developer experience
This is much larger than simply adding another renderer.
Rethinking the LeveloJS Architecture
Once we decided that multi-platform was the direction, we realized that the old browser-oriented architecture could not simply remain unchanged.
The original LeveloJS architecture was designed primarily around the web.
That made sense.
But a multi-platform framework needs a foundation that is not tightly coupled to one platform's rendering model.
So we started redesigning parts of the architecture.
The JSX tree is now being treated much more deliberately.
We are experimenting with representing individual elements and their relationships in a way that gives the renderer greater control over what each part of the application actually represents.
This is one of the reasons the architecture is becoming more complex—and potentially more capable.
Type Safety Is Becoming More Important
Another major direction of the new architecture is type safety.
We are trying to make the system as type-safe as realistically possible.
For us, this isn't just about getting better autocomplete.
When the same application is expected to target multiple environments, the underlying representation becomes much more important.
We want the architecture to make invalid states harder to create and the relationship between the application structure and rendering system more explicit.
There is still work to do here.
But type safety is now part of the architectural direction rather than something we want to add later.
Security Is Also Part of the Redesign
The new architecture is also being designed with stronger security considerations.
Because we are treating the JSX tree and individual elements more explicitly, we have more control over how those pieces are represented and processed.
This gives us a better foundation for introducing stronger boundaries and safer behavior.
We are still researching and implementing these changes, so we don't want to make exaggerated claims about security.
What we can say is:
Security is being considered as part of the architecture itself, rather than as an afterthought.
Why Rust?
One of the more interesting things we are currently researching is the renderer.
We are experimenting with using Rust in the rendering architecture.
The reason is straightforward.
When you start targeting multiple platforms, performance and low-level control become increasingly important.
A browser framework can rely heavily on browser APIs and the browser's rendering environment.
A multi-platform framework has to think beyond that.
We want a rendering layer that can potentially provide:
- high performance
- predictable behavior
- stronger type guarantees
- low-level control
- and a foundation suitable for multiple platforms
Rust is one of the technologies we are exploring to help achieve that.
This is still experimental.
We are not announcing a final renderer architecture yet.
There Is One Part We Are Keeping Secret
There is one particularly important part of our multi-platform architecture that we are intentionally not revealing yet.
It concerns how the rendering system will actually work across different platforms.
We already have a direction and ongoing research around it.
But we want to reveal that part together with the relevant LeveloJS feature release.
So for now, we will simply say:
The renderer is being designed around the multi-platform goal from the beginning.
When the implementation is ready, we will explain the architecture publicly.
Why We Chose This Direction
At the end of the day, this isn't about trying to prove that LeveloJS is better than React, Svelte, SolidJS, Vue, or any other framework.
Those frameworks already have strong ecosystems and solve real problems.
We simply don't want to spend our time rebuilding something that already exists in many forms.
We want to explore a problem that is different.
If a developer already knows JavaScript and JSX, could they use that knowledge to build software for multiple platforms?
Could the same development philosophy extend from a website to a desktop application, mobile application, and other environments?
Could we reduce the amount of platform-specific knowledge required to get started?
Those are the questions behind LeveloJS Multi-platform.
What We Want for the Next Generation of Developers
We don't believe developers should stop learning native technologies.
Learning Kotlin, Swift, Flutter, Rust, platform APIs, or other technologies can be extremely valuable.
But we also believe that every platform should not necessarily require a developer to start from zero.
A web developer already knows how to think in JavaScript.
They already understand components, state, events, JSX, and application logic.
If LeveloJS can preserve more of that knowledge while allowing developers to reach other platforms, we think that could make application development more accessible.
That is the opportunity we see.
Not replacing native development.
Not replacing existing frameworks.
But creating another path.
Where We Are Now
At the moment, LeveloJS Multi-platform is still under active research and development.
We are working on:
- architectural redesign
- multi-platform rendering research
- JSX tree representation
- type-safety improvements
- security considerations
- Rust-based rendering experiments
- and the overall "write once, run anywhere" direction
We don't know exactly where this research will end.
Some ideas will work.
Some will need to change.
Some may fail completely.
That's part of building something new.
But the work is ongoing.
Help Us Explore This
This is also where the community can help.
If you have experience with:
- multi-platform frameworks
- rendering engines
- compiler architecture
- Rust
- JavaScript runtimes
- native application architecture
- cross-platform UI systems
- or "write once, run anywhere" technologies
we would genuinely like to hear your ideas.
If you have already researched a similar problem, found an interesting architecture, or simply have an idea that could help us think about LeveloJS differently, share it with us.
Your research may help us avoid mistakes.
It may even help shape the architecture.
We are not trying to pretend that we already know everything.
We are researching.
We are learning.
And we are building.
So, Why Was LeveloJS Quiet for a Month?
Now you know.
For almost a month, we didn't have a major public update because we were working on something that required us to rethink the foundation of LeveloJS.
Joseph and I started this collaboration with a bigger goal:
to explore whether LeveloJS can evolve from a web framework into a multi-platform framework.
That requires architectural changes.
It requires research.
It requires experimentation.
And it requires accepting that we may not have all the answers yet.
But that's okay.
We don't know how far we can take this.
We are putting our trust in Allah and doing the work.
In-sha-Allah, LeveloJS will have a very different story to tell in its next chapter.
This is not the end of LeveloJS as a web framework.
It's an exploration of what LeveloJS could become beyond the web.
The foundation is changing.
The research has started.
And the next chapter is being built.
Top comments (1)
Indeed the story is quite gonna be unique. Good job, Saif.