Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: PHP vs. Node.js vs. Go for a new startup?
29 points by x0054 on Nov 3, 2013 | hide | past | favorite | 72 comments
I am coming back to the IT industry after about 6 years of being involved in something completely unrelated. My partner and I are starting a startup that’s going to make a online blogging application for a niche market. If we are successful, the application would need to be able to scale to handle a lot of users (100k visitor per day if we are successful, nothing like FB levels or something). Because it’s going to be a blogging platform with a business model similar to squarespace.com, the load will be distributed over many different domains, making it easier to scale.

Both my partner and I have good knowledge of PHP. However, due to the complexity of the project, we will have to find additional developers anyway. From what I read online Node.js and Go are the in thing right now, and scale much better than PHP. My question is, should we stick with the “Devil we know,” PHP, or dive into learning and developing in Node.js or Go. Should we consider another programing language / platform?

What are your thoughts. This are honest questions, we are just looking for some feedback. Thank you for your help.




Unless you know you can't use what you know, stick with what you know. Business concerns trump technical concerns for early-stage startups, and the differences between the three are minute as far as business is concerned. However, having to struggle with learning a new stack can impact your business.

Even if the differences between node.js and Go mattered, you won't get anything valuable from asking HN "should I use node.js or Go", since the two stacks are broadly in a similar niche and have similarly-sized communities. It'll mostly be fans of one technology bashing the other, as you can already see in this thread. It would be better to focus on specific concerns: Do you need support for shared memory on multicore? Is the ability to reuse JavaScript code on the browser and the server a concern? Is there a specific library that's essential to your business that's only available on one or the other? These questions would engender a much more interesting discussion.


This is the best answer. You can scale any language to 100k pageviews/day. Some scale easier than others, but almost anything reasonable will hit those numbers with the proper infrastructure.

New languages and frameworks have their pitfalls. Pick what you know so that you don't get tangled up in the weeds while trying to build out a product quickly.


I still don't understand why people ask this question. It's exactly like you say. The technology stack does not really matter. All that matters is how productive you are in the initial phase.

You should always be choosing something you are familiar with, because it will allow you to get where you want much quicker. And yes, later, then you do actually build a business, you can start playing around with newer technologies. But only if they are valuable for the business.


Double so because OP has been out of the loop for 6 years, which tells me that they are probably a bit rusty and not prepared to absorb a new language on short notice.


node's error handling is by far its weakest point IMO, Go is a lot better in that respect, but a full javascript stack has its advantages


FWIW (to give a little context to this comment):

TJ is the author of Jade, Stylus, Express, Connect, Component, Kue, Mongoose, Knox, Cluster (before the bundled cluster module), Canvas, N, Commander, etc, etc.

If anyone has a perch upon which to criticize Node, he's certainly amongst the most qualified.


I remember you criticized on twitter this point of Node some time ago and the response of some leaders of Node community was like "Sorry, this isn't Erlang" and "Erlang is better but it's harder"


Yeah, pretty naive responses, but understandably most people who have been in the community for a long time don't want to admit the reality, seeing as node is what powers most of our jobs haha. Bottom line is node has a massive flaw, and it should be fixed, at least core members should have interest in fixing it.

Especially with tools like Go there's a lot of pressure to NOT use node in production when great alternatives are available. Node still has the "JavaScript edge", but if fault tolerance remains as poor as it is now that won't matter for long.


Your are right.

Once ES6 is here(when? i dont know), things are going to get better i think,

but Go way of dealing with concurrency in general is a lot better than javascript's for now.


