The more users rely on software in their daily lives, the more personal data they share with various applications and services.

Is it good for the users?

To access new, exciting features users are forced to give away personal information. A constant tension exists between functionality and privacy. The more powerful and attractive the functionality becomes, the greater the compromise on users' privacy.

Let’s explore an example.
I’m using “CinemApp” - an application for keeping track of all movies I’ve watched. This application requires registration and will store my watched movies record. It would ask me about my personal taste, and location, in order to provide better recommendations for movies in theatres nearby that I might like. It would ask for access to my calendar and credit card details in order to book tickets.

This is a really narrow use-case application, but it already knows manifold of information about me.
What if I want to try an alternative application that stores records of movies watched and in addition these of attended concerts? Will I be able to migrate my data?
How about planning a movies night out together with a group of friends? Will they all be required to install the app and register as well? Will we all be obliged to share our personal information to allow the app coordinate planning and scheduling?
What if the application ceases to exist or is no longer maintained? Will my movies records be lost?

The users not only grant access to their personal data, they don’t have control over how this data is used and stored.

Is it good for the developers?

User data is a prerequisite for software, especially a modern AI-powered one, to deliver quality services. However, personal data is not only problematic for users to give out, it is also challenging for developers to gather, manage, and protect. Instead of focusing on the key differentiating feature in their product, the developers have to address tasks related to data collection, storage, and implementation of data access and security.

These fundamental tasks, common to all software products, become a significant barrier to the adoption of new software, especially for smaller companies and individual developers. With great power comes great responsibility. Acquiring user data allows developers to provide innovative and unique services, but also imposes maintenance and security requirements and obligations, which are costly in terms of both - time and effort.

Summary

All the above constitutes the same problem with different possible angles to look at:

• Users are forced to grant excessive access to their personal information and lost control over their data

• Developers are forced to engage in repetitive, exhaustive and costly efforts of gaining user trust, collecting, and maintaining user data

• The very same user data is scattered and replicated in multiple silos, over and over again on various servers for various purposes.

Code comes to data

Atom54 addresses the set of challenges described above by adopting and implementing the “code comes to data” paradigm. In this paradigm all data is stored at the user’s medium of choice. The user maintains full ownership of their data. It is the user who decides how and where this data is being stored, and it is the user who decides what code is to run on it and when.

Upon user’s request, a corresponding code module can be executed on the data, without exfiltrating any personal information to third parties. The action is only finalized with the user’s approval.

An Atomic component has no direct access to data. The Atomic code units are stateless and cannot communicate with one another. The inputs and outputs of the Atoms are declarative and managed by the framework.

This way the Atomic software is fully defined by its data flow, and access to data is governed by the framework. The data flow can be analyzed and privacy policy rules can be enforced. 

Data privacy is built-in into the very core of the Atomic software.

Security: Isolation

Privacy guarantees are only as good as the security is. Atoms or compounds of Atoms can be executed in isolation from each other: 

Each code component is a pure JavaScript object and is sanitized and frozen at load time. Each component can be executed in a sandbox.

Depending on the execution environment (web, browser extension, server API, etc), different security/isolation solutions can be selected. The levels of security can be adjusted, and made suitable for sensitive data as needed, for example, to handle financial or medical information.

Due to its composable architecture (please, read the post below, if you haven’t already), Atom54 can compose complex and meaningful software solutions from stateless code components in a privacy preserving and secure manner.

To learn more about Atom54, please visit our website, repository, read our blog or get in touch.

Before delving into details, please review our previous article about the core concepts of Atomic software and the composition of Atomic components, if you haven’t already:

Atom54 software is modular and composable. This architecture not only allows, but also embraces the use of AI in all the software layers:

Atoms use AI

An individual Atom can use AI to perform the standard regression, clustering, classification, and other operations:

Atoms co-authored with AI

AI can be used to co-author the code of an Atom. Atoms are usually relatively small and well-scoped code units, well suitable to be generated by an LLM.

AI-powered reality interfaces

Atoms also leverage AI to interaction with reality interfaces, such as: vision, sound, speech, touch, motion, and more:

