Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Building a large webapp today - what language for the backend, and why?
31 points by swix on Aug 5, 2012 | hide | past | web | favorite | 61 comments
As the title reads, what platform/language would you pick for the backend, and why? Taking into consideration development time, costs and maintainability. Given you/your team were/are equally experienced with all languages/platforms. Thanks!

For a 'large' webapp I would honestly go with Java. A good stack is Jetty for the http server, and Jersey/JAX-RS for the web framework. The JVM is unbeatable, and you will have an easy time onboarding people since everyone knows Java.

It's not as 'hip' as Rails/Django but you will be very productive and you will have the benefit of the plethora of Java libraries out there that are performant and reliable. Not to mention the great profiling tools.

I would prefer ASP.NET MVC (thus C#) over the Java platform. The .NET stack is extremely powerful (much better than Java imho) and the ASP.NET MVC framework has a lot of the features that make RoR great (it's just must faster than Ruby).

..another vote for .Net, MVC and SQL Server from me.

A great example of this stack, is that it powers stackoverflow.com

This is the first time in my life I've seen someone defend C# and .NET. I don't know that I've been looking very hard though.

I take it that it's not popular around here because this site is full of Apple lovers, but there is not denying that C# is 'Java done right/better', so I really see no reason to use Java over C#.

Furthermore C# has the best IDE in the world (Visual Studio), it has a lot better performance than Ruby for instance, it has a sublime integration with web services/databases/etc., it has great documentation (MSDN)...

A lot would argue that it's a horribly cluttered and slow IDE. People who love VIM will definitely not like Visual Studio.

That said, since the last few years Microsoft has really been on top of their game. Their latest frameworks are easy to grasp and perform very well. C# is also not too verbose and on top of that they are starting to push open-source with initiatives like codeplex and NuGet. In their MVC Framework they even push jQuery and they are core contributors to it. They recently released their WebAPI wich is a pretty smooth way to create a REST-ful JSON/XML API.

It's definitely not a bad choice. Especially if your developers have already mastered it.

It might not be hip (yet) but it's definitely solid. Although still lagging behind after the trendsetters (Ruby community imo).

Isn't comparing VIM to VS like comparing apples and oranges? One is a text editor (although highly advanced) and one is an IDE. Would a VIM guy consider any IDE seriously?

If I were going to do .Net on windows, I'd probably use Visual Studio. The last time I used it was about 10 years ago, and I found that it didn't get in my way. Not having VI controls in the buffer editor would probably drive me crazy but I'm adaptable.

I'd still be installing vim on my windows box, but when in Rome...

Great reply, I fully agree with it.

Some of it might have to do with the server platform - a lot of us really like the flexibility of using Linux on the server, but when we think C# we think IIS + Windows.

Is the server-side ecosystem for Linux-hosted C# production worthy? And if so, does it compare well to the solutions getting recommended in this thread?

I wouldn't run .NET software on Linux, I'd just stick to Windows Server. It's really solid nowadays, and there is enough choice (it isn't even more expensive than linux hosting). Check out Azure and AppHarbor for cloud hosting for example: they both work extremely simple, and have powerful capabilities.

>> it isn't even more expensive than linux hosting

A specific comparison would be nice, blanket statements are not helpful.

> Furthermore C# has the best IDE in the world (Visual Studio)

You don't seem to be aware of IntelliJ IDEA. VS may be very good, but it's highly unlikely it's "the best in the world" while IDEA is in it.

I tried IDEA, and it's nice and all (I love JetBrains software), but I can't say that it's a serious competitor to Visual Studio.

IntelliJ also makes Resharper, a VS plugin. VS+R# is the best IDE in the world (IMHO)

not an apple lover, but prefer open source and open tools vs everything MS on top of increasing cost of development, on top of reliance on MS for everything from using an MS stack.

>> there is not denying that C# is 'Java done right/better', so I really see no reason to use Java over C#

I see plenty and I've done both and stuff that existed before Java or C# either one existed like C++, C, BASIC and Assembly.

i don not use windows

