Earlier quoted context omitted.
What does it mean, exactly?
It means let Apple do all the GUI work for you. And then let them change their designs, and the design of your app of course, according to their whims. Its okay, I understand I'm getting downvoted for not following along with the groupthink that Apple can't do anything wrong in the GUI department, and therefore native is far superior to anything else, but I've still got the opinion that the native GUI toolkits/framew…
Issues with Apple's iOS WebGL Implementation
21–27 of 27 posts
Re: Issues with Apple's iOS WebGL Implementation
#22Earlier quoted context omitted.
What does it mean, exactly?
It means let Apple do all the GUI work for you. And then let them change their designs, and the design of your app of course, according to their whims. Its okay, I understand I'm getting downvoted for not following along with the groupthink that Apple can't do anything wrong in the GUI department, and therefore native is far superior to anything else, but I've still got the opinion that the native GUI toolkits/framew…
I think this "persecution complex" is more groupthink that what you accuse as groupthink. There are tons of discussions on HN, and highly voted comments, about Apple's errors in GUI work (and elsewhere). They just happen to do a better job than 80% of the developers out there.
Furturmore, I disagree with the two basic premises of your comment:
1) Native doesn't mean "let the GUI to Apple". You conflate native with "follows a platform's GUI guidelines religiously".
You can create a great native app, using Cocoa APIs et al, that still looks totally different from Apple's apps. Take for example Paper for iOS. Or Procreate. Or Elements. Or tons of stuff, really.
You don't have to follow the GUI look at all, you can even have your own widgets for stuff. Just don't try using Swing in a Mac app, or some shitty Cocoa port on a Windows app. And let the common behavior of items like dropdowns and text-entry boxes be the same (e.g with regard to keyboard shortcuts).
But for those that do want to "leave the GUI" (well, look) to Apple, it's because it saves them tons of fucking work. Redundunt work of having to implement common stuff for themselves and their app.
2) Second, I don't think "native GUI toolkits/frameworks for each platform are really designed to lock users - and developers - into the platform" makes much sense.
What DEFINES a platform is the very presence of such things (native GUIs/frameworks, etc).
Without those, what you ask amounts to OS landscape where everything is the same generic base, sort of like FreeBSD/NetBSD/OpenBSD/etc but also at the desktop level.
What's the sense in having "platforms" for desktop OSes at all, if that's the case?
If you just want one OS to rule them all, for everybody, just ask for that. It makes no sense to want to have different platforms but still be bound to not have unique APIs and frameworks for each.
Re: Issues with Apple's iOS WebGL Implementation
#23Firefox crashed completely. Chrome popped up a "Rats! WebGL hit a snag".
So in a sense, iOS has reached feature parity :-)
Re: Issues with Apple's iOS WebGL Implementation
#24Though, I feel disappointed that the promises of "web app" were not really held so far (just look how you can't even open an external link in the browser from a webapp now), in favor of native apps, and hope that webGL in the browser isn't gonna be just another bittersweet thing.
I guess we can simply wait to see how the tickets you linked to will go to have a good sense about that.
Re: Issues with Apple's iOS WebGL Implementation
#25I just ran the Conformance test under Firefox (30.0) and Chrome (35.0). Firefox crashed completely. Chrome popped up a "Rats! WebGL hit a snag". So in a sense, iOS has reached feature parity :-)
Re: Issues with Apple's iOS WebGL Implementation
#26Earlier quoted context omitted.
It means let Apple do all the GUI work for you. And then let them change their designs, and the design of your app of course, according to their whims. Its okay, I understand I'm getting downvoted for not following along with the groupthink that Apple can't do anything wrong in the GUI department, and therefore native is far superior to anything else, but I've still got the opinion that the native GUI toolkits/framew…
> Its okay, I understand I'm getting downvoted for not following along with the groupthink that Apple can't do anything wrong in the GUI department I think this "persecution complex" is more groupthink that what you accuse as groupthink. There are tons of discussions on HN, and highly voted comments, about Apple's errors in GUI work (and elsewhere). They just happen to do a better job than 80% of the developers out t…
The point is, that this is an artificial arbitrary, a line drawn in the sand by market - not technological - forces, and to play along with it is to pander to the divide and conquer strategy begin applied in the effort to capture developer mindshare. Why deal with it at all, when .. with a little effort .. a cross-platform solution that works effectively on all platforms is a tangible, viable product? Just consider the amount of work that had to be done to update apps for the recent changes in iOS' look and feel, and consider what life would be like if instead the effort was made on a cross-platform solution that put the application-standard GUI together, driven by the application-developer, not OS/hardware vendors whose motives are entirely driven by keeping developers away 'from those other platforms'.
I've built big Android and big iOS projects. Neither one of them is better than the other, in any sense whatsoever; both platforms have their thorns and pitfalls, and maintaining two separate codebases, with all the pitfalls, is just counter-productive. Better to have one codebase that fits all and keeps the productivity where it needs to be: on the application, and not on keeping up with the joneses ..
Re: Issues with Apple's iOS WebGL Implementation
#27Earlier quoted context omitted.
> Its okay, I understand I'm getting downvoted for not following along with the groupthink that Apple can't do anything wrong in the GUI department I think this "persecution complex" is more groupthink that what you accuse as groupthink. There are tons of discussions on HN, and highly voted comments, about Apple's errors in GUI work (and elsewhere). They just happen to do a better job than 80% of the developers out t…
>It makes no sense to want to have different platforms but still be bound to not have unique APIs and frameworks for each. The point is, that this is an artificial arbitrary, a line drawn in the sand by market - not technological - forces, and to play along with it is to pander to the divide and conquer strategy begin applied in the effort to capture developer mindshare. Why deal with it at all, when .. with a little…
That's wrong. Platforms are different, and offer different APIs and frameworks, because of technological forces too, not just because of some corporate conspiracy for lock in.
Case in point, even Open Source OSes offer different platforms and incompatible frameworks. Not all are just a UNIX/POSIX clone.
VMS has a different philosophy to UNIX. Lisp Machines even more so. Windows. BeOS. Etc. And that's the core OS. The same goes for platforms and desktop level stuff.
Having the same stuff (APIs, GUIs etc) work in all platforms the same, kills diversification and competition between technological implementations and design philosophies.
>I've built big Android and big iOS projects. Neither one of them is better than the other, in any sense whatsoever; both platforms have their thorns and pitfalls, and maintaining two separate codebases, with all the pitfalls, is just counter-productive.
Well, that's like your opinion man. I find iOS vastly superior for most of my uses cases.
I surely don't wish iOS and Android got merged into the same codebase.