custom .ojs is not standardized, why not use markdown with extensions instead

[uptonking]

• at first, i love your great work.

• but writing .ojs is not so happy.

• the drawbacks of ojs:

  • current ide won't highlight the syntax. writing experience is not happy 🙃️
  • a custom format. put js first. the syntax needs guessing.
  • look at your examples in .ojs. most contents are already in md. so why not put markdown first, instead of js first?

• the benefits of markdown

  • yes, most ide already support syntax highlighting. 😋️
  • markdown extensions are so common that many users are already familiar with.
    • especially the popular mdx.
    • mdx is much easier to both read and write than js.
  • markdown has popular front matter convention for defining meta data like FileAttachment that can provide extra info but won't be rendered

• with the large ecosystem of mdx, we can push this editor even better.

• for example, to solve one problem of observablehq.com, that we cannot hide the cell name.

  • start = new Date("2020-10-01");
    • the start = is often unnecessay.
  • with mdx, u just need to use export const start = new Date("2020-10-01");
    • in mdx, all import and export won't be rendered by default.
    • if u want to use the variable, just use it <div>{myVariable}</div>
  • this is just an example, i haven't considered the implementation details.

• another example, for ui views, may be we can write the popular jsx

// instead of 

viewof pagesSource = Inputs.textarea({
  rows: 6,
  width: 220,
  label: md`<b>Pages"`,
  value: `Donald_Trump
Mike_Pence
Joe_Biden
Kamala_Harris`,
});

// maybe we can write the popular jsx

<Inputs.textarea rows='6' width='220' {...restProps} />

• one more thing, there are so many ui components and other plugins wo can use directly in mdx.

@asg017 do u feel excited 🤗️

• another option is to write a converter to tranfrom mdx ast to ojs, seems doable 🤔️

[asg017]

ya I agree, .ojs right now isn't that great, mostly because it's brand new. There are small things you can do to make it a better experience while developing, like, associating .ojs files with JavaScript in your editor. For example, in VS Code, I have:

"files.associations": {
    "*.ojs": "javascript"
  }

Which associates my .ojs files with VS Code's builtin JavaScript features, like syntax highlighting and autocompletion.

But, .ojs isn't perfectly JavaScript (see Observable’s not JavaScript), so viewof, mutable, and block cells (x = {return 4;}) will erroneously show syntax errors. Autocompletion is based off static analysis on generic JS libraries and not 100% perfect. And prettier/most formatting libraries won't work.

There are other issues on this repo that are tackling some of these problems (mainly #18 for a Dataflow autocomplete features + language server), and I hope to scope out more work for how syntax highlighting, a .ojs prettier plugin, and other ways to make .ojs nicer to work with.

I do like the ideas you bring up here, but there are reasons I want to stick with .ojs. Other people can definitely build things that compile to .ojs (for example, a tool that compiles your jsx example to .ojs, or a custom mdx format that compiles to .ojs). But staying with .ojs makes the Dataflow compiling process very straightforward, any other format would require pre-processing which would add complexity. Also, I want to make it as easy as possible to copy+paste examples on observablehq.com into Dataflow Observable notebooks, so .ojs makes that straightforward.