Comment by conartist6
4 days ago
That brings them to 120x the amount of money I've invested in the same problem, and still they're only just announcing that they're intending to start trying to do something that I've already done better
4 days ago
That brings them to 120x the amount of money I've invested in the same problem, and still they're only just announcing that they're intending to start trying to do something that I've already done better
Can we see?
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
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.
1 reply →
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.
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.
3 replies →