6 ms·

> Examples? Big ones: the whole Google suite. Gmail is clearly the most reliable, but strange things still happen in gmail, like chat dropping, task lists lock

by algore 16y ago

> Examples? Big ones: the whole Google suite. Gmail is clearly the most reliable, but strange things still happen in gmail, like chat dropping, task lists locking up, or crashes. I love gmail, use it all the time, has great features. But I'd love a native client for Gmail even more. Flickr. Great content and community, but the web interface is clearly clunky. Imagine Flickr on a tablet. Swiping, pinching, tapping. If you had the choice, you'd use the app, not the webpage. Facebook. Insanely popular, insanely buggy. Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive. Just using those 3 examples, you will see great client front-ends created for those in the next few years. Though maybe not Google if they don't get their head out of the sand. Soon Facebook will do a great tablet client, and it will be a KILLER app. So what type of professional document creation are you doing in Google Docs?

jasongullickson 16y ago
Yeah I've never had a native/desktop app exhibit any of these behaviors...oh wait...
mgcross 16y ago
It seems to me that some of the issues you mention with web apps would also be apparent with native apps acting as a front-end to online apps. Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that. Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I don't doubt for a minute that the experience would be better for each platform as a native app, but would it be profitable for small/medium size business? I feel like SMBs are the target of web-based mobile frameworks, for the most part. I don't think we'll see Facebook in JQuery Mobile any time soon.
- algore 16y ago
  > Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that. Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform. > I feel like SMBs are the target of web-based mobile frameworks Sure, that's possible. But there are also people creating native frameworks to put SMBs into apps. Magazines are a good example. The big publishers are making their own apps, but they're are also working on frameworks to deliver other magazines. Then there are non-publishers like Zinio that are making the platform for any magazine to be published. > Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I'm not arguing that everyone who wants a blog needs to write their own blog software. No, obviously they can use something like Wordpress, and let WP worry about the programming and compatibility, and they can concentrate on content. Same goes for apps. I'm simply saying that native apps always were superior to webapps. People forgot because it became so easy and cheap to churn out functional web code. AND because these mobile client devices were closed off for development for so long. Love him or hate him, Jobs opened up everything with the iPhone SDK. I think the expectation of a company to have a native app today is equivalent to the expectation that they would have a website in 1997. Back then it was a very expensive proposition. Today EVERYONE has a website. Tomorrow everyone will have an app. Doesn't mean they have to hire their own software team to build it from scratch.
  - jasonlotito 16y ago
    > Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform. I think you fail to realize this can be accomplished using the tools in the article. They have access to things like this, including cameras and what not. You keep saying things that make no sense in context.
    - algore 16y ago
      You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do. Why continue to struggle with a flawed platform? > You keep saying things that make no sense in context. In what context is that? I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong? Can you hack together a way to do all this in JS? Maybe, but it's unreliable, and it's years away from being comparable. Sure, you can wait 2 years until it's figured out, by then it will be outdated again anyway. I think you're very comfortable writing your web apps, it's something you understand and you're good at it, and naturally you're resisting change. But the industry is not going to stop changing because you're good at CSS hacks to make rounded corners on div blocks and you just wish we'd keep doing it that way because it's easy for you.
      - jasonlotito 16y ago
        > I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong? Your not. However, I haven't argued against this. > You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do. Well, good thing they aren't using HTML then. > In what context is that? In the context of the article. PhoneGap let's you create native software but using technology like HTML and JS that hooks into Apple's (and others) existing API. More importantly, Apple uses XML for it's UI as well, so the difference between HTML and Apple's own XML format for it's UI is negligible. > and naturally you're resisting change. The industry is changing from desktop TO web-based. Your cherished MS, Apple, and Google agree with this as well, as you can see by their plans to not only support, but promote these types of applications. And, in this case, I can either follow the lead of Apple, MS, Google, and Mozilla, or take the advice of some nobody random commenter with a stick up his ass. Maybe you can explain how these companies are wrong?
jasonlotito 16y ago
> But I'd love a native client for Gmail even more. Email clients have been out for a long time. > Imagine Flickr on a tablet. Swiping, pinching, tapping. All of which can be accomplished without going native. These are accessible by normal web pages using JavaScript. > Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive. Facebook has native apps already, and they aren't any better. You can't find new messages, notifications not appearing properly are some of the problems I face. And you don't have to wait 30 minutes to have these problems. They appear before opening the app!
- algore 16y ago
  > Email clients have been out for a long time On the desktop, yes. Why? Because all the innovation in organizing, displaying, and managing email was focuses on webmail. Not because it was a better platform, but because it was incredibly easy to deploy and cheaper to develop. Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Used to be the same on the desktop when being online meant you were tying up a phone line at a per minute cost. Your desktop is always online now, so it's not an issue. But I still believe we will see a return to native email clients because of the integration possible with other client software and services. We already see it on tablets and phones.
  - jasonlotito 16y ago
    > Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Can still be accomplished without being native. Listen, it's clear we aren't going to agree. But the simple fact is, unless things change, going the JS and HTML route for apps is best for the vast majority of applications people use on a daily basis. This is demonstrated by the fact that they are using these apps on a daily basis.
    - algore 16y ago
      > This is demonstrated by the fact that they are using these apps on a daily basis That's not true. People are using apps on their phones, not webapps. They're using apps on their TVs and tablets, not webapps. And people are actually paying for native apps, something no one is doing for webapps. Seriously, you don't see any parallels between now and the late 90s? You don't think it's going to get drastically cheaper to produce native apps in the next couple years? The same thing happened in web development, a combination of better dev tools, more code libraries/frameworks, and more labor supply will drive costs down.

by algore 16y ago

jasongullickson 16y ago

