If you take a look at Meeker's 2016 Internet trends report that came out last week, you will see that 3 apps dominate 80% of the usage on phones. I decided when I started my food side project a year back, that I was not going to do a native app.
I have been trying to make the front end look better, but I did not want to use very heavy frameworks, so I settled on using the SASS mixin library Bourbon.io along with the grid and a few others the company provides.
The css that is produces is very tight, and I can save on developer costs. I should say, save on finding another front end developer as the one I was using took some money and ran.
I don't really see how user time-share is relevant unless your goal is to start a social network/messaging system.
80% of user time is spent in those 3 apps, that doesn't preclude very profitable apps from being developed. After all, people spend 16+ hours a day at home/work, but there are still plenty of reasons to open restaurants. Unless you profit directly from time-spent-in-app this doesn't seem like a consequential measurement.
See: Uber, pretty low on the charts for time-in-app but yet a massive business. Ditto Amazon, or GrubHub, or any number of other apps that deliver value to their users (and revenue to their owners) without long sessions.
Totally agree. The most money I've ever spent is on Tasker and AutoApps family of Tasker plugins, and I rarely even open them - they're the ultimate background apps, but they work, they work well, and they're very much worth the money I paid.
There is going to be some reluctance to download a new app. If you can get tons of VC money, and you can pour it into marketing, you can get people to download your app.
But I think user adoption is just that much easier if all they have to do is open up your mobile web app in their phones browser. You could always build the app later after you have gotten the traction and growth.
sass+bourbon.io (or similar combos like sass+compass) can help a TON with keep front-end dev costs down.
Some apps do benefit a lot being native, but as others point out you throw in the middleman app-store model instead of just dealing with the browser, and keeping your UI simple, clean, efficient and of-course usable.
Agree, but have you ever built a responsive drag and drop document builder? Anytime you start getting into mobile-specific UX on a responsive web page, it often becomes and unpredictable mess. Parallax scrolling isn't the best example, but it is a good illustration. Parallax on mobile browsers historically has been pretty glitchy and horrible. When a similar kind of UX interaction that's actually a necessary part of the app is done in responsive, it's generally very hard.
Really the problem with mobile web seems to be JavaScript.
Agree, but have you ever built a responsive drag and drop document builder? Anytime you start getting into mobile-specific UX on a responsive web page, it often becomes and unpredictable mess. Parallax scrolling isn't the best example, but it is a good illustration. Parallax on mobile browsers historically has been pretty glitchy and horrible. When a similar kind of UX interaction that's actually a necessary part of the app is done in responsive, it's generally very hard.
Really the problem with mobile web seems to be JavaScript.
Although a rant, this is also pretty substantive. We've replaced the baity title with a representative sentence from the article in the hope that commenters will follow suit.
I just check a couple times a day... honestly, I'm usually too busy when I'm not checking HN to deal with a reply right at any given moment anyway. It's a forum.
Dunno, I'd be okay with web notifications via chrome.
Though that some clickbait sites are asking for that permission is really irritating... I mean more so than interstitial or late-loading ads that push content down.
I use hnnotify to tell me about replies and the Hacker News app on iOS by premii is pretty decent for read only access ( I mostly only post when I'm at a computer, I find that my responses make a little more sense that way :) )
Kind of wish HN would adapt Open* or similar for token access for posting... though that opens the door to a lot of potential issues (spam) I'm guessing they're trying to avoid... maybe requiring the web interface until you hit 1K karma or something.
Worrying about spam doesn't make much sense here, as the web interface is pure HTML forms, with no client-side checks. It isn't hard to automate the posting process.
Fuckity fuck fuck <what the title said> fuck you, and shut the fuck up, dear reader. More fuckity fuck because the author has a keyboard macro that expands "," to "fuck".
I don't know, I thought it was pretty much a waste of my time. Read the top of the page you're looking at right now, read my first sentence. There, saved you a few minutes.
1. The cost of building an app can be calculated in the back of a napkin. The cost of a web app that works consistently across devices? Not so much.
2. The cost of building backend services has been commoditised to a degree. Front end web development? Its downright hard finding someone that can do good front end web work.
3. The reality that big companies (silos) will push their agenda over anything else and win.
If the idea of the cost of an android app is will it work fine on a Samsung galaxy 1 behind the current gen then sure a napkin will work.
I feel like doing anything non trivial for Android with a wide target audience is not always any more reliable than the Web experience claimed in the article
Android definitely has issues. But its simpler than browsers. I'm not saying people should abandon browsers. Not at all. My point is that the browser gets treated poorly and web standards are simply ignored. Ultimately we end up with a web that is broken or missing.
To your second point... many companies are only paying lip service to finding someone good... I price myself out of the majority of jobs I'm approached about, and consider myself in the top few percent on front end web development (JS in general).
> The cost of a web app that works consistently across devices?
To me the problem is right here: why must every web app work on all devices? And why, if you build an iOS app do you have to build one for Android too?
If you're a small business, getting your first 50k, 100k, 200k customers is what matters. You can do this more effectively at lower cost by focusing on just one platform / browser / environment.
"To me the problem is right here: why must every web app work on all devices?"
Because users want them to. If your web app doesn't work on their device, they're going to leave and use something else. The days of people being tied to their laptops is over.
"And why, if you build an iOS app do you have to build one for Android too?"
You don't have to, but if you want success, it's probably best to try and reach as many people as possible. And there are more Android users than iOS users.
> The cost of a web app that works consistently across devices?
To me the problem is right here: why must every web app work on all devices? And why, if you build an iOS app do you have to build one for Android too?
If you're a small business, getting your first 50k, 100k, 200k customers is what matters. You can do this more effectively at lower cost by focusing on just one platform / browser / environment.
I don't know about that. The word "web" is used far more often in that article than any swear word, and "build" is used precisely as often. Yet there are no comments complaining about those words, and I feel pretty sure there wouldn't be even if the swearing were omitted. It seems like it's the swearing that people object to.
I object to swearing. I believe it's a very inefficient way to convey meaning, especially in a technical context, where it may make it actually harder to follow the line of thought. In addition, in some contexts (e.g. socially conservative environments), it could potentially be offensive to some people, and I generally think it's not worth to offend people unless there is a reason for it. It may be argued that some swear words are particularly good at transferring connotative meaning, but then the English language is rich enough that you can find other ways to do so.
Substantive but not new and something that could have been said in much fewer words. If the baity title had been left alone I would have been saved a waste of time.
"One app for iOS, one for Android, and I got over 90% consumer coverage"
What's the consumer coverage for Mobile Chrome + Mobile Safari? Giving up on total cross-browser compatibility doesn't have to mean writing native apps.
The coverage is probably pretty high, but you're limited by each browsers respective feature set. There may be functionality that you can't ship due to limits on multiple browsers. Other issues arise if you factor in sites which needs to take into account all browsers; You'll end up bloating your JS/CSS to handle all of these conditions impacting mobile page size. It can be done, if the product is fairly simple, but problems arise as you increase your products complexity and feature set. Native apps have their own set of problems with distribution and the web has it's own set of problems with performance and hardware API access.
Potentially, although I think that there are cases when it's fine. For example when I lived in San Francisco, my LTE speeds were insanely fast so it wasn't as big of a deal. Now that I'm in Pittsburgh, the LTE speeds here aren't as good so mobile web isn't as good.
Also on a desktop or laptop where you've got a good Wi-Fi connection most websites are really good. That being said, I still things like Tweetbot, Flume, and Airmail over twitter.com, instagram.com or gmail.com.
Ehhhh, I really haven't had these issues with any of the meteor apps I've made. Even getting swiping and full page animation transitions has been relatively simple. My experience is anecdotal, but I actually left being android developer to do mobile web and I've found the experience to be far easier.
Easier, yes. The tools for web development are awesome and amazing, but there's so many restrictions and limitations that come with the web. Maybe the web is the way forward, but native will be kicking its ass (regarding experience) for a long time.
Similar experience here using Meteor + Ionic, exported with Cordova. I also feel like the skills I'm developing in web development are much more widely applicable than learning a particular mobile OS.
Exactly this. I guess for people who have built their careers building mobile apps they couldn't care less about more rounded skills(in relation to web at least), its mostly full stack/back-end devs who know JS seem to state this. Not that there is anything wrong with that.
(note: I've met Eran a few times, he is very smart and I respect his opinion)
Note aside: this is one of those "it really depends" kind of situations. For many cases native apps are always going to be cheaper to build. For others the web is just much better. It seems like the problem Eran is describing is more of a labor shortage. It's really, really difficult to hire good web developers. I have no idea why this is.
When you multiply that 90% consumer coverage by the percentage of people who will install your app when you ask them to, it's going to knock down your 90% pretty considerably.
For users, I'm not sure how this is significantly worse than asking people to visit your mobile website. In my personal experience, people will search the app store for your mobile web application by default anyway.
If your product is an "app" in the functionality sense, then people are going to look for it in the "app store". Period. For user, it's actually a better experience than using Chrome/Safari.
I agree. Personally, I consciously avoid anything that smells of webapp and consider this to be a product of a lazy-ass company. Non-native applications pretty much universally suck, and it only shows that the quality/usefulness is not a goal.
What about developing a core codebase to build an app for different platforms (including the web)? There are framework out there that can help you do that. At least in C++ (this is the language I use the most).
And if only there were solutions that made it easier to prototype and get your backend running faster. It could make it even cheaper to make native apps. end: self serving response :)
I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook link. Tap it, and it opens in the Facebook app (or the browser, or any other app registered to handle the URL, your choice!).
I think these are the definitions that he/she goes by:
Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.).
Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole).
Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists, it's far less likely that users will do so, because of the install-barrier.
And what you mentioned requires the service to maintain both an app and a webpage, so that doesn't work when we're talking about dropping the webpage...
So the criticism is that apps alone, without a web presence, cannot be "searchable" and "sharable". "Deep-linkable" is still possible; your app can handle and resolve URLs that another app could not. And I'm going to assume that it's the content of the app we're discussing, and not the app itself, since that's kind of trivial.
So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.
They're achievable, but not native. You can't make your content crawlable unless it's on the web. You can deep link and share, but only if you explicitly build all of that while it's native to the web. And another one that always annoys the hell out of me is that I can't search text on an app screen. Again, you could build it yourself, but very few apps actually do.
I don't understand why people think this is a huge friction point. Installing apps is comfortable, familiar, and easy for people. By comparison, finding a mobile web application in the browser on a phone has significantly more friction.
I might of not been clear, but my intent with the comment was to encompass the entirety of friction points involved in getting an app installed on a user's device, from discoverability on down.
True but there's additional friction on the web app side as well. At this exact moment without looking at my browser, I'm not sure how to add an app to the homescreen. How many users actually know how to do that implicitly?
A lot of people in the real world don't want to install apps.
Also I disbelieve on how hard it is to find a mobile web application on a phone. Find it once, save a shortcut to a web page on your home screen, and now it is as easy to launch as an app. I actually find this easier to do than it is to install an app.
> A lot of people in the real world don't want to install apps.
A lot of just a specific subset of highly technical people? I don't think I've met anyone with an aversion to apps who also used a ton of mobile web apps.
> save a shortcut to a web page on your home screen
- The study in the sibling reply shows 65% of users dont install any apps in a month. I would think technical people actually install more (for testing etc)!
- Actually you don't lose anyone because browser history and address bar autocomplete are your friends. I dont think people care to save a shortcut, because they know they will be able to find it later.
I'm a technical user and I haven't installed an app in a month. I've probably gone a few months without apps. I've used a few mobile websites and zero mobile web apps.
I don't think it's fair to say that users who aren't installing any apps are actually going to mobile web apps instead. They're simply using what they already have. At some point I have all the apps I ever need for all the interactions I use my phone for.
> Actually you don't lose anyone because browser history and address bar autocomplete are your friends.
On the desktop sure, you might have a point, but interacting with a mobile browser to find stuff that way is not a good use experience. You think browser history and autocomplete is a substitute for a home screen icon? I don't know how to respond to that.
Because when you're browsing the web on your phone and you come to a page and you get a giant banner that says "HEY INSTALL OUR APP" what do you do? If you're 90% of the world, you hit the close button on that banner.
Seems like you're deferring one dragon for another.
Deliver the project got easier; "Control the customer" got significantly harder. You've now got someone's app store in the middle of your customer relationships and are exposed to approval drama, various forms of revenue squeeze, and other meddling from the platform owner. What happens if the folks running the platform decide to launch their own offering?
Speaking as another small developer, our solution to the cross-browser feature support is simple: anything that doesn't run on most modern browsers doesn't make the final design. If the customer doesn't bite on basic design, we don't expect a miraculous shift with the latest widgets.
Not really. It's called the Enterprise Program. While this is for 'enterprise', you can also use it - and Apple allows this - to distribute _outside the App Store_.
A few years ago I built a nice sms delivery system for installing an app I was working on. Text anything to our number (we had multiple numbers thru twilio based on market). App replies back with a download link. Install. It worked perfect and we could actually tell who requested the app and who installed it. We had around 75k users installing. Not millions, of course, but still, not too bad.
So, it is possible. We also did not have to wait for any approval process. And when the app started up, it checked for an updated version on our system. If there was, the app would then prompt the user to start the update. It was a very nice flow and we had many comments from users telling us that 'it just worked'.
This was app pre-iOS 7 and automatic app update, but it's still being used today.
Apps stores are crippled excused for real package management. In the open world, you can import someone else's key and repository and install their packages. In Play/iOS/Windows you have a single provider. There's no bug tracker to add your packages and no way to add a stable and unstable channel..unless both apps are in the same store ...and every beta release then has to get approved.
iOS and Windows Phone devices may be limited to a single package provider, but Android devices are not. I've had more than one store on my Android phones and tablets for over five years now. And, yes, I'd love it if there were a standard way to include signing keys for additional stores so that installations were seamless, that's not a significant problem in practice.
In practice, they do. On iOS, you can only go through the App Store. On Android, while you can sideload, the vast majority of users are going to expect to get your app from the Google Play Store, and not bother to check anywhere else.
If you're a two person startup quit building on quicksand. Use stuff that works. Once you have some users you can start venturing towards the bleeding edge of what's possible.
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."
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.
> 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)
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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"
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.
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.
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.
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.
> 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.
> "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.
"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.
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.
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.
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.
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.
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.
> 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.
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.
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.
>> 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.
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.
""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?
Agree with everything except with the numbers. Users won't install your app that much so it goes to a balance. It depends of course on the application itself but, since you're struggling so hard to go 'web', I presume it might be a mobile version of a website. I visit a lot of websites each day but do I install everything those websites suggest? No!
Since the article doesn't touch on specific I'm wondering where React Native falls regarding all this. I'm considering using it for our pending iOS and Android apps, seems like a no-brainer at this point versus true native.
Well React Native is one of many strategies they could use to build their app and later on back port their components to the web, should they resurrect it. I would agree with your point that it's a no brainer.
Meh, supporting a couple of iOS versions and a couple of Android versions for a native app along with device specific quirks is as much of a pain as supporting Firefox, Chrome, Safari and IE. Also, maintaining two code bases for native Android and iOS apps is a massive investment compared to a single web app code base.
A lot of the issues here are with mobile Safari. I agree it completely sucks just due to how behind Safari are with ES6. On the upside the work is complete to fix this in dev releases, so there's a very good chance that we're 3 months or so away from a large step change. I'm not planning on releasing anything in the next 3 months, so that timetable is okay for me, YMMV
I don't think that it's ES6 that's holding them back, there's Babel to fix that, I think it's all the browser vendors and the varying level of standards, different bugs and behaviors on every browser platform, plus there's features on Native platforms that are nearly impossible to replicate on the web. For instance `backdrop-filter`/iOS 7 like blurring wasn't possible on the web until Webkit implemented it, a year later only Safari has it and it's buggy in Chrome Canary (it blurs content under the box shadow). Another example ServiceWorkers, only in Firefox and Chrome, which cover most users on the Desktop, but on mobile you're screwed because half of your users use mobile Safari.
This seems like a misunderstanding of the tech. Service workers can really only fire up when they get a push notification, which you have to explicitly opt into, or when the page is running in the browser.
The processing allowed is tightly controlled, and even with permission the push notification can't do anything behind your back - it has to result in a visible notification which will alert you that there's something you want to disable.
backdrop-filter tends to go in my not-very-nice-to-have bucket. It's certainly something you can live fairly comfortably without.
Service workers are more of an issue - realistically if you want to build a serious web-app for iPhone right now you're going to have to build a shim around it for notifications and offline, although that can be quite small.
If you are aiming to provide a worthwhile experience to the users who will never install your app, or need some serious selling first then you need something on the web, so you are going to have a mobile site. Building a lightweight service-worker shim around that for iPhone and providing a couple of browser-specific stylesheets ought to be less work than full native apps.
Last time I checked, a lot of Android phones in my region (including new ones) were running 2.X versions with some unnamed browsers (probably webkit-based, but not chrome). For me that's much more issue. I can live with Safari, because there are 2 actual versions (iOS 8 & iOS 9) and they are modern enough. But those archaic androids with unnamed browsers are nightmare that I have to support.
I understand and empathize with the author's aggravation. But cheaper? Really?
So iOs and Android are more than 90% of the market. You are telling me that it is cheaper to build and maintain 2 separate apps and pass on the remaining part of the market than have one app that covers everything?
Android device support is supposed to be a nightmare - there are so many versions to contend with, each device manufacturer can customize things.
iOS is easier to support but fighting with Apple can be quite the ordeal.
Using the web means you bypass these other issues but have to contend with the ones cited in the article. It sounds like pick your poison.
I could conceive that after the initial cost of building 2 separate apps, for iOS and Android, that perhaps it is less aggravating and costly to maintain them, as opposed to dealing with the web. However how complicated is the UI for the web apps? Can't you keep it simple? Unless you can show numbers I cannot in my wildest dreams believe that building and maintain 1 web app is more than twice the cost of building and maintaining 2 separate native apps.
What are you building that requires building a 2016 Web app with every new feature? Maybe that is your problem.
Not really. If you are doing anything that relies on device hardware, camera, microphone etc... then device type absolutely matters - and it's even worse on mobile web because you can't get close to the metal.
I would agree, the native interface with hardware would be easier with native than the web. But the testing issues across all android devices is still an issue that the web should not have to contend with. And the Apple store issue is hard to quantify. You just don't know if they are going to let you in. The web means you don't have to get the user to install the app.
Of course if you use cordova or phone gap you still have to do deal with those issues. I still cannot conceive when 2 separate apps are cheaper to maintain than one.
You won't know until AFTER you apply. You'll find out after. There are numerous HN posts where founders have submitted their app to Apple and have been forced to wait or resubmit.
I can only shake my head at the venom being reserved for this post.
The number of permutations for testing scenarios across android versions as well as hardware manufacturers is significantly bigger than the number of available browsers. The difference between browsers is well documented and as far as I'm concerned finite. How many versions of Android are worth supporting? What about the differences between manufacturers. Browser differences are generally known and well documented. Can you say the same for Android?
There are many scenarios where I agree it is significantly harder to create a user experience building a web app that can compare with the native experience. But the premise of the article is that it is cheaper to build on 2 separate native platforms than it is to build web app?
The part that gets me is the author complains about things like multiple line ellipses and autocomplete text boxes. Here's a better question - why are multiple line ellipses core to your business? What value does a multiple line ellipse do for the app?
If you're building a web app (of more than trivial complexity, where you need to do things like profile for performance or access the user's hardware), you are building four apps: Chrome, IE, Firefox, and Safari. I mean, there are other browsers, but let's not kid ourselves. ;)
You are, in fact, also building those four apps on five different architectures: Android, Windows, Mac, Linux, and iOS. There are others, but again, let's not kid ourselves.
Your complexity surface is the product of your feature-set, the quirks of each of those browsers as they silently version-up for your users, and the quirks of each of those browsers on each OS platform as they also vary in version.
If you're building a trivial web app, it's a web page and by all means build it directly in the browser. But when you start to bust out the profiler to figure out why this one interaction is butter-smooth in Chrome and runs like crap in Firefox from versions X to Y, except on Linux where it's X to Z... Two mobile platforms is fewer than 4 browser platforms.
He forgot to mention how web frameworks come and go, and then you've got this legacy code nightmare. Also breaking upgrades and dependency hell. I'm a front end web developer, and yeah. If your building something simple, the web is the way to go, but his complaints are totally on spot.
321 comments
[ 2.9 ms ] story [ 345 ms ] threadIf you take a look at Meeker's 2016 Internet trends report that came out last week, you will see that 3 apps dominate 80% of the usage on phones. I decided when I started my food side project a year back, that I was not going to do a native app.
I have been trying to make the front end look better, but I did not want to use very heavy frameworks, so I settled on using the SASS mixin library Bourbon.io along with the grid and a few others the company provides.
The css that is produces is very tight, and I can save on developer costs. I should say, save on finding another front end developer as the one I was using took some money and ran.
80% of user time is spent in those 3 apps, that doesn't preclude very profitable apps from being developed. After all, people spend 16+ hours a day at home/work, but there are still plenty of reasons to open restaurants. Unless you profit directly from time-spent-in-app this doesn't seem like a consequential measurement.
See: Uber, pretty low on the charts for time-in-app but yet a massive business. Ditto Amazon, or GrubHub, or any number of other apps that deliver value to their users (and revenue to their owners) without long sessions.
But I think user adoption is just that much easier if all they have to do is open up your mobile web app in their phones browser. You could always build the app later after you have gotten the traction and growth.
Some apps do benefit a lot being native, but as others point out you throw in the middleman app-store model instead of just dealing with the browser, and keeping your UI simple, clean, efficient and of-course usable.
Really the problem with mobile web seems to be JavaScript.
Really the problem with mobile web seems to be JavaScript.
The biggest thing is still a better way to browse/post on iOS.
Though that some clickbait sites are asking for that permission is really irritating... I mean more so than interstitial or late-loading ads that push content down.
http://www.hnreplies.com
I use it.
I still wonder why HN seems hesitant to develop the HN platform further (although I'm relatively new to the site, so I don't know the history).
Fuckity fuck fuck <what the title said> fuck you, and shut the fuck up, dear reader. More fuckity fuck because the author has a keyboard macro that expands "," to "fuck".
I don't know, I thought it was pretty much a waste of my time. Read the top of the page you're looking at right now, read my first sentence. There, saved you a few minutes.
1. The cost of building an app can be calculated in the back of a napkin. The cost of a web app that works consistently across devices? Not so much.
2. The cost of building backend services has been commoditised to a degree. Front end web development? Its downright hard finding someone that can do good front end web work.
3. The reality that big companies (silos) will push their agenda over anything else and win.
I feel like doing anything non trivial for Android with a wide target audience is not always any more reliable than the Web experience claimed in the article
To me the problem is right here: why must every web app work on all devices? And why, if you build an iOS app do you have to build one for Android too?
If you're a small business, getting your first 50k, 100k, 200k customers is what matters. You can do this more effectively at lower cost by focusing on just one platform / browser / environment.
Because users want them to. If your web app doesn't work on their device, they're going to leave and use something else. The days of people being tied to their laptops is over.
"And why, if you build an iOS app do you have to build one for Android too?"
You don't have to, but if you want success, it's probably best to try and reach as many people as possible. And there are more Android users than iOS users.
To me the problem is right here: why must every web app work on all devices? And why, if you build an iOS app do you have to build one for Android too?
If you're a small business, getting your first 50k, 100k, 200k customers is what matters. You can do this more effectively at lower cost by focusing on just one platform / browser / environment.
What's the consumer coverage for Mobile Chrome + Mobile Safari? Giving up on total cross-browser compatibility doesn't have to mean writing native apps.
Also on a desktop or laptop where you've got a good Wi-Fi connection most websites are really good. That being said, I still things like Tweetbot, Flume, and Airmail over twitter.com, instagram.com or gmail.com.
Note aside: this is one of those "it really depends" kind of situations. For many cases native apps are always going to be cheaper to build. For others the web is just much better. It seems like the problem Eran is describing is more of a labor shortage. It's really, really difficult to hire good web developers. I have no idea why this is.
The obvious answer is the one given in the article: Google, Facebook, etc. can afford to pay good web developers far more than a small business.
If your product is an "app" in the functionality sense, then people are going to look for it in the "app store". Period. For user, it's actually a better experience than using Chrome/Safari.
1 dev 100k 1*5 500k in salaries
https://discord.engineering/using-react-native-one-year-late...
However with a huge friction point of requiring users to download and install an app.
Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.).
Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole).
Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists, it's far less likely that users will do so, because of the install-barrier.
And what you mentioned requires the service to maintain both an app and a webpage, so that doesn't work when we're talking about dropping the webpage...
So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.
Also I disbelieve on how hard it is to find a mobile web application on a phone. Find it once, save a shortcut to a web page on your home screen, and now it is as easy to launch as an app. I actually find this easier to do than it is to install an app.
A lot of just a specific subset of highly technical people? I don't think I've met anyone with an aversion to apps who also used a ton of mobile web apps.
> save a shortcut to a web page on your home screen
How many people did you lose at this point?
- Actually you don't lose anyone because browser history and address bar autocomplete are your friends. I dont think people care to save a shortcut, because they know they will be able to find it later.
I don't think it's fair to say that users who aren't installing any apps are actually going to mobile web apps instead. They're simply using what they already have. At some point I have all the apps I ever need for all the interactions I use my phone for.
> Actually you don't lose anyone because browser history and address bar autocomplete are your friends.
On the desktop sure, you might have a point, but interacting with a mobile browser to find stuff that way is not a good use experience. You think browser history and autocomplete is a substitute for a home screen icon? I don't know how to respond to that.
Because the numbers seems to indicate that. http://qz.com/253618/most-smartphone-users-download-zero-app...
Deliver the project got easier; "Control the customer" got significantly harder. You've now got someone's app store in the middle of your customer relationships and are exposed to approval drama, various forms of revenue squeeze, and other meddling from the platform owner. What happens if the folks running the platform decide to launch their own offering?
Speaking as another small developer, our solution to the cross-browser feature support is simple: anything that doesn't run on most modern browsers doesn't make the final design. If the customer doesn't bite on basic design, we don't expect a miraculous shift with the latest widgets.
A few years ago I built a nice sms delivery system for installing an app I was working on. Text anything to our number (we had multiple numbers thru twilio based on market). App replies back with a download link. Install. It worked perfect and we could actually tell who requested the app and who installed it. We had around 75k users installing. Not millions, of course, but still, not too bad.
So, it is possible. We also did not have to wait for any approval process. And when the app started up, it checked for an updated version on our system. If there was, the app would then prompt the user to start the update. It was a very nice flow and we had many comments from users telling us that 'it just worked'.
This was app pre-iOS 7 and automatic app update, but it's still being used today.
It's maddening. I wrote a thing about it and other Android issues: http://penguindreams.org/blog/android-fragmentation/
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."
That's the point of the article. Getting these things right on the web is non-trivial (and therefore expensive).
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."
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.
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.
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.
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.
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.
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.)
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.
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.
No, it rarely removes deprecated features.
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.
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.
Really? More unaffordable and unavailable than at least one native developer for each platform you're targeting? I find that hard to believe.
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"
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.
That's the killer.
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.
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.
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.
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
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/
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.
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.
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.
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.
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.
Another point against making web apps: users have stricter expectations about them.
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.
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.
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.
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?
The processing allowed is tightly controlled, and even with permission the push notification can't do anything behind your back - it has to result in a visible notification which will alert you that there's something you want to disable.
Service workers are more of an issue - realistically if you want to build a serious web-app for iPhone right now you're going to have to build a shim around it for notifications and offline, although that can be quite small.
If you are aiming to provide a worthwhile experience to the users who will never install your app, or need some serious selling first then you need something on the web, so you are going to have a mobile site. Building a lightweight service-worker shim around that for iPhone and providing a couple of browser-specific stylesheets ought to be less work than full native apps.
So iOs and Android are more than 90% of the market. You are telling me that it is cheaper to build and maintain 2 separate apps and pass on the remaining part of the market than have one app that covers everything?
Android device support is supposed to be a nightmare - there are so many versions to contend with, each device manufacturer can customize things.
iOS is easier to support but fighting with Apple can be quite the ordeal.
Using the web means you bypass these other issues but have to contend with the ones cited in the article. It sounds like pick your poison.
I could conceive that after the initial cost of building 2 separate apps, for iOS and Android, that perhaps it is less aggravating and costly to maintain them, as opposed to dealing with the web. However how complicated is the UI for the web apps? Can't you keep it simple? Unless you can show numbers I cannot in my wildest dreams believe that building and maintain 1 web app is more than twice the cost of building and maintaining 2 separate native apps.
What are you building that requires building a 2016 Web app with every new feature? Maybe that is your problem.
Not really. If you are doing anything that relies on device hardware, camera, microphone etc... then device type absolutely matters - and it's even worse on mobile web because you can't get close to the metal.
Of course if you use cordova or phone gap you still have to do deal with those issues. I still cannot conceive when 2 separate apps are cheaper to maintain than one.
I can only shake my head at the venom being reserved for this post.
And yet, it is.
"And the Apple store issue is hard to quantify. You just don't know if they are going to let you in."
Yeah, you do. It's pretty easy to read the rules. And things being flat out denied, rather than told they need to fix something, is really rare.
There are many scenarios where I agree it is significantly harder to create a user experience building a web app that can compare with the native experience. But the premise of the article is that it is cheaper to build on 2 separate native platforms than it is to build web app?
The part that gets me is the author complains about things like multiple line ellipses and autocomplete text boxes. Here's a better question - why are multiple line ellipses core to your business? What value does a multiple line ellipse do for the app?
98.4% http://www.gartner.com/newsroom/id/3215217
I think it's pretty reasonable to pass on the remaining 1.6%, especially as those probably aren't your target audience anyway.
You are, in fact, also building those four apps on five different architectures: Android, Windows, Mac, Linux, and iOS. There are others, but again, let's not kid ourselves.
Your complexity surface is the product of your feature-set, the quirks of each of those browsers as they silently version-up for your users, and the quirks of each of those browsers on each OS platform as they also vary in version.
If you're building a trivial web app, it's a web page and by all means build it directly in the browser. But when you start to bust out the profiler to figure out why this one interaction is butter-smooth in Chrome and runs like crap in Firefox from versions X to Y, except on Linux where it's X to Z... Two mobile platforms is fewer than 4 browser platforms.