

Isobuild: why Meteor created a new package system - Mandar
https://www.meteor.com/blog/2014/08/28/isobuild-why-meteor-created-a-new-package-system

======
igl
Everything about Meteor reads like a marketing article.

How about:

\- It defines global variables. \- The documentation is full of red warning
messages and "this will be easier in the future" \- The code is pretty
unorganized and has some wild pieces in there. \- do any of your friends
use/heard of meteor?

~~~
matthewmacleod
I don't think that's fair at all.

The _whole point_ of Meteor is to play with different approaches to web
development that will be required in the future (if you want to build big
distributed, interactive web apps). It's not finished yet, and they're pretty
upfront about that.

~~~
cmelbye
I'm curious, what part of Meteor will be a requirement for future web
development? Are we not already building big distributed, interactive web apps
without using techniques that Meteor introduced?

~~~
sferoze
Currently, I don't think Meteor's main advantage is bringing new capabilities,
but rather providing a platform for building modern web apps.

So it is different than any one javascript framework in that it's goal is to
bring together a complete set of technologies that are needed to build an app,
rather than the developer joining different pieces themselves.

Currently many developers work with separate multiple frameworks, and Meteor
brings them together into a cohesive, power, clean API.

Meteor is amazing, and even with the rough edges, and evolving API, it is
still a joy to work with. They are thinking about the big picture and it
really allows the developer to focus more on the creative aspects of your app.
I am excited to see Meteor evolve over time.

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

~~~
kaoD
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.

~~~
tel
Math and CS are close enough that I think they should be nice neighbors and
respect one another's terminology. I use the mathematical term "isomorphism"
_daily_ almost _hourly_ while programming.

~~~
kaoD
> should [...] respect one another's terminology

I see your point, but IMHO isomorphic is a word, not math terminology. Math
borrows words from regular languages, but it can't expropriate words!

The first thing I think when reading "isomorphic" is "same shape" even though
I know what a math isomorphism is.

Just notice how _function_ means something completely different in programming
and math, but we're so used that nobody nitpicks on HN.

Math permeates everything, borrows and loans words. More examples:

\- Electrical Engineers use finite _ground planes_ even if a plane is by
definition infinite and has no thickness.

\- Music is pretty much math, but their _chords_ are not segments inside
circles.

\- We use _braces_ {} to delimit blocks, not sets.

\- We _flip_ bits in a non-geometrical sense.

\- The DOM has _events_ even though there are no statistics involved.

\- We _compress_ files even though they're not geometric objects.

\- We use _domain_ names.

And so on. It's the beauty of language! Our libraries are full of functions
instead of books. If there's no chance of ambiguity, who cares?

~~~
tel
While this is sort of a silly argument to continue, I'll suggest that
"function" is probably the closest example you've given in terms of how
"isomorphic" is a technical word over a common use word.

And the use of "function" in computer science for things which are hardly at
all functions _is_ a source of massive confusion and pain in the interface
between the two fields. I believe personally that it leads to an enormous
amount of improper education and broken intuition.

Let me provide another example— _variable_. This one is _far_ worse than
"function" in the confusion caused by its poor appropriation into computer
science. The concept of variable is extremely well-designed in mathematics
crafted over hundreds of years of philosophical and mathematical debate... and
then it also become a mutable slot in Algol and stuck to every mathematician's
chagrin.

It's not a good idea to copy technical words and abuse them in similar fields.
It'd be as though people in the airplane industry started calling propellers
"rockets" all over. Rocket comes from Italian "rocchetto" meaning
bobbin/cylinder and so the shape of a propeller engine fits that definition
and words are just words right?

Certainly, but that's just unnecessarily confusing. The person who popularized
that terminology would be rightfully considered a fool.

~~~
kaoD
> While this is sort of a silly argument to continue

So you love silly arguments too! :P

Perhaps our "disagreement" stems from how used we are to _isomorphic_ as a
common word. My mother language is full of greek and latin loanwords/particles
in common speech. If I had to guess it's not as pervasive in yours. Or maybe
you've been exposed to a lot more math than me! Who knows.

I still can't help but read _iso+morph_ separately (as _equal+shape_ ) in
"isomorphic javascript".

New words are not a common occurrence, especially when existing words fit the
concept (such as isomorphic = same shape; variable = its value can vary; etc.)
or parallels can be drawn (function = takes arguments and computes a value;
chord = probably because there is a _circle_ of fifths in music where you can
draw literal chords).

I see how it can be confusing on tech fields though, but that's just how
language works. You could argue there are better alternatives to "isomorphic
JavaScript", but to date it's been the only proposal.

