Live data from Hacker News

Why I Develop For The Mac

evanmiller.org

71–80 of 184 posts

Re: Why I Develop For The Mac

#72
post #59

Earlier quoted context omitted.

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

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.

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.

Re: Why I Develop For The Mac

#73

Earlier quoted context omitted.

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

No, it's just that when you go out the first time you pick the low hanging fruit.

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.

Re: Why I Develop For The Mac

#74
post #71
post #67

Earlier quoted context omitted.

C++11 looks better to me.

ObjC++ uses C++11 (plus you NEED ObjC/ObjC++ to make calls to Cocoa).

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.

Re: Why I Develop For The Mac

#75

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

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.

Re: Why I Develop For The Mac

#76
> So I'm left with , and 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/

Re: Why I Develop For The Mac

#77

Earlier quoted context omitted.

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…

> So, if 20% of them bought your app for $1 you'd be $13 million dollars richer. http://sivers.org/1pct

> http://sivers.org/1pct

GP is not an exemplar of the 1% fallacy. GGP asserted that their product would have a 20% install base, so GP used that number.

Re: Why I Develop For The Mac

#78

Earlier quoted context omitted.

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…

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.

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

Re: Why I Develop For The Mac

#79

> So I'm left with , and 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 element…

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

Re: Why I Develop For The Mac

#80

Earlier quoted context omitted.

> 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 unt…

This made me scratch my head. Desktop apps have been accommodating multiple screen and window sizes since before the Internet existed. Do you think we hard-code a separate layout for every window size?

I don't know if responsive design is "hard" or not, but I observe that on the web, fixed widths are still incredibly common, and even major sites break easily. I visit Google, and if my window size is not at least one thousand pixels, the Sign In button is clipped and not initially visible. This would simply be considered a bug in a desktop app.

Besides, I always thought that layout was one of the weakest parts of HTML and CSS - witness the endless parade of hacks to achieve equal height columns.

Post reply on HN