This looks very promising but as I was reading though it I was expecting to see some new Tiny devs. What does the current staffing look like? Will Ben still chip in when he has free time or is he finishing this task and that’s it? Will we see some fresh faces ? Or will it be 100% community ?
21 Likes
I am still holding out hope that Tiny will pay what it takes to keep Ben, his knowledge of the project is super valuable. And if not then the knowledge transfer from him to the community for now and then the new dev team when they join the project should be priority 1. We could create architecture diagrams, maybe record screen shares where the project is described in detail, things of that nature. If anyone else has ideas for this effort please share them
14 Likes
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
1 Like
So glad to have this roadmap. Very excited for the future of Meteor.
9 Likes
🤦, 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.
1 Like
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.
2 Likes
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.
9 Likes
Where did this claim originate from?
3 Likes
speculation 
5 Likes
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.
25 Likes
This is wonderful news!
5 Likes
Glad you clarified this immediately. There’s enough FUD around Meteor.
2 Likes
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 .
2 Likes
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.
4 Likes
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.
2 Likes
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.
2 Likes
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.
11 Likes