This is still an early version. Its purpose is to introduce what CellScript is, show what the language looks like, and explain how it maps to CKB’s Cell model.
Feedback would be very welcome, especially from community members with strong experience in product, interaction design, frontend development, or developer tooling.
CellScript is not production-ready yet. Once it reaches that stage, I plan to write and maintain a CellScript cookbook on the site, covering practical contract patterns, examples, and developer workflows. I also plan to develop and maintain the CellScript registry there.
For now, I have personally covered a three-year domain lease and cloud hosting. I see this as part of my contribution to the CKB community, and as a public-good effort rather than a private product.
In the longer term, if CellScript gains real adoption, the website may become the home for a shared cookbook and package registry. Since those resources may require collaborative and long-term maintenance, it may eventually be more appropriate for them to be hosted or stewarded by a suitable community organisation or entity, rather than remaining entirely under my personal ownership.
Any feedback, suggestions, or criticism would be greatly appreciated.
Following up on the website release notes thread, I have revamped the site and been turning the Playground from a single text box into a small online IDE for learning and inspecting .cell contracts.
Inspect compiler output in a more natural order: Actions, Types, then Metadata.
Use a more editor-like experience: indentation, multi-line indent/outdent, bracket pairing, and cleaner examples menu behavior.
A small note on the three output views:
Actions describe what the contract says will happen to Cells: which Cells are consumed, created, replaced, burned, or relocked. This is the transaction-shape view.
Types show the structured data model the compiler understands: resources, fields, fixed types, vecs, and other typed pieces that make the contract reviewable.
Metadata is the build evidence. It is the JSON-like record that tools and reviewers can inspect after compilation: actions, types, hashes, effects, target information, and warnings.
The goal is that someone can open the Playground, pick an example, edit it, immediately see what broke, and then inspect the compiler’s view of the contract without setting up a local project first.
This is also a step toward a more complete builder flow. I may build the next layer as an interactive transaction builder, so users can go from CellScript source → metadata/action model → actual CKB transaction construction. Some of that direction is already visible in the AMM builder integration work being explored by @WuodOdhis here:
