5 ms·

"You want mobile notifications? Sure, but not on mobile Safari." You can do this with PhoneGap. "Multiple line ellipsis? Sure, but only on webkit." Okay, yea

by 54mf 10y ago

"You want mobile notifications? Sure, but not on mobile Safari." You can do this with PhoneGap. "Multiple line ellipsis? Sure, but only on webkit." Okay, yeah, this sucks. "Consistent rendering size across browsers? Just fuck off." This is probably your fault. "We fix a layout bug on Safari and break something on Edge." This is probably your fault. "We change font size on Chrome and now all you can see on Firefox is the letter F." This is probably your fault. "How about hiding the address bar or controlling swipes from the left edge of the screen? Don’t be stupid." Stop trying to make the browser not a browser. Users hate when you hijack expected behavior. (See: Imgur.) "Oh, and don’t get me started on all these new custom mobile keyboards you can use and how autocomplete can fuck with your input box events." You can disable autocomplete. Did you mean predictive word suggestions? TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose."

hnal943 10y ago
This is probably your fault That's the point of the article. Getting these things right on the web is non-trivial (and therefore expensive).
- squeaky-clean 10y ago
  Ehhh.... These examples seem really amateurish to me. You'll run into lots of issues developing for the web, sure, it's not perfect. Especially web "apps" that need to work cross-browser. But the listed problems stem from not understanding your platform, not problems inherent to the web itself. To make an analogy, it's like the equivalent writing a native app where input and UI rendering are handled by the same thread, and then complaining that input doesn't work during intensive operations, so javascript / the web is better for apps, and native is terrible. It's also an unfair comparison. These statements: > We made a bet on the web. Built a responsive site for desktop and mobile and tried to avoid the native app space (still are). And then later > One app for iOS, one for Android, and I got over 90% consumer coverage. I can even use a framework to share work between the two. So originally with the web, they're trying to target Desktop Chrome, Desktop Safari, Desktop Firefox, Desktop Edge, Mobile Chrome and Mobile Safari with one codebase. Then they move to only targeting Android and iOS (native mobile only) with two separate codebases? They could have just as easily targeted mobile Chrome and mobile Safari, and shared 100% of the code. I'm not sure what they mean by a framework to share work between the two. If they're referring to something like Xamarin, I hope they've at least tried it before assuming everything works great. They're very unstable, and you still need separate codebases for your views, typically more. Ironically, the most stable ones of these I've tried have been web-dev based frameworks. tl;dr: "It's cheaper to make an app for 2 platforms than for 8 you don't understand."
  - dave2000 10y ago
    I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction? Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.
    - squeaky-clean 10y ago
      > I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction? You generally only have to write it once. But you've gotta write it right. The other attractions are no installs, just visit a web page. No users with "out of date" clients, you just serve the updated page to users. A sandboxed environment to run in. Ease of sharing (URLs). The DOM, while slow, is also rather nice if your layout model resembles documents. There's a million reasons why web might be the better choice. There's also a million reasons to prefer native. > Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it. Usually these are showing off new features available in the browser that weren't present before. And they can do a hell of a lot more than let you interact with it in some limited way, or move an object. How about an entire 3d Modeling Application in your browser? (Warning may lag a mobile device or slow PC) http://www.3dtin.com/ http://www.3dtin.com/ But these are crazy, cutting-edge things that are still best done natively. Most of the time you're not making a 3d Modeling application. 99% of the time an "app" is something that shows text and images, and takes text (and sometimes images) from the user. You can make it super flashy, and that's where a native app would excel. But does it really need to be flashy? Does a cruise line's ticket booking app really need to show water flowing across the screen while you load the next page, and a tugboat pulling in prices? Or are these gimmicks that will just end up pissing off the user? I guess I really just disagree with the blanket statements by the author. Native probably was a better call for their app, but they don't focus on why. Just that web supposedly sucks... Instead of learning the strong suites of web and native, and why they thought web worked for their app but it didn't, they've "learned" to not touch the web. Which I think is the wrong lesson.
