webwright, haven't seen your job ad, but I guess its not that challenging for a real "client" hacker to become attracted. Personally, I wouldn't bother applying because I see no future for myself as a "desktop" fanatic at your company - don't take it seriously, I do and love web apps too!
Ask HN: Does anyone WANT to build client software anymore?
11–20 of 58 posts
Re: Ask HN: Does anyone WANT to build client software anymore?
#12I'd like it as long as it was Mac.
To elaborate, the pool of people willing to pay for Linux client software isn't large enough. The pool of people willing to pay for Windows software is large enough, but I don't enjoy writing C#/.NET or MFC. And as importantly, it is hard to stick out as an indie in that environment.
So, the time invested to learn these technologies isn't worthwhile.
On the mac, you have a user base which is used to paying for software, and it is growing. And although no environment is perfect, I do enjoy writing Objective C and Cocoa.
Re: Ask HN: Does anyone WANT to build client software anymore?
#13I have a number of years experience working with Tcl, and also a bit of Tk, which fits the bill nicely for that kind of thing. However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy…
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work.
The same is true about web interfaces, of course, but they at least have hype behind them, and therefore they're picked up by trendy young coders. Plus, there's the challenge -- or, IMO, endless pain -- of actually making it work across multiple browsers.
There is certainly an art to making a good, usable interface, but it's not a typical programmer's challenge, and writing a UI by hand is simply a pain in the ass. It sucks to do the stupid connections and packing if you don't have a drag and drop layout tool. And once you have that, you start leaving the programmer's domain, and into the designer's domain.
Note, I'm only talking about interfaces. The logic behind them can be anything, but it's the same logic with a web or desktop frontend.
I think it's just that once the shine wore off of the "hey, I can make buttons!" thing, the highly motivated programmers realized that UI design wasn't something that they wanted to focus on -- it's better left to designers (in theory at least -- im reality it's probably left to lowly grunt programmers) who can make the UI with drag and drop GUI builders, leaving them to work on interesting technical challenges. Making a GUI tends to be incidental to the core of the problem. I suspect that if it wasn't for the shine factor in web apps, it would have the exact same sort of apathy that you see in most programmers about desktop GUIs.
Re: Ask HN: Does anyone WANT to build client software anymore?
#14I got into programming via the games route, and until pretty recently, that meant to-the-metal C, C++ and the libraries close to the system. (and when I started to teach myself to program, I hadn't heard of the internet) I've always tried to stay on top with other tech as well though, including the web, and now that I've given up game programming, my consulting work is about 50% client-side (C/Win32, C/UNIX, C++/MFC, .NET, Java - you name it) and 50% web-based. I enjoy both.
I guess the web is what's hot right now (and that's hardly going to change so quickly) so it's what attracts the freshest talent. I don't think there's anything fundamental about web technology that will attract "YC style hackers". I also don't think the desktop is dead just yet.
I suppose it's therefore no surprise that my own pet project is a kind of web/client hybrid that you'll be able to use either via a browser or run locally. (although some of the more complex graphical UI is pretty tricky to do in a browser, so we'll have to see what happens)
I'm probably in the wrong country to help you out directly, but I suspect there are plenty of people out there that fit your requirements. I don't hang out there, but you could check the Joel on Software boards/jobs, I understand that's frequented by Windows folk.
EDIT: this post seems to make me sound old. I'm 24, so typical YCer age, as far as I can tell.
Re: Ask HN: Does anyone WANT to build client software anymore?
#15The idea often appeals to me but I quickly get turned off by the practical realities involved, particularly when getting the app to both look reasonable and work on several platforms. That said, I've been thinking about XUL/Firefox addons for some simple configuration things.
In that case it's worth plunking down the cash for a Qt license (or going Open Source). It really is the best framework for doing cross-platform native-ish development.
Re: Ask HN: Does anyone WANT to build client software anymore?
#16Earlier quoted context omitted.
Heh- true 'nuff! If we could do what we do using only web software, we would. It seems that apps like Quicksilver (Mac), Enso (Windows), Firefox, etc., are still pretty darn innovative. But the agility that the web affords is pretty darn addictive.
I think within your post right here lies a lot of the problem. There needs to be a really compelling to write something as desktop software instead of as a web app, so most people don't even bother to learn how to write desktop software in the first place.
Absolutely, the paradigm of 'client-software' is becoming ambiguous for most of the web people. 'Porting' an existing web app to a 'client software' is a very trivial work, thanks to stuff like XULRunner.
Re: Ask HN: Does anyone WANT to build client software anymore?
#17I have a number of years experience working with Tcl, and also a bit of Tk, which fits the bill nicely for that kind of thing. However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy…
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
I would say that unless you're making command line programs or AI the most important part of an application is the GUI. It is all your customers see, and if it doesn't work nothing else matters much.
Re: Ask HN: Does anyone WANT to build client software anymore?
#18Compiled, non cross platform, download-only, "client software"... no.
Cross platform, deployable on the web or any OS desktop, or mobile phones (with new generation browsers)... yes.
But we had to write an entire framework first ;)
Re: Ask HN: Does anyone WANT to build client software anymore?
#19I have a number of years experience working with Tcl, and also a bit of Tk, which fits the bill nicely for that kind of thing. However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy…
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
> For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work... [t]he same is true about web interfaces...
I wish it were true for web interfaces... something like balsamiq.com, but it would output html (or haml, etc.) instead of xml.
Re: Ask HN: Does anyone WANT to build client software anymore?
#20Earlier quoted context omitted.
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
I would say that unless you're making command line programs or AI the most important part of an application is the GUI. It is all your customers see, and if it doesn't work nothing else matters much.
It's not unimportant. It's just menial and trivial when done in code. Yes, there's an art to it, but that's not a technical challenge in the programming domain. The outside veneer is important, but it's not interesting to work on from a technical viewpoint. And furthermore, it's best left to UI experts to design -- any sane GUI designer makes it easy enough for 90% of the UI to be done by drag and drop. (Yep. No sane GUI designers that I've seen yet exist for web apps,partly because there's no standard GUI toolkit.)
It's not like mechanical engineers spend the majority of their time deciding on the trim and positioning of internals which compose the interface to the car. Instead they collaborate with the designers the constraints on the interior layout, and then they leave the interface details to the designers, while working on the drivetrain, suspension, frame, and so on.
The point I'm making isn't that GUIs are unimportant. The point is that GUIs are uninteresting if you are looking for a technically challenging problem to solve with code. This lack of challenge can be compounded today with the trend towards designers providing specs to programmers, and then leaving the programmers to implement it, as the creative element is reduced.