What language is the majority of startups using today?
63 comments
Python + JavaScript + Flash.
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.
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.
"... Python + JavaScript + Flash. ..."
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.
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 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.
We spent considerable time testing Django, Plone (not really a framework), PHP, and Cake PHP. We ended up going with django (Python). Really quick to learn. There's some documentation lacking once you get really deep and start doing some crazy stuff, but its more than made up for by a very helpful IRC community. We love it!
Django and Python. Because they're just that good.
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?
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?
"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"
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.
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.
I can think of worse reasons, and worse places to ask:)
Rolled my own framework with mod_python. I am sick of reading docs to figure something out. Also, the bugs in my framework code are easy to fix compared to those found in the 'real' code. I don't think the cost of a home grown framework is high if you spend more than a few months on something.
We speak Spanish and English.
Also Python/Turbogears and Javascript.
Perl. Reason: I can build scalable things in it really quickly. For people deciding between different languages, I think the main selling points for Perl are a) most of the code is already written for you (see http://search.cpan.org/) and b) it scales really well (see http://perl.apache.org/).
Here is what I have learned from 2 years of questing for the One True Language:
there is no one true language and you should focus on accomplishing specific goals and getting stuff shipped instead.
there is no one true language and you should focus on accomplishing specific goals and getting stuff shipped instead.
There seem to be more references to Lisps (Common Lisp + Scheme) in that thread than this one.
Has anyone previously using a Lisp for your startup since abandoned it? What were the reasons?
Has anyone previously using a Lisp for your startup since abandoned it? What were the reasons?
I used webpy for my last site, but recently changed development to django. Django is really easy to learn, and provides a full stack of components that integrates really well together. I used AJS javascript library, but has changed to JQuery this time. Mostly because of JQuery's numerous plugins.
I'm using webpy for a few sites and it seems great to me. Are there many reasons for the switch? Or did you just want to try something new/better supported?
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'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've found that I had to gradually replace large parts of web.py as my webapp evolved. For instance:
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.
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.
I use Python-Pylons/JS and Schevo for the backend. I have some experience with Django. Pylons is much better for serious programming - Django is better if you want to make a run of th e mill app like a blog. Using Pylons is like working with Lego bricks - stuff is swappable easily - not so with Django.
Yes, that's what I need and pretty much what webpy feels like to me.
If I were to switch to anything else, I'd probably try plyons first.
If I were to switch to anything else, I'd probably try plyons first.
I really like webpy and its open ended approach, but Django is just a more complete framework, and thats what I need for rapid development. django.contrib contains user/auth and other things I'd need to roll my own in webpy. And the middleware, like session stuff - beeing written for django - ties nicely in with all the helpers (generic views, etc..), while still being loosely coupled. Initially I thought that Django was mainly for news driven sites, but I find it to be just as flexible as Rails and more explicit and intuitive. So basically I'm looking for the solution that allows me to write the minimum amount of code, while still providing the flexibility I need. And of course it has to be Python (because that's what I prefer).
I really appreciate these comments about webpy.
I recently started using it and I love it for its simplicity, but at the same time I wondered about the advantages/disadvantages of its "anti-framework" philosophy against the full features of a mega framework ala Django, Pylons or TG.
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.
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.
No question. PHP. However, this doesn't mean you should follow suit. In particular, PHP works best as a vanilla choice, something to get set up with quickly. The moment you start using e.g. Cake, the point of PHP is no longer and you should look elsewhere.
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.
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.
I disagree. I believe the opposite: GWT is a bad choice, mainly because GWT has to be compiled every time. It's much better to use a framework, including ones for PHP, since PHP is faster than Ruby and most popular frameworks have memcached support, and a great community.
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.
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.
There are a few misconceptions about GWT in the above comment:
"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.
"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.
You used the word misconceptions, but I don't think I was wrong about anything I said if you read what I wrote carefully.
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...
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...
Adobe Flex a very different approach to the rich client model. GWT will be on the same side as Prototype, Dojo, etc. if there is a showdown with Flex. Flex is not an alternative to GWT but rather an alternative to AJAX. I suspect both sides will continue to coexist peacefully.
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.
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.
If you get your eclipse and ant build scripts setup right on your development box, deployment takes a single mouse click. It takes me ~10 seconds to sftp changes to pre-prod, stop tomcat, build, compile, and restart tomcat if you change your java class files on my W2K3 production server also running a stripped down version of eclipse (even less if just working with web files or jsps)
Common Lisp, but my project is a poor representation of "the majority of startups" because it's not a web app or a social networking tool. It also doesn't qualify as a startup yet, but that's the goal.
English. It's pretty popular even in Europe, because it bridges borders.
In terms of programming languages, Ruby all the way, with some Java (j2me) and Hecl thrown in.
In terms of programming languages, Ruby all the way, with some Java (j2me) and Hecl thrown in.
Can someone please tell me why everyone is so anti-php these days. I'm been working on my web project this summer in php, and it seems like every self proclaimed web 2.0 site is choosing either python or ruby.
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?
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?
To answer your question, the only thing users care about is what your site does and if it does it well. The only people who care are the other people who are developing websites as well.
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.
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.
Good point, adamdoupe. I've created a large project in straight PHP and it was a mess. Now I work with CakePHP, a framework similar to Rails, and it's 100... no, 1000... times cleaner and more scalable!
PHP lowers the barriers to entry for web programming, which is a good thing. It also means that a lot of really shitty code gets written. At my last job, we had one file that was 10,000 lines long. Basically, I never want to touch PHP again after that job.
PHP is just a rather nasty language. It's got a lot going for it, in terms of deploy-ability, scalability, existing libraries and code, and number of developers and designers who are familiar with it, but it's also got a horribly inconsistent standard library, poorly implemented seemingly Java-inspired objects, and a vast majority of the existing code is poorly written.
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).
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).
Perl with Catalyst, DBIx::Class, and Template Toolkit. All the actual every-day code is really simple because all three are designed for extensibility. I just write little plugins that abstract away the repetitive stuff. I also write lots of long-lived systems daemons. They do all the asynchronous tasks in a super efficient way. Not enough people use this technique in my experience.
I just use cron for asynchronous tasks, because it's less complex to write for (just write the script to do the task once, after all), and any unix will already have cron running for other things.
Yeah cron works for lots of stuff. Some things need to happen asynchronous but more quickly than is convenient to do with cron. Not enough people use cron jobs though either.
I am not a developer but here is what Tabblo's founder has to say about Django. Tabblo was acquired by HP 9 months after launch.http://theonda.org/articles/2007/07/02/now-with-django-power...
We're using C#/ASP.NET (which though rare across startups, has worked out well for us so far).
See Red vs. Blue if you're deciding on Ruby/Rails vs. Python/Django
http://jng.imagine27.com/articles/2007/07/12/red-vs-blue
http://jng.imagine27.com/articles/2007/07/12/red-vs-blue
Does it really matter? Use whatever makes YOU most productive, because at the end of the day the only thing that matter is a simple answer, yes or no. The question is always the same: Is it done?
I'm using Java, too.
During WFP07 it looked something like this on the backend:
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.
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.
The language that best solves the problem and that scales.
CakePHP + Scriptaculous. CakePHP was easy to learn, however the documentation is not complete, you'll have to read the code for advanced features.
Python (with Django) and RoR.
If you had to choose one, which would you pick?
We went with Python + Django. It was an excellent choice for us! We don't have any performance & scaling issues so far (and we have a pretty big site already) and programmer productivity has been nothing short of amazing.
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#.
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#.
RoR is great for making a prototype, but just wait until you try to find other good rails hackers. they're scarce.
Finding good hackers is difficult in any case. If you manage to get one, they can learn Rails quickly. Unless you have a very urgent, short term need, you're taking the wrong approach if you're searching first and foremost for a rails guy rather than just someone who's good and willing to work with rails.
http://brl.codesimply.net/
Reason: I'm doing a database-driven web application, and I designed this language exactly for that purpose.
Reason: I'm doing a database-driven web application, and I designed this language exactly for that purpose.
We use Ruby on Rails with a lot of JavaScript for Ajax-y thingies. So far there's only 2 of us, but looks like here in NYC there's more than a few RoR devs.
everyone is going to shoot me for this, but we are building our project in C# (debug time + .NET library),C++ (faster sockets), actionscript (not flex) and ajax
If you can do reasonably rapid development with that, more power to you. :) At least the result should be fast.
Python (pylons) + JavaScript + Flash, and loving it!
I used to use PHP, but once I tasted Python I couldn't go back.
I used to use PHP, but once I tasted Python I couldn't go back.
Python and Django for web stuff, C++ for desktop stuff (games, 3D applications)
python + django
lisp + javascript
LAMP bundle.
Haskell.
Java
php
I'm currently researching Python with Django as the web framework. Coming from a decent size website in RoR, Django is looking quite promising. I'd love to hear what people's experiences are using Django.
What's your startup using and your reason for choosing said language?