Generators will help a tiny bit but certainly not nearly as much as something like coroutines with separate stacks. I know the node-fiber guy(s) had some issues with v8's internal stack usage so it doesn't seem like a near-future possibility to really have light-weight coros in node :(


Write it in PHP to start. If it takes off, hire a bunch of devs and rewrite it in Go. I say this as someone who hates PHP and generally likes Go and Javascript.

The biggest question in your business model is not "How do I scale this?" or even "What technology should I use?", but "Will this take off?" If the answer to that is yes, you will have resources to deal with the problems of how to scale it, and you will have more information to answer the question of what technology to use. (In particular, you'll know what your developers want to use; you can give them an ownership stake in the technology decision - which should really be their decision, not yours; you will know exactly what feature set you need to implement and what sort of loads you'll bear; and additional libraries or technologies may have come out in the meantime.)

Usually the biggest factor in development time is how well you know the technologies you're using, not any intrinsic level of productivity with the tools. Different technologies will top out at different levels, and IMHO Go tops out significantly higher than Node.js, which tops out significantly higher than PHP (and at least in the early stages, Python tops out higher than Go). But if your goal is to found a successful company and you know what idea you want to pursue, you are better off investing the time in proving out your business idea than in learning the perfect new technology. (If you don't have a concrete idea, investing in learning a new technology is a pretty good way to pass the time until you do.)


Exactly, and I'm in the same situation and we decided to go with PHP (as much as I loathe it) because any cheap hosting has PHP enabled in their base offerings. If things kickup and our idea is validated and we can hire some devs, then we will use something else.


If I was starting from scratch today I'd use Go. Go makes writing fast, scalable and reliable servers as easy as it is possible to make it. At least that is my experience.

I started out writing CGIs and servers in C many years ago and have experimented with Perl, Python, PHP, Ruby, NodeJS and Go since then.

Go has a syntax that is instantly familiar and simple to master. Go's concurrency paradigms are simple to understand and easy to use. Go's compiler is fast and clear. If a Go program compiles it nearly always runs. Go's built-in library has most things you need to write HTTP-based servers.

If you use Go naively you will almost certainly be using Go correctly: your server will be fast and efficient. This is not the case with NodeJS. Writing fast, efficient NodeJS code is hard. Maintaining fast, efficient NodeJS code is even harder.

On the down side - while Go don't suffer from 'callback hell' but it does have a tendency towards 'cast soup' - this makes working with JSON a little trickier than it should.

Aside from the main programming language I would also look at:

* JSON API-first driven development

* Redis

* NodeJS's plethora of web-centric code management tools & compilers: SCSS, RequireJS, Grunt etc

* Single-page javascript App technology: Ember, Angular etc

* Docker.io

* SVG

* Camlistore

These (with Go) are the main technologies I'd use to build a large web infrastructure.


I've done a couple projects with Go now and really like it, but it does have a big weakness as far as backend -- models and and the tools to make a good model abstraction layer. This may be a personal opinion problem, so I'd like to hear what other people think of it. I personally find the tools for interacting with datastores particularly weak. Their sql package for example was way too simple for me.

I've heard good things about the mongodb package and interface, but I haven't had a reason to use mongo.

So really if you use Go for your server side, you'll get a lot of nice benefits, listed by sambeau, but just be aware, you might have to tussle to find the right fit of backend tools, and you will likely have to make your own Model abstraction. This might not be a downside though, as I know a lot of engineers will build (or rebuild) the model layer no matter the framework.


If you're looking for an ORM-like thing, check out gorp (https://github.com/coopernurse/gorp). I find abstracts interaction with datastores quite idiomatically.

