Recently I created a new project and found new unfamiliar “import” operators in a default code of a template application. I think that any such optional functionality should be avoided by default and described separately in sections titled with descriptions of possible issues, where such additional functionality is really needed. In other words Meteor should remain strong in complexity management and serve to socio-cultural change as a ball pen did, having made every smart person to be a competent writer.
import statements were introduced in ES6, and have nothing to do with Meteor.
In the future, please avoid making posts with clickbait titles before understanding your issue.
We strongly believe everyone starting a new app today should be using imports for everything, and designed the tutorials accordingly. There have been a lot of conversations already on this topic, and the title here is not great. Would you mind changing it to something more constructive?
And I don’t want to.
I’ve changed the title. I feel that the main drama of Meteor is that it wants to please professional developers instead of advancing its unique mission to disrupt this profession at least in some domains.
The title is still far from matching the issue about your personal js fatigue. Indeed it is demanding and sometimes difficult to see through, nonetheless, I recommend you to stay up to date and steadily adapt to the latest trends. It’s essential to do so.
Try to have different perspective on your problem or at least grasp the bigger picture. What you’re describing is not to a matter of direction or standardisation in the js ecosystem. It is the evolutionary development process of software development itself you’re stuck with. It’s matter of time until this problem vanishes and you’re able to work with reliable and future proof tools.
Yes, grasping the bigger picture, evolve, follow the development directions. All are good advice, but many of us started with Meteor just because we did not have the time and energy to do just that and Meteor gave us an alternative.
Yes, we have to accept what has become but we do not have to be happy about it.
I had time to reflect on my irritation, and now I see this to be depended
on the personal role choosen. The original point was made in position of
business analyst, for whom Meteor is just an instrument to achieve
non-programming goals. On the other hand, if I position myself as just a
programmer I see no significant issue.
Hey, there have been a lot of threads like this already in the past with mostly the same points made, so I’m going to close this one - please PM me if you don’t think closing was the right decision.
I think it would be great to have some constructive discussions about how today’s Meteor could be made more beginner friendly, while sticking to the modern language standards.