samuelstros

100% agree with the sentimment. markdown is hell as a format for editors :D

the effort it takes to serialize and parse markdown into an AST that rich text editor frameworks reliably operate on takes months. been there, done that. the majority of the engineering effort of building a markdown editor in the browser went into parsing and serializing markdown :/

Anyhow, we took the learnings from the Markdown editor app and created "zettel" as a result: https://github.com/opral/monorepo/tree/main/packages/zettel/.... The goal is to have an interoperable rich text AST—basically Markdown but with an AST spec.

> The only reason people build “apps” in the browser to begin with is because it simplifies the development for the engineering team. Easier to ship, easier to update, write once, etc. Sometimes the user benefits, but rarely.

Interesting take. Usually web apps lower friction for users.

- no installations - no large binaries - collaborative - easy to adopt

I can't think of any (desktop) app that came out in recent years that specifically pitched "because native, we are better" and won. Sketch is a glaring example of a web app (figma) killing native (sketch)

What makes you think the browser as OS is silly?

nice, "run JS without (browser) runtime" is coming. perforr, jaws, or another project will eventually succeed.

Why did you pivot away from localization?

See their old launch https://news.ycombinator.com/item?id=31166924

That's a good tip. I was wondering how SQLite avoids page fragmentation. The answer is "it depends," but VACUUM is to the rescue.

What are your reasons for advocating for SQLite as a filesystem abstraction?

Today i learned that HN has a nesting limit. @surrealize i fixed the username https://github.com/opral/monorepo/commit/7dc1f3c806bd89c6d68...

Yes. The runtime was not affected. Hence, the ts-expect-error. Still nice to have the ts-expect-error fixed :)

You are now forever in our git history https://github.com/opral/monorepo/commit/58734e11e51d8e20092.... the ts-expect-error was indeed fixed by your suggestion

Yes. We looked at all version control systems (fossil, pijul, jj, git, darc, sapling). None provide what we need:

- target the browser

- supports any file format, not just text files

- understands changes, not just versioning of files

- suited to build web apps on top

- ultimately enable 1000's of artists, designers, lawyers, civil engineers, etc. to collaborate

we are 2 years into the journey. dec 16, we'll release a public preview

the types kysely implemented are crazy. even custom where clause like this one [0] are typesafe :O

[0] https://github.com/opral/monorepo/blob/99356e577f558f4442a95...

We also came around to dumping files into SQLite instead of dealing with the filesystem (and git) for the lix change control system. This article touches on problems we encountered: https://opral.substack.com/i/150054233/breaking-git-compatib....

- File locking, concurrency, etc., are problems that SQLite solves

- Using SQLite allows drumroll querying files with SQL instead of platform-dependent fs APIs

- Using SQL queries is typesafe with Kysely https://kysely.dev/ (without the need for an ORM)

I wish we could talk about your use case later at Local Thirst. But ... I lost my passport and won't be able to make it. Another time!

Yeah bummer that Safari and Firefox are blocking any origin file access for security reasons.

> when the company owning the DNS records for that origin goes out of business.

Likely not a problem. Local data in OPFS is synced with a remote server for collaboration reasons anyway.

> There's also the issue with actually having an executable that can just run without any external dependencies

Assume you target the browser as OS, then it's already possible to have an executable: Run the JS file that renders a UI. Related: We will likely have an app launcher demo soon for https://lix.opral.com/

OPFS works in Safari, see this demo app https://csv-n2qj.onrender.com/.

What doesn't work in Safari and Firefox is (non sandboxed) access to the files of a user. OPFS is sandboxed.

Webapps will work locally soon. Say hello to OPFS https://web.dev/articles/origin-private-file-system. Works surprisingly good, see this demo app https://fink2.onrender.com/

Using lix change control to plot changes over time is a neat idea!

Hm. Not convincing. Disclaimer: I am the founder of Opral (https://inlang.com/ && https://lix.opral.com/)

The idea of parsing source code to auto inject translations, especially while leveraging machine translations comes up every 2 months.

It’s not solving the problem.

The problem to be solved is change control. Doing translations is (surprise!) cheap compared to controlling changes. Changes referring to the marketing copy changed, the button label changed, a new screen has been added, etc. It needs one system that can track and control changes across apps, translations, files.

If change control is solved, localization boils down to managing CI/CD pipelines.

While building lix change control I figured out that collaboration was/is the driver behind local to cloud. A secondary reason is compute.

If a system exists that enables (distributed) collaboration on files, the appeal of cloud-based software vanishes. Remote compute becomes possible as well.

At least, that’s the bet we are taking with lix https://lix.opral.com/

Agree. What’s your reasoning?

interesting. that was not the case in 2019 when i did a bit of data science.

are you running into issues while building on top of git & github? i assume that you need to teach data science people git/github

i assume that editing csv's is coming later? i can upload a csv but not edit it

Did that, done that. Check out https://inlang.com/m/tdozzpar/app-inlang-finkLocalizationEdi...

We are going to switch the approach from opening git repos in the browser to a new "version control" system that is designed for apps and file formats beyond text. Building an app on top of git is a fiasco that leads to 90% of time investments going into workarounds around git, like a text-based database to avoid merge conflicts.

We are making the "version control system" for apps and binary files available soon. Here is a landing page https://lix.opral.com/

Isn't sending an email publishing (in version control terms CI/CD deployment)?

Things we discussed:

- a commit is somewhat a 'save' but unlike a 'final_v1.docx'

- a commit prevents changes from being overwritten

Doesn't make click for me. Snapshot is a VCS term that seems to have a different meaning in photography.

From Wikipedia "A snapshot is a photograph that is "shot" spontaneously and quickly, most often without artistic or journalistic intent and usually made with a relatively cheap and compact camera."

disclaimer: i'm the founder of https://inlang.com/

monetizing your solution will likely be a dead end.

the value prop of your solution doesn't match the app you built, and what buyers pay for. for example, machine translating translation files is easier for you to build and developers to use with a cli [0] instead of a web app. there is no value in rendering json in the web app. vscode does a better job at rendering json's.

you could monetize via a web app if you allow non-devs to edit translations. but that's a beast called CAT editor [1], where you need to support all sorts of different file formats. aka, the value of a CAT editor is the file support and ecosystem around it, not the editor itself.

[0] https://inlang.com/m/2qj2w8pu/app-inlang-cli#machine-transla...

[1] https://inlang.com/m/tdozzpar/app-inlang-finkLocalizationEdi...

> translation infrastructure built around .PO files

not only .po files :D XML, i18next json, localizable strings (iOS), ... the list goes on.

if conflict resolution has to happen in the network layer -> tbd. it seems like apps that have built-in conflict resolution can resolve conflicts.

zip archives will play a role. i am pushing for "zipped repositories" internally, precisely for portability. but also because it makes the UX of using apps with conflict resolution like any other file-based software: simple.

btw my rfc led to another one https://github.com/orgs/opral/discussions/2975. if we agree on the proposal, i will follow up soon with a "okay, we have repos now. let's zip them for portability"