On the other hand, video games enable a wide breadth of intellectual experiences.
Being a simulated guitar hero and simulated pro skater is more enriching than the likely baseline of having zero experience with either.
And, video games can help in discovering real world passions — the number of guitarists who found their inspirational spark through Guitar Hero is likely significant. Same for Factorio or Minecraft -> programming.
Yes, supporting additional languages is straightforward; just need to write language-specific SDKs with bindings to the necessary Pax APIs, which are exposed through an ABI / FFI. (a major advantage of building at the systems level.)
Major constraints for a given language will be runtime size and browser viability — it's fine to use e.g. C# and the CLR when deploying a desktop or (arguably) a mobile app, but it's a showstopper to bundle a several-hundred-MB wasm runtime to ship a C# app to the web. Zig and C++ don't share this problem, and JS gets a freebie because the browser already includes the JS runtime.
Community contributions would be amazing in this regard. Likely our core team should ship JavaScript support first as a template, then Pax's language support should be roughly as extensible as e.g. Stripe's SDKs: https://github.com/stripe
C# does have WASM flavour, and several hundred (the runtime is actually very light, it's the whole SDK installer that weights this much) turn into a couple megabytes. It's not perfect with Mono-WASM target still, so there's an experiment for NativeAOT-LLVM that builds on top of .NET's IL AOT Compiler that is significantly more size and performance efficient.
I should’ve added - seems like an awesome concept! I’ll retry on desktop today :) you should be very proud of what you’ve built! I was in a grumpy mood and not softening my messages
Honestly wish your team as Borat says “Great Success” seems like heaps of thought and planning has gone into it. And Rust is cool. One extra feedback id make is to have an image/gif/video at the very top of the GitHub read me as the first thing someone sees. That will hook more people (from experience) as it’s quite a technical project (can you condense the idea into a visual or a sub 10 second gif?)
Have you tried posting on reddit? I’d imagine you’d get a lot of traction there, post on r/webdev at 8pm Thursday night NZ time
Thank you for the follow up and suggestions! We did post on r/rust with solid reception[0] and I've added r/webdev to our channels list for the next push.
Will also capture a GIF, makes a lot of sense; just gotta nail condensing the story.
> I hope in the process of doing it we will find new ways of doing things.
HTML & CSS themselves have become a major bottleneck to quality and creativity. The arcane layout model, the baggage of backwards compatibility, the cognitive dissonance — played out over decades of design-by-committee — between "this is a document engine" and "this is an app engine."
The rendering-thread-is-the-main-thread architecture of JS plus the JS garbage collector cause jitters & frame drops that most people don't consciously recognize, but everyone subconsciously recognizes. These little bits of jank are why consumers can recognize webview-wrapped apps vs. native apps.
Don't get me wrong — HTML and CSS and JS have brought us far, and the zero-trust execution environment that is the browser is an amazing feat of humanity.
I hope the "new ways of doing things" you describe include a major innovation on HTML and CSS and JS. WebAssembly makes this possible today — and I have dedicated the last few years of my life to proving this concept[0], and I hope others explore similar avenues. We deserve a better substrate, and this can be done without reinventing the browser.
I disagree. There has never been a better markup language. HTML allows precise control of atomic elements that make up a component. It has been the best thing for accessibility we ever came up with.
I can imagine no better way for readability and accessibility than a text-first representation of content, which is what HTML is. I will even argue that having the modern web emerge from a text-content first approach is the best thing that could have happened to us.
All other content representation infrastructures that weren't text first, like java applets or flash died because they were no match for HTML.
Agreed! Markup-as-content-backbone is one of many things HTML/CSS do extremely well, and I agree not building around something like this was a major weakness of Flash.
Silverlight sought to do this with XAML, but it had other problems (required a plugin right as plugins were on their way out; CLR was a huge dependency; too locked down and proprietary under Ballmer leadership)
Can you imagine a text-first content representation, which is visually editable with the UX of a vector design tool? This is the rabbit hole that drives our work on Pax.
Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces?
Don't get me wrong, I also could imagine better markup languages for that purpose. But everything I have seen in the wild was worse in multiple, show-stopping ways.
Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and put the solutions into CSS4 and HTML6
Both Figma autolayout and HStack / VStack are careful subsets of flexbox; not quite the same thing. Consider whether a marble statue is "just a subset" of the block that contained it.
None of these is a perfect technology, but I believe the most practical answer to the question driving this thread[0] is to study/understand the landscape, then build towards a better future.[1]
[0] > Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces?
> Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.
Flexbox was once an "alternate layout engine for the web," as was Flash player, as is Figma. Framer, Retool, and Squarespace all offer alternate layout engines tailored for visual building. All of these seem practical to me.
1. not Figma or Flash: it's not practical or performant to manipulate HTML/CSS to achieve the creative freedom of a vector design tool[0]
2. the rest of these that build on HTML: not a single one of them exposes that code for manual editing, so they're not developer tools and their "alternate layouts" are proprietary + locked away.
The root issue: HTML was not designed to be a substrate for design.
[0] I don't claim this casually; I spent several years seeking to do exactly this with github.com/famous/famous and https://www.haikuanimator.com/
`Waiting for fonts.googleapis...`, pax website was blank for a couple of minutes, might want to reconsider making third-party fonts non blocking on your website so it doesn't appear broken/empty when a third-party CDN edge is slow.
It's one of the core things that has enabled the web to be as useful as it is. One of the things that draws people in, and keeps them using it.
Yes, there are problems with what we have. But if you break compatibility, you'll either not be adopted, or part of the crowd that the audience yells at for taking away their favourite things. You'll kill efforts and bury knowledge bases.
I don't think the world should abandon HTML, nor break backwards compatibility across the HTML spec. The first cars drove on roads designed for horses, and horses are still around. At no time did we gather a committee and decree that horses were deprecated.
Taken to an extreme, "don't break backwards compatibility" has an insidious failure mode, which is "don't innovate." The car could not have come about without a willingness to break backwards compatibility with horse drawn carriages, plows, mills, hitching posts, etc.
The adoption of a radically new technology like this is voluntary, collaborative, and progressive. Provided it offers enough value to exceed the switching costs, there's no need to kill efforts or bury knowledge bases.
Doesn't the rendered page run in a different thread to its JS? If the website does use some SPA framework to lazy-render the components, load the new view, or execute some logic, maybe then, but when I say run `(() => { const s = Date.now(); while (Date.now() - s < 10000); })();` and try to scroll the page, it doesn't freeze.
Interesting project. Have you tested any non-XML markup languages for the user interface declaration so that metadata doesn't take as much space as data in
<Text>Hi {firstName} </Text>
and also requiring double the number brackets
There are modern cleaner markup alternatives like kdl
We chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML.
We predict 95%+ of Pax will be written by machines, especially visual design tools and LLMs, so verbosity becomes less important (LLMs may even benefit from explicit closing tags.) We're innovating on multiple axes, including language, so we chose to make the syntax itself as boring and uninnovative as possible.
But clarify is exactly what's lacking because it's verbose, it obscures content at no benefit to simple matching bracket highlights
Also, will it be read 95% of the time by machines during design? That's not what the demo shows with the side-by-side xml and output, which I expect is a much more common workflow than 5%
The innovating part is what puzzled me and prompted this question - why cling to the old garbage when you're doing new design?
Point taken! And yes, especially for developers (our core target demographic,) you are right that hand-writing should account for >5% of code volume.
Syntax is fairly contentious. "One man's trash is another man's treasure," on your note of "old garbage." It's hard to please everyone, however:
We could offer syntax "skins," since the data storage mechanism is a layer separated from the AST (thus different ASTs/syntaxes could de/serialize from the same persisted data.) So folks who want closing tags can have them; folks who want a YAML-like format could have it; folks who want a KDL-like language could have it.
At the language level, Pax's distinguishing characteristic is that it's the union of an expression language and a markup language; this is the reason we couldn't use an off the shelf markup language / parser. But again, KDL or YAML could be extended with PAXEL to make pax-kdl and pax-yaml flavors alongside pax-xml.
We had to start somewhere, and starting as close as possible to the markup lingua franca (HTML) made sense to us. It'd be a dream for Pax to be loved / adopted enough that we or anyone else cares to make a syntax skin.
I won't claim Pax is better than any of these, but that we seek to solve different goals.
Unlike Flash: driven by a markup language, fully open source, no plugin required, solves a11y, compiles to native apps incl. mobile
Unlike Silverlight: fully open source, no plugin required, no heavy VM
Unlike JavaFX: no plugin required, no heavy VM, visual builder is a vector design tool
Unlike Flutter: designed for web (small footprint, a11y out of the box); first-party and foundationally integrated visual builder, visual builder is a vector design tool
Thanks for explanations. However, instead of making yet another framework, wouldn't it be better to contribute to Flutter (e.g. optimize its wasm target, add a vector visual builder), so there is one strong open cross-platform alternative to HTML/CSS/JS?
Pax's primary goal is "designability" — to enable a vector design tool to read & write the same content & behavior you may write by hand. (.pax files)
Our solution requires language constraints — a hermetic separation of concerns between the declarative description language (.pax) and a Turing-complete programming language (starting with Rust.)
These language constraints and rendering requirements[0] are so core to our solution that building anywhere other than the systems level was not tenable.
[0] Specifically, the runtime must render in "design tool coordinates," to enable a vector design tool authoring UX. This authoring experience must also be extremely fast, like Figma's. The rendering engine must be designed around this requirement and neither HTML/CSS's or Flutter's were.
Sort of like a new Flash, but open source, compiles to WASM or LLVM instead of requiring a plugin, and driven by language all the way down.
The language piece is a declarative UI language tailored to vector design; the vector design tool reads & writes this declarative language and you can go back and forth between visual edits and code edits. All of this attaches to and is driven by existing programming languages, starting with Rust and following soon with JavaScript.
Getting very close to our first launch! Have been quietly developing in the open for a while.
This is really cool. I've been building a GUI system in Rust that features an expression language[0] — and we ruled out using CEL a while ago because the canonical Go CEL interpreter would cost several megabytes of runtime footprint (e.g. in a WASM bundle.)
Haven't measured the footprint of cel-rust yet, but I expect it's orders of magnitude smaller than cel-go. The Go runtime itself is the culprit with cel-go.
This Rust implementation may let us port to CEL after all, while maintaining Pax's <100KB wasm footprint. Nice work!
> canonical Go CEL interpreter would cost several megabytes of runtime footprint (e.g. in a WASM bundle.)
At first blush Go seems incompatible with WASM in terms of maintaining Go's strengths—the two runtimes have different memory models and stack representations. I'm curious why one would choose Go if WASM were a target to begin with.
I don't know why people don't just use Lua. It's extremely small, can be embedded only with the Lua modules you want it to include (e.g. you do not need to provide file system access, networking etc. making it similar to CEL, just better), can be compiled to every possible target being written in standard C, is very mature and is completely open source.
The problem is that Lua is Turing complete, so you can write programs that don't halt or which take an input-dependent duration to halt. Example:
while true do
print("meow?")
end
In contrast, each CEL expression has a maximum depth which directly determines how long it takes to execute. (More precisely: by calculating the maximum costs up the expression tree from leaves to root.)
The point here is that you know (at maximum) how many instructions will be executed before running it, and so if it exceeds the limit, you can avoid running it altogether, instead of killing it midway through its execution, leaving things in an indeterminate/corrupt state.
You don't. Even non-Turing complete languages can run for an arbitrary length of time. In general Turing completeness is never a relevant property in the real world.
Well, they claim "linear time". Constant time would be impossible.
But anyway they achieve that by being much more restrictive than just "not Turing complete", e.g. you can't define functions.
It certainly sounds like an attractive feature, but how much benefit is it really to restrict a language so much that it will probably run quickly enough compared to just setting a timeout or computation limit? The only advantage I can think of is that you get some kind of computation constraints that don't depend on the data... But this is a pretty niche requirement.
It is a niche, yes. However, that niche is about adding some customizability to certain parts of a program, where Lua would be overkill. Moreover, hardening Lua, which is doable but not trivial, may be beyond the ability, interest, or simply time available to the developer. If you don't need the extra features Lua provides, why include them?
> If you don't need the extra features Lua provides, why include them?
The whole point of a feature like this is that you don't know what will be required. It's going to be pretty annoying when a user does find they need something that's impossible with CEL and they can't do it because the devs think they'll write slow code.
Lua is not very nice IMO, but I've used Rhai successfully in the past. It even has an operation limit feature already:
The games industry isn't nobody, that is how Lua got its fame, being a common scripting language, before Unreal and Unity became the only two engines most people know about.
> (digestive problems vs anaphylaxis) ... and would probably be better classified as an intolerance similar to lactose
is misinformation — "digestive problems" and "intolerance" drastically understate the seriousness of celiac disease, and contribute to the educational challenges surrounding the condition.
The chronic impact of gluten exposure to a celiac patient include: permanent damage to the small intestine, malnutrition, reduction of lifespan, and significantly increased risk of comorbid autoimmune diseases (MS, diabetes, and more) and cancer.
The acute symptoms span from gastrointestinal symptoms to neurological issues, systemic pain, and cognitive impairment. The reason for all of this is gluten causes the celiac patient's immune system to mobilize and attack the patient, i.e. "autoimmunity." Not anaphylactic, correct, but not a digestive problem nor an intolerance.
> I apologize for any inconvenience my current licensing terms may cause.
Friendly advice from a stranger, worth what it costs: I believe the greatest inconvenience of a commercial license will be to _you_, as opposed to end-users.
The market is so saturated with open source, developers expect it, and commercial licenses cause huge usage friction and doubt.
The "dual license" died as a viable business model around the time Meta (née Facebook) and Microsoft starting investing billions into free-as-in-beer OSS, 10-15 years ago.
Today, this model will only sabotage usage. People using your OSS is good. Even if your goal isn't to become popular, usage & feedback are learning, and while it's fine for popularity not to be a goal, I would encourage you not to proactively target the opposite of popularity.
If you have some other IP (the other tech you're describing) that can remain proprietary or wrapped behind a service, then people using other pieces of your stack for free is a _really good thing._ At least, they're aware of your brand and have started to trust it. At best, they're ready to use your commercial offering out of the gate.
Building a cross-platform GUI toolkit takes an incredible amount of work & time, especially at the systems level.[0]
A robust cross-platform ecosystem for the underlying programming language is a necessary but insufficient piece of the puzzle.
Given the proliferation of HTML and WebView/web-tech wrappers (Electron, Tauri, React Native etc.) there are now enough "good enough" solutions that most organizations that would underwrite the in-house R&D of a new Neuron Data or Delphi or Flash simply don't feel the need.
When it does happen — say Google Flutter — it's almost statistically impossible to keep the hydra of VPs and biz folks aligned over the decades of ongoing investment it takes to mature & form community around this kind of technology — see the recent Flutter team layoffs at Google.
[0] speaking from my experience building a cross-platform GUI solution in Rust for several years now; see pax.dev
Exactly. Many programmers don’t want to worry about edge cases, and cross platform GUI frameworks are essentially coding an “oops all edge cases” project.
Isn't the whole "Flutter team layoffs" narrative somewhat debunked at this point? My understanding is that some positions were cut and some were moved, but no more than any other engineering area at Google.
Being a simulated guitar hero and simulated pro skater is more enriching than the likely baseline of having zero experience with either.
And, video games can help in discovering real world passions — the number of guitarists who found their inspirational spark through Guitar Hero is likely significant. Same for Factorio or Minecraft -> programming.