Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Develop For The Mac

evanmiller.org

Post reply on HN
Print view View original

91–100 of 184 posts

Re: Why I Develop For The Mac

#91

Post by blub »

drivebyacct2 wrote: post #39
rimantas wrote: post #36

Earlier quoted context omitted.

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

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

I agree about Reddit, Twitter, etc, but the fact that these apps even exist and they're so popular tells a lot about the capabilities of web apps. It's so bad that websites create apps to access websites and on HN people applaud the huge progresses in web design...

Re: Why I Develop For The Mac

#92

Post by ccgus »

stevejohnson wrote: post #49
pcwalton wrote: post #35

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

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.

Re: Why I Develop For The Mac

#93

Post by jamespo »

shmerl wrote: post #74
mhenr18 wrote: post #71

Earlier quoted context omitted.

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.

Mac users typically don't like non-native UI apps

Re: Why I Develop For The Mac

#94

Post by shmerl »

jamespo wrote: post #93
shmerl wrote: post #74

Earlier quoted context omitted.

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.

Mac users typically don't like non-native UI apps

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

Re: Why I Develop For The Mac

#95

Post by martian »

zenocon wrote: post #4

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.

Your comparison of Wizard with Refine is misguided. The two products do completely different things. Refine "refines" data into a usable form. Wizard is a stats and visualization tool for understanding an already-clean dataset. Last I checked, Refine actually runs a local web server, even if its client is in the browser, so it's not that different from a native app. Wizard also does incredible amounts of visualization that Refine doesn't do.

(disclaimer: I purchased Wizard a few months ago and have been exceptionally happy with it -- it's a brilliant product)

Re: Why I Develop For The Mac

#96

Post by takluyver »

mmariani wrote: post #81
sidcool wrote: post #38

How do you define 'fast enough'?

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.

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

Re: Why I Develop For The Mac

#97

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

Re: Why I Develop For The Mac

#98

Post by rytis »

millstone wrote: post #80
drivebyacct2 wrote: post #45

Earlier quoted context omitted.

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…

As someone who is not a "web designer", but occasionally have to knock up a page or two I agree with you all 100%. To me the whole CSS business is just a big hack, and not at all usable or intuitive. YMMV, but I think there's a reason why people come up with [1] type jokes...

[1] http://bethesignal.org/wp-content/uploads/2009/06/css-is-awe...

Re: Why I Develop For The Mac

#99

Post by simonsarris »

drewcrawford wrote: post #89
simonsarris wrote: post #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 element…

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

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/

Re: Why I Develop For The Mac

#100

Post by adventureloop »

PavlovsCat wrote: post #83
fsckin wrote: post #2

>OpenGL is simply not a good option for 2D text-heavy graphics. So I'm left with , and is slow. That's what we call throwing the baby out with the bath water. What's wrong with using an orthographic frustrum?

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.

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

Post reply on HN