bhl

Asana uses ProseMirror and Slab uses QuillJS, and neither of them lag by default if you look at the standalone libraries.. so :shrug:

If you have free time, I'd pop open Chrome Dev Tools, run a performance monitor on both and try to diff out what each of those products do that cause the additional input lag (if there's no code obfuscation).

I'm trying to find the source data Apple uses for text replacements / suggestions.

It's more than just the CLDR keywords (https://unicode.org/emoji/charts/emoji-list.html), since text replacement or autocomplete shows up for words not on that list.

Has anyone reversed-engineered the Apple emoji dictionary that maps some keywords to emojis? Last time I checked, they only shipped binaries on the newest MacOS. Would love to use that mapping to elevate search on my custom emoji picker.

Perhaps you could come up with a list of commonly-used functions and write optimized SQL functions for them, such that users start off learning with that API and gradually learn SQL when they're more comfortable.

> there is no official repository of Plug-ins instead everyone is rebuilding everything

To be fair, both Slate and ProseMirror call themselves frameworks for building rich text editors as opposed to drag-and-drop editors themselves.

The best way to build an editor yourself then would be to look at other existing editors using the same framework, and try to understand the architecture and usage.

What features of Slate put it closest to Notion's editor compared to other frameworks besides the obvious one that Slate's view layer is built on top of React?

Is it somehow that Slate is more suitable handling asynchronous data (e.g. server generated uuids for each block, recursively fetching content for each block and its children)?

There’s a few papers from http://sustain.stanford.edu/projects that has to do with satellite imagery, deep learning, and measuring poverty.

That link does go over an optimized tree-diffing algorithm for ASTs, but the question I'm wondering is how to extend incremental parsing into incremental diffing, as opposed to full parse into full diff.

`tree-sitter` has been post to the website a bunch of times so I remembered from those submissions: https://hn.algolia.com/?query=tree-sitter

Also these resources:

https://github.blog/2018-10-31-atoms-new-parsing-system/

https://www.youtube.com/watch?v=a1rC79DHpmY

Anyone know how to compute the diff between two ASTs if the edits _are_ known, either in general or with tree-sitter.

The method used by diffsitter is to compute the path with minimal editing distance: https://github.com/afnanenayet/diffsitter/blob/main/src/ast.....

