Gmaps.js the easiest way to use Google Maps | Hacker News Reader

Gmaps.js the easiest way to use Google Maps

hpneo.github.com

276 pointsDanielRibeiro40 comments

... and also probably against the newest terms of use that Google put out recently:

https://developers.google.com/maps/terms 10.2(a):

"(a) No "Wrapping." You must not create or offer a "wrapper" for the Service, unless you obtain Google's written consent to do so. For example, you are not permitted to: ... (ii) create a Maps API Implementation that reimplements or duplicates Google Maps/Google Earth. For clarity, you are not "re-implementing or duplicating" Google Maps/Google Earth if your Maps API Implementation provides substantial additional features or content beyond Google Maps/Google Earth, and those additional features or content constitute the primary defining characteristic of your Maps API Implementation."

I think they are talking about web APIs here, not client-side libraries.

No, this applies to client-side libraries. OpenLayers required a specific letter from Google saying the terms didn't apply to them (but will apply to others).

Note that it says nothing about using a wrapper.

Honest question: what's the raison d'etre here? Is the Maps API really that annoying that people need a wrapper?

Yes it is overly complex.

Really? I found it rather easy to use compared to say, GIS.

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.

Complex how? And how does adding another layer between the service and the user limit complexity?

Completely agree. It's really pretty easy. The main problem is that it's ugly in places and some things you may want to do are downright impossible (such as separating the results containers from address autocomplete from the input to create a mobile interface. You have no way to get at the results json. The only option to do that is to proxy their HTTP API through your server because JSONP is no longer an option.

I really like that the interface is generic, abstracting away the mapping service. This way it may be possible to write bindings to other mapping services, such as OpenStreetMap or Bing Maps, and switch the service by just changing a variable.

There's OpenLayers too (http://openlayers.org/). Google Maps or Bing Maps are one of the possible layers. Works well for GIS-type folks, has some quirks otherwise. Don't like the layer switcher myself however, not very strong UX wise.

Yeah, using OpenLayers here too-- I was about to say almost the exact same thing. My PM is one of those GIS-type folks; I'm not, and there's some frequent pain. I've actually been messing with layer switching this morning, we have our own control UI for it. The native OL controls are generally pretty lame (especially compared to GMaps). We're progressively throwing out most of them, opting for a different direction that fits more with our filtering/search features.

Code-wise, I've found OL pretty awkward. It stinks of Java to me: over-organization, unnecessary complication in the name of feature completeness, confusing function sigs, overuse of `new`, etc. Feature-wise, I have little to complain about, but GMaps.js's look a lot more idiomatic and nicer to write code against, though I bet there's still comparatively a lot missing...

If you like that, have a look at http://mapstraction.com/

As someone who likes to hack things together but is really not a great developer this is wonderful!

Would it be possible to add integration for Stamen maps?

http://maps.stamen.com/

I'd love that!

That's certainly a nice project. No idea why it went pass our radar. We'll look into that!

Didn't know about Stamen maps either, thanks for sharing

Requires jQuery. Strange that this is not mentioned anywhere in their website.

Looking at the source, this also requires jQuery in that unique 'jQuery as a crutch for not understanding the DOM at all' way.

It was born as a jQuery plugin for a couple of projects we had to use Google Maps and that incidentally used jQuery as well, so it made sense.

We aren't totally sure it will move forward as an independent Javascript library but it's certainly a turn it could have. We are rewriting it with Coffeescript now, so maybe is something to consider more closely.

Has anyone compared this to Leaflet[1] or Mapstraction[2]? Leaflet was a big help on a quick project, but the abstraction was somewhat leaky and there were annoying bugs switching between maps.

[1] http://leaflet.cloudmade.com/ [2] http://mapstraction.com/

While I respect the work done by the Mapstraction guys, I found that to get several non-trivial things working, I had to dig into the proprietary parts of the individual underlying framework - which defeats the purpose of using Mapstraction in the first place.

I had to rewrite large portions of the map interface code when I switched from Google to Open Street Map.

That said, the project is still young and maybe once I get some time, I should really contribute code to it to get those bits I needed working.

OT: Please fix the title. The unpaired quote makes me feel uncomfortable. ;)

bookmarked for my current project, why doesn't Google Map use an API like this? Would save lives.

For what is worth, we also have a Rails gem for GmapsJS at github.com/xenda/gmapsjs.

Issues and ideas are always welcome for both the JS and Gem versions!

I was under the impression that features like routing required the expensive paid Google Maps tier.. is that not the case?

I does not. You have access to a, albeit limited, number of requests to to Geolocating, Geo-referencing and others. Should be no problem for a personal or small project.

And that's* why cleaner APIs like this are awesome: I didn't knew half the available capabilities of Google Maps API until gmaps.js was published.

I recently was reading was looking for an API that had address and directions support and found these two, http://gmap3.net/ and http://code.google.com/p/jquery-ui-map/. Any plans to add that to gmaps.js?

Also nice is this JQuery plugin by Shawn Allen that uses simple html and data attributes to generate basic maps. Very useful if the maps are just supplemental, because they can be just built out in a template: http://prag.ma/code/htmapl/

Very nice. Going to use it.

Great work, I'm using GMapEZ, but gmaps.js seems to be much easy and cleaner IMHO. Will take a look at it later. Thanks for sharing.

This is one of the coolest things on here today. Definitely bookmarked.

Add to my toolbox. Thanks!

GMAP3 (http://gmap3.net/) is the killer ;-)

Actually, this feels and looks like a ripoff of J.B. Demonte's work (https://github.com/jbdemonte/gmap3), or is it a fork?

Not really. Demonte's is a much thinner wrapper and have a totally different API. This is a brand new (and nicer to use IMHO) solution to the same problem.

Disclaimer: I commited the "staticMapURL" method to gmaps.js

The gmap3 and also the one on google code(forget name) seem to have a larger API, for example I really like the "DirectionsRenderer",I don't see anything like that gmaps.js.

Reply on news.ycombinator.com