5 ms·

Performance and access to the internal SDK seem to be what ultimately kill this approach. Seems like this happens at the beginning of every product cycle. So w

• sirkneeland 13y ago
  "Also, ChromeOS and FirefoxOS are browser's so of course they have a vested interest in making their apps in HTML / JS" Isn't that the point of those platforms?
• sirkneeland 13y ago
  Is this really the correct interpretation? Ubuntu IS releasing a native Qt/QML SDK... they're not going HTML exclusive here.
• erikpukinskis 13y ago
  > So we've got this decent platform, we build up HTML apps that end up kludgy compared to IOS or Android native People say this all the time, and it makes me wonder if I'm living on a different planet than them. I can see some places where native is better: * A camera app, or a guitar tuner... something that requires access to special APIs. Making that in HTML would be a kludge. * An app that's targeted at tech people, who want to feel like they're living in the future, and who need to have have fancy transitions and animations and subtle 3d effects. But in my experience, the vast majority of apps do NOT require those things. Most apps are just buttons and pages and pictures and videos, and for that kind of stuff, I honestly don't see what the advantage of native is over HTML. Maybe it's because I am an interaction designer. In my experience, the interaction design in most apps, native or HTML, is seriously lacking. It seems like almost no one actually tests their product with actual people. And it seems like very few developers are actually willing to build the dozens of prototypes that are required to iterate through a design in order to get something that actually works well. And so we end up with all of these native apps that are supposedly "not kludgy" because they have native widgets and 3d animations, but actually are extremely kludgy in that everything you do in them is a pain in the ass. But again, I hear people ring the native app bell over and over again like it's some major design issue. So maybe I'm just living in a different world.
  • Arnor 13y ago
    How do you feel about native vs HTML5 for applications that need to do a lot of timing? From my perspective setInterval and setTimeout seem pretty kludgy. Also, I'm really interested in what you mean by "the dozens of prototypes that are required..." If you're talking about building several prototypes of the same feature to compare and contrast, would you mind sharing the tools/workflows you use for this?
    • TuringTest 13y ago
      If you wrap the callbacks in promises or observables, they become a very elegant and side-effect-free model. Reactive programming is starting to get traction, now that it's more well known and being adopted by mainstream libraries.
      • taeric 13y ago
        I would argue it is gaining steam due to the money being poured into it. Probably also possible now that resources are particularly "free" on platforms. It isn't like most of these techniques were invented this past year.
    • erikpukinskis 13y ago
      No, I'm talking about a wide range of prototypes, from paper prototypes to experience prototypes to barely-functional HTML prototypes that only test one small aspect of your app, to small native apps that you throw away that let you test various aspects of your design that need to be mocked up more fully. Finally, towards the very end you might do a few variations within your fully realized native app, but that kind of prototyping is extraordinarily expensive and 90% of your design questions should be answered by that point. The output of a good design process should include dozens of vastly different looking prototypes, in totally different mediums, each of which helped answer key design questions. A good introduction to this's stuff is Rogers, Preece and Sharp's "Interaction Design". My personal favorite for diving into the breadth of design techniques is Brenda Laurel's "Design Research".