One of the areas of technology with huge potential and undelivered promise is the wearable, AR, VR, IoT spaces. All these involve multi-device scenarios and much closer interaction with physical reality than the classical use cases addressed by software. These areas didn’t get enough developer community engagement simply because it is hard to develop for these devices. This is where Atom54 can make a big difference - not only it facilitates multi-device experiences, it does it in a general-purpose, device agnostic way.

AI-driven composition

And last but not least, composition is always semantic, as it is defined by connecting inputs and outputs of the components:

The LLMs are well positioned to reason about the composition and create novel experiences.

To learn more about Atom54, please visit our website, repository, read our blog or get in touch.

To use an abstract analogy, imagine switching from today’s mechanical prosthetic arm that is made of plastic, titanium, silicone, etc to a prosthetic arm that is grown from human cells and tissue. The biological arm has a significantly better sensitivity, feedback and movement support than the mechanical one.

Similar is the qualitative leap from linear or block programming to Atomic programming. Each Atomic component is like a biological cell that responds to stimuli. The larger compounds of Atomic components have more complex reactions and motivation, and constitute software that evolves and morphs depending on the builtin goals and requirements, and the context it operates in.

What is an Atom?

Let’s dive into how Atomic programming actually works. Within the software, we have a basic code unit called an Atom:

Every Atom is defined by its inputs and output. 
Atoms are reactive - they only do work if one of their inputs changes.

Composition of Atoms

Atoms can be composed into compounds by connecting their inputs and outputs. 

Modularity and Decoupling

The Atomic components are modular and have no interdependencies. The data is decoupled from business logic, decoupled from UX, and so on.

This allows any module to be modified or replaced without affecting the stability of the rest of the system. It’s like replacing a tire or an engine while you drive.

In this paradigm, developers have the freedom to control every choice of underlying technology or service provider, or alternatively fall back to the framework’s deliberation for decisions they don’t want to make.

Every component is easily pluggable. For example, the developer may specifically choose Firebase storage and later replace it with a Fission storage. On the other hand, the developer may just request an abstract persistent storage, and let the framework choose one.

Moreover, each component can stand on its own, and developers have the freedom to run their components independently, outside of the Atom54 framework. 

Cross Device / Multi device

The modularity and dependency-free architecture allows the Atomic software to run on any device or combination of devices, on any platform or OS.

Like any other implementation aspect, the UX is pluggable and optional. Atom54 experiences can include no UX whatsoever and run as background server tasks. 

The decoupling of UX also allows Atom54 to render UX onto any rendering surface (for example, DOM), or multiple surfaces and devices.

The framework manages the cross device orchestration of components, while being transparent for the developer.

Composition of compositions

A composition of Atoms can be treated as a logical Atomic unit of itself.  It is similarly defined by its inputs and outputs. And in the same way as the basic Atoms, the compositions of Atoms themselves are composable by connecting inputs and outputs.

Due to its composable nature, the Atomic software is future ready and adaptable to innovations yet to come.

Similarly, the Atomic software can also be composed with standalone classic software via this universal data-flow determined API.

To learn more about Atom54, please visit our website, repository, read our blog or get in touch.

As software evolved, it became suitable for solving a wider range of tasks for a larger target audiences of users. Programming itself has also become significantly easier and more accessible.

This growth skyrocketed with the rise of the internet and mobile devices, but has begun slowing in recent years. AI opens the door to sustained exponential growth, and Atom54 unlocks unique opportunities to accelerate development and solve an even wider variety of problems.

Software Layering

Over the years, programming evolved from punch cards, to assembly, and then to higher-level programming languages that are more developer friendly. However, between programming languages and the software end-product there still is the uncharted territory of unstructured software.

Within this layer, developers have to keep solving the same problems over and over, each reinventing the wheel. This causes incompatible and less efficient solutions, as well as extra manual labor.

Recently more frameworks, libraries and developer tools are being introduced in this intermediate layer. 

They address certain problems, but they also introduce new challenges:

• Dependencies make software vulnerable to breakages, downtimes, and licensing changes

• Compatibility: different frameworks and libraries may not work together smoothly, requiring time and effort to reconcile.

