I heard someone say that developing on the mac using cocoa is great for rapid development.
Is it a good framework for building GUI based apps relatively fast?
Here's for some historical perspective:
The Cocoa framework evolved from the NeXTSTEP framework when Apple bought NeXT (and Steve Jobs along with it) to form the basis of OS X. This is why you see lots of NS littered throughout Cocoa. And NeXTSTEP was one of the earliest frameworks to call itself a RAD framework. So from that point yes, Cocoa is a RAD framework.
There was a famous demo of how fast you can develop apps in NeXTSTEP where a full-fledged text editor (with font selection, file load/save, everything) was developed during the course of the demo (I believe it was under 30 minutes).
Another famous use of NeXTSTEP was the invention of the World Wide Web. Basically HTTP and HTML. Legend has it that Tim Berners-Lee cooked up HTTP and HTML and prototyped the worlds first web browser and web server in just a couple of days. And remember, that first web browser had the ability to edit as well as view HTML -- yes, the original internet was a giant Wiki!
Even at the time it was released as Cocoa around 96/97 it was still considered one of the top RAD environments around. This was around the time Borland was heavily positioning Delphi as a RAD environment and Microsoft's MFC was painful to use in comparison.
These days I would say that it is roughly comparable to .Net. Though I personally feel (and I know lots of long-time Cocoa programmers tend to share this sentiment) that Cocoa still has an edge in how fast I can take an idea to completion and how clean the resulting code is. It's an older framework, more mature and implemented lots of things right but other frameworks have had lots of time to catch up.
I strongly believe the combination of Interface Builder and Cocoa makes prototyping an application faster than anything else I've used. Typically, creating something that is 'visible' takes just a few minutes using IB to wire controls to code, and a few more to write the code itself. Factor in the modular nature of View Controllers and the process of adding GUI elements to a large codebase is suddenly very easy. The next version of Xcode makes this process even faster, so I daresay you've got a lot to look forward to.
If you are familiar with the tools and willing to work with the provided UI elements then I think so. However because you're working with a fairly rich and stateful UI once you decide that you need custom views then you have signed up for some real work.
Overall I find web development slightly faster, largely because there's a wider selection of available libraries and frameworks to build on, but that's only an alternative for certain types of applications.
Related
I know this sounds a little bizarre, but there is a very simple application I want to write, a sort of unique image viewer, which requires some interactivity with the host system at the user level. Simplicity when developing is a must as this is a very small side project. The project does require some amount of graphical work and quite a bit of mouse based interactivity (as well as some keyboard shortcuts), but quite frankly, I don't want to dig my hands into OGL for something this small. I looked at the available options, and I think I've narrowed it down to two main choices: Webkit (through either QtWebkit or WebkitGtk), and the language Processing.
Since I haven't actually used Processing but I do have some amount of HTML5 canvas and Javascript experience, I am somewhat tempted to using a Webkit based solution. There are however, several concerns I have.
How is Webkit's support for canvas, specifically for more graphically intensive processes?
I've heard that bridging is handled better in QtWebkit than WebkitGtk. Is this still true?
To what degree can bridging actually do? Can a Webkit based application do everything that an application which interacts with the files on the system needs?
Looking at Processing, there are similarly, a couple things I'm wondering.
Processing is known for its graphical capabilities, but how capable is it for writing a general everyday desktop application?
There are many sources that link Processing to Java, both in lineage as well as in distributing applications over the web (ie: JApplets). Is the "Application Export" similarly closely integrated with Java?
As for directly comparing the two, the main concern I do have is the overhead of each. I want the application to start up as snappy as possible, and I know that Java has a bit of an overhead regarding start up because it first has to start up the interpreter. How do Processing and QtWebkit/WebkitGtk compare for start up?
Note that I am targeting the Linux platform only.
Thanks!
It's difficult to give a specific answer, because you're actually asking a few different kind of questions - and some of them you could be more precise.
Processing is a subset or child of java - it's really "just" a java framework with an free ide that hides the messy setup work of building an applet, so that a user can dive in and write something quickly without getting bogged down in widgets and ui, etc. So processing can exist by itself and the end user needs to know nothing of Java (except syntax - processing is java, so the user must learn java syntax).
But a programmer who already knows java can exploit the fun quick nature of processing and then leverage their normal java experience for whatever else is needed - everything of java is in processing, just a maybe slightly hidden (but only at first) It's also possible to import the processing.jars into an existing java program and use them there. See http://processing.org/learning/eclipse/ form more information.
"how capable is it for writing a general everyday desktop application?" - Not particularly on it's own (it's not made to be), but some things are possible and easy (i.e. file saving & loading, non-standard gui, etc.), and in some ways it's similar to old school actionscript or lingo. There is a library called controlP5 that makes gui stuff a bit easier.
Webkit is another kettle of fish, especially if you aren't making a web-based thing (it sounds like you're thinking on using the webkit libraries as part of a larger program. I'll admit I don't have the dev expertise with those specific libraries to give you the answer you really want, but I'm pretty certain that unless you have programming experience beyond html5/javascript you'll probably get going much faster with processing.
Good luck with whichever path you choose!
I'm trying to understand if it is worth the pain to learn XUL more thoroughly.
If you have experience with a moderately complex project (like an independent application rather than a Firefox extension), can you tell me what your experience has been like?
I am particularly worried for feature which are not supported by the XUL framework natively. There are two possibilities: either create more XPCOM components, or using external tools. The latter approach is not completely satisfactory, as interprocess communication seems somehow lacking in XUL.
On the other hand, I have no knowledge of C++. How difficult would it be for a first time learner to wrap an existing library in XPCOM dressing?
I have not written any XPCOM in my three years of developing XUL applications. It does seem intimidating. So far, though, I haven't had a good reason to create any XPCOM. I do use some external tools - for reporting, working with mobile devices, etc. I eventually figured out that you can at least get the STDOUT return value from a process that runs (at least on Windows, it seems that this particular feature might not be consistent across platforms). That allowed me to have at least a single return value, which allowed me to implement error handling.
I think that you will find that you can do quite a bit without touching XPCOM. However, everything is not polished and easy, and there is not a large, helpful, developer community/ not much developer support, so it can be a frustrating learning experience.
If this is a large application, or an application that you might be adding other developers too, you may wish to consider choosing a more supported development platform.
Seaside just released a release candidate for the upcoming 3.0 version, so it appeared on my radar again. As I'm currently pondering what web framework to use for a future project, I wonder whether it's something to consider. Alas, most of the publicity for Seaside is from '07, which is probably one or two generations for the web. So I'm hoping that the community here can answer some questions
Continuation-based frameworks were pretty great when most of your workflow was mostly in HTML, e.g. form submits. For today's JavaScript-heavy environments, that hardly seems worthwhile anymore.
Is Squeak able to handle a reasonable workload? From other questions here and elsewhere, it seems that for proper scaling another implementation (Gemstone etc.) would probably fare better in the long run, but I don't have a proper idea how far away that is. Sessions seem to be rather expensive.
I know that comparisons are hard, but most of the articles you find on the net set Seaside and Rails side by side. How would combinations like Scala/Lift, Clojure/Compojure or Erlang/Nitrogen do instead?
I have answers to question one and two:
This is true. However since version 2.8 Seaside is not a strictly "continuation-based" framework anymore. Seaside uses continuations in the flow module only. Since Seaside 3.0 the flow module is even optional. Also note that Seaside has strong Javascript support since 2005, this is long before mainstream frameworks started to add Javascript functionality. Today Seaside comes with JQuery and JQueryUI support built-in.
Of course that depends on what you store within your session objects, but typically sessions are small (less than 20 KiB). Use the memory profiler in your application to determine the exact memory consumption.
And there is a new seaside book: http://book.seaside.st/book
I find the productivity of working in a Smalltalk IDE with a good set of abstractions outweights all other issues in engineering dominated projects. It works well as an enterprise system for a small company with about 100 (simultaneous, but not heavy) users on a single server (without going to SSD). Since 2007:
Seaside has shown to be able to make the switch from html workflows to javascript ones;
Seaside has been ported to a lot of different Smalltalks;
Has seen Gemstone release GLASS;
The new 'cog' vm with much improved performance has been released a few weeks ago and shows great promise for improved performance.
In Smalltalk we have now three web frameworks to consider, besides Seaside also
Aida/Web and
Iliad.
Both later effectively solve three-like control flow, but without needing continuations. Both also have a very strong Ajax integration, actually you don't realize anymore that you are working with Ajax.
Both also scale in memory consumption well. 10.000 sessions spend 220MB in Aida/Web, that is about 23KB per session, which can be further optimized down to mere 400B per session. This means, that you can run not only but many websites from the single Smalltalk image. Of course you can always upgrade to load balancing solution, when you really need. Which is from my experience very rarely needed.
Comparing to Ruby on Rails, a friend of mine complained that he needs 50MB of memory initially for every webshop site he is selling. He then turned to the Aida/Web solution where he needs about the same MB for the image, but then just few KB for every additional webshop site.
Avi Bryant, the developer of Seaside, said that AJAX triumphs continuations in almost all situations. Nevertheless, you can build reasonably powerful applications with Seaside and AJAX, too.
The Application part of a Web-App can be done in other frameworks quite well using Ajax.
I think a Seaside integrated Smalltalk-to-Javascript Framework like Cappuccino-for-Clamato is missing, currently. I'd like to be able to build real Javascript-Apps using Smalltalk.
Javascript is awesome but being capable of dealing with complicated workflow in a clean cheap way in the server side (as Seaside allows you to) is preventing it to become obsolete. Economy and utility are things that gives return in the short and long run. But telling this in the abstract has no value at all. You should be talking about a precise application and deciding if seaside is part of your bunch of competitive advantages to form an equation that rocks (and knowing why).
About scaling workload with Seaside, the short answer is that you can scale it like hell yah (for the long answer check my answer here: Does Seaside scale?).
too unanswerable man :) rty a variation of what you're really trying to ask
I think the best thing you can do is a prototype of something in a weekend.
If you can do a prototype in two days and you can capture some attention and you enjoyed the developing experience of doing it with seaside then you'll have the foundation of your next thing.
It costs only your time (you can publish in an amazon server).
BTW, this week I've heard about a startup that made its prototype by hand (was everything static and they processed stuff manually). Pretty amazing and crazy and cheap. When they felt that they had enough traction on the idea (which the had) they implemented the app (with whatever tech, I'm sure is no challenge for a seaside developer)
The recent article of steve jobs link
made me think about the future of flash. I'm learning actionscript 3.0 in my studies but is it the right decision still to go for it? I was pretty sure that I will be able to build application in as3 for iphones/ipads in the near future. It seems to me, while I would stay with flash, the market will be polarized by apple and adobe and you will always work double for both clientele, or just lose half of them.
Which decision would you take as a designer, if you were still at university and you intend to become a freelancer?
This question has been around a lot of times. For my opinion on flash's future please look at this answer: Should I Abandon Adobe Flash for HTML5 and <canvas>?
If you are a designer, you will probably actually feel good working with Adobe's Creative Suite, including Flash CS3/CS4/CS5. CS5 will be able to export HTML5 in the near future: http://www.9to5mac.com/Flash-html5-canvas-35409730 . You shouldn't be too worried. OTOH you should consider, that whatever CS5 exports is likely to perform poorer in HTML5, than on flash player.
From my perspective as a developer, I think there is no harm in learning any language, altough ActionScript 3 is relatively boring and easy to grasp. However this makes it a good language to learn programming, including many best practices. The most important things you learn as a programmer transcend languages. The more languages you try to really fully understand and exploit, the better you become by understanding the approaches they promote.
My personal advice to web developers is to have a look at Haxe. It is a much more powerful, elegant and expressive language than ActionScript and it allows you to target many platforms. Enough to build a whole web app on 'classic' platforms with only one language. Haxe's C++ backend allows building native iPhone apps using an SDL based port of the flash player API, although currently it's not very clear whether Apple's policy will allow distribution. Nonetheless it is an open source language with an enthusiastic community, that moves really fast and adapts to changes rapidly (e.g. unlike ActionScript Haxe can leverage flash player 10's alchemy opcodes for fast memory access) making you as a developer independant.
edit: I have personally dropped any plans of targetting the platform until Apple is willing to ease its very restictive policies, since I find this kind of behaviour intollerable. Nonetheless, I think Objective-C is a great and inspiring language, so you may actually wanna have a look at it.
I think that reports of the death of flash have been greatly exaggerated. Flash has always been "the bad guy" - self-proclaimed experts have always loudly declared that Flash sucks and is on its way out, but oddly enough I've never had any trouble finding lots of Flash work. There are things that you can do quickly and easily in Flash that are either much harder or flat-out impossible without it. It's an amazing tool and it's going to be in use at least in some capacity for the foreseeable future.
That said, even if Flash on the web goes the way of the dodo in two years (which won't happen) it's still a valuable tool. It's a wonderful way to learn Object Oriented Programming, and its uses go far beyond shiny websites. You can use something like Flash Builder in Eclipse to get accustomed to working in a code-oriented IDE, you can build AIR apps to deploy across platforms, you will soon be able to publish saleable apps to every major phone including the iPhone, etc. I've been having a lot of fun with it lately getting it to work with Arduino - it's just a hobby project but I'm trying to build a little helicopter that I can control from an AIR app. I'd be curious to see someone do that in HTML5. ;)
Flash is amazingly powerful - your abilities are in many respects limited only by your imagination and willingness to figure out how to make it work. It's really bizarre to read all of this stuff about how (some) browsers can now play (certain types of) video one their own, ergo Flash is Dead. How unimaginative. :)
This is a tough call. Flash is a fairly dominant technology at this point when it comes to media-intensive web sites. Flash is also very popular for delivering mini-games. I do think that Flash video, which is currently also dominant, will gradually be replaced by HTML5 technologies. I'm not so sure that Flash can be replaced easily when it comes to those media-intensive sites. There is a large number of very talented people comfortable with Flash that might be reluctant to adopt other technologies. I would probably hedge my bets and get comfortable with Javascript and other HTML5 technologies.
Apple vs. Adobe controversy reveals two opposite views of mobile computing.
Apple wants that its developers make the best of its devices by excluding middleware. The aim is to deliver the best possible user experience.
Adobe wants that its developers publish their work on as many platforms as possible. The aim is to reach the widest audience.
Nobody knows which view will win in the future. The mobile war is just beginning...
I think it depends on how far into the future you want to look, and what you think is most important. Flash on the desktop will not die for a long time, if ever. If that is good enough, keep going with where you're going. If not using flash on iPhone/iPad is a deal breaker, you only really have two choices - Objective-C or HTML5.
HTML5 is definitely gaining momentum, but it can't be used directly in all browsers yet, and likely for a while. However, in the mobile space, there is pretty excellent support in the major smart phones.
There isn't a single platform/technology/language that can hit everything. If I were going to bet money on the future, though, I would say HTML5 is going to win for the most reach across platforms. And given it is on the rise, I would bet that in the next few years, there will be a lot of demand for good developers in this area, but don't expect the path to be fully paved for you. You'll have to get your hands a little dirty. If you're looking for a decent editor, I use Netbeans, but I also do Java development, so that makes sense for me. Search around, though, and you'll probably find a decent set of tools that work well for you. It is a very active space.
As far as I'm concerned, Actionscript is a pretty good language to learn OOP. Javascript is a bit shit. Eitherway, I would expect you'd learn a certain set of (frontend/2d graphics) skills which will come in handy regardless of the vehicle you'll eventually use to deploy your work.
Personally, I like the flexscript language used by Flash, it's more structured and object oriented than Javascript. Also it has real inheritance, not the prototype based crap, and compiles to bytecode. For the artist, Flash is easier to use in many ways due to the available tools.
I do hope for better integration into browsers. The current flash plugin is clunky and causes crashes for many users, also the plugin system makes it integrate badly into the flow of pages.
With HTML5, I think the browser plugin idiom is dying in general. Everything from video playback to fancy vector animations can be done with just HTML + Javascript. Even a standard for 3D graphics in webpages is on the way (O3D).
Also I wonder how Adobe will cope with the current explosion of platforms/operating sytems/browsers, especially in the mobile realm. At the moment, the Flash support for systems except for Windows on PC isn't much good.
Just as projects like SVGWeb brings SVG capabilities to browsers that don't have native SVG, I would expect that if/when HTML5 gains traction against Flash there will be conversion capabilities from existing Flash to browsers without Flash. In fact, Adobe already has a conversion from Flash to iPhone using Flash Professional CS5. IMHO, there's too much Flash content in the wild for this not to happen eventually, and there are too many people for which Actionscript is their primary (or only) language for some conversion not to happen.
Career-wise, the clear long-term trend is away from Flash, and I agree with Tom that hedging your bets is wise. However, HTML5 is still fairly new, and you might do yourself a disservice to ignore Flash at this point. With conversion technologies, a Flash skillset will likely be usable for at least several years.
I'm looking for strategies and articles on making Carbon code 64-bit ready.
Carbon for 64-bit does not and will not exist. It's pretty much a dead end.
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
So in order to bring Carbon application and toolkits to 64-bit their GUI part will have to be re-written in Cocoa and Objective-C, right?
Yup.
How can I minimize the effort I have to put into the transition? How can I minimize the amount of needed Objective-C code?
Learn Cocoa. Read The Objective-C Programming Language and the Cocoa Fundamentals Guide. Become familiar with MVC, KVC, and Objective-C. Bookmark the Foundation and AppKit framework references. Learn to love Interface Builder, for it is your friend (moreso in Cocoa than it ever was in Carbon).
Get good at Cocoa. Read more Guides (if you're still on Leopard, use [1] instead). Write as many throwaway apps and even real apps as you can get away with in whatever time you have available. If you can, give them away under a BSD license, and write reusable source code and give that away, too. People will find bugs and some will tell you about them, and some will submit patches. Get to be able to write a complete app with a model layer, no more than two controllers, and at least one custom view or cell in a day.
Read the Carbon Porting Guide, then port your app.
I came from Carbon myself. It's completely different—you may as well start fresh, ignoring your previous Carbon experience, and maybe you won't make some of the early mistakes I did (like skipping the model layer).
As for your app, you probably have a lot of surgery to do, as Carbon did not force you to keep UI and logic separate like Cocoa does. Cocoa enforces MVC; if you don't adhere to it, you pay the price by reinventing wheels and making and correcting mistakes.
That makes Cocoa sound like more work, but it's not. Porting is hard (inevitably), but otherwise, Cocoa is quite the opposite: Writing (and reading!) a Cocoa app is much easier than writing (and reading) a Carbon app. Once the porting is over, you'll be glad you switched.
Oh, and many people will recommend one or both of Cocoa Programming for Mac OS X by Aaron Hillegass and Programming in Objective-C 2.0 by Stephen Kochan. I have the first book, and have read some of it, but that was after I had already learned Cocoa, so I can't earnestly recommend it; that said, it is not bad, and I don't think you'd do wrong to read it. I have not even seen the second book, so I won't say anything about its quality.
[1]: file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/index-date0.html (Stack Overflow won't let me link file: URLs)