4 ms·

I strongly disagree with most of the points in this article. Why does he blame small app developers for vendor lock-in? Why is everyone casually avoiding the fa

by s1k3s 4y ago

I strongly disagree with most of the points in this article. Why does he blame small app developers for vendor lock-in? Why is everyone casually avoiding the fact that vendor lock-in comes from.. vendors? You think I want to rewrite the same app 3 times for it to work on Apple, Google and Microsoft systems? When is the last time these 3 major platform owners have done anything but locking you in their ecosystem? Such a weird take on this, really.

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 ago
    I 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.
akira2501 4y ago
The sense I get is, things should be more open, but not too open, because then it would be harder to sell the app. They're hoping that a very unnatural state becomes the default because it would be more profitable for _them_. It's a selfish take.

by s1k3s 4y ago

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 ago
  I 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.

akira2501 4y ago

The sense I get is, things should be more open, but not too open, because then it would be harder to sell the app. They're hoping that a very unnatural state becomes the default because it would be more profitable for _them_. It's a selfish take.