Welcome to

BABLR is a parser framework roughly comparable to Tree-sitter, but built from the ground up for the web. It is meant to be "everything but the GUI" of an IDE. It can provide version control, syntax awareness, and the integration APIs that will allow products built on the BABLR core to support our ecosystem of compatible libraries and extensions.

Its purpose is to faciliate experimentation with new UX paradigms, particularly by faciliating the creation of new generation of "semantic-syntactic" code editors. Such an editor is syntactic in that it presents code as 2D text, but can also be semantic by not (ever) allowing invalid syntax like unclosed quotes or mismatched braces. Instead such an editor should be centered around compostion: it should make logically-coherent pieces of code feel like they can be taken apart and snapped together with the delightful ease usually associated with Lego bricks.

Existing projects which BABLR competes with generally fit into one of a few categories:

• Tools for writing Javascript, like ESLint, Prettier, or Babel
• Toolchains for writing Javascript, like Biome (in Rust), VoidZero (in Rust), or Typescript (moving to Go)
• Toolchains for working with code in any language, like ANTLR, TreeSitter, or SrcML

BABLR is the first full toolchain written in Javascript for working with code in any language!

• We needed to own a full toolchain to be able to experiement with simplicity-focused full-stack adaptations like gap parsing.
• We wanted our toolchain to be multilingual so that once we built trust in our it we could take it with us to projects written in any programming language and give it to people who speak any human language.
• We wanted the toolchain to be written in Javascript so that it would be an asset to anyone with a web browser, and could welcome to its community of collaborators and maintainers anyone who knows Javascript

BABLR code is open source under the MIT License. In addition the project is "open" in the sense that its complete development history is recorded in a public forum (our Discord) where community members are welcome to come and share their experiences and insights for how to improve the product.

Because we need to make money the Silphium Labs team that built BABLR will also start to build closed-source products, yet we believe that BABLR will always be free and open no matter what because we've designed it that way. Insead of centralizing the cost of maintaining an ecosystem on ourselves, we've done everything to ensure that the ownership costs of this system can be distributed between a large number of individuals who may only trust each other provisionally. We've intentially left ourselves with very little "proprietary" leverage by building the kind of products that are complete not when there is nothing more to add, but when there is nothing left to take away.

The answer is conditional, but yes, BABLR is stable enough to use in production.

How our project reaches production stability is a process that often surprises people. We don't write a lot of tests for example, and we often don't do much testing before we ship releases. Instead we test exhaustively after we ship releases, which is the only way we know of knowing for sure that the product we shipped does what we think it does. This tends to separate our releases into two categories: bleeding edge feature releases, and follow-on stability releases. If you're going to deploy a release to production, make sure it's one of the stability releases!

We also don't (usually) practice TDD. If you look at the number of tests we have, it likely won't seem like it's anywhere near enough to keep a project of this size stable! The secret sauce here is that our key invariants aren't written in our test files, they're baked into the core of the implementation. Every time you use the code, you're essentially testing it. To gain confidence in our core, we simply try to use it to do a lot of real work.

Garbage in, garbage out. Keep It Simple, Stupid. Etc.

We don't want to support error recovery in parsers because it's not a game you can win: if you have a scenario where the product breaks because you no longer know what it was the user meant to do, you can't fix that by guessing. The only solution that will fix that problem and keep it fixed is to give the user the ability to express their intended meaning.

Our goal is less to support existing code editors than to start a metamorphasis towards intent-driven IDE design that will spread itself everywhere.

The answer to that depends on what you want to do with it and whether we already have a parser for your language. If we don't have a parser for the language you want to use BABLR with, come talk to us and we may be able to help you get one built quickly. If we do, we have a variety of tutorials that can help walk you through first-time usage.

We would love if you wanted to help us reach our goals! We're always looking for both monetary donations and code contributions. If you want to give money we are able to accept such donations through our OpenCollective. If you want to help code, right now we badly need people to try using BABLR to write parsers for more real languges. If you want to show off your mad skillz while putting your knowledge of an existing language like Python, Java, or Ruby, we'd love to see what you can do and are happy to provide any help and support we can. Our writing a parser tutorial is the place to get started.