SPB compared

(For a quick introduction to the SPB project read [this document]).

			___S.P.B.___	Evernotes	WordPress^*3	PowerPoint
Information belongs to ...			YOU	app	app	app
Web Friendly			YES	NO	YES	NO
Standard/Non propietary format			YES	NO	NO	NO
Zettlekasten friendly			YES	YES	NO	NO
Needs a non-standard DDBB			NO^*1	YES	YES	NO
Needs server maintenance			NO	NO	YES	NO
git friendly (advanced distributed team collaboration and version control)			YES	NO	NO	NO
works Offline			YES	YES	NO	YES
Search by text			YES	YES	YES	NO
Search by (N-dimensional) topics			YES	YES	YES	NO
Search by unique-id			YES	NO	YES	NO
Search by text and topic			YES	YES?	YES?	NO
Search speed			FAST^*1	FAST	SLOW	N/A
Save search as bookmark			YES	NO	YES	NO
Proximity map			YES	NO	NO	NO
Fast preview			YES	NO	NO	YES
e-commerce/SEO plugins			NO	NO	YES	NO
Intranet/Public Web			INTRA	INTRA	PUBLIC	NONE
Zoom in/out Map view			YES	NO	NO	NO
Print to book			YES	NO	YES?	NO
Print sub-book			YES	NO	NO	NO
WYSIWYG Interface			NO	YES	YES	YES
Quick edit interface			YES^*2	NO	NO	NO
1 Your HTML file is your database. Content is indexed and classified upon page load in real-time by the web browser Javascript engine. 2 Using your favourite HTML/text editor with support for macros, templates, auto-completion. 3 Similar results apply to other CMS like Confluence or SharePoint. 4 Modern web browsers load, index and classify a full book or site faster than the time it takes to load a single article from a remote CMS. This is due to the bottleneck in CMS central database when different users search for content in parallel saturating the resources. With the SPB approach, no pressure is put on any central database. All search is run in parallel on each client.

SPB compared to ...

... advanced note-taking apps (Evernote, ...)

Evernote (and others) are friendly visual apps targeting any type of user. Those apps use some form of proprietary database format to store the content and proprietary services to synchronize it.

On the other side SPB follows the philosophy that the storage format must be as simple and safe as possible to be sure 10 years from now we have zero problems to recover the information written inside or copy/export it to a different device or platform.
The internal format of SPB is HTML (plain-text mixed with plain-text tags).
(It takes a couple of hours to master the basics of HTML, and then you can use it for the rest of your life).
Even in the absence of a web-browser the documentation in an HTML SPB project can be consulted with text editor like Notepad, vim, Ultraedit or Word and transformed with easy to other formats.
This is how a "Notes on Java" SPB looks like, and this is how its corresponding text/HTML internal source format looks like.
If some hardware error corrupts the HTML file, much of information can still be recovered. This is mostly impossible with binary proprietary formats.

Editing content with HTML (vs WYSIWYG note-taking apps) is less friendly for newcomers, but it's (much) faster once used to the minimal HTML syntax, specially once we get used to some of the many powerful free and commercial tools available on the wild. The acquired HTML knowledge gained while editing SPB documentation, is also reusable in many other contexts like e-commerce, or digital publishing.
Also by using standard HTML, SPB documents can also integrated with easy with any other HTML content, for example, allowing to add to business-charts, auto-generated HTML reporting outputs, video content, ... .
This is not possible with proprietary tools/formats.

Since version 1.1 SPBs allows to create printed books (or sub-books) of the content, again by just profiting from standard (CSS) technology in modern browsers.

HTML formats allows also to share the information as e-mail or chat attachments, or integrate into distributed (high-tolerant to hardware&network failures) version control systems like Git for collaborative, distributed and offline work.
This is not possible with proprietary tools/formats.

Probably "normal" users will be happy enough with apps like Evernote, but once they want something more "advanced" and gain control, they will prefer the power of standard Web technologies like SPB.
... PowerPoint presentations:

