Howdy Meteor Forum peeps, It is time to plan show #6!
I think we will be getting @debergalis on as a guest for part or all of the next show! We will be touching base on the How Open Source is Meteor topic again.
Reply below, let us know which topics are the most important to you from the past week(s)!
Update
Show #5 is rockin… we are getting some great feedback and encouragement. @sashko dropped some great bits of wisdom in the last show and we will be making highlight YouTube videos of them.
Thank you all for your support and feedback!
About TRANSMISSION
TRANSMISSION is a weekly podcast/vlog covering the most important topics to come out of the Meteor Forums. Each week I need your help to pick the most relevant forum posts for @sashko and I to discuss in deeper detail. We will pick 2 of your topics to talk on, Sashko will pick the another two. I will be your investigative journalist and Sashko will be our “inside contact”.
It is our hope for this show to becomes a weekly staple for all Meteor developers to get the inside scoop.
“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.
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
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”.
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
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-app feature 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.
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.