For example I got an error similar to the one described here. This error causes that a clients website is not reachable for a lot of its customers anymore.
For me personally it is not much important that every new short term hyped frontend framework is supported and every ES7 feature will be available direclty.
I also think disccusion like here are very imortant. The fact this is discussed a thousand times could be a sign there is a need of a better (and maybe paid) support for the whole thing.
In the startup world, you are suppose to listen to customer feedback. I think MDG got a little caught up in the feedback from hipster programmers and just second guessed themselves. That or they were beginning to get short on financial runway, and needed to think more short-term⌠they couldnât âwait it outâ to see if the âold meteorâ would catch on⌠not their fault. Thatâs just the way the cookie crumbles sometimes.
Iâm also not saying the current meteor isnât good. Just saying itâs a completely different business hypothesis.
What I am missing, comming from a LAMP-environment, is a simple way of deploying. Whoa! Stay with me I read a thousand read.meâs on this, I will get there, but really? When you are used to just syncing with a server, importing (if you want to!) as MySQL dump, and re-pointing Apache to a new dir, it is⌠maybe not complicated, but messyâŚ
Let me try to explain: most Meteor hosting is not application hosting - as I understand it. You will need to add a database hoster as well. Huh. Ok - why? That cannot be faster then hosting in one data-center, can it? It makes the proces a) less clear and b) more expensive. (With even the expenses not clear.) Then there are a lot of companies that will not host your application, neither your database, put perform some kind of magic, apparently worth money, but what it is they are adding other than âone click deploymentâ after a few days of study what is really happening, I do not know.
There are plenty of script, utilities, deployment strategies out there. But choosing and understanding what it is you are choosing between can be really bewildering. I think it is a shame that even Galaxy is more complicated than should be needed: "Galaxy doesnât provide a database layer, you will need to host one yourself or use a third party. " Why? The whole fun for me started when it was clear that meteor has a near-invisible data layer on the client. Until you want to deploy it, apparently, and then I need a whole separate company to host this? [The funny thing is - I have yet to find a good explanation for this - really!]
Well, as you understand by now, I am on the verge of publishing my app. And getting a bit frustrated by this muddy thing with 2873465 possibilities, and none quite as easy as: press here -> sign up -> sync app -> get rich.
I would forgo the last step as a requirement, but I would love the rest to be as simple as that. (oh, and AWS Amercia is out of the question for me, so there you are )
Couldnât agree more â we went from prototype to production-ready in a couple of months, and have paying enterprise customers using already.
As money flows in, we are considering helping finance the âold wayâ as frankly, it really surpasses when it comes to speed, features and reliability.
Thereâs a very good reason for it, itâs that MDG can do a much better job with Galaxy if we focus on the hosting part alone. There are companies that offer just database hosting, and they do it better than we could.
Since the database providers we recommend are in the same AWS regions as Galaxy is, the latency is negligible.
Galaxy doesnât offer database hosting (yet) for the same reason that your doctor doesnât fix your cavities. You go to the dentist for that.
That said, Galaxy may add MongoDB hosting in the future, when and if it makes sense.
Meteor should have an integrated router (FlowRouter should be integrated imo).
I believe it also needs to regain itâs âuser friendlinessâ. 1.3 got more complex, tutorials got more complex, and thereâs less time spent developing & more time on markup/imports/etc.
I believe it would be very easy to regain Meteorâs user friendliness. Just need some better tutorials, and tighter integration for imports/load orders/etc.
So much time lately is spent on shiny new features & linking us together with the JavaScript world. But I would love it if Meteor âinvited JavaScript to experience the Meteor worldâ. If that makes senseâŚ
I have to agree here. You still see people starting projects with iron router, which means they look at IR docs/tuts, have subscriptions at the router level, etcâŚ
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.
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?
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)
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!
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:
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.
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 )
I read a thousand 
