My two ¢: I also get fatigue when reading too much AI generated words. There's something about the over-polished nature of AI text and the missing feeling that you are interacting with a real human that makes it tiring to engage with for long periods of time. I don't have any evidence to support this, but my gut feeling is that - in contrast to AI - there is some "roughness" with interacting with humans that makes it easier for me to mentally "latch on to" their words that doesn't come with AI.

I used Shimmer in 2022. The app had poor UX and frequent bugs, and the core offering (weekly Google Meet sessions with a “coach”) felt like generic self-help and not personalized coaching. The promised between-session support mostly consisted of DM'd article links, even after I raised that concern directly.

The sessions themselves often felt unprofessional, with background noise, unstable connections, and poor audio quality. The coach WFM'd on their couch during call. Given the price (hundreds of dollars per month at the time), the gap between what was marketed and what was delivered was significant.

Hopefully the new product addresses these issues, but I’d encourage people evaluating it to look at Shimmer’s prior execution and customer feedback, not just the announcement.

Though yes, they could have explicitly defined a z-index or defined a convention on how the ordering should work (first nodes top and last nodes bottom or vice versa?). It's interesting to think about the trade offs between explicitly defining these things vs. leaving the application to implicitly make the choice. JSON Canvas seems to be designed to use in tandem with markdown files in a note taking app, so it makes sense why they opted for the more implicit design to be similar to markdown

Sqlite as an application file format is great [1], but for a knowledge base / note taking app the benefits are not worth the tradeoffs in my opinion.

Sqlite is more performant more performant and provides lots of built-in features. However, most note taking users do not have enough notes or files to benefit from that performance. Sqlite will also lock the user into the application, whereas a "pack of files" can be used in the shell as a text editor. Using markdown files + a open json format has the benefit of being supported by multiple applications (e.g. sometimes i open my obsidian vault in vscode), while a sqlite database would need a proprietary schema coupled with a single application

I prefer an open file format that isn't tied to a vendor. A "data bridge" might handle syncing and diffing more efficiently than plain files, but it is still tied to the vendor. For example, I prefer not to pay for Obsidian Sync, and I'm able to use a git plugin and storing my files on nextcloud to sync between my devices. This leverages existing tech without having to implement features from the ground up

[1] https://www.sqlite.org/appfileformat.html

[1] https://www.json.org/json-en.html

JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of implementation details (i.e. how are files rendered, what file formats are supported, etc), edit tags, etc) are left open to implementation.

Markdown and JSON are meant to be non-opague file formats that prioritizes portability and human readability over other features. An application format like Sqlite has a lot of benefits over markdown, but it loses the benefits of text based formats like being compatible with git and is less portable.

What I would like to see is a convention for extending the node and edge definitions, similar to frontmatter in markdown files- something that is not required for basic rendering but is a nice-to-have for applications to consume) - that way portability between apps of varying complexity can be maximized while still allowing for more complex features that some apps might implement. Markdown has the benefit of supporting extensions (for example like tables in GFM) - apps that are not compatible can still render the unsupported markup. But there should be an explicit way to extend open JSON formats.

Some feedback off the top of my head and from reading the comments:

1. *Specifying node ordering*. Obsidian seems to just send whatever is last touched to the top, but this makes a common feature in many apps (move up/down/back/front) more difficult to impement

2.*More explicit definition for line shape*. Adding a way to "bend" a line in a specific way. Useful for creating more complex diagrams.

3. *Relations between nodes*. Group nodes contain child nodes, but the spec doesn't specify how the child nodes are defined. I would expect it to have a `children` property to nest nodes. Obsidian seems to implicitly link nodes to groups based on whether their bounds intersect. This makes it difficult to implement some common features:

a. nodes that exist outside of the bounds of its group, for example a node that "floats" just outside of the edge of the group's borders.

b. nodes that are not part of a group even though it exists within the bounds of that group.

There are many different ways for a canvas app to extend the spec to implement those features, but it seems like something that should be defined in the spec to maximize portability

