New to meteor - my thoughts

community
1

I found out about meteor few months ago, and decided to make the move away from Django. Here is what has happened since then (and some of my thoughts):

  • I haven’t written a line of Meteor code due to the uncertainty in the community. Reading the forum posts didn’t help. I had previously tried to learn NodeJS web development but gave up due to the fragmented eco system. It’s chaos The Sad State of Web Development

  • Unlike everyone else, I was first skeptical about it being a venture funded project compared to Django, which is being developed and maintained by Django software foundation, a non for profit organisation. This may be why majority (at least on this forum) seem to unhappy with the direction Meteor is going yet they continue this direction.

  • I love atmosphere and think moving to npm is absolutely unnecessary! Django has pip , and Djangopackages.org for Django packages. Most web frameworks have this.

  • I left Django because it was getting very fat and complex. Now I see that meteor is facing the same problem, from a simple easy to use/start framework, to a complex fragmented monster trying to solve everything. Then MDG managed to force React down everyone’s throat. How many of you learnt it solve a problem you were having? What people don’t understand is that React is solving Facebook’s problem, not everyone’s problem. Same thing for GraphQL, the ability to have one single interface for several, maybe hundreds APIs.

  • At this point, I’m considering moving to Mobile App development since it’s a more stable/predictable. Infact, I’m considering moving away from web development altogether.

  • From my understanding, the scalability issues facing Meteor can easily be solved with current tech out there such as RethinkDB. Infact, I heard they reached out, but MDG didn’t feel like rewriting many core components. The guys went on to develop horizion.io http://horizon.io/(my only issue is it’s just a realtime backend, and not a fullstack and no account-system yet)

  • I think MDG should swallow their pride and go back to the drawing board. Try to solve the issues with the current stack, and make meteor the best it can be. One framework to rule them all.

7 Likes
2

That’s a shame. This place has been poison for the last 8 to 10 months.

It’s claims like this that are part of the problem IMO.

I’ve done a lot of Meteor coding in the last year. Haven’t touched React since I tried it with a small project a year ago. Haven’t felt forced in any shape or form to adopt it. Use Blaze, React, Angular or one of the less recommended view layers but I wish everyone would stop misrepresenting the state of things.

Blaze, Angular and React are all represented on meteor.com in the tutorials and all represented in the Meteor Guide. I don’t see any shotguns to anyone’s head there.

Blaze may wither away in the future or it might thrive. Too early to say, but if you are looking for some framework or library that’s still going to be the most popular or most recommended 2, 3 and 5 years out you are asking the impossible IMO. Unless React is the pinnacle of JavaScript evolution (doubtful) people are going to be dumping that for something else in coming years.

Make a decision, start building stuff and be prepared to have to adapt to inevitable change in the landscape no matter what decisions you make now. Particularly in the JavaScript world.

7 Likes
3

[quote=“eosimosu, post:1, topic:28595”] What people don’t understand is that React is solving Facebook’s problem, not everyone’s problem. Same thing for GraphQL, the ability to have one single interface for several, maybe hundreds APIs.
[/quote]

Bingo - Facebook has over 10,000,000 lines of code.

4 Likes
4

I’m gonna second @peter.roehlen, the forums have been filled with a circular loop of misinformation driven by strong emotions (driven by misinformation…) for quite some time. I suggest you pick a starting point from one of the setups shown in the guide and dive in!

Meteor is even more awesome now than when I started (1.1). Yes, they’ve had some hiccups in the PR area, but they’ve learned from that, and on the technical side everything is still awesome!

Everything you could do in Meteor 1.2, “meteor classic” as some are calling it, is still working today and just as viable.
React, import / export, Apollo, etc are all opt-in.
Yes, Blaze is no longer maintained by Meteor. The React integration isn’t either, so both are pretty much on the same level, and I can’t wait to participate in Blaze improvements!

You love Atmosphere, but you haven’t written any Meteor code yet. I love Atmosphere and NPM. I’ve done quite a bit of development, building both apps and Atmosphere packages, and I’m so glad for NPM access. Prior to the NPM integration, you either had to manually pull in 3rd library packages or create Atmosphere wrapper packages for NPM packages. It was silly and often annoying. Atmosphere is great, but having access to NPM as well is much nicer!

