You can still use exactly the same code in the browser and on the server. Allowing stuff like server-side rendering on old browsers and JS rendering for the majority of users from a single piece of code.
You can still use exactly the same code in the browser and on the server. Allowing stuff like server-side rendering on old browsers and JS rendering for the majority of users from a single piece of code.
If you are in a client browser (any client browser, no matter how old) and try to do HTTP.get('http://www.google.com') it will fail because of CORS restrictions. If you do that on the server or in a native app, it will succeed (because they do not have CORS restrictions).
if anything, isn't this a great argument for a client/server package manager? you could write a library that knows to use and create a proxy if a specific client type tries to fetch cross domain.
Working around CORS is just a matter of server configuration. With the same API you only fix the servers, with different APIs you have to fix both the servers and the code.
Also HTTP.get() may be smart enough to detect cross-domain call failure and try to automatically proxy the call. Meteor has a server-side component that can act as a proxy.