marijn

Apropos, the author is currently looking for work: http://tef.computer/

nb: This project has been going for 13 years.

I've started communicating a clear expectation (https://prosemirror.net/#about) that profitable users help support my software. Of course, most still won't, but some do, and with a big enough user base those contributions, plus some consulting around the projects, provides a decent income.

Building a new JIT for a dynamic language, if it is supposed to be competitive with JS compilers, is a project several orders of magnitude bigger than building a runtime like this.

TypeScript's design is very much that of a typing layer over a dynamic language. It's unsoundness and various loopholes to escape typing mean it's not much of a help for typed compilation.

That's by a different author with no connection to this book, though, so calling it equivalent is misleading.

This aligns with my experience with https://eloquentjavascript.net, except that I put it online before publishing on paper, and my hunch is that it wouldn't have reached anywhere near the level of fame (and thus sales) it did if it hadn't been available online.

Not all invariants relate to allocation. Rust protects you from a whole class of shared-mutable-state issues that JavaScript and Lisp are zero help with.

Rust is also C, if the fact that you can't encode all possible invariants into the type system makes a language C. But this is a spectrum, not a dichotomy, and TypeScript falls somewhere way beyond C, but below Rust, in what you can statically encode. And Idris lies beyond Rust.

The assumption that those who care about treating others decently can not at the same time be good technologists speaks volumes.

He wasn't blacklisted for committing thought crime. The dumb Epstein email triggered a reevaluation of his consistent creepy and inappropriate behavior against current community standards, which resulted in a large part of the community deciding they didn't want anything to do with him anymore. Freedom of speech does not mean freedom from social consequences.

It is, if you include a JS interpreter in your wasm bundle.

But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.

> If there are no routers or Volk phones nearby to hop to, you'll either not have service, have to use Wifi, or fallback to LTE if you have a SIM card installed and it has active service.

That does make the "Global Coverage: Our network is everywhere our users are" claim a bit dodgy, no? Sure, you'll have coverage in the middle of the desert—if there happens to be a chain of Volk phones from there to the nearest point with actual regular coverage... which is highly unlikely.

If you mean indentation, shift-tab should auto-indent the selection

(https://prosemirror.net does)

Note that though this lists ProseMirror as one of the evaluated editors, followed by a bullet list of issues, only one of those issues can reasonably be considered to apply to ProseMirror—and that's "Re-inventing the view layer", i.e. "doesn't use React", which can arguably be an advantage.

While it sounds very reasonable, friendly, and non-authoritarian, a big problem with an approach like this, without real teeth or rigidity, is that it is very easy to harass people out of a community while staying within its constraints, and provides very little recourse for those being harassed (who often are not in a position of power) to put on pressure for getting something done about it.

The approach taken largely ignores the discussion that's been going on about this topic, and sounds pretty naive, if not willfully passive.

Nice! I too, would love to read more on the OT/CRDT trade-off.

Companion reading (the approach taken in ProseMirror, which was implemented in significantly less person-years): http://marijnhaverbeke.nl/blog/collaborative-editing.html

Awesome to see the stupid trick to abbreviate object properties that I came up with in 2010 [1] is still a living part of the mini JS demo scene.

[1]: http://marijnhaverbeke.nl/js1k/

As long as the types on both sides match, the behavior of == is perfectly reasonable, and in typical uses, this will be the case.

Makes sense. But I guess precise paths (ending with .js) are recognized and cause no actual file system searching?

Another question—does this also resolve from directory paths to index.js, add missing extensions, and so on, or does it only map package names to directories? As in, does this get rid of all 'superfluous' file system access during resolution?

This seems to be solving a problem quite similar to the one of getting browsers to resolve non-relative imports (without file system access, they also need a precise map from module names to paths). Unfortunately, I can't remember who or what was working on that and I'm not sure how much progress it is making, but it'd be wonderful if this could somehow be framed in a way where it also helps that issue along. Are you taking this into consideration in the design?

> Your options are to increase the number of bits used, which puts off the overflow, or you could work with infinite precision arithmetic, which would slowly use up the available memory and finally bring the system down.

Yeah, no. Doubling the amount of bits to 64 while keeping the same precision gets you about 3 billion years worth of time, which is probably enough. And I'm going to leave calculating how much time it'd take to fill up any reasonable amount of memory with a single arbitrary-precision integer as an exercise to the reader.

We're not really using shims, just targeting the lowest-common-denominator contentEditable behavior that we can count on, and implementing anything else ourselves.

Indeed, I'm aware of those and they are great.

It should not be hard to do this as a plugin, but the core maintainers are unlikely to work on it.

> Will CodeMirror6 implement vim mode in a similar fashion?

This hasn't been decided yet—I'm aware how much people appreciate the vim bindings, but they are _huge_ (as big as the current core) and written by someone else. I'll probably take a stab at porting them when the new API is stable, and give up when it turns out to be too messy. On the bright side, they have a lot of tests, which helps with making sure I don't break them. But they _are_ still looking for a new maintainer, and even if I do port them, I'm not taking over maintenance.

There's a lot of architectural influence on the new CodeMirror from our ProseMirror work, but the actual systems are different enough that code sharing didn't really work (or, at least, would add enough levels of extra indirection and complexity to the reused code that it's not worth it—code size is a significant cost in JS components)

It provides significant advantages when it comes to noticing bugs and including types (also for docs) in the code from the start. I feel that TypeScript is widely enough known at this point (and close enough to JavaScript to figure it out quickly) to not be too much of a barrier.

I did study Monaco, but we're using a very different approach (Monaco resembles the current CodeMirror more), because what they do in almost impossible to make work on mobile. When it comes to accessibility, they do a great job, and I'm planning to take more inspiration from their code as I work on things like autocompletion