I agree - I would choose Java (or I guess Scala if I had a really good team around me) for the core stuff. I might bridge out beyond the core though and start using Groovy or JRuby for non-core functionality.

Jersey/JAX-RS are good, alternatively if I felt like taking a bit of risk I might give Play2 a try.

The Java/JVM ecosystem just has too many positives going for it (awesome VM, libraries, great community, huge developer pool) to really consider another stack for a 'large' web app.

I started my business exactly a year ago this month. My co-founder and I went with Java on the backend for a few reasons:

1. This is what we were most experienced in. It is important to use what you know in a lot of circumstances because otherwise you'll have a harder time getting off the ground with your projects. Sure, Java isn't hip/cool in a lot of circles, but it gets the job done and there is a ton of support for it. Libraries like Joda DateTime/Money and Jackson are lifesavers that you can't find anywhere else. Do you want to build a business or spend time working on your tooling?

2. When your is new, you pivot your code a lot as you figure out the best way to do things. I can't tell you how many times we've said: "Wow, so glad we used a language that is easily refactored". Being able to safely make huge sweeping changes across your entire codebase without worrying about whether or not you are going to have runtime errors is golden.

3. We are hosted on top of Google AppEngine using Objectify to talk to the datastore as our database. This is another huge win for us. We get unlimited scalability with all the benefits of never having to carry a pager, manage servers or databases. Deploying code takes 2-3 minutes and is super simple. This means more time for adding features, which is very important when you are just starting off. Python is another good choice here, but lacks #2.

I'm definitely not a huge fanboy of Java any longer. I do feel that it hasn't grown with the times and I think Java has too much stuff to type out (even with Eclipse doing most of it for me). That said, I do see Sunacle actively working on it and 3-5 years from now, I bet there will be a shift either back to Java (as Java8 starts to get more widely used and brings the language more current) or to another language like Ceylon, which unfortunately just isn't quite ready yet.

Scala my friend.

Python (Tornado or Twisted) + Riak.

Why? You can scale very easily, write code in a higher level language that has lots and lots of libraries, have map reduce out of the box, but you don't need to really worry about your DB dying on you.

Here is what you do need to worry about in this set up: Eventual consistency. But I would argue that any web app at scale needs to worry about it. So if you are coming from a company that already has lots of users and you are writing a new app that will be in the hands of lots of people very quickly, go with Riak + Tornado/Twisted. You'll probably want to set R = 1 or 2 and pay special attention to conflict resolution.

lein new noir myBigWebApp


I think Clojure makes a lot of sense for the web, emphasis on immutability etc. I also am a sucker for lisps, and I think the Hiccup templating system is nice. Noir seems to do middleware well. Plus, real nerds get on that ClojureScript.

Then again, I kind of also believe that the back-end really shouldn't do much more than process CRUD commands, and that most of your serious application logic should happen on the client. So it doesn't really matter. Pick something with a DB adapter you're comfortable with and get to javascripting.

I'm inclined to agree for a few reasons other than the usual things people cite about Clojure. These are the first to come to mind:

* The property list pattern and inheritance-like behavior are very natural and convenient with maps and records. I think that sort of thing is very helpful with large applications.