That said, I'll try to keep my linguistic creativity to a minimum in tech ;)

~~~
tel
Yeah... It's Wadler's Law. I accept it.

I think there's a lot of room for creativity in technical fields (étale
morphism comes to mind) but typically once a word has a technical definition
it is made off-limits within relevant fields. Terminological blurriness is
nice sometimes, but often technical terms are incredibly concrete.

To me "isomorphism" means exactly "a pair of arrows, called witnesses, (f, g)
in a category such that fg = id and gf = id" and it confers many properties.
If you find a category where {Server Javascript} and {Client Javascript} are
two objects and exhibit an isomorphism then I will gladly let you call that
object "isomorphic javascript" all day long. Frankly I'm already feeling
"isomorphism" fails to capture the nature of this relationship, though.

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

~~~
rational-future
>> 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.

~~~
untog
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'](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).

~~~
rational-future
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.

~~~
untog
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?

~~~
rational-future
I believe Twitter is trying to kill their API, hence no CORS or JSONP.

~~~
joesb
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.

~~~
rational-future
Well the point is any other API will face the same restrictions in the
browser. It isn't something JavaScript code can fix directly. If you need to
call external services from the browser (and not everybody does), the isobuild
APIs certainly don't make the situation worse.

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.

------
general_failure
The specific http issue is already solved by browserify.

[http://browserify.org/](http://browserify.org/)

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

------
jordanlev
off-topic (but perhaps related to the general usefulness of meteor): I browse
with cookies and localStorage disabled by default. Every time I go to the
meteor site to read something, the page just continually reloads itself
without ever getting anywhere. I understand that some sites require cookies or
localStorage to function (although I think it's nuts that that would be
required for a site that is just displaying content and not an interactive
application), but at the very least put up a message saying that cookies
and/or localStorage must be enabled instead of just making my browser freak
out. Thanks, can't wait to actually read about them without having to open a
different browser :)

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

------
hywel
Why 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.

~~~
avital
From
[https://github.com/meteor/meteor/pull/516#issuecomment-12919...](https://github.com/meteor/meteor/pull/516#issuecomment-12919473):

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

~~~
hywel
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.

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

~~~
richardwhiuk
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?

~~~
astrodust
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.

~~~
richardwhiuk
Simple API is almost always a synonym for feature limited. APIs are often
complicated because they have a lot of power, flexibility or functionality.

------
arbesfeld
If 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...](https://www.youtube.com/watch?v=4dJLPLWMImw&index=11&list=UU3fBiJrFFMhKlsWM46AsAYw)

------
MisterMashable
We can only hope their new package system will contain something that allows
the programmer to chose their own database. I want to use Couchbase and
Elasticsearch. I can't see why any other document store couldn't do the same
job as Mongo. Don't get me wrong, I'm ok with Mongo (but it's not for me) but
can't we make at least some choice???

~~~
imslavko
You can make your choice! The problem for a lot of people: you need to write a
real-time adapter if you want it to be efficient and performant. We have
implemented Redis adapter, for example:
[https://www.youtube.com/watch?v=-Vnb8tjnE3k](https://www.youtube.com/watch?v=-Vnb8tjnE3k)

------
joeyspn
I really don't mind about the packaging system, I think that the meteor team
should put special emphasis in solving the scalability issues, cos right now
(IMO) is the major barrier for adoption.

I find really useful all the features they're launching but there's no way I'm
going to pay for a 8Gb and quadcore server just for supporting 100 concurrent
visitors...

I started building a real-time webapp with meteor and had to switch to express
+ primus which was a _much_ more efficient solution (orders of magnitude).

I really hope they do something about it ASAP... I really enjoyed working with
meteor and still use for small projects, but for a medium/big app? not
_yet_...

------
jimmytidey
Why do Meteor care so much about you starring them on Github?

~~~
aioprisan
It's a good way to drive the point home, by adding that last sentence in every
post. An effective way to spread the word. What's wrong with asking that? For
the past projects that I open sourced, I asked people to star them if they
found them useful.

------
pantalaimon
That website is a prime example for
[https://news.ycombinator.com/item?id=8237996](https://news.ycombinator.com/item?id=8237996)

It's really just text and a few images, nothing fancy, an ordinary blog post -
yet it freezes my browser for what feels like half a minute while it uses 100%
CPU for rendering. What the fuck?!

~~~
sogen
There's a huge .JS file in there, it has the whole site or so it seems. It has
content: * the blog * Other pages like Get involved