• Cumulative costs of frameworks and underlying resources may be a constraint, especially for individuals and smaller businesses.

• Lack of flexibility and customization: standard libraries and frameworks often aren’t precisely suitable for the problem at hand, resulting in compromises in the end product’s functionality.

• Lock in: after a dependency on a service or a library is introduced, it is difficult to revisit and switch to an alternative provider, especially once the software is in production.

Novel layer

Atom54 introduces a new software layer in the software technology structure.  This layer unveils novel concepts and unique properties to programming, and addresses the status-quo challenges described above.

The Atom54 layer consists of:

• Xenon core framework - that runs the Atomic components

• An Ecosystem of Atomic components

• And an Environment for morphing, evolving, and growing components

It is important to note that Atom54 is not a monolithic layer, quite the opposite. The Atomic components are independent of each other, and also, most importantly, independent of the framework. Similarly to how biological cells get connected together to form tissue, organs and organisms, the Atomic components get connected to form features, experiences, and applications.

Please, learn more about Atom54 on atom54.com or subscribe to our substack!

We are now called Atom54, and here is why:

Atom is an independent (atomic) code unit.

Atomic programming is a paradigm that allows composing individual Atoms into compounds (and compounds of compounds) to perform tasks and fulfill goals.

Xenon is the name of the framework we use to run Atoms. 

54 is the atomic number of Xenon. 

Why Xenon? Xenon is a noble gas, it is chemically inert. In the same spirit, in the Xenon framework Atoms are not bound directly and cannot talk to each other. The Atoms are loosely connected, just like the gas molecules are loosely coupled.

Another remarkable quality of Xenon (the element) - it lights up when ionized with electrodes. Similarly, in our framework, the Xenon experiences come to life when they encounter incoming data. 

And last but not least, Xenon (the element) is used for thrusters in spacecraft, which is just cool.

Welcome to Atom54!

It is even more peculiar when the material-world restrictions surface in software more apparently than in physical reality. For example, I pay the store to buy a microwave, then at home I plug it in and pay the power company. The microwave is a commodity and I own it. The electricity is provided as a service. Similarly, the cellphone: I can buy a device (the commodity) and choose a mobile provider I connect it with (the service).

This distinction between commodity and service is fairly clear in the material world, but not so much in the world of software. More often than not, the “tool” (i.e., commodity) and the “service”1 are marketed as a hybrid, presumably for the sake of simplicity. But in reality, the entanglement of tools and services, the lack of granularity, is what enables monopolies, constrains users’ free choices of providers, and ultimately forces customer lock-ins.

The constrained choice and lock-ins are increasingly unfortunate and flawed when it comes to open-source. Over the years, the open-source software grew from enthusiast to mainstream culture, and yet in the past couple of weeks I stumbled upon a few articles2 describing license updates by open source projects aimed at converting users to paying customers. Some authors present this strategy as a viable business model. 

In my opinion, this approach undermines the open-source concept overall. As an open-source community member myself, it is my responsibility to make sure this won’t happen with XenonJs:

• All XenonJs code components have no dependencies. They can stand on their own and are runnable outside the XenonJs framework. 

• XenonJs experiences are composed from components. Some components are “commodity” (e.g., business logic or UI), some are “services” (e.g., storage, or access to LLMs). All components are interoperable and hence interchangeable, meaning the user can easily switch between service providers without affecting the rest of the experience.

Independently from the personal qualities of XenonJs authors, due to the very nature of its architecture, XenonJs is open, flexible and unequipped for lock-in.

MVP can also be a trap.

The bigger the part that software plays in our daily lives, and the more we rely on our software, the more complex and extensive it becomes. As a result, every new product’s MVP grows larger, making it harder and more time-consuming to build. It’s as if you had to rebuild the entire house from the ground up, just to recarpet a bedroom.

MVP is simple; it is an excellent approach to a small, narrow scoped problem. MVP is an excellent tactical prototyping approach, but a bad strategy. It encourages tunnel vision, and leads to reinventing the wheel. Aiming for MVPs we end up creating multiple silos. MVP is an ally of a good product in a vacuum, but an enemy of a good solution. Because our lives are complex, and so are the problems that need solving. 

