The server-side choice between Python and Ruby is completely arbitrary; I suspect either one could do the job equally well. I was swayed by the somewhat greater availability of libraries for Python, plus I thought it'd be easier to get Python programmers if we got big enough to hire, plus it's somewhat more likely that an acquirer will use Python than Ruby.
PHP or Perl could also have done the job equally well, but I figure that if I'm gonna code my ass off for a year or two, it might as well be in a language that I enjoy. I've written some decent-sized PHP projects before, I'm reasonably fluent in the language, and I just don't want to deal with its gotchas.
On the client side, your choices are much more limited. Basically, if you want to do any sort of rich embeddable widget, it has to be Flash. That's the only technology available on nearly every browser that isn't blocked by 3rd party websites for security reasons. If you want to do rich interfaces on your own site that don't run in a box, it has to be JavaScript.
Nostra... what's the front/back ratio? I remember reading Ryan from Wufoo's "Web App Autopsy" ~ ( http://particletree.com/features/web-app-autopsy/ ) was quoting 60% front-end to 40% back-end code ratios.
Hard to tell what the finished product will have, because we're nowhere near done. The site that's currently up at www.diffle.com is 707 lines of HTML, 733 CSS, 6283 Python (including all server administration tools), and 81 JavaScript. (These figures include comments and tests, which are fairly extensive in the Python and basically omitted on the frontend.) However, that's a very Web 1.0 site, with AJAX used in only a couple places where it really improves usability.
The 8 or so prototypes we've done for the more dynamic aspects total about 1000 lines of JavaScript and 3107 lines of ActionScript, but this is misleading. Since they're prototypes, they often copy straight from each other and don't bother to factor out common functionality.
I'm expecting it'll be something like 60/40 front/back by the time we're done, with nearly all of the post-launch code going on the front. But much of the JavaScript and ActionScript may be generated by Python scripts running on the backend. Kinda hard to say what's front-end and what back-end then.
The server-side choice between Python and Ruby is completely arbitrary; I suspect either one could do the job equally well. I was swayed by the somewhat greater availability of libraries for Python, plus I thought it'd be easier to get Python programmers if we got big enough to hire, plus it's somewhat more likely that an acquirer will use Python than Ruby.
PHP or Perl could also have done the job equally well, but I figure that if I'm gonna code my ass off for a year or two, it might as well be in a language that I enjoy. I've written some decent-sized PHP projects before, I'm reasonably fluent in the language, and I just don't want to deal with its gotchas.
On the client side, your choices are much more limited. Basically, if you want to do any sort of rich embeddable widget, it has to be Flash. That's the only technology available on nearly every browser that isn't blocked by 3rd party websites for security reasons. If you want to do rich interfaces on your own site that don't run in a box, it has to be JavaScript.