This is really a case of picking the wrong tool for the job. __This is in no way a slight of the author__...b/c I have done worse on more than one occasion, so thanks for sharing.

To anyone reading, you really should understand your workload before picking tools. And, you need to understand the difference between Web Application vs. Web Site: Which are you building?

Server-side rending is the winner for content sites (as mentioned by the author). Beyond initial rendering, a server-side solution allows for more caching. Depending on the site you could even push a good amount of file delivery to a CDN. In the end the author switched to Go, but Node.js + Express, RoR, PHP, Java with Play, etc. would all work just as well.

Next, are you CPU bound or network bound or I/O bound. If you're writing an application that requires heavy calculations that utilize massive amounts of CPU, then pick the appropriate framework (i.e. not Node). If you are I/O bound then Node may be a great solution.

Client-side rending (such as Angular/Backbone/etc) really shine when you need a web application (not web site). These frameworks are best when the application code is significant relative to the data such that many small JSON requests deliver better overall performance. Think of a traditional desktop application or native mobile app where the application code is in MB, but the amount of data required per request is in bytes. The same logic applies to web apps.

A few areas where problems such as what the author experienced emerged from blanked statements about technologies:

1. Gulp vs. Grunt: I use Grunt. I may switch to Gulp. But seriously, which one is "more complex", "faster", can be quantified. Lots of people pick the wrong technology because the web is littered with echo'd opinion statements. Exchange "more complex" for project A has a config file with X number of lines, while project B has a configuration of Y number of lines for the same task. Or project A uses JSON for its configuration while project B uses YAML.

2. "Or we could have used a different framework) - with a link to Meteor" - No please do NOT use Meteor for your site. I love Meteor and want it to succeed, but it is not the optimal choice for a content heavy site where each user views a large amount of data. As mentioned above, use a server-side rendering solution (like you did with Go), then cache, then push to a CDN. Problem solved. Meteor is awesome and is a great real-time framework. Use it when you need real-time capabilities...but not for a content heavy, static site.

> but they just weren’t the right tools for our site.

This could have been the title or first sentence and would have delivered 100% of the message if the reader read no further.

A lot of these articles about why we changed from technology A to B could be much improved if the original decision making was documented (not just the switch). As in we picked project A because we thought it would deliver A, B and C benefits based on our applications required capabilities. However, our application really needed capabilities M, N and O, which project A was not a good fit for. So, we switched to project B and experienced the following improvements. Therefore, it can be concluded that if your application needs M, N and O then project B will be a better fit.