
Show HN: Meteor, a realtime JavaScript framework - geoffschmidt
http://www.meteor.com
======
micheljansen
My first impression of this: wow. If Meteor is all it appears to be, this is
nothing short of revolutionary.

My second reaction: what happens when the magic ends? When I was new to Rails,
I really loved how easy it was to get started with scaffolding, a nice DSL for
specifying relations, nifty form helpers. However, the first time I veered a
little off the golden path and wanted to do something a little more
complicated (that was not supported by the form helpers at that time), I ran
into a huge wall. I found out that I actually had no idea how Rails worked.
The magic had hidden all complexity from me before, and now the magic failed
me and I didn't know where to start doing it on my own. Rails has matured a
lot since then (it also dropped some of the magic in favor of more explicit
behavior) and my understanding of the framework has grown with it.

Meteor looks even more magic to me. There is so much stuff happening. What if
I plan to do a lot of dynamic updates and I want to defer live-updating
because I am doing mass-updates? What if I need a hard division between
client/server code? What if I want to share the backend with an iOS app or
something? Can I use this to build an API? The documentation does not yet
fully answer these questions for me.

~~~
mmobile
Like the reference to Rails—so easy and at the same time so inaccessible.

In the earlier days without powerful frameworks I was really developing:
figuring out which pattern/algorithm did the best job. Nowadays when working
with frameworks I feel dumber and dumber—before thinking myself I just google
API calls and put them together. I am not trying anymore because I don't know
where to start and everything is already solved on Github. This magic feels
sometimes so meta and boring because I am more into consuming specs,
tutorials, screencasts just gluing things together instead of real
programming.

Just diving into JS and Node.JS to get this "go-kart" feeling back. But I
guess the more magic involved the faster the development and Meteor admittedly
looks revolutionary.

~~~
10098
It's like the industrial revolution. Long ago, things (like furniture) used to
be made by craftsmen. They had to choose the materials, they had to get a
picture of what the final product should look like. They used to work by hand,
using only simple tools. It was hard. To become a skilled craftsman you had to
be an apprentice for several years and learn a lot from your master.

Then came factories. Factories were super-effective, they produced a lot of
things fast, and cheap too, and the level of skill required from a factory
worker was in no way comparable to the skill of a proper craftsman.

I notice the same tendency in software development today - we, the software
developers, are more similar to factory workers mindlessly sticking together
parts than "ninjas" or "rockstars". Of course, the process of software
development today is not entirely like a factory, but I sense it's moving
towards there. And if it is, programmers will become something cheap and
fungible. Imagine hiring illegal immigrants to write an iPhone app :)