I find gorp with Revel (http://robfig.github.io/revel/) makes for a powerful and performant backend. I just wish Revel had better testing integration.


Node doesn't suffer from callback hell if you're an adequate javascript developer. Named functions?

Or how about a class which you pass methods to your callback functions and bind them to the instance properly.

You never need to nest a callback if you know how to work with prototypical inheritance.


So, clearly, I'm not 'an adequate javascript developer'.

Luckily an inadequate javascript developer can write naive code in Go that reads from disk or writes to a socket without worrying about needing "a class which you pass methods to your callback functions and bind them to the instance properly" or "prototypical inheritance".

You can just call a function and use the result.


you still need to write callbacks,wether they are named or not, that's the problem. Go deals with concurrency a much nicer way. 10 asyncs operations in a row are still 10 functions you'll need to write in javascript.


Stick with what you know so you can get your start-up off the ground quickly and cheap. Once you hit PHPs limits, you can still gradually migrate over to $whatever_language_is_hipster_language. Regarding node.js and Go explicitly, I'd give those two at least one year of "maturing time" until you use it for mission-critical stuff.


Pick what you know the best. You will waste time in learning something new instead of working on your product.

When time comes, you can always optimize it(writing performance critical parts in c), or pay guys who are better than you to "translate" your app to another language.

God knows i'm not following this advice, but please do not fall into a "premature optimization" trap.


PHP.

You want to start with something you know, especially at a time when getting an MVP, making iterations, and being nimble is important. Because you both already know PHP, this is a no-brainer. Things have changed dramatically with every aspect of web development in the past 6 years, and PHP is the thing that (although its changed a lot) has probably changed the least compared to your web front-end (HTML5/CSS3), client-side JS, and responsive design (which basically didn't exist 6 years ago).

You should also consider the economics of your situation. Developers who know enough about Go and Node.js to do it professionally are going to charge you much more than those who code PHP professionally.

Ultimately, you're probably doomed to failure just by raising this question. Its been stated ad nauseam on HN before, but you need to iterate quickly and discover what works and drives traffic/sales. Don't waste time trying to learn a new programming language. If you want to devote any time to learning something new, it should be learning how to market your product better.


If it's performance you care about, here's a ridiculously exhaustive set of benchmarks for every web framework you've heard of, and many more you haven't.

http://www.techempower.com/benchmarks/#section=data-r7&hw=ec...

I've got no love for PHP, but if you must, use a recent version and a decent framework.


That link filters it to the frameworks tested on EC2/Amazon, not showing Go and such. Main (i7) tests:

http://www.techempower.com/benchmarks/#section=data-r7


I thought the EC2 tests might be more relevant to an early-stage startup, although I had not noticed that some tests were left out.


If you are starting a business and plan to be the initial developers, use what you know (PHP) because you probably won't have time to learn new stuff and build your business. I'd base the decision on who is doing the coding and what skills they have. Try to stick to standard frameworks and programming practices/decent docs, task/project management, and source control, making it easier to transfer responsibility and project historical artifacts to other developers or grow the team as you grow your business.


100k visitors per day is 4k visitors/hour is 1.2 visitors/s. Suppose each visitor clicks on 10 pages (that is very high) and you get a total of 12 requests/s. Now even assuming much higher load during peak hours you're still looking at max 100 requests/s.

My point is that that kind of traffic is truly minuscule. As long as you set it up correctly and use a decent cache it will handle the load fine. Any platform you choose and hosting for ~$200/month will be enough.


You're assuming that all the visits are evenly distributed over the day. I doubt that assumption will hold...


No, I explicitly assumed peak loads about 10 times the average, 100 reqs/s instead of 12 reqs/s..


100k/day is far from 4k/hour


You need to explain traffic spikes and lulls, because right now your argument looks ridiculous.


You know PHP, so use PHP. There's going to be a mountain of business challenges between 0 and 100K daily visitors - free up your mental bandwidth for that.

Also, something as read-heavy as a blog is well suited for something like Varnish (https://www.varnish-cache.org/). Regardless of the backend technology you choose, a caching http proxy (or whatever) should be absorbing most of the traffic.


Go is a better language than PHP. Much better. It also compiles to machine code, and has excellent multi-thread facilities (goroutines) that boost performance and also make coding simpler (Not more complex!).

But you might find coming up to date on PHP easier, since you already know an old version of it.

There are many more coders available for PHP than Go. But Go programmers on average are higher in quality because the drudges and blubs don't bother learning new languages.

Recently one of my hosting providers sent me a notice that my account was being transitioned to a new version of PHP. That can't happen with a compiled language like Go, since the none of the language itself goes up on the website, only the executable program binary.

I don't know much about Node.js...


I am the OP. Thank you for the great feedback! I think this clarified our choices. I think we will go with PHP, simply because we know PHP now, and don't have to learn something new, as so many of you pointed out. I'll have to update my skills, but that's easy by comparison. I will try to design the project to be as modular as possible, to allow for easy technology substitution in the future. Some one also very correctly pointed out that our blogging platform will be read heavy, which allows for significant caching optimization.


Learn Go! It will take some effort but it's worth it.

I am currently switching to Go from PHP. It's really not that hard to learn once you get your head around the static types and lack of OO - last thing is a big plus in my book. The way they handle it with structs and interfaces are so much better.

Biggest problem is there are limited ressources on the net about Go, and the documentation is lacking compared to PHP, examples are sparse. So be warned it will take you some time to learn.

But it's such a beautiful and simple language, that will be a breeze to support in the future for you and your team. Debugging and maintainability is top knotch.

And much faster than PHP. Node.js is also fast, but well it's not as maintainable, javascript is a pretty messy language. My thoughts on the matter is described well here:

http://umugenzi.wordpress.com/2013/09/06/node-js-vs-go/

For the frontend i recommend AngularJS


I have been using the same. I ported an entire ROR application to GO and Angularjs.


Building a startup is hard enough. Adding another rather large dimension of an unknown language/technology is increasing risks significantly. Untested/unfamiliar technology is one of the top 5 risks which cause software budget and time overruns (pick any book by Steve McConnel on software project management, he does a good summary of these risks).

If you think you have the time and resources, and more importantly, if an interesting technology is part of the reason why you wanted to do a startup; then take the numerous technical advice given by others here.


If you count on 100k visitors per day, it doesn't really matter which one you choose. We are serving well over 10M page views daily and we don't see a reason to switch away from PHP yet.

The only reason I see you might want to go with Node or Go is if you want to attract developers who like to work with latest technologies. If you want to do the first version yourself, then choose the one you are most comfortable with. When you need to scale (from technical and resource perspective), make sure to analyse all aspects of it before going into one direction.


PHP will take your 100k/day and work wonderfully.

PHP can easily take 1m/day.


PHP is rarely going to be a bottleneck, especially with opcode caching. Content heavy stuff beats up a database, so caching there, then stick Varnish in front of apache.


Depends on what you want to do. But I can tell you that this is sort of a pointless argument for a blogging platform

I've found that the really important bit when writing read-heavy web-apps is good caching. The write-path could be written in something slow-ish and it will be hit far less than the front-caches serving data.

So, if you need a web templating language + basic json callbacks, php will definitely do the trick for version 1.0 (or ruby-on-rails or whatever gets you up to 100% feature complete). I've written game backends which did ~2.5k-3k rps on a single machine with PHP (though, I did have to fix PHP APC's locks to handle those loads in the process).

But then you still need to know JS to write the frontend code.

Node.js basically lets you combine 2 skill sets into one - the frontend and backend can share the same data model code for instance. This is easy if you have complex data-structures to communicate between the two layers.

Go actually gives up that advantage, but wins out because it can do compute intensive tasks faster - and can do state-ful daemons in a much nicer way. If you were building say, an online game, where say it was poker game with low-latencies, I would go for go. Definitely.

But as it stands, the only reason to go for Node.js is that your front-end dev can double as a backend-dev. Otherwise, I'd stick with what you know & are most productive in.


I'm going to go against the grain here and say ditch php and build it on node. There is no better way to update your skillset than by building your own product with a tool you've never used. If you're building a web app, you'll need to learn JavaScript regardless.

Worry about scaling problems when you hit them, not when you're picking a language. For comparison, I serve 100k users per day using rails/Postgres on a single $80/month linode server.


Building his/her business is more important at this point than upgrading his/her technical skillset.


"There's no time to sharpen the saw - I'm too busy cutting down the tree"

http://www.codinghorror.com/blog/2009/03/sharpening-the-saw....


Node. Node node node node node.

Why node?

Node is a great framework for building web applications. It's got good support for scalable servers using Amazon Opsworks, nodejitsu, heroku, etc.

Javascript developers are easy to find, and even with no Node experience, any developer worth their salt can get up to speed pretty quickly.

Front-end and back-end can be written in the same language.

You can build rapidly and get to an MVP very quickly, at which point you can either switch to an enterprise language like Java (ugh) or Go, or whatever else to leverage performance, or scale your existing Node codebase using modules such as cluster, or by developing simple strategies on multiple servers.

I have built every kind of applicaton you can think of using Node, from desktop apps using node-webkit, to simple TCP video streaming servers using the built in networking and piping data directly into ffmpeg.

Testing and test driven development is natural in node, and you can write your server tests and browser tests in the same framework using mocha and phantomjs. I've even been building integration tests and automated UI tests using node, mocha and pahntomjs.

Our latest concurrent benchmarks for a load balanced group of t1 micros on a single mongodb instance get to at least 30k concurrent requests a second before you get a few timeouts, but that's just because i'm not too familiar with ops and haven't done any proper optimisation yet.

There is no right answer to this quest, but the above is my personal and professional opinion.


Summary:

A Javascript developer that have been using it for client-side purpose will not learn how to use nodejs from the day to night even if he is a expert on it, for something nodejs is for serverside programing.

"Front-end and back-end can be written in the same language.". I would prefer to right my backend in something else instead Javscript , even PHP would be a more pleasant choice, and if that would be the case i would rather use Clojure and Clojurescript togather to right everything in the same language.


> Mediocre Javascript developers are easy to find

FTFY.

In all seriousness, though, I'm the lead developer on a web applications team at a medium-sized client services company and my experience has been that competent JavaScript developers are among the hardest kind of developer to find right now.


Use whatever is best for you... PHP can scale... I've built applications that handled 4x as much visitors per day as you mentioned without any real problems... Crappy code is in every language, it's all on you... You can build amazing things in PHP... Just like you can in Node.js and Ruby, and Python...

If you want to build it quickly, do it in what you know best... If you want to learn a new language as you go, build it in Node.js or Go.


If one were to analyze this concretely instead of with a bunch of platitudes, you want to find the optimal intersection between the productivity a language grants you for the task you are trying to accomplish, the amount of developer time required to maintain it, and the hardware required to support it.

1) Productivity - The speed at which you can create a respectable prototype. This is not just a matter of your team having mastered the language -- some languages are more specialized than others. For example, it will be orders of a magnitude easier (i.e. will require less dev time) to build a distributed system in a language with built-in actor support (i.e. Go, Scala, Erlang, etc.) than it would be to do so in say, PHP.

2) Maintainability (in terms of dev time) - The languages and its predominant frameworks will dictate how difficult it is to maintain a codebase. For example, many programmers will attest that statically typed codebases are easier to grok and maintain than dynamically typed. Dynamically typed code requires more edge case testing, and statically typed code allows an entire class of bugs to be compiled at runtime.

