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

[LnxPrgr3]

Not to mention the effect of time. The Web is not a stable application environment, and you may get caught in limbo, where the old way to do something is technically deprecated, but only one browser implements the new scheme, and only in nightly builds and even then only if you launch with --please-segfault-hourly. But using the deprecated API means at some arbitrary point in the future your working code will stop working.

[asadotzler]

The Web rarely deprecates features. Browsers still have to display the Web of 1995.

[LnxPrgr3]

How about the Web of 2012?

WebSockets changed wire formats multiple times before we settled on something. Last I checked, the API still isn't final, and changes in browser behavior forced a project I was on to abandon it for socket.io. Web Audio has been through at least one breaking rewrite since 2012, and still isn't finalized.

Sure, '<h1>' still gets me a big, bold heading (probably, subject to CSS), but playing a sound file without plugins is still bleeding edge, and subject to arbitrary breakage. But we've broken plugins (for the best, eventually), so the old solution to that problem no longer reliably works.

[dragonwriter]

> The Web rarely deprecates features.

No, it rarely removes deprecated features.

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

[tracker1]

"If you have a ship that can carry a tank, why not just put guns on the ship?"

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

[StefanKarpinski]

Which is why it's cheaper to build multiple native apps... which was the point of the article.

[stcredzero]

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]

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.

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

[sievebrain]

Ye gods people.

The entire article is saying "I used to believe it was too expensive to do native apps so we did web, I now believe I was wrong, even though it may seem cheaper at first the costs of the web are far less predictable and it's now economically better to just do native apps"

[baddox]

But the author didn't actually compare the difficulties and costs of web development to native development. The article just lists a bunch of (debatably valid) difficulties of web development. But most (all?) software development has difficulties and annoyances.

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

[fixermark]

But do you provide an amount of value that offsets the cost of two or three completely-adequate devs working in parallel on mobile apps? ;)

That's the killer.

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

[st3v3r]

I read it as entirely condescending. The several "It's your fault" replies? Nothing but condescension.

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

[dave2000]

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]

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

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.

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

[pier25]

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.

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

[Someone1234]

Yes. But the article paints the picture that these weren't minor font size differences.

[rhizome]

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

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

[ptx]

It is actually a feature, called "font inflation"[1], that tries to find the main content text on a site not designed for mobile and make it a readable size. It just wasn't doing a good job figuring out which parts were the content.

I would guess the recent improvement is due to the site itself being fixed – it now uses a "viewport" meta tag, which I don't think it did last year.

[1] http://www.jwir3.com/font-inflation-fennec-and-you/

[fixermark]

Yep. Features like this are basically why developing tightly-controlled UI experiences on the web are a garbage fire.

For a tightly-controlled UI experience, you want a thin, predictable framework that you can build your experience on top of. The web is the opposite of that. Big, big chunks of important detail for user experience are not specified in the RFCs and standards themselves.

Take CSS as an example. The first thing most web development frameworks will have you load is a CSS that sets the style for everything to some known defaults. If the web as an app development framework had been designed for a controllable experience, that would be unnecessary. But the web wasn't designed as an app development framework; it was designed as a heavily user-configurable presentation layer for standardized format of content.

[IanCal]

While I generally agree, I'm not surprised mobile browsers did weird things with HN. Look at the source, it's nested tables with expanded invisible 1 pixel gifs used for indentation.

[MichaelGG]

I've not designed HTML since the early 2000s but that was an easy, workable, way to do layout then and should still work now. HTML takes are just weird and require tricks like that to work. I understand the current preferred way is creating a grid via CSS.

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