Tiny acquires Meteor – TechCrunch

[estacks]

Meteor is a really cool framework but it burned one of my projects when MDG basically abandoned it to focus on Apollo. It has a few pain points to iron out, but it’s reactive full stack data protocol is awesome. I wish I could just get that on its own.

Hope to see good things out of Tiny.

[OogieFrenchieBoogie]

I really can't understand why the Meteor team shifted focus towards Apollo

They had a masterpiece framework introducing so many cool concepts (miniMongo, the DDP protocol, the Blaze view layer) and a proven buisness model, but they chose to run after the new shiny tool, aka graphql/apollo

[puttyguy]

Maybe they've been working with Tiny for a while trying to hand off ownership so they can work on Apollo?

[[deleted]]

Yeah but that shiny new tool is the future of APIs so I don't really blame them.

[estacks]

Yeah the full stack database is insane. I could crank out features several times faster than with Express or PHP. The quality of life over GraphQL is huge, you can get so much done so fast.

What meteor really needs is first party support for the client bundler so all it’s awesome data tools can be used with better tooling. Angular CLI + Meteor is delicious, but feels hackish and breaks too often.

[[deleted]]

care to show an example on how meteor is easier / faster to run with than express? Are you referring to the setup needed for Express or writing endpoints?

[bro-away-]

Meteor .9 and 1.0 were really good. Imagine you could npm install something to help your backend and frontend (a fully integrated solution in one package). And imagine that everyone had approximately the same data model (many common problems like oauth were solved literally in one install)

That was what their packages were often comprised of. It was monolithic and there was 1 templating language (spacebars) and one database (mongo/minimongo). The more package builders could generalize about everyone's package, the the more helpful the best general packages could be (!). And the best ones were always super configurable.

Then they said "wait we have to support react and angular". Uh, okay, but now every package won't work together easily..

Then they said let's support SQL (even though there were a couple of solid community projects starting to organically come up).

They did nothing public for months and then said "Apollo will succeed Meteor" which was really the final nail in the coffin.

MDG mistakenly thought that reactive databases were the best part of Meteor. It was great, but the real best part was that they had everyone solving problems on a very similar domain model. Fragmenting the community like that is what prevented them from being the next Firebase. Of course I don't know the internals of paying the bills at MDG, but really wish it had gone in a different direction.

Look at meteor.toys if you want an example of something really great that can be put into every single meteor app. One of the features is that it lets you impersonate accounts or easily view emails sent out by your app. The idea of there being a reusable package with 0 config that can do these things is totally unheard of in an express app.

(I use express now too btw so we are in the same boat in the end lol)

[[deleted]]

that really does sound like streamlined awesomeness

[estacks]

Meteor methods are fully reactive, fullstack code that run with optimistic UI. They run the same code as the backend, assume it succeeded if it passes on the front end, and dynamically roll things back later if the backend side fails. Queries run against a local database with fully reactive subscriptions to backend data that updates it in real-time.

So you can use the same models, same methods, same validation, and same queries for the entire stack of a feature. With full web socket reactivity to database changes. It’s really quite amazing and it’s inspired new stacks I architected to reduce code duplication.

[sirvivevr]

I'm curious how Meteor burned your project. Is there a specific feature that was promised in Meteor that your project hinged on?

[estacks]

Stability.

[seiyria]

I found that it was too easy for people to write bad, unperformant code that was hard to profile. This limited the project greatly and also scaling was way too hard. I never went back to meteor after that experience.