Mesh: December 2017 Update

Mesh is an attempt to achieve a better "power to UI" trade-off in programming.

The last few months have seen design changes to improve that trade-off further, beyond the version posted to Reddit and Hacker News. Try the updated version here.

Major changes since July release

The two major changes move the Mesh UI closer to how people would normally use a spreadsheet, while preserving the readability and importability of the JS code output.

First, Mesh now writes code as an object literal format. By using getters for anything that's not a literal:

Second, to make it easier to enter data, Mesh transforms non-formula text. For example, you don't need to put quotes around text to enter a string — Mesh will guess your intention and do that for you. Effectively, prepending a formula with = means the rest of the commit is interpreted as 'raw' JS.

I am trying to keep the codebase within 2000 lines, and ideally within 1500. So far so good — it's around 1900 and there is decent low hanging fruit for further reductions.

Next steps

The downside of using object literals as the format for JS code output is that references are unnecessarily verbose:

The messiest part is variable refs being prefaced with 'MODULE' or 'this' (see https://t.co/PxTl3UwsN0) - hoping this can be handled via UI, maybe you click on the cell instead of typing the ref in

— Mesh IDE (@mesh_ide) 18 December 2017

I would also like to allow users to enter data without needing to name it first. That may require anonymous IDs for code that can optionally be upgraded to names chosen by the user. I don't want to require the user to impose structure early in the problem-solving process if it can be avoided: a spreadsheet is a good scratch-pad for quick, unstructured calcs, and maybe Mesh can reduce the barriers to entry for coding by supporting a similar workflow.

Both of the above could be handled with UI (eg click on the data you want to reference when entering a formula, and Mesh will insert the right ID). However, I am not certain this is a good idea:

  1. users may end up with messy spreadsheets, which are harder to impose structure on later
  2. it may also be harder for 'regular' JS programmers to determine the file's API if read as plain text.

I am also not sure about the best way to impose more complicated data structures, such as tables. Initial thinking was to specify data structures with HTML tags, but thinking it through more, I don't want to compromise the efficiency or familiarity of a grid interface.

My current thinking is that Mesh will require more complicated data structures to be explicitly decared via buttons or keyboard shortcuts (like how Excel requires listobjects or pivot tables to be explicitly declared). That would potentially work well with a currently pie-in-the-sky idea to allow cells to be grouped together visually and be 'promoted' to a higher-level data structure (such as an array or object), and vice versa (this is also a solution to #1 of the two risks above).

There are also some 'elbow grease' changes required: