

Show HN: We're writing a book about Meteor - tmeasday
http://themeteorbook.com

======
niftylettuce
have you guys picked a platform yet for writing the book? using LaTeX? this
looks like something that <http://pen.fm> might be useful for, especially
since the founder of that is into node as well, might be doing meteor stuff
too actually :)

e.g. [http://www.pen.fm/read/Returning-as-an-Engineer-
PN1368383b7c...](http://www.pen.fm/read/Returning-as-an-Engineer-
PN1368383b7cd66bfc)

~~~
sgdesign
What does Pen.fm do?

And we haven't really decided on this yet, I don't think we'll need to use
LaTeX but we'll see. Any suggestions are welcome :)

~~~
kanatzidis
If you do end up deciding to use LaTeX, please consider <http://SpanDeX.io>!
Not sure when you intend to start writing but in the next month we plan to
push out some really robust reviewing/editing features. I don't think we've
had anyone write a book on our platform yet so it'd be interesting to see how
that goes. Anyway, if you end up going this route feel free to reach out to me
if you have any feedback!

------
Tomdarkness
The only problem I could see is that the meteor api is still potentially
subject to major changes which could make large parts of the book invalid in a
short period of time.

~~~
vph
yes. This is a curious decision.

~~~
sgdesign
Of course, we'll make sure the book is up to date with the latest version
whenever it comes out. And we'll also provide updates if any major change come
out in the months after the book's release.

------
tferris
Those who like to build to Meteor-like apps while keeping Node's modularity
and npm should check out Derbyjs, SocketStream, FlatItron, Express paired with
Backbone/Amber/Angular and Airbnb's upcoming Rendr.

Most allow also to opt for a server-side rendering and mix it with real-time
features which is good for SEO (check out Airbnb's new mobile site).

~~~
jmduke
Jesus. Is it bad that I recognize exactly two of those proper nouns?

~~~
manmal
Single-page apps will be all the rage in the upcoming years, so I'd get
familiar with one of them (I prefer Ember, has been renamed from Amber).

~~~
andyhmltn
Do you happen to have any resources on them? I have been looking around for
the past few days and it's hard to find something that seems to teach best
practices and not 'hey let's copy the code for a todo app and not tell you
what's going on'

------
nathanbarry
Looks great! I'm really looking forward to seeing the finished book.

------
tianshuo
Interested, but can't open in China, where's the hosting?

~~~
JPKab
Good god. I don't know how you poor bastards put up with that ridiculous nanny
state firewall. Living in China must be like living with really strict
parents.

~~~
saraid216
You're not very familiar with Chinese parents in general, are you...?

------
elb0w
Cool, but why not just use web sockets?

~~~
tmeasday
Well, if you use websockets, you have to wire things together yourself. Sure,
you might want to decide _exactly_ what data to send to each client, when to
send it, how to propagate it between clients, how to deal with merging issues,
etc at a message-by-message level, you want to get down to this level.

But there's probably a good chance that (unless you are doing something very
specific) you'll just end up re-implementing the built in pub/sub mechanisms
of meteor collections which usually give you exactly what you need with almost
no work required.

To me, that's like asking "why use rails, why not just use HTTP?". We build on
layers of abstraction.

~~~
tferris
Isn't that what Node.js is all about? Modularity? To get away from the
monolithic, bloated, one-fits-all frameworks like Rails? And maybe there's
something between "Rails" and "HTTP" (Sinatra => Express JS => modularity).

Building a new framework on top of Node but cutting out the fabulous npm and
its huge ecosystem, instead unnecessarily introducing an own package
manager/middleman in order to lock in developers and not following (or rather
ignoring) Node's core principles is a brave step. Good luck guys, you'll need
it.

~~~
tmeasday
Definitely! There are things between meteor + websockets (socketstream and
derby come to mind), and depending on your project, sometimes they are going
to be the best choice. Just like sometimes Rails is the best choice and
sometimes Sinatra is.

I was just saying that it's a rare case that going all the way down to the
metal, and using websockets alone is going to be that best choice.

On the second point, I'll won't speak for the meteor team (which I'm not a
part of), but here's what Geoff Schmidt recently had to say on the matter:
[https://github.com/meteor/meteor/pull/516#issuecomment-12919...](https://github.com/meteor/meteor/pull/516#issuecomment-12919473).

~~~
tferris
Thanks for your thoughts but how can a walled garden like Meteor can be the
best choice for anything?

Meteor tries to create an entire new ecosystem using Node's merits. The
reference you posted lists pseudo reasons for choosing a new package system. I
don't know if here is the right place to discuss them but some of them are
heavily misleading and primarily business-driven and motivated by a
developer's lock in. It's important to state that especially Node's npm is one
of the most modern package managers around and already solving issues like
repeatability, asset building and bundling (npm's concept is totally different
though). Sure there's a need for package management on the client side but
coupling everything together is not the answer.

I highly appreciate the talented team behind Meteor and their achievements up
to now but it's sad and a deal breaker that they choose this non-npm route.

As a final point, I am aware that maybe it can be good to have competing JS on
the server ecosystems and all JS users will benefit at the end from this
competition.

~~~
tmeasday
I don't think it's quite as bad as you make out / think.

As Geoff said, in the upcoming release, it'll be trivial for a meteor package
to wrap a npm package and integrate it into the 'walled garden'. If and when a
client side package manager appears that everyone is using, I'm sure they'll
do the same.

So, I'd expect a situation to arise which is much like that of rails + gems; a
ruby library that is not completely tied to rails is usually published as a
stand-alone gem, with a X-rails gem which does the railties stuff.

Perhaps it's not as clean as it could be, but I think it's unavoidable when
you consider some of meteor's design decisions (synchronous APIs being the
biggest one) -- debating these is of course a separate issue.

------
ckluis
ignorant marketer here:

Could Meteor be used to build a CMS with 90% static clean html + 10% live
updating information (comments, chat, social, etc)?

