"If the vision is for every human to own their data" you don't design a text data format that is of interest to the geeky 1% of humans who do care about encoding,
Not so my friend. I mean of course all data formats can be argued to be of interest only to 1% of humans, so its not a criticism of FTD. Only a few decades back entire internet was of interest only to 1% of humans. More and more humans are living lives in digital world, moving their data and records online. At some point they will need data interoperability etc, a proper data format has to emerge.
I contend that JSON is not that data format. I content XML was quite good, schema, data and templating put together, but syntax was horrible.
FTD is an attempt to be that format. Unlike XML it has cleaner syntax, and does more than XML (direct serde serialisation for example, actual ADT support etc).
Try it, check this: FTD Playground, it has data schema definition, and data definition.
My question to you my friend is: is this not better than what we have, XML/JSON/YML?
I am looking for some actual technical feedback. How do you compare FTD with the alternatives available to you today? How can you help me make FTD better? Its really early days, I am sure there is lot of scope of improvement.
HTML/CSS/JS are over-complicated. Look at the Rust book project. It could have been written in HTML, but its in markdown. Markdown is better than HTML. Its a alternative to someone who wants to write a prose on web.
FTD is like markdown, but unlike markdown it gives you much more, much more styling and full page layout. And it gives you event handling. And it gives you data definition and data driven UI.
You are seriously dismayed that say this: FTD Playground exists?
Take the slideshow above, and write it in Svelte, and come back and tell me you find Svelte actually better experience.
Also I am not competing with full blow application development framework. Its Markdown on steroids, not what you will write you next GMail with.
FTD compiles to HTML/CSS/JS so browser need not support FTD natively. Though the plan is to create a FTD Browser as well, which will not require the bloated CSS/JS, and you can say use it on embedded devices and so forth.
If you ever considered building embedded UI, you may soon(hopefully) find FTD a really nice alternative. And hopefully for terminal applications, at least the ones that are largely to display information to people, not full blown ViM clone (tho FTD could be used as the rendering layer of such clone one day).
Sounds like you need to rewrite your documentation to make this clear. It reads like you're out to replace HTML/CSS/JavaScript, not markdown. If your goal is to replace markdown, I'd suggest emphasizing how FTD can coexist with HTML/CSS/JavaScript, e.g., by generating snippets of HTML. Otherwise potential adopters will be concerned that the need to have pop-up menus might require them to rewrite all their content.
Thanks for the detailed feedback on the pitch, it was written in 30 mins with no editing etc.
Not at all. I posted it here because ftd is a rust crate: say you want to make a landing page, eg FTD Playground, you can today write in HTML/CSS/JS or you I am offering you, a IMHO better alternative: write it in FTD. You care create reusable data driven components with lot of ease, especially for the one of landing pages, marketing pages, support pages, even blog etc.
If you have any feedback on ftd crate, ftd format, the documentation, features etc please let me know.
PS: How is mentioning Realm taking credit away from me? I have written the initial code, probably 90% is still mine, I have built it over 3-4 years. And it is open source, you can use it today, there is some documentation and a quick-start template. If I can be honest with you I found this remark in poor taste, and my first impulse was to presume you a troll and ignore your reply. But you did give a lot of feedback so I am assuming good intentions here. The writing, README etc are indeed quite not there yet. So thanks, these things matter too and I would improve them (when I get time, not my priority tho: I am offering something that I believe can help you, take it as that.).
This is not really the place to debate the merits of HTML versus other markup languages. Folks, when people post their Rust projects here, it would be great if we could keep commentary focused on aspects of particular interest to Rust developers.