
Why I Develop For The Mac - plinkplonk
http://www.evanmiller.org/why-i-develop-for-the-mac.html
======
imechura
Developers, please take note of the authors statement below....

"Many developers assume that everyone wants their data to be “in the cloud”,
but that's actually not true for a lot of my customers. Professional
researchers often sign agreements in their children's blood stating that their
data will be stored on an encrypted disk, won't leave their laptop, and will
be destroyed when the research project is completed. “The cloud” is the last
place they want their data to go."

There are so many great note taking and productivity application that I just
can't use because the majority of my notes are of a confidential nature. If my
company provided macbook where to be compromised I would not be held liable,
however if my personal dropbox or evernote account where compromised I would
be held accountable.

~~~
jgrahamc
I'm very much in the camp of not wanting my data in the cloud. I don't
autoupload photos, for example, because I want control over them.

What I would like is a home cloud server which would handle all the services I
could get from the cloud with explicit sharing with chosen people (e.g. my
family).

~~~
johnrob
Isn't that just "security by obscurity"? Your home cloud server is probably
more accessible to hackers than an amazon server.

If you're ok with relying on obscurity, you already have it - you are one
person among billions on this planet. Who else cares about _your_ photos?

~~~
chmars
It's not only about protection from hacking, it's often also about protection
from access by authorities – in particular American authorities. Non-
disclosure agreements, data privacy laws and attorney-client privileges are
not compatible are simply not compatible with most hosted services, especially
not abroad where your local law cannot protect your local legal obligations.

------
simonsarris
> So I'm left with <canvas>, and <canvas> is slow.

I consider this a bit of a frustrating pseudo-myth. It's true canvas is slow
compared to lots of native drawing, but its usually presented as a false
equivalency issue. Canvas didn't set out to replace native drawing of hand-
crafted OpenCL. It's an alternative to cross-platform graphics on the web,
where you get Canvas or you get Flash (Or SVG or hobbling together colored DOM
elements to animate while crying and eating ice-cream out of a gallon tub.
We've been there. Don't lie.).

What's worse, looking at the videos demoing his Mac app[1], they don't even
look like they'd need canvas levels of performance. They look like they'd work
just fine in _SVG._ What's wrong in this case with the very good performance
across many platforms (even tablets) of the SVG-backed RaphaelJS?[2]

Unless his app can do things he'd rather not demo, I'm guessing this post is
moreso post-hoc rationalization of picking Mac as his preferred development
platform. At the risk of being a bit rude, it's worth noting that he doesn't
bother with all Desktops, just Mac, which causes further suspicion that this
is really just a rationalization piece and not about performance.

(Unrelated to the post at hand, this canvas pseudo-myth also upsets me because
I spend big chunks of free time helping people with their canvas work, and its
_almost always_ an issue on the programmer's part. This is fine, I've never
fault a programmer for writing less-than-optimal code, but often programmers
tend to contribute their voices to the chorus of "Canvas is slow", regardless
of looking for fault prior to their declaration.)

[1] <http://magicmaps.evanmiller.org/gallery.html>

[2] <http://raphaeljs.com/world/>

~~~
drewcrawford
> What's wrong in this case with the very good performance across many
> platforms (even tablets) of the SVG-backed RaphaelJS?

So I attempted to determine the accuracy of this claim. I ran a benchmark from
Kevin Roast [1] who seems to author a lot of Canvas demos. For each of the 8
tests in his benchmark, I recorded the FPS reading that I saw that was the
lowest (e.g., framerate dropped to X at some point during the 5-second test).

Mac iPad

20fps 16fps

29fps 18fps

30fps 21fps

30fps 30fps

28fps 6fps

29fps 18fps

29fps 7fps

12fps 30fps

mean_mac = 25.875, median_mac = 29 mean_ipad = 18.25, median_ipad = 18

On the Mac side, I can see both sides of the issue. Arguably 26-29fps in a
wide variety of situations is good enough for a wide variety of applications.
At the same time, I can understand the author really wanting to blow past
29fps.

On the iPad side, the issue is more clear. I think most people would say that
18fps is unacceptable for a drawing application.

(If these numbers are contributing to the "pseudo-myth" of slow Canvas
performance, please point me to a reasonable benchmark. This one is just the
most comprehensive one that I found.)

> At the risk of being a bit rude, it's worth noting that he doesn't bother
> with all Desktops, just Mac, which causes further suspicion that this is
> really just a rationalization piece and not about performance.

