Today, anyone involved in building software — notably software with graphical user interfaces like web pages or mobile apps — has experienced more than one squished tomato, or discordant strum. 

Our ideas take 1,000,000 paper cuts on their way to shipping, no matter your job title, and no matter what technologies you use. If we consider user interfaces as a medium for art, creative fidelity is low. But it doesn't have to be this way. 

It's not you.  It's our tools. 

And I mean this lovingly, for everyone on this planet who interacts with screens and computers, both creators and consumers.

Our tools for building software — especially user interfaces — could be better.  Should be better.

Imagine the lift to the wellbeing of humanity if we could grease the gears of our interface with machines.  To make ourselves more creative, to empower more creators, and to enrich our lives with more art and personality.  As humanity spends ever more time in front of screens1, the quality and diversity of these experiences become ever more important.

What if creating software could feel like drawing, or painting, or writing poetry?  What if anyone who can use a smartphone could contribute directly to a codebase through visual and verbal tools?

Abracadabra

If I could wave a magic wand and change one thing about the past, it would be to erase the differences between Webflow and Figma.  Webflow builds software, but it is constrained by the layout system & technical rules of HTML, which is why creative fidelity is so low.  You don’t get to draw in Webflow; you must build in a very complicated way.

On the other hand, Figma offers high creative fidelity, but is fundamentally disconnected from code. As a result, Figma is scoped to "drawing pictures" instead of "drawing software."  Wrong medium, for this particular goal. 

And the heart of the problem is that Webflow vs. Figma, or SwiftUI vs. Photoshop — they speak different languages.  In a formal sense: these languages are not bijectively equivalent2, which is why we can't freely translate back and forth between design and code.

But what if “an HTML” were designed exactly to be the backbone of a vector design tool, as well as the backbone of a user interface engine?  Let's try something wild — let's imagine a language that describes `R ⋃ F`, the union of `R: anything you can express in React`, and `F: anything you can express in Figma`.  

Let’s play this thought experiment out, by building it.

A design tool for codebases

Let's start by building a rendering engine like Figma's.  This must be a professional vector design tool, even as it builds software.3 The coordinate system of this rendering engine must be the same as a vector design tool’s, and the vocabulary must include all of the same concepts, e.g. Group, Rectangle, Path, Text.

Why does Figma feel so unlike every other browser experience?  Because it's built at the systems level, not limited by JavaScript's stuttering garbage collector.4  Our practical choices for building at this level are C, C++, or Rust.  We can use constructs like reference-counted pointers at this layer, operating over a fixed span of linear memory instead of allocating to the JavaScript heap and trigger unpredictable, frame-dropping garbage collections, i.e. stutters. 

Another cool thing about building at the systems level is we can target browsers through WebAssembly, but also can build to pure native apps for just about any device on the planet.

Now that we have this rendering engine, instead of packaging it away into a design tool, let's expose it through a declarative language, so that you can write it by hand in addition to drawing it.  This is that “HTML-like” language we imagined a minute ago, and it looks exactly like React:

<Group>
    <Button />
    <SomeCustomComponent />
    <Rectangle />
</Group>

To write a <Rectangle/> is to draw a <Rectangle/>.  And vice-versa.  

Let’s sprinkle in an expression language, so this can (1) remain 100% declarative, just data, so it can be read & written deterministically, but also (2) allow you to express anything you might express with React and (3) forge a connection with programming languages, so this whole thing can attach to a programming language in the spirit of HTML.

<Group>
    <Button @click=handle_click />
    <SomeCustomComponent some_prop={some_data + 5} /> 
    <Rectangle fill={hsl((num_clicks)deg, 100%, 50%)} />
</Group>

Snap it together with templated reusable components, compile across platforms, customize and extend with Rust (or TypeScript, coming soon.)

We’ve already built all of the above — it’s free and open source and compiles into extremely fast (240FPS) native apps or WebAssembly. Check out Pax Engine on GitHub.

A more creative future

Finally, let’s build a vector design tool, using the language above as the source of truth, reading & writing that language with every operation.  This makes it so you can hand-code a user interface declaration alongside visually designing it. Use the best tool for the job and for your skillset.

The latest design can be opened at any time in the project’s journey, just like opening a codebase with VSCode, or opening a design file with Figma.

Critically, the design now lives in source code and ships to production — contributions are made as pull requests and non-developers can contribute to the same codebase as developers.  Artists, creatives, marketers — anyone who can use a spreadsheet or a design tool or a notepad — now becomes a builder of software.

That’s Pax.  And we’re doing this all so we can have a more creative, more collaborative, more inclusive future — a better interface between humans and machines.

Pax Create is our design tool for making cross-platform apps & websites, built around the open source Pax Engine. As of June 2024, Pax Create is pre-release, but we are getting close to our first launch. Sign up for early access or learn more at pax.dev.

