25 ms·

Why I Develop For The Mac

263 points by plinkplonk 13y ago

fsckin 13y ago
>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?
- Keyframe 13y ago
  Maybe he meant WebGL, but even then it could be done very well as with more modern OpenGL variants with bitmapped font tables. OpenGL on Mac is 3.2 IIRC. Nvidia recently tinkered with proprietary version of OpenVG with beautiful text rendering capabilities. There are numerous ways to make great text with OpenGL be performant with native code. Even GUIs with IMGUI approach. Some of those techniques could be done with WebGL, I'm sure. So, I don't really understand his point about text and OpenGL a no go Sure, WebGL is not all you can get with native and OpenGL, but nowhere near a fiasco in performance.
- PavlovsCat 13y ago
  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 13y ago
    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 http://blog.wolfire.com/2013/03/High-quality-text-rendering
tannerc 13y ago
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 http://daringfireball.net/2013/04/web_apps_native_apps
- zenocon 13y ago
  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-love-story http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
  - chenglou 13y ago
    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.
  - coolsunglasses 13y ago
    They had to do more work, relatively speaking, to make that work well than it would've taken to do the same with a native app. Sencha's little demonstration was the very definition of "bending over backwards".
zenocon 13y ago
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/ https://code.google.com/p/google-refine/ which is a similar tool to his Wizard tool, with a web front-end.
- rimantas 13y ago
  > 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.
  - drivebyacct2 13y ago
    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.
    - millstone 13y ago
brianwillis 13y ago
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.
- makeset 13y ago
  Your ISP might also be proxying YouTube IPs to local cache servers, the way Time Warner does in the US (though not necessarily improving performance, judging by the recent excitement over how to disable it).
- driverdan 13y ago
  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.
_nato_ 13y ago
Evan.. nice to see you on the top slot on HN! Thoughtful blog post as usual.
sergiotapia 13y ago
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.
- daniel-cussen 13y ago
  At the same time, every member of that 10% bought a Mac desktop, and therefore bought a product with high margins. If 10% of your potential audience has no problem buying software, especially high-margin software, they'll be easier to sell high-margin software to.
- babarock 13y ago
  That's about 2% of the total amount of desktops. I don't know the exact numbers, but I assume that it amounts to several dozens of million sales. Are we getting so disillusioned that we consider to be "such a small potential userbase"?
  - jacquesm 13y ago
    No, it's just that when you go out the first time you pick the low hanging fruit.
    - nicholassmith 13y ago
      It's great going for low hanging fruit, but you need to be realistic about things as well. Bigger market means more sales, but potentially only at a lower cost. Markets are a funny old beast.
- Samuel_Michon 13y ago
  There are 75 million Mac users, many of whom have iTunes accounts and credit cards on file – they can buy from the Mac App Store with a single click. 20% of 75 million is 15 million. 15 million copies of any paid app is huge. Also, let’s not forget that Mac sales has been growing for years, while the PC market as a whole has been shrinking. Today, there are 3 times as many Mac users than 5 years a go.
obviouslygreen 13y ago
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 13y ago
  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 13y ago
    That's not even 10% of the article.
    - samastur 13y ago
      So? If that was enough to make a specific point, why should he use more words?
- scott_s 13y ago
  He was being very careful to not overstate his claims, or even to appear to be overstating his claims. Considering how people in forums typically respond, I understand why.
imechura 13y ago
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.
- zenocon 13y ago
  This is a great point, but also orthogonal to the tech/platform choice. One can still develop a front-end using web tech which connects to a localhost server (see for example Google Refine -- which runs a localhost web server). It may make packaging and distribution it tad more annoying, but there are tools that can do this, and then you get the benefit of cross-platform adoption -- as well as the option to make it a hosted service, if desired.
  - claudius 13y ago
    > a front-end using web tech which connects to a localhost server But what advantage does that offer over a native application? You’d then need a ‘native’ web server and would still rely on the local browser in a way that opens you up to more incompatibilities than just using the native interface framework?
    - jfb 13y ago
      Ease of development for folks who aren't platform-native. Doesn't appeal to me, but then, I've parted ways with web applications.
      - claudius 13y ago
drivebyacct2 13y ago
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.
- micampe 13y ago
  The reverse is also often true.
- claudius 13y ago
  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.
  - drivebyacct2 13y ago
    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.