3) Hardware - Languages have different performance characteristics. Some languages will require $x / unit of web traffic. Others will require $y / unit. This translates into the # of servers required to support your app, which may diverge at a polynomial rate or worse over time. This is unlikely to be a big factor in the early goings, but it can matter a lot when / if you achieve success, so can be a worthy tiebreaker -- because it is highly unlikely you will be switching languages entirely once your company is in the groove, so the choice you make early on will stay with your company for a lifetime.


Yes, use what you know the best. Might want to consider using a framework like Laravel 4 or Symfony 2 to boost your productivity.


Great question. Other folks have made good points about the value of sticking with what you know but on the other hand there are advantages of other platforms as well. Could the kind of blogging application you've got in mind be built around Ghost? [1] If so then node could make a lot of sense.

I weighed a similar choice this summer and my first thought was Go but a friend suggested I look at node.js, Closure or Scala as alternatives. I wound up choosing node.js for an initial version because of the vibrant ecosystem with some great building blocks, mostly MIT-licensed.

jon

[1] https://github.com/TryGhost/Ghost


I am a big fan of Go, but why not python or even ruby? Seems either python/ruby would be a better fit for this kind of project than node/php, and easier to hire for than Go (since that was kind of alluded to as a requirement).


100K req/day translates to about 1 req/sec, which you can run on anything using any technology with zero scalability problems. it can probably run on my old TI calculator ;)