Let’s scope “creating” to: visual design, writing code, managing a team, or authoring content & text. For each of these disciplines, and especially the collaborative interfaces between them, certainly the future will be better than today. But how so?  And why? How do we get there?

Let’s start by painting a Star-Trek-like utopian future — free from the constraints of the present — as it relates to creating GUIs.  Here are some brush strokes to get the canvas started.

The future is multi-modal

That is, you can create UIs using different modes — code is just one such mode.  Following are some other creative modes of the future, some of which we can already glimpse in the present.

Creative mode: drawing, painting, and visual building

In addition to code, you will be able to create user interfaces visually, with graphical tools akin to modern vector & raster design tools. 

We have already seen a glimpse of this with visual builders like Webflow, Squarespace, Framer, and Wix — and a vivid illustration of it back in the ‘90s and ‘00s with Flash’s visual design & development environment — but these tools have plateaued at a local maximum over the last two decades. 

There is a steep learning curve to every one of these tools, and the “visual editing” process in fact requires understanding the underlying developer platform, HTML and CSS, and their complex, technical systems of styling and layout.  In other words, to be effective with these tools, you must first be a developer — which limits the utility of these tools as an alternative to writing code.

One day, after we break past this plateau of constrained, technical visual editors, creating app GUIs & websites will be ultimately be as intuitive and accessible as drawing, painting, or modeling clay.

Creative mode: natural language & AI

Natural language via LLMs and their successors will be another mode of creating user interfaces.  This facet of the future is already at our doorstep, at least early iterations of it, with tools like Durable.co and Framer’s AI.  

As an extension of LLMs transforming explicit requirements into GUIs, you can also imagine autonomous agents creating on their own, or some degree separated from an initial prompt.  Instead of a human turning the crank on each iteration, agents will be able to run with and satisfactorily complete, zero-shot, high-level tasks.

Finally, we will soon be able to input graphical inspiration and generate something that looks or feels like something similar.  A common tool for visual designers is the mood board — a collage of images that channel the “mood” of whatever is being designed, as a tool to get the creative juices flowing toward a yet-inchoate idea.  

LLMs will be able to accept prompts from us in the form of "this picture I took of the sunrise," or "this collection of brands assets or illustrations or graphics" — and channel that inspiration into a coat of digital paint on our apps & websites.

Creative mode: code

Is code here to stay?  To formulate an opinion on this, it’s worth examining why code exists in the first place. 

Code is a tool for unambiguously encoding data or sequences of instructions (algorithms) that we can reason about logically as humans, which also have meaning to computers. 

When we use the word “code,” we are generally describing either programming languages like C++ and JavaScript, or data-encoding languages like JSON and YAML.  In both scenarios, you can think of code as a common language between computers and humans.  With LLMs at our doorstep, we're finally breaking into the territory of natural language like English being a common language as well.  

So: will we create all of our apps, websites, and digital graphical interfaces entirely with English & other natural languages in the future? 

While English & other natural languages will increasingly become portals to computation, “code” as we think of it today will stick around for at least two reasons: 

(1) Ambiguity — Natural language is generally more awkward to channel into unambiguous instructions than it is to channel a programming language into unambiguous instructions.  As long as we speak organic languages like English, rife with both structural and lexical ambiguity, we will benefit from computer languages designed to avoid these pitfalls.

(2) Visuospatial information density — well paraphrased with the idiom "a picture is worth 1000 words." Describing graphical or spatial content — like a picture, or a GUI, or hierarchical information like relational data, or spatially related data like the values in a spreadsheet — will remain best served by code and data-encoding languages. This boils down to the fact that visuospatial information can be quite dense, while natural language is inherently sequential. For an illustration of this phenomenon, think about the last time you had to wait for a call center’s automated telephone recording to read out numeric options for you — and how you felt while you navigated this system — vs. how quickly you can find options when you have them all laid out in front of you on a screen.

The future is more collaborative

As humans, we tend to develop specialized skills.  Some people are proficient with code; some are proficient with drawing & painting; some are proficient writing natural language.  Some folks are dealt a lucky hand and are proficient across several different skills — but usually, we work professionally on diverse teams where different contributors have different talents, and this diversity becomes a strength of the team as a whole.

Now the problem today is, these modes of building software are mutually exclusive.  Either you create a GUI using code, or you use a visual builder like Webflow.  Either you draw an idealized GUI in a design tool like Figma, or you “design in the final medium,” — but you don’t do these things together, not in the same language.  Where we must collaborate across these modes, we do so in the form of “hand-offs” — of tasking a human being to translate, for example, a drawing of a user interface (for example, in Figma) into a “real” user interface (for example, in HTML/CSS, or Webflow, or developer platforms like SwiftUI / Jetpack Compose.)

