blockprotocol
libasciidoc
Our great sponsors
blockprotocol | libasciidoc | |
---|---|---|
3 | 3 | |
1,330 | 192 | |
1.3% | 2.1% | |
8.2 | 4.3 | |
13 days ago | 8 days ago | |
TypeScript | Go | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
blockprotocol
-
Learning HTML was too hard so I made a compiler instead
Relevant to this conversation, I saw Joel Spolsky giving a talk about his new big project/stab at addressing this problem The Block Protocol.
-
The Block Protocol
1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API).
2) What's going on with the type signatures here?
The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.
The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.
libasciidoc
-
Learning HTML was too hard so I made a compiler instead
AsciiDoc is the language, AsciiDoctor is an implementation in Ruby. There are other implementations, such as libasciidoc for Go: https://github.com/bytesparadise/libasciidoc.
-
Compare AsciiDoc and Markdown
If you mean libasciidoc for Go, it does not support all the AsciiDoc features [1]. The JS parser is transpiled [2] from the Ruby implementation (which is not a bad thing, it's something most languages can't have).
My favourites are Rust and Haskell. Neither of them had a parcer until recently (even though the original implementation has been around for a few years now). Both are at early development stages at the moment.
[1]: https://github.com/bytesparadise/libasciidoc/blob/master/LIM...
- Couple of other implementations in GO
What are some alternatives?
solid - Solid - Re-decentralizing the web (project directory)
markup - Determines which markup library to use to render a content file (e.g. README) on GitHub
PyLD - JSON-LD processor written in Python
asciidoctor-go - [mirror] Native Go module for parsing and converting asciidoc markup language.
custom-elements-manifest - A file format for describing custom elements
marktext - 📝A simple and elegant markdown editor, available for Linux, macOS and Windows.
icestudio - :snowflake: Visual editor for open FPGA boards
commonmark-spec - CommonMark spec, with reference implementations in C and JavaScript
awesome-jsonschema - A curated list of awesome JSON Schema resources, tutorials, tools, and more.
OctoBase - 🐙 OctoBase is the open-source database behind AFFiNE, local-first, yet collaborative. A light-weight, scalable, data engine written in Rust.