What is Meteor missing?

Well, you can always get the “old way” back by putting your code in the client and server directories instead of imports, and everything will be auto-imported for you (with the usual caveats about load ordering).

I generally think that’s an improvement to support both, and allow people to use it both ways (and combining them too!).

FWIW Rails also auto-imports everything (except the lib folder), and it hasn’t hurt it’s popularity in the slightest. Also, in years of working with Rails, I’ve never had an issue with load order – but then again, Rails is much more opinionated about its directory structure than Meteor.

What bugs me is perhaps that it feels like with Meteor 1.3, the “old way” may still be supported but it feels deprecated, since the guides and tutorial recommend using the “new way”. That might scare off a lot of new people who previously would have chosen Meteor for it’s ease of use especially when getting started.

That’s a JavaScript issue. Not something that Meteor can or should fix. It’s an old and well-documented issue, and there are solutions available. In Meteor specifically, you can use the 3stack:bignumber package.

1 Like

QFT. This x100.

Having a coherent strategy around autoimport is a must. The ES6 modules are fantastic and powerful and a gold-standard feature. However, we’ve traded the occasional intractable load-ordering errors for semi-ubiquitous cannot-find-module errors.

Also, moving a file from one directory to another has suddenly a complicated process. We also need refactoring tools, similar to VisualStudio, so when we move a file, all of it’s import references get updated. Don’t need drag-and-drop functionality. Right-click > move would be sufficient.

And +1 for getting something that improves decimal arithmetic. And TypeScript. How can we help get TypeScript and better arithmetic into core?

Agreed. :confused:

3 Likes
  • React Native
  • Code Splitting (even if broad based - I don’t want to send all my admin templates to the client side end user).
  • ES 7 async/await on client and server, obscuring the older ways to do it (because that seems to be a huge tripping point for people trying to write server code, and it’s a place where code doesn’t run/can’t be written exactly the same on the server and the client)
  • Apollo integration!
1 Like

I do t hink its nice how you can do either way.

But I am in agreement that it “feels” deprecated.

Furthermore, they said this is just a ‘backwards compatibility’ feature and it will probably be removed. That would be very disappointing to me.

That is a big part of what I mean about Meteor’s user friendliness.

TBH, aside from some things with deploying not being as smooth as possible, I am overall very happy with Meteor. There’s not many features past what is on the roadmap that I would really care about being added. (although I do agree with @tab00 , as my stock management project does have a lot of decimal calculations and it does get annoying). I am fine with NoSQL so I’m not so excited about that (although I know many users are).

What matters to me? How convenient Meteor is to use, how fast Meteor is to work with, and how much time Meteor can save for a fully functional web application that has support for real-time features.

Those are the things that made me a Meteor user. I also believe that’s Meteor’s biggest strength. So I hope that part of Meteor will be focused on again in the future!

1 Like

meteor missing a deploy easy system. i have a project finished and i can’t deploy easy, i can’t use google compute engine with grapicsMagick,

a good idea google cloud launcher with grapicsmagick!!!.

another good idea. integration blaze + Macaw scarlet!!! front and back all in one WISIWYG, fast, complex and powerfull (the meteor philosophy)

Funny how the Javascript (not Meteor) issue with decimals comes up again… The simple solution is not to use decimals/floats for monetary calculations, like discussed before on this forum:

And of course what @pandawhisperer sad:

1 Like

Because it’s too hard.
Better to let you struggle with it yourself :wink:

Fast build tool. Professional adoption at scale.

5 Likes

It comes up again because the problem hasn’t been fixed. There are workarounds that I use but I have to write extra code to use them (including replacements for $inc and $sum in MongoDB).

That is not an acceptable fix-all solution as has already been discussed elsewhere in the forum.

It is not Meteor’s fault but I think @benjamn is part of the Ecma Technical Committee 39, so maybe he could think up a proper fix once-and-for-all for a future ES version.

If you are using ESlint (highly recommended), you might be interested in this plugin: GitHub - kriszyp/eslint-plugin-auto-import: ESLint plugin for automatically importing modules

Of course it would be better to have it build into Meteor itself without any setup.

1 Like

Just out of curiosity, could you point me to that discussion? I’m willing to learn more about the issue! (And don’t want to get to much off topic here :wink: )

1 Like

I disagree. Not all applications use routing, and why should Meteor pick the router I should use?

1 Like

I have vented my frustration on many occasions in various threads about the issue. Here are some of them:
The Sad State of Web Development
Meteor for corporate developers
Getting results from aggregation
Do you recommend meteor for financial service…?

That looks interesting. So there would no longer be any need to write all those tedious import statements at the top of each file. Have you tried it?

Correct. You will need to define how undefined variables will be imported via the config. Haven’t tried it myself though. And you will need to run eslint --fix to make esllint add the missing import statements. Which is a bit tedious perhaps…

Hm, we might be able to create a default config for all Meteor core packages. That would save a lot of people time when transitioning from 1.2 to 1.3+…

The funny thing about this is that some random guy has already created a solution for this called DEC64 (repo), and he’s also on TC39 …

1 Like

I know about dec64 but it didn’t go anywhere, though I sure wish it did. Maybe benjamn and doug can team up and push for it to be implemented into ES.

3 Likes

Tossing in my 2 cents.

I would really love to see built in support for AWS dynamo. I know you have just recently started to enable other databases, I think dynamo should be top of list.

Other lower priorities:

Could meteor interact with AWS Lambda?
Create a simplified webhook interface for subscribed webhooks and creating webhooks.

Definitely been stated above, but:

  • ability to turn off reactivity (make it easier. pub/sub is CPU intensive and not necessary most of the time.)
  • support for more databases.
  • fuller mongodb support. e.g. aggregate, findAndModify, batchUpdate (the first two at least are addon packages.)
  • ability to not use certain files depending on the meteor settings or env vars.
  • ability not to use it as a single page app at all times

Rock solid documentation!

No commits that add any change/enhancement to the way something existing works or that add any new feature without rock-solid documentation of the change! And I’m not talking about a mention in HISTORY.md. If it is not a bug fix and it is significant enough to bother making the change in the first place, then the feature deserves documentation at docs.meteor.com.