He addresses the choice of the Mac platform in some detail in the "Drawbacks"
and "Conclusions" section of the post. At the risk of being a bit rude, it's
poor form to dismiss someone's reasoning as a "rationalization" without
addressing the reasoning on the merits. To the extent that his choice of Mac
over Windows et al is specious, it is not a claim that is supported by your
comment.

[1] <http://www.kevs3d.co.uk/dev/canvasmark/>

~~~
simonsarris
In the sentence you quoted I'm referring to SVG, not canvas, and the "in this
case" refers to mapping apps, not games. I never made any claims with regards
to games.

In the test you quoted the goal is to stress it until it could only handle
30fps (it says so on the page), so you _necessarily_ must see 30fps for the
test to go on to the next one. That is why your median score on the Mac is
29fps, because it degrades smoothly on the desktop compared to a mobile
device.

If you want to see many devices peg 60fps on the canvas (the rate imposed by
requestAnimationFrame), you can use a demo like MS' Fish one.[1] Your Mac
ought to get 60fps for 1000 fish on a 1920 x 1075 canvas with no sweat. This
is not a very interesting test, and I don't know what it will look like on an
iPad, but it more than enough accounts for any animation you might see in a
_mapping application._

[1] <http://ie.microsoft.com/testdrive/performance/fishietank/>

~~~
Samuel_Michon
_“Your Mac ought to get 60fps for 1000 fish on a 1920 x 1075 canvas with no
sweat.”_

I just checked, and indeed, my new MacBook Air with external display ran it
just fine at 60fps. My 3 year old Mac mini handled 45fps. My iPad 4 managed to
crank out 25fps in a 981x644 window.

------
rubyrescue
This is written by someone who actually writes a popular web framework for
Erlang - the exact opposite of throwing a static site on S3. That gives this
piece more credibility - he knows how to build active server-side software as
well.

~~~
hawkw
Good point. I'm personally of the opinion that one should not publicly
denounce a thing unless they've spent time in the trenches trying to make it
work.

------
pcwalton
> Browser vendors with cross-platform drawing kits just don't invest the same
> kind of effort into drawing lines and circles. As a result, large <canvas>
> areas seem laggy on most browsers, whereas native apps “just work”. (“Are
> the graphics pre-computed?”)

This is incorrect. Firefox and Safari use Core Graphics (Quartz) just as Mac
native apps do. Things like lines and circles go through the exact same SSE-
accelerated routines. I don't know off the top of my head whether Chrome uses
Skia or Core Graphics on the Mac, but either way, its blitting routines use
SSE optimizations as well.

~~~
stevejohnson
Technical reasons aside, the canvas tag is still orders of magnitude slower
than writing Core Graphics by hand. Personally I'd say almost unacceptably
slow, but YMMV.

You succeeded in picking out a minor technical inaccuracy, but not in
addressing the point the author was making about rendering performance.

~~~
ccgus
One of the reasons it's slow is because CG bitmap contexts are pre-multiplied,
but the Canvas spec requires things to be not-premultiplied, so there's a bit
of extra math that needs to happen w/ Canvas vs. straight CG/Quartz.

~~~
daeken
> the Canvas spec requires things to be not-premultiplied

It does, but unfortunately neither Webkit nor Gecko respect this. Take a PNG
with an alpha channel and draw it to a canvas over a white div then read back
the pixels; you get the pixels premultiplied by the white behind it. Same with
other backing colors. There are cases where it won't premultiply, but
unfortunately they're a minority.

(The reason I ran across this particular case is that I use PNGs to compress
data, and using the alpha channel to store data is impossible because of the
premultiplication.)

------
tannerc
All good thoughts, and similar to why I develop native apps for iOS vs web
apps.

I think John Gruber summarized it nicely when he said: "Facebook, bless them,
has it right. What's great about the web is ubiquitous network availability,
not running within a browser tab. Websites are just services, and what you see
in a browser tab is merely one possible interface to that service. The best
possible interface to that service is often, if not usually, going to be a
native app, not a web app."[1]

1\. <http://daringfireball.net/2013/04/web_apps_native_apps>

~~~
zenocon
I think dismissing web tech b/c of what Facebook does or John Gruber says is
short-sighted. Case in point: the people over at Sencha rebuilt Facebook in
HTML5 to run faster than Facebook's native app [1]. It may take an additional
level of skill and careful planning...and it may be easier to shoot yourself
in the foot with a WebApp that provides a compelling experience with
performance on par with a native app, but that doesn't mean it can't be done.