In the future, we won’t have hand-offs.  Tools specialized for each creative mode will be able to affect the substrate itself.  We will be able to collaborate seamlessly across different modes, and each contribution will be additive and interleaved, instead of siloed and waterfalled.  The ability to create collaboratively around the same source of truth will not only make creation far more efficient, but more creative as well.  Imagine artists adding art to a codebase while engineers add code, and marketers add copy and managers add tickets & comments.

The future is democratized 

You may have already identified this in the negative space of what we’ve envisioned above — but by lowering the technical bar to creating interactive experiences, more and more humans will be able to create interactive experiences — apps, websites, interactive cartoons, games, data visualizations, 2D and 3D experiences, and augmented & virtual reality.  

As a reference point, consider the humble spreadsheet.  Anyone, with very limited technical training, can pick up & use a spreadsheet.  It’s so visual — point, click, type, enter.  Spreadsheets are also the sterling example of a “low-code” tool, where writing programmatic expressions has an extremely low technical bar, with immediate feedback, and without all of the ancillary technical hurdles of most programming environments.

This may help explain why Excel spreadsheet formulae are the world’s most widely used programming language  — and why as many as 2B people use spreadsheets today. That’s roughly 1/4 of all living humans.

In our utopian future, anyone who can make a spreadsheet can make an app or a website. Any mom & pop selling handmade goods in a developing economy will be able to use their smartphone to publish an interactive e-commerce site.  The prosperity enabled by digital connectivity and commerce will be extended to the entire globe, as more people can create interactive experiences, rather than just consume them.

How do we get there?

We face a certain truth today: we don’t yet live in our utopian future. 

“Truth is not what you want it to be; it is what it is. And you must bend to its power or live a lie.”

- Miyamoto Musashi

Our design & developer tools live across a chasm of hand-offs.  Visual builders are creatively limited and locked into proprietary platforms.  Not to mention, there’s tremendous momentum & commercial interest  behind existing technologies & tools, and these existing technologies aren’t going to unify themselves.  The truth is, we live in a fractured digital creative world.

But if we can imagine this future, we can build it, right?  This is the magic of invention after all: with enough audacity & grit, history has shown time & again that a third option can be forced into Musashi-sama’s dichotomy.  You can bend to the power of truth, you can live a lie — or you can bend truth itself, by building something that changes the rules.

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”

- Buckminster Fuller

When you think about it this way, a more creative, more efficient, more connected future seems well within reach. It will require blood, sweat, and tears — but a better future for GUIs is ours for the building.

Death of a startup

18 months ago, I shut down my last startup, Haiku Systems Inc.  Our mission was to "Unify design & code — to unlock new creativity."  We battled it out for a few years, pivoting a couple times. Our most loved (and remunerative) product was a design tool called Haiku Animator, which is now open-source, though unmaintained.

Have you ever had an opportunity come along that feels like it could change your life?  Some goal you’ve worked toward for years, which one day is within your grasp — you just need to win this one battle.  A linchpin that, if removed, will catapult you toward your life goals.

For me, Haiku was that opportunity.  My career aspiration had always been entrepreneurship.  Back in 2018, after over a year of slog with my co-founder, we managed to assemble a team and develop a scrappy, revenue-generating product.  Based on that progress, I was able to raise a $3M seed round from Silicon Valley investors.  

This was my shot.

Maybe, like me, you’ll do whatever is necessary, bound by your moral compass, to seize such an opportunity.  Long nights, lost sleep, emotional turmoil, gray hairs. Cursed and blessed with more than my fair share of tenacity, I remember resolving to myself: "Haiku will survive."  And survive we did, for several years.

The problem:  I was so intent on Haiku surviving that, when faced with difficulties and the need to pivot, I compromised on ambition.  The path to survival is to be less ambitious.  And through an insidious blend of execution errors, leadership discord, and bad luck, we pivoted multiple times.

In mid-2021, over the backdrop of the pandemic, and after my co-founder and I parted ways, I finally recognized that Haiku was in a death spiral.  We no longer had the capability, financially or in morale, to exploit any opportunity that might come our way.  So, I pulled the plug.

And I started reflecting.

From the rubble

The problems with Haiku began when my co-founder and I didn’t see eye-to-eye.  We disagreed about what we should do as a business, and we separately did our own things, made all the easier by being 100% remote.  As CEO and tie-breaker, ultimately, drilling into this misalignment was my responsibility, and not doing so was my most fundamental error.

Our misalignment culminated in a product that wasn’t quite made for anyone, with too much complexity, with a dead-ended trajectory — it was making money, yes, and it was serving a niche use — but this was not what any of us had signed up for.

We needed to pivot, and this was the end of the road for my co-founder and CTO. The problem: with him off the ship, we were left without an inventor, which ended up being a very difficult role to replace mid-voyage.  Meanwhile, Haiku: the company, the strategy, the mission, "to unlock new creativity" — they were all predicated on invention.