- rimantas 13y ago
  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 13y ago
freyrs3 13y ago
> 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 13y ago
  I sure hope compilers haven't been twiddling their thumbs for the past decade.
  - Narishma 13y ago
    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 13y ago
      LLVM especially llvm-polly seems to be the state of the art, at least of the open source auto-vectorization routines.
jokoon 13y ago
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 13y ago
  Perhaps you could paste the error text somewhere?
  - jokoon 13y ago
    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.
reion 13y ago
My favourite "OpenGL is simply not a good option for 2D text-heavy graphics."
- checker659 13y ago
  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.
- pjmlp 13y ago
  Actually it is quite true, contrary to many other 3D graphics APIs, OpenGL lacks support for text rendering. It is up to you to somehow transform text into 3D graphics operations.
pcwalton 13y ago
> 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.
- checker659 13y ago
  Yes, Skia makes use of SSE2/3. He pulled that right out of his ass.
- stevejohnson 13y ago
  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 13y ago
    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 13y ago
      > 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.)
sidcool 13y ago
How do you define 'fast enough'?
- mmariani 13y ago
  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 13y ago
    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-limits/ http://www.nngroup.com/articles/response-times-3-important-l...
  - sidcool 13y ago
    Sounds very logical. Thanks for your response.
shmerl 13y ago
Objective C? What for, when there is C++.
- kybernetyk 13y ago
  Or ... Objective-C++.
  - shmerl 13y ago
    C++11 looks better to me.
    - mhenr18 13y ago
      ObjC++ uses C++11 (plus you NEED ObjC/ObjC++ to make calls to Cocoa).
      - shmerl 13y ago
        That's my point. Learning the language just to use some platform specific non portable technology like Cocoa? No thanks. Better to stick with what's reusable, like C++ and Qt.
        jamespo 13y ago
        Mac users typically don't like non-native UI apps
        shmerl 13y ago
        This is not specific to Mac users. Most prefer applications which integrate with their desktop environment well. It's a tradeoff. Using something like Qt will try to mimic the native UI close enough, even if not 100%. But saves you the time on learning each native toolkit. I'd say it usually pays off, and that small percent doesn't worth the effort (especially if the project is supposed to be cross platform).
rubyrescue 13y ago
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 13y ago
  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.
bcoates 13y ago
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 13y ago
  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 13y ago
    That's assuming that the app store is the only way to distribute mac apps which, unlike iOS, it isn't.
    - visualR 13y ago
      Correct but if your not on the app store, who will know about your app.
      - tonyedgecombe 13y ago
        I seem to remember people were selling software for the Mac before the app store came along.
        visualR 13y ago
        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.
      - pjmlp 13y ago
        Given the amount of applications on the app store, it is as hard to find anything as anywhere else. Plus, people are selling desktop applications since the dawn of home computing, nothing new there.
simonsarris 13y ago
> 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 http://magicmaps.evanmiller.org/gallery.html [2] http://raphaeljs.com/world/ http://raphaeljs.com/world/
- ricardobeat 13y ago
  Yes, SVG is the perfect tool for this, and I bet there is no visualization library remotely as awesome as D3 for the desktop: https://github.com/mbostock/d3/wiki/Gallery https://github.com/mbostock/d3/wiki/Gallery
  - Intermernet 13y ago
    You can use D3 on the desktop as far as I know. It's a JS library.
    - 13y ago
pjmlp 13y ago
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.
- klibertp 13y ago
  That's nice sentiment from developer perspective. For a manager or entrepreneur it would be an unacceptable waste of time and money, so I don't think it's going to happen anytime soon.
  - pjmlp 13y ago
    Why? I work for a consulting company which does all kind of projects, and I jump from joy every time I get to chose a native project instead of a web one. It all depends on the market you are aiming for.
- MarkMc 13y ago
  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 13y ago
    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 -> ;
  - pjmlp 13y ago
    Only if you are speaking about database frontends that are nothing more than enhanced versions of "form submit", which used to be done in RPG, COBOL, CLIPPER, VB and now Web. There are many other areas when desktop is still the way to go.
static_typed 13y ago
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.
deleted 13y ago
[deleted]
eslaught 13y ago
> 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.pdf http://theory.stanford.edu/~aiken/publications/papers/pldi13... 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/ http://terralang.org/
lettergram 13y ago
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.
hcarvalhoalves 13y ago
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.
rjempson 13y ago
Buyer's pride perhaps?
jonknee 13y ago
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.
samastur 13y ago
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.
dvhh 13y ago
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.

