simple - performance is often garbage. web apps use more cpu and memory than a native app. people should not need an M1 MacBook or better just to edit a document. (see top comment)
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.
The other problem I have is it blurs the lines between data on your machine (private) and data that is in the cloud. not everybody wants all their data in the cloud. When you’re working with a “app” in the web browser it’s not always clear.
> 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)
searching on the ios or mac app store, or sharing a link to the app download page, is not exactly hard to adopt most of the time.
Gen Z might think so but that’s because we’ve conditioned them to expect everything in a browser IMO, not because it’s actually complicated.
“no large binaries”, i agree browsers have an advantage here - somewhat. Most apps have large binaries because software development today is lazy. Companies typically use huge libraries for EVERYTHING and then their final binary gets bloated. For example 90% of apps (excluding games) could be 30mb or less. Stuff like analytics and user tracking, advertising libs, the list goes on.
Who says a native app can’t be collaborative? You can use http or websockets in a native app to push/pull data. That’s like saying social media apps aren’t collaborative.
I do agree some web apps are well executed. Figma is pretty good. Google docs and google maps are excellent. I have a few more that i genuinely enjoy using. That’s the _exception_ though.
The browser is for browsing the Internet, it is a tool specialized for that, it has nothing to do with being an operating system. Being able to boot an OS within it does not make it an OS either. It just adds an unnecessary and potentially detrimental (to both performance and security) layer: OS -> browser -> OS, which is just silly. If you do not see the absurdity, let us consider this: OS -> browser -> OS -> browser -> OS, ad infinitum. :P
I guess "yes" wouldn't be an incorrect answer, but a more nuanced look might want to consider that node does actually contain the js runtime of a browser, just minus all the rest of that browser.
A wasm runtime can be far more lightweight than node, not only because node itself is a wasm runtime, plus a lot of other things. Wasm could (or does, already?) occupy a sweet spot where platform independent extensibility is desired, but where that is not enough of a core feature to make inclusion of a heavier runtime advisable. Kind of like how Lua has its place, but with more focus on near-native speed and less focus on ad-hoc programming (aka scripting).
Totally random, but I had a guess about the ts error. I hadn't seen kysely before, very cool!
diff --git a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
index 7d677477e..39502f245 100644
--- a/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
+++ b/packages/lix-sdk/src/query-utilities/is-in-simulated-branch.ts
@@ -21,10 +21,9 @@ export function isInSimulatedCurrentBranch(
// change is not in a conflict
eb("change.id", "not in", (subquery) =>
subquery.selectFrom("conflict").select("conflict.change_id").unionAll(
- // @ts-expect-error - no idea why
subquery
.selectFrom("conflict")
- .select("conflict.conflicting_change_id"),
+ .select("conflict.conflicting_change_id as change_id"),
),
),
// change is in a conflict that has not been resolved
The conversation in some aspect may have tripped the flamewar detection, which removes the reply button iirc. You can manually reply to a specific comment by clicking/tapping on on its timestamp.
In the context of the union query, I think it makes sense. The query takes two different columns (with two different names) from the same table, and combines them together into one column. The TS error happened because the column names didn't match between the two union inputs. But they would never match without the "as".
I'm a huge proponent of using SQLite as an abstraction over a filesystem. One warning I will note though, is be aware that a SQLite database does not shrink unless you vacuum it (basically copies the data into a separate file and deletes the original). This is a manual operation you have to do at points where it makes sense within your application. So be careful with disk usage when just writing binary data and then deleting it.
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/
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.
Most data scientists know git! Or, at the very least, how to follow a step-by-step git guide.
If notebooks are tracked anywhere at an org it's either where their code is stored (GitHub/GitLab), or in their managed notebook environment (Databricks/Hex)
