Hacker News new | ask | show | jobs
by untog 4308 days ago
Sounds interesting, but the devil is in the details. To use their example, HTTP.get() will have to deal with CORS on the web, but not in apps. If you end up with dozens of "oh yeah well for X you just need to add Y" situations then the utility is kind of wasted.

And to be honest, I still don't get why this requires a new package manager. NPM (with a utility library, perhaps) could perform most of these functions.
2 comments
rational-future 4308 days ago
>> HTTP.get() will have to deal with CORS on the web, but not in apps

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.

link
untog 4308 days ago
But you can't.

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).

link
rational-future 4308 days ago
Yes, we can :)

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.

link
untog 4308 days ago
Sure, if you control the server. I guess these Meteor packages will only be useful in those contexts. But what if I want to use the Twitter API, for example?
link
ef4 4308 days ago
I'm pretty sure their answer is: we can automatically proxy through the meteor server to twitter or anywhere else.
link
rational-future 4308 days ago
I believe Twitter is trying to kill their API, hence no CORS or JSONP.
link
joesb 4308 days ago
The point is that only HTTP.get() inside browser require CORS to be enabled on the server side. On non-browser environment, HTTP.get() can open any cross site web request.
link
catshirt 4308 days ago
the code doesn't fail, the response just differs by client. for the purposes of your example, the "server" is a actually a client. and that's not a problem for the package manager to solve.

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.

link
astrodust 4308 days ago
If npm had some kind of conformance flag, where you could tag your package with the platforms it supports, this would help considerably.
link