My biggest problem choosing Meteor is the lack of response in the community and the state the way a lot of Meteor packages are in. I’m excited about FINALLY supporting node /modules is going to be a little better in 1.3 but I have concerns about the state of Meteor in general?
Also seeing libraries stopped being maintained kills my heart a little bit, especially now that I have an app in production, for instance, the awesome CFS collection2 maintainer has said goodbye, this is the stuff that really worries me. What’s next, Collection2, Roles? Has most of the boat swam to shore and I’m left scooping water with out with a bucket?
The inactivity of the project libraries in atmosphere really kills me.
Trying to make a case to my management this Meteor is the right choice??
Should i be looking at this with an examining eye?
Is MDG equipped to meet 2016 and beyond? Is there really enough financial support for MDG Meteor in the current fashion? Is there anything really big really running on Meteor anyway, that I use?
Anyone want to turn this back at me? I guess you get what you pay for
Libraries and packages always come and go. There isn’t anything Meteor or any other company can do about it.
But there is an effort now to enshrine a certain set of packages and approaches in projects like the Meteor Guide and Mantra. If a package from the guide is abandoned, we will certainly do something about it.
I’ve been trying to stay out of the Meteor concerns threads, but I think it’s worth saying that for our company (and I suspect many others) the above statement is a massively important commitment.
As I understand it, the guide is going to always provide a ‘best-practice’ approach for producing a fully-functioning, secure, scalable, etc. app on the Meteor platform?
Obviously what counts as best-practice will change over time, but as I understand it the statement above means if you stick to the guide, then your app will be secure, functional and using a supported approach for as long as MDG are around?
When you say “do something about it”, am I right to say that means that if a formerly best-practice 3rd party package ceases to be supported, then the guide will recommend an alternative, or in the absence of an alternative that MDG will take on keeping the package functional themselves, in order to ensure that there remains a supported “best-practice” stack?
If so, I’d suggest publishing that commitment far and wide; one of the things that has kept us on the Microsoft stack for so long is the knowledge that there will always be a full stack we can use and a well documented way to use it. That’s really important for us as a dev shop, and also as part of our sell into enterprise.
If MDG are offering that, then effectively you are out Microsofting Microsoft. In a way you will have created the enterprise and enterprise developers’ holy grail… a “not sh*t version of webforms”!
You’re here since July. Since then, you asked around 40 questions. At the same time, your number of helpful answers to other peoples’ problems is close to zero. The list of your forums replies is a stream of “me, me, me, me, me”. I don’t remember seeing you helping people on IRC, Gitter or Slack either.
Yet, you notice that YOU have a problem with the lack of response in the community.
The lack of response you experience is because of people like yourself, who don’t give, but only take.
If you want to continue like that, then please chose a different stack, the community will be more healthy.
If you have a product in production, why don’t you contribute to the tools you’re using? You’re making money with it, so give something back to something you’re getting for free. We are constantly contributing to Polymer’s catalog of elements since we’re using them. Fixing bugs and imroving them benefits us and everyone else. I’d do the same with meteor if we had the capabilities to do so but I certianly hope to have people invest on the meteor platform once we have more great developers on our team.
I don’t see any reason what stops you from looking at an incredibly well written package, pick off where someone left of and continue to improve it. You’re obviously using it in production, maybe are making money with it. I’m pretty sure you also write your own code, or are unicorns writing that code? Why not look at the collection code, see if you maybe can help out with it?
Like sashko said, libraries come and go but nobody stops you from using them. Just like Blaze. Blaze is kind of dying but what would anyone stop them to keep using it? What stops people from forking it once Meteor officially deprecated it and keep it up to date with the stack?
Also, your example of meteorizer is a good example of something that we simply don’t need. MUP does the job well if you want to deploy an app anywhere else than Galaxy. I’ve never had great experiences with demeteorizer but MUP is a proven tool that works, offering far more than what demeteorizer can do, so what’s the problem here?
If you can’t deploy your app to modulus with MUP, then modulus is the real problem, not the fact that demeteorizer is no longer updated.
I wouldn’t say that I only take from the community. I would imagine that me posting questions and getting answers to common questions would only prove to be searchable and benefit other users, especially new ones.
As far as contributing to libraries, It’s not like that I don’t want to or don’t plan to it’s just that haven’t yet (I have contributed small patches to mostly custom solutions), it’s just that I’ve been in a fire drill for the last 6 months and I haven’t had the time to really to do so (yet). I also contribute to Meteor by subscribing to Kadira and I also send support financially directly to developers, Aldeed for instance, as much as my personal budget allows. Albeit, I do post a lot of questions, mainly out of a little frustration of still being relatively new to the framework, 6 months is hardly enough time to be an expert.
Just trying to push the envelope with Meteor with my app. After I feel my libraries are up to snuff (tests and all), I’ll add to Atmosphere.
In short: Just add in the aws sdk or use same pattern as in https://github.com/raix/Meteor-CloudFS - Then read up on SQS, S3 events and lambda functions on aws - and you would have a solution that scales without writing much code.