~~~
maigret
You're only seeing a part of the development task. Yes, the knowledge
requirements for doing a task X (let's say a given CRUD app) are declining.
But:

\- How do you guarantee that all those pieces you just glued together will
work with high availability? That they'll feel easy to use and consistent if
exposed to the end user, or easy to maintain (future developers) and operate?
Quite some work is often needed to have all that.

\- User expectations are getting higher. You could get away with a certain
quality and usability of software in 2005 that you couldn't today. Had a
desktop software in 2000? In 2006 it was a desktop software and a website, now
it is a web app, an iphone app, an android app...

\- What you are describing is putting together a solution. Might make sense in
many end user scenarios, web apps, etc. For things like automotive and other,
low level programming is still needed - though abstraction is also slowly
making its way in there also.

------
geoffschmidt
Hey everyone! The four of us have been working very hard on this for the last
six months, and we're excited to finally take the wraps off. Can't wait to
hear what you think!

We've got a lot more stuff coming over the next few months, and if there are
particular things you'd like us to do/prioritize, I'd love to hear about them!

~~~
AdleyEskridge
This looks fantastic. I genuinely got giddy watching the screencast!

If I were to use Meteor for a partially closed source app earning around $1000
per month, how much could I expect to pay you? From the FAQ:

> If the GPL doesn't work for your project, get in touch (contact@meteor.com)
> and we will write you a commercial license to your specifications.

~~~
zavulon
I love everything about Meteor so far, except for this.

This is no way to answer such an important question that most potential users
will have - let's face it, there's a lot of people who will want to use this
for open source, but a lot more who will want to use this for commercial apps.
To ensure Meteor's wide-spread acceptance, you need to clearly answer this
question on FAQ page, and not with "we need to have a conversation".

~~~
dspillett
A great many things are sold this way, and it is sometimes unavoidable.
Commercial projects tend to have a wide range of requirements from a licensing
point of view so if they spent time drawing up a full commercial license they
would end up having to rearrange half or more of it for the first commercial
client that came along anyway. They could spend time drawing up many license
templates (world wide, X,000 users, X server, ...) and pricing plans with many
combinations of support and development agreements to try cover the bases -
_or_ they could spend more time coding.

Their preference is that the library be used under the GPL. That is their
choice and it is a fair enough choice. But they also acknowledge that some
entities can't accept that for one reason or another, and are willing to be
flexible. Very flexible: instead of saying "this is our commercial license,
deal with it" they have said "tell us what you need, and we'll see what we can
do".

~~~
zavulon
Fair enough - if that's their choice, that's totally understandable. But my
point is - if they wish to make it a wide-spread popular platform for web
development, this is not the way to go about it. An MIT license like Rails
would be a much better choice.

------
luigi
This feels to me a lot like how Rails felt back in 2005. A fundamental leap
forward and an understanding of where web technology is going.

I haven't felt that way about Node.js or even its higher-level frameworks like
Express or Batman. This feels like "The One", even though I've been absorbing
the docs and screencasts only for the last 20 minutes.

~~~
kgosser
Completely agree. I thought Backbone was the "missing piece", but this really
is it.

Edit: to clarify I specifically meant a front-end tool to help me leap a level
in personal development skill.

~~~
cfontes
I am sorry but there is no way to compare backbone with this one( but it looks
very nice, too ), they aim at different things.

I am using backbone for a while and it's backend agnostic which is great !

This one have more resemblance to knockout.js( I am talking client side) and
it's MVVM design, backbone doesn't even try to approach that problem.

~~~
kgosser
Very true. I wasn't very explicit that I didn't mean they were the same thing,
apples to apples. I meant "missing piece" in terms of the front-end tool to
help me leap a level.

------
erikpukinskis
I'm surprised no one is talking about the glaring hole, which is security.
It's apparently on the developers' short list of high priority features
([http://stackoverflow.com/questions/10100813/data-
validation-...](http://stackoverflow.com/questions/10100813/data-validation-
and-security-in-meteor)) but it doesn't seem like a trivial addition.

With client-side DB access, and eventual consistency baked into the platform
as a core feature, you can't just throw _"if current_user == object.owner"_ in
your controller and call it a day. I'd love to know what they're thinking
here.

Certainly you could go with a row-level security scheme like CouchDB has,
where you attach little javascript snippets to your database that check
security. But then how does the client verify? Maybe you can just assume that
only malicious users will ever bump into security problems and so client-side
verification is unnecessary.

If auth is baked into the framework, then maybe they can give you basic row-
level security for free by maintaining a user table with auth tokens that's
only accessible on the server side, and passing the auth token along with
every database request, and maintaining a meteor-controlled owner key on
objects. But that doesn't help if your security checks are more involved.
I.e.: _"if object.owner.friends.includes?(current_user)"_.

I'd love to hear what they're planning for this.

~~~
romaniv
That's a common problem with a lot of web frameworks. Every single one of them
claims to make "web development" easier. They promote themselves by showing
how well they solve some narrowly-defined and often imaginary problem (in this
case - client-side updates), but completely side-step all the typical issues
that _really_ make web development difficult: user and group management,
caching, validation, authentication, permission handling, stuff that prevents
XSS, CSRF and injection attacks, version upgrades, dependency management and
so on.

Anything can be made to look easy if you're ignoring real-life issues. Heck,
you can do seamless client updates by refreshing all the pages on my website
every second. It will be inefficient, but it is easily doable.

~~~
ofrasergreen
I think you take for granted some features commonly provided by modern web
frameworks addressing what used to make web development difficult. For
example, in the pre-Rails era, building just a simple CRUD website used to be
difficult.

For arguments sake, if we say there are 20 "real-life issues" then all web
frameworks tend to address up to 12. New frameworks are created to address
some of the issues of the past frameworks but with regressions in other areas.

Recently, I've been using Lift which happens to be very strong on most of the
points you named, yet in retrospect, I don't feel it made web development
easier overall because it has other deficiencies.

------
rabidsnail
"You can use the database api on the client!"

Does that freak anyone else out? Where are they doing permissions checking?
Who can run what database commands under what circumstances?

~~~
dbuxton
From the docs (<http://docs.meteor.com/#meteor_collection>):

"Currently the client is given full write access to the collection. They can
execute arbitrary Mongo update commands. Once we build authentication, you
will be able to limit the client's direct access to insert, update, and
remove. We are also considering validators and other ORM-like functionality."

So just for toys for the moment. Still, very cool...

~~~
famousactress
Right. But as soon as you have this ability, don't you quickly turn off
insert/update? then you throttle/contain reads... So in the end, do we benefit
from having a client side database connection? I'm struggling to put together
a real-world use case for one that isn't irresponsible.

~~~
dgreensp
On the "read" side of things, you control what data is exposed to each
subscription, and you'll be able to base access on authentication. The client
doesn't get a direct database connection, but rather a live-updating subset
(or arbitrary function, in the general case) of the database.

The rationale is that clients typically end up doing sorting and filtering on
subsets of the database anyway, as they get more sophisticated and start
caching data. For example, Gmail starts to need a notion of an email message
on the client, to avoid going back to the server for the same message. When I
worked on Google Wave I saw firsthand the complicated plumbing you need in
order to do this in an ad hoc way. (They used GWT to share the model objects,
but synchronized the data manually.)

You can also separate this facility from your database completely, and use it
as a way of sending "data feeds" to clients; then use methods as RPCs.

~~~
alttab
This still doesn't sound like a straight forward answer. I think there is a
justifiable cause for trying to minimize the role of the server but
controlling the operating environment of the data itself is the essence of
modern web security.

There would need to be some sort of public key system for authentication, but
in the end you are still compromising your data if the client gets hacked.
There would have to be a database control layer for the final say, and thats
called a server.

~~~
disbelief
Not sure if Mongo has this feature, but in many classic SQL databases, per-
user views can be created which act like tables, but are actually "the user's
view into that table".

This would mean creating database user accounts on the fly for people, but it
would resolve this problem (as long as the views are secure).

------
chime
Just watched the entire demo. First time I heard two people present a product
together - definitely makes it a lot more interesting and much less
monotonous. After the first 30seconds, I went "pfft, live reload isn't new."
But I'm glad I stayed till the very end because it is indeed so much more. It
looks very promising, especially if you offer app hosting of some kind (or
make it easy on Heroku etc.)

I am curious about the security aspect of writing to DB directly via the
client but I'm sure you've thought of it. I love the 'add less', 'add
coffeescript' feature. Can't wait to try this out soon.

~~~
geoffschmidt
Thanks for the feedback about the beginning of the demo. We had a really tough
time with the site and the video because the people who are interested in
frameworks like Meteor come from a lot of different backgrounds. Some people
have written half a dozen Backbone applications and have written their own
highly scalable node.js cache invalidation servers, while other people have
suggested that we take the word "REST" off the homepage because it's confusing
to new developers.

It's tough to find a pace that holds the attention of the experienced people
while not losing the people that are new to web development.

~~~
loceng
Don't shy away from opportunity to teach. Just make sure you show it as a
link, perhaps that means a simple popover explaining in simple terms what REST
means.

------
jonny_eh
I predict we'll see "Looking for Meteor.js developers, minimum 5 years
experience" ads in the next 6 months.

~~~
mathiasrw
Would love it :)

------
equark
Is GPL really viable for a web framework? The Free Software Foundation has
consistently held that linking to GPL code (not LGPL) is derived work.

~~~
chc
I think Meteor actually has the opposite problem: Running a web app is not
generally considered to be distribution, so as long as you aren't actually
giving the source code to anybody else, the requirements of the GPL don't
apply to you. (IANAL, but this is my understanding.)

~~~
kragen
Meteor runs on the client, not the server. If the server sends the code to the
client so that the client can run it, the code is being distributed to the
client. Better make sure that you have a link to the un-minified version of
your site's JS if you minify it and use Meteor, and of course don't try to
restrict your users from studying, copying, modifying, and redistributing your
site's JS.

------
enobrev
Very cool implementation, and fantastic site and video!

I grabbed the source to see what it would take to write a mysql plugin. As far
as I can tell, it's fairly well tied into mongodb[1]. It seems this would
benefit a great deal if the minimongo package[2] had some sort of interface to
build to for custom data sources.

I would love to add mysql-livedata, and a mini-sql of sorts. Or maybe even a
simple mini-orm with basic insert / update / delete / select methods and a
more advanced "WHERE" syntax (SQL cousin to minimongo's selector magic).
Obviously the real magic is in the livedata synchronization.

Regardless, this is very impressive. Thanks for putting this together!

1: As far as I can tell, the server won't even run without Mongo, at least
according to this in server.js: `throw new Error("MONGO_URL must be set in
environment")`

2: An incredibly cool browser-based implementation of the mongodb query api

~~~
geoffschmidt
Yeah, there still a few places where Mongo is hardcoded (the prototype assumed
Mongo everywhere, and we've gradually factored out these assumptions.) Most of
these places have to do with the code that automatically starts mongod for you
when you type 'meteor' to run your app in development mode. I think all of the
database assumptions have been factored out of livedata, but we'll only know
for sure once we have a second database packaged :)

And yes a second time: to package a sql database, you would ideally have a
'minisql', a client-side cache with a sql-compatible interface. It's not
strictly necessary though. There's no reason a DDP[1] dataset couldn't use a
different database API on the client and the server (say, sql on the server,
mongo on the client), but if you did this and you wanted latency compensation,
you'd have to write all of your methods twice, once against each API.

I am really excited about having sql support, but we tried really hard to
defer anything that wasn't absolutely necessary for release :)

[1] DDP is the protocol that livedata speaks between the client and the
server. In Meteor, the client and the server mostly keep themselves at arm's
length. The client doesn't know that the server is made with Meteor, just that
it speaks DDP, and vice versa.

------
bryanh
Big props on stellar presentation. The code is impressive, but even better is
their slick install, deploy, docs, screencast and examples.

This looks big. If nothing else, hopefully others will notice the code to
support materials ratio. Its just as relevant for straight OS as much as it is
for "businesses around GPL".

~~~
munaf
Agreed. What struck me most was how much care they put into the presentation
of the framework, docs, and videos.

I'm really happy to see so many developers taking UX seriously, even if it's
just for other developers. Quite a nice trend I'm seeing with
libraries/frameworks these days.

------
CWIZO
Note that the name "Meteor" is already used: <http://meteorserver.org/> it's a
comet server, so there might be some confusion here (I thought that this was
the next version of meteor I linked to, at first).

Other then that: "holy shit" was the first thing that popped into my head
after watching 2 minutes of the video. Excellent work guys!

------
silverlight
This is very neat. I've been using Backbone + ShareJS[1] to do a lot of
similar things for a current app I'm building. This is certainly nicer,
though, with concepts like latency correction and support for keeping the
user's changes in place whenever a template updates by only updating the
specific elements that change (very cool).

A couple of questions for you:

1) What's the current and projected goal in terms of concurrency for the
server? Is this going to be able to handle thousands of simultaneous
connections? Is the Node server built on anything else like Socket.IO, or is
it fully new and unique code?

2) How does this handle conflicts? ShareJS implements Operational
Transformation[2] to attempt to smartly handle conflicting writes from
multiple clients (used in Google Wave, for example). Does this just do a
simple timestamp-based overwrite? If so, how far down the tree? I'm not
familiar with MongoDB (sorry), but would it be at the object level? Or the
property level?

