4 ms·

> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks I never understand this point. All

> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks I never understand this point. All APIs are exposed via some protocol. Whether it's javascript, C, Objective-C or HTTP. High-level APIs like HTML5 or Cocoa need to be exposed in a high-level language. The restrictions imposed by js or obj-c are an inescapable part of what make these environments better than what we used before. Does anyone really want to go back to using thin wrappers around C APIs?

grey-area 13y ago
It's an interesting debate, and in particular UI bindings often need higher level access. I'm not convinced that the trade off of being locked into whatever Apple decides is the one true language and API is worth the gains though. I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser. That has been a limiting, but at the same time truly revolutionary, feature of web software which freed it from domination by large software vendors and restrictive practices like those we've seen on iOS or (to a lesser extent) Android. If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web - given the current situation of competing ecosystems with draconian restrictions I suspect they will all be subsumed by the web at some point.
- chrisdevereux 13y ago
  > I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser On the server, that's definitely true. On the client, it's basically the same situation w/r/t languages. But this is a client/server distinction, not a native/web distinction. Clients are just inherently coupled to the APIs that they use. Servers aren't so much. The coupling in languages reflects this. > If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web That's an interesting point (although we'll then be totally locked to a particular platform/language on the client) and I think the web will eventually win. But not for a while. At some point, the rate of progress on native will decrease and the advantages of standardization (cost, mostly) will overcome the disadvantages (lack of progress). It'll be interesting to see how the manafacturers adapt to that. I suspect that Google will do better than Apple.

grey-area 13y ago

It's an interesting debate, and in particular UI bindings often need higher level access. I'm not convinced that the trade off of being locked into whatever Apple decides is the one true language and API is worth the gains though. I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser. That has been a limiting, but at the same time truly revolutionary, feature of web software which freed it from domination by large software vendors and restrictive practices like those we've seen on iOS or (to a lesser extent) Android. If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web - given the current situation of competing ecosystems with draconian restrictions I suspect they will all be subsumed by the web at some point.

chrisdevereux 13y ago
> I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser On the server, that's definitely true. On the client, it's basically the same situation w/r/t languages. But this is a client/server distinction, not a native/web distinction. Clients are just inherently coupled to the APIs that they use. Servers aren't so much. The coupling in languages reflects this. > If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web That's an interesting point (although we'll then be totally locked to a particular platform/language on the client) and I think the web will eventually win. But not for a while. At some point, the rate of progress on native will decrease and the advantages of standardization (cost, mostly) will overcome the disadvantages (lack of progress). It'll be interesting to see how the manafacturers adapt to that. I suspect that Google will do better than Apple.