There is a saying that “90% of the work gets done in 10% of the time, and the last 10% of the work takes 90% of the time”. Usually a large portion of the MVP falls within the initial 90%, and more often than not, it was already pretty sound. Unfortunately, developers find themselves rebuilding the foundations over and over again, instead of focusing on the remaining 10%, where the real impact is.

The key to comprehensive solutions is building them upon the existing ones. Yet the current unit of granularity in software - the “application” - isn’t suitable for reusing and extending. Each application is like a perfectly solid smooth brick, but one that cannot be bound together with other bricks to build a wall of a house. To connect any two of the bricks we need to build a custom integration.

XenonJs proposes a novel approach: its modular architecture enables effectively leveraging an entire ecosystem and seamlessly interoperating with 3rd-party components. Rather than rebuilding the end-to-end from scratch, XenonJs allows you to specifically focus on your own innovative features implementation. 

To find out more on how XenonJs promotes reuse and composability, please visit our website, repository or get in touch.

Ironically, while the physical world has consolidated many functions into a single device, the virtual world still fails to do so. Similarly to how we used to have separate gadgets before, we keep using separate applications for each activity. For instance, I use a calendar app to set a reminder for making a call. Then I go to a separate calling app to dial and speak. 

There are different approaches to solving the problem. Some apps are being built specifically to address a narrow use case variant. Others strive to support all possible permutations, often resulting in a frankensteinian combination of features that is hard to navigate. And so developers keep building more and more apps to deal with the overwhelming abundance of already existing apps, instead of exploring alternative approaches.

XenonJs offers a novel approach. We think that an “application” is simply not the right level of granularity. With XenonJs we support flexible levels of scoping: each individual “feature” - small or big - is a composable unit, and a collection of the composable units is a composable unit in its turn. All such units are collaborative and interoperable, transforming the current space of walled silos into a naturally evolving software universe that adapts to each person’s momentary needs and adopts new technological capabilities as they become available.

We don’t say “a supermarket user bought a carton of milk”. 

We don’t say “a refrigerator user opened a door and put the milk inside”. 

We don’t say “a Verizon user made a phone call”. 

We, as humans, have ownership over our actions and objects and this is expressed in our language. We say “I bought milk” and “someone put it inside the refrigerator”, and “they made a phone call”.

The recency of software becoming an integral part of our life is a likely reason why we refer to a human as a user. In the early computer days, user was a title one held proudly. However in saying “Youtube users watch videos” and “Facebook users write posts” – human ownership of the virtual entities and action is not reflected. People who use software are treated as guests in the corporations’ virtual space. 

In XenonJs paradigm this model is reversed. We, the humans being served by the software, regain our autonomy, authority and sovereignty. All our data belongs to us, and the software adjusts and morphs to shapes, matching the exact momentary personal need.

For Technology

XenonJs is a modular and adaptive computing paradigm.

It empowers innovation.

XenonJs is suitable for any creator – from ones with no coding skills at all to an expert software engineer.

XenonJs is applicable to any task – from a quick experiment or an individual feature, to a complex and scalable application or platform. 

XenonJs is highly modular and composable. All its components are interoperable, allowing assemblers (no-code, low-code developers) to compose new solutions, leveraging the rich and varied ecosystem of existing components.

XenonJs components are durable and adaptive. It allows crafters (developers) to only ever write truly new innovative code, focusing on their area of expertise and leveraging the reusable and maintainable components.

For the Future

XenonJs based platforms promote and complement innovation. XenonJs accelerates the iterations from invention of new technology to its global availability. 

By virtue of its multi-layered and adaptive architecture XenonJs based software is built to incorporate latest scientific breakthroughs whenever and in whatever shape they occur. 

AI is a good example of this. Due to its modular nature, XenonJs can best leverage AI by presenting it with diverse well-defined subtasks, complementing them with non-AI programmatic solutions where appropriate, and composing all into a coherent experience. XenonJs amplifies the AI strengths, and is well-positioned to accommodate and govern as much of AI participation, as is considered secure and optimal for the task in hand.

XenonJs is future-ready.