In the case where the edits are known (because you're re-creating the AST per keystroke), you can save parsing time by passing in the old tree and a set of edits: https://tree-sitter.github.io/tree-sitter/using-parsers#edit....

Intuitively, I feel like there should be a way to reduce diffing time as well to avoid O(mn) run and space time that comes from the dynamic programming solution to compute the minimal edit.

Github is also behind the library that diffsitter builds upon: https://github.com/tree-sitter/tree-sitter.

I don't think jupyter by default comes with real time collaborative editing.

Just curious, have you tried vite with react? It uses esbuild, which might result in a heavier dependency folder, but I also wonder if getting rid of webpack removes a lot of the CRA dependencies.

At face value, the idea feels reminiscent of earlier collaborative text editors like etherpad, hackpad, or usecanvas. I think the hard part would be resisting the temptation of folding your markdown (hiding # or *) or moving to WYSIWYG.

For starters, you can take inspiration from apps like bear notes, ia writer, ulysses, typora, or even apple notes (which has collaborative editing nowadays).

Skiff uses https://github.com/chanzuckerberg/czi-prosemirror last time I checked, which just uses the DOM.

When I was taught stable matching, there was a homework problem on showing that the algorithm is “proposer-optimal” and “proposee-pessimal”, meaning that a proposer always does the best they can do relative to other proposers’ preferences while proposees do the worst.

The crucial part here is how big is the gap between a proposee’s worst and best match: if the gap is null for all proposees, there isn’t any strategic incentive for one to lie about their preferences. However, that obviously is a very hard requirement.

How far are we away from having _collaborative_ Jupyter in the browser? Would love a Google Docs experience of sharing a no-sign up required link to help remotely teach basic python.

That sounds a great side project, since some developers might prefer a static svg dynamically created via url like boringavatar.app/[username here].

There's some prior work on this: e.g. https://github.com/lfades/static-tweet and https://github.com/vercel/og-image.

I agree with React being a good bet, but looking at the source code at the link, porting the library over to vanilla javascript or vue seems rather simple given it's mostly using JSX and not using an in-depth React feature like hooks.

What’s the reasoning why Notion doesn’t have partial text selection across blocks? I originally thought it was an issue with each block being it’s separate contenteditable, but if you wrap all of the contenteditable blocks in another contenteditable div, partial text selection works (at least on Chrome).

Given for a text editor, find-and-replace is a feature anyways that's not natively supported by contenteditable.., you will need to build out a custom app search feature anyways. But yeah, for preview only mode, sad to see native features not work on a static document.

With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?

For the majority of use cases, do you think contenteditable + view layer which precisely updates the HTML is still viable? More specifically, what do you think about open-source libraries like ProseMirror (https://prosemirror.net/) or Slate.js (https://github.com/ianstormtaylor/slate) which do that (ProseMirror uses its own view library on vanilla javascript, Slate uses React)?

I understand if you have really long documents or spreadsheets (I imagine latter is more frequent), you could maybe solve performance rendering problems with virtualization, which canvas gives more flexibility to?

Makes me wonder if you could split an ipynb into an in and out file, then add /*.out to .gitignore.

The default way to persist a ProseMirror doc is JSON. There is a way to serialize that to Markdown via the prosemirror-markdown package, but not every node can be represented as plain text. You can also use html without a non core package since each node has to define a toDOM and parseDOM method.

That engineering blog post is a bit ambiguous to whether or not SQLite is also used in the browser web-app, which I'm presume is being used for most people who clicked on the link.

So that could mean two things:

- SQLite is being used in-memory, but things are still being flushed to IndexedDB for persistence? shouldn't help with faster page navigation here

- SQLite is not being used, so it can't explain the performance increase

I think the answer is more in the second link (changelog):

> - *Your workspace is now more reliable after Apr 16, 2021's scheduled maintenance — we upgraded from a single database instance to a sharded deployment, which means Notion is now capable of serving 3x as much traffic as before*

Maybe it's just an oversight then when inline and block math was rolled out. KaTeX has a `renderToString` function that can be used to server-side render the LaTeX.

On an other hand, Notion doesn't seem built to serve read-only webpages like a static blog or Medium.com: the expectation is that you'll use the editor, so assumption is javascript is enabled and the editor itself can be used to render a read-only view from JSON or however they're keeping document state.

Opening dev tools on the website, it looks like they're just using Webpack (like React CRA?); not sure if they're changing the javascript bundle per page like with Next.js. It would make sense to not have server-side rendering if you're building both browser and desktop apps, since that would mean avoiding a separate framework only for the browser.

Another clue is that people who try to use Notion as a CMS for their blogs had to build out a React library to emulate the feel of Notion itself: https://github.com/splitbee/react-notion https://github.com/NotionX/react-notion-x.

There's two sides to every story. Reducing the amount of third-party tracking cookies on the web, and implementing a novel application of federated learning are definitely things some engineers would do, money aside, because they're technically challenging.

Also link to that source code mentioned: https://source.chromium.org/chromium/chromium/src/+/master:c...

[1] https://actualbudget.com/blog/porting-local-app-web

[2] https://news.ycombinator.com/item?id=23508923

With respect to tech companies, the compensation ratio is a good starter to get people to think about wealth inequality but as tool or metric for public policy, it is useless.

Here's my intuition on that:

- it doesn't answer how much of the wealth was created (endogenous) or taken (zero sum): tech companies can simultaneously induce new demand and preferences while replacing older companies

- it doesn't answer whether the average worker or society as a whole is better or worse with a lower or higher compensation ratio, because by averaging you lose nuance; for example, are more or less people employed by tech companies now then by the companies that were replaced? are the worker salaries themselves higher or lower compared previous worker salaries?

For me, higher compensation ratios in _tech_ companies is good for people in tech: tech requires less labor for inch of market cap, while that labor is compensated higher. Whether or not that's an overall good for society though, idk.