I've been doing this for 8-9 years, I have a good idea on how to talk with my clients :)
I've been doing this for 8-9 years, I have a good idea on how to talk with my clients :)
We've got a pretty good google maps integration in our rails app & I've found sticking with plain old rails for CRUD and using fancy-pants javascript in high-value places to work out well.
Your milage, and billing rates, may vary.
As an author with every post and submission you make a conscious decision about what is important to you. Do you want to enlighten your readers or do you want to gain notoriety at the expense of your audience?
Ask yourself, do you want to be the Daily Mail or Le Monde?
Because there's a subset of map-based sites for which pure, out-of-the-box Google Maps is the best solution, but I'd estimate it at no more than 30%. (StreetView and consistent street-level addressing are the two main points in its favour.)
For the other 70%, you will build something better by working with the raw map data (which usually means PostGIS) and using custom cartography (which could mean a lot of things, but let's say TileMill+OpenStreetMap).
This greatly swings the balance back towards Ruby or Python. FWIW I don't generally use Rails, preferring a custom Rack+DataMapper stack, but the same point holds. The amount of smart geo stuff you can do in one line of code with a PostGIS-friendly ORM is astonishing.
More broadly, your article says "technology A is better than technology B because C". That's cool. And here I am, posting a comment that says technology D (custom geo) is better than technology E (GMaps) because F. No doubt there are also arguments G, H, and so on. Your C is essentially a productivity argument - do the same thing faster. That's important, yes, but deeply personal (I find it difficult to believe I'd ever be as productive in JS as Ruby, and I'm not entirely a JS n00b). But if F, G, and H enable you to do actual new stuff, they're the arguments I'll listen to.