Here is my biased opinion. Frankly before meteor mentioned moving to npm I never even considered writing or even rewriting my logic for the node ecosystem. I as well as other community developers went through endless nights of no rest and sickening worries , wondering if I was falling behind because I continued to write packages in atmosphere and not on npm.
Until I realized something very important. The whole push to write packages for npm vs atmosphere came shortly after the React nightmare (not truly , but the scare ) and meteors position on react being superior to blaze.
I spent weeks learning react , angular and kept finding myself missing blaze. I learned a lot of great things from react which inevitably lead me to appreciate blaze-components.
Then I asked myself the big question whatâs wrong with Atmosphere ? I mean really. Iâve written several packages and not once has Atmosphere or Meteors packaging system failed me or held me back.
Then I realized I was worrying myself because of the hype.
My closing thoughts. atmosphere is amazing. Blaze is amazing and will be better. If the whole point of writing packages for npm is just for the sake of embracing and welcoming a larger group of the js community then perhaps Iâd prefer to buy each of them a coffee open my laptop and introduce them to meteor create the-best-thing-ever
Itâs a complete shame but the core developer left on Meteor thinks package.js is a âlaundry listâ. This is how out of touch MDN got from the original Meteor spirit - they just donât get it.
Meteor has amazing roots, and it is the best web framework, but their developer(s) are completely prone to hypes. They didnât skip any of them: Angular (which finally died), es6, reactâŚ
I just wish they wonât keep destroying it - as they did with any version since v1.2 .
Wish they were sticking to the roots and kept their apis backward compatible, so the amazing hard work, done by so many devs, wouldnât go to waste.
They give us a feeling in the docs like they are going to take the ground off our feets and close Atmosphere tomorrow, where in fact they got nothing to replace it - what a shame. So glad Mitar started this thread, to show how poor the situation is.
Stay vigilant people and love Blaze - we survived Angular!
-Daniel
I couldnât agree more. I understand what happens with hype frameworks. They should definitely be evaluated. However when you are engineering a project and the decisions you make within the architecture aspect of the project may potentially affect thousands possibly millions some day you have considered backwards compatibility and the community you re working with.
Again this is not to bash MDG because without Meteor this thread wouldnât exist. But I do feel as if giving the community the impression that Atmosphere will be shut down or it has some negative impact vs. Npm was not a smart move. Look at yarn for example and many other npm alternatives.
I absolutely agree with you guys. I donât get why some people try to move their meteor opinionated packages to npm. Doesnât make sense at all if you ask me. And if you do, you have to go through build script shit and npm link nightmaresâŚ
Actually itâs npm that is just crap and we try to use it because itâs supposed to be standard (at least for the next 100 days)
I second on that. Still, I havenât seen any solid approach to replace Atmosphere packages completely. I do understand that npm is widely used, and in fact, when I first encountered Meteor, I was wondering why they invented their own package manager instead of using npm. But now I know. And I cannot understand that MDG is pushing things towards npm without having established a full alternative on that basis, i.e. including support for different architectures, especially mobile, which still is a strong USP for Meteorâs build system.
After encouragement from some people here I brought back the post I removed.
It is rude, and thatâs why I removed it - but it came from the heart, MDG youâll have to forgive me if it is too offensive, but it reflects real feelings in the community - be more in touch with us.
I want to give few examples for how bad the situation is:
When upgrading to v1.4.2.3 I found that Arunoda greathttps://github.com/meteorhacks/inject-data broke, not sure why.
As you know, Arunoda left us already, and this package isnât supported any longer.
I managed to find a fork here: https://atmospherejs.com/staringatlights/inject-data that fixed the issue and saved the day (pure luck, if I did the upgrade immediately when it came out it would take me hours to work it out).
My tap:i18n package, loved by many and endorsed by the Meteor docs themselves, got broken with API changes to the point where it doesnât work for many edge cases.
Every release of Meteor is net-negative for me, a bunch of hyped features that I donât even use or need, and a set of breaking changes that destroy my build and 3rd-party packages I am relying on. (I must upgrade for security reasons).
It totally surprised me, and it still does, how for a project that is so dependent on community work the time from release candidate to release is a matter of few days! nothing can work this way, zero time for the community to test and respond - no process with the community.
If Meteor wants this fast release cycles it can work only if it will take a list of all the top 500 community packages and make sure they arenât breaking by their release - and still I wouldnât recommend it.
Without this every release destory the confident of the developers - and that is why we see the calls for community fork.
And, just another note, ever since the close of the mailing list, I lost touch with the community, I simply have no time to read 100s of messages in the forums (regarding the Community Fork effort, how things are going with it?) the mailing list keep me in touch, since at least I can read few lines from now and then of the things that are going onâŚ
Thanks @theosp for your post, I couldnât agree more. Iâm still on 1.2 with my app, since every attempt to upgrade it resulted in hours (!) of unproductive and very frustrating research. This was the case when I migrated from 1.1 to 1.2, and it was also the case when I tried to upgrade further. All of these incompatibilities were eventually related to breaking changes in the build system, and many of them affected SASS. Letâs make this crystal clear: I still really love this great platform, but the upgrade nightmares do scare me.
(The issues you linked were a very interesting read. I was just about to implement inject-data for SEO, but now I will think twice. Would be just another puzzle piece doomed to break.)
@seba, check the above thread, you wrote:
âAlthough a bit outdated with the move to NPM. As the developer of https://github.com/sebakerckhof/stratosphere (private meteor package server) I could write a section on how the meteor package system works.â
There is no signs for transition to NPM in the coming future, and your work is invaluable. One day might even be part of the stack that will help us to fork away from the main branch when itâll get completely astray.
Stratosphere was really cool I tried it I believe 2 years ago and really liked where it was. I am the author of Scorpius the fork if Orion , and it would be really cool to see true systems come together to push a better community.
@theosp let me know if you plan to work on Stratosphere Iâd like to help get that up to the visual appearance of atmosphere
Never heard of Stratosphere yet, thatâs pretty cool! At the moment, I am using the PACKAGE_DIRS option to get access to private packages, but this server solution is way more elegant. Is Stratosphere being actively maintained? I am asking since so many packages become deprecated these days, and using such a private package server would quickly become a vital part of your development setup.
I havenât used stratosphere in about 2 years, but when I used it it needed a little work and the author was reaching out for assistance. At the time I didnât have enough bandwidth to contribute, but I can see something like Stratosphere going mainstream.
I can even see stratosphere leveraged to a paid service or SAAS.
(not truly , but the scare ) and meteors position on react being superior to blaze.