Coping with architectural option overload

help
1

I just have to take a moment and scream…

THERE ARE TOO MANY WAYS OF DOING EVERYTHING IN METEOR!

And everything seems to be deprecated before it’s even declared 1.0.

I’m dying here. And I consider myself relatively a master of chaos!

I think there’s only one answer: good old Brooks’ “Plan to throw one away.” Just get something working even if it’s “the old way of doing things” and we already know we’re going to replace Blaze with React and Ionic with React Native and Iron Router with Flow Router and maybe far more besides. A lot of those upgrades will be more or less transactional so maybe the prototype doesn’t need to be thrown out in the event.

But then there’s the corollary, “If you plan to throw one away, you’ll throw away two.”

It’s really hard to avoid procrastination if all the code you will write this week will be a one-liner next week when someone releases a magic package to do it all for you.

Curses! Too many choices!

Carry on I’m beyond help… :confounded:

2 Likes
2

Hey @spicemix

I can relate to this pain, and there’s a saying I would paraphrase as: "if you always strive for the best, you’ll never suffice"
that being said, I believe there are two things to suffice:

  1. keep things modular - that way, you reduce the pain of refactor/replace something. Practically, this means trying to write code in packages and sticking to universal best coding practices such as DRY (I can’t convey this in a post reply, this is a subject of lifetime learning)

  2. be sure that there will always be something faster, better, shinier - you’d do well to pick one way that seems reasonable, productive and methodical to your own personal taste.
    Besides, every new FastBlazingSpeedGodSendExtension.js takes time to learn and per this theory, wouldn’t be worth its salt 2 days later anyway.

as for your last comment on magic packages, why don’t you do some magic of your own?

1 Like