3 ms·

That may be, but not because of a barrier to entry. (the wall around the garden)

kevingadd 6y ago
The barrier to entry for integrating with the web ecosystem is way higher than native. I can interop trivially with basically any native app on my machine, meanwhile even basic tasks like 'export my data from this web service' are often difficult or impossible because vendors don't care. If you are building a custom product from scratch with no need to integrate with users' existing data and services, the barrier to entry is low. But most users have lots of existing data to use and it lives on other services, so you have to integrate... if you can
- recursive 6y ago
  > I can interop trivially with basically any native app on my machine. You must have different native apps than most users. In any case, there's nothing special about WASM and DOM that makes it less interoperable than native stuff.
  - kevingadd 6y ago
    The problem isn't WASM and DOM, it's that in the web environment because the storage and expressiveness are so limited most of your data lives on a third-party server and now you have to integrate with that. My Outlook and Thunderbird inboxes are files on my local disk, so if I'm determined enough I can dig through those files with custom software. If I want to process my gmails no amount of time in a hex editor will help me because that data lives on a server somewhere. In practice, Thunderbird acts as my interop tool here, because the developers of that program did the work to keep up with whatever method was offered to pull content out of gmail. In this case there are standardized APIs (network protocols) for talking to mail servers, and lots of software that implements those. What's the equivalent if you want to do this in a webapp? Is there a common API that I can use in my webapp to access a user's gmail, apple mail, outlook mail, etc? In practice you need to do 1-off integrations with almost every given web service a customer's data might live on, and some of those services don't have any APIs so it's screen-scraping or nothing. It's as if every user's photos were stored in a mix of 50 different custom image file formats.

The barrier to entry for integrating with the web ecosystem is way higher than native. I can interop trivially with basically any native app on my machine, meanwhile even basic tasks like 'export my data from this web service' are often difficult or impossible because vendors don't care. If you are building a custom product from scratch with no need to integrate with users' existing data and services, the barrier to entry is low. But most users have lots of existing data to use and it lives on other services, so you have to integrate... if you can

recursive 6y ago
> I can interop trivially with basically any native app on my machine. You must have different native apps than most users. In any case, there's nothing special about WASM and DOM that makes it less interoperable than native stuff.
- kevingadd 6y ago
  The problem isn't WASM and DOM, it's that in the web environment because the storage and expressiveness are so limited most of your data lives on a third-party server and now you have to integrate with that. My Outlook and Thunderbird inboxes are files on my local disk, so if I'm determined enough I can dig through those files with custom software. If I want to process my gmails no amount of time in a hex editor will help me because that data lives on a server somewhere. In practice, Thunderbird acts as my interop tool here, because the developers of that program did the work to keep up with whatever method was offered to pull content out of gmail. In this case there are standardized APIs (network protocols) for talking to mail servers, and lots of software that implements those. What's the equivalent if you want to do this in a webapp? Is there a common API that I can use in my webapp to access a user's gmail, apple mail, outlook mail, etc? In practice you need to do 1-off integrations with almost every given web service a customer's data might live on, and some of those services don't have any APIs so it's screen-scraping or nothing. It's as if every user's photos were stored in a mix of 50 different custom image file formats.