[1] <http://sharejs.org> [2]
<http://en.wikipedia.org/wiki/Operational_transformation>

~~~
guscost
It looks like David Greenspan (the guy who created EtherPad and then got hired
by Google to work on Wave) is on the team so it's probably safe to assume that
OT is a feature.

~~~
silverlight
A very good point :-). Just wanted to know what their "official" word is,
since I didn't read about it in the docs...

EDIT: I see that they mention OT on the people page:
<http://www.meteor.com/about/people>, so excuse my ignorance about the people
behind the work...

~~~
guscost
Well you got me to read the whole Wiki page, that counts for something. And
it's a feature to be pretty excited about!

------
gsharma
I got very excited after watching that video. Meteor does a great job at
hitting a lot of things a new web framework requires. However, I then viewed
the source on meteor.com. It includes just a javascript and everything else is
in that Javascript file.

Are all the apps going to be like this or just how they roll? Putting the HTML
markup in a Javascript file not just breaks crawlers[1] (they are not indexed
by Google) but also (I guess) not accessible to all sorts of users/browsers.

[1]:
[https://developers.facebook.com/tools/debug/og/echo?q=http%3...](https://developers.facebook.com/tools/debug/og/echo?q=http%3A%2F%2Fmeteor.com%2F)

~~~
geoffschmidt
Meteor developer here -- we think it's super important to be able to serve
static HTML when the situation calls for it (eg, crawlers.) Our architecture
is designed to do this but we haven't had a chance to implement it yet. We
have a lot of incentive to get to it soon, because it's no fun to be left out
of Google :)

There's a bit more in the FAQ. Our approach is based on rendering the template
as a string (it doesn't require building a DOM tree on the server and then
serializing it.)

<http://meteor.com/faq/can-meteor-serve-static-html>

~~~
gsharma
Good to see that you are aware of this and working towards it. I'll keep an
eye out for it, won't be able to use Meteor before that.

------
Geee
Would it be possible to set it up so that the initial page load is completely
static html served from cache? The page would then be updated when it changes,
i.e pushed to client and new cache.

There's lots of overhead on both server and client side generating everything
dynamically, especially on slow mobile clients. Testing it on fast machine on
localhost creates visible delay in initial DOM update. On typical
content/read-heavy pages it would make sense to always serve static pages as a
fast as possible and update cache and client-DOMs on database write.

~~~
davej
I agree, I want to call the Meteor framework revolutionary, but this is the
one thing that's stopping me. Unfortunately, it's only suitable for web
applications (i.e. _not_ content sites) because Google can't index it and
permalinks wont work in browsers that don't support push state (IE 9 and below
don't support push state).

In my opinion, this is the missing feature to make Meteor revolutionary in the
process of web development.

------
swah
So many projects these days, I wish they had simple metadata like Stackparts
projects:

    
    
        meteor
         - Is a: webframework
         - Depends on: node.js
         - Comparable to: backbone.js knockout.js rails django
         - Connects: ....

------
sleight42
I had two knee jerk reactions. The first has been discussed already (client
side DB access). The second has not.

Does Meteor have any opinions on testing? I didn't see anything from a quick
glance at the docs.

I love the idea of tighter development cycles. But as a Meteor app grow in
size and complexity, won't it still need a test suite to prevent regressions?

Eager to hear thoughts on this from the Meteor devs.