even if traffic has high peaks, scalability is not your concern.

Time to market and quality of people is. If you are going to do it mostly by yourself with some help later in the game, then do it in PHP. If you are going to hire people anyway, you might get a better talent by choosing something else. A blogging platform doesn't need a node/go level of concurrency. so don't discard rails and djungo.


What's wrong with Python? I've messed with all 3 you listed but at the end of the day I always end up going with Python.


i used go,php and nodejs.

let's say you want to create a bloging plateform like Wordpress. Wordpress code is horrible,but Wordpress has loads of features (and plugins).

1/PHP - horrible language with very good libraries. Just look at the Symfony library, there is everything one's need to build a blogging plateform the sane way. And if you want to distribute your project as open source, you'll find more user with PHP that any other language.

2/ NODE Node is here to write servers. NodeJS is new,so dont expect libs to be as mature as php ones.

3/ GO i think go can be compared to nodejs but better. The way go deals with concurrency is better, the language itself it better than javascript. But same problem , new stuff, a lot of code needs to be written.

PHP has an interesting thing coming,Zephir that will allow you to write php native C extensions with a language close to PHP/Java but statically typed. so you could distribute your blog engine as a native extension.


Here's an interview with the founders of StatusPage.io and about how they built it. You might find it interesting. In the end they stuck with what they knew - Rails.

