treenotation.org VS makepad

> concatenating them changes the label for [b] from "a" to "z\na", and perhaps more damningly, erases the whitespace before "z". But, since none of the alternative formats (except ndjson and I guess plain uninterpreted binary, ASCII, or Unicode) is closed under concatenation, maybe that's less important.

Yes, being closed under concatenation is a feature I was aiming for and it indeed does bring with it this issue.

Just something to have in mind when devising formats. A simple solution here is to disallow having anything other than whitespace in the suffix of a Jevko with > 0 children. Then, if a format converts these labels to keys in a map, trimming leading and trailing whitespace, there is no problem. This is how I did it here:

https://github.com/jevko/easyjevko.js

> I don't know if you saw the last time this topic came up I linked to https://ogdl.org/, which seems pretty close to a minimal rose-tree notation.

Yes, I've seen OGDL before. It's pretty nice. A similar one is https://treenotation.org/

I have experimented with indentation-based syntaxes myself, before settling on brackets.

I have found them to be problematic, at least because:

* For complex structures they become less compact.

* A grammar that correctly captures significant indentation can't really be written in pure BNF. The way OGDL does it is this:

  [12] space(n) ::= char_space*n ; where n is the equivalent number of spaces (can be 0)

This reminds me a bit of Breck Yunits' Tree Notation (https://treenotation.org/). Both seem to have a ~totalizing energy. Maybe some common cause. :)

Hi, I'm a programmer and I've used quite a few different languages in my career. I've never studied compilers or language design, however it has always interested me from afar. Also I've always had a strong preference for simple syntax, what sane person wouldn't? Anyway I've scanned over the https://treenotation.org/ site. I get the general gist, that this provides a tool to easily create languages that use tree notation. Unfortunately I still don't really understand how to use it. If there was tutorial that held your hand that would be really useful. I suspect there a large number of people like myself that would benefit from this. Perhaps at some point I'll role up my sleeves and do it myself, but I'm sure someone else could do a better job.

> The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.

About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2, nowadays https://treenotation.org/). It seems to me we've missed a sort of fundamental universal notation of the universe, which you can think of as "two-dimensional binary". I predict we will soon see a Cambrian Explosion of new formats and notations that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.

Awesome app. Do you plan on using it for anything in particular? Or are you just creating it as a passion project. It's totally cool.

Learning about https://treenotation.org/ (linking this for other people, not for you, Breck :P), and I like what I see. My first impression was "Lisp, but with python indenting"

> We no longer need to store our data in error prone CSV, XML, or JSON. Tree Notation gives us a simpler, more powerful encoding for data with lots of new advanced features

This is the one thing I didn't understand! Tree notation seems equivalent to these. Like at a certain level, it's all just data. Now, the major benefit is that you're supposed to think differently about what you're doing when using tree notation. Would love to hear your opinion about this conjecture.

Lots of code examples here: https://jtree.treenotation.org/designer/

And the source for that homepage is here: https://github.com/treenotation/treenotation.org

Always open to PR!

It is what Makepad is working on in an interesting way using Wasm and Rust. They have created a Figma-like DSL and a good code separation with the logic behind it. You can edit UI's of in-production apps, and they are bundling an editor for that. Accessibility is an issue, and the project are looking to offer proper support there. In their video linked on the README they run the conference slides on Makepad with live apps embedded and running at 120 fps.

https://github.com/makepad/makepad

https://news.ycombinator.com/item?id=36567681

> if anyone tells you they need to use WebAssembly to make the UI snappy I'd advise you interrogate that assertion thoroughly.

Get prepared to be blown away by Makepad [0]. I have no affiliation with them, but just watched their most recent conference presentation [1]. The slides were made with Makepad itself and included, embedded, a full-blown IDE, a synthesizer app, a Mandelbrod to zoom in endlessly, and more. All running at 120fps. The presentation is for the most part live-coding with this setup.

What they want to do is bring coders and designers closer together, and while some code is in Rust they developed a DSL for the GUI parts that is close to how Figma works. These GUI's can run anywhere.

And I couldn't help thinking "Why would people have complicated stacks to create Web 2.0 apps for the Google Web, when they have this?", in other words an opportunity to break out of the browser straitjacket.

[0] https://github.com/makepad/makepad

[1] https://www.youtube.com/watch?v=rC4FCS-oMpg

For those who haven’t seen it, Makepad is also an in-browser code editor with an open-source UI toolkit. Looks like this synth is one of the examples of the UI toolkit.

https://makepad.dev/

And I'm obsessed with what happens when you press Alt in their editor. I never knew I wanted this, but boy, do I want it.

I tried this, using https://makepad.dev our GPU accelerated UI and renderstack. And unfortunately it wasn't a great experience. Text popping forward for whatever reason is not really an improvement (i tried indent depth, syntax highlighting reasons, cursor behavior). Maybe 'veeeeery' subtly could do something, but otherwise you dont want it to break visual symmetry as we are used to

Wow, so they did: https://github.com/makepad/makepad/pull/142

It says on the front page Mac and Web only

https://github.com/makepad/makepad#prerequisites

(windows and linux are coming )

We can! It’s a lot of work because you don’t have the whole JS ecosystem to fall back on, but to some that’s a feature not a bug.

My favorite example of this is https://makepad.dev

And a feature highlight of Code Lens. The idea is borrowed from https://github.com/makepad/makepad

When it comes to compile times, the most optimized Rust codebase I know for optimized for this is makepad.dev [1].

It is compiling from scratch on mac m1 in around 7.5s [2] and that's +100k lines of Rust. However there is close to none dependencies, so this +100k is all there is to compile pretty much.

[1] https://makepad.dev/

[2] https://twitter.com/rikarends/status/1467529091284934666