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.
How are his points regarding computational performance and local handling of large amounts of data misinformed? There’s a reason why there is Wolfram|Alpha and Mathematica.
You're right of course, I didn't mean "all" of it by any means. In fact, last night I lamented about web app overhead and the effect on performance. That having been said, it doesn't make his bits about graphics acceleration, local caching or storage any less inaccurate.
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. “…
But what if the app stored the data in your own AWS account, encrypted with a key only you know? (That's what we're building at Filosync)
Probably still not acceptable for many of these situations, especially when you're signing these kinds of data custody agreements. Oftentimes they specify requirements for physical custody of the hardware, and even if they don't, adding third parties into the mix (Amazon and you) may make the auditing requirements more complicated.
A lot of the time, these requirements are more about auditing and liability than about technical security measures.
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."
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.
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.
20% is huge. If you have a product so good that 1 in 5 Mac owners will purchase it, don't hold back.
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.
> 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…
No offense, but with that intro to your post and the way you follow it up, you strike me as exactly the person in question who has been out of the web dev game for a bit and doesn't know how much it's progressed in the last 3 years alone.
It's not hard to do responsive design. Yes, in iOS world you can still hard code 5 layouts if you want. Those of us that have also done Android design work understand why that's untenable moving forward. I'll take relative layouts, etc and be very happy with Bootstrap/Foundation.
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. “…
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).
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).
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?
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.
> 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 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…
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.
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 se…
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 t…
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.