Comment by fkyoureadthedoc

It's apparently this but I can't really say that I get it: https://bablr.org

He seems to be saying he spent $350k making this. I guess it's some tooling for writing parsers.

He has this to say about Zed:

> Zed: Founded by Atom’s dev team, Zed was the rewrite that Atom always wanted to be able to do but couldn’t when Microsoft bought Github and made the executive decision to kill a product it might otherwise have had to compete with. Unfortunately Zed decided to do that rewrite in Rust. This has slowed their iteration speed, caused much of their dev effort to go to cross-platform support instead of innovation, cut them off from being able to offer their experience on the web, severely limited their hackability, and generally made theirs a niche tool for enthusiasts. What’s worse, their reliance on LSP — a product which believes that the presentation layer should be the primary abstraction layer — means their product is forever doomed to look like a VSCode knock-off. [1]

1. https://docs.bablr.org/architecture/prior-art/#ides

mtndew4brkfst 5 days ago

IMO in the 12 months or so I've been aware of the BABLR work and observed the author's comment contributions, they've never really substantiated why BABLR would be preferable to tree-sitter, or how a JS-based implementation of parser tech can fulfill any of the same niches. Most consumers of tree-sitter leverage it via FFI or native code, not an embedded or external JS runtime.

It's not clear to me how you could substantially replace the capabilities/benefits of what LSP provides with BABLR either.

Reply View 1 reply

conartist6 5 days ago

We have some meaningful advantages that help us gain a practical edge on Tree-sitter:
- Our core and grammars are relatively tiny and can easily be loaded into any web page as a syntax highlighter, except actually a bit more: more like being able to embed ASTExplorer directly into your docs page or blog post to help people understand code examples.
- We support runtime extensibility of languages, e.g. TS can extend from JS at runtime. Tree-sitter only supports static linking, so every shipped language extended from their JS grammar contains a complete copy of the JS grammar.
- Our grammars are much easier to debug. They're written as plain scripts, and they can be run and debugged in exactly the form they're written in.
- We can parse inputs with embedding gaps. An example of such an input would be the content of a template tag before interpolations have been applied. Parsing after interpolation opens the door to injection attacks, but parsing before interpolation allow safe composition of code fragments using template tags.
- We emit streaming parse results on the fly, and can parse infinitely long data streams with ease or syntax highlight. within large single-line files without freezing up
- Tree-sitter is half an IDE's state solution: "just add text buffer". Our solution is the whole thing. One stop shop. IDE in a box.
- CSTML lets us do round trip serialization of any tree and also gives our trees stable hashes. Tree-sitter could trivially represent its parse results as CSTML if it cared to, giving it competitive compatibility with BABLR. A rising tide lifts all boats.
- While they're setting out to make version control for the first time now, we're already basically as powerful as git thanks to the combination of hashed trees, immutable data, and btree amortization within nodes for maximum structural reuse of data.
- Did I mention you don't have to deal with this? https://github.com/tree-sitter/tree-sitter-typescript/blob/m...
- We can probably literally just run the Javascript source code for Tree-sitter grammars on our runtime. The only problem is the C lexers, but C lexers are one of the great annoyances of tree-sitter anyway since any context in the grammar requires you to hand-write the lexer

Reply View | 0 replies

eikenberry 5 days ago

I don't think they are doomed to be a VSCode knock-off due to their technical decisions. I think they decided to be a VSCode knock-off by design. I mean they follow the same project oriented GUI design that VSCode and Sublime helped make popular. There is nothing inherent to their tech that required that.

Reply View 0 replies

conartist6 5 days ago

Haha yes I wrote that, thank you for sharing.

We're approaching the problem by drawing from browser design. We want to see an editor with a DOM API for code documents. BABLR is a parser framework meant as a direct answer to Tree-sitter.

Reply View 3 replies

WD-42 5 days ago

Myself and most people I know that switch to Zed (many from Sublime) did it because we DON'T want a DOM in our text editor. Webtech makes for crappy text editors.

Reply View | 2 replies
- conartist6 5 days ago
  
  Sorry, I didn't make that very clear. I'm not talking about the HTML DOM, which exists as an API to control the 2D pixel rendering layer.
  A standardized DOM for code would provide a universal way of changing code documents using scripts and would allow many different code-oriented tools to interoperate naturally where they never could before.
  
  Reply View | 1 reply
  
  dbalatero 5 days ago
  
  I think I know what you're saying, and it sounds like an interesting thing to attempt. Some sort of universal API that feels really good to make structural edits to code documents would be excellent.
  
  Reply View | 0 replies