Why do Meteor care so much about you starring them on Github?
Isobuild: why Meteor created a new package system
21–30 of 54 posts
Re: Isobuild: why Meteor created a new package system
#22Why start from scratch? Seems like reinventing the wheel to start from a blank slate rather than forking npm etc. I guess forking doesn't get you to the top of HN though.
Re: Isobuild: why Meteor created a new package system
#23If you're curious, here is the video of the Cordova integration that he mentioned: https://www.youtube.com/watch?v=4dJLPLWMImw&index=11&list=UU...
Re: Isobuild: why Meteor created a new package system
#24Earlier quoted context omitted.
>> 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.
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).
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.
Re: Isobuild: why Meteor created a new package system
#25Earlier quoted context omitted.
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).
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.
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?
Re: Isobuild: why Meteor created a new package system
#26Nitpick: does the term "isomorphic JavaScript" to describe JS that runs on both the client and server annoy anyone? Where's the isomorphism? When I think of isomorphism I think of two things that look different but have the same structure. If you had a set of functions that are synchronous and a set that are async, then maybe you can call the sets isomorphic. Or if you have a Python library that mimics a command line…
That annoys the hell out of me. It's a cool word, sure, but it also has an incredibly tight technical meaning of which "runs of server and client" seems to have next to no relation.
[deleted]
Re: Isobuild: why Meteor created a new package system
#27Nitpick: does the term "isomorphic JavaScript" to describe JS that runs on both the client and server annoy anyone? Where's the isomorphism? When I think of isomorphism I think of two things that look different but have the same structure. If you had a set of functions that are synchronous and a set that are async, then maybe you can call the sets isomorphic. Or if you have a Python library that mimics a command line…
Iso = Equal. Morph = Shape. Isomorph = Same shape.
Isomorphic JavaScript = JavaScript that takes the same shape [in multiple environments].
You're thinking isomorphism as math terminology but it isn't. It's just borrowed from Greek. From a quick search it means "same shape" in regular English too!
Your nitpick would be akin to being annoyed by the use of "group" to mean "a number of people or things considered or classed together" because it has a specific meaning in math.
Re: Isobuild: why Meteor created a new package system
#28Why start from scratch? Seems like reinventing the wheel to start from a blank slate rather than forking npm etc. I guess forking doesn't get you to the top of HN though.
From https://github.com/meteor/meteor/pull/516#issuecomment-12919...:
"If you think about it, if we tried to build all of the above on top of npm, it would be npm in name only. Even if Meteor packages were in npm, you wouldn't use the npm tool to find or install packages (you'd use a wrapper that implemented the 'release snapshots', 'curation', 'repeatability' considerations), nor could you drop them directly into existing npm applications (per 'client vs server' and 'asset bundling')."
Re: Isobuild: why Meteor created a new package system
#29The specific http issue is already solved by browserify. http://browserify.org/
I've been using browserify for quite a while now, and browserify is absolutely fantastic and handles building "isometric" apps with elegance.
I suppose it's nice that they bundle some functionality in like `camera`, but I don't see why that would be an "isopack" thing and not just an external library.
And anyway, doesn't building a framework-specific package disregard the "isometric" ideal: write once, run anywhere?
(as long as "anywhere" means that it's using meteor.)
Re: Isobuild: why Meteor created a new package system
#30Why start from scratch? Seems like reinventing the wheel to start from a blank slate rather than forking npm etc. I guess forking doesn't get you to the top of HN though.
From https://github.com/meteor/meteor/pull/516#issuecomment-12919... : "If you think about it, if we tried to build all of the above on top of npm, it would be npm in name only. Even if Meteor packages were in npm, you wouldn't use the npm tool to find or install packages (you'd use a wrapper that implemented the 'release snapshots', 'curation', 'repeatability' considerations), nor could you drop them directly into e…
That's a good find but I'm not suggesting they wrap npm, but that they fork it. I don't think this comment explains why they couldn't fork their spangly new system from a robust existing one.