Complex? For some certain tasks perhaps it's verbose, but I do like that the API is structured in a Java-like way.
With wrappers like these I need to constantly consult the docs to find out what arguments to pass to the constructors.
With the google maps api I just create a new object and can use the various setters and getters to set and retrieve values. Everything is mostly self-descriptive as well.
You can place an extern file so that you can get additional help via intellisense in an IDE as well.
Personally, I don't like the Java smell. GMaps.js is more idiomatic JS; I have no problem remembering props to pass in to a method, but can never keep straight a bunch of classes and getters/setters. And I prefer building abstractions over relying on IDEs; being able to go back and change some keys/vals is more maintainable to me than having to go back to a bunch of explicit methods, with all their quirks and gotchas.
ugh, I was hoping we were moving past the "smells like Java" kneejerk objection. It doesn't apply here. Maybe you don't use the Maps API very much? It (v3, at least) actually strongly embraced being a Javascript API in a time when most APIs were not. Almost all objects are created with options specified almost exactly the same way as here. The main thing this seems to add is being able to specify event handlers in the same way (that really does appear to be the majority of the code).
It does look lighter to use, but that's just the age-old difficulty of writing an API that's both lightweight when it needs to be and completely flexible when it needs to be. You'll run into the same problem with this library, but in the other direction, if you need more than one click handler on something, or you need to use the underlying MVC structure directly, etc.
edit: it's a minor thing, but not having to create a LatLng object every time you need one is nice on the code verbosity scale. That's one of the first things I alias when making a project with the maps api, actually. Lots of "new"s in your code isn't unidiomatic Javascript, though, even if some wish it were :)
Maybe it's not a "smells like Java" but from Google's perspective, they treat every api method with equal weight because so many people use different parts of it. GMaps is trying to solve the simple use cases where the other 80% of the api methods are unnecessary.
If you need something specific and you're building something beyond the typical google maps customer, then you'll have to use the google standard apis, but most people would be happy to use something simpler.
