5 ms·

> 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

> 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. [0] www.pax.dev

pyrale 2y ago
> These little bits of jank are why consumers can recognize webview-wrapped apps vs. native apps. That and, of course, the half-page box telling you how much better off you'd be if you were using the app.
throwaway14356 2y ago
I want to see different file types with their own rendering engines and/or programming languages in the same browsers. Very powerful but also very limited languages and formats that know what their purpose is.
eviks 2y ago
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
- zackbrown 2y ago
  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.
  - eviks 2y ago
    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?
    - zackbrown 2y ago
      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.
selfmodruntime 2y ago
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.
- zackbrown 2y ago
  It sounds like we agree about the good parts of HTML. > There has never been a better markup language. > It has been the best thing for accessibility we ever came up with. I observe past tense in both sentences above. So perhaps we agree, the salient question is: is it the best thing we can come up with? With a focus on the future. I argue we can do better, while celebrating and building off of what's great about the past & present.[0] [0] https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text=Prior%20Art%20%26%20Inspiration https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text...
  - ttepasse 2y ago
    Oh, yet another ActiveX.
    - zackbrown 2y ago
      Closer to "yet another Flash," but 100% open source, and no browser plugin thanks to WebAssembly
      - paxcoder 2y ago
        [dead]
      - galangalalgol 2y ago
        How about the same old flash emulated in wasm, so no plugin. https://ruffle.rs/ https://ruffle.rs/ Use those same great adobe tools in a vm.
  - selfmodruntime 2y ago
    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.
shakna 2y ago
Don't break backwards compatibility. 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.
- zackbrown 2y ago
  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.
atoav 2y ago
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
- zackbrown 2y ago
  > Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? HTML/CSS is pretty good! SwiftUI's HStack and VStack are solid, though they suffer from ambient API complexity & Conway's law.[0] Figma's autolayout is a strong reference, but it's not a tool for creating software. > 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 Why not both? Innovate freely and independently (the prerogative of any builder) and adopt as spec any innovations that pass committee. [0] arguably same diagnosis, different course of disease vs. HTML/CSS
  - madeofpalk 2y ago
    Isn't Figma's "auto layout" just a GUI for a canvas-based implementation of flexbox? Likewise, HStack and VStack are ports of flexbox to SwiftUI.
    - zackbrown 2y ago
      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? [1] www.pax.dev
  - odo1242 2y ago
madeofpalk 2y ago
HTML and CSS is the worst layout system except all others. But actually, HTML and CSS is pretty good considering the problems is solves.
- zackbrown 2y ago
  > HTML and CSS is pretty good considering the problems is solves. Agreed: pretty good. Shouldn't we pursue excellence?
  - madeofpalk 2y ago
    I think CSS is excellent and pragmatic. Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.
    - zackbrown 2y ago
      > 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.
      - themikesanto 2y ago
        All of the products you described are just tools that build HTML/CSS for you.
        zackbrown 2y ago
        > just tools that build HTML/CSS for you 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/ https://www.haikuanimator.com/
pona-a 2y ago
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.
replete 2y ago
`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.
- zackbrown 2y ago
  Thank you for the tip!
bangaladore 2y ago
To me, it seems like you are reinventing frameworks like Svelte while adding the complexity of Rust. I don't see the benefits.
- zackbrown 2y ago
  Primary goal of Pax is "designability" -- any project can be opened and edited visually at any time with Pax Designer, which is a vector design tool. The difference between Webflow and Figma is immense; Pax unlocks a Figma-style visual creative experience while building software.
niutech 2y ago
We already had Flash, Silverlight, JavaFX and now Flutter (with Wasm). How is Pax better than them?
- zackbrown 2y ago
  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
  - niutech 2y ago
    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?
    - zackbrown 2y ago
      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.

pyrale 2y ago

> These little bits of jank are why consumers can recognize webview-wrapped apps vs. native apps. That and, of course, the half-page box telling you how much better off you'd be if you were using the app.

throwaway14356 2y ago

I want to see different file types with their own rendering engines and/or programming languages in the same browsers. Very powerful but also very limited languages and formats that know what their purpose is.

eviks 2y ago

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

zackbrown 2y ago
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.
- eviks 2y ago
  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?
  - zackbrown 2y ago
    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.

selfmodruntime 2y ago

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.

zackbrown 2y ago
It sounds like we agree about the good parts of HTML. > There has never been a better markup language. > It has been the best thing for accessibility we ever came up with. I observe past tense in both sentences above. So perhaps we agree, the salient question is: is it the best thing we can come up with? With a focus on the future. I argue we can do better, while celebrating and building off of what's great about the past & present.[0] [0] https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text=Prior%20Art%20%26%20Inspiration https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text...
- ttepasse 2y ago
  Oh, yet another ActiveX.
  - zackbrown 2y ago
    Closer to "yet another Flash," but 100% open source, and no browser plugin thanks to WebAssembly
    - paxcoder 2y ago
      [dead]
    - galangalalgol 2y ago
      How about the same old flash emulated in wasm, so no plugin. https://ruffle.rs/ https://ruffle.rs/ Use those same great adobe tools in a vm.
- selfmodruntime 2y ago
  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.

shakna 2y ago

Don't break backwards compatibility. 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.

zackbrown 2y ago
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.

atoav 2y ago

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

zackbrown 2y ago
> Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? HTML/CSS is pretty good! SwiftUI's HStack and VStack are solid, though they suffer from ambient API complexity & Conway's law.[0] Figma's autolayout is a strong reference, but it's not a tool for creating software. > 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 Why not both? Innovate freely and independently (the prerogative of any builder) and adopt as spec any innovations that pass committee. [0] arguably same diagnosis, different course of disease vs. HTML/CSS
- madeofpalk 2y ago
  Isn't Figma's "auto layout" just a GUI for a canvas-based implementation of flexbox? Likewise, HStack and VStack are ports of flexbox to SwiftUI.
  - zackbrown 2y ago
    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? [1] www.pax.dev
- odo1242 2y ago

madeofpalk 2y ago

HTML and CSS is the worst layout system except all others. But actually, HTML and CSS is pretty good considering the problems is solves.

zackbrown 2y ago
> HTML and CSS is pretty good considering the problems is solves. Agreed: pretty good. Shouldn't we pursue excellence?
- madeofpalk 2y ago
  I think CSS is excellent and pragmatic. Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.
  - zackbrown 2y ago
    > 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.
    - themikesanto 2y ago
      All of the products you described are just tools that build HTML/CSS for you.
      - zackbrown 2y ago
        > just tools that build HTML/CSS for you 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/ https://www.haikuanimator.com/

pona-a 2y ago

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.

replete 2y ago

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

zackbrown 2y ago
Thank you for the tip!

bangaladore 2y ago

To me, it seems like you are reinventing frameworks like Svelte while adding the complexity of Rust. I don't see the benefits.

zackbrown 2y ago
Primary goal of Pax is "designability" -- any project can be opened and edited visually at any time with Pax Designer, which is a vector design tool. The difference between Webflow and Figma is immense; Pax unlocks a Figma-style visual creative experience while building software.

niutech 2y ago

We already had Flash, Silverlight, JavaFX and now Flutter (with Wasm). How is Pax better than them?

zackbrown 2y ago
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
- niutech 2y ago
  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?
  - zackbrown 2y ago
    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.