Yeah, React Native is a hot topic!
Then there’s the GraphQL thing, I don’t know if we want to talk about it again but I’m always happy to give more info:
Then there’s chatting with @debergalis about open source stuff.
4 Likes
The show numbering thing has me confused as hell lol. Listening now 
3 Likes
I guess it’s inspired by NodeJS versioning 
13 Likes
It’s because simplecast doesn’t support SemVer for episode numbering…
3 Likes
“Meteor gives you an competitive edge in building out features quicker.”
BOOYAH - hit the nail on the head with this quip @sashko. I stuck around with Meteor not because it could handle 2 million concurrent users, but because how quick it let me build features that are more than fast enough for the vast majority of my projects.
13 Likes
I’d like to hear MDG’s thoughts on @gadicc 's Hacky Hot Module Replacement, the implementation is almost comically hacky but it achieves something really important and useful, and @benjamin said he’d like to see something like it in 1.3.1
It’d also be nice to hear about Meteor for Corporate Developers since I fall into the corporate developer category and would like to know what Meteor’s plan is to move from something that’s viewed as “only good for MVPs” to a complete development platform for more experienced of developers
5 Likes
If @benjamn has time to come on to talk about that in between all of the hard work on releasing 1.3, it would be awesome!
3 Likes
I’d really like to hear about how/when the Meteor Guide is being upgraded to Meteor v1.3, as I think a lot of people will need a hand getting to grips with the new NPM “way”, along with some more React “best-practices”.
4 Likes
Talking of the guide, I’d be interested to hear:
- How the guide gets maintained going forward - has some of the team that wrote it now moved onto the new data layer project?
- How will the guide deal with React (and Angular… and I suppose Angular 2) going forward, will it be like MSDN where each example has a version for each language (Blaze, React, Angular). That seems like a maintenance headache, but with React becoming first choice for a lot of people here it seems like featuring Blaze alone in the guide might limit it’s usefulness for the UI sections, especially as newcomers (like us) are choosing React from the outset.
- When will the additional forms related content be added to the guide?
I’d definitely be interested to hear about that too
1 Like
The answers to these questions are very simple, though:
- There will be at least 5 new articles for Meteor 1.3, along with updates to the existing articles to fit the new module approach:
- App structure - this will tell you how to use the new module feature
- Code style
- Testing - how to use the new
meteor test-appfeature that works with modules, and other testing topics - React - we’re going to get rid of the separate React guide
- Angular - written by @Urigo to make Angular more of a first-class citizen
- We won’t have code samples for each frontend at this stage. Ideally you can read, for example, the React article, and that will tell you how to apply all of the principles for React specifically. In future versions that might improve.
- Forms aren’t coming in this version, because we don’t have a good example app, or a way to validate our ideas against real form problems in the field. So for now we aren’t going to have it because we aren’t an authority on the issue.
If you think it’s still valuable to basically say the above in the podcast, we can do it. But I think the other topics have a more interesting discussion.
2 Likes
I think you’ve covered it all @sashko, thank you, so yes I agree the other topics are more interesting
1 Like
If you really like reading stream of consciousness, you can always parse it out of the meeting notes:
https://github.com/meteor/guide/blob/master/meeting-notes.md
2 Likes
Great news! @benjamn said he can come on the podcast tomorrow and drop some knowledge about the hot module replacement! Super pumped.
Should be a star-studded cast tomorrow, with @debergalis joining as well :]
6 Likes
Do we want people to only import and not use globals? In which case do we need to export every symbol in the API, so you can e.g. do import { loginWithPassword } from 'meteor/accounts-password? In which case should we mark the old APIs as deprecated? (see https://github.com/meteor/guide/pull/221/files#r51830171)
Please no. Make us import externals, but let Meteor things be global, for the love of Merlin. 
We’re going to recommend importing everything, but everything works the same way it did before. You can still use the Meteor things from global variables.
In other words, this is a new feature, not a breaking change.
2 Likes
OH MY! We will have a big crowd in this show! Having @debergalis , @benjamn , and @sashko . 
Everyone be prepared for a 2 hour show LOL
10 Likes
For those that don’t like importing things all the time, you can always expose things to the global scope in some kind of /lib/globalize.js file:
import moment from 'moment';
import { PropTypes } from 'react';
global.moment = moment;
global.PropTypes = PropTypes;
3 Likes
Note that in the future where Meteor has dead code elimination, making everything global to get around imports will not let you use that feature at all, since it all depends on the build tool being able to analyze your dependencies.
4 Likes
Oh that’s good to know. You’re talking about rollup.js right?