1\. [http://www.sencha.com/blog/the-making-of-fastbook-an-
html5-l...](http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-
story)

~~~
chenglou
I've seen the case of Sencha Facebook app brought up many times now, but I've
never seen someone point out their huge flaw in the scrolling. At one point in
the demo, they trivially dismiss the fact that they made the scrolling inertia
smaller to give the data a chance to load; but that's in my opinion THE main
flaw of the app. As a matter of fact, that's the first thing I notice on every
web app I've seen to date: the quirky scrolling physics. For me, Sencha's
implementation falls right in that uncanny valley and it kills the UX of the
app each time for me. I don't see why they put so much emphasis on the loading
speed or smoothness (not that it's not important), when all this effort to
improve the UX is completely offset by the scrolling.

------
zenocon
I'm going to take a wild stab at the primary reason he develops on the Mac is
his own comfort and expertise with it - which is fine, of course. With the
advancements made in web tech today, I don't think all the performance reasons
he listed ring entirely true. See for example Google Refine
<https://code.google.com/p/google-refine/> which is a similar tool to his
Wizard tool, with a web front-end.

~~~
rimantas

      > his own comfort and expertise with it - which is fine, of
      > course. With the advancements made in web tech today
    

Do you have any expertise developing for desktop/native mobile? I have a lot
of expertise developing for the web—I've spent 4x as much being the web
developer before switching to iOS programming full-time and every time I see
someone presenting web tech as a superior way to build apps I have a hard time
taking this seriously. If there is a lack of expertise it must be the other
way: web devs don't know what native frameworks offer. Sure we can push and
twist and stretch a systems with foundations met for the marking-up document
structure and styling document presentation to fit the needs for the up, but
what's really the point? Yes there is the promise of develop once run on every
platform, which in practice is more like develop core once, endlessly tweak
for idiosyncrasies later. And when the web tech really works for mobile app it
usually just means that your app had to be a web page anyway.

~~~
zenocon
You've mis-read my statement as some sort of attack on native development and
counter-attacked accordingly - even personally? I never said web tech was
superior. I'm simply presenting a counter-argument to those that continue to
deride web development and claim it can't hold a candle to native apps. There
are endless examples of web applications done right that have compelling
experiences and perform on par with native apps. I've provided a couple of
examples in this thread, but there are countless others. I'm simply claiming
web apps can be done right.

~~~
tvon
You gave a very cavalier response.

> _I'm going to take a wild stab at the primary reason he develops on the Mac
> is his own comfort and expertise with it (...)_

This to me reads as "I'm not going to put much thought into this, but it
sounds like he is just ignorant."

Maybe you didn't intend it that way, but that's how it read to me.

~~~
zenocon
At the risk of sounding cavalier :) see
<https://news.ycombinator.com/item?id=5659447> \-- which is a better summary
of the point I was trying to make. It seems he likes the Mac native platform,
which is great, but don't try to sell me on the idea that all other platforms
and the web, in particular fall short.

~~~
scott_s
He's quite explicit in stating this his reasoning is for his specific problem.

------
brianwillis
_Sure, your web app might feel instantaneous when your server is sitting
across the LAN, but many users have crappy Internet connections, or are
downloading a Torrent, or are living in New Zealand..._

Yup. New Zealand's internet speeds are just abysmal. On behalf of kiwis
everywhere, can I ask that you all stop writing your own wrappers for web
based videos? Instead, upload your videos to YouTube and embed that on your
site. Their buffering is orders of magnitude better than some of the half
baked crap I see from other people, probably because streaming video is
YouTube's core business so they've focused a lot of time and attention on
getting it right. If you live in urban parts of United States or Asia it's not
a problem you'd notice, but for the rest of us it's a daily nuisance.

~~~
driverdan
On the other hand I have a great home internet connection here in the USA yet
YouTube is terrible for me. I constantly get HD video streaming at 250KB/s
which is well below the bitrate meaning I have to wait for it to buffer. And
yes, I've tried the hacks (blacklisting YT CDN IPs) to no avail.

------
pjmlp
With each web project I take part on, I feel more and more in sync with what
the author states.

The proper way is to have desktop applications that take proper advantage of
the hardware and operating system integration and use the network for
communication.

Leave the browser for the documents. No need for browser compatibility
headaches or JavaScript/CSS/HTML hacks.