http://blog.leanstack.io/how-statuspage-io-was-built/


I'd strongly recommend using what you know best. If you're good at PHP, use that.

If, however, it's been a long 6 years and you're going to be pretty rusty at whatever you use, I'd recommend giving Node.js a shot. We've had really good luck with it and it has a fantastic community behind it.


PHP is such a poor technology, however many great websites were build using it, so I would say that you should go with technology you know best.

PHP will rather never be a bottleneck itself, you can fuck up many other things like data storage. All modern data storage solutions come with PHP interface.


Go with PHP and buy Steve Corona's book - https://www.scalingphpbook.com/.

Also, be sure to get up on the improvements that have been made with PHP 5, 5.3-5.4. It's come a long way in 6 years.

Good luck!


If you are hiring "additional" developers then you need to go with something you know, unless you want to learn something new and get started on it first. Otherwise you are just hiring developers and not participating...


PHP, given that's what you know. Also PHP developers are easier to find and cheaper.

As for scale, It doesn't really matter which you choose, because if you reach scale, the difficult bottlenecks will all be around the database anyway.


If it must be one of those 3 options, I'd probably go with TypeScript running in Node.

Scala is another option you might want to look into.

For scaling, see: http://12factor.net/


If you don't care about performance issues, go for PHP, with a nice framework, so you can get ready quickly. Else, go for node.js (I don't know Go, but it seems it has a pretty good performance too).


Bootstrap it on top of an existing CMS, such as WordPress or Drupal. It'll save you heaps of time. Hell, you may even be able to do it alone, with all the time you'll be saving.


In brief: - PHP => cheap developers - Node.js => share code between client / server / meteor.js - Go => multithread & performance


It depend on what kind of online service you want create.

I think you will get 100 postings where 100 people try to convince you from their favorite language.


Go with PHP.

It will speed you up. Scalability isn't an issue right now for you, so don't optimize for it.


We have a server that we've deployed for our customers. It's a middleware-free web platform. It won't be released officially for some time but we'd be happy to have you evaluate it.


How about Go vs Java/Scala/Clojure?


GO for it. Go is much better and easier.


Java.


Summary: Php is a stable and reliable.

Nodejs: Is new and young.

Go: Same history as the one above.

Scalabilty is not something that you should worry about at this stage, if your app reach the scale that you expect it to get then refactor and do something about it. Scalability has nothing to do with the language, so use that "Devil you know", stop wasting time and move on.


I'd go with a simple Rails or Sinatra app.




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

Search: