What language is the majority of startups using today?
Based on what I can see, it looks like more and more people are switching to Python and Ruby from PHP.
What's your startup using and your reason for choosing said language?
What's your startup using and your reason for choosing said language?
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.
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.
But, really, use what you're good at. If you're working on a startup, do you really want to spend valuable time getting up to speed with a programming language that you don't know and are only learning because random people on the Internet told you they were using it?
I did that.
It probably hurt the startup a bit - we'd be moving much faster if I didn't have to learn the technologies as I went along. Thing is - the web technologies I really know well consist of PHP and JSF, and I know them well enough to know that I do not want to be programming in them if I can help it.
I figure that any startup will be taking up a good chunk of your time, and you might as well make it at least semi-enjoyable. I'd much rather put in the up-front effort to learn Python and have a tool that can grow with me than curse PHP's naming conventions or lack thereof for the umpteenth time.
there is no one true language and you should focus on accomplishing specific goals and getting stuff shipped instead.
Has anyone previously using a Lisp for your startup since abandoned it? What were the reasons?
I'm thinking of taking a look at django just because guido tells me to, but I don't see any strong reason to switch.
I had to drop the built-in DB library once I needed to connect to multiple databases. Global DB connections = bad. I suspect that if I'd kept using it, I would've had problems with transactions too.
I had to replace some of the request dispatching when I wanted to add code that triggers on every request (eg. logging, transactions, custom session management, "who's online?", traffic analytics).
I had to drop the Cheetah integration to add internationalization support - Cheetah supports the _ function, but only in precompiled templates.
I had to drop Cheetah entirely as the templates got a little more complicated and I wanted to factor some bits out. Web.py patches the Cheetah #include directive to do what you'd expect: include a file at compile-time (which is the same as runtime under web.py). With precompiled templates, however, it includes it at runtime, which means the included file can't have any #defs. Big pain.
It's not a bad framework to start out with, but you will end up needing to ditch nearly all of it by the time you've handled everything a typical webapp needs. If I were to do it over again, I'd probably start with Pylons. I'd consider Django, but I'm not sure you can swap out Django components the way you can with Pylons.
If I were to switch to anything else, I'd probably try plyons first.
I still find it very appealing, because 99% of the time, it is used for common, simple websites. And in these cases, its simplicity pays off. I like that I don't have to fiddle with multiple files or configurations, since everything can be contained in a single file in a very clear way, and just adding "web.run" to your script converts it into a running website.
There's no useful answer in any case, just hints and use cases. It depends entirely on what you're building.
Heavy single-purpose web app like gmail? No question - GWT.
Light multi-purpose web app with lots of pages but where some ajax here and there wouldn't go amiss: rails looks good.
etcetera.
Also, most frameworks are evolving FAR quicker than GWT is.
Thirdly, GWT will still require server-side coding. You might as well use a framework with an Ajax library or just plain html output, and then add-in GWT or Adobe Flex later, if at all.
Fourth, GWT does not have anywhere near the community or IRC users that most frameworks do.
But, mainly, GWT is a bad idea because it loses the advantage that web frameworks give to web startups over desktop development. That's because using GWT can be even slower than using traditional desktop development tools like Visual Studio because you not only have to compile, but also upload the files to get a real idea of what you're doing.
Why not just use a console with a web framework, or something with both in one like Seaside? As soon as you save the file, the change exists.
"most frameworks are evolving FAR quicker than GWT is."
GWT is only a year old and has had 4 major releases. It just went open-source recently, so it's too early to tell how fast it will evolve.
"GWT does not have anywhere near the community or IRC users that most frameworks do."
GWT community is huge - there are over 600 posts a week on its Google Group. I'm not aware of an IRC channel for it though.
"using GWT can be even slower than using traditional desktop development tools like Visual Studio because you not only have to compile, but also upload the files to get a real idea of what you're doing."
No, you only need to upload files when you're actually doing a release.
I'm not sure where you disagree since you are defensive about GWT, when I never said it was bad, just that using a web framework is a much better idea, especially at first.
How can you predict how many users GWT might have in the future when Adobe Flex and Apollo are around the corner?
On the other hand, the server-side coding won't change from PHP, Python, or Ruby for most startups over the next year, however, and their web frameworks are much easier to use and integrate than GWT.
I like GWT, but I think it requires at least one or two additional orders of magnitude of time to get something going. Plus, you'd still have to write server-side code to handle the ajax calls, so you may as well need to start with a web framework anyway!
And remember, you don't have to compile all the time with web frameworks.
Finally, the "major" releases you mention have been very minor. For example, One of the VERY few releases GWT has had in the past 8 months involved Google changing their source to be open source, without making any improvements that I can remember.
If you started with a toolset, you should stay with it. But if you're starting a new project, use a web framework.
What would be great is if this prediction comes true:
http://getahead.org/blog/joe/2007/05/11/googles_next_open_so...
Keep in mind that GWT is not a full web framework. So it's pointless to argue which is better, web framework or GWT, just like apples and oranges. You can use GWT with whichever back end framework (e.g. Rails) you want if you choose to go that route. Like I said earlier, GWT is an alternative to JS frameworks like Prototype, not server frameworks like Rails. What GWT does allow you to do is not use a web framework at all since its server-side calls are very easy to implement. But if you require a DB, etc, you can still use Rails and GWT.
In terms of programming languages, Ruby all the way, with some Java (j2me) and Hecl thrown in.
I feel like I'm on the wrong side of the road, and php is web 1.0. I wonder though, do users care what language the site is made in? And has usuability and quality of a site become determined by programming language?
Basically I see the PHP backlash coming out of many painful personal experiences that hit the limitations/drawbacks of PHP. I've maintained a large social networking site written by someone else and I can tell you it was a stinking pile of spaghetti.
I think the power comes from using a framework like RoR of Django that abstracts aways common parts of web development. Plus I see it as a way to keep from reinventing the wheel which leads to simpler code. And we all love simple code.
Anyway, just my thoughts on the matter.
There are some impressive PHP projects out there, with pretty clean code (I've been pleased by the quality of code in Dokuwiki and Flyspray, for example), and you can't beat PHP with a stick for availability--you can deploy a PHP app on the cheapest Dreamhost account and expect it to work just fine. That cannot be said of RoR, Django, or Catalyst applications (and don't even think about Lisp or Haskell or Erlang in that context).
45% Ruby (mostly RoR, but one might not have been using Rails) 30% PHP 15% Java 10% Perl
Almost all of the groups were heavily using JavaScript, as well. In fact, some of them were predominantly JavaScript with quite lightweight back-ends (Zenter and Weebly come to mind). Heysan were predominantly Flash at the time, but I believe they have a lot more PHP back-end code now.
I don't believe there were any Python projects.
In the end, pick whatever you feel more comfortable with and whatever the market you have company in supports. If it's easy to find RoR folks around where you live, use that... if it's easier to find Python people, maybe you should use Python instead. They're both excellent languages and a huge improvement over Java/C++/C#.
Reason: I'm doing a database-driven web application, and I designed this language exactly for that purpose.
I used to use PHP, but once I tasted Python I couldn't go back.