New Meteor Book?

[waldgeist]

Ah, nice, didn’t know these are the same guys.

[jkuester]

Yeah atmosphere needs definitely the option to indicate abandoned packages. Some are old but just work well and don’t require further maintenance, while others inhibit fatal security issues and should be flagged as insecure.

[brian5083]

Thanks for the helpful information.

[maka]

I use Meteor for nearly everything, and anything. Heck, I built an irrigation system out of a raspberry pi (and some solenoids) with Meteor on the raspberry pi and a Meteor built iPhone app.

Yeah, they hype may be gone. What I’m left with, is a freaking stable platform I can use to create an entire EC2 fleet, data acquisition and real time streaming weather stations, and my grandmother’s b&b website… for example.

I just aced a masters course in pen testing with the help of meteor, the professor was blown away by how quickly I could create a website to do my masters project on (btw, it’s really easy to f-up security in meteor… be careful).

A meteor book… with usages like mine, and everyone else’s experience with meteor… there should be a book.

[captainn]

It’s just so hard to earn a living while writing one …

[maka]

haha, I can’t but agree…

[digitalx778]

A series of guides, best practices, on how to build common application in different categories say data visualization , mobile app with real time notification sms etc. User, data storage, schema ,management with MongoDB and accounts.
Making use of reactjs

[sacha]

The reason why it’s hard to write a modern Meteor book is that there’s in practice two “Meteors”. There’s the “traditional” stack using Blaze, publish/subscribe, DDP, minimongo, etc. and all the other things that made Meteor great.

But that stack is not used by MDG themselves, and it’s obvious that they’re not investing any more time and effort into improving it. So writing a book is a big gamble, and your only audience is pretty much people who are already using Meteor – and to that also subtract people who’ve been using it for so long that they don’t really need a book anymore.

On the other hand there’s also the “modern” Apollo/React/etc. stack but 1) it’s vastly more complex, meaning 2x-3x more work to write a comprehensive book and 2) if you’re going to learn Apollo/React anyway you might as well go the extra mile and use Gatsby, Next.js, or some of the other platforms that have more momentum that Meteor. Meaning the audience for such a book is pretty small.

Btw I should add that Discover Meteor is now completely free so if anybody wants to take the content and update it for a more up to date version of either stack 1 or 2, be our guest

[jonlachlan]

I think with the new useTracker (to be announced?), there might be an opportunity for Meteor to be the reactive data-source that works nicely with the composable, modular, importable (sharable/reusable) frontend framework React (with a nice upgrade to React Router that’s on the horizon).

I also think Meteor has a market with people who want to develop server-side and client-side code in the same repo/process, because you specify a mainModule for your client and your server (or alternatively you eagerly load from your /client and /server directories). It is not apparent how to do this otherwise (unless you’re a big fan of configuration). The Mongo stack is additive to this (but you can write packages that depend on it).

There will always be various newcomers as well as people with vested interests. For starters, there’s students, academics and hobbyists. Add to that professionals-in-charge-of-inventing-something-nobody-else-knows-how-to-do. Add to that professionals-who-evangelize-because-they-want-others-to-like-Meteor.

[captainn]

I think there are still a number of people who use Meteor + React + Mongo/Tracker. I’d love to see some stats from MDG on that if they have that sort of data.

I’d thought of trying to write a book based on the particular way I build apps with Meteor (using my somewhat customized data system).

Of course, now I’m looking pretty hard at Svelte - maybe there’s an opportunity there!

[cereal]

I use svelte + meteor/ddp for the transport layer.

The thing is, the transport layer doesn’t matter. If you’re deploying to a serverless environment, you’d use serverless functions and a rest API.

If you have some monolith, you might use REST, you could use apollo, you could use some other pre-made solution. It doesn’t matter. The client doesn’t care. As long as it has the right data.

I think ddp is a fantastic solution to the transport layer. Just super easy, zero mess. Graphql is super verbose. There’s a lot of duplication involved, between defining your database schema, your graphql schema, your object mappings. It comes with a lot of overhead. If you’re developing an enterprise application on a relational database, it makes a lot of sense.

If you’re building a hobby app, meteor’s ddp transport layer is like a miracle in comparison.

[maxhodges]

Why a book?

these days people just Google for specific answers when they get stuck. Books don’t just compete with other books, they compete with alternatives to books, like docs, slack channels, forums, stackoverflow, youtube, and online courses. Maybe no one has written a book because the market is already being well-served by other resources. Long ago I bought that Meteor ebook published by @sacha, but never actually read it!

[distalx]

Meteor Guide is awesome and beginner friendly. Things started to get complicated onces you start solving real-life problem (rating system, friend list, search).

People have already shared patterns, tricks either in form of Articles or on this forum. These gems are kind of opinionated and problem specific. If we start putting it all together as a community we might start coming-up with standards.

Putting together 10 chapters is time consuming as a single author or team of two. But write down a single recipe is less difficult. Also it would be easier to revise a recipe than an entire a book.

So what I’m proposing here is a community driven cookbook, where people (author) can just submit a recipe.

If we able to figure out a way to provide a financial incentive for authors and reviewers that would be awesome.

For authors, we can have some sort of payout structure for authors, like DigitalOcens’s Write for donations program. link

For funds, we can use kickstarter, open-collective, buymeacoffee.

[robfallows]

You seem to be describing meteorpedia - which I think could do with some love.

[a.com]

I feel like the meteor guide is basically a book. The docs are good these days as well. And the forum has grown to encompass a lot of discussion on how to build certain functionality/types of apps.

[Volodymyr]

The book How to build a SaaS with Meteor would be great especially if you use Blaze and willing to contribute your boilerplate to readers without domain-specific code. There is cool Ryan Glover’s Clever Beagle but it is still in development and is React-based from the beginning.

As you have gone through it from the beginning to release, scaling, maintenance, integrating user requests as well as fulfilling it would be easy to build on your experience.

Meteor is alive but it lacks integrity and ready SaaS-oriented solutions, which e.g. Laravel has out of the box.

I would gladly pay for something like https://devdojo.com/wave#download-section

I would gladly pay for Enterprise version of Meteor

But Meteor community are too shy to charge anything with few exceptions like Max Savin

[distalx]

Yes, something like that. Thanks for sharing that - I didn’t know about it.

[rimskys]

This is what Vulcan is trying to achieve.

[Volodymyr]

Vulcan does not have strong community. Meteor is a much better choice for that.

[rimskys]

Vulcan is based on Meteor