It turns out it’s exceedingly difficult — maybe impossible — to delegate the core, atomic act of invention. 

But I could see this only in retrospect, from the rubble.

Renaissance

The pandemic brought mortality closer into focus for many of us.  Haiku played out over 14% of my expected lifespan.

The mission that has guided my life's work so far, to unlock new creativity — to empower creative expression on screens, to bring the interactive digital medium closer to art — still had an inexorable draw.

Yet I could be dedicating my life's energy to taking on global hunger!  Disease!  Climate change!  Agriculture, infrastructure, human rights — the list goes on. 

So I stepped away from the problem.  I visited family across Europe, North America and Asia.  I proposed to my ever-supportive now-husband.  I dove into 4x4ing and off-the-grid camping in the deep wilderness of the U.S. West Coast, from the Mojave Desert to the Olympic Peninsula.  I cooked.  I made music.

I breathed. 

Through the lens of my life goals, I knew I wanted to do something with impact.  As a friend put it, I wanted my next project to be worth putting on my tombstone.  Is creative empowerment a tombstone-worthy cause?  

Etched within me is a belief: we have barely scratched the surface of the creative potential of computers.  We have been stuck in local maxima, since the ‘90s and ‘00s, in how we create software.  The fractured way we collaborate between creative stakeholders; the disjoint languages across the worlds of design & code.  The painfully low creative fidelity and performance of foundational UI platforms like HTML and CSS. The fragmented landscape of desktop, mobile, and web application platforms.

And here’s my burden: I can see a better world, in cursed, vivid detail.  I first caught a glimpse of it years ago, when I learned to code in Flash — a design tool for shipping cross-platform software; a multi-stakeholder creative collaboration tool.  A no-code tool well ahead of its time. A splash of the future. 

We lost a chapter of history, an entire category of collaborative creative tooling, when Flash died, and with each passing day our world ever-more-sorely needs the next chapter to start — for creativity’s sake.  For art’s sake.

Beyond dreams of creative empowerment, what sealed the deal for me was this: we have the potential for so many more human beings to create and collaborate around software, if we could just figure out the right platform to enable them.  Over one billion people use spreadsheets.  That’s a tool for making software.  Why can’t every one of these people make apps and websites, too?  How do we usher in the next five billion software creators?

To unlock creativity, and the empowerment that comes with creating software — potentially for so many people — yes, this is a calling. This is worth ten more of my prime years.  This is tombstone-worthy.

So one day, I sat down and tried something I had not tried in a long time. I started coding, all by myself.  I wasn’t filling gaps.  I wasn’t adapting, or reacting to a broken team or culture, or doing any of the million other things needed to maintain payroll and livelihoods. I was no longer delegating the act of invention to somebody else.  I just started building what needed to be built.

Wilderness

I set out to create the best damn digital creative tool I could imagine, no matter the cost. It had to be fast, thus built close to the metal (C, C++, or Rust.)  It had to start as a developer tool, but pave the way for design collaboration.  It had to run on any device.  It had to enable a portal to non-technical users — as a rule of thumb “anyone who can use a spreadsheet should be able to use this creative tool.”

This tool would need to read and write code, so it needed to operate on the substrate of a computer language that is suitable for all the creative stakeholders and tools surrounding software teams. Such a language didn’t already exist, so I added it to the list. 

As I tabulated the requirements, the amount of work ahead grew and grew.  With the necessary capital and a full team, this business would easily be a 10-year undertaking.  But how to get there, starting as a single person?  The invention needed to be able to speak for itself.

Two years.  I estimated it would take two years to reach the "Eureka" milestone, to the point where the idea speaks for itself and can attract others to the mission.  Two years of irrationality, of starving artistry, of "this is crazy," because it presupposes a world that definitionally doesn't exist.  Until it does.  An invention, successfully executed, changes the world. 

So I approached it as war.  Anything was on the table — nothing was sacred, all that mattered was building the right thing, for the right user, to rain fire on this opportunity.  JavaScript was a problem — so go beneath it to C and WebAssembly.  Skia is a problem — so write a <100Kb, cross-platform, operating-system-level rendering engine and interactive runtime in Rust.  HTML and CSS and React are a problem — so write a new declarative UI language, designed for humans as well as machines, and write the necessary companion grammar, parser, and compiler.  The web browser is heavy and slow — make the browser, and all of its technology, optional.  Imagine it's 1995 and we're building the foundational layers of computing again — like the browser, like the operating system, like creative tools.  

Like I said, nothing was sacred.  And the code kept flowing.

Naturally, the best name I could come up with for this violent project was Pax.  Pax means “peace” in Latin, and Pax was the Roman goddess of peace. The name is also a nod to Unity, which is one of many technologies that inspired Pax.

