Show HN: We're writing a book about Meteor | Hacker News Reader

Show HN: We're writing a book about Meteor

themeteorbook.com

46 pointstmeasday29 comments

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

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

it's a really simple site w/wysiwyg for writing e-books (spits out epub/mobi/pdf too). has a nice reader as well (see prev demo link). i think mike@pen.fm is in palo alto actually.

Even if you don't need LaTeX, you should consider it anyhow: even if its a little awkward and clunky, it does separate content from presentation and the results tend to look really good.

You could also check out something like Pandoc, which would let you write the actual content in markdown and then export it to LaTeX (or HTML).

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!

Seconding the PenFM suggestion. I know mike personally and have seen his work on the platform. It's very impressive. I don't think there's anything else out there that can so easily push out a perfectly-formatted ebook without all the usual pains involved.

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.

yes. This is a curious decision.

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.

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

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

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

I thought they were all the rage 5 years ago. :(

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'

As someone who has tooled around with Meteor a bit, and also digging into the other platforms (although I haven't messed with FlatIron yet, despite being a Nodejitsu customer/fan), I think Meteor has a huge sweet spot in the Enterprise world. It really does abstract a huge amount in a way that is very un-Node, but that has some great pros when it comes to time saving. It is unbelievable how quickly a professional app with authentication, bootstrap, email (integration with mailgun out of the box, or your own) can be built. A lot of times in my day job as a data analyst, I just need to quickly get a tool deployed for my team to work with, and I'm not trying to be "pure" and worry about being able to npm install the latest MongoDB to Postgres synchronization module, or something like it.

Don't get me wrong, I'm very excited about where Rendr will go when they finally get it ready for prime time, and I'm trying to get more comfortable with Backbone in preparation for it. But the ease with which I was able to quickly build something in Meteor makes a stark contrast with what I'm having to do with Backbone/Express combo.

also sharejs.

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

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

It's hosted on Heroku, is Heroku blocked in China? 真奇怪…

Anyway here's a PDF version of the page:

http://cl.ly/MiTa

And you can sign up to the mailing list here:

http://sachagreif.us2.list-manage.com/subscribe/post?u=b5af4...

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.

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

Cool, but why not just use web sockets?

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.

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.

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

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.

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.

I share your concerns regarding "walled garden." Are you aware of Meteorite, and the Atmosphere repository? Essentially Meteorite is an open package manager which wraps the meteor functionality, and allows installation of all of the third party packages on Atmosphere.

I do want to point out one difference I've noticed when using Meteor: ease of implementation.

Once the "accounts-ui" package is added, here is the code that is added (in two respective files) to implement a login/registration function:

    <div style="float: right; margin-right:20px;">
		{{loginButtons align="right"}}
    </div>

and

Accounts.ui.config({ passwordSignupFields: 'USERNAME_AND_OPTIONAL_EMAIL' });

ignorant marketer here:

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

Reply on news.ycombinator.com