Isobuild: why Meteor created a new package system • Hacker News Board

Re: Isobuild: why Meteor created a new package system

#11

Post by astrodust » Thu, Aug 28, 2014, 4:47 PM UTC

richardwhiuk wrote: post #5

panarky wrote: post #2

This is awesome. With Isobuild and Cordova, you'll be able to add a camera package to your app and use one simple Camera.takePicture() API to take a photo, and then type one command to build your app not just for the browser, but for the iOS and Android app stores too.

As if anything is that simple. Where will the photo be stored? What effects will be applied? What format will it be in? How large will it be? What happens if it requires a permission request (e.g. in browsers and on iOS)? Will it auto generate the manifest file?

For example, JPEG returned as a string or as part of a result object. Why is this so impossible to imagine? The rest is all options you can specify.

Re: Isobuild: why Meteor created a new package system

#12

Post by chubot » Thu, Aug 28, 2014, 4:48 PM UTC

Nitpick: 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 tool, then they could be isomorphic.

Re: Isobuild: why Meteor created a new package system

#13

Post by imslavko » Thu, Aug 28, 2014, 4:54 PM UTC

icholy wrote: post #3

panarky wrote: post #2

This is awesome. With Isobuild and Cordova, you'll be able to add a camera package to your app and use one simple Camera.takePicture() API to take a photo, and then type one command to build your app not just for the browser, but for the iOS and Android app stores too.

Because running the cordova commands is so hard.

You will be surprised, but I believe it can be hard for a lot of people who come from the webdev background.

When I just started with Cordova, I went to a HTML5DEVCONF talk where the speaker tried to install (just install) Cordova in a 20m slot. He failed, his slides had all the ingredients (Xcode, jdk, ant, maven, npm, cordova, ios-sim, etc) but on the live demo his new machine failed because some of the many steps wasn't satisfied.

About using Cordova: again, for newcomers, it is so non-obvious: what do you do when your build fails? How do I debug this objective-c code again? Why the heck Cordova doesn't give me all the logs by default? ios-sim is an npm module that is compiled with a C compiler and the build process is navigated by rake - ruby-based make clone.

Re: Isobuild: why Meteor created a new package system

#14

Post by untog » Thu, Aug 28, 2014, 4:54 PM UTC

rational-future wrote: post #8

untog wrote: post #6

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.

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

Re: Isobuild: why Meteor created a new package system

#15

Post by mjackson » Thu, Aug 28, 2014, 4:56 PM UTC

tl;dr: "We want to build isomorphic apps, so we wrote a new package manager"

Coupling the goal of building isomorphic apps with the need for a new way of managing packages to accomplish that goal doesn't make any sense. How you install packages and manage dependencies has absolutely no bearing on what you can or cannot do with those packages.

In other words, you can write fully isomorphic apps using npm as your package manager. We're already doing it.

Re: Isobuild: why Meteor created a new package system

#16

Post by [deleted] » Thu, Aug 28, 2014, 4:58 PM UTC

mjackson wrote: post #15

tl;dr: "We want to build isomorphic apps, so we wrote a new package manager" Coupling the goal of building isomorphic apps with the need for a new way of managing packages to accomplish that goal doesn't make any sense. How you install packages and manage dependencies has absolutely no bearing on what you can or cannot do with those packages. In other words, you can write fully isomorphic apps using npm as your packa…

[deleted]

Re: Isobuild: why Meteor created a new package system

#17

Post by mjackson » Thu, Aug 28, 2014, 4:59 PM UTC

[deleted] wrote: post #16

mjackson wrote: post #15

tl;dr: "We want to build isomorphic apps, so we wrote a new package manager" Coupling the goal of building isomorphic apps with the need for a new way of managing packages to accomplish that goal doesn't make any sense. How you install packages and manage dependencies has absolutely no bearing on what you can or cannot do with those packages. In other words, you can write fully isomorphic apps using npm as your packa…

[deleted]

That should be part of your build system, not your package manager.

Re: Isobuild: why Meteor created a new package system

#18

Post by general_failure » Thu, Aug 28, 2014, 5:08 PM UTC

The specific http issue is already solved by browserify.

http://browserify.org/

Re: Isobuild: why Meteor created a new package system

#19

Post by catshirt » Thu, Aug 28, 2014, 5:09 PM UTC

untog wrote: post #14

rational-future wrote: post #8

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

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.

Re: Isobuild: why Meteor created a new package system

#20

Post by tel » Thu, Aug 28, 2014, 5:12 PM UTC

chubot wrote: post #12

Nitpick: 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.