The roadmap looks awesome! Thx @filipenevola!
Is meteor now entirely developed by voluntary community members or will tiny hire some folks to work on the roadmap? Or is this the community-only-roadmap and tiny has its own roadmap?
Edit: Just saw @marklynch post.
Just created a Feature Request on that topic: https://github.com/meteor/meteor-feature-requests/issues/378
So glad to have this roadmap. Very excited for the future of Meteor.
🤦, if there is one thing I was really glad not to find in the roadmap is such a wasteful effort.
I understand you might comprehend your whole project at all times, but for us, having some assistance is always a plus.
Nothing prevents you from writing your Meteor project in TypeScript if adding types helps you comprehend it better.
Just 3 years ago, it was es6 that all the code in the world should have been rewritten to.
Why waste immense time rewriting substantial existing working codebase, while creating bugs in the process, just because this is the current recent hype? What do you get in return for the time and risk involved?
Just wait another 3 years and let’s rewrite it in the hype that will come up then. At least will save us 3 years to actually do something productive in.
If you’ve ever tried to wrap your head around the Meteor codebase, you would know that it Really needs typings. It is massive, full of global variables that are modified in many different places. It is almost impossible to build anything substantial without a lot of guidance from people like Ben who know how it all works together (there was a thread somewhere where he said how difficult it is even for him).
And as it increasingly seems like Tiny is not investing in full time devs for Meteor, and that it will be 100% community driven, making the codebase easier to update in the future by new community members is vital.
The bus-factor for Meteor is 1, if Ben stops, Meteor is in trouble. Types (or just ES6) will help us reduce his mandatory involvement in every PR over the long term.
Where did this claim originate from?
speculation 
Tiny is building a core team to focus on Meteor and I was one of the first hires there, but we also want to rely on the community to continue to contribute to build Meteor into something that the community wants and needs.
We also plan to hire more engineers for the core team in 2020 
And please note that we are already moving forward in many areas.
See the Roadmaps (Meteor and Galaxy) plus many PRs and issues being merged/fixed.
A few examples of important PRs:
We see a bright future for Meteor and that will be possible from the combination of efforts from Tiny and the Meteor community.
This is wonderful news!
Glad you clarified this immediately. There’s enough FUD around Meteor.
Yes, I did read parts of Meteor’s codebase, including the DDP implementation in full, which we extended for special needs of JustDo.com .
Please explain how types are helping to comprehend a codebase. Or how they can help with codebase that had been written before, as you say: “full of global variables that are modified in many different places”.
Or, come up with an actual example where if only you knew that a name such ‘is_first_time’ is a boolean instead of a number - the code would magically start to make sense to you.
Sadly, the problem: “It is almost impossible to build anything substantial without a lot of guidance from people like Ben who know how it all works together” is as long as software development itself, and had never been solved.
Turning to the economical question, that you seems to ignore, what do you think is the effort that will be required from mdg, or the community at large to convert the 100k of lines of code involved in the meteor codebase to TypeScript?
While, I am aware that I am deferring to authority, I am too tempted to finish with:
“I think that JavaScript’s loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.” Douglas Crockford .
I think there is a reason that Typescript is catching on - it does lead to a much better dev experience. And this is enhanced as a codebase gets larger. Meteor built on Typescript would speed up the velocity of evolution to Meteor itself (at the cost of doing the migration, as you have pointed out) as well as speed up the process of developing applications using Meteor.
I , for one, am a big fan of the decision to do this (in spite of being a relative noobie to TS).
The fact that a hype is catching, in the economical world, and even more so in the web-dev world, that is extremely prone to hypes**, isn’t an argument for its validity.
** My theory is that it has to do with the general young age of the cohort.
I think it’s a bit presumptuous to assume that all the devs (myself included) who have tested out Typescript and like it sufficiently to migrate projects over to it, are going through all that effort because ‘hype’ has pulled the wool over their eyes and they can’t actually make a rational decision on whether all the effort and time is worthwhile.
Sure, I can understand it not being for everyone (I’d be interested on hearing your real-world experience with it as well). I myself, after doing all the research have decided to implement only the parts that I feel are useful to me (making the whole thing far simpler and faster). I can imagine diving in deeper over time as my project as well as my understanding of Typescript evolves.
I don’t think it’s presumptuous at all. @theosp likely meant ‘experience’ instead of ‘age’. Because one recognises the arguments for type safety when coming from someone experienced in developing in a type safe language like Java.
I can see why Ben would want TypeScript for Meteor’s codebase, and I’m guessing it’s mostly because many JS developers do not have the experience and discipline typically learned from other languages, and as such pull requests become a pain to check.
JavaScript was meant to be freedom. There’s a ton of other languages if one wants constraints.
Btw, in a recent Meteor night @benjamn motivated his choice for typescript, see these slides onwards:
I’m myself not a big typescript fan in my own projects, but I can see the benefits for writing the Meteor core in this way.
But will it make Meteor easier to grasp? I don’t believe it will. In fact, I think the Meteor framework (the packages under meteor/packages at devel · meteor/meteor · GitHub ) is quite easy to understand. The meteor-tool ( meteor/tools at devel · meteor/meteor · GitHub ) on the other hand is very complex and I don’t think adding types will change that. What that part needs is a book on how all things work and fit together.
But adding types will give you a lot more editor tooling and confidence when making changes to it. Currently, if I make a PR to Meteor I’m never confident it’s not breaking anything. My usual workflow is doing a search through the code on where certain API’s are being used, but it’s easy to miss some details. This is something I think typescript can improve.
Fair points. Although I remain of the opinion that Typescript’s growth isn’t down to just hype and there are tangible benefits to it.
Your point about checking PRs and Seba’s along making PRs brings up an interesting point against Typescript I hadn’t thought of (but likely has been mentioned before) - if this means that community PRs to Meteor would have to be in Typescript, then that may reduce the number of PRs made?
Meteor being on Typescript would not force any Meteor developers to use TS/JS on their own projects of course. The beauty about this being that the dev experience would be improved regardless.
seriously, you and Douglas Crockford should work on a good, modern typescript project.
“JavaScript’s loose typing is one of its best features” No, definitly not.
Some people think about typescript: “oh, then i need to annotate every variable, write classes and interfaces? Why not using java then?”
This is wrong. Typescript embraced features from functional programming like type inference. You don’t nee to annotate as much as you think. It’s the people coming from java or c# that overuse types and try to write everything in old-school oop-code.
My personal advice: Lern functional patterns and you will love types. and: don’t use classes! *
*(unless you know what you do)
i totally see why ben would want to add typescript. Just look at the codebase of some parts of meteor and you will understand.