Framework is unfortunately a term that's both ill-defined and quite overloaded. Electron is a framework in a very different sense than the "JS frameworks" op is asking about. The latter is about libraries with APIs and mental models for producing the UI & UX of web applications.
Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs. You wouldn't say that Chrome/Firefox/Safari are frameworks just because they execute JS code and has APIs. In the context of this discussion, it is fair to say that Obsidian was built without a framework.
> Electron is a framework in a very different sense than the "JS frameworks" op is asking about.
The OP doesn't have a good understanding of what they're asking about, and that's okay. That's why they asked the question.
The linked thread is titled "What framework did the developer use to create Obsidian desktop application?". It's not asking about a web application and specifically referencing a desktop framework with: "He must be using some sort of desktop framework in order to push this out simultaneously right?".
> The latter is about libraries with APIs and mental models for producing the UI & UX of web applications.
Obsidian is not a web application. It is a desktop and mobile application. There is presently no Obsidian web application. So it would be odd to be asking about web frameworks for a non-web desktop and mobile application.
> Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs.
No, Electron is a complete Javascript-based application framework. It does so much more[1] than that.
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.
Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs. You wouldn't say that Chrome/Firefox/Safari are frameworks just because they execute JS code and has APIs. In the context of this discussion, it is fair to say that Obsidian was built without a framework.