Message in a bottle

Building the first versions was hard, spiritually and intellectually.  It's the most technically challenging thing I've ever undertaken.  For over a year, I didn't know if it was even possible, or if I would hit some intractable dead-end as I filled in the implementation details.  Each day I had to hack through relentlessly creeping brambles of doubt, and the ever-increasing need to, you know, make money, and make sure I'm doing right for my career and family.  Was my husband wondering if he made the right choice?  Am I making the right choice?

Steadily, though, it started coming together.  The rendering engine, the responsive layout system, the reusable & composable component system, the C ABI bridge that connects the operating system-specific rendering engines with the Rust-based runtime, the declarative GUI language that might just deliver the ergonomics of high-level, React-like authoring to the world of systems programming.

In September of 2022, almost a year after starting, I put out a message in a bottle.  I open-sourced Pax, committing to developing it in the open thereafter.  And I wrote the initial docs and put out a simple prototype demo.

The tech wasn't ready to use yet!  It was open-source demo-ware.  Thus, broadcasting this developer tool was likely to backfire — imagine inviting (with fanfare!) patrons into a new restaurant before the kitchen is operational.

Maybe, though, I could find a kindred spirit, a partner for the journey.  So I crafted this message for him, or her, or them, and gently launched Pax Alpha Preview into the world.

Collaborator

January 2023. It started with a LinkedIn InMail.  Probably spam.  But this one hit different — Warfa Jibril, fresh MBA graduate from Stanford, with a highly technical background: studied computer science at Carnegie Mellon University then worked for several years as a software engineer at Google.  He wanted to pick my brain about my experience with Haiku.

We hopped on a call.  Turns out, Warfa is passionate about design & development collaboration, and about the future of digital creative tooling.  Just like me.  He had been at it solo for about a year.  Just like me.  Our conversation started about Haiku and the problem-space, then I blind-sided him with this project I had been working on, Pax.  As we dug into Pax — crazy as the whole thing is, and thanks uniquely to his own experiences of the last year — it all just clicked with him.

Our next meeting, over coffee and a walk that circumscribed downtown Berkeley, was rapid-fire conversation: non-stop, discussing ideas, experiences, and philosophy; exploring compatibility, alignment, and vibes.

Each subsequent meeting with Warfa left me more and more curious.  This man is highly intelligent and technical, but also well balanced and charismatic.  Ambitious, but extremely practical in execution. Kind-spirited, but formidable.

Particularly special is the collaborative leverage we have been able to find through first-principles communication.  Whereas both of us are highly technical, yet also have footings in the world of business, we can attack any problem with a shared vocabulary, e.g. of discrete math, deterministic finite automata, set theory, and programming languages — across problem spaces like psychology, fundraising, strategy, hiring, and communications.  It's some kind of hacking.

Soon after meeting, we started working together on Pax full time.

From left to right: Zack and Warfa on a walk through the Berkeley Hills

Eureka and beyond

Connecting with Warfa lit a new fire under me.  Pax was ahead of schedule.  The Eureka milestone — where the invention could speak for itself — was close at hand, not two years out after all, and it could be sped up if I put my nose to the grindstone.  Imagine a tunnel under a mountain, a year into digging — and imagine that last push before you see daylight on the other side.  That’s where we were.  I just needed to power through, to get Warfa onboard.

Then, a few weeks ago while Warfa was working out of my place in Berkeley, the first beam of light broke through.  "We've got it."  I showed Warfa my screen: write some Pax, compile it, render on screen; rinse, repeat.  We had our loop.  It was alive.

Since then, Warfa has already started shipping code in the heart of the rendering engine, compiler, and standard library! Now, together, we’re rapidly approaching the Alpha launch for Pax, when we can finally get this technology into users’ hands.  And really, this is just the beginning — there’s a long road for this developer tool to become worth its salt, and an even longer road to birthing the collaborative and creative tooling that connects non-developers with developers.

As with any long journey, we’re taking it one step at a time.  And most importantly of all, now it’s “we.” 

Subscribe

Subscribe to Developing Pax for more writings, from Warfa, from me, and from future collaborators.  You'll see more when we launch Alpha and beyond.

Subscribe now

Thanks for reading!

Zack

Their underestimation highlights the staggering developer growth over the last few years. With this growth has come an increasing interest in tooling for developers. As a result, early-stage developer tool companies received over $4.4 billion in funding in Q4 of 2022, nearly triple the amount invested in Q4 of 2019.

Although the growth in developer tooling is impressive, many criticize it for only empowering a small fraction (<1.5%) of the world's population to create software. "No-code" tooling emerged to fill this hole and enable non-developers to build software applications.

No-code is a software development process that enables programmers and non-programmers to create software applications using a UI (user interface) without requiring manual coding. 

