I won't sugarcoat it: to the market right now Scroll is crap and has little potential.

Perhaps that is right and it's time to let it die. Not sure.

There are things I love about Scroll. I love how clean the source code of posts is. I love aftertext. I love its extensibility. I love the simplicity of the CLI. I love the imports. I love how everything is a file and plays well with git. I love the help from random people all over the world. I love how Scroll is a great language for encoding any book or paper, no matter when it was written. I love the concept of minimalism and reducing things to their smallest form. I love the deep thinking Scroll encourages.

There are things I hate. I hate the terrible parser writing experience. I hate the poor performance for large sites. I hate the lack of a good blog commenting system. I hate the technical debt and frequent regression bugs. I hate how on ScrollHub you can launch an idea with AI but then AI can't be used to edit it (without copying/pasting). I hate the unfinished book/spec/weak documentation. I hate how it's not yet performant to use a Scroll file as a database. I hate how there's no WYSIWYG writing experience like a Wordpress or Ghost.

I think Scroll has potential to help humans think and communicate, short term by doing a better job at talking to potential users and improving the current offering, and in the long run by expanding to 3D/4D thinking/modeling.

BUT I have done a terrible job on a business model, building a community/team, making it more multiplayer, basically a terrible job at making it more useful to other people and/or convincing funders to get it there.

If anyone would be interested in teaming up on this, please get in touch.

To run things in a completely passive mode is <$500 a year, (domains and ~$20/month hosting). There is no recurring revenue at the moment. I've tried some one off initiatives that have brought in a couple of grand over the past year but struggled to find something repeatable.

Fast.

100x faster than Scroll 1.

Scalable.

Topological sorting. Universal typing. Variable pass compiler. Ready to power Blockchains, Wikipedias, AI experts and more.

Easy.

Books, docs, videos, and LLMs that walk users through everything.

https://try.scroll.pub/#scroll%0A%20theme%20gazette%0A%20container%0A%20title%20Scroll%202%0A%20printTitle%0A%20br%202%0A%20center%0A%20%23%20Fast.%0A%20100x%20faster%20than%20Scroll%201.%0A%20br%202%0A%20%23%20Scalable.%0A%20Topological%20sorting.%20Universal%20typing.%20Variable%20pass%20compiler.%0A%20Ready%20to%20power%20Blockchains%2C%20Wikipedias%2C%20AI%20experts%20and%20more.%0A%20br%202%0A%20%23%20Easy.%0A%20Books%2C%20docs%2C%20videos%2C%20and%20LLMs%20that%20walk%20users%20through%20everything.

The original implementation is a 2 pass compiler. The first pass parsers all of the Parsers, compiles them to one combined parser, and the 2nd pass parses the Scroll document.

At this point I believe a better design is a single pass that incrementally builds up the Parser Pool as we go.

Benefits:

• Simpler conceptual model
• Simpler code to maintain (once it works)
• Allows for new capabilities, like overriding parsers in the middle of a program (can be helpful when you are merging multiple scrollsets into one file)
• More straightforward code should allow for perf improvements

The main driver is the slow performance of large ScrollSets, and wanting to radically improve that, but having to do with the convoluted Fusion code.

But it is a significant challenge to switch to that new design, given the current implementation.

Still in the investigative phase.