
It’s cheaper to build multiple native applications than one responsive web app - cdnsteve
https://hueniverse.com/2016/06/08/the-fucking-open-web/
======
donatj
I don't think that's remotely true if you keep the responsive web app simple.
YNGNI and KISS and what not.

I've been doing this for over ten years. In that time I've seen large web
applications built for under 4k; I've also seen massively overbuilt simple
applications go for 50k+. It comes down to often how needlessly complex you
make the stack.

If you stick with solid simple guaranteed tech instead of cutting edge you can
knock a web app out relatively cheap and easy.

When it comes right down to it, 95% of web apps have two jobs. Present text to
the user, take text from the user. Everything else is a nice to have. HTTP has
been doing those two jobs amazingly well for decades. It's a solved problem,
don't make it harder than it needs to be.

Lastly: Don't fight the browser. Design for the browser. Responsive is easy if
you design for things to flow as the browser would have it. It's one of the
biggest mistake I see so often. If a design requires you to fight the native
behaviours of the browser, it's likely a bad design. Fight back against that
junk, it just makes future work that much harder.

tl;dr Develop for the web of a couple years ago and not the web of today.
It'll save you time and headaches.

~~~
rsp1984
I think the author is already addressing this:

 _Yes, you can build 2007 websites much better now. They will be consistent
across platforms and perform great. But my 12 year olds don’t want 2007
websites. They want 2016 apps._

~~~
brianwawok
12 year olds don't have money, I would wait till people are at least 16 to
care if they use my app...

~~~
RGamma
The toy industry would like to disagree!

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

~~~
paulddraper
Apps don't have to be downloaded from stores, thought that certainly does make
things nice.

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