The idea itself is not new, but the number of software creation tools classified as "no-code" has grown significantly over the past five years. Notable examples include Webflow, Airtable, Bubble, Retool, Notion, and Amazon's Honeycode. 

The popularity of no-code tools has resulted in a differentiation between software creation tools geared toward developers and those catering to non-developers.

Although "no-code" may suggest the opposite of developer tools, these tools have more similarities than differences.

They both take developers of varying proficiency and allow them to create their software. 

In fact, if you step back and look at it:

No-code and developer tools are the same thing — they just provide different levels of accessibility to their users and offer varying levels of extensibility. 

In software, extensibility refers to the ability to add new capabilities or functions, just like how Lego bricks allow building on top of existing models, while other toys would require buying a different one.

React vs. Webflow

Let us take React as an example. React is a developer framework for building user interfaces. It’s built on top of JavaScript and is one of the most popular web frameworks among developers today. 

This is what React looks like:

React is incredibly extensible. Users can write their own components (which act like Lego) and completely control how they are shown in the browser. They can define their styling and layout within React or separately. 

On the no-code side, let's look at Webflow. Webflow markets itself as a no-code website builder. It gives users a visual editor (shown below) to style and lay out their web pages. Internally, it uses HTML and CSS (like React) to lay out these pages, but it hides much of that complexity from users in favor of a more accessible experience.

If you asked me to build, say... Twitter, I'd be hard-pressed to choose Webflow. I'd need to make custom file storage, direct messaging, and many more features that this "no-code" tool doesn't support. Simply put: the project would require significantly more extensibility than Webflow offers. React would be a much better choice.

For a basic web page, both Webflow and React can be used. However, even as a developer, I'd pick Webflow. Its visual layout system is faster than messing with CSS, and I can deploy it within the tool. I could have a website up in under 10 minutes.

My point here is to illustrate that there are use cases in which less complexity is preferred, even for developers. 

Accessibility or Extensibility

Looking at all the tools available to build software, we can begin to organize them by extensibility. 

We can establish a partial ordering among these tools by defining that a tool is more "extensible" than another if it has the capability to create the latter.

In our example, we'd say that React is more extensible than Webflow because we can build Webflow with React, but not the other way around.

Applying this to some commonly used tools, we get something like the following:

At the top, we have C. C is a general-purpose programming language that underlies a lot of technology we use today. Virtually any project can be built using C, but even seasoned programmers avoid C (unless absolutely necessary) because of its complexity. 

The following two levels (JavaScript, AWS, React, NodeJS, Vercel) are typical "developer tools". These tools are often built in more complex languages like C; offering programmers increased ease and the requisite flexibility to do most work. 

Traditional 'no-code' tools (Retool, Webflow, Airtable, Notion) are at the bottom. Although they are the most accessible, they are also the least extensible. These tools are often marketed towards non-coders, but even developers can benefit from their specialized user interfaces, which can provide the fastest solution to modest problems.

At each level, we trade extensibility for accessibility. To make things easier for users, it seems inevitable that we shrink the universe of problems these tools can solve. 

Is this always the case? Are there tools that offer both high accessibility and high extensibility? 

A tool that grows with you

Imagine a tool that's user-friendly enough for anyone, even your parents, and also robust enough to meet the needs of industry professionals. Although it may seem like an impossible balance to achieve, you are already using a tool like this: spreadsheets.

Spreadsheets are a prime example of high accessibility AND extensibility. They have a simple yet powerful interface that can be used for anything from a grocery list to a complex financial model. Spreadsheets are used by over a billion people worldwide, including both lay and expert users. They provide complexity to those with advanced knowledge while remaining user-friendly and extensible for everyone.

While they aren't new, spreadsheets showcase what's possible with a tool. They show us that it's possible to build something radically accessible with high extensibility. They show us that a user can define the tool rather than the tool defining the user.

The spreadsheets of developer tools doesn’t exist at the moment, and I doubt it will exist until we re-examine how we develop today. Were HTML and CSS designed to be accessible to everyone? Perhaps in 1996, but today I know plenty of professional developers that would say it wasn’t even designed for them. We can now build a similarly extensible alternative that’s far easier to use. 

Yes, the future development environment does look closer to Webflow than VS Code, but we can’t get there by shunting extensibility. A tool must be built for both developers AND no-coders. Otherwise, we will not bridge the gap and will be left with tools for creating landing pages rather than creating software.

As we aspire to a world where over 2% of the population is creating software, we need tools that allow more people to do more. Spreadsheets showed people rows and columns and taught billions how to program (via formulas). Today, we have a similar opportunity with developer tools to give users visual builders that can teach them how to build software.

An opportunity to make experts rather than simply catering to them.