263 points by plinkplonk 13y ago

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

Keyframe 13y ago
Maybe he meant WebGL, but even then it could be done very well as with more modern OpenGL variants with bitmapped font tables. OpenGL on Mac is 3.2 IIRC. Nvidia recently tinkered with proprietary version of OpenVG with beautiful text rendering capabilities. There are numerous ways to make great text with OpenGL be performant with native code. Even GUIs with IMGUI approach. Some of those techniques could be done with WebGL, I'm sure. So, I don't really understand his point about text and OpenGL a no go Sure, WebGL is not all you can get with native and OpenGL, but nowhere near a fiasco in performance.
PavlovsCat 13y ago
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 13y ago
  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 http://blog.wolfire.com/2013/03/High-quality-text-rendering

tannerc 13y ago

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 http://daringfireball.net/2013/04/web_apps_native_apps

zenocon 13y ago
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-love-story http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
- chenglou 13y ago
  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.
- coolsunglasses 13y ago
  They had to do more work, relatively speaking, to make that work well than it would've taken to do the same with a native app. Sencha's little demonstration was the very definition of "bending over backwards".

zenocon 13y ago

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/ https://code.google.com/p/google-refine/ which is a similar tool to his Wizard tool, with a web front-end.

rimantas 13y ago
> 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.
- drivebyacct2 13y ago
  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.
  - millstone 13y ago

brianwillis 13y ago

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.

makeset 13y ago
Your ISP might also be proxying YouTube IPs to local cache servers, the way Time Warner does in the US (though not necessarily improving performance, judging by the recent excitement over how to disable it).
driverdan 13y ago
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.

_nato_ 13y ago

Evan.. nice to see you on the top slot on HN! Thoughtful blog post as usual.

sergiotapia 13y ago

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.

daniel-cussen 13y ago
At the same time, every member of that 10% bought a Mac desktop, and therefore bought a product with high margins. If 10% of your potential audience has no problem buying software, especially high-margin software, they'll be easier to sell high-margin software to.
babarock 13y ago
That's about 2% of the total amount of desktops. I don't know the exact numbers, but I assume that it amounts to several dozens of million sales. Are we getting so disillusioned that we consider to be "such a small potential userbase"?
- jacquesm 13y ago
  No, it's just that when you go out the first time you pick the low hanging fruit.
  - nicholassmith 13y ago
    It's great going for low hanging fruit, but you need to be realistic about things as well. Bigger market means more sales, but potentially only at a lower cost. Markets are a funny old beast.
Samuel_Michon 13y ago
There are 75 million Mac users, many of whom have iTunes accounts and credit cards on file – they can buy from the Mac App Store with a single click. 20% of 75 million is 15 million. 15 million copies of any paid app is huge. Also, let’s not forget that Mac sales has been growing for years, while the PC market as a whole has been shrinking. Today, there are 3 times as many Mac users than 5 years a go.

obviouslygreen 13y ago

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 13y ago
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 13y ago
  That's not even 10% of the article.
  - samastur 13y ago
    So? If that was enough to make a specific point, why should he use more words?
scott_s 13y ago
He was being very careful to not overstate his claims, or even to appear to be overstating his claims. Considering how people in forums typically respond, I understand why.

imechura 13y ago

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.

zenocon 13y ago
This is a great point, but also orthogonal to the tech/platform choice. One can still develop a front-end using web tech which connects to a localhost server (see for example Google Refine -- which runs a localhost web server). It may make packaging and distribution it tad more annoying, but there are tools that can do this, and then you get the benefit of cross-platform adoption -- as well as the option to make it a hosted service, if desired.
- claudius 13y ago
  > a front-end using web tech which connects to a localhost server But what advantage does that offer over a native application? You’d then need a ‘native’ web server and would still rely on the local browser in a way that opens you up to more incompatibilities than just using the native interface framework?
  - jfb 13y ago
    Ease of development for folks who aren't platform-native. Doesn't appeal to me, but then, I've parted ways with web applications.
    - claudius 13y ago

drivebyacct2 13y ago

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.

micampe 13y ago
The reverse is also often true.
claudius 13y ago
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.
- drivebyacct2 13y ago
  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.