Just use your favourite programming language and take advantage of the OS
capabilities to full extent.

~~~
MarkMc
I'm surprised by this sentiment. I thought web apps had 'won' on the desktop?
Is the pendulum starting to swing the other way?

~~~
Shorel
I do both.

Debugging CSS is much less fun than using a proven multiplatform C++ toolkit.
Only when node.js got popular I could write the ever reliable callbacks in my
web code, while I use them all the time in C++.

But of course there are more people who can write web apps than people who can
add this symbol at the end of the line -> ;

------
freyrs3
> Try running a profiler on a native Mac application that does a fair amount
> of drawing. You'll see references to function calls like: sse64CGSFill8by1

Try running a disassembler on any compiled graphic applications of the last 10
years on any platform and you'll see SSE instructions.

~~~
hornetblack
I sure hope compilers haven't been twiddling their thumbs for the past decade.

~~~
Narishma
You mean developers, right? Compiler auto-vectorization hasn't really advanced
that much. You still need to manually use SIMD intrinsics (or inline asm) to
get any kind of worthwhile performance increase.

~~~
freyrs3
LLVM especially llvm-polly seems to be the state of the art, at least of the
open source auto-vectorization routines.

------
obviouslygreen
More accurately: _Why I develop this specific class of applications for the
desktop rather than the web._ This is basically what the author is talking
about despite the generalization regarding desktop apps; if he's going to
stick with that he should have gone with "desktop" instead of "mac."

