> Text files are inherently GPU-hostile, and that makes them a weird choice for a graphical markup language.

The point of a standard is to be device agnostic. Tying it to present-day technical implementations would limit its adaptability to future tools, as well as creative misuse of the technology.

Then why tie the format to present-day technical tools like text editors? Why not invest in a format that makes sense and the tools to understand and work with it?

Also, GPUs and their architecture aren't a fad, they have been the same for the last 30 years. If you want your format to be truly device agnostic, text is a bad format because it precludes many types of devices (GPUs and hardware accelerators) from being able to use it.

Text had been then same for the past 5000 years or so, predating text editors by an enormous margin.

As far as i know HTML and JS are also text formats which must be interpreted. So i do not see any advantage between parsing a text format or HTML or JS.

How are text files gpu hostile?

Text files are very hard to efficiently parse in parallel because there are so many variable-length and conditionally present fields. That necessarily leads to branches in your code which GPUs are not designed for.

It depends on the format of the text, the parser for that format, the language of the parser, and many other factors. Such a broad affirmative statement that text files are inefficient is tenuous at best.

We need some technology that turns text files into binary. To the startupmobile!

Hmm sounds like a compiler

Then pad fields and require them, even if the value is Null/None/Nil, and the field names too.

  USERNAME:dotancohen\0\0\0\0\0\0
  FOOBAR\0\0:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

This might look ugly if you open it in Notepad, but so do XML and Org mode files. However an Emacs/VIM/VsCode plugin could make this seamless for the user.

They might not look as pleasant as Markdown, but Org mode files still look good in a plain text editor like Notepad.