- dave2000 10y ago
  That's because the web is a terrible platform to develop for - because it's essentially a text-with-graphics platform with about 20 million different extensions, standards and so on to deal with. So the choices are: 1) deal with it 2) pick a better platform 3) try and come up with a new platform which is broswer-like but where there is predictable, obvious behaviour on multiple implementations of the platform, and where the platform supports, out of the box, all the sorts of functionality you'd like for a modern app. If your platform is missing any of the APIs you have available on, say, Android or ios you're going to struggle to make a web app as rich as, say, google maps, or whatever. I'd for for 3 but I guess it's hard because all the people who care are too busy trying to keep up with which framework to use, or centering text, or whatever.
- Dr_tldr 10y ago
  For a totally new project, especially with React and React Native, it's not trivial to get things right, but it's not that hard either. Technically it's not "one app", but if you build them in parallel and you know what you're doing, 90% of the codebase can be shared. The author is putting forth a false dichotomy between "write one web app that works on everything" and "write a new app from scratch for every platform." The right answer in 2016 is a hybrid approach.
  - pier25 10y ago
    Couldn't agree more. We are building a product that runs on iOS, Android, Web, Desktop (using Electron) and Chrome OS, with Firebase, React, and React Native. A lot of code is shared among all platforms.
deanCommie 10y ago
Did we read the same article? What is this condescending bullshit. Nobody is arguing these things CAN'T be done, just that it's too much effort on the web, and the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.
- stcredzero 10y ago
  the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable. The market has spoken. Doing those things is hard enough, people can charge lots for it. That sucks. "Sucks" == suffering. Suffering == opportunity. (Deliberate Yodaism. Actually high market price == market opportunity.)
  - StefanKarpinski 10y ago
    Which is why it's cheaper to build multiple native apps... which was the point of the article.
    - stcredzero 10y ago
      You seem to be laboring under the false impression that I'm disagreeing with the article. I'm agreeing with the article. I'm also pointing out that this situation would indicate there's a market opportunity somewhere. (In the words of Jeff Bezos: Your margin is my opportunity.)
      - djsumdog 10y ago
        There are a lot of those little frameworks that try and bridge all this together: PhoneGap, Titanium, etc. They're all varying levels of terrible (unless you want to make games, in which case Unity mobile is a pretty solid bet). So there is a market, people are trying to fill those gaps, and yet none of them seem to be able to bridge the gap in such a way that devs prefer maintaining two or more native apps over one that compiles for multiple devices with a common framework. So there is a market, but it doesn't look like it's an easy problem to solve.
dzolvd 10y ago
This. +1 for PhoneGap, we are sharing a single codebase between a mobile web interface, iOS app, and android app and have managed to keep it fairly clean.
kartan 10y ago
> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." Complete agree on this, and I think that it is the most important point here. It's similar to the when people try to code in one language and complains that doesn't behaves like the one that they are used to. Browsers are designed for a function, or a lot of them, force your design ignoring web needs is going to produce a buggy hard to maintain software.
kurttheviking 10y ago
> "Consistent rendering size across browsers? Just fuck off." > This is probably your fault. As someone who has spent an embarrassing amount of time debugging kerning differences, line spacing, and obscure letter size differences across IE/Firefox/Chrome I can enthusiastically say, it might be his fault but I doubt it. Different browsers do things differently and in cases where things must be the same, this is an expensive and time-consuming problem.
- rhizome 10y ago
  Can't a UI be designed such that minor fontsize differences aren't a disaster?
  - Someone1234 10y ago
    Yes. But the article paints the picture that these weren't minor font size differences.
    - rhizome 10y ago
      "We change font size on Chrome and now all you can see on Firefox is the letter F." They're doing something funky. They can call it a "2016 website" but the problems described in the article don't really make sense to me as anything but design-related. Now, I know that you can't design your way out of every problem, but if they're going to use IE6 as a hellmouth and not IE8, they may be using a greater number of bad practices than necessary.