~~~
pooriaazimi
You seem to have missed the whole "Features" section. Here's a list of what he
said he gains "for free" by developing for Mac (of course, other environments
might have similar stuff, but not exactly like OS X's): Undo/Redo with Core
Data, PDF export (and "import" into current documents), Multi-touch zoom.

~~~
checker659
That's not even 10% of the article.

~~~
samastur
So? If that was enough to make a specific point, why should he use more words?

------
fsckin
>OpenGL is simply not a good option for 2D text-heavy graphics. So I'm left
with <canvas>, and <canvas> is slow.

That's what we call throwing the baby out with the bath water. What's wrong
with using an orthographic frustrum?

~~~
PavlovsCat
I think the keyword is "text-heavy". Rendering 256 characters into a texture
to use with WebGL is one thing, but what about unicode, or readability at
small sizes? I'm honestly asking, I'd love to hear about ideas or libraries
etc.

~~~
adventureloop
In OpenGL you can use CoreGraphics to render into a context and convert that
data to a texture. This could be done for each string, but doing so you loose
the power of the underlying implementation. If there are libraries that make
this easier I am yet to come across them.

Wolfire have written a very good blog post about the issues with text
rendering and OpenGL. <http://blog.wolfire.com/2013/03/High-quality-text-
rendering>

------
sergiotapia
I would love to make Mac applications but the prospect of having such a small
potential userbase makes it a non-option for me.

Imagine, 10% of desktops have Mac OS, of that only 20% will buy my
application; that's a very small user base.

~~~
jscipione
Well, according to this [1] the Mac install base is around 66 million users.
So, if 20% of them bought your app for $1 you'd be $13 million dollars richer.
That seems worth it to me. It seems that you are underestimating the size of
the market and potential the to make money by writing applications for the
Mac. You are also ignoring the fact that Macs sell at a premium so those 66
million represent not the bottom end of the market, but those with money to
purchase services to make their lives easier.

[1] <http://aaplinvestors.net/stats/mac-installed-base/>

~~~
Samuel_Michon
Those numbers are one year old (WWDC 2012). In the meanwhile, Apple has sold
17 million Macs. Mac install base is closer to 75 million.

~~~
stcredzero
A lot of those are going to be replacements for existing Macs, however. (Mac
user since original 128k.)

~~~
Samuel_Michon
My estimate of 75 million was conservative, it’s closer to 80 million.

Half of all new Macs are sold to people who are ‘new to Mac’[1]. Even the
people who buy a replacement for their old Mac will often find other uses for
that old Mac or they will sell it or give it away.

One year a go, Mac install base was 66 million. Since then, 17 million Macs
have been sold. 8.5 million of those are sold to people who never owned a Mac
before. Let’s imagine that all the remaining 8.5 million units are bought by
existing Mac users, and that half of them are bought because the old Macs
died. That gives us a new total of 78.75 million.

[1]
[http://www.forbes.com/sites/carminegallo/2012/07/25/7-sure-f...](http://www.forbes.com/sites/carminegallo/2012/07/25/7-sure-
fire-ways-apple-store-converts-browsers-into-buyers/)

------
lettergram
Until instantaneous data transfer discovered (where the speed of light isn't
the limit), the closer one is to the processor the faster the application will
be. The point being that with data manipulation unless you have a huge
bandwidth, the packet size can match and the ability to assure rare outages
(if ever) applications on ones personal computer, with personal data will
always be faster. The point being is all the discussion regarding performance
on desktops vs web applications is moot when we are at least a decade away
from everyone having internet connections capable of instantaneously
transferring hundreds of megabytes of data.

Personally, I can barely stand web applications, I want my computer to move as
fast or faster than I think.

------
bcoates
I was experiencing some native-client nostalgia for a bit until I got to "beg
Apple to perform an expedited review of the fixes." Seriously? _Fuck that
shit_. I'll keep my lousy performance and server maintenance woes, thanks.

~~~
visualR
This is exactly why I stopped developing for native. If you want to fix a bug
or tweak/add one little feature its a huge ordeal. Plus the 30% tax on non-
recurring revenue. I'm glad he's doing mac apps. Less competition in the web
space.

~~~
oneeyedpigeon
That's assuming that the app store is the only way to distribute mac apps
which, unlike iOS, it isn't.

~~~
visualR
Correct but if your not on the app store, who will know about your app.

~~~
tonyedgecombe
I seem to remember people were selling software for the Mac before the app
store came along.

~~~
visualR
Im just saying your giving up a major marketing outlet if you arnt on the MAS.
Of course you can go it alone, but since it is a MAC app, that would be
foolish.

------
samastur
I find this article a very good example of how you can try your very best to
describe in reasonable terms and tone why a certain decision was the right one
for you, but that won't stop a bunch of people who know neither you nor your
business to tell you why your opinion and you personally suck.

------
reion
My favourite "OpenGL is simply not a good option for 2D text-heavy graphics."

~~~
checker659
Well, the raw GPU interface IS not good for 2D text-heavy graphics!! I mean
you could render to an offscreen framebuffer but doing it on the CPU is much
more convenient.

------
eslaught
> nothing beats multithreaded C and vectorized assembly code

I think Terra would give you a run for your money:

[http://theory.stanford.edu/~aiken/publications/papers/pldi13...](http://theory.stanford.edu/~aiken/publications/papers/pldi13.pdf)

From the paper:

> Our Terra-based auto- tuner for BLAS routines performs within 20% of ATLAS,
> and our DSL for stencil computations runs 2.3x faster than hand-written C.

See also:

<http://terralang.org/>

------
jonknee
That's also why few people will ever use his applications. Javascript might be
more limiting, but it can open your app up to orders of magnitude more users.

------
dvhh
I somehow feel that he misses the point, "web app" and "desktop class app"
usually have very different purpose and goal. It almost sound like to me: fuck
these gui app console app are way faster, and see how easy it is to run them
on headless server.

------
hcarvalhoalves
I don't think it requires too many explanation to point that out. It suffices
to compare Cocoa with the clusterfrack that it is shoehorning UIs in the
browser.

That said, he points out performance, which is a pretty poor reason nowadays.

------
_nato_
Evan.. nice to see you on the top slot on HN!

Thoughtful blog post as usual.

------
jokoon
answer: become nobody really wants to do it, and obviously the supply/demand
system might be really rewarding.

I recently (today) stopped to try to make some simple ogre3d application
because somehow xcode can't manage permissions to create a file somewhere.

~~~
astrange
Perhaps you could paste the error text somewhere?

~~~
jokoon
make error cannot copy create file in /path/hft7ahd7wtyc7hoy4awt/blabla/thing

I had already searched and found people with the same problems, but it boils
down to hardship between xcode and cross-platform build software like cmake
and others.

I don't want to bash apple, but it feels awkward to be a dev and watching
apple digging up their NS tech to put in everyone's mouth, even if there are
business with big working c++ codebases. Being incompatible with the
competition is still a strategy, even if apple use unix-flavored stuff.

------
rjempson
Buyer's pride perhaps?

------
sidcool
How do you define 'fast enough'?

~~~
mmariani
If you return control to the user under 150ms your app will fell quite snappy.
From 150ms to 200ms is okay too. Anything above 250ms is noticeable and
considered by many as sluggish.

~~~
takluyver
Another rule of thumb that's used is that responses within a tenth of a second
feel instant, within a second will keep the user focussed, and you can get up
to about ten seconds before they'll want to do something else while they wait.

Source: [http://www.nngroup.com/articles/response-
times-3-important-l...](http://www.nngroup.com/articles/response-
times-3-important-limits/)

------
shmerl
Objective C? What for, when there is C++.

~~~
gte910h
C++ isn't a pure win. It's far more complex, and leaky abstraction wise than
Objective C is. MOST people write mac and iOS apps in Objective C, and it
works well, is predictable. It's also far easier to find people who do Obj-C
well than C++ (in the mac environment, but this holds for all systems I've
ever seen as well).

~~~
cageface
The worst thing about C++ for UI work is that it offers essentially no
introspection and is a nightmare for tools authors. It's good for writing
high-performance application kernels but for everyday UI building it's just
overly complex and awkward.

~~~
blub
Also agree that QML is light years ahead of anything else for UI work.
Declarative is the way to go, but most are focusing in the wrong direction
(e.g storyboards).

Any programming language will be awful for UIs, be it C++, Obj-C, Python or
C#.

------
drivebyacct2
Having a hard time phrasing this without being a jerk, but many of these
"native is better than web" psuedo-rants contain misinformation or seem to be
lacking in an understanding of the current state of web technologies like
persistance, app caching, etc, etc.

~~~
rimantas
Sorry, but I guess you lack in the understanding of both. Yeah, app caching
looks nice in theory. Now implement it reliably in practice. What will you use
in the place of Core Data? Local storage? IndexedDB(with no support in default
browser both on iOS and Android)? How will your replacement for UITableView
with reusable cells look like? How about the same combined with
UIFetchedResultController? I am not even talking about Core Graphics,
animation, etc, etc. Sorry, but anyone really wanting to advance web tech on
mobile should first learn what native SDKs really offer. And then think long
and think hard about an answer to this question: "Should we?Why?". How about
finding the way finally to serve responsible images on the web instead of
fighting wars against native apps?

~~~
drivebyacct2
I'm well aware of what native SDKs offer. I don't know why you assumed I'm
unfamiliar with native development.

As for the last statement, and much of the others, I'm not even sure what
you're asking. If you want a nice syntax for it, then yeah, wait for the spec
to be finished. Otherwise, you're probably implementing that logic yourself.
The same as if you want a native app to pull in different assets (unless we're
talking about UI assets and a sane OS, but still, it's not like that's a
compelling lacking feature).

Look, I'd be happy to be wrong but there are half a dozen inaccuracies in this
very article about what is possible with web technology and how browsers
themselves work.

Am I suggesting Angry Birds in web tech (even though it's already been done):
No. Am I suggesting that shit basic apps like Facebook, Twitter, Reddit, etc
make more sense as simple, functional, accessible webapps? Absolutely.

~~~
gdubs
FWIW Facebook's HTML5 app was terrible. They recently made a switch back to
native.[1]

1: [https://www.facebook.com/notes/facebook-engineering/under-
th...](https://www.facebook.com/notes/facebook-engineering/under-the-hood-
rebuilding-facebook-for-ios/10151036091753920)

~~~
drivebyacct2
And then Sencha remade it and it managed to be faster than the native app.
Also note that the actual mobile Facebook site remains as fast as the native
app and was always faster than the "native" app that just used webtech. So,
ironically, the webapp still wins when used and developed properly for a
Facebook type app.

~~~
kenjackson
Native apps should always be faster except in the case where the native app
isn't architected properly or web services are poorly implemented.
Unfortunately, I've seen that both are often the case.

For CRUD apps like Facebook, it's often easier to do them right as web apps,
but a good native app developer with a good backend team should almost always
be able to beat them.

~~~
drivebyacct2
In that case it's incredibly disappointing that Twitter or Facebook's mobile
apps continue to be every bit as fast as their native apps. I KNOW that you
are right, as I've said, I'm well aware and worried of the overhead of doing
things like video decoding in the browser... but for literally a few http
requests, infinite scrolling and TEXT... (which is Facebook, Twitter,
Instagram, Path, etc, etc, etc)... Chrome for Android is simply going to be as
fast as the native app.

------
static_typed
Someone develops for the Mac because thinking about cross platform and making
it work in the browser is too hard, so we'll just bet the farm on letting
Apple handle the hard stuff, and hope that performance doesn't later drop off,
and then clients ask why it is no longer so good, and I say "but, I develop on
this closed platform, and it should be good..." etc.