Thanks for reading! This is part of our vision with Pax. We’re building a developer tool that will natively support non-coders. Please reach out if you want to chat about it.

Zack and Warfa reporting from Pax HQ! It’s been a whirlwind few months for us and we wanted to update you (our friends & family) about the recent changes. 

The 3 major updates we wanted to share are: cofounder update (Warfa), reaching “eureka”, and the new blog (Developing Pax).

New Co-founder

The first update is that the Pax team has grown from 1->2. Zack and I met organically at the end of 2022. By then, without realizing it, we had already been working remotely together for quite some time. 

I graduated from my MBA at Stanford earlier that year. Through school, I had grown obsessed with figuring out how to improve the “design->dev” hand-off process. For our lucky readers that haven’t had the pleasure of dealing with this, it's the process of turning a design for a software application into the application itself. Designer’s tools like Figma have redefined the process of conceptualizing graphical user interfaces (GUIs). While these free-form tools are ideal to support creativity, it requires painstaking work by developers to turn the output (pictures) into reality. As a developer constantly faced with this work, I believed there had to be a better way. 

I began building a Figma plugin called Rembo, Swahili for beautiful. My goal was to take design data from Figma and declaratively generate Javascript UI components to ease the hand-off process. 

In parallel, with my newly acquired MBA skill (talking), I began to have conversations. A lot of conversations! I talked with trendy designers and curmudgeon engineers. I talked to senior developers at massive companies like Adobe that said this problem was impossible to solve and sole designers at tiny firms that craved even a marginal solution to this problem. 

As I listened to all these perspectives, I began to build a matrix. On the X-axis, I put experience with the complexity of this problem and on the Y, I put optimism about solving it. 

Throughout my conversations, I was constantly met with two perspectives: I named them the dreamer and the pessimist. The dreamer has touched the problem in some way but has never attempted to solve it. They can imagine a world without it and are excited to explain how this current one sucks. They were great interviews to learn about current industry practices and the issues stakeholders face. The other perspective, the pessimist, was often a dreamer who tried to solve the problem themselves. They are typically technical and have gotten far enough in their journey to touch the immense complexity intrinsic to this problem. They were great to talk with to understand the limitations they see in current technology and to learn from their approaches. 

After a year of independent research, prototyping and these conversations, I stumbled on Haiku. 

“Haiku exists to unify design and code: to power new creativity.”

The Crunchbase description immediately stuck out to me. It wasn’t a product; it was a vision. I dug deeper. The company had operated for 5 years. They raised money, released a few products and had since shuttered in 2021. I found their CEO on LinkedIn and shot him an In-mail. The ask was simple:

With a 99th percentile response time, Zack hit me back with his Calendly and his eagerness to chat. I quickly scheduled 30 minutes, excited for the call.

Our “30 minute” call, days later, proved to be the most insightful conversation of the past year. As I pestered Zack with questions about his thoughts on the problem, I soon found myself drinking from a fire-hose. His knowledge was both deep and comprehensive. He talked about the GTM difficulty of targeting both designers and developers. An obstacle he had faced with Haiku and I had too began to touch with my Figma plugin product Rembo. After that he moved onto the technical complexity of the problem, going so far as to compare it to AGI.

As we dug through this, knowing his experience with Haiku, I had assumed that I had met another pessimist. 

It wasn’t until an hour into our 30 minute conversation, that he segued into his current work: Pax, a new user interface language. After Haiku, he had come to the conclusion that a venture-funded business wasn’t the right venue to innovate on this problem. He believed that it required an “invention” before the business and decided to dedicate the next year to that belief. 

As he talked about Pax, I began to think about my work generating Javascript while building Rembo. Zack had embarked on an even more audacious project; he had decided that Javascript alone was not the right material to bridge the gap to design. It needed something tailored from the ground up. Having just spent a year myself attempting to use Javascript for this exact purpose, I understood why. The language wasn’t meant for it; attempts to generate JS from designs quickly becomes unwieldy. This results in a terrible experience for developers that is virtually impossible to sell. 

Zack had decided that instead of banging on the Javascript wall, he would dig a tunnel underneath it. Having just spent a year talking to many pessimists that had starved from banging on this wall, I saw the wisdom of the choice. 

By the end of the call, I knew two things: 

1) I wanted to consume all the information online about Pax. 

2) I wanted to work with Zack.

I had found the third section of my matrix: The Collaborator 🤝: someone knowledgeable yet optimistic about the future.

Not long after this, Zack and I decided to partner up to attack this problem. Sparks have been flying ever since and we’re both fired up about the long journey ahead!

Reaching “Eureka”

The second important update is that we’ve reached automatic compilation for Pax, dubbed “Eureka”. This has been the culmination of over a year of work on the Pax Language. It is now possible for a new developer to write a Pax app and automatically compile it for Web, by way of Web Assembly, and Mac, with LLVM. This is a massive step towards onboarding developers onto Pax and a mission critical step for our public launch!