It's maddening. I wrote a thing about it and other Android issues:
[http://penguindreams.org/blog/android-
fragmentation/](http://penguindreams.org/blog/android-fragmentation/)

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

~~~
dec0dedab0de
ATM's at casinos and clubs can charge $5+ dollars for a withdrawal, but that
doesn't make it a viable solution for even %10 of ATMs.

------
donw
I can speak with some knowledge of a not-insignificant B2C company -- not my
current gig -- that went down this exact same route some years ago.

Swore off mobile web in favor of pushing people to the app, because app
conversions were much higher.

A satellite office broke away from the fold and implemented a responsive
mobile site, immediately increasing their bottom-line revenue by 30%... and
that's before doing any sort of conversion optimization.

The main office followed suit shortly thereafter... with a new head of
engineering.

Native apps are no easier or harder to build than web apps. Equivalent level
of difficulty in my experience, with apps being slightly harder because end-
to-end testing needs to be done almost completely manually, and because the
release cycle is partially outside of your control.

But for most businesses, you really, really do not want to neglect the mobile
web.

Yes, conversion for in-app users is broadly higher across the board. But
that's not because conversions suddenly spike when people use an app. Rather,
your most dedicated users -- the ones most likely to convert -- are the ones
that will install an app.

For the rest of us, if it's "app or bust", we will pick "bust".

As a consumer, I deal on an annual basis with probably over a hundred
different companies. I do not want an app for each of those companies. And if
you force me to download an app from the get-go, I will go to your
competition.

~~~
podcastrank
exactly, [http://www.recode.net/2016/6/8/11883518/app-boom-over-
snapch...](http://www.recode.net/2016/6/8/11883518/app-boom-over-snapchat-
uber)

Alternatives are webapp's or even building chat bots/apps on messenger
platforms. This progressive mobile webapp example is impressive
[http://www.flipkart.com/](http://www.flipkart.com/)

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

------
untog
Even if this is true, I doubt it's a wise idea, given that the average US
consumer downloads _zero_ apps per month:

[http://qz.com/253618/most-smartphone-users-download-zero-
app...](http://qz.com/253618/most-smartphone-users-download-zero-apps-per-
month/)

Unless you're in a very fortunate niche, you can't afford to not do the web.
You can afford to not do apps.

------
jordanlev
I don't like how the author mocks other people who make decisions based on
money over ideals:

> That group, btw, has mostly sold out taking high paying jobs at Facebook and
> Google, and have not heard from since

...but then later justifies his argument to forsake his ideals because "hey
I've got a business to run":

> I don’t need you to troll me on Twitter and tell me how I’m betraying the
> web and the free fucking world. I am just trying to keep my startup going.

------
tmaly
I can totally relate to some of this.

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.

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

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

------
0xsnowcrash
I think this is a bit of "grass is greener" syndrome.

I developed web apps for 14 years before building ios apps for 5 years.

The last couple of years I've worked on both native apps and responsive web
sites.

Both can be pains in the a __e. But the pain points are different.

Both are moving rapidly. eg Ios: having to rejig xibs to storyboards was
annoying.

Css: Supporting older versions of IE has been a pain.

I could go on at length but plenty of people have already done so.

~~~
jordanlev
Was just going to comment that "the grass is always greener..."

For example, here is something that was on the HN front page just a few weeks
ago: [http://clean-swift.com/mobile-development-projects-fail/](http://clean-
swift.com/mobile-development-projects-fail/)

------
Illniyar
There might be something to the headline but the content isn't delivering.

1\. You can't compare making an ios and android app to making an app for every
bloody broweser, I mean you could just as easily built your webite to safari
and chrome for mobile. You want a true cost comparision compare building an
app for universal windows, and mac and linux. Of course if you reduce the
scope of your app's access you are going to get reduced costs.

2\. Building a messaging app is probably the least appropriate and one of the
hardest things to build with web technologie( after a game). Use the
appropriate technology for your app.

3\. By your remarks on how costly mobile developers are, I'm guessing you've
hired to inexpierenced web developrs. Get expierenced developers who know the
limitations and best practices and you wont encounter so many issues.

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

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

~~~
aeorgnoieang
"Giving up on total cross-browser compatibility" seems like it would entirely
avoid "sites which needs to take into account all browsers".

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

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

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

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

------
jaredcwhite
This article might have had some resonance a couple of years ago. Today it's
just not the reality. Mobile apps are running into major engagement issues.
App Stores are loosing their value prop and running towards web-like SaaS
pricing models (Apple's hand was basically forced here).

On the other hand, mobile web browsers are way better than they ever have
been. Desire to maximize web performance instead of allowing bloatware JS and
ad cruft is at all-time high of industry awareness. Many mobile apps are
"hybrids" anyway. Basecamp 3's new mobile apps are good examples of how you
can create a pretty solid experience with a sensible mix of native and web-
based functionality.

In other words, the open web is actually in better shape now technologically
than several years ago. If only the big VC-backed SV startups would see that
instead of chasing their tails trying to grab app users' ever decreasing
attention.

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

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

~~~
zghst
Well, Native could also mean transitioning over to React Native, Cordova,
Phone Gap, etc

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

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

~~~
hypercluster
I often hear this. I tend tp agree but what exactly do you mean? That
Javascript is used more widely?

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

~~~
needz
You hit the nail on the head -- I am a full-stack/back-end dev. Always
prepared to learn the next thing (provided it's in javascript, hah).

------
joeyspn
Comparing "responsive web apps" with native mobile apps? Really? What about
cordova/phonegap/ionic?

Don't blame the _web_ because you made a poor decision picking your tech stack
(or hiring your devs). Nowadays a single webdev can ship OSX, Android and
Windows apps with frameworks like Ionic... in weeks.

Starters (there are hundreds) help a lot:
[https://market.ionic.io/starters](https://market.ionic.io/starters)

~~~
st3v3r
Stuff like Cordova and Phonegap almost universally produce crappy apps. Doubly
so if the person doesn't think they need to style the app for the individual
platform, instead of just shipping the default (usually iOS) styling.

Shipping an app with one of those is almost universally saying, "I don't care
about user experience, I just want to shovel something out the door as cheaply
and quickly as possible."

~~~
joeyspn
> Stuff like Cordova and Phonegap almost universally produce crappy apps.

Again, don't blame the tool. Blame the bad usage of the tool. You're just
saying: "Let's ban knives, assassins use them to do bad stuff!"

> [...] style the app for the individual platforms [...]

Ionic does this for you automatically. Surprise!

[http://ionicframework.com/docs/v2/components/](http://ionicframework.com/docs/v2/components/)

It's easier to complain about the tools than acknowledge that you might be
wrong about how you or your devs use them (because of unfamiliarity).

Truth is many people are shipping stunning apps in no time thanks to web
technologies.

~~~
st3v3r
No, I blame the tool because it's a poor tool. And I'm not using them wrong,
because I'm not using them. I do native apps, because I care about my user's
experience.

------
z3t4
> Yes, you can build 2007 websites much better now. They will be consistent
> across platforms and perform great.

There you have it. Using bleeding edge features will create a lot of problems.
First you need to figure out what type of users you want to target, PC users
with 24 inch monitors and keyboard? Or 12 year olds with iPads? But still, for
your software to really work across as many units as possible, and continue to
work for years, you have to look what existed 5-10 years ago, and only use
those features that are still standard.

I have a mobile phone that no longer gets updates. It is HTML 5 compatible, so
it should handle everything that is not bleeding edge, but still _many_ web
pages, for example medium.com does not work!

I remember being a web developer ten years ago, it was your professional duty
do make sure it was pixel perfect on existing GUI based browsers and even look
good on the text based ones. I think web dev's today is too quick to jump on
the latest and greatest.

If you take a look at the browser features that existed 5-10 years ago, it's
way behind the native phone app experience! It seems browser vendors totally
missed the mobile explosion, and only lately have begun to catch up!
Considering how fast the web tech moves now though, the future for web dev
looks bright. I think that in in 5-10 years, the mobile browser experience
will be on pair or even ahead of native, at least considering dev experience
and cross device/platform support.

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

~~~
pdonis
_> 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.

------
mikeryan
_One app for iOS, one for Android, and I got over 90% consumer coverage_

However with a huge friction point of requiring users to download and install
an app.

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

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

~~~
wvenable
> 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

How many people did you lose at this point?

~~~
return0
\- 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.

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

------
cjcenizal
Pro-tip: You can make your article sound like it's been written by a grown-up
if you find/replace all instances of the word "fucking" and "fuck" with "".

~~~
JBReefer
People also just speak differently. You're allowed to curse on the internet,
and as someone who lives in Queens, I honestly have trouble speaking without
cursing. It feels kind of stilted and overly proper. Language is fluid and
evolves.

~~~
pbhjpbhj
But presumably you don't write in every "um", <cough>, stutter and mis-speak
so why keep in the swear words rather than cutting them and increasing your
readability and information density? You may have trouble speaking without
cursing but you clearly manage to write without including the curse words.

------
bryanlarsen
Sure, it may be cheaper to build an Android app and an iOS app than it is to
build a responsive web app. I'll buy that.

But most customers want an Android app, an iOS app and a web site for desktop.

It's certainly cheaper to build that desktop webapp if you don't have to make
it mobile-y, but is it cheaper to build an Android app, an iOS app and a
desktop webapp than it is to build a responsive webapp?

------
jflatow
'www' should stand for wild, wild, web. In many ways, the web is a technology
frontier, with all the frustration and liberation that goes along with it.

I sympathize with the author. The problem is trying to tame the web, as
opposed to embracing it for what it is.

~~~
dave2000
It would appear that "what it is" is "not good enough", and that the sort of
functionality and control over behaviour an layout is so hard to achieve on
the browser that it's just not possible for any reasonably complex app and for
a sensible price.

------
EGreg
Seriously... there should be a framework that takes care of all that for you.

We built this framework. And it took us four YEARS. Ok, it also does a ton
more stuff than just make the app work across devices.

But, the web rocks. Seriously. PhoneGap lets you basically stuff the web app
into a fullscreen shell and go to town. And the best part is that you gey to
control updates, _totally legally_ without Apple holding you up. Have a front-
end bug? Fix it for everyone tomorrow! Have a new feature you want to roll out
to only 5% of your users? YOU CAN! And then A/B test it. Whoa. Like how would
you A/B test with the app store? Yeah, that.

Also... when invitation links are clicked, where do you think the mobile user
goes?

TO THE WEB.

And so... you need a web experience anyway, that does more than say "Please
download our app. Here is a nice picture and description so you can clutter
your phone now."

And finally... web push notifications? Yes, this is one of the TWO BIGGEST
THINGS MISSING in iOS Safari. (The other is access to the address book, with
permission of course.)

But I think that's about to change at WWDC. Android Chrome has Web Push!

------
llamataboot
"native app developers seems to think $50K is the smaller amount you should
bill for a native app these day"

Ummm, yeah, I would say $50k would cover a small native app using Parse or
similar or an extremely light backend. Even a medium size native app is going
to run $100-150k. That's the price of software development if it's happening
in the US.

------
r2dnb
One thing we tend to forget as developers is that in any industrial process,
there needs to be technical limitations enforcing requirements before
requirements enforce technical specifications. We tend to be too easy because
everything seems achievable with software systems.

A project should start by considering political things such as: is it smart to
have this particular application hosted in a marketplace. Right after that,
the chief engineer should be consulted to know the technical approach
(platform, stack, etc...) that should be used, and the technical limitations
that the requirements should observe to allow the development effort to be
successful and efficient.

The more self-imposed technical constraints are observed, the more successful
and easy the development will be - and passed a certain point, the more
difficult it becomes to sell the product or service.

Applying this reasoning to the article, to me the problem is the very thing
they have decided to develop.

------
bradscarleton
Responsive web apps are difficult to build, however settling for native
Android and iOS is not sufficient for comparison since he's leaving out the
desktop (so he should probably include Windows and OSX for some level of
parity for what a responsive web app can do).

The real underlying problem is the state of the mobile web browser, which
neither Apple nor Google have much incentive to improve due to their revenue
generating app stores. That's not to say that there wouldn't still be some
major differences between native apps and mobile web (especially in the
discovery / delivery department), but if you had better feature parity between
these platforms I think rants like this guys would be fewer and farther
between.

tl;dr: He picked the wrong technology platform for his product, therefore
since it didn't work for his use case, it must be fundamentally broken.

------
pfooti
Mobile Chrome + Mobile Safari would be a great way to cover enough bases to
make a good responsive web app reach a huge audience. The core problem is that
Mobile Safari is really quite frustrating in a lot of ways.

As a simple example, I had a bug with some of the dialogs and menu popups I
was using not rendering in Mobile Safari. It turns out that if you have a div
that is a child (in the DOM) of a div that has overflow: hidden, that child
will not be rendered outside of the clipping box of the parent, _even if_ the
child div is position: absolute and at a higher z-index than the parent. This
works differently in chrome.

There are plenty of workarounds available, but the basic strategy of creating
a position: relative context and having a position: absolute floating menu /
dialog that's rendered near the button that creates it won't work if your menu
bar has overflow: hidden on it. But then you have to make sure you've got your
menubar set up well so that it doesn't become super-tall in narrow screens,
because you specified overflow: visible. Or you have to put your floating divs
elsewhere in the DOM tree and specify their position as fixed and manually
calculate where to put them using javascript.

It's things like this that frustrate me the most in working with safari - I'm
constantly wrestling with a rendering stack that doesn't seem to do what I
want (it was only in recent versions that I could stop setting flex-basis:
0.01px instead of flex-basis: auto (on safari) like I do everywhere else on
divs that had only text children that I wanted to make expand but also become
multiline text instead of pushing everything way out to the right. And don't
get me started on safari's support for indexeddb, let alone the other neat
features that chrome is supporting to make mobile just plain better.

I'm at the point now where I'd literally be willing to tell my users: "install
chrome for iOS" if it were actually chrome, instead of supporting safari. But
instead, I deal with the sort of resonance back-and-forthing when I fix a
safari layout bug that introduces oddities in chrome's renders.

------
amasad
>The web is the future. The web will always be the future. But that’s the
problem. I need to ship products now.

It's like tomorrow is always tomorrow -- it is never today. One thing that
bothers me about the web dev community is the insistence that technology has a
will of it's own. As if the web will just eventually win no matter what. I
consider myself an advocate for the Web but it _needs_ to be good or better
than the alternatives.

So, joke aside, it doesn't follow from the rant that the web is the future. It
follows that there is a lot of work that needs to happen before you can say it
might be part of the future.

~~~
hutzlibu
I don't like the dramatic at all.

It allways has been the case, that if you used the most bleeding-edge
features, you will bleed getting it to work everywhere. Very painful indeed,
but I won't suspect, that this is going to change in the future, with so many
people and companys involved.

So if you need to ship products now, you have to use, what's stable enough, if
you want to target everyone.

------
siegecraft
The core of his argument really boils down to: I have to do it this way
because my audience is 12 year olds and this is what they want. A good lesson
in knowing your customer I guess. But I don't think the conclusion is useful
for most people.

Another thing that stood out to me: "a closed ecosystem will always deliver
higher quality in any given moment." Which is so absolute it's ridiculously
easily disproved, even while being true at certain points.

------
joehewitt
I used publicly whine quite a lot in favor of open web standards. When the
specs were simpler, this made more sense, but as they grew more and more
complex I felt overwhelmed with the chore of developing cross-browser apps.
The investment of time required just didn't make sense anymore, and I felt
like the only way to serve the web was to develop simple content-focused
pages, and leave any complex functionality to native apps.

------
mozey
"Do I miss IE6? As a CEO, actually yes." Seriously? Article should just have
started with this, then I wouldn't have had to read the rest.

------
Joeri
The web's view layer, html and css, has the wrong granularity for building
precise ui. Html's controls are too high level for pixel perfect manipulation,
and too low level for easy assembly into rich ui. CSS meanwhile tries to get
you to make general rules that interact to produce a precise rendering, which
you never quite achieve because there are always unintended side effects of
the rules. No native view api works like this, and for good reason. Since
these technologies are almost entirely but not quite unsuitable for building a
native-like view layer, people build abstractions around them to approximate
the view layer api any native ui gives you. But then the problem becomes one
of synchronizing the facade view to the real view, hence ten thousand
templating and layout frameworks, all while continually dealing with the leaky
nature of the abstraction.

I guess what i'm saying is that i believe in the principles of the web, but i
think html and css are terrible technologies that do a disservice to those
principles.

~~~
CharlesW
> Html's controls are too high level for pixel perfect manipulation, and too
> low level for easy assembly into rich ui.

HTML+CSS isn't the only abstraction available, though. If you want a lower-
level abstraction, you can use canvas. If you want a higher-level abstraction,
you have your choice of composable view component systems (e.g. React).

------
volune
Problem is no one wants to download your native app.

------
ciokan
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!

------
jokoon
I'd say it again: break compatibility and make an open,
preparsed/compiled/binary HTML format. You'll get several order of magnitude
speed increase and reduced memory consumption in browsers (parsing text is
expensive). Something a little similar to microsoft .CHM file format.

So instead of having a competition in browsers, you'll have competition is the
HTML parsers that developers will use.

No more messy W3C messy standard which is VERY hard and ambiguous to parse for
any browser.

I've repeated that rant so often, I might start making a simple example of
what I'm talking about. We just MUST abandon the text only approach. It
allowed the internet to thrive without microsoft's attempt to make money with
it. But today browsers are so ubiquitous, all that there is to do is enable
browsers to just render binary HTML, which would just be a tree of rectangles
and styles, so really simple. I think.

~~~
oneeyedpigeon
Aren't the big bottlenecks things like waiting for large resources (images) to
download and javascript processing? The parsing of HTML, as far as I'm aware,
has a tiny relative impact.

~~~
spriggan3
> javascript processing?

Actually Javascript engines are extremely fast, the UI in a web app isn't
because web engines have to deal with a complex repaint model. Resources can
be loaded asynchronously, so it's not really a bottleneck. On the other hand
repaints can absolutely be a serious bottleneck in webpage.

Native UI use a much much more simple model, which makes repaints less
expensive and allow a better FPS rate.

That's why webpages shouldn't try to look like native apps on mobile.

------
unicornporn
VERY relevant article: [https://govinsider.asia/smart-gov/why-britain-banned-
mobile-...](https://govinsider.asia/smart-gov/why-britain-banned-mobile-apps/)

Ben Terrett was former head of design at the UK Government Digital Service and
he wholehearted disagrees.

~~~
hutzlibu
It's refreshing to hear so much competence from a part of a government ...

But about the disagreement: government-apps don't need to be bleeding-edge,
like the one from the article. They just have to work without glamour. So 2007
works fine for them ...

------
mark_l_watson
The author of the article ignores user experience: it is much nicer to use a
web app than install yet another app. Personally I don't like installing web
apps, even if they don't ask for a lot of permissions. Also re: notifications:
I think most users don't like to be interupted by notifications.

~~~
st3v3r
User experience is generally much better in native apps than in websites,
though. Native apps match the look and feel of the native platform, with all
of the network and performance benefits that entails. Native apps can
integrate with the platform to a degree that web apps just can't.

------
gmarcus
How about a real world example.

tl;dr The Hybrid app took longer to ship (+ 20%), and was more expensive (+
525%)

We were able to participate in a unique experiment: \- Develop a native app
for iOS and Android at the same time a separate team was developing the exact
same app as Hybrid (Cordova/React).

The app had 20 screens and used modern UX (onboarding, profiles, hamburger
menus, alerts, GPS, content rich screens (text/images/video) with
lists/details talking to a backend REST API with local/offline/sync'd storage.

Native = 8 man/weeks

\- 1 iOS dev for 4 weeks \- 1 Android dev for 4 weeks

Hybrid = 50 man/weeks

\- 5 Hybrid devs 10 weeks

You can argue that the 5 devs had overhead in communication and project
management, but we observed that was not a major contributing factor.

The above was for app development (not the server). Hybrid app required the
same amount of QA as the Native app.

------
petermolyneux
I built this app with web tech. It was sweaty, and I many times wished that I
had gone native. But now that it's done it is something native could never be
:) [http://www.oneviewcalendar.com](http://www.oneviewcalendar.com)

------
z0r
>But it pisses me off every time I see a Twitter thread about how native apps
are destroying the free world.

I can't understand this sentiment the author claims to see. Web apps are
generally going to be less free than native apps. A native app doesn't have to
be open and a web app doesn't have to be open, but a web app is definitely
going to require that you connect to the host, will probably keep all your
data stored away from your grasp on its servers, and may change its
functionality and terms of service at any time. Native apps can share many or
all of these traits but at least there's a chance you can control a copy of
the software. The web is a terrible software platform for users.

~~~
arjie
I freaking love the web as an app platform. Now I don't have to wait for
Google Maps for Linux, or Gmail for Linux, or whatever. That world sucked.

~~~
z0r
Google Maps is magical, but it isn't magical when you can't view uncached
tiles or search for things when your connection is offline. A downloadable map
application that you could purchase and view and search entirely offline would
be even more magical.

~~~
prewett
Seeing as how Open Street Map's complete dataset is 40 GB compressed (and that
probably doesn't have all the businesses, addresses, keywords, etc. of Google
Maps), there's a pretty good reason why you can't search it offline. Not to
mention, why would Google give away all their data on every install.

But, you are partially in luck. Google Maps now allows you to download up to
120,000 sq. km.
[https://support.google.com/maps/answer/6291838?hl=en](https://support.google.com/maps/answer/6291838?hl=en)

------
eggy
> How many of our web evangelist are using an Apple laptop, the most closed
> ecosystem around?

He's got a point here. I gave up my MBPs for a Win 10/Linux notebook, and I've
come across some opensource and commercial projects I hadn't noticed only
worked on OS X and Windows (MAX/MSP). Sometimes Linux is supported, but as a
third, less-supported option (Mathematica 10.4).

Maybe it's because I made the change that I am focused on this now, but every
talk I watch has the Apple logo.

I've noticed some older coders with cred are rocking Lenovos and 3 to 5 year
old laptops. I used keep a laptop for 4 or more years, but now I am guilty of
'upgrading' every 2 to 3 years.

------
ChrisArgyle
If you miss Ted Dziuba's writing at Unvoc you will thoroughly enjoy this
article

------
enturn
I completely agree with the article. I joined a startup a few years ago and we
went mostly native on Android and iOS with some simple screens as web views
shared between them. Later on some clients wanted desktop and Windows Phone
versions so we built a lesser featured version as a website to cater for any
other devices (adding features as necessary). We started out as 3 software
developers and a designer and are expanding. Native apps was a more cost
effective way to deliver a good experience while the competition mostly
developed web apps resulting in a lesser experience in my opinion.

------
return0
Good luck having the users download your app. I use everything from the
browser, including gmail and twitter (both load faster and don't bother me
with notifications). However I hate how they prompt me to download the native
apps every fucking time (obligatory). I actually wonder, what are the action
rates for those app install prompts?

If you don't play games there is barely a reason to download an app ever.

And really how bad or difficult is the mobile web? Use bootstrap and you have
a pretty fine experience. I think we are focusing too much on slick experience
instead of offering something useful.

------
csours
You should still STRONGLY PREFER Web Apps. The cost and headaches of a web app
will be MUCH LOWER than native or even hybrid app development.

BUT, if you need a Native App, make a Native App and don't try to fake it on
Web.

------
ProfChronos
Really excessive and sometimes completely out of the road: "Open standards are
always going to be inferior to closed ones. How many of our web evangelist are
using an Apple laptop, the most closed ecosystem around?" You have many open
standards that are superior to closed ones, simply because it unleashes
creativity of the community. Many techies use Apple because they build an
amazing user experience, based on a closed but very large ecosystem - go to
the App Store and you'll see most of the apps you need

------
Glyptodon
Is there some rule that startup CEOs have to say "fuck" a lot?

------
nikdaheratik
I can sense the frustration, but I don't think it's the web's problem
necessarily, and I've done work in both areas. Some ideas just don't work well
in a web browser, because despite 20 years of attempts to force it down that
path, a web browser isn't the same as something like Flash, let alone a native
software stack. There are more stakeholders than just the app development
people, and they don't always care about the same things you do.

------
anuraj
We do the same - each of our Android and iOS developers can complete a medium
complexity app in 2 months flat without any issues - Web - not so much - while
initial work is done much faster - it takes ages to tackle responsiveness
issues even with Bootstrap. So although our web apps are responsive - we still
provide native Android and iOS apps to clients. I don't see web apps replacing
native apps anytime soon.

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

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

~~~
xenadu02
And for good reason. I don't want random websites burning my battery for their
"oh so important" background tasks.

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

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

~~~
legulere
> So iOs and Android are more than 90% of the market.

98.4%
[http://www.gartner.com/newsroom/id/3215217](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.

~~~
padseeker
The 90% was based on a previous post. I was too lazy to search for the total
market share of iOS + Android.

------
jtmarmon
It might be true that it's a pain in the ass to write a responsive web app,
but that doesn't mean it's not worth it. Users are unlikely to download a
mobile app just because you say so.

Of course YMMV. If you have control over what the user does like some kind of
internal enterprise app then go for it.

------
tonyle
I wonder if multiple native app is still cheaper than maintaining multiple
different web builds.

Reminds me of this library I stumbled across.

[http://www.zebkit.com/](http://www.zebkit.com/)

People either respond with this is cool or your going against the web when I
told them about it.

------
chadcmulligan
Have a look at Delphi if you want cross platform native apps
[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi).
It's very easy, $50K would take you a very long way.

------
danjayh
Key takeaway: "Open standards are always going to be inferior to closed ones."
This is totally true, but as the author notes, open standards still have their
place.

Also, I realize he's mad, but he really needs to expand his expletive
vocabulary :)

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

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

------
api
At age 38 I'm a little bit of an oldster for this industry, and I remember PCs
in the 80s. I was a kid but that's when I learned to code and I distinctly
remember what it was like.

It was a lot like today: loads of fragmentation and loads of vertical 'silos'
with their own peculiar way of doing things.

Until the late 1980s you had a million little vertically integrated platforms:
Apple II, TRS-80, Commodore 64, TI-99, IBM PC, etc. Even within manufacturers
you had major incompatibilities, like Commodore VIC-20 vs. Commodore 64. Those
were almost totally different machines.

Then the explosion of cheap IBM PC/AT clones changed all that and killed all
the smaller players. There was a brief period from about 1988 until roughly
1999 when we had essentially one platform MS/Intel. That was MS-DOS and
Windows, and the latter would usually run DOS apps. You also had one UI
metaphor: the mouse and the keyboard and the screen. You had some hardware
fragmentation but if you were targeting OS APIs and not trying to be bare
metal it wasn't too hard to deal with. You mostly had one platform you could
target and get 90%+ of the end-user market.

No more. Today if you want that 90th percentile of the user base you have to
roll at least three _completely different_ UIs at a minimum. Either that or
you go all-web, which as this author correctly points out is a major headache
if you want something that's mobile friendly. We've had good luck with
bootstrap+react but it is more work than targeting a _single_ native platform.
(Not sure if I buy that many native platforms are more work... probably
depends on the stack.)

On one hand all this diversity is interesting, but on the other hand if you
just want to ship a damn product it's infuriating. It's also true on the
backend: you have at least six Linux distributions, Docker, a million
different 'stacks', clouds like Amazon building closed mainframe platforms
like lambda, etc.

------
neom
Related: [http://thenewstack.io/the-new-stack-analysts-show-19-web-
vs-...](http://thenewstack.io/the-new-stack-analysts-show-19-web-vs-mobile-vs-
native-vs-open/)

------
njharman
"Building" is very small part of software life cycle.

Is it also cheaper to bug fix, add features to, update apps when each native
platform updates, hire developers who know details of each platform, etc.

~~~
sintaxi
I'll disagree and say its cheaper, faster, and less risk to bug fix and add
features if you only maintain one codebase.

~~~
njharman
Well then you are agreeing with me, because that is what I said. One webapp
cheaper, faster and less risk than multiple native apps.

------
nsxwolf
This person is angry. I can't imagine that if someone was ridiculing me on
Twitter for destroying the free internet I'd care enough to start swearing up
a storm.

------
lsiebert
My current employer bought the app I work on from my previous employer. It
embeds websites in webviews with JS-Objective-C/JS-Java bridges so they can
make native calls. You get most if not all the benefits of native apps, native
UI when you really want it, quicker iteration then the App Store, and can
build in whatever stack you want. Of course I've had to follow an intermittent
bug from the rails back end, to the angular front end, to the native java and
up to the companies api servers before, so YMMV.

------
WalterSear
No it's not. Get better designers - ones who understand responsive design, and
developers who speak modern javascript.

~~~
elliotec
I'd argue that "modern JavaScript" is a pretty huge part of the issue at hand.

------
hartator
I think it's interesting to know that native apps need to be responsive as
well.

------
jtwebman
Has he looked at mixed tech like React? Get web tech with native controls!

~~~
elliotec
React is absolutely not going to make things easier for him.

------
mkem
The requirement logic of my benefactors necessitated no less...

------
fallo
Well, I'll take all of that instead of the f __ __ _g c_ _p the native gives
me from all the bright minds at g_ __ _e, a_ __e and m __ __ __t, anytime. The
future is here.

------
myoxide1337
Makes sense and reminds me of 2006-2007 when this was a big topic in the US
with Android and Windows mobile apps with Apple in the passenger seat

------
Bino
You're clearly doing it wrong...

------
mmanfrin
But which is easier to maintain?

------
sidneys
you're wrong. dead wrong. about 2012 was the turning point in this game...

------
jcoffland
What this article needs is more F-bombs. Otherwise it's ranty but makes some
good points.

------
dalacv
I like the last line

------
myoxide1337
Makes sense

------
chriswwweb
I don't think "web apps" are as problematic today than they were several years
ago. I don't say this because I hope web apps will be the future of app
development, but because together with a few other devs we have built such an
app at the company I work for. I think the result is a success but
unfortunately I didn’t have enough time to write about our experience yet. I
hope I will have the time to so anytime soon.

Yes the development costs are super important, especially for small companies
/ startups. As important is the performance of your app(s) and also super
important is the usability of such an app. If the development costs are much
higher than building native apps besides your website, then you failed. If
your app is slow and unresponsive then you failed. If your users dislike the
app because it is not smooth like a native app and feels sluggish then you
failed.

But does this mean that building mobile web apps is impossible, I don’t think
so. We did several things that helped us to keep the costs as low as possible
and for sure much lower than if we would have written server, apps and client
code using different languages / frameworks and libraries.

Our server side code, the code of our web apps as well as (obviously) our
client (browser) code are written in javascript. We have used typescript to
write all our code, this allowed us to use the latest ES6 features and gave us
features like strict typing. The ES6 features we have most used are promises
and classes. Typescript compiles our ES6 code into ES5 UMD modules. We choosed
Visual Studio as IDE as it compiles typescript on the fly, which allowed as to
quickly test new code almost in real time. We also used the node js tools for
visual studio which allowed us to use the node js debugger from within our
IDE. Setting breakpoints (typescript creates Javascript to TypeScript source
maps), reading stack traces or watching variables was a piece of cake.

We have built an isomorphic website first. Our server side got built on top of
express js (node js). All our modules and libraries are UMD modules, which
means that more than 95% of the code we wrote is the same that we use on the
server and in the client. We have built a server views renderer using Backbone
and domino. Our collections and models are the same on the server and in the
client, the only difference are the adapters we wrote to make ajax or server
side requests. We use the same router on the server and in the client, which
means the first page that gets served is always built on the server but the
next pages are built in the client. This also means that crawlers can harvest
our pages but for users we only retrieve the data needed to build the pages
from server and do all other work in the client, which makes the pages load
very quickly. We also had to write a cache library once, the only difference
again are their adapters, the server adapter of our caching library saves
objects into redis while our client adapter saves them in IndexedDB. A lot of
things needed to built the pages get cached too, so each template, each
translation and so on only needs to get fetched once by the client and can be
reused until we publish an updated version of the item.

Our web apps are built using phonegap. Again 95% of the code of our apps is
the same as the code that is being used by the client (browsers). Obviously we
had to write clean and powerful code to ensure that our apps come as close as
possible to the speed that people expect from a native app. We had to track
every minor memory leak, especially those that occur when binding events to
ensure that our apps use a minimum of memory. This was not only important for
the web apps but also for the node js code. A memory leak is something you
really don’t want to have when writing a nodejs app ;).

I think what helped us to keep the costs low, was that we used the same
language and therefore resulting code for the client, server and apps. But
this did not only allow us to work quickly, it will also allow us to add new
features quickly in the future. If we now write a new feature, as soon as we
release it, it will be available to users that use our website as well as
users that are using our Android / iOS apps either on their phone or tablet.
The same is true for bugs, if we find a bug in the client and fix it, it will
be fixed for all our platforms.

The other big advantage was that all the know-how we had but especially the
one we acquired during the time we needed to build our project did benefit all
our platforms. We didn’t have to optimize our Java code for Android our
Objective-C or Swift code for iOS and our PHP, Ruby or .Net code for the
server. We just needed to optimize our Javascript code. We reduced the amount
of platform / language specific problems to a minimum. It is really great when
all your devs use (speak) the same language ;).

------
sockopen
No.

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

~~~
pboutros
The fact that you go to this effort is why I love HN.

~~~
emdd
If only we could get notifications for replies & a decent mobile app existed.

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

~~~
heywire
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 :) )

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

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

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

~~~
mmargerum
Yup. I've got iOS native code written for iOS 2 still runs like a champ. My 2
year old angular 1 code is looking like a total rewrite.

------
moribondus
Consider the following problem. If this very question is relevant, then your
project is not.

Would it have mattered what they had picked for Google Search? A web site or
an app? No. It would not have made any difference.

If what you are building is compelling to its users, they will want it badly.
Otherwise, regardless of how well you package it, it will be a waste of time.

You see, for example, companies choose SAP, and then they buy the servers,
desktops, and other hardware and software that is suitable for running in a
SAP context.

Nobody cares whether the SAP client is a desktop GUI or a web client. It is
immaterial. In other words, if that kind of things matter, your program
doesn't.

------
gallonofmilk
at first I rolled my eyes but by the end I was filled with sympathy and
agreement! spot on!

------
prozaic
if web is future then future is now!

------
meerita
1 dev = all 5 device dev = 5 apps

1 dev 100k 1*5 500k in salaries

------
Kazamai
I guess he hasn't heard of React Native...

~~~
mwcampbell
React Native is no panacea. For example, Discord has found it unsuitable for
Android so far. [1]

[https://discord.engineering/using-react-native-one-year-
late...](https://discord.engineering/using-react-native-one-year-
later-91fd5e949933#.a3kbj831w)

~~~
maelito
They tried it for Android at the "early stages". It may be better now ?

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

------
josh_carterPDX
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 :)

~~~
minimaxir
Hawking your own startup here doesn't make sense since the issues presented in
the rant discuss user-facing product architecture.

~~~
josh_carterPDX
It was done tongue and cheek. Sounds like that's frowned upon. Heard and
heard.