- MichaelGG 10y ago
  For a while, Firefox mobile would render different parts of HN's text in different sizes. At first I thought it was a mobile-only feature, but that would be odd for HN to do. Nope, turns out it was a Firefox table-something layout font issue. Seems fixed as of, perhaps 6 months ago? Searching around also finds this answer pointing to a now-dead link saying Chrome used to have known issues with "consistent" fonts on sites like Reddit. http://stackoverflow.com/a/19988987/27012 http://stackoverflow.com/a/19988987/27012
ksk 10y ago
>This is probably your fault. I wonder if it is more arrogant to claim that things are broken or to tell someone its their fault without even knowing what they're trying to do.
stouset 10y ago
> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." That's literally his entire thesis. There's been a ton of effort invested in trying to make web apps capable of competing with native apps, and his point is that it's still simply just not feasible. It's cheaper — and more importantly, costs are more predictable — to develop a native app for every platform you want to support, than to develop a single modern webapp of equivalent quality.
briandear 10y ago
PhoneGap? I thought the point was the original author didn't want to ship shit. PhoneGap apps are generally terrible. PhoneGap is the preferred solution for CIOs that want to save money but end up delivering a glitchy crap product. JavaScript isn't the catch all savior many JS people seem to think it is. CSS and JS animations are children's toys compared to Metal on iOS. You can make a far more beautiful and smooth experience with native apps than anything ever done on PhoneGap. You want access to a new iOS API on PhoneGap? You have to wait until it's public. If you want to upgrade your app for iOS 10? You have to wait until iOS 10 is publicly released. Anyone using PhoneGap is almost certainly someone who is unwilling to learn Swift. Nobody actually thinks PhoneGap is better.. It's just a convenient crutch for those who are unwilling to invest the time to do it right. If you have to ship a mobile app because of some executive vanity for a mobile app-- go ahead use PhoneGap. But if you actually want to write the best app possible, delivering a great user experience (as well as device experience,) then learn the real thing. Also, you missed the point of the article -- obviously the problems are 'his fault.' The point is that all of those problems are more painful than simply building a great mobile app.
- r2dnb 10y ago
  The issue with your comment is that it is based on the idea that supporting a platform is the goal. As per your value metrics, the more platform-rich the experience is, the better it is. This is however not how business works and not how businesses work because it is not what they need. What they need is to transfer value to move their business forward. It is also the only thing they (should) want. Full Android or iOS support is not what smart business leaders aim, I would tend to say it is the opposite. I don't care for 1 second about the Metal/Swift you talk about when I can have people get their credit card out with an HTML page without CSS.
Scarblac 10y ago
> Stop trying to make the browser not a browser. Users hate when you hijack expected behavior. Another point against making web apps: users have stricter expectations about them.
diminish 10y ago
>> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." The first wave of designers who targeted print had the same trouble native app designers had and ended up building big blobs of flash applications. Native app devs moving the responsive web route face similar troubles. I guess they can alleviate most of the cross platform, multiple screen and accessibility compatibility by relying on a framework. In the mean a lot of native apps lack support for accessibility, multiple font sizes, and color schemes, ability of bookmarking a certain screen, ability of moving back and forth between screens, ability to open multiple pages (or screens) at the same time, better caching when mobile and offline, a way to hyper link within or across apps, support for various screen sizes from large to very small. So it could be better the native-to-web refugee to focus on the advantages of the plain old web which apps lacked.
serge2k 10y ago
> You can disable autocomplete You can, but it makes you pretty much the literal devil. Don't disable my autocomplete. > TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." It makes him grumpy because he can't get users what they want.
djsumdog 10y ago
You can't disable auto-complete in a web app (or can you? If so, I'm sure it's different for each platform). We're not just talking about iOS and Android. You've got Chrome mobile, the ASOP browser, Firefox mobile, whatever shitty browser the carrier wants to include and all the various versions of those that will never get upgraded. Personally, I really like the ranty tone of this article. I don't think it's unjustified at all. The author's frustrations are very valid.
- Keats 10y ago
  It seems doable https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion https://developer.mozilla.org/en-US/docs/Web/Security/Securi...
