Just checked - they didn’t drop Coffee. They unofficially said that they think of it 3-4 months ago and since then, nothing happened.
Manuel:viewmodel is Coffee too. 
2 Likes
Is it? Yeah, so ViewModel & BlazeComponents, then… they’ve been adopting the language and patterns used in Atom. Another missing piece would be an Atom DDP package; but I think that might exist already.
An MDG authored Visual Studio integration would be awesome (something akin to what you get in WebStorm with the ability to debug and pause execution). You can get all the important features of Visual Studio in the free versions now, and in my opinion it’s still streets ahead of the other IDEs, so that combined with Meteor would be killer.
It would also make it far easier to tempt dot netters into trying Meteor. I know that we would have tried Meteor a lot sooner if we could have just installed it as an extension and then chosen a Meteor project as an option in the template explorer.
1 Like
Well, Meteor Snippets made it into Visual Studio Code ecosystem about three months ago. It’s a start. 
https://marketplace.visualstudio.com/items?itemName=jmlv.MeteorSnippets
1 Like
Tones of video tutorials to go with the guides 
An “interactive” guide would be pretty awesome too.
SWEET. That’s going in like, all the apps.
4 Likes
My sentiments exactly. As soon as I get to work tomorrow I am going to be doing meteor add simple:dev-error-overlay to the 5 projects our team is active on! Like, first thing!
2 Likes
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