Those technologies probably don't scale well in terms of hiring.
Also, those technologies probably don't scale at all to 1000s of servers, something a Google project has to do from day 1.
(I'm not sure they'd even be fast enough on a single server. As a rule of thumb, the more technologies you put in the mix, the more abstractions there are, the harder it is to minimize the work done.)
Yes. We did work to make wave scale before we knew what features would be important to users. That was definitely a problem, but its hard to avoid scaling when you're google and the whole world is watching.
The earlier you launch, the sooner you need to do that scaling work. But the later you launch the more development you do in a vacuum, without real customer validation.
I guess you're talking about node.js .
That, of course is a hot topic today, but I'm confident that this problem is solvable.
That's why I called it 'node.js-ish', meaning a backend that can do similar things as well as or better than node.js.
CoffeeScript and Backbone.js have nothing to do with scale, as they are used on the front end.
The author talked about how horrible it was to have the UI written in Java (having to wait 3 minutes for a recompile after a CSS change).
These two tools (plus SASS and alternatives) on the front end makes Java->Javascript totally redundant, imho.
Also, those technologies probably don't scale at all to 1000s of servers, something a Google project has to do from day 1.
(I'm not sure they'd even be fast enough on a single server. As a rule of thumb, the more technologies you put in the mix, the more abstractions there are, the harder it is to minimize the work done.)