st3v3r 10y ago
""Consistent rendering size across browsers? Just fuck off." This is probably your fault. "We fix a layout bug on Safari and break something on Edge." This is probably your fault. "We change font size on Chrome and now all you can see on Firefox is the letter F." This is probably your fault." Seriously, that's your answer? There are problems, and your response is to blame the user, rather than admit that these are problems that simply should not exist?

by 54mf 10y ago

hnal943 10y ago

This is probably your fault That's the point of the article. Getting these things right on the web is non-trivial (and therefore expensive).

squeaky-clean 10y ago
Ehhh.... These examples seem really amateurish to me. You'll run into lots of issues developing for the web, sure, it's not perfect. Especially web "apps" that need to work cross-browser. But the listed problems stem from not understanding your platform, not problems inherent to the web itself. To make an analogy, it's like the equivalent writing a native app where input and UI rendering are handled by the same thread, and then complaining that input doesn't work during intensive operations, so javascript / the web is better for apps, and native is terrible. It's also an unfair comparison. These statements: > We made a bet on the web. Built a responsive site for desktop and mobile and tried to avoid the native app space (still are). And then later > One app for iOS, one for Android, and I got over 90% consumer coverage. I can even use a framework to share work between the two. So originally with the web, they're trying to target Desktop Chrome, Desktop Safari, Desktop Firefox, Desktop Edge, Mobile Chrome and Mobile Safari with one codebase. Then they move to only targeting Android and iOS (native mobile only) with two separate codebases? They could have just as easily targeted mobile Chrome and mobile Safari, and shared 100% of the code. I'm not sure what they mean by a framework to share work between the two. If they're referring to something like Xamarin, I hope they've at least tried it before assuming everything works great. They're very unstable, and you still need separate codebases for your views, typically more. Ironically, the most stable ones of these I've tried have been web-dev based frameworks. tl;dr: "It's cheaper to make an app for 2 platforms than for 8 you don't understand."
- dave2000 10y ago
  I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction? Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it.
  - squeaky-clean 10y ago
    > I thought the attraction of web development was that you just write something once and it works on all browsers. If you have to write it 8 times then what's the attraction? You generally only have to write it once. But you've gotta write it right. The other attractions are no installs, just visit a web page. No users with "out of date" clients, you just serve the updated page to users. A sandboxed environment to run in. Ease of sharing (URLs). The DOM, while slow, is also rather nice if your layout model resembles documents. There's a million reasons why web might be the better choice. There's also a million reasons to prefer native. > Often people show me "tech demos", by which they apparently mean something you'd never bother to show anyone else if it was an app or a game, but because it's running in a browser window and because it doesn't look like yet another shitty website (because it has something that moves, or which you can interact with in some limited way) it's supposed to somehow impress me. I don't get it. Usually these are showing off new features available in the browser that weren't present before. And they can do a hell of a lot more than let you interact with it in some limited way, or move an object. How about an entire 3d Modeling Application in your browser? (Warning may lag a mobile device or slow PC) http://www.3dtin.com/ http://www.3dtin.com/ But these are crazy, cutting-edge things that are still best done natively. Most of the time you're not making a 3d Modeling application. 99% of the time an "app" is something that shows text and images, and takes text (and sometimes images) from the user. You can make it super flashy, and that's where a native app would excel. But does it really need to be flashy? Does a cruise line's ticket booking app really need to show water flowing across the screen while you load the next page, and a tugboat pulling in prices? Or are these gimmicks that will just end up pissing off the user? I guess I really just disagree with the blanket statements by the author. Native probably was a better call for their app, but they don't focus on why. Just that web supposedly sucks... Instead of learning the strong suites of web and native, and why they thought web worked for their app but it didn't, they've "learned" to not touch the web. Which I think is the wrong lesson.
