I mean, you're correct that Obsidian doesn't run on the browser. But it's built on web technologies. As a result, I would argue that the overlap between the skillset and work needed to build an app like Obsidian overlaps more with most web applications than most desktop and mobile applications.
You're also correct that Electron provides APIs beyond those available in the browser, such as access to the native filesystem. The way I see it, those are mostly some lower-level details it wouldn't be that hard to run Obsidian in the browser, it's just a product choice not to (specifically, it would imply creating a file hosting service). As the Obsidian mobile app demonstrates, Electron is swappable and not needed for Obsidian's core functionality. In contrast, had Obsidian been built on React, it would be rather difficult to simply "run without React" without rewriting the entire application.
How to build a large front-end app on non-web technologies (Swift, C++/QT, C#, etc) is also an interesting question but I didn't understand that as being the topic of this conversation.
I developed my note-taking app Daino Notes[1], which has a block editor (like Notion) and is written in C++ and QML using Qt. I wrote extensively about its development in my blog: https://rubymamistvalove.com/block-editor
Everyone else in this thread is talking about (React/Angular/Vue/JQuery/etc) v.s. (Plain JS/Direct DOM manipulation/etc). Running that code on top of Electron or not is entirely orthogonal. So I admit I'm confused why you're fixated on bringing Electron into the conversation. Op's question appears to me like it references the last part of the linked thread: "I’d like to know what JavaScript framework (e.g. Vue, React) Obsidian desktop application is using for creating the user interface?"
Since we seem to be talking past each other, what do you think the conversation is about?
Electron does not belong in the same category as React & Vue. JavaScript frameworks are commonly understood to mean:
- Third-party libraries, almost always implemented in JS (technically it could be some language compiled to WASM but I'm not aware of any commonly used WASM framework)
- Dynamically loaded from a CDN or bundled with application code at build time
- Provide an high-level API for creating and updating UI
- Whose implementation edits the DOM (a browser's low-level UI representation)
In contrast, writing an app _without a UI framework_, therefore implies writing first-party JS code that interacts with DOM APIs directly, without that level of abstraction in-between. This is not a common choice these days, and could be considered an impressive accomplishment, hence this Ask HN.
To create that UI, you use the same low-level DOM APIs in Electron as you would in the browser because well, it is a Chromium browser engine.
Example of each combination:
- Framework-using apps running in the browser: Airbnb, Figma
- Frameworkless apps running in the browser: HN
- Framework-using apps running in Electron: Figma's desktop app
- Frameworkless apps running in Electron: Obsidian
I wouldn't consider Electron as an answer to the question. It would be best described as a framework for running web apps as a standalone desktop app, but not a framework for creating user interfaces. Just using Electron doesn't make any progress towards having a solution for managing the complexity of writing code that interacts with the DOM.
You're also correct that Electron provides APIs beyond those available in the browser, such as access to the native filesystem. The way I see it, those are mostly some lower-level details it wouldn't be that hard to run Obsidian in the browser, it's just a product choice not to (specifically, it would imply creating a file hosting service). As the Obsidian mobile app demonstrates, Electron is swappable and not needed for Obsidian's core functionality. In contrast, had Obsidian been built on React, it would be rather difficult to simply "run without React" without rewriting the entire application.
How to build a large front-end app on non-web technologies (Swift, C++/QT, C#, etc) is also an interesting question but I didn't understand that as being the topic of this conversation.