Thanks! This will be a hell of a help.
An application.json file. Basically all the .meteor/* files, but in JSON format.
3 Likes
I would like the code under Meteor.isServer not to be served to the client
5 Likes
There is already a github issue about this. It is planned to do dead code removal in the client build, but it probably won’t make it for 1.3.
1 Like
Good, didn’t know about the issue
I’d like to have galaxy to be able to be plugged to my own dedicated server (I prefer dedicated over AWS and mongolab) - to get all the metrics and logs and stuff.
Also:
- webpack-style hot module replacement,
- incremental app loading (don’t know if it’s already in 1.3),
- configurable bundling of production code - like I ask here
3 Likes
- Better support for sharing data across Meteor apps. For example, we scale our Meteor apps using Docker containers. Further, we separate our core app from our search app (microservices using Meteor), and users remain logged-in across all apps. It’s a pain sharing authentication data between each app instance. It could be that I’m missing something. In that case, please fill me in.
- A complete overhaul of Atmosphere. It is terribly slow and sometimes doesn’t even load. There are far-too-many defunct or incomplete packages that appear in the search results. Most developers don’t have the time to revise all the code for every single one of them. Further, I believe there needs to be a Contributor rating system or similar. One reason being, the documentation for a lot of the packages is too vague and not good enough. The stars don’t do justice.
- Upgrading Node. It really is about time. Even if it is v4.x.x LTS to start with.
- Use Promises and ES7 async / wait instead of Futures / Fibers.
- Remove the allow and deny rules.
- Reactive aggregations.
- React Native integration.
1 Like
As has been said a few times. This would be a really nice way to improve the ecosystem.
I believe this is on the roadmap for post 1.3. There are some compatibility issues that will have to be sorted out, but LTS version is the target.
While I don’t care much about that on the server (and it is nice that fibers produce linear code without having to think about where to put await) yes please for client. I would love to see methods and subscriptions overhauled to return a promise!
Just meteor remove insecure and they’re gone for all intents and purposes. As long as you don’t use an allow rule, everything is denied. It is planned to remove those in the near future though.
Yes please!
Great if it is done, i am using webpack for this & autoprefix, add post-css etc. Meteor does need a way to manage css/scss
1 Like
+1 for async/await !
1 Like
Sorry to be the party pooper here, but what Meteor really needs is a consistent strategy.
In the last years, there’s been so much growth and change, and not everything was managed well. Things like MeteorPad just disappearing overnight, taking a huge amount of code samples with it.
Same story with Velocity. First, announcing it as the official testing framework, then unceremoniously dumping it in favor of a half baked homemade implementation in Meteor 1.3.
Similarly, Iron Router was supposed to be the “official” standard, suddenly, now it’s FlowRouter, which is arguably worse.
Now, Blaze is being downgraded to a “community supported” project (in other words, “we don’t have money to spend on this”). Is Meteor just going to be another backend solution for building React/Angular apps? If so, what’s the point? If it’s just about those two frameworks, why would I even choose Meteor in the future?
MDG has worked so hard to build momentum for this project, and now that it finally has gained some traction, it feels like it’s just about to evaporate into a cloud of “me too” buzzwords. Which is sad, because there are some really cool things about it.
When I first started working with Meteor in 2014, it’s strengths were simplicity, (somewhat) consistency and ease of getting started.
With Meteor 1.3, it seems to be trying to appeal more to enterprises and React/Angular lemmings. Gone is the ease of use (using another view layer requires installing extra packages and a significant amount of setup). Gone is the simplicity, instead of just getting started, you now have to decide between Blaze, Angular, and React. Soon, we’ll have support for other DBs, and then there will be even more choices to make. Sure, some of you will say “but it’s backwards compatible, so you can still use it the ‘old way’.” — Sure, but that’s getting increasingly buried under all the new efforts to make it appeal to big enterprises.
Just my 2 cents.
3 Likes
ES6 modules has certainly made Meteor much more complicated, but it’s for the better in the long run. Though what’s missing now are things that would make it easier to work with ES6 modules. e.g. auto-import functionality. It would be great if there was an IDE that could allow you to easily import a required module (just right click on the unresolved variable), which is what Visual Studio has had for C# for years. Visual Studio even knows which imports are unnecessary that you can remove.
More generally, what’s missing from JavaScript / ECMAScript is a fix for imprecise decimal arithmetic. e.g. they need to make 0.1 + 0.2 equal exactly 0.3. The imprecise arithmetic makes programming for monetary / financial / e-commerce applications much more tedious and laborious. The problem was fixed in Java and .NET around a decade ago (with the BigDecimal and decimal data types). Is it ever going to be fixed in JavaScript / ECMAScript? It’s obvious that apps that do monetary calculations will continue to grow into the future. Instead a lot of time has been spent on trying to make code syntax a bit shorter, which is OK but (arguably) not as important. Maybe it’s just too difficult to make 0.1 + 0.2 equal exactly 0.3.
2 Likes
I wish Meteor was just more stable and reliable.
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.
I think MDG built something that is AMAZING.
Then they second guessed themselves.
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.
2 Likes
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 )
Other than this, BTW, I love meteor 
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.
2 Likes
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.
5 Likes
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…
2 Likes
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…