rimantas 13y ago
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 13y ago

freyrs3 13y ago

> 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 13y ago
I sure hope compilers haven't been twiddling their thumbs for the past decade.
- Narishma 13y ago
  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 13y ago
    LLVM especially llvm-polly seems to be the state of the art, at least of the open source auto-vectorization routines.

jokoon 13y ago

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 13y ago
Perhaps you could paste the error text somewhere?
- jokoon 13y ago
  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.

reion 13y ago

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

checker659 13y ago
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.
pjmlp 13y ago
Actually it is quite true, contrary to many other 3D graphics APIs, OpenGL lacks support for text rendering. It is up to you to somehow transform text into 3D graphics operations.

pcwalton 13y ago

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

checker659 13y ago
Yes, Skia makes use of SSE2/3. He pulled that right out of his ass.
stevejohnson 13y ago
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 13y ago
  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 13y ago
    > 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.)

sidcool 13y ago

How do you define 'fast enough'?

mmariani 13y ago
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 13y ago
  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-limits/ http://www.nngroup.com/articles/response-times-3-important-l...
- sidcool 13y ago
  Sounds very logical. Thanks for your response.

shmerl 13y ago

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

kybernetyk 13y ago
Or ... Objective-C++.
- shmerl 13y ago
  C++11 looks better to me.
  - mhenr18 13y ago
    ObjC++ uses C++11 (plus you NEED ObjC/ObjC++ to make calls to Cocoa).
    - shmerl 13y ago
      That's my point. Learning the language just to use some platform specific non portable technology like Cocoa? No thanks. Better to stick with what's reusable, like C++ and Qt.
      - jamespo 13y ago
        Mac users typically don't like non-native UI apps
        shmerl 13y ago
        This is not specific to Mac users. Most prefer applications which integrate with their desktop environment well. It's a tradeoff. Using something like Qt will try to mimic the native UI close enough, even if not 100%. But saves you the time on learning each native toolkit. I'd say it usually pays off, and that small percent doesn't worth the effort (especially if the project is supposed to be cross platform).

rubyrescue 13y ago

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 13y ago
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.

bcoates 13y ago

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 13y ago
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 13y ago
  That's assuming that the app store is the only way to distribute mac apps which, unlike iOS, it isn't.
  - visualR 13y ago
    Correct but if your not on the app store, who will know about your app.
    - tonyedgecombe 13y ago
      I seem to remember people were selling software for the Mac before the app store came along.
      - visualR 13y ago
        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.
    - pjmlp 13y ago
      Given the amount of applications on the app store, it is as hard to find anything as anywhere else. Plus, people are selling desktop applications since the dawn of home computing, nothing new there.

simonsarris 13y ago

> 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 http://magicmaps.evanmiller.org/gallery.html [2] http://raphaeljs.com/world/ http://raphaeljs.com/world/

ricardobeat 13y ago
Yes, SVG is the perfect tool for this, and I bet there is no visualization library remotely as awesome as D3 for the desktop: https://github.com/mbostock/d3/wiki/Gallery https://github.com/mbostock/d3/wiki/Gallery
- Intermernet 13y ago
  You can use D3 on the desktop as far as I know. It's a JS library.
  - 13y ago

pjmlp 13y ago

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.

klibertp 13y ago
That's nice sentiment from developer perspective. For a manager or entrepreneur it would be an unacceptable waste of time and money, so I don't think it's going to happen anytime soon.
- pjmlp 13y ago
  Why? I work for a consulting company which does all kind of projects, and I jump from joy every time I get to chose a native project instead of a web one. It all depends on the market you are aiming for.
MarkMc 13y ago
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 13y ago
  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 -> ;
- pjmlp 13y ago
  Only if you are speaking about database frontends that are nothing more than enhanced versions of "form submit", which used to be done in RPG, COBOL, CLIPPER, VB and now Web. There are many other areas when desktop is still the way to go.

static_typed 13y ago

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.

deleted 13y ago

[deleted]

eslaught 13y ago

> 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.pdf http://theory.stanford.edu/~aiken/publications/papers/pldi13... 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/ http://terralang.org/

lettergram 13y ago

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.

hcarvalhoalves 13y ago

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.

rjempson 13y ago

Buyer's pride perhaps?

jonknee 13y ago

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.

samastur 13y ago

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.

dvhh 13y ago

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.