~~~
amirhhz
That puzzled me, too, I started browsing the code and noticed there's not a
lot of testing of the project code itself:
<https://github.com/meteor/meteor/tree/master/tests>

So I agree, it would be good to hear from the devs about their opinions and
thoughts on testing. (Is there a chance that they think the "realtime-by-
default" approach lessens the need for testing?)

I'm no testing zealot, but I've found writing tests useful and it would be a
shame to be frustrated by that missing piece in an otherwise great project.

~~~
debergalis
We've actually written a lot of testing for the core framework packages --
those tests are in each package directory. Look for *_test.js files.

<https://github.com/meteor/meteor/tree/master/packages/>

You're 100% right though. We don't have a fully baked story yet for
application level testing. It's something we're trying to push forward as soon
as we can.

~~~
edwinnathaniel
From product adoption perspective, you guys are going to win a lot more users
if you can support the following scenario:

1) unit-tests

2) integration-tests

3) provide at least guidance/best-practices on client-side testing in the
_headless_ scenario (no complex setup of remote machines with 3-4 browsers
installed etc)

People may have their opinions about testing UI/client-side (is it end-to-end?
is it worth? not testing using the browser no-go?, etc) but the fact that
Meteor is leaning toward more code in the client-side will definitely put
testing in almost make-or-break decision for a group of developers.

GWT with their MVP approach is definitely heading toward that direction and it
is quite unfortunate that the client-side JS community out there haven't
picked up that style (some brushed GWT off because it is Java).

Rails won the heart of many Java developers not only because of its simplicity
but also because of automated testing.

So, show how easy it is to test the whole Meteor app and I (almost) guarantee
you will get many more developers (especially those who skipped the Rails
boat).

~~~
sleight42
Or even those of us (like myself) who are currently on the Rails boat!

------
tete
Looks interesting, but..

    
    
      $ curl install.meteor.com | sh
      Unable to install. Meteor supports RedHat and Debian.
      Installation failed.
    

However the slow start description in their README works fine. Maybe this
should be mentioned in the message above?

<https://github.com/meteor/meteor/blob/master/README.md>

Looks like an interesting approach. I always thought SocketStream would be the
next big thing, but now I am uncertain. Nice that there are a number of
frameworks though! :)

<http://www.socketstream.org/tour>

Oh, a CoffeeScript would be nice.

~~~
kodablah
I still think SocketStream is the next big thing. The 0.3 release is moving
along well and I have had fantastic success with it. The features touted by
Meteor seem to already exist in SocketStream (template choice, server/client
push/pull, DB choice) besides the "no server code part". It also works very
well on Windows of course.

~~~
zenocon
I've been building a SocketStream app for a couple weeks now, and this was my
thought too -- plus it has other, important stuff done (e.g.
authentication/authorization is working/sync'd up between http and sockets).

Meteor has some nice packaging and deploy stuff and the hosting is nice, but
that to me is a nice-to-have.

------
dclowd9901
Thanks for the trouble you guys have caused me. I'm gonna have to hose-whip my
co-founder to keep this out of our project until it's mature enough.

------
beggi
This looks extremely interesting, and reminds me a bit of Lunascript
(<http://asana.com/luna/>). I'm very interested in who is paying for the
development? I notice that there's no big tech company behind this and from
the contact page I can see Meteor Development Group has an office in downtown
San Francisco. So do you have any info on what the plan is regarding
monetization?

~~~
geoffschmidt
Well, I am one of the Meteor devs, and I used to work at Asana :) Luna is an
astonishing codebase, and Meteor is a small fraction of it in sophistication
and functionality. But we think there's room for a lighter weight framework
for the masses.

Monetization: We're still figuring that out. For now, we just want to see what
people do with it. We think a lot about companies like redhat and mysql, and
how they have been successful while building open ecosystems.

------
hbrundage
Congrats to the Meteor team: it looks amazing.

Questions:

\- What's browser support like?

\- Do you do synchronous AJAX to return results synchronously for DB
operations on the client? It looked like newly created records' IDs were
returned as soon as the creation code was executed.

\- How do you track a reactive function's dependencies?

\- Do you plan to make a run loop similar to Ender's to stage and order
various recalculations and DOM updates?

------
tlrobinson
Neat. Sounds a bit like Asana's Luna: <http://asana.com/luna/>

~~~
beggi
I thought so too, one of the founders was an employee of Asana.

~~~
tlrobinson
Well that explains it. Also, David Greenspan from AppJet/Etherpad.

------
delano
This is a very uncool way to install something:

    
    
        $ curl install.meteor.com | /bin/sh

~~~
geoffschmidt
I am to blame for that. Here is our thinking on it:

\- Though it "feels wrong" (definitely with you there), is it really any
different from downloading an installer package and running it?

\- You can just go to install.meteor.com in your browser if you want to see
what the script does (or just leave off the | sh), which is arguably better
than other installation mechanisms.

Curious to hear people's thoughts :)

~~~
moe
I'm chiming in here because it may still be early enough to stop you.

Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER.

Your universe is ~/.meteor. Do not even think about touching anything outside
that. It's taboo.

You clearly know what you're doing otherwise, so please get this one right
from the start and save yourselves a lot of headache later on (cf. npm).

Install to ~/.meteor and provide the user with a small snippet to paste to
their ~/.bash_profile ("source ~/.meteor/magic.sh").

~~~
mhansen
It would be more helpful for people reading this comment if you gave reasons
beyond "It's taboo".

I'm sure you have good reasons, I just can't see them here.

~~~
moe
Portability, robustness, flexibility and security. There's little reason to
spread out a package like meteor all over /usr/local. But _many_ reasons
against doing that.

To illustrate, a few simple questions:

What if I need multiple meteor versions on the same system (different versions
for different users/projects)?

How do I quickly switch between different meteor versions (often needed in
fast-moving projects like this)?

How do I monkey-patch meteor to try something out and/or contribute back?

What if I absolutely _must_ mix meteor with an unsupported version of node or
other runtime dependency?

What if all my servers are SuSE Solaris95 but you only provide packages for
Debian and RedHat?

How do I bundle my meteor runtime with my deployment?

~~~
geoffschmidt
I agree with all of this :) Meteor is self-contained and installing it in
/usr/local is totally optional. The reason we install into /usr/local is that
it is a way to get the 'meteor' command into the user's path without trying to
edit their dotfiles for them, and without setting obscure system preferences
that the user would have trouble unsetting. We went to a lot of trouble to
make it easy to try Meteor, and we thought that "great, now go edit your
dotfiles" would have lost a lot of people.

