Can somebody please answer the question below regarding the Google API for Charts?
1- Is Google Charts API completely independent of any other JS libraries or software like Flash etc?
2- Does it work completely offline (using the new version)?
3- Is it completely free for commercial usage?
Thank you.
The API is dependent on Google's internal libraries (nothing you have to specifically load), but generally not any external libraries. The exceptions are for the AnnotatedTimeLine and Motion charts, which are Flash-based. 3rd-party visualizations may be dependent on other libraries.
You cannot use the API offline. Downloading the API and hosting it locally is strictly forbidden in the Terms of Service.
The API is free for almost all commercial usage, see Terms of Service for details.
The google charts api uses js libraries.
You can't use it offline
your computer must have live access to http://www.google.com/jsapi in order to use charts. This is because the visualization libraries that your page requires are loaded dynamically before you use them. The code for loading the appropriate library is part of the included jsapi script, and is called when you invoke the google.load() method. Our terms of service do not allow you to download the google.load or google.visualization code to use offline.
(https://developers.google.com/chart/interactive/faq#offline)
3 . The api is completly free (https://developers.google.com/chart/terms?hl=nl#license)
Related
A) <script src="https://apis.google.com/js/platform.js"></script>
versus
B) <script src="https://apis.google.com/js/api.js"></script>
I am a little bit confused about how to use Google OAuth service, should I use platform script or api script.
The functionality in platform.js is a superset of the functionality in api.js. If you are using both the sheets APIs and the sign-in API, platform.js will suffice, you needn't load both. ~https://github.com/google/google-api-javascript-client/issues/658
platform.js is a platform detection library that works on nearly all JavaScript platforms.
platform.js is for informational purposes only & not intended as a substitution for feature detection/inference checks.
platform.js is Google's library for accessing the Google Plus API.
Platform.js is part of the BestieJS “Best in Class” module collection. This means we promote solid browser/environment support, ES5+ precedents, unit testing, & plenty of documentation.
Using the platform.js library, it becomes very easy for us to detect the browser just by writing one line of JavaScript code. You can get this library on GitHub. All the complicated code is already written in this library and we just have to use it.
The answer of Neha Jha is right for your question, however, I wanna update the news from Google. They announce to discontinue Google Sign-In JavaScript Platform Library for web and they ask us to migrate to the new thing before 31/03/2023.
platform.js is the Google Plus API, which has been shut down march 7th 2019.
api.js is the Google API Client Library for JavaScript "The Google API Client Library for JavaScript is designed for JavaScript client-application developers. It offers simple, flexible access to many Google APIs."
Use api.js for your use case. See this.
Speed tests report that my site loads in about 8 seconds on mobile and 2 on desktop.
When looking at the "waterfall" of the asset/script loading it seems to be mostly due to 3rd party analytic scripts like zendesk, hubspot, and google analytics.
Is there anyway to optimize a site for mobile when using these type of scripts?
As far as the files go on my site I've optimized them nearly as much as I could. I've even used a cron (probably not a great idea) to cache the google analytics script locally and fetch a newer version every few days.
I've looked into using Tag Manager or something like Segment to optimize the script loading of these files, but I'm not sure if that will actually improve performance or if those services are mostly just for convenience.
I've also looked at service workers for mobile app caching, but I'm not sure if that will help either and don't want to dive into learning how to use them if it won't actually make a difference.
To sum up, is there a way to speed up mobile with multiple 3rd party analytic scripts or am I just going to have to forgo using some of them or possibly add a mobile version or AMP version without using them or some of them.
Since you've tagged AMP in your question, I'll answer from the AMP perspective:
AMP solves this problem by using a mediator that connects directly to the endpoints of various analytics providers, replacing their clunky and power hungry JS scripts.
Of course, AMP comes with its own set of constrains and is really only targeted at powering static content, but if you're willing to go that route, learn more about AMP Analytics here.
I'm a bit stuck with which charting library I will use in my project. Im stuck with this two (but also open for other suggestions)
For YUI Charts :
Pro :
- Very robust and configurable
Cons :
- Uses flash 9 >, which might potentially be inaccessible for users without up to date flash version
- Does not support export to image (for flash versions < 10 only)
For Google Visualization API
pros:
- small file size for the libraries,
- can be exported to static image charts (via separate API call)
Cons
- limited configuration options
So there, please help me decide. YUI charts has the edge over configuration options but Google Visualization API has the edge in terms of accessibility as it uses SVG to render the grapsh instead of Flash. For users that are hand-cuffed by corporate IT prohibitions , they cant just upgrade their Flash version and the page will not work.
Thanks!
I would choose Google's API as it requires only a javascript interpreter or internet access (to Google).
The fewer dependencies, the better. Not to mention there is quite an array of tools for manipulating SVG images.
If you really cannot make do without certain features in YUI or cannot find simpler ways to express your charts, then choose YUI.
You might also want to take a peek at http://www.simile-widgets.org/ It might be overkill / bad fit for your needs, but it is positively sexy.
If you don't want flash for drawing charts in your application it is better to choose
Google Visualization API...
The Google Visualization JavaScript API lets you access structured data and visualize that data using JavaScript in your web pages. The Google Visualization API also enables creation of gadgets.
If I wanted to get a javascript library published to the ajax CDNs hosted by Google or Microsoft, what would I have to do?
Are there any formal requirements for this, like number of users etc?
I doubt there are any formal requirements except that the lib has to be wildly popular, and probably will have to be regarded to be of high quality by the companies running the CDNs.
Google's Ajax libraries main page has this to say:
Google works directly with the key stake holders for each library effort and accepts the latest stable versions as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.
I'd say if you feel your library is popular and good enough - seeing as Google for example are hosting 12 projects at the moment, yours would have to be in the world wide top twenty by some measure though! - simply talk to Google and Microsoft and see what they say.
Here is a blog post that could provide you with some contacts to approach. Also, the author seems to be somehow affiliated with Google (he's talking about "we").
The Google Ajax Library Blog may also be a good resource.
The Yahoo Javascript library (YUI), JQuery and less so Google maps all allow you to reference their files using the following format:
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/yahoo-dom-event/yahoo-dom-event.js"></script>
This does a request for the script from their servers, which will also pass to their web server the HTTP referrer. Do Yahoo etc. use this to produce statistics on which websites get what traffic? Or is this a conspiracy theory?
Of course their servers most of the time will be a lot faster than any small company would buy, so using the hosted version of the script makes more sense.
Chris,
I work on the YUI team at Yahoo.
We host only YUI on yui.yahooapis.com; Google hosts YUI and many other libraries on its CDN. I can tell you from the Yahoo side that we don't monitor site usage of YUI from our CDN. We do track general growth of yui.yahooapis.com usage, but we don't track which sites are generating traffic. You're right to suggest that we could track usage -- and we state as clearly as we can in our hosting docs that you should only use this kind of service if the traffic logs generated on our side don't represent a privacy concern for you.
In general, though, I don't regard CDN traffic for library usage to be a reliable measurement of anything. Most YUI usage, even at Yahoo, doesn't use yui.yahooapis.com or Google's equivalent, and I'm sure the same is true for other libraries. And even when a site is using YUI from our servers, we wouldn't have comprehensive traffic data of the kind you'd get from Google Analytics or Yahoo Analytics -- because not all pages would use YUI or the CDN uniformly.
Given the advantages of the hosted service -- including SSL from Google and YUI combo-handling from Yahoo -- I see the CDN as being a big win for most implementers, with little downside.
-Eric
Of course they produce statistics - at minimum they need to know how many resources they spend on hosting these scripts. And it's also nice to know who uses your code.
I don't think it's a bad thing.
And using a hosted version makes even more sense because your visitors might have the script already cached after visiting another site.
Sure, they can easily have statistics about which sites use YUI and how often, and also which parts of YUI API are more populare (among small sites). However, they cannot know what exactly web site visitors do with their libs.
Given, that they (Google & Yahoo) index a lot of web pages, they can get an even more precise statistics if they analyze their indexes. So you cannot hide that you are using YUI if your site is public.
The same applies to Google maps and jQuery.