I mean... Every serious operating system already has some form of keyring feature right?
Not necessarily. There are many paths to exfiltrated data that don't require privileged access, and can be exploited through vulnerabilities in other applications.
Yeah, and electron already has a secureStorage API that handles the OS interop for you. Which signal isn't using, and a PR already exists to enable...
Probably not. Having actually played with making a WYSIWYG editor as a learning project markdown is too simplistic for the formatting needs of any non-trivial text editing, as a serialized storage format.
You almost always end up back with your own data structure that you serialize into something like XML for storage. Or you end up supporting HTML or non-spec compliant syntax in your markdown.
And if you care about performance, you're not actually working with XML, HTML, or Markdown in memory. You're working with a data structure that you have to serialize/deserialize from your storage format. This is where markdown becomes a bit more tedious since it's not as easy to work with in this manner, and you end up with a weird parsing layer in-between the markdown and your runtime data structures.
The commenter that's downvoted is more correct than not IMHO (Also why are we downloading discussions??). Markdown is ill suited for "most WYSIWYG needs". It tends to get augmented with XML or custom non-spec compliant syntax. The spec poorly supports layout (columns, image & media positioning, sizing...etc) and styling (font color, size, family, backgrounds...etc)
There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.
It's typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.
Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.
There's no need to include complex technology stacks into it!
Now the real hard part is the rendering engine for WYSIWYG. That's a nightmare.
I go full chaos and look up where I last used it when I need a snippet...
And what does it imply?
That an AI might be better at writing documentation than the average dev, who is largely inept at writing good documentation?
Understandably, as technical writing isn't exactly a focus point or career growing thing for most devs. If it was, we would be writing much better code as well.
I've seen my peers work, they could use something like this. I'd welcome it.
Nevermind PC games, think about how this would impact mobile games. Where you get TONS of transient installs, and very few consistent players.
You could actually go into debt by using unity, and accidentally being successful if you aren't abusively monitizing your game.
Yeah but the ecosystem drags it about as far down as you can go.
Backend development for large applications relies on stability, the JS ecosystem has anything except stability.This is okay for FE development where you naturally have a lot of churn.
It's a reasonable expectation that a backend built today should be maintenance free and stable over the next 5-10 years if no more features or bugfixes are required. And is buildable, as is, anywhere in that timeframe with minimal or zero additional work.
Additionally, strong backends in the same ecosystem are similar, they use similar technologies, similar configs, similar patterns, and similar conventions. This is not the case for JS/TS backends, there is incredible churn that hurts their long term stability and the low-maintenance requirements of strong enterprise, and even more importantly small businesses backends.
Mature ecosystems provide this by default this is why C#/Java is so popular for these long-standing, massive, enterprise systems. Because they are stable, they have well established conventions, and are consistent across codebases and enterprises.
This is a perspective most devs in the ecosystem lack, given that half of all developers have < 5 years of experience and the vast majority of that is weighted into the JS ecosystem. It takes working with systems written in python, TS, JS, C#, Java....etc to gain the critical insight necessary to evaluate what is actually important in backend development.
Edit: to be clear this isn't just shitting on JavaScript because that's what people do, I work with it everyday, TS is by far my favorite language. 2/3 of my career is with JS/TS. This is recognizing actual problems that are not singularly solvable with the ecosystem that pulls down its liability for backend development. There are languages and ecosystems are much better for your back end it's not that scary to learn a new language (many of my co-workers would disagree it's not scary 😒)
If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.
Your frontend will always churn, that's the nature of the job.
This is what fundamental scientific illiteracy gets you.
When you have no reference point for how the world around you works anything makes sense.