4 ms·
I don't even know what the argument is either. Vendor lock-in on behalf of Apple, Google, and Microsoft, sure. But then: > but all frameworks are guilty. Elec
by juunpp 4y ago
I don't even know what the argument is either.
Vendor lock-in on behalf of Apple, Google, and Microsoft, sure. But then:
> but all frameworks are guilty. Electron, Capacitor, Tauri, Xamarin, Qt, NativeScript, the lot.
Well, these all solve entirely different problems. Different problems, different solutions. Not sure what the "lock-in" is here. It's like arguing that there is "lock-in" because one project is written in C# and the other in Javascript. Seems like stretching the concept of "lock-in" too thin.
> What I’d really rather see more of is standalone platform-agnostic modules
This is a false proposition. A phone is very different from a desktop. "Platform-agnostic" would mean a denominator so common that it isn't useful for anything. Again, different problem/hardware, different solution.
The rest of the post just devolves from there.
- Kinrany 4y ago> It's like arguing that there is "lock-in" because one project is written in C# and the other in Javascript. Seems like stretching the concept of "lock-in" too thin. This is absolutely an instance of lock-in. An ecosystem grows faster when it can borrow from other ecosystems but doesn't allow doing the same. This is exactly the same problem: there is no good FFI, so we have to write M libraries times N languages.
- juunpp 3y agoI agree that M libraries x N languages is an absurd reality (and why I still write C), but "lock-in" to me suggests intent, and the situation you describe is more accidental, at least if you exclude corporate languages like .NET and such.