Metaphorically speaking, if Power Point is an Apple Store of documentation in Fifth Avenue where i-Phones are sold, the SPB is the Apple factory in Asia where document information is stored, assembled and tested.
- From the writer's point of view, quick (1-hours) presentations can be done on Power Point. Storing the knowledge acquired over the years in different interrelated topics requires "something else". SPB is this "something else".
- From the reader point-of-view, a Power Point can be enough to put attention, then an SPB will be needed to make sensible decisions.
... Learn X in Y Minutes (Link):
Learn X in Y minutes (and related ones like cheat.sh, "bullet points", ...) have surged to create a "learn-fast" path for newcomers with few free time.
They make a great job for what they have been designed. Still such projects fall short once we try to get deeper since there is no easy way to relate growing information in different places.
Learning data-science or IA or modern language programming is not about one cheat-sheet, but about many inter-related ones.
SPB can be used to create extended "learn X in Y minutes" covering the basics, the details, and the ecosystem around, and making all the information easier to retrieve.
This is how "learn-x-in-y-minutes" presents java to newcomers and this is how SPB presents java to newcomers and seniors developers.
... Zettelkasten knowledge and info management:
Zettlekasten follows a set of patterns for advanced documentation and note-taking.
Actually SPB do not compares to, but can be used as a way for "Zettelkasten"ing.
Some tools have been developed for Zettelkasten. With SPB, the tool is your browser!.
Actually "Zettelkasten"ers looks to like the SPB format according to some comments in reddit.
... Content Management Systems (CMS):
A CMS is an application running 24x7 in a server "somewhere in the Internet".
The SPB is NOT a server or any other type of software, just plain HTML (OK, and some spots of JavaScript and CSS).
The content on a CMS is stored in a central database running also "somewhere in the Internet"
The content on a SPB is the HTML file in your local hard-disk. Since it's HTML (plain text) you can use some tool like git to put on a central or distributed system (and branch, fork or collaborate with your team).
CMS is more user-friendly ... once you have a server running 24x7, and some CMS admin is out there to "keep it alive" and the network is up and there are backups in place and users agree of common usage pattern, and someone/somebody takes charge of cleaning repeated information and same topics are used by anyone, and users are notified of other users changes ... and users don't get used to think that the CMS is a place to "pile" random word and powerpoint files and care is taken to avoid repeated content in different places (or even worse, different versions of the same content anywhere) OK, you know, CMS most of the times does not work as planned. It requires lot of attention and discipline by end users (and CMS administrators).
... Wikis:
SPB can be seen as a lightweight Wiki. Actually Wikis can be seen as lightweight CMSs.
A Wiki usually also need a server running 24x7 and Wiki operators to maintain it.
Similar advantages / disadvantages than in the CMS should apply. Actually the Wikipedia is the only Wiki/CMS I'm aware that run as expected once they managed to have a server running 24x7, and some CMS admin is out there to "keep it alive" and the network is up and there are backups in place and users agree of common usage pattern, and someone/somebody takes charge of cleaning repeated information and same topics are used by anyone,
... Plain text files:
Important things (those that affects thousands of millions of people every day) are written down in ".txt".
HTML and by extension SPB, also likes txt. Just put your important staff inside <pre zoom> tags (pre: pre-formatted).
... Canvas like boards:
With some minor training on how to layout elements, SPB can also be used as a simple canvas-like application (and again, being pure HTML/txt, you can profit from all the "goodies" of git to version or branch your project canvas).
With good programming skills it can also be used as a complex canvas-like board, by just rendering the HTML "somehow" from a remote server.
... Git to WiKi like systems:
As of 2021 more companies are realizing about the advantages of using the git-to-wiki approach to replace complex CMS with their internal complex databases. (historical note: SPB is more than 3 years ahead of them).
This link explains how Mozilla has changed its SQL database for a git repository to maintain its documentation and how such change has permitted to increase the number of potential contributors, simplified the infrastructure and maintenance of the system.
The main difference is that a SPB is a final solution, while most git-to-wiki systems still need some type of setup and extra setup steps to transform content in git to a final HTML content.
git-to-wiki is a better approach when hundreds or thousands of writers are expected on the same document, while SPB (a single HTML file) is simpler when just a few writers work together.
Advanced users with some minimal script experience (bash, python,...), can also generate SPBs as the output of a batch or script execution to have all the advantages of git-to-wiki systems for free, while normal users just need to expend a couple of hours learning the basics of HTML.
... Issue and Project Tracking Software (JIRA):
SPB was not designed with the intention of creating a project-tracking software. Nevertheless daily usage probes that it offers a light platform to track projects, issues or deadlines with little effort by just choosing the appropiate topics to classify the content.
Using SPB avoid set-up and maintenance of complex infrastructure (again, no need for databases and JIRA servers running and serving request) and gets rid of opinionated workflows and data internal opaque schemas (just look at the Entity-relationship internals of JIRA) that many times stand in they way instead of helping to manage projects.
Of course, integration of the Tracking Software with the Content Management System is straightforward (actually it can be the same document) and so it is integration with Git. Just as a reference, the plugin to make the JIRA project tracking system integrate with the Confluence tracking system is larger than the full Javascript code used in SPB. On top of that JIRA and Confluence need one or more servers running a SQL database, a 1Gigabyte JAVA SDK, and two separate processes for JIRA and Confluence, each of them running "many" parallel threads, even before starting to write a single ticket. Tracking systems like JIRA do not ussualy provide a clean mechanism to check "who-changed-what", something that makes tracking other people's progress very problematic and cumbersome.
When using SPB, we let Git track changes:
Git provides to documentation the same service that blockchain provides to money. It keep a trace of all changes and how a given data (some note in git, some account balance in blockchain) evolved over time to arrive to the current state. It's used by all major software companies (Google, Microsoft, IBM, Amazon, ...) to track their most valuable assets, source-code.
Most probably you are reading this page in github, a git hosting service frequently used to track code ... and documentation.
Author's Personal note: I still have nightmares with a old project where the scrum "master" liked to play with JIRA customizing it in a million of non-standard ways that only he was aware of, using magic (and useless) plugins.
Worst at all, the system was constantly down or irresponsive. And this complex structure and buggy solution was used to update just about 2-3 tickets per-week per-user on average.