4 ms·

Discoverability and system integration are huge problems, sure, but Cordova mostly addresses these concerns. The reason everyone always cites for going native

Discoverability and system integration are huge problems, sure, but Cordova mostly addresses these concerns. The reason everyone always cites for going native is "performance", but, tbh, it seems like most web projects don't pay attention to the same level of detail as native apps because the web is so much faster to prototype. I bet if devs spent the same amount of time working on perf and loading states on the web as they did on native, the performance argument would have much less impact.

randomdata 13y ago
> the web is so much faster to prototype. We tried testing that theory, having one team prototype the same app using web technologies and the other prototyping it using iOS native technologies. iOS appeared to be the faster of the two. The vast majority of the work was prototypeable in Storyboards directly, and only required, if I recall correctly, around 20 lines of code for supporting requirements to build out the prototype. I haven't found many tools for the web that can compete with that. Of course it depends on what you are trying to develop. If your application is document-centric, then it will be difficult to beat HTML. That is, after all, what it is designed for. But for an application-centric design, I'm not sure it is really all that fast as a prototyping platform – unless, I suppose, that is all you know. It does take time to ramp up familiarity with new platforms.
- bennyg 13y ago
  Objective-C is so beautiful in those regards. So many things are abstracted and optimized for you already, especially compared to Android and their libraries. Rapid prototyping is insanely fast if you can handle yourself in Xcode and around Obj-C.
  - enraged_camel 13y ago
    Yep. And people still wonder why most developers prefer developing for iOS first...
  - jkn 13y ago
    You make me curious. Could you provide some examples of the benefits of Objective-C in this context? (and how it compares to Android and its libraries).
  - chc 13y ago
    I don't see how this has anything to do with Objective-C. He actually said he used very little Objective-C and did it mostly in Xibs.
    - randomdata 13y ago
      I think I see where he is coming from. They are not exactly separable. Interface Builder is more than just an interface builder, it is a serialized data builder. That distinction means that you can instantiate virtually any class in your project without having to write a line of code. It is not limited to just UI elements. That turns out to be pretty powerful. Below that level, the deserializer exploits a number of properties of the Objective-C's dynamic runtime in order to provide that instantiation of random objects and properties. There are certainly other languages that can be exploited in the same way, but it is not something that can be done directly in just any language. Without Objective-C, or at least something like it, there would be no Interface Builder as we know it today.
jjtheblunt 13y ago
There are entire types of things not possible in web apps, such as true threading with a dedicated processor, accessing OpenGL accelerator support with custom shaders, getting at purposeful hardware support in general, whose reason for existence was cumulative need over more apps for more years than JavaScript and doms have existed.
- Lerc 13y ago
  The great big bullet point features (like OpenGL) are getting added. It's the small, subtle features that are being neglected. The test case that I'd like to see is someone replacing notepad.exe with a webapp in such a way that an end user cannot tell that a change has been done. It's the Turing test of usability. Web Apps can do an excellent editor, but the finer details like (associate *.txt, save, save-as etc.) are still a problem.
- rictic 13y ago
  There are things native can do that webapps can't, but the two examples you gave aren't among them. You write custom shaders with webgl, and make use of multiple processors with web workers (though they are more analogous to processes than threads, as they don't share state).

randomdata 13y ago

> the web is so much faster to prototype. We tried testing that theory, having one team prototype the same app using web technologies and the other prototyping it using iOS native technologies. iOS appeared to be the faster of the two. The vast majority of the work was prototypeable in Storyboards directly, and only required, if I recall correctly, around 20 lines of code for supporting requirements to build out the prototype. I haven't found many tools for the web that can compete with that. Of course it depends on what you are trying to develop. If your application is document-centric, then it will be difficult to beat HTML. That is, after all, what it is designed for. But for an application-centric design, I'm not sure it is really all that fast as a prototyping platform – unless, I suppose, that is all you know. It does take time to ramp up familiarity with new platforms.

bennyg 13y ago
Objective-C is so beautiful in those regards. So many things are abstracted and optimized for you already, especially compared to Android and their libraries. Rapid prototyping is insanely fast if you can handle yourself in Xcode and around Obj-C.
- enraged_camel 13y ago
  Yep. And people still wonder why most developers prefer developing for iOS first...
- jkn 13y ago
  You make me curious. Could you provide some examples of the benefits of Objective-C in this context? (and how it compares to Android and its libraries).
- chc 13y ago
  I don't see how this has anything to do with Objective-C. He actually said he used very little Objective-C and did it mostly in Xibs.
  - randomdata 13y ago
    I think I see where he is coming from. They are not exactly separable. Interface Builder is more than just an interface builder, it is a serialized data builder. That distinction means that you can instantiate virtually any class in your project without having to write a line of code. It is not limited to just UI elements. That turns out to be pretty powerful. Below that level, the deserializer exploits a number of properties of the Objective-C's dynamic runtime in order to provide that instantiation of random objects and properties. There are certainly other languages that can be exploited in the same way, but it is not something that can be done directly in just any language. Without Objective-C, or at least something like it, there would be no Interface Builder as we know it today.

jjtheblunt 13y ago

There are entire types of things not possible in web apps, such as true threading with a dedicated processor, accessing OpenGL accelerator support with custom shaders, getting at purposeful hardware support in general, whose reason for existence was cumulative need over more apps for more years than JavaScript and doms have existed.

Lerc 13y ago
The great big bullet point features (like OpenGL) are getting added. It's the small, subtle features that are being neglected. The test case that I'd like to see is someone replacing notepad.exe with a webapp in such a way that an end user cannot tell that a change has been done. It's the Turing test of usability. Web Apps can do an excellent editor, but the finer details like (associate *.txt, save, save-as etc.) are still a problem.
rictic 13y ago
There are things native can do that webapps can't, but the two examples you gave aren't among them. You write custom shaders with webgl, and make use of multiple processors with web workers (though they are more analogous to processes than threads, as they don't share state).