
Meteor hits 1.0 - debergalis
https://www.meteor.com/
======
state
I'm still a bit unclear on what the target market for Meteor is. Is this just
for small to medium sized projects, or is it intended to be used for large-
scale projects as well?

Since it seems like everyone wants to think of themselves as doing something
huge, I'm sure the answer can't be 'no' to the second question — but I don't
see any examples of significant projects being built on the platform.
Actually, with that in mind, what happened to the gallery of projects built on
top of Meteor? Perhaps I'm missing it.

All that being said, congratulations on reaching 1.0. There's clearly a lot of
great energy and thought that went in to the project.

edit: The videos on the site weren't obvious to me at first, but after finding
them I think this one is a good counterpoint:
[https://www.youtube.com/watch?v=QzhtQzAX_6k](https://www.youtube.com/watch?v=QzhtQzAX_6k)

~~~
Everhusk
It's definitely a win for hackathons and getting a MVP out there that needs
real time features. I can't speak much for large scale projects since I
haven't had the fortune of reaching that scale yet with meteor, but I'd
imagine it will be ideal for that eventually simply by extrapolating the
current growth and improvement trends of the framework.

~~~
swartkrans
At last months devshop in SF a speaker discussed straining the system and
reaching the limits of Meteor with just hundreds of simultaneous connections:

[https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s](https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s)

Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or
it could have just been the application that was at fault. It's one data point
however on how meteor scales.

~~~
imslavko
[I work at Meteor and contributed to the MongoDB realtime driver]

Scaling low-latency data synchronization is a challenge for scalability for
sure! We are gradually building better and better drivers with persistence to
MongoDB.

The scalability can vary greatly depending on your application's data schema,
usage patterns and amount of writes.

If you watch the mentioned talk carefully, the speaker describes a
collaboration tool with log replay with a lot of actions and running from a
single box.

~~~
thathonkey
The "running from a single box" at the end seems like it could be the most
important part of the equation. Would you agree? Or rather, would that be the
recommended place to start optimizing if your app runs into scaling problems?

~~~
imslavko
Here is a very fine blog posts series on scaling Meteor horizontally, please
consider looking at it: [https://meteorhacks.com/pro-
meteor/](https://meteorhacks.com/pro-meteor/)

~~~
thathonkey
Interesting, thanks. In that first blog post it mentions that Meteor serves
static files. Is that a requirement?

edit: posted too soon they talk about it here [https://meteorhacks.com/does-
meteor-scale.html](https://meteorhacks.com/does-meteor-scale.html)

~~~
arunoda
And you can use cloudflare or some other CDN very easily. See:
[https://meteorhacks.com/cloudflare-meets-
meteor.html](https://meteorhacks.com/cloudflare-meets-meteor.html)

------
killertypo
Congratulations on 1.0 but these kinds of buzzwordy lines

    
    
        Accomplish in 10 lines what would otherwise take 1000,
        thanks to a reactive programming model that extends all 
        the way from the database to the user's screen.
    

Really bother me.

Show me where you eliminated 1000 lines of code and how it was beneficial.
Each line of code, to me, is placed with purpose and intent.

Are you eliminating thousands of lines of boilerplate? Or are you making best
guess assumptions that fit the common need, and we still end up with those
1000 lines for something truly custom?

~~~
djmashko2
(Disclaimer: I work at Meteor) That box is referring to the data syncing,
event handling, and view rendering code that you don't have to write when you
use Meteor, compared to some of the previous generation frameworks.

If you put together the right list of cutting-edge components like React,
Firebase, Bootstrap, and some build tools, you might get a similar improvement
in code simplicity. Our goal at Meteor is to give you the same benefits
without making you write code to plumb between several different frameworks.

~~~
mrcwinn
I'm doing a rebuild of a personal project over the holidays and I spent some
time looking into binding together React, Airbnb's Rendr, and JSX through
Browserify and Grunt. It's possible, but it's a nightmare. Meteor definitely
succeeds and just delivering that.

(Not that that is the only requirement you might have.)

~~~
pluma
I'm using React. My server-side rendering is essentially
`React.renderComponentToString(App(data))`. The only difference between how I
invoke my app on the server vs on the client is that instead of
`React.renderComponent` I use `React.renderComponentToString`. On the client,
React just uses the pre-rendered HTML and binds itself to that without re-
rendering a single DOM node.

All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to
re-bundle my client, I invoke a script that essentially does `browserify -g
uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the
bundler script are automatically invoked by a watcher.

This[0] is my entire build script and the only reason it's verbose is because
I like to be able to execute each task separately if I want to.

The only problem with React is that it is _only_ a view library. It only does
components. The blessed solution is a Flux-like architecture as implemented by
Fluxxor or Reflux, but you can integrate React into nearly anything you
already have. I like the immutable/unidirectional approach React and Flux
share and ended up writing my own library[1] because there were things I
didn't like about the existing Flux implementations, but you don't have to do
that.

I have to admit that Flux has a steep learning curve. And if you've never
dealt with immutability before it can really melt your brain. But I don't see
how Meteor is any easier to pick up, especially considering that it comes with
its own entirely separate ecosystem (the only non-node library I use in my
React app is an XHR-wrapper that replaces `request` on the client).

[0]:
[https://gist.github.com/pluma/61a1639906e188be8423](https://gist.github.com/pluma/61a1639906e188be8423)

[1]: [https://github.com/foss-haas/flox](https://github.com/foss-haas/flox)

~~~
dmak
I agree with you that it probably is not easy to pick up, but I have to admit,
there is significantly less to deal with. Meteor is the fullstack, and it even
has sockets built into it. You definitely have to buy into one ecosystem, and
that's convenient because you don't have to know a serverside ecosystem (e.g.
Rails) and a frontend ecosystem (e.g. Angular, React, and Ember).

~~~
pluma
Sure, but my current ecosystem is npm. For browser-specific substitutes to
node-specific code I simply use browserify. If I decide React is boring, I can
switch to an entirely different front-end without changing anything else. For
stuff that isn't on npm I have to work with bower or something else, but that
(i.e. ecosystem-external dependencies) is a problem in any application, not
specific to npm.

With Meteor, you're developing Meteor apps. Sure, you can put a different
front-end in it or replace its server-side with an API compatible equivalent,
but that's like saying you can use Django without its template system or ORM
(if you don't know anything about Django: you can, but Django's built-ins
provide a lot of synergy that you can only get from tight coupling).

------
mrcwinn
There's a lot to like about Meteor. Just compare setting up some kind of
"dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY
FRIDAY NIGHT GO.

Meter out of the box "just works," but it only works with Mongo for now, and
it only works if you are all-in with the platform — on both the client and the
server side. Those are two pretty big bets to make.

I would say Meteor is ideal for learning, except that it's important to learn
what the request-response lifecycle is all about, and I think it can be
detrimental when a "magical" framework does so much for you.

And one thing I just can't get over -- page loads in Meteor.com feel super
fast. Until you realize it actually downloaded the contents (not the unseen
images, of course) of the entire website! DPP is doing some interesting
things, but some of Meteor is some nice magic tricks that we've seen before.
600kb+ of JS on page load is certainly an interesting concept.

Huge amount of work by a talented team. A super nice community. As for the
framework itself, give it some time, let it grow, but most importantly,
understand objectively its strengths and risks. It has both!

~~~
pluma
First of all, why is JSX in that list? It's essentially an ES6 transpiler with
syntactic sugar for nested function calls. If you mean the additional build
step it requires, that doesn't really make sense either: you should be
bundling and minifying your client assets already and JSX is just another
(fully transparent) link in the build chain.

Secondly, why Rendr? Rendr was built for Backbone. The most recent info I can
find that suggests using Rendr with React is over a year old. React can be
rendered on the server just fine. The only thing you need to solve outside
React is routing, getting the data and making it available to your React
components. Either use stores or pass all the data as `props`.

Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the
current hotness, not Grunt. And you don't need either of them anyway, there is
so little to configure that you don't even need a full-blown build tool.

I don't have a single line of database code in my React app. All the API calls
are handled by a small wrapper around my database's domain-specific HTTP API.
I could use the same API with zero changes for a native mobile app or a new
web app that doesn't use any of the existing code. My web server is a dumb
proxy for the database API and a pre-rendered for React (the pre-renderer
essentially consists of a single line of JavaScript).

I can understand the appeal of Meteor, but it's not like anything you complain
about has to do with React.

(Now Angular on the other hand... let's hope you don't need any prerendering
ever.)

~~~
dmak
I am still using Grunt, and have been wondering how Gulp is. How do you like
it? Why is it better?

~~~
pluma
I switched from Grunt to Gulp because I never liked Grunt's focus on
configuration over code. But that's entirely a matter of taste. It's not
"better" or "worse" than Grunt, it's just a different approach.

Gulp is pretty neat, until you try to integrate watch tasks. Want to run a
transpiler whenever a file changes? Better don't have any compile-time errors
or your stream will choke and die (without necessarily killing the process,
mind you).

There are some workarounds (e.g. gulp-plumber), but depending on the actual
tool you're trying to use they may not actually work -- or only work
sometimes, which can be just as bad as not working at all.

Personally I've switched from Gulp to just putting scripts in my package.json
file as god (or Isaac) intended. Every tool I want to use has a CLI anyway,
and supports stdin/stdout, so it's all just Unix legos anyway. Except for
browserify, which I replace with watchify in development for performance
reasons (browserify in a large project can take a few seconds, watchify only
updates the diffs).

------
liscovich
I wonder if the criticism that the Flux team at Facebook has directed at two-
way data binding is also applicable to Meteor. Jing Chen is her intro of Flux
([https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G...](https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-GS188xDYE-u1ShQmFFGbrk0v#t=622))
says that two-way data binding creates a major challenge for scaling
applications because views can trigger changes in data, and data changes can
trigger cascading changes in views, which makes it very difficult to predict
the behavior of the app as a whole. Wouldn't Meteor face the same challenges?

In other words, if you believe that the Flux design pattern (which involves a
central dispatcher as the only entity capable of updating the data) is sound,
shouldn't you stay away from Meteor's model when building large applications?
Or am I missing something?

~~~
kfinley
I don't believe Meteor has two-way data binding. You have to update the model
manually using events[0].

0:
[https://docs.meteor.com/#/full/eventmaps](https://docs.meteor.com/#/full/eventmaps)

~~~
imslavko
Two way data-bindings are not a Core feature and they are implemented in
packages. My favorite one is this:
[http://viewmodel.meteor.com/](http://viewmodel.meteor.com/)

------
aliakhtar
I've read somewhere that a use-case of Meteor is to let you write your server-
side logic in javascript, and then run the server-side logic on the client.
Wouldn't that be clearly insecure, to trust the client with running server
logic?

Also, this was accomplished years ago with Google Web Toolkit, which lets you
write both the server & client in Java, and compiles the client-side java to
very efficient, optimized javascript. That has the added advantage of letting
you use a sane, strongly typed language, with all the productivity tools
available for Java, and none of the quirks of javascript.
[http://www.gwtproject.org/overview.html](http://www.gwtproject.org/overview.html)

~~~
swartkrans
If you read the docs you will see it's not implemented in an insecure way. The
core meteor devs are pretty brilliant people, creator of etherpad, svn core
contributer, early asana employee, these people aren't dummies they wouldn't
do something that silly. Such a dumb thing would have been called out way
before 1.0 wouldn't you think? Maybe give it a moment of thought before you
comment.

~~~
d23
> Such a dumb thing would have been called out way before 1.0 wouldn't you
> think? Maybe give it a moment of thought before you comment.

To be fair, I'm pretty sure the previous versions _did_ have this issue -- it
was just supposed to be ultimately fixed. I could be recalling incorrectly
though.

~~~
sbking
It was fixed about two years ago in October of 2012, when they added the
accounts system and allow/deny rules. Since then they've added additional
security features such as the browser policy package.

------
moondowner
Here's the official blog post announcement for Meteor 1.0:
[https://www.meteor.com/blog/2014/10/28/meteor-1-0](https://www.meteor.com/blog/2014/10/28/meteor-1-0)

~~~
ljlolel
And here's a quick way to try it out in a click interactively in the browser:
[https://www.terminal.com/tiny/F4bHKa1XiB](https://www.terminal.com/tiny/F4bHKa1XiB)

~~~
dandv
Or [http://meteorpad.com](http://meteorpad.com) \- the JSFiddle/Plunkr of
Meteor.

~~~
pihentagy
Hehe, not yet supports 1.0 :)

------
hardwaresofton
I haven't looked at Meteor in a while, but am really impressed with how the
vision of Meteor and the code (and of course the website) have evolved.

Meteor looks extremely simple to get up and started with, and I was thoroughly
impressed by the implicit modularity of it all ("meteor create" makes like 3
files, I think that's awesome)

They really try (and succeed) to rid ourselves of the duplication on server
and client. And if the android/ios support is as easy as it looks, this is an
insanely useful framework.

I'm going to use it in my next project for sure now, just need to see how
template/module composition works

~~~
brentjanderson
Phonegap development is still phonegap development, even with Meteor. That
said, I built a prototype chat app and deployed to iOS in about an hour. It
really was that easy, and the app runs terrifically well. The "write once, run
anywhere" mantra is a little more real with Meteor than with other approaches
I've used before.

~~~
hardwaresofton
Thanks for sharing -- that's awesome to hear, yeah, Phonegap definitely has
it's warts, but I like the idea of being able to at least get SOMETHING up so
quick (to match the web interface

------
saym
While I do enjoy the bleeding edge on which we live. I'd love to wait to have
the discussion about the new Meteor features until their site and newsletter
tells us about the release.

Sure the git commit is a landmark, but there's nothing to offer other than
'kudos' with this link as the discussion point.

~~~
dang
saym's comment refers to the original post, which pointed to a GitHub commit:
[https://news.ycombinator.com/item?id=8522106](https://news.ycombinator.com/item?id=8522106).

We merged the stories (in our ghetto way) and moved the comments over here.

~~~
saym
Sneaky! Glad to have a better discussion focus point. Thanks for providing
context to my comment.

------
resca79
When the first release of meteor came out, I was really impressed by the
product. The real time update of the web page with zero code was an amazing
feature. Today why I need of Meter?

Server side I have multiple choices that guarantee me heigh scalability,
performance, and real time. Also the mongodb solo option, without sql is very
restrictive.

Client side, there are great js frameworks like React, Ember and Angular that
are great modular libraries.

~~~
prottmann
I hoped they change meteor and opened it to other databases. The mongodb only
option was the reason for us to stop using meteor.

Most of our customer projects use "old school" sql and only a few nosql-
databases.

Waiting for Version 2 ;-)

~~~
resca79
I'm not really confident about new version the releasing of version 1 was too
long. Also I do not see a strong open community that support them like Rails,
Django o Node. Of course I wish them to grow in terms of contributors

~~~
pluma
There is a pretty distinct and active Meteor community, though from the
outside it's hard to tell how much of that is just people who are interested
in it because of the hype (kinda the problem MongoDB had) vs people who
actually use it and know what they are doing.

I wouldn't say the wait for 1.0 is a good indicator of stability or success,
though. Node.js is still at 0.x and so is React. AngularJS took a long while
to get to 1.x but is now actively working on 2.0.

Many developers are cautious about when they dare calling a product 1.0. Until
the idea that "if your code is in production, it's already 1.0" gained some
ground, there was barely any code on npm that wasn't stuck in pre-1.0 land.

The real indicator is how much time passes between minor or bugfix releases.
Ideally the latter should happen fairly regularly and the former not too
often. If Meteor hits 2.0 anytime soon, that could be a worse sign than if it
sticks with 1.0.x for "too long".

~~~
MrBra
There is this tiny detail about Meteor, that is has been funded $11.2 million.

\- [https://www.meteor.com/blog/2012/07/25/meteors-
new-112-milli...](https://www.meteor.com/blog/2012/07/25/meteors-
new-112-million-development-budget)

\- [http://venturebeat.com/2012/07/25/meteor-
funding/](http://venturebeat.com/2012/07/25/meteor-funding/)

------
perlmonkey
This is about books as learning resources.

For everyone looking to learn Meteor the first 8 chapters of Discover Meteor
are available for free for the next week. It is probably the starting book for
everyone :)
[https://book.discovermeteor.com/starter](https://book.discovermeteor.com/starter)

Also the Manning book Meteor in Action is 50% off the next week with the code
jiafinal50 The book is in heavy development with updates every couple of
weeks. However it is still not finished and lacks some advanced chapters
still.
[http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509](http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509)

Apress also has a book called Beginning Meteor but it has almost no relevant
content as of yet and no updates in the last months.
[http://www.apress.com/9781430268369](http://www.apress.com/9781430268369)

All Packt titles are hopelessly outdated for version 1.0, so you better stay
away from them.

~~~
dturnbull
Also, as a shameless plug, beginning web developers are quite fond of my book
about Meteor:

[http://meteortips.com/book](http://meteortips.com/book)

It'll be a couple of days before a (completely) revised version is released
for 1.0 though.

(Reviews can be found on Amazon:
[http://www.amazon.com/dp/B00MA8KVAY](http://www.amazon.com/dp/B00MA8KVAY))

------
dia80
Thank you Meteor team - you have done fantastic work, what an achievement.
I've had a blast building my meteor hobby site [1]

[1] [http://quantpapers.com](http://quantpapers.com)

------
sferoze
This is really awesome, I just checked out the new website and docs.
Everything is so much more clear, I love the new docs. Stuff is laid out
really well, people new to Meteor are gonna really like this.

------
wasd
Hey Meteor Folks, [https://www.meteor.com/main](https://www.meteor.com/main)
says Preview 0.9.4. First place I went after I checked the git repo.

~~~
imslavko
The release 1.0 is pushed to git but there is still work to do: docs, web-
site, announcements, etc.

It is not done yet :)

------
decidertm
Great job, Meteor has really helped me develop my programming skills as a
beginner. It allows me to get instant feedback on the code I write. To see a
real world prototype keeps me going!

------
donutdan4114
How does one start a project like this and get paid? What are the revenue
sources for the team? It's a great product, and the fact that it's open source
is amazing.

~~~
cjbarber
Step number one:

Create an awesome framework that people want to use (Meteor started out as a
travel guide site, I believe, and other YC batchmates wanted to use their web
framework)

Step number two:

Keep building the web framework

Step number three:

Raise money to keep building that framework, with a partner who believes for
the long term

Step number four:

Keep being awesome, and become the tool that a ton of devs want to use

Step number five:

Monetize with your own enterprise support and hosting

~~~
polarix
"I think you should be more explicit here in step 3"

[http://i.imgur.com/uvulagb.jpg](http://i.imgur.com/uvulagb.jpg)

------
dfischer
I absolutely love Meteor. I've been evangelizing it a lot this year. I wish
someone at Meteor would reply to my emails. _wink_ ;) me@danielfischer.com

~~~
dandv
I applied too, they were in a hiring freeze before 1.0 :-)

------
ajhit406
Meteor is already easy to setup, but for those of you on Windows or who want a
clean sandbox to develop meteor apps, we launched a custom Meteor template on
Nitrous today. We also increased the free resources:

[http://blog.nitrous.io/2014/10/28/meteor-template-on-
nitrous...](http://blog.nitrous.io/2014/10/28/meteor-template-on-nitrous-
io.html)

------
logicalman
How did Meteor get to 1.0 when node.js is still at 0.10? I congratulate the
Meteor team, but can anyone confirm it is actually stable?

~~~
akbar501
Meteor hit 1.0 b/c their APIs are stable. I'd also guess that the software has
hit a level of maturity where the Meteor team is comfortable with a supported
release.

As for Node, there are some within the Node community who would like to bump
it to 1.0 as it is clearly production ready. In Node's case, .1 vs. 1. is a
just a numbering scheme issue, not a production ready issue.

------
roshanj
Congratulations to the Meteor Development Group! I've been using Meteor for 16
months now and it's amazing how much it has changed/improved. It is a great
tool to learn for any beginner web developer.

Also check out a catalog of the best Meteor learning resources at
[http://MeteorHelp.com](http://MeteorHelp.com)

------
lukb
UI & API in one go?

I just went through the tutorial on meteor.com, and I'm impressed with the
speed of getting results.

When I were to build another online app, I'd split that in building the
frontend and the API composed from microservices, so that I'd be able to offer
access through the UI _and_ the web API. Is Meteor a good choice for this
approach?

~~~
dandv
You can create REST points from Meteor collection very easily -
[http://www.meteorpedia.com/read/REST_API](http://www.meteorpedia.com/read/REST_API)

------
bkruse
First of all - absolutely love meteor. Couchbase/CouchDB support would be
fantastic! More (NoSQL) database support would be fantastic. I worry that it's
so MongoDB specific now and the "scale" technologies are MongoDB specific
(Oplog tailing only) that adding other databases in the future will become a
lot more difficult.

~~~
thinkcontext
Check out [http://hood.ie/](http://hood.ie/) its CouchDB based and has some
similar concepts to Meteor

------
GordyMD
I am excited to give Meteor a go and take advantage of its isomorphic nature.

I am particularly excited by the potential of being able to swap out Mongo for
RethinkDB ([https://github.com/tuhinc/rethink-
livedata](https://github.com/tuhinc/rethink-livedata)).

~~~
mrcwinn
That project has been abandoned, it seems, and wouldn't work with 1.0.

------
sarciszewski
[https://www.meteor.com/install](https://www.meteor.com/install)

curl [https://install.meteor.com/](https://install.meteor.com/) | sh

This despicable habit rears its ugly head again.

~~~
sooheon
Just curious. What is wrong with this?

~~~
anonfunction
[http://blog.existentialize.com/dont-pipe-to-your-
shell.html](http://blog.existentialize.com/dont-pipe-to-your-shell.html)

------
callesgg
Nice i love meteor, i hope that there will be some work on a sql backend.

I want defined database strucures ;)

~~~
uptownJimmy
Absolutely necessary, I agree.

------
taternuts
Congrats to the team - maybe it's just me, but it seems like you guys to to
1.0 pretty quickly

edit: random aside, I literally just saw the transition from the preview
website to the 1.0 website as it was hotswapped in, and I have to say it looks
_much_ nicer!

------
sferoze
Wow that was fast, I can't believe Meteor is already at 1.0! This is really
exciting times, so much progress has been made with Meteor. Ill upgrade my
meteor app as soon as the official release is out.

------
tomcam
Kudos, Meteor team! Now, SQL, please...

~~~
swartkrans
You can have SQL already, use ddp methods to query a database on the backend.
It's not reactive, but it enables you to use SQL.

~~~
1qaz2wsx3edc
The data isn't reactively loaded in realtime, but Meteor itself is still
reactive. What I mean to point out is that even if you're depending on say
classic JSON APIs, the meteor app within itself can still do reactive-features
(templates, local collections, etc). And depending how you implement things,
you could still take advantage of push capabilities for your data from a
legacy endpoint.

But yes, I agree, it's not ideal until a SQL adapter is available.

------
landland
Meteor is awesome, congrats to the Meteor team for their 1.0 release! I've
been using Meteor for over a year now, and it is staggering how far it has
come. They've addressed and continue to address just about any concerns the
community has brought up, from security to speed to tools, etc. And where they
haven't, the community has stepped up huge. Seriously, Meteor is amazing, but
what makes it even better is the awesome community surrounding it. Congrats
again.

------
findjashua
seems like their selling point is data binding + client syncing. Considering I
can do that with Ractive/React + Firebase, what's the advantage of using
Meteor?

~~~
rco8786
You can ask it either way.

seems like their selling point is data binding + client syncing. Considering I
can do that with Meteor, what's the advantage of using Ractive/React +
Firebase?

~~~
findjashua
For starters:

1\. You can reuse your existing API, or choose the stack you're comfortable
with (I prefer Python to Javascript and Postgres to Mongo)

2\. They are being used in production by high traffic websites (Guardian and
Instagram respectively), so they're more battle tested

3\. Their press releases aren't loaded with buzzwords and hyperbole

~~~
sbking
The reasons I prefer Meteor (in no particular order):

* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.

* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...

* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.

* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.

~~~
anonfunction
Great overview of the benefits!

------
1qaz2wsx3edc
Not official but here is the a change log:
[https://github.com/meteor/meteor/blob/fb7466078ec5da90321bdc...](https://github.com/meteor/meteor/blob/fb7466078ec5da90321bdca3f08ddf085775e947/History.md#v10)

It's a bit light on details. I wouldn't say Meteor is 1.0 yet, but preparing
for it. Also Worldwide Meteor day is Nov 6th, I anticipate a more formal
announcement then.

------
jeswin
The importance of JavaScript as a Platform is not abt billions of browsers
running JS, but abt how each one of them is also a JS IDE. If we could click
the fork button, and start editing, testing and deploying right away, all
within the browser, we'd probably get programmers to contribute to open source
web apps in a way never seen before.

A sea change in how web software gets built and consumed, in the same way
Britannica yielded (had to) to Wikipedia.

------
Everhusk
Amazing :D Great work, and hats off to the meteor team! I just finished a
hackathon this weekend with a meteor app, and absolutely loved the framework.

------
richardofyork
For an unbiased overview of Meteor, including what it offers and how it
differs from typical JavaScript frameworks (like Angular.js and Backbone.js)
and ecosystems (like Mean.js and Yeoman), read this article:
[http://javascriptissexy.com/learn-meteor-js-
properly/](http://javascriptissexy.com/learn-meteor-js-properly/)

------
emmanueloga_
When I saw a link to an "Atmosphere" page I was curious what did meteor had to
do with the Atmosphere project [1], a "real Time Client Server Framework for
the JVM, supporting WebSockets and Cross-Browser Fallbacks Support". The
answer: nothing.

1: [https://github.com/Atmosphere](https://github.com/Atmosphere)

------
rdtsc
Trying to figure out how it works. And saw this in one of the paragraphs:

> No longer do you need to provision server resources, or deploy API endpoints
> in the cloud, or manage a database

So you don't manage a database, but what happens to the data.

Can anyone trace an example, I don't, order or cart update from client code to
persisting it on the back-end somehow? Does it use flat files...?

~~~
aroman
It uses a database, specifically MongoDB. But as I understand it, Meteor
manages this for you itself, and abstracts the orchestration of those things
into the Meteor platform itself.

It's just a higher level of abstraction, not a new technology. And certainly
not flat files.

~~~
rdtsc
MongoDB? I think to be accepted and taken more seriously they'd have to at
least have an option for something else.

~~~
sarciszewski
I say PostgreSQL. Not only can it do everything MongoDB can do (and faster*
too), it's time-tested technology.

* [http://blogs.enterprisedb.com/2014/09/24/postgres-outperform...](http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-ushers-in-new-developer-reality/)

------
xs
Hi meteor.com team. I've scanned the home page and even looked at some other
links on the site. I still don't know what this does. Is it a javascript
library? Or template maker? A project packager? I have a lot to do and very
little time. Can you make a quick video that describes why I should use Meteor
and what it does for me? Thanks!

~~~
TylerE
Basically, yes to all.

In terms of scope it's roughly as encompassing as something like Rails - it's
full stack.

~~~
xs
Ah thanks. But if Rails is my coding platform of choice how does this
integrate into it?

~~~
pepr
It doesn't, this is a separate coding platform. If your coding platform is
Rails, you don't integrate Django into it.

------
swartkrans
I used my meteor developer account to get the free discover meteor book (via
the limited time 1.0 promotion I guess), but I thought I did something wrong,
tried again and ended up with two copies/purchases. It was free, but seems
like a bug. Maybe detect if someone already got a book?

~~~
sgdesign
We fixed that. Thanks for pointing it out!

------
dasmithii
At this point, what percentage of web development can't/shouldn't be done with
Meteor? It seems like everything else is obsolete in comparison. The only non-
Meteor cases I can think of involve especially large scale.

~~~
chm
Because Meteor hides much of what's really going on, it's sometimes hard to
understand just how the app is working. At least that was my impression of it
when I tried it about 9 months ago.

Choosing a stack on your own means more time is spent making things work, but
then you know how it works. That's why I went for a MEAN stack instead of
Meteor. But I'm going to try Meteor again soon!

~~~
emgee3
While Meteor does do a lot for you out of the box, it doesn't really prevent
you from seeing what's going on. There are some good resources for seeing what
Meteor is doing behind the scenes (meteorhacks.com and eventedmind.com) if one
does want to dig in.

------
akhatri_aus
Congrats to the Meteor team on 1.0! We're building our app
[http://servicelocale.com](http://servicelocale.com) on it for high quality
services & crafts in Australia.

~~~
staticelf
Looks great but the site doesn't feel very snappy.

~~~
djm_
I haven't found a Meteor site that does yet, I would love to see an example of
one where I don't have to sit at a loading wheel. Anyone?

~~~
dandv
[http://meteor.com](http://meteor.com) is very snappy. So are sites using
fast-render, see [https://meteorhacks.com/fast-
render/](https://meteorhacks.com/fast-render/)

------
andreasklinger
i am super excited to see the launch

quick feedback: this scares me off a bit:

200 open issues / 150 stale branches / 42 open pull requests

might be normal for open source projects of that size though

~~~
johnjwang
On the contrary, I think that is a good sign. It means there is an active
community that is opening and contributing to issues. If you check out Rails'
repo ([https://github.com/rails/rails](https://github.com/rails/rails)) you'll
see the same thing. If you've ever been an open source maintainer, you'll know
that you'll inevitably write bugs and so you'll always have open issues. The
scary thing would be if no one filed any issues or had any pull requests.

~~~
andreasklinger
good point

cycle times might be better indications

------
nathan-muir
Congrats to the Meteor team!

We've built an enterprise/b2b app on meteor, and even through all of the hard
yards, it's been a success & the right choice for us.

When I first heard about meteor, back at v0.5 or v0.6 - I watched the video
from their home page, and thought it was full of buzzword bullshit. I didn't
have a clue what it did.

I then ended up reading about how their latency-compensation API system worked
[Meteor Methods]; And instantly knew that it was for me.

Having an API that simulates itself on the client, while simultaneously
performing the same work on the server, is freaking awesome. (And then rolls
back automatically if they don't agree).

 __If you are building a real-time, collaborative tool. Meteor is the
framework. __

That being said, there are a few questions about integration & scalability.

Opportunities to use Meteor:

* If you can make something small, eg. an internal tool [Free mobile app with cordova!]

* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)

* You're a sadist, and you're going to port your whole app to meteor...

* You're writing an MVP and you're going to scrap it later

* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].

Scalability:

* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.

* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.

* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.

* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].

All in all. Meteor is great at what it does; and what it does, is going to be
the next generation of web apps.

~~~
notastartup
> * You're product has realtime/ collaborative elements that are a SELLING
> feature [not just for your personal enjoyment].

What opportunities exist in the enterprise market that specifically benefits
from this feature?

~~~
dandv
I'm working on Google's Governance, Risk and Compliance management system.[1]
Porting it to Meteor would accomplish several goals:

* clean and much simpler code base

* automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux

* ease of onboarding new developers in the team given the simplicity and ease of learning of Meteor

[1]: [https://github.com/reciprocity/ggrc-
core](https://github.com/reciprocity/ggrc-core)

~~~
notastartup
I worked with Meteor.js on an enterprise app a year ago but it seems to be
more mature now. I think this is a great time to begin porting it.

------
frequentflyeru
Just started using Meteor + Telescope on my site TravelMo.re and love it so
far. Really easy to use, kind of a pain in the butt to deploy.

~~~
thathonkey
Could you elaborate on why it is a pain to deploy? I've never used Meteor but
I thought one of the selling points is ease of deploy, hot code pushes, stuff
like that.

~~~
cjbarber
[Not the op] Meteor is extremely easy to deploy.

Disclaimer: I think Meteor is fantastic.

Never really had an issue - I can't say the same about rails! Obviously Meteor
has the advantage of being younger and so less cruft has built up, but I'd bet
on it still being insanely easy to deploy 4 years from now.

The Meteor team is doing an awesome job spending the VC money on making an
experience that is fantastic for devs. Major props to Geoff et al.

~~~
brentjanderson
Deployment depends on where you want to run it. Builds into tarballs that can
be deployed pretty directly onto EC2 or other hosting services. It does
require a VPS or equivalent system (LAMP hosts won't run Meteor). I understand
Heroku can be a little more complicated as well. That said, Meteor's self-
hosting option is pretty good for getting started, and Amazon instances run it
very well.

Also +1 on the Major Props to the Meteor team. They are a model team.

------
coffeemug
Congrats to the team! This is a very serious engineering achievement. I'd
imagine it wasn't nearly as easy as they made it look.

------
nojvek
Congrats Meteor! but I really find it loading a bazillion javascript files a
bit of an overkill. Also debugging is a pain in the butt.

~~~
sbking
In production in bundles and minifies all JS and HTML into one file that is
sent to the client. Then all further communication happens with JSON over
WebSockets/SockJS. If changes are made to the JS/HTML, the server will send
down a new application bundle and hot-reload the app without interrupting the
user if you are storing the user's app state in the Session.

The CSS is also bundled in production. When further changes are made to the
CSS, the new stylesheet is live-injected into the running apps without
reloading the browser.

------
AndyKelley
I see this in example code:

    
    
        if (Meteor.isClient) {
    

I don't get it. Are we shipping server side code to the client?

~~~
arbesfeld
Not unless you want to. Anything in a `server/` or `private/` directory is not
sent to the client. This pattern is sometimes used to group similar functions
in a single file.

Relevant section of the docs:
[https://docs.meteor.com/#/basic/filestructure](https://docs.meteor.com/#/basic/filestructure)

------
dsyko
Congratulations to everyone on the Meteor team on 1.0! I feel this is just the
beginning of many great things to come!

------
coldcode
What is the status of supporting Redis. I'd be more excited if I could use my
favorite instead of Mongo.

~~~
imslavko
I and another Core Dev Justin SB worked on the Redis support for a month:
[https://atmospherejs.com/slava/redis-
livedata](https://atmospherejs.com/slava/redis-livedata)

It has seamless support for hashes and strings, miniredis, latency
compensation, user input validations - similar features to MongoDB
integration.

Right now you need to start the Redis server and set up the KV observations
manually once for every Redis server you intend to use.

This support was experimental and we didn't develop it further from there. We
told our community about it on a Meteor Devshop but there wasn't much
interest. If there will be more interest, we will continue developing it.

------
maxharris
Congratulations and thanks, Meteor team!

------
general_failure
What is meteor's revenue model?

What am I missing...

~~~
dandv
Galaxy, an enterprise-grade, multi-tenant hosting environment for Meteor apps
- [https://www.meteor.com/blog/2012/07/25/meteors-
new-112-milli...](https://www.meteor.com/blog/2012/07/25/meteors-
new-112-million-development-budget)

~~~
KhalPanda
For a second there I was like "Woah! $112M?". Damn friendly-URL's.

------
niix
Yay! Congrats to the Meteor team!

------
jakelin
Well done, Meteor team. My project based on Meteor is going to finished this
Friday.

------
adam_h
Thank you Meteor team. I really enjoy working on my web app that I made with
Meteor.

------
desireco42
Congrats Meteor, great times!

------
ambhaiji
The inevitable will come soon News headline: Google buys meteor

------
freefrancisco
Congrats Meteor team!

------
j_k_s
Congratulations, and great pun for the title. :)

------
ForFreedom
Are there any similar applications like meteor?

~~~
tarcon
I think [http://derbyjs.com](http://derbyjs.com) can be seen as a competing
framework.

------
Lauricio
Congratulations!!

------
waitingkuo
Awesome, really excited to the 1.0!!!

------
rglover
Awesome! Really excited for this.

------
arunoda
congrats guys :) Very excited to be a part of the community.

------
thewhiteox
Grats Meteor!

------
ofcapl_
congrats to meteor team!

------
notastartup
So last time I used this was back in August 2013.

The main concerns we had was scalability and reliability.

How does 1.0 address the previous concerns that was enough to abandon
meteor.js altogether?

~~~
dandv
See this previous reply:
[https://news.ycombinator.com/item?id=8522918](https://news.ycombinator.com/item?id=8522918)

------
char_pointer
FYI: this link gets me into a redirect loop (probably because of something
NoScript related)

~~~
q3k
Don't expect to see meteor-based sites work with JS disabled.

Not a huge fan of this turn of events, either...

------
zura
If only this was built in Dart... or at least TypeScript.

~~~
treehau5
I am grateful that it was built in neither.

