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.
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.
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
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.
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.
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/
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
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.
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 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.
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.
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.