We’re now hard at work improving the developer experience on Pax and rounding out the standard library. During this process, we'd love to chat with Rust developers! If you or someone you know works with Rust, hit us up!

Stay tuned for our alpha launch in the coming months! 

Developing Pax (blog)

Finally, the last update is that we’re starting this blog as a channel to share updates and interesting ideas we encounter along the journey developing Pax! We'll cover everything from the technical aspects of Pax's architecture (hint: Rust + Web Assembly) to breakdowns of the current collaboration landscape (such as a comparison of Figma vs. Webflow).

Follow along with us and join our Discord as we explore the possibilities of creative design and development. 

Subscribe now

Thank you to all our friends and family for the support so far!

Zack & Warfa

Read this section of Pax’s docs for some ideas on how to help.

Run demo

As of this writing, you can run the Pax demo for macOS and Web on the jabberwocky-demo branch, after following the instructions in README.md, then using the shell scripts ./run.sh and ./run-web.sh

This has only been tested on macOS! The Web example should work, perhaps out-of-the-box, on Linux and Windows development machines. The macOS example will only compile if you are developing on a Mac.

Compiler finish-line

The most fundamental remaining work for Pax to become useful is to finish automation of the compiler. Until that automation is complete, here are the manual steps necessary to write a Pax program today:

• "unroll" any Pax code into RIL ("Rust Intermediate Language"), in the specific format required by pax-cartridge. This includes creating individual vtable entries for each expression and writing instance factories for each component.

• compile the resulting Rust "cartridge" into a library

• load that cartridge library into one or more native app chassis (e.g. pax-chassis-macos) and build the chassis/cartridge combo into a single cdylib, then

• plug that cdylib into the appropriate platform "harness", running an external compiler to generate a final executable (.app, .exe, etc.)

This is not particularly user-friendly: what would be the point of writing C if you had to manually unroll it into assembly before you could run a program?

The work for the compiler finish-line is happening on the master branch on GitHub. Once this work is done — and you can write + automatically compile basic Pax programs — Pax can progress from alpha preview to alpha.

Hot on the heels of compiler finish-line work will be error message improvements and a language server for debugging & syntax highlighting, among other things.

Async

A common use-case with GUIs is: "load some data from server; update GUI."

While awaiting a response from the server, a user may reasonably expect that the GUI will continue rendering, animating, or updating.

This is not yet the case for Pax, because it does not yet attach to async Rust code.

The planned approach is to write all future event handlers as async, and to dispatch those methods asynchronously via the Pax runtime.

#[pax(/*...*/)]
pub struct MyStruct {
    pub app_data: Property<String>
}
impl MyStruct {
    //Note the `async` below!
    #[pax_on(DidMount)]
    pub async fn fetch_data(mut self) {
        //Proposed API:  for async functions, a "disposable" copy of the struct is passed by move from the Pax runtime. `my_crate::MyStruct::fetch_data(disposable_copy)`
        //`Property` is in charge of opaquely managing message-passing, such that by calling
        //`self.app_data.set("new value".to_string())` on this local, disposable `self`, a message is
        //sent to the canonical PropertyInstance to update its value.
    }
}

The above approach will require embedding an async runtime into the engine. In the long run, this will require that the async runtime can be parameterized, or swapped out. One possible approach is via the patch mechanism used already inside pax build.

Cross-platform++

Further work remains to run Pax on more screens. To support a new platform (like Android,) a new chassis and dev harness must be built. Thus far, two (chassis, dev harness) pairs have been built: see pax-chassis-macos/ and pax-chassis-web/.

In order to support targeting Linux, Windows, Android, and iOS, a chassis and dev harness will need to be written for each platform. In broad strokes:

1. writing a low-level bridge in a platform-native language (e.g. Swift on macOS) to accept the C structs that pass over the wire from the Pax engine, and

2. interpreting these structs as messages, mapping into CRUD operations for native elements like text and form controls. (search for the method processNativeMessageQueue in pax-chassis-macos for an example.) pax-chassis-ios will be able to share about 90% of the logic already written for pax-chassis-macos, so iOS support is close at hand.

3. keeping each chassis' CRUD logic updated over time with the addition of further native rendering elements, like form controls and drawing primitives

More primitives, form controls, and layout components

Pax's component library is just getting started, and to be a truly useful GUI and graphics toolkit it requires a more thorough standard library.

Some high-priority upcoming pieces:

Form controls:

• Dropdown list

• Text input box

• Checkbox

• Radio button list

• File upload

• Date picker

Drawing primitives

• Path (bezier sequence)

• Ellipse

• Polygon

Layouts & widgets

• Scroller (plus native scrolling hookups)

Interested in helping?

See this article on contribution.