* Clojure has the ability to abstract the database (I'm thinking of Korma here) in a way that preserves and works with the relational model more directly than ORM.

Clojure's ability to leverage Java libraries also means you're unlikely to ever get stuck implementing common functionality from scratch[0] when another language would have a library.

[0] I did, however once write a CSV library for Clojure because it seemed easier than using an existing Java library for the subset of functionality I needed or writing a wrapper.

I totally agree that Clojure and Noir are a great choice. In dev mode with automatic code reloading, you have a fluid setup.

I am starting to rebel a bit against really fat JavaScript/CoffeeScript/ClojureScript clients as the default implementation strategy. For many apps, using old fashioned forms, render on the server, and after you have functionality convert bits to AJAX as needed to make the web app nicer to use. It is an economic decision: is the cost of a slick fat client justified for a given project?

Pick what ever gives you and the people you are working with the greatest productivity. Chances are it will get rewritten later on to address the problems you encountered.

I like Ruby and Sinatra, but PHP with a decent Sinatra equivalent framework like Slim would be just as nice, or Python+flask/bottle, or Java/Scala and the Play framework. Honestly, it doesn't matter.

Use what you know and like and just build the app. Scaling is a nice problem to have, but don't solve it until you have it.

Use what you know and like and just build the app.

And for a large app, use what the team knows. Both dev and ops.

Scaling is a nice problem to have, but don't solve it until you have it.

And since scaling issues are mostly matters of architecture, rather than language, see rule one: "use what you know."

Ruby/Rails and Python/Django seem to be the most common choices among YC startups. They are pretty much interchangeable on the development time, costs and maintainability fronts.

First I would point out I'm not seeing testing frameworks being mentioned as part of these platforms ;)

I like Node.js + Mocha

* Development in Node is super fast

* Mocha makes TDD or its variants really fun

* Node feels natural for webapps (the Hello World example is an HTTP server)

* JavaScript is a really flexible and elegant language if you get past its minor quirks

* The community is fantastic

* The built-in package manager is fantastic

* The open-source libraries are fantastic (pick the right DB for the job, there are good drivers for all of them)

There's lots to say about Node. No language is perfect for every task.

EDIT: fixed spacing

Python/Django or Ruby on Rails. If you have to move fast and change ideas quick and timely. Pick on of them.

Given my current project where i am the sole developer i dont want to know how much more time i would have spent coding in e.g. PHP.

I'd choose Ruby in a service oriented architecture. Use HTTP/JSON for internal APIs between distinct systems. If performance becomes a business-limiting factor, you can investigate replacing a single part of the system with a lower-level language (Java, Haskell, Go, Erlang, etc).

Rails (and in particular the RailsApi gem) makes prototyping and putting together a SOA like this easy and fast. Except for the API client, which I don't yet have a good solution (ie, what ActiveResource was supposed to solve).

Use a higher level programming language and use a standard interface to communicate with the frontend. If you build a REST API for the backend it doesn't even matter what language it is written in. You can always swap parts out for faster performing versions later on. You can even split up parts in different programming languages.

If you want to decrease development cost go with an ecosystem that most of your developers have mastered. Python, PHP, Ruby, Java, .NET, whatever. Pretty much all these languages have great frameworks these days to allow for faster development.

I personally go with Ruby because they were pretty much first on the scene with their gem ecosystem (which is massive), they have a lot of cool and smart developers in the community and it's overal a great experience. Easy to pick up too with all the resources that are out there.

But whatever you do don't force a language along with it's ecosystem that your developers don't like. Listen to the dev team and know that every language has great potential. I'd come back and ask what frameworks should I use to build a high performance site as quickly & efficiently as possible given I work with language X. Maybe the dev team is unaware of recent awesome frameworks in the language they know & love.

I'm a Ruby fan, but "pretty much first on the scene with their gem ecosystem" is patently false. CPAN is much bigger, and much older.


'Building a large webapp today'

Do you mean starting to build a large webapp today?

I would recommend Ruby on Rails or Python/Django - they allow for fast prototyping and easy collaboration.

I'd maybe go for small components with small APIs so team members could build upon and combine on top in whatever language they want.

I gotta go in a sec, but I'll link you to previous comments of why I recommend Haskell [1] and/or Erlang [2] for a more massive backend architecture.

[1] http://news.ycombinator.com/item?id=4181223

[2] http://news.ycombinator.com/item?id=4341322

I recommend Java the language and base platform running on Apache Tomcat frontended _not_ with mod_jk but with mod_proxy.

See my post here for specifics: http://forum.linode.com/viewtopic.php?t=9230&p=53085#p53...

For the Web UI I recommend GWT by using Eclipse and the GWT Designer GUI web designer they bought from the excellent folks at Instantiations back in 2010.

https://developers.google.com/web-toolkit/tools/gwtdesigner/ https://developers.google.com/web-toolkit/tools/gwtdesigner/...

If you have customers that demand a platform GUI application which accesses your web backend, Google donated WindowBuilder to Eclipse.


Personally, I'd go with PHP.


- It's easy to get things done fast.

- There are plenty of classes available online that'll make things even easier.

- It's easier to maintain (IMHO) than some other languages.

- It'll run on almost all web hosting services cheaply.

- It's scaleable.

If and when you need something more powerful, a seamless transition can be made over to another language.

I agree that PHP is good for "personal" development. But for large-scale system, PHP is far from a good option. By large-scale I mean there need many developers working on many modules interoperating with well-defined interfaces.

There are simply other languages which have all the goodness you mentioned of the "Personal Home Page"(PHP) language, as well as some more advangtages over PHP in a long term development procedure.

As long as you use some tricks to hide the .php from your URLs, else you'll have to add tons of redirects.

But PHP is quite good. Especially PHP 5.4, which has lots of nice things like short array syntax.

Large webapp and seamless transition to another language are not really compatible.

If you use the same database, and just change the code accessing it, it is.

Rails is nice, but it's really really slow. At my job we use Jetty as the server with Play or Lift as the framework -- I think most of the devs like Play better, though. Really easy to run as an unprivileged user and do backends through nginx as well.

Just to put this out there -- since nobody has really mentioned it -- ruby (as a language) doesn't have the greatest performance. You can do some tricks with GC to speed it up (Ruby EE might be a faster option), but you're still looking at 50x slower than C (python is 40x, Java 7 is around 2x, Javascript on V8 -- Node-- is 4x). So if you're planning on doing a lot on the backend, you might want to consider breaking off your logic/processing into java or lisp or something and using a rpc/mq system to send it tasks from your RoR/Django app....but then again...you might not want to start with too many moving parts :)

I agree that ruby is slow, and I actually recommended Java, but ruby execution is not going to be the bottleneck for a webapp, the database is.

I disagree that the slow part of a RoR app is the database - from my anecdotal experience, the slowest part is rendering views and the string manipulation there-in, probalby caused by GC. For a Rails 2.3 App with REE and MySQL, time is ~25% GC, ~25% DB and 50% ruby (from NewRelic).

However, premature optimization and all that, don't choose Java because its faster than Ruby in some arbitrary benchmark. Choose Ruby because it makes you happy and you can meet business objectives faster and easier with it.

On the other hand, if you put your DB on SSDs, back to square one.

Do you have any sources for these performance comparisons? It would be great to see actual speed benchmarks for these different languages.

See http://shootout.alioth.debian.org/ as a starting point for language speed comparisons.

Something that runs on the JVM. Personally, I'd pick Ruby on JRuby.

It is not a matter of the language so much. Use what your team is comfortable with. I find it super important how to structure the app. First design an API. Then implement it on the server with corresponding tests. Then build the frontend. Here is more to decide: server driven (server faces or server pages) or single paged (client side MVCs)

Go, for the same reasons as Java, but because Go is nicer than Java (to me.) The stdlib net/http library is also insanely fast, handling ~40,000 (dynamic, but not DB-backed) req/s without a sweat, and without requiring any kind of callback spaghetti.

I agree with the use what you know mantra unless you don't know anything. Then I would recommend Rails for the backed and Backbone.js for the front end. Choosing popular technologies is important because it will save you and your team a lot time.

You have a number of great choices. Much depends on the team building the app - if you want to be adventurous try: Clojure & Noir. Other options (in particular order):

* Groovy & Grails * Ruby & Rails * Python & Django

I don't know about everyone else, but I was always taught that analysis and design come before the implementation. It's not something you do in 10 minutes before you start making software.

What kind of site is it? Is there a lot of content to manage? Drupal/PHP might even be a good tool for the job, depending on what you're trying to accomplish. More info would be helpful.

Pick the the language your team most familiar with. If there are no one such language, pick Python/Django, Clojure/Noir or Ruby/Rail, and keep yourself far from PHP.

You are going to rewrite it anyway if it's successful so you might start with something easy and quick like Django or Rails.

Depends on the requirements, but I suggest Python+Pyramid Web Framework - it's so flexible that you cant go wrong with it.

I use a mix of PHP and Java.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact