> 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 languages that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.

Hey, nice! I have a notes file experimenting with a similar tree-style minimalist data notation; it's definitely an area that needs more exploration.

I like what you've done with it, I'll need to take a closer look.

While I was thinking about it, I also decided to take a look into prior art, which took me all the way back to Landin's "The Next 700 Programming Languages" from 1966 which introduced the hypothetical language ISWIM, which was the first to introduce indentation based syntax and inspired the ML and Haskell family of languages (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)

It wasn't exactly what I was looking for, but it's fascinating to see how long we've been thinking about these kinds of issues.

Yes, and surprisingly there are not too many that use any indentation based syntax (about 1 in 50). However, of the ones that do (abc, aldor, boo, buddyscript, cobra, coffeescript, csl, curry, elixir, f-sharp, genie, haml, haskell, inform, iswim, literate-coffeescript, livescript, madcap-vi, madcap, makefile, markdown, miranda, nemerle, net-format, nim, occam, org, promal, python, restructuredtext, sass, scss, spin, stylus, xl-programming-language, yaml) there are some real gems.

Some more interesting read's in this space:

2003 - Egil Möller's I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

1984 - Alan Kay's 3-D spreadsheet - http://worrydream.com/refs/Kay%20-%20Computer%20Software%20-...

1972 - Mark Wells' A Review of Two-Dimensional Programming Languages - http://sci-hub.cc/10.1145/942576.807009

Cool! Thanks for some more reading and inspiration.

Here's what I have in my notes buffer; I hadn't gotten much further than this.

  Ssn: /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/
  People: Table
      first: String
      last: String
      dob: Date
      ssn: SSN

  Csv
      headings: True
      load people.csv
          as: People
      select first last dob
      filter dob.age > 21

Well, I had some discussion, alternate forms of the syntax, links to prior art, etc, but not much else worth sharing.

Will have to add your TreeNotation and Ohayo to that list, as well as these other links you've shared.

Very nice! The nice thing about these kinds of notations is that they last. Simplicity is timeless. I can immediately grok exactly what you are doing here. :)

How is this not just S-expressions with indentation instead of parentheses? What makes it different from say Sweet Expressions?

Common question. You cannot do column and matrix operations natively against S-Expressions (You need to parse the whole thing). This turns out to be very important and useful. S-Expressions need to be transversed in 1-D linear order.

When you two-dimensionalize S-Expressions and remove the parens, you get Tree Notation.

Wow that tree notation looks super interesting!

Bookmarked for a later in-depth read but my interest is piqued!

Do you have a more formal documentation for treenotation? The idea is intriguing but I couldn’t find the actual rules specified on the site.

The rules for the basic notation are really simple. It's just basically a grid (visualize a spreadsheet), where each line is a row and each word is a cell. Indent a line to indicate a child node/row.

An updated spec: https://faq.treenotation.org/spec/

Thanks - that’s what I was looking for! Looks like a potential improvement on s-expressions to me in terms of a readable syntactic kernel.

For what it’s worth, I have been interested in the concept of 2d languages for quite some time, and I’m not sure what your definition is.

To me this seems to have a 1d topology - I.e. it’s still left to right top to bottom, and there are no loops or semantics that require reading in other directions.

I contrast this with something like a circuit diagram or labview program.

I may be missing something though.

Once the trail has been blazed by pioneers, expect a gold rush.

What would a good API look like, I wonder?

This is a dark pattern. Webassembly is binaries with no source. There is nothing to deny that. It closes the web and it isn't free software. It is moving back to proprietary. For reasons that all the googlers or other webasm devs here can't admit.

The dom isn't trash. Its good enough. We just need to stop making it do things it wasn't supposed to. That's why things like electron make sense a little bit. Not perfect but sensible.

People are trying to make DOM be a WYSWIG text editor. You're point is dead on.

The response is to write an opaque, vendor-specific "DOM". Which is the complete opposite of what HTML was supposed to be. But the browser is now a platform and not a browser, so the metaphors are horribly mixed to the point where I'm not even sure what a DOM is supposed to be anymore.

The DOM was always a WYSIWYG editor – albeit, for HTML, not text. Though, back in the day, HTML was a subset of text with image and table support; none of this fancy `line-height: 1.5em;`…

I wish the web had evolved in a more documenty way.

Hmmm... maybe I should have chosen a different acronym.

What you expected to see isn't alwasy what you got.

WYETSIAWYG

Rendering across browsers and operating systems was a trainwreck until maybe 5 years ago (over a decade of polyfill is finally gone). And even with an ecosystem like ElectronJS + Bootstrap, Win10 MacOS and Linux all look slightly different.

So yes and no to "DOM was always...", but more "No."

> We just need to stop making it do things it wasn't supposed to

This is a thread about Google Docs. Your suggestion to the Docs team is to ... stop? Just shut down their product?

Just send LibreOffice files as attachments via your personal email server, what’s the problem?

/s

Well, to be fair Libre Office online exists[0]. However, I believe EtherCalc[1] is faster.

[0] https://www.libreoffice.org/download/libreoffice-online/

[1] https://ethercalc.net/

I read this as sometimes you need to use an exit hatch like Canvas instead of a bunch of hacks to make a WYSIWYG editor strictly with the DOM. Google seemed to come to the same realization and that is why they are using Canvas

Oh no. They're google. They make a godforsaken browser. They can pay people to do nothing more than think about code. By all means. They can launch a satellite with css if they want.

But the rest of us plebs...

Btw for NASA css is shorthand for Control Stick Steering, which is something you did at later stages of landing with a space shuttle.

Yes? Most of the web really ought to be shut down. It's just providing negative utility to society.

Alternatively: return to monke.

I'd agree. I think the DOM is fantastic, *unless* you are doing advanced document manipulation, in which case it is trash (for that use case only). This is what I'm assuming the author meant.

I spent many years working on that sort of thing, a decade ago.

The problem is that the escape hatch from document to application is completely broken. The DOM is fine for documents, but it's completely awful for applications. Admittedly, some things on the web that should be documents insist on being applications instead, but many things on the web aren't documents.

For these things, using the DOM is painful. When the pain becomes great enough, the biggest available escape hatch is pure native 2D rendering (canvas), which is a nightmare for accessibility and affordance to end-users. It would be awesome to have something else to escape to.

Isn't Electron rendering to an embedded Chromium and therefore the DOM as well?

Yes

That's the entire point. DOM is meant for structured web pages, not web apps. If you want to build complex web apps it is better to use your own renderer..which is exactly what Google is doing with Docs.

We should just port wine to webassembly and be done with it