[rasmusfabbe]

Hello, person behind Playbit here. Happy to hear you like some of the concepts :-)

My hopes with Playbit is to create a "setting", a "scenery", really an environment which encourages software creators to be more experimental and do less heads-up planning. All this with a playful tone and approach. Think about someone wanting to spend a Sunday today, making some simple todo app or whatever. The wall of software the average person in this situation need to sift through is ridiculous. You install Homebrew, then nodejs, then some horrid 1900 file big set of npm packages, spend an hour researching how to get this week's js bundler working with the latest typescript with last week's most popular UI framework. And so on. Once you actually start tinkering on your little fun app, most of your Sunday has likely gone by. This is no criticism of and specific tools or software libraries but—I believe—a mindset issue.

If the barrier was lower to experiment we might see more ideas and more interesting software.

Is there nothing like this? Of course there is :-) History and event the contemporary software world offers many examples. For example, the web in ~2000 was really interesting. You could look at a big-name website, view source, save it as mything.html, make some edits—which result you'd see immediately—and share it by drag and drop in an FTP client. Was it the most immersive and rich software ever made? No. Was is the most reliable and testable way to develop software? Definitely not. Was is secure? Hell no. But was it fun and did it spur an ocean of ideas and creative change to software? Yes! Another example: In ~2005–2010 creating Mac OS X apps was a similar experience. Yes it was only possible on a Mac, but the barrier to make an app and share that with people was inspiringly low. Table views, buttons, windows and most other kinds of things you might want were all there and really easy to use. You spent your time exploring the essence of your app, not choosing which table-view implementation to use.

Now I don't know exactly what the path to something like that will look like, but my bet is that starting out with a safe playground that makes a few people able to experience this is a good place to start. Playbit might end up being more of an app you run on your whatever OS rather than an OS by itself, no matter the technical manifestation I believe that it needs to "take over the screen" for the "setting", the playful environment to succeed.

Addressing the DOM structure: This is a tactical & practical small piece of the Playbit effort. In order to provide a landscape in which to play there needs to be some lego pieces around to support the basics. Any interesting software indeed speaks with the outside world which can be thought of as "data" in "code & data" (i.e. software is both code and data.) An earlier version of the "data" solution was an acyclic graph, another was a Facebook Ent-like key-value database. I landed on a DOM structure as a (not "the", BTW) data layer. It can be used as a list to make a text editor, as a tree for an email app, or a dictionary for ...uhm, a dictionary.

Namespaces: The file system (it's "directories") is closer to the kind of namespaces I'm talking about (than for example namespaces in Clojure or C++.) The Linux kernel does have a (really neat) namespace feature which Playbit may make use of, but in a transient hierarchical way rather than a persistent concurrent way. In my experience namespaces gets messy when treated as a named link of indirection. We all know the classic saying that in computer science, all problems can be solved with an extra level of indirection. It's both a joke and a practical truth. Some limited indirection can be really useful (like for example file name -> inode -> disk sector) but when the abstraction (of the indirection) leaks it means a cognitive toll is payed by the person having to navigate it and that is not good. I think this is often when computers feel "complicated". I'm sure many of us have followed a call stack trace in code at some point, trying to trace the cause of an effect. If the program made use of things like asynchronous message passing (or things like JavaScript promises) the dimensionality of indirections can explode and we can almost feel the computer "working against us." Anyhow, end of ramble :-)