If you don't want it in /usr/local, you can check it out anywhere you like and
just run the 'meteor' in the top directory of the checkout, and it'll work
great. This is mentioned in the README/on Github, and it's how we have been
developing Meteor. You can have as many copies of Meteor on your system as you
like, and they can even coexist with a copy at /usr/local. So for me, I type
'~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself
to run the latest official release.

You can either build the binary dependencies (node, etc) yourself by running
an included script, or if you do not, the first time you run meteor it will
automatically fetch a prebuilt binary kit for your convenience. All of the
binary dependencies are kept in a directory in the checkout and managed by
meteor, meaning that each meteor install on your system can have its own
version of node.

Finally, to your last point, 'meteor bundle' does exactly that :P In fact,
right now on our deploy servers, we have live apps running that were deployed
with a variety of historical versions of meteor, all coexisting side by side.

I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger
and more complicated -- when all of the packages do not fit in a 'packages'
directory, and when there are more binary dependencies than node and mongo.
But I hope that this helps to persuade you that we're not totally nuts,
despite how sleep deprived I was when we recorded that screencast.

If you thought this was a helpful answer, could you repost the question on
Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my
HN profile?) That way I could repost this answer there in case it might be
helpful to other people.

~~~
moe
Thanks for the exhaustive response.

I agree with almost everything you say; you seem to have it right then, I just
didn't go through github so I never saw the README.

However, I would still argue that you should get rid of the packages, that's
extra-work you could better spend elsewhere. For someone installing a dev-
toolkit it's absolutely not too much asked to paste "echo >>~/.bash_profile
'source ~/.meteor/magic.sh'".