Yeah I've never had a native/desktop app exhibit any of these behaviors...oh wait...

mgcross 16y ago

It seems to me that some of the issues you mention with web apps would also be apparent with native apps acting as a front-end to online apps. Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that. Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I don't doubt for a minute that the experience would be better for each platform as a native app, but would it be profitable for small/medium size business? I feel like SMBs are the target of web-based mobile frameworks, for the most part. I don't think we'll see Facebook in JQuery Mobile any time soon.

algore 16y ago
> Network transfers and latency can result in pauses and delays that would impact user experience more than choppy transitions, and native apps can't change that. Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform. > I feel like SMBs are the target of web-based mobile frameworks Sure, that's possible. But there are also people creating native frameworks to put SMBs into apps. Magazines are a good example. The big publishers are making their own apps, but they're are also working on frameworks to deliver other magazines. Then there are non-publishers like Zinio that are making the platform for any magazine to be published. > Is it worth the time and cost to create native front-ends for iOS, Android, BB, W7P? I'm not arguing that everyone who wants a blog needs to write their own blog software. No, obviously they can use something like Wordpress, and let WP worry about the programming and compatibility, and they can concentrate on content. Same goes for apps. I'm simply saying that native apps always were superior to webapps. People forgot because it became so easy and cheap to churn out functional web code. AND because these mobile client devices were closed off for development for so long. Love him or hate him, Jobs opened up everything with the iPhone SDK. I think the expectation of a company to have a native app today is equivalent to the expectation that they would have a website in 1997. Back then it was a very expensive proposition. Today EVERYONE has a website. Tomorrow everyone will have an app. Doesn't mean they have to hire their own software team to build it from scratch.
- jasonlotito 16y ago
  > Yes they can. Things can be pre-loaded in the background. Data can be queued. Storage can be local. I know you can find some package or framework somewhere that attempts to do these things in a web browser, but its all hacks. Stateless HTML is not a application development platform. I think you fail to realize this can be accomplished using the tools in the article. They have access to things like this, including cameras and what not. You keep saying things that make no sense in context.
  - algore 16y ago
    You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do. Why continue to struggle with a flawed platform? > You keep saying things that make no sense in context. In what context is that? I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong? Can you hack together a way to do all this in JS? Maybe, but it's unreliable, and it's years away from being comparable. Sure, you can wait 2 years until it's figured out, by then it will be outdated again anyway. I think you're very comfortable writing your web apps, it's something you understand and you're good at it, and naturally you're resisting change. But the industry is not going to stop changing because you're good at CSS hacks to make rounded corners on div blocks and you just wish we'd keep doing it that way because it's easy for you.
    - jasonlotito 16y ago
      > I'm looking around, I'm seeing movement by Microsoft, Apple, and Google to limited-purpose simplified computers with app stores built in. I'm seeing developers actually able to sell software again. I'm seeing rich, beautiful interfaces that are responsive and smooth. I'm seeing voice, camera, accelerometer, and GPS integration. And I'm seeing it in native software TODAY. It works now, it's not beta, and it's making money. Tell me where I'm wrong? Your not. However, I haven't argued against this. > You fail to realize that these "tools" are ugly hacks to make HTML do things it's clearly not well suited to do. Well, good thing they aren't using HTML then. > In what context is that? In the context of the article. PhoneGap let's you create native software but using technology like HTML and JS that hooks into Apple's (and others) existing API. More importantly, Apple uses XML for it's UI as well, so the difference between HTML and Apple's own XML format for it's UI is negligible. > and naturally you're resisting change. The industry is changing from desktop TO web-based. Your cherished MS, Apple, and Google agree with this as well, as you can see by their plans to not only support, but promote these types of applications. And, in this case, I can either follow the lead of Apple, MS, Google, and Mozilla, or take the advice of some nobody random commenter with a stick up his ass. Maybe you can explain how these companies are wrong?

jasonlotito 16y ago

> But I'd love a native client for Gmail even more. Email clients have been out for a long time. > Imagine Flickr on a tablet. Swiping, pinching, tapping. All of which can be accomplished without going native. These are accessible by normal web pages using JavaScript. > Try spending 30 minutes going through newsfeeds and photo albums without having the javascript go unresponsive. Facebook has native apps already, and they aren't any better. You can't find new messages, notifications not appearing properly are some of the problems I face. And you don't have to wait 30 minutes to have these problems. They appear before opening the app!

algore 16y ago
> Email clients have been out for a long time On the desktop, yes. Why? Because all the innovation in organizing, displaying, and managing email was focuses on webmail. Not because it was a better platform, but because it was incredibly easy to deploy and cheaper to develop. Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Used to be the same on the desktop when being online meant you were tying up a phone line at a per minute cost. Your desktop is always online now, so it's not an issue. But I still believe we will see a return to native email clients because of the integration possible with other client software and services. We already see it on tablets and phones.
- jasonlotito 16y ago
  > Where is the email client back? On the phone. People want access to their email if they don't have an internet connection. Can still be accomplished without being native. Listen, it's clear we aren't going to agree. But the simple fact is, unless things change, going the JS and HTML route for apps is best for the vast majority of applications people use on a daily basis. This is demonstrated by the fact that they are using these apps on a daily basis.
  - algore 16y ago
    > This is demonstrated by the fact that they are using these apps on a daily basis That's not true. People are using apps on their phones, not webapps. They're using apps on their TVs and tablets, not webapps. And people are actually paying for native apps, something no one is doing for webapps. Seriously, you don't see any parallels between now and the late 90s? You don't think it's going to get drastically cheaper to produce native apps in the next couple years? The same thing happened in web development, a combination of better dev tools, more code libraries/frameworks, and more labor supply will drive costs down.