4. *Extensibility.* Either explicitly support or provide a standard for defining more styles for nodes and edges, such as stroke width, stroke style, rotation, etc. It seems like "color" should be a part of this as well, rather than being an explicit property of a node.

5. *Embeds.* Supporting "embeds" as a node type. I even think the "file" node should be redefined as `embed` with a `uri` property to support different schemes (`file://`, `oembed://`, `https://`) and maybe a `mime-type` (`text/markdown`, `image/webp`). The file node's "subpath" property seems to be only relevant for markdown files, so I think that should be an extension rather than an explicitly defined.

6.*YAML* :) (Should just seemlessly convert from json, but yaml is more readable than json)

Being able to design standards that evolve over time and making tough decisions about what what to make explicit and what to leave implicit is a skill I want to improve on as a developer this year. Does anyone have any resource recommendations or best practices to recommend for me to research?

* Using SQL has clear benefits for writing an application. You can use existing stable tools for performing migrations.

* Using SQLite in a filesystem offers many advantages w.r.t performance and reliability. Do these advantages translate over when using WebAssembly SQLite over OPFS?

* How does SQLite / OPFS performance compare to reading / writing to localstorage?

* From what I know about web workers, the browser thinks it is making http requests to communicate with subzero, while the web worker proxies these requests to a local subzero server. What is the overhead cost with doing this, and what benefits does this give over having the browser communicate directly with SQLite?

* I remember seeing a demo of using [SQLite over HTTP](https://hn.algolia.com/?q=sqlite+http) a while back. I wonder if that can be implemented with web workers as an even simpler interface between the web and SQLite and how that affects bundle size...

Would I host any of my critical side projects on my cluster? Probably not. Kubernetes was made with large organizations (google made it after all) in mind. As a solo developer, it's better for me to host my apps on a VM and move to AWS/Azure/GCP if I need to scale.

I even started self hosting it this year and it continues to "just work" - although I don't recommend it to most people since I now have to manage a server. I was already self hosting a lot of other things last year (wanted to move away from google/apple services) so the "cost" of self hosting Bitwarden was negligible.

Anyway I know I rambled a lot, but just wanted to chime in and throw in my opinion about bitwarden

1. Provisioning the server, either via VPS or setting it up on your local machine and exposing port 443.

2. Installing Apache on your operating system

3. Installing a cert, getting it signed by an authority

4. Installing php, enabling it in apache

5. Installing mysql

At this point you'll have to write your php from scratch or use something like wordpress. Assuming we want to keep it as simple as possible and write php from scratch, you'll want to consider file permissions so your database credentials aren't accidentally leaked.

6. Creating the schema and tables on your database

7. Distributing your site's static content through a CDN

And this doesn't even involve automated deployments, which these services give out of the box.

My point is that a "traditional" approach can appear just as overengineered and convoluted if we want to replicate the scalability, stability and security of solid PaaS services like Vercel and Fauna.

I get that a hit counter is very simple, but I assume the point of this article is to provide a simple "hello world" example that uses these PaaS services, which again, provide a lot of benefits over manually configuring infrastructure.

pros:

* No tooling to set up, don't have to think about project structure or computation (VMs or cloud functions)

* Don't have to think about databases, connection strings, etc

* Fast deployments

* Perfect for rapid prototyping or hackathons

cons:

* Vendor lock-in at the language and infrastructure level

* Not open source

* Have to learn a new language

Compared to serverless (for a CRUD application), I wouldn't have to write configuration to set up the API endpoints / dynamodb tables. Also, deployments would be super fast which closes the developer feedback loop. I shouldn't have to worry about emulating my stack locally or deploying my stack every time I want to test my code.

The cons make this very hard for me to buy though. My ideal framework would be open source in a popular language (JS / Go), runs on cloud (AWS / Azure / GCP), fast deployments (no cloudformation), low configuration / convention based (like nextjs), and integrates with popular NoSQL data stores (mongo, redis, etc). Basically it would be completely conventional with an opinioned data access and the ability to override features to add more complicated functionality like optimizing data access after the initial prototyping.