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.
8 Likes
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?
10 Likes
Is this just some kind of 1st April joke? Or you just don’t follow JavaScript evolution (ES6)?
2 Likes
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.
I guess the whole Javascript world is the problem. Everyone does things different, there is no clear direction or standardization. While some people love this about the JS ecosystem because you can do things like you want to do, this way also provides some problems. A few days ago I’ve tried to use some React ui frameworks (Material-Ui and React-Toolbox). React-Toolbox is using cssmodules, which don’t work very well with Meteor. Material-Ui uses inline style objects, which could cause performance issues on slower devices. I’ve lost 2 days because I’ve tried to get React-Toolbox running. In the past, you’ve added the ui framework (JS+CSS) and everything has worked without problems. Now you have to configure your whole setup, check if everything is compatible only to get some ui components out of the box.
1 Like
2 Likes
1 Like
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.
1 Like
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.
3 Likes