They have to do that anyway as soon as they need the latest git-HEAD because
of some bug in the release version (we know how it goes, don't we? ;-)).

So by giving them the right instructions right away you save them this extra
step. And you save yourself from making a bad (and false!) first impression on
the older and grumpier devs like myself.

------
xxpor
One comment on the screencast, isn't encouraging people to do

    
    
        curl $URI | sh
    

a really bad idea?

~~~
beaumartinez
No. You can have the same confidence it's legit as when you download an
installer and run that. The bonus here is that you can load _$URI_ and read
the source before you even run it.

~~~
xxpor
Right, I guess I was just thinking of the opposite direction.

Usually I download something, look at it (more to see how it works, not
security, but I digress) and then sh it.

------
jaredsohn
Interesting (and smart) that they post to Hacker News a couple of days prior
to the launch of Firebase (which provided the realtime functionality used by
MMO Asteroids and has been active at hackathons.)

~~~
jamest
(Co-founder of Firebase here)

We know the Meteor guys well and are really excited about what they're
building. It's very complementary.

We're both advocating a new paradigm in software development and the faster it
comes the better.

------
polychrome
Great work!

I have to ask, I know that Mongo is all the rage these days, but how quickly
could you add MySQL support? I can already see several uses for this, but I
need to tie into legacy systems.

In terms of security (say a dashboard), could you just disable the system from
being able to modify the DB and just read it?

------
zenocon
Looks nice. There are a handful of similar frameworks out there (e.g now.js
<http://nowjs.com/>, socketstream
<https://github.com/socketstream/socketstream>)...the trend seems to be toward
heavy use of sockets in webapps.

I'm developing with socketstream right now, and I love it. I hope they are all
successful.

~~~
juliennakache
Love SocketStream too. I'll be exploring Meteor to see the differences :)

------
ph0rque
Somehow, I feel that these guys are a YC company, but don't want to reveal it
yet.

~~~
tstyle
That would explain Garry Tan's photo and endorsement on the front page : )

------
vishl
What are the client-side performance implications? I am worried about running
this on mobile clients (mobile web or within phonegap). Three things in
particular:

1\. Running complex DB queries on the client

2\. The in-memory database cache described in the documentation using a lot of
memory

3\. Having little control over how often the client hits the server and vice
versa.

------
treetrouble
This is the first use of server-side js that has made a lick of sense to me as
anything other than an experiment.

I think in terms of security and flexibility the API may wind up being a lot
more complex than it is now. Maturity aside, clearly an excellent idea and
work so far...

------
benrahn
For a not-full-time developer like me (I've picked up bits and pieces here and
there) Meteor might just blow the doors open on what's within reach of my
prototyping abilities.

(Full disclosure: I'm friends with most of the Meteor crew, very excited to
see the wrapping come off!)

------
javert
Can't people find an alternative to the world "realtime" that hasn't already
been used for _30 years_ to mean something _entirely_ different? (As in, real-
time systems, real-time operating systems, etc.)

I'm not trying to put down Meteor, I imagine it's great.

~~~
dreamdu5t
Agreed. I prefer the term "auto-synchronizing" rather than "real-time."

------
ericingram
One question: How did you get a hold of Meteor.com?

------
tent1
At first face it looks a genius idea, but the more I think about it the less
convinced I am about it all.

It seems as though it has combined automatic polling and asynchronous updating
together, and has removed traditional controllers and models. Yeah, it's cool
out of the box and yeah, it's great for scaffolding and rapid development.

But really, it seems like another stack to learn and completely depend upon,
and with codebase that 'liquid' it seems like it's much riskier than doing
things traditionally. I'd be worried that it auto-injects into the running
app.

Don't get me wrong — it's amazing. But what's the real, actual benefit here?

------
alexro
I'm at risk of sounding offensive, but I don't mean it. I just want to point
out that to me many recent accomplishments in the realm of web frameworks
sound similar to how Microsoft was making noise back in the day with their
frameworks.

The MS frameworks were great in themselves, they even cooperated somewhat. But
they ultimately lacked in the ability to support long-term development, you
know, when people just drop out of the project and you suddenly need to bring
someone in ASAP.

Keeping this in mind will allow the new generation of "web guys" do better
than us, the "desktop guys".

------
chrisherring
What's the roadmap for supporting windows?

I tried to install meteor using cygwin and hit "Sorry, this OS is not
supported yet.".

~~~
chrisherring
[http://stackoverflow.com/questions/10108840/meteor-and-
windo...](http://stackoverflow.com/questions/10108840/meteor-and-windows)

------
gridspy
I really like the look of Meteor. We're currently building the next version of
our dashboards for Gridspy (<http://www.gridspy.co.nz/>). It would rock to
have a solid real-time library at the core.

For us it needs to support our live data feeds, inter-operate nicely with our
PostgreSQL db (via our own API?) and if possible take advantage of our
existing django application.

Our rendered dashboards need to be seamless and fast. I've been leaning
towards highly cached static data to ensure this.

------
joshontheweb
Very cool, this feels like the natural evolution of the realtime web. I am
fearful that there could be too much 'magic' though. Have to play with it
before I pass judgement.

------
kilowatt
Cool stuff! Really like the template handler that "notices" which attributes
you're interested in and registers listeners for you. Is that implemented with
a proxy "this?" or with actual Javascript parsing? _gulp_

Any reason the GitHub link isn't above the fold? That's the first thing I
looked for...

I'd also be curious to know if any of the live reloading stuff was inspired by
Brett Victor's "Inventing on Principle?" Something about tools that let you
create "live" seems to be in the air.

------
keeptrying
Does it scale to really heavy javascript pages? Do you have any benchmarks on
when it starts to breakdown in terms of performance?

Also have you built a "solid" production app with it?

~~~
mathiasrw
<http://www.meteor.com/faq/meteor-is-a-early-preview>

------
davidcann
Is there a built-in way to execute different code on the server, such as
proprietary business logic, custom authentication, non-cross-domain APIs, etc?

~~~
geoffschmidt
Certainly! Take a look at Meteor.methods. That lets you define a method that
the client can call without necessarily having the source. (If you give the
client the source it will be able to do predictive latency compensation. But
you don't have to. Or you can give the client a "stub" implementation that
just inserts some placeholder records, while the server goes off and moves the
forklifts around your warehouse over CORBA, or whatever.)

~~~
fruchtose
Just to hear it explicitly, does this library allow the client to call a
server-side function without the end user ever seeing the source of the
server-side function? That's my biggest concern, especially with the emphasis
in the video on, "The client can access the DB!"

------
flav0ur
Great. I'm sure realtime web frameworks will be the future of node.js and the
entiry web itself. However, I do have some concerns. Opening my Databse via
the web? Neeh, this is one thing not clear in the video.

P.S.: You should provide your cli via npm. Go and register the name before
someone else do. (It's not taken currently <http://search.npmjs.org/#/meteor>)

------
zach
Anyone want to speculate on the difficulty level of integrating Meteor with
Cappuccino?

That combination seems like it could be spectacular, if it's at all possible.

------
pirateking
I love Coffeescript and Backbone, but was on the fence about trying to build a
Javascript only app using Node.js on the server. This looks a bit more
interesting to me as it seems like a truly modern web framework, that may
actually make web development fun again.

Freaking love the name too (admittedly a non-trivial factor to me when
deciding whether to investigate new technologies).

------
chrismealy
"In Meteor, your server code runs in a single thread per request, not in the
asynchronous callback style typical of Node."

So node's not a cancer now?

~~~
bbayer
+1, what about performance? Does this mean all server will be blocked while
doing IO?

~~~
alexmic
No, it says one thread per request, not single-threaded.

~~~
bbayer
sorry. missed that one. Again, I believe multi-threading is not best approach
in terms of scalability. Asynchronous io is the secret sauce of node and it
distinguishes node from other server side technologies. I think, asynchronous
nature doesn't suite well to meteor's approach. I will be appreciated to learn
real reason.

------
md224
Wasn't there a Backend-as-a-Service platform released recently for use with
Backbone.js? Does anyone remember what that was? Seems like we're seeing a new
wave of "front-end only" application frameworks coming out...

EDIT: oh yeah, Backlift! (<http://www.backlift.com>) This is definitely an
interesting trend.

------
atleta
The demo video looks nice, but to me it stinks. Maybe I wasn't listening
carefully enough, but exposing the database to client code...? Almost a decade
ago, back the time when we were writing Java apps, there were some debates
around if you should write fat clients (business logic in clients) or not on a
local java email list. I happened to throw in the counter argument that you
shouldn't give direct access to your db to anyone, but your own code. (Which
means you have to use an API, because you can't control what's happening on a
client.) Then some DBA guy said that you have to set up the DB access rights
anyway and that should be enough. But of course, if you don't use stored
procedures, you can't do it fine grained enough. And these were SQL databases
(!). We know how that story ended.

But what I see here, is retrying what already have failed, only know the DB is
even less protected. Doesn't seem very wise to me.

------
defeated
The live demo is here: <http://colors.meteor.com/>

Seems to have a minor glitch with unicode characters? When you do
Colors.remove() everything goes away, but the entries with unicode all come
back? Somewhat strange...

Interesting tech, but db access from the client scares me to no end, call me a
curmudgeon I guess.

~~~
shashashasha
Performance on that url also seems to be super slow right now with a lot of
people hitting it. Curious to see how Meteor handles loads, it's really
exciting stuff.

~~~
defeated
I _think_ that someone might've gotten clever and done something like, while
(true) { Colors.insert(...); }

On a related note, they took it down now.

------
keeptrying
A big part of the problem is building the community. Ie the right license and
creating a core group that's more than just the employees of one company.

The tech looks great but I think the community is key for this to be adopted
rather than anything else.

Rails nailed the community aspect and that's a big reason to its success.

------
cslarson
This looks like it has some similarities to Derby (<http://derbyjs.com/>) and
SocketStream (<http://socketstream.org/>). Will be interesting to see with
authentication and permission handling.

------
erichocean
Pairing Meteor with Blossom[1] would basically close the loop on writing high-
performance mobile HTML5 apps.

(Blossom recently went full native on mobile -- the platform runtimes are no
longer needed.)

[1] <https://github.com/fohr/blossom>

~~~
hbrundage
Can you expand on this? To me it seems like Meteor accomplishes the same thing
as Blossom, on the web platform at least, except that it does HTML /templating
instead of rendering to a canvas. I bet it would be hard to reconcile the two
different frameworks ideas of what Observable or Subscriber/Subscription looks
like as well.

~~~
erichocean
AFAICT, Meteor solves a different problem: eliminating the server-side of
writing a JavaScript single-page application.

The auto-updating template stuff is cute, but unless your goal is apps that
max out around the complexity of a todo list, there's a ton of performance
pitfalls (c.f. Ember.js), especially in mobile browsers. A lot of apps _are_
that simple though, so I don't want to knock Meteor (or Ember) here -- that's
a useful niche to be in and anything that makes development faster/easier is
great!

A Blossom app would simply use the server capabilities and data updating stuff
in Meteor, but in the context of a normal, high-performance Blossom-based
mobile UI with statecharts, hardware-accelerated surfaces and animation, and
yes, GPU-accelerated Canvas rendering (although Blossom now supports old-style
HTML/CSS views as well).

Mobile apps written with Blossom have virtually the same amount of resource
control as a native iOS app, and to my knowledge, is the only mobile app
framework with 100% JavaScript controls that can say that. (Appcelerator's
Titanium is the other way to go – wrap the native controls with a JavaScript
API.) Not to mention the ability to run on Android and iOS browsers from the
same code base, or deploy via PhoneGap, or target desktop browsers or tablets
with effectively native performance.

Meteor is really neat, I did something similar to at least the data syncing
part two years with a tech I developed called HubSync, which kept a SproutCore
datastore in sync across clients. The net effect was the same -- no server
code, data stays in sync automatically, and you only ever dealt with the
client API. (It could do a few other things, like still function offline, and
was also shared nothing on the server side with Cassandra or BigTable -- I've
seen serious problems with Mongo scaling in the past (yay, global lock!), and
I have no idea what the offline story is for Meteor.)

But still, very cool tech overall, and the team looks like they've got some
great ideas. Bravo!

------
devs1010
Weird how this just came out a day ago as I've been starting to learn node and
I was just trying to figure out a way to blend backbone with node so that I
could re-use models server-side. I saw this yesterday on the front page but
didn't pay much attention to it and then today I remembered seeing it and came
back to it and it looks like it solves the issue I had been trying to figure
out myself. All the examples, etc I could find on combing backbone and node
seemed half-baked and I couldn't find an easy to follow example for a
beginner, its as if this came to the surface just in time.. I am definitely
going to give it a try

------
spasquali
This is just the client code necessary to run a todo app:
[https://github.com/meteor/meteor/tree/master/examples/todos/...](https://github.com/meteor/meteor/tree/master/examples/todos/client)

Seems rather fat. Fatter than what I've seen for Knockout, or Ember, or even
Backbone.

As I suspected this idea of just dropping any package and bang it works
depends on that package having been made available by the Meteor team, and the
requisite wrapper/bindings made around the original package. Which means now
using Meteor means you must use _their_ package, which even with best
intentions, means their team will have to keep up to date with every package
you'd like to use, every new version, the bugs, etc.

What if my data comes from multiple sources ("the cloud" and "big data" and
"3.0" means your apps don't all share the same persistence layer, and likely
use several)

What if I push 1000 records of data to the client, in the html for efficiency
and network reasons, to power my fancy D3 chloropleth, and the client
interface allows manipulation of that (local) data. How do I take advantage of
Meteor's data binding system? This is something almost every serious
application does -- updating a local data structure and propagating that
change to several views.

Overhead of having all these sockets open? If I want to change 20 items and
then update my view, do I now have to write the boilerplate to store up 20
changes, then package, then send in one shot down the Meteor pipe? Do I make
20 calls via client DB bindings? Probably the former. Which means I end up
doing a lot of work that I wouldn't have if I had a local model with CRUD
methods (like Ember, Backbone, etc).

Latency compensation. Sounds great. So I say "pay my bill" and my interface
updates with an optimistic confirmation. Great! Now I can drive my kid to the
soccer game. Hope I notice that the number got switched back (server fail).
How will I notice? Hope the developer implemented a noticeable notification
system...

Security? Anyone with a browser can change my DB? How do you secure that? Log
in? Now logged-in people can change my DB from their browser? Whitepaper is
necessary, so this aspect can be tested.

Great team. Good ideas. But it is quite early yet.

~~~
spasquali
Meteor packages: <https://github.com/meteor/meteor/tree/master/packages>

The comments here are telling:
[https://github.com/meteor/meteor/blob/master/packages/handle...](https://github.com/meteor/meteor/blob/master/packages/handlebars/package.js)

------
yan
Geoff & Co, this is wonderful!

(Not sure if you remember, but I met you in SF at one point a few years ago
and we wandered around the downtown talking for a little bit. Was actually
just wondering what you were up to)

------
jameswyse
This is.. Awesome!

I've been using node.js for a while and I think I've tried all of the
different frameworks, none of them seemed quite right.. I eventually settled
on using express and building on top of it with modules and my own code.

When I installed the leaderboard example I expected a big directory with a
million files.. my jaw dropped when I saw the whole app was 3 files! And
app.js was tiny!

This looks like the node framework we've all been waiting for.

I really can't wait until this is more polished so I can actually use it for
live apps. Great job guys, bravo!

------
iamjpg
I keep picturing HackerNews being rewritten with Meteor so I can watch up-
votes in realtime.

Seriously though, Meteor looks incredible and I can't wait to mess around with
it! Awesome work.

------
eliaskg
First of all, the project is great! I think many of us have always dreamed of
developing for the web in this way.

I also think they have to try to solve the "API Problem" at some point. Mobile
apps are native and they will remain native for some time. Nobody wants to
implement a web app with Meteor and re-write an API in a traditional manner.

But nevertheless this is a very interesting piece of work and I am thrilled to
hear about updates!

------
jalada
The whole Meteor website just refreshed for me while I was watching the
screencast. Did they just push something? ;)

Edit: And now it's down. Thundering herd?

------
it
This looks similar to another project being worked on by a friend of mine:
<http://objectfabric.com>. A couple of big differences are that ObjectFabric
is implemented in Java, and it is supposed to support secure authentication.

Edit: Looking a bit more, I noticed that ObjectFabric doesn't yet support
JavaScript directly, only through GWT.

------
darylteo
Hi Geoff,

something I've been wondering: how can Meteor help prevent race conditions?
For example, if there is a lengthy piece of text (say a blog post) being
edited by > 1 person. Can Meteor simply lock a resource and prevent edits on
client-side or is this something that needs further tweaking by the developer?
Or will it somehow have Google Docs style collaborative editing?

Regards, daryl

------
mkmcdonald
So, has anyone actually read the code?

I'd guess that these guys have spent a maximum of one month writing
JavaScript. It's a giant mess.

All flash, no substance.

~~~
Raynos
Agreed, the codebase is a mess.

The ideas are nice, the implementation is absolutely horrible.

------
troels
Very impressive and an inevitable evolution, I guess. Although I must say that
this is exactly what Stallman is warning us about.

Javascript applications are fine as long as they are used as intended by the
programmer, but they do not have the interoperability of a html+http
application. Fundamentally, this is reducing the browser to a thin client.

------
desireco42
Pretty awesome. I like discussion so far, a lot of good points made, however
no-one didn't mention now.js, and this kind of is mostly similar to now.js and
magic it does.

It definitely has a potential to bring huge changes. I love how packages are
bundled. Other things as well. I will try it out with coffeescript.

Congratulations guys, this is pretty awesome.

------
follower
It would be helpful if the phrase "simple DDP protocol" on the home page
linked to a description of said protocol. :)

------
kelvin0
I think this is a great idea, however I still am still adamant to use
Javascript. The framework is a great step in the right direction, and is quite
an evolution from something like Google Gears.

I would love to use this framework if it was implemented as Google's NaCL,
running 'native' code instead of Javascript.

------
mcgwiz
I wonder how much money they burned to get that domain name. Overall, this
seems to be a production that feels much glossier and slicker than other
technology "debuts". Is this the new way to launch a technology? Razzle and
dazzle the programmer into the latest cargo cult... :/

------
cfontes
Do you plan to charge for it at some point? because for me it's not clear.

Is there a business model or just releasing it for people to use in their
business and if improved contribute back ?

Because I cannot see anyone adopting it without those questions answered.

Anyway, nice thing you guys have build... keep it going !

------
sbarre
Just watching the screencast and reading through the API for an hour or so is
giving me real ideas for practical projects that I would never have tried
before because of the sheer amount of "plumbing" required, but Meteor provides
it already.

------
mcmire
I'll have to think of a use for this, but this definitely seems really
interesting. I think working to make building web apps easier and faster is an
awesome mission, so mad props to you guys, looking forward to see where this
project goes.

------
villagefool
Trying to read your docs and examples to figure what is in the framework
(Leaderboard is a Meteor object?) and how it works. An image showing the
sequence/flow of data between client/server/framework/and user code, would of
helped a lot.

------
AhtiK
Being licensed as GPL2 (
<https://github.com/meteor/meteor/blob/master/LICENSE.txt> ) isn't this a risk
when using it for any commercial purpose?

------
speg
Looks cool! How will it fair if I try to make a mobile app via PhoneGap or
similar?

------
neebz
woha. this looks like what I build using Nowjs and Knockoutjs.
(<https://github.com/neebz/Real-Time-Notice-Board>) plus mongodb access. Great
stuff.

------
grayrest
Lots of smart design choices. I have equivalent bits and pieces scattered all
over the place that I've been meaning to put together to get the "wow" that
this package delivers. Kudos for actually making it happen.

------
netopolit
Correct me if I'm wrong but Meteor seem similar to Derby (derbyjs.com). Don't
have any experience with either yet but Derby's MIT license seems more
appealing than Meteor's GPL / commercial license.

------
tlear
This feels like something big or perhaps something that will inspire something
big. But you could probably avoid the database query straight in the client a
distraction from an awesome presentation.

------
level09
Brilliant idea, I believe that HTML5 local storage will never work and perform
well. these guys brought mongoose APIs to the client, this will bring along
unlimited potential and possibilities.

------
goldmab
Shouldn't this page be more clear about the fact that this completely insecure
and not currently suitable for any public website, due to the unlimited
database rights?

------
norviller
Why choose Mongo as the default Data store? Redis anyone?

------
wicknicks
Wow! This is amazing. Though not entirely new, I love the idea of syncing
database content with web content. They seem to have gotten it right!

------
reilly3000
I would love to see somebody build HN or reddit on Meteor - I bet the social
dynamic would be different. I don't know how, but it would be...

------
rdl
Congratulations -- I'd talked to you guys about what you were working on, but
it looks like it's much more awesome than I thought.

------
aba_sababa
I would love have all my node packages available to me...in the meantime, HTTP
requests from the server would be much appreciated

------
robomartin
Why does one have to point to origin.meteor.com to host on a custom domain?

Does using "meteor bundle" also require pointing to origin.meteor.com?

------
melpomene
How is security handled here when it seems like the client can write freely to
the database? Are there any restrictions?

~~~
usamec
there are no restrictions so far :)

------
iamleppert
How are they delivering a result back from those async mongo function calls
right away on the client? Anyone know??

------
charlieok
Is there a blog with an RSS and/or Atom feed? That's how I generally try to
stay in the loop on these things...

------
firefoxman1
The live code update without the server restarting is really intriguing. What
package is responsible for that?

------
joshmlewis
Why do none of the linked demos work? :/

~~~
Leftium
The demo links are randomly generated. The links are preceded by instructions
to set up your own demos at these unique sub-domains.

------
nikic
Consider my mind blown. This is awesome.

------
avelis
I know the install script is fairly easy but will this support installs via
the homebrew package manager?

------
Metapony
Ha! I was watching the example just now, and got a sudden grey screen http
error -- "No data received"

------
j0hnlucas
Going through the examples now. This is blowing my mind. Excellent job guys!!!

------
antihero
How do you handle authentication and authorization in real-world apps?

------
erjjones
If this is what it says it is ... then it will rival Rails for sure.

------
angelohuang
Could someone explain how it could work with Firebase?

------
mikecaron
Can't wait to deploy my first meteor app on Heroku!

------
yakko
why is <http://http://colors.meteor.com/> timing out?

------
buster
reads like socketstream

------
fascinated
#fuckyeah geoff!

------
nicklovescode
Very impressed

------
jcarden
Interesting. I may be in love.

------
GutenYe
It remembers me of emberjs

------
flexterra
Looks like the future

------
atjoslin
This is awesome :D

------
daraosn
I loved this project, nice job... just wondering, what if I want to protect my
DB so people cannot change it through the browser console as shown in the
video? (also this example <http://colors.meteor.com/>)

------
hk_kh
I have typed a (lame) version of the installer compatible with archlinux
(through dpkg)
[https://raw.github.com/gist/2360250/a5d101386590a17fed026c7b...](https://raw.github.com/gist/2360250/a5d101386590a17fed026c7b07725d53f296dbde/install-
meteor.sh)

EDIT: didn't see <https://aur.archlinux.org/packages.php?ID=24167> ...

------
Jebus
GPL?! I don't even..

------
DancingWolf
It was a few years since I was "in" with the new things happening in the web-
world.

But how did JavaScript come to be the new "cool" language? It got some
horrible problems with object oriented stuff, some really strange
bugs/features, and it's slow-ish.

I liked making cool stuff with JavaScript, but compared to something like ruby
isn't this a step backwards?

I can see the advantages of this framework, but it still seems wonky.

~~~
cwsaylor
Grab a copy of "Javascript: The Good Parts". It's a short read and goes over
the parts of JS that don't suck.

~~~
kika
And then try coffeescript which just isolates you from the parts which do suck
:-)

