[54mf]

"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."

[deanCommie]

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.

[mrlatinos]

This is also what I took from the article. Everything they're wanting to accomplish is certainly possible, but instead of just knowing the ins and outs of each platform, you have to know the ins and outs of each browser AND how each can affect the other browsers.

Beyond this, it is clear to me when an iOS-minded developer creates a web app that ends up on Android. Each have their own specific styles, and this gets lost with web apps.

[hatfieej]

What I thought the author was trying to say was that you can make a car that floats. It's just a much better understood problem to buy a car and a boat, then call it a day.

[stcredzero]

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.)

[bartof303]

The "condescending bullshit" is the title of the original post. I read the title "the fucking open web" and thought that 54mf's response was pretty diplomatic in comparison.

[baddox]

> and the only web devs that know the ins and outs of every browser enough to make it work are unaffordable and unavailable.

Really? More unaffordable and unavailable than at least one native developer for each platform you're targeting? I find that hard to believe.

[tracker1]

I'm available... and semi-actively looking... ;-) But I'm not cheap. That said, I provide great value.

I've been writing web based applications for about 20 years now. It's a lot better than it was in the late 90's and early 2000's, so stop bitching or get off the lawn. (sarcasm) Seriously though, I'd much rather deal with webpack, babel, react, redux and the like than angular 1&2 (just feels like a decade old solution now), and heaven forbid having to ever look at an <ILayer> again, or breaking up forms dynamically in the v4 browsers.

Yes, there are a few features not broadly supported, but there is also tooling that makes web dev as good, and in some ways better than app dev (though less than natural, and all out performance on a complex app is hard)... all of that said, it's a VERY valid option for many/most sites/applications.

[dave2000]

> Nobody is arguing these things CAN'T be done, just that > it's too much effort on the web,

They're saying it shouldn't be done, or that it's possible and if you can't do it you're a lame developer. I didn't see it as condescending at all.

[hnal943]

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]

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."

[Dr_tldr]

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.

[dave2000]

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.

[kurttheviking]

> "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]

Can't a UI be designed such that minor fontsize differences aren't a disaster?

[MichaelGG]

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

[stouset]

> 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.

[ksk]

>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.

[briandear]

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]

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.

[diminish]

>> 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.

[kartan]

> 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.

[serge2k]

> 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]

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]

It seems doable https://developer.mozilla.org/en-US/docs/Web/Security/Securi...

[dzolvd]

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.

[st3v3r]

""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?

[Scarblac]

> 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.