6 Likes
5

Here’s the thing:

  • Python has Pip
  • Ruby has Gems
  • JavaScript has NPM

Meteor was built on NPM, so why should it compete with it? That’s biting from the hand that feeds you.

MDG has made a lot of mistakes, I think we can all agree on that. But so have we, and so has our leadership, in our respective jobs. Such is life.

Now MDG is taking it in the chin, trying to understand where they went wrong, and is moving forward with Apollo while fixing other Meteor quirks (like build times) to course correct so that they’re not the next IBM of the 90’s.

4 Likes
6

I think MDG should swallow their pride and go back to the drawing board.

I don’t want to sound too harsh, but by your own admission, you haven’t written a single line of Meteor code and don’t sound like you plan to. Why should your opinion carry any weight?

10 Likes
7

@joshowens just updated crater.io, which is a Meteor site, to React. Page load speeds have increased dramatically. Josh credits React:

You will notice the overall speed is WAY faster and this is almost totally due to using React instead of Blaze.

2 Likes
9

Because it’s important to get a newbie’s perspective. It’s important to remember what attracted people to Meteor in the first place. That is the purpose of this post, not to bash anyone.

10

And he also said he won’t using Meteor for new projects.

1 Like
11

I’ve been having the same feelings to be honest. Backend work is just more fun to me now. I get to write tests, prove without doubt my software will run as expected and scale. Let other people worry about shaking the javascript tree and rollup and webpackify, etc etc rabble rabble.

I browse these forums these days because I guess some part of me still wants to believe MDG will come down with a white horse and say: “Here’s what you’ve been missing for 9 months now” and immediately revindicate themselves.

1 Like
12

I can’t speak for all of MDG, but I really appreciate that you took the time to provide feedback. It is not often that we get insight into what Meteor looks like to someone who is new. Thanks!

I think we (the community and MDG) need to do a better job at emphasizing how great Meteor is overall, and work harder to have constructive conversations about how we can address its weaknesses and make Meteor even better.

I am convinced that MDG has been making the right decisions in the last 6 months- both for its business as well as for the future of Meteor as a framework - but that we haven’t done a good enough job communicating and involving the community. I can’t make those problems go away over night, but I’m going to actively work on improving both aspects. If any of you want to help, please let me know!

8 Likes
13

Facebook is also producing tooling and performance measuring code, solid testing frameworks, etc. From a shear perspective of money and people power, React will continue to push forward at a much faster pace than anything MDG or the community could produce at this point.

That is why Apollo client libraries started with React first. Just a realization that React and Angular will likely produce better results for front-ends, performance-wise. At the end of the day, speed matters when you build something, the speed of page delivery can determine sales fluctuations. Nobody wants to stack the deck against themselves out of the gate, startup or established big co.

5 Likes
14

That feeling when you write a two page long response in order to:

  • point out fallacies in an argument’s logic

  • express the silliness you see in expecting mdg to pivot their product in order to keep you from leaving web dev for mobile app dev

  • help prevent “is x dying?” posts

only to realize your post is bumping the thread to the top of the page…

2 Likes
15

That is correct. But I still work on Meteor apps day to day. Until MDG clairifies it stance on the future of Meteor, DDP, and other bits of tech… I just don’t feel right making bets on it in the long term for other people.

I think it is pretty telling that we never got a Meteor Summit, even when I offered to help run it. We do have a GraphQL summit being put on by MDG, though. My parting thought is this verse from Matthew 6:21:

Wherever your treasure is, there the desires of your heart will also be.

3 Likes
16

This really isn’t an issue of scaling out for hosting apps. It is more an issue of converting people to a new way of thinking. DDP is a new standard and would require mass adoption to be useful in the long run. GraphQL is doing a better job of convincing people that it should be a new standard. REST was never really adopted or proclaimed king by some board of people, it just made sense and people started to use it. MDG doesn’t have the pockets to persuade people to use DDP like that. While DDP and GraphQL might feel different at the moment, things like subscription support will make it’s way to GraphQL and overtake the current functionality we have from DDP. I think this is a core piece of the decision process that isn’t really being discussed much by MDG.