dave2000 10y ago
That's because the web is a terrible platform to develop for - because it's essentially a text-with-graphics platform with about 20 million different extensions, standards and so on to deal with. So the choices are: 1) deal with it 2) pick a better platform 3) try and come up with a new platform which is broswer-like but where there is predictable, obvious behaviour on multiple implementations of the platform, and where the platform supports, out of the box, all the sorts of functionality you'd like for a modern app. If your platform is missing any of the APIs you have available on, say, Android or ios you're going to struggle to make a web app as rich as, say, google maps, or whatever. I'd for for 3 but I guess it's hard because all the people who care are too busy trying to keep up with which framework to use, or centering text, or whatever.
Dr_tldr 10y ago
For a totally new project, especially with React and React Native, it's not trivial to get things right, but it's not that hard either. Technically it's not "one app", but if you build them in parallel and you know what you're doing, 90% of the codebase can be shared. The author is putting forth a false dichotomy between "write one web app that works on everything" and "write a new app from scratch for every platform." The right answer in 2016 is a hybrid approach.
- pier25 10y ago
  Couldn't agree more. We are building a product that runs on iOS, Android, Web, Desktop (using Electron) and Chrome OS, with Firebase, React, and React Native. A lot of code is shared among all platforms.

deanCommie 10y ago

Did we read the same article? What is this condescending bullshit. Nobody is arguing these things CAN'T be done, just that it's too much effort on the web, and the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.

stcredzero 10y ago
the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable. The market has spoken. Doing those things is hard enough, people can charge lots for it. That sucks. "Sucks" == suffering. Suffering == opportunity. (Deliberate Yodaism. Actually high market price == market opportunity.)
- StefanKarpinski 10y ago
  Which is why it's cheaper to build multiple native apps... which was the point of the article.
  - stcredzero 10y ago
    You seem to be laboring under the false impression that I'm disagreeing with the article. I'm agreeing with the article. I'm also pointing out that this situation would indicate there's a market opportunity somewhere. (In the words of Jeff Bezos: Your margin is my opportunity.)
    - djsumdog 10y ago
      There are a lot of those little frameworks that try and bridge all this together: PhoneGap, Titanium, etc. They're all varying levels of terrible (unless you want to make games, in which case Unity mobile is a pretty solid bet). So there is a market, people are trying to fill those gaps, and yet none of them seem to be able to bridge the gap in such a way that devs prefer maintaining two or more native apps over one that compiles for multiple devices with a common framework. So there is a market, but it doesn't look like it's an easy problem to solve.

dzolvd 10y ago

This. +1 for PhoneGap, we are sharing a single codebase between a mobile web interface, iOS app, and android app and have managed to keep it fairly clean.

kartan 10y ago

> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." Complete agree on this, and I think that it is the most important point here. It's similar to the when people try to code in one language and complains that doesn't behaves like the one that they are used to. Browsers are designed for a function, or a lot of them, force your design ignoring web needs is going to produce a buggy hard to maintain software.

kurttheviking 10y ago

> "Consistent rendering size across browsers? Just fuck off." > This is probably your fault. As someone who has spent an embarrassing amount of time debugging kerning differences, line spacing, and obscure letter size differences across IE/Firefox/Chrome I can enthusiastically say, it might be his fault but I doubt it. Different browsers do things differently and in cases where things must be the same, this is an expensive and time-consuming problem.

rhizome 10y ago
Can't a UI be designed such that minor fontsize differences aren't a disaster?
- Someone1234 10y ago
  Yes. But the article paints the picture that these weren't minor font size differences.
  - rhizome 10y ago
    "We change font size on Chrome and now all you can see on Firefox is the letter F." They're doing something funky. They can call it a "2016 website" but the problems described in the article don't really make sense to me as anything but design-related. Now, I know that you can't design your way out of every problem, but if they're going to use IE6 as a hellmouth and not IE8, they may be using a greater number of bad practices than necessary.
MichaelGG 10y ago
For a while, Firefox mobile would render different parts of HN's text in different sizes. At first I thought it was a mobile-only feature, but that would be odd for HN to do. Nope, turns out it was a Firefox table-something layout font issue. Seems fixed as of, perhaps 6 months ago? Searching around also finds this answer pointing to a now-dead link saying Chrome used to have known issues with "consistent" fonts on sites like Reddit. http://stackoverflow.com/a/19988987/27012 http://stackoverflow.com/a/19988987/27012

ksk 10y ago

>This is probably your fault. I wonder if it is more arrogant to claim that things are broken or to tell someone its their fault without even knowing what they're trying to do.

stouset 10y ago

> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." That's literally his entire thesis. There's been a ton of effort invested in trying to make web apps capable of competing with native apps, and his point is that it's still simply just not feasible. It's cheaper — and more importantly, costs are more predictable — to develop a native app for every platform you want to support, than to develop a single modern webapp of equivalent quality.

briandear 10y ago

PhoneGap? I thought the point was the original author didn't want to ship shit. PhoneGap apps are generally terrible. PhoneGap is the preferred solution for CIOs that want to save money but end up delivering a glitchy crap product. JavaScript isn't the catch all savior many JS people seem to think it is. CSS and JS animations are children's toys compared to Metal on iOS. You can make a far more beautiful and smooth experience with native apps than anything ever done on PhoneGap. You want access to a new iOS API on PhoneGap? You have to wait until it's public. If you want to upgrade your app for iOS 10? You have to wait until iOS 10 is publicly released. Anyone using PhoneGap is almost certainly someone who is unwilling to learn Swift. Nobody actually thinks PhoneGap is better.. It's just a convenient crutch for those who are unwilling to invest the time to do it right. If you have to ship a mobile app because of some executive vanity for a mobile app-- go ahead use PhoneGap. But if you actually want to write the best app possible, delivering a great user experience (as well as device experience,) then learn the real thing. Also, you missed the point of the article -- obviously the problems are 'his fault.' The point is that all of those problems are more painful than simply building a great mobile app.

r2dnb 10y ago
The issue with your comment is that it is based on the idea that supporting a platform is the goal. As per your value metrics, the more platform-rich the experience is, the better it is. This is however not how business works and not how businesses work because it is not what they need. What they need is to transfer value to move their business forward. It is also the only thing they (should) want. Full Android or iOS support is not what smart business leaders aim, I would tend to say it is the opposite. I don't care for 1 second about the Metal/Swift you talk about when I can have people get their credit card out with an HTML page without CSS.

Scarblac 10y ago

> Stop trying to make the browser not a browser. Users hate when you hijack expected behavior. Another point against making web apps: users have stricter expectations about them.

diminish 10y ago

>> TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." The first wave of designers who targeted print had the same trouble native app designers had and ended up building big blobs of flash applications. Native app devs moving the responsive web route face similar troubles. I guess they can alleviate most of the cross platform, multiple screen and accessibility compatibility by relying on a framework. In the mean a lot of native apps lack support for accessibility, multiple font sizes, and color schemes, ability of bookmarking a certain screen, ability of moving back and forth between screens, ability to open multiple pages (or screens) at the same time, better caching when mobile and offline, a way to hyper link within or across apps, support for various screen sizes from large to very small. So it could be better the native-to-web refugee to focus on the advantages of the plain old web which apps lacked.

serge2k 10y ago

> You can disable autocomplete You can, but it makes you pretty much the literal devil. Don't disable my autocomplete. > TL;DR: "We tried to make a responsive web app act like a native app and it didn't work because it doesn't work, and that makes me a grumpy goose." It makes him grumpy because he can't get users what they want.

djsumdog 10y ago

You can't disable auto-complete in a web app (or can you? If so, I'm sure it's different for each platform). We're not just talking about iOS and Android. You've got Chrome mobile, the ASOP browser, Firefox mobile, whatever shitty browser the carrier wants to include and all the various versions of those that will never get upgraded. Personally, I really like the ranty tone of this article. I don't think it's unjustified at all. The author's frustrations are very valid.

Keats 10y ago
It seems doable https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion https://developer.mozilla.org/en-US/docs/Web/Security/Securi...

st3v3r 10y ago

""Consistent rendering size across browsers? Just fuck off." This is probably your fault. "We fix a layout bug on Safari and break something on Edge." This is probably your fault. "We change font size on Chrome and now all you can see on Firefox is the letter F." This is probably your fault." Seriously, that's your answer? There are problems, and your response is to blame the user, rather than admit that these are problems that simply should not exist?