Let’s be clear, Atmosphere is only an informational site that is suppose to run some algos to help rank packages. One could easily rebuild a site on top of NPM based information to help with finding good packages. It also turns out those algos aren’t doing the best job and could use a tweak.

As for the package system that meteor has now (I think the main server is called Troposphere), it likely should go away in the long run. The team at MDG should focus on problems that it can handle and effectively solve in a unique way. It turns out the NIH syndrome that helped Meteor do a bunch of things early on came with a hefty price tag - you have to pay those people to push it forward in the long term. Turns out that is likely bad for startups with a certain amount of cash on hand… But it did make for awesome times when things like webpack and React didn’t exist at all. Now we can get those libraries from NPM easily. Why should Meteor maintain a big infrastructure if NPM can cover most of what we need?

You are correct that they did talk, @slava even built a package for it! But this goes back to DDP. Turns out building both the front and backend data storage was likely a bad idea, hence Apollo was born. Use GraphQL and Redux and then you suddenly gain a lot of possibilities on the front-end and back-end. Adding something like RethinkDB support to Meteor meant writing new front and backend code. With Apollo, just write a new resolver using existing node drivers for RethinkDB. But flexibility in the choices you can make often come at a price, you don’t enjoy the luxuries of tighter integration points like the accounts system. People are certainly working on options, but it will take time still…

In the end, I do believe a lot of these choices are being made because it makes more sense for a company to build a profitable product - Optics.

8 Likes
17

Thanks for lengthy response. Actually cleared a few things up!

18

Blaze is not developed anymore by MDG. This is a fact.

1 Like
19

@eosimosu don’t get me wrong, how can you be a newbie when you don’t write a single meteor code?

20

I’m really curious where that perception comes from. It’s 100% wrong in my opinion, and the data seems to support the fact that React is definitely solving a lot of people’s problems, not just Facebook’s.

4 Likes
21

It really amazes me how in-denial some fokes are. How some on here lash out at others for bringing this information to you. Devs need to understand that Blaze is no longer maintained by MDG.

Also, In another thread someone from MDG asked if another Dev wanted to take on useraccounts maintenance. MDG is moving to NPM and Atmosphere will eventually be put out to pasture. Tracker, MiniMongo will also become the community’s responsibility as soon as someone steps up to take them on I’m sure. Who’s going to eventually pick up the build-tool? Even the Apollo client is community driven from what I’ve read.

Meteor classic’s parts will be farmed out to the community for maintenance as the community steps up. Blaze is the first big part to go to the community.

MDG is preparing for this. Meteor 1.4.1 allows for pinning, so we now have the ability to release things like Blaze outside of the Meteor release cycle.

MDG will be building out Apollo Sever and Client, this will be their focus. Meteor-classic will become one of many integration points for Apollo, and as such I’m sure MDG will make sure Meteor is prepared for the task. MDG has chosen not to complete where they have in the past. Instead MDG focus on the data persistence and analysis experience.

From what I’ve read, React is maintained by an army of FB devs. According to @joshowens it will improve the performance of your site just swapping it out from Blaze. And according to @sacha survey, devs are happy with the tech and plan to use it again.

GraphQL was designed by FB too, and MDG will do their best to bring us a great experience with it – they’re betting a portion of their business on it.

This is not just smoke you-all. There is nothing to fear or have uncertainty and doubt about. Devs need this important information to base their decisions on. I have a business running on Meteor classic. I will continue to use Meteor, and slowly switch out Iron Router + Blaze for React Router + React. When Apollo nails reactively I’ll adopt that too.

By the way, I’m sure Vue.js and Angular2 are probably great choices as well. Blaze is also great and I’m very productive with it, but is maintained now by only a few. And since I have a business to run, I need the fastest view layer framework, with some of the best tooling available, supported by a large company that is committed to further its state of the art.

Also, MDG is not forcing anything on us devs. We can continue to use Meteor classic and just swap out the portions you don’t want if you so desire. And I’m happy to report so far MDG seems to be helping with the transition to this new tech stack.

Also, @joshowens we appreciate you brining your perspective and insights into this discussion. And are you running a conference in the near future? I’m interested in attending if things line up.

1 Like