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
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.
1 Like
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.
5 Likes
My feeling was always that people run away from Java and the likes to actually escape from “old-school oop-code”. Maybe that’s just the devs you know/worked with?
Personally, as a Java developer, I could never understand why some JavaScript software was bent and contorted to use inheritance and taxonomies the way Javas does, when the language itself gives you far more elegant ways (i.e. anonymous functions with closures). Then it turns out the developer never wrote a single Java class but they were taught OOP with Java is the best way and thus should be used no matter what.
The simplicity with which you can pass functions around in JS is absolute freedom! I’m sure every decent engineer with a C++ or Java background currently programming in JS will tell you the same thing. Otherwise why would they be developing in JS !?
Ben’s stance is perfectly understandable (thanks @seba for the reminder - watched that but forgot the exact reasoning). I don’t think anyone with an idea about good software development practices would reject TypeScript based on lack of merits. The argument, from what I understand, is simply about return on investment. I myself think on the same side of the fence: with so many priorities, and also with the expectation that there will be more contributors, does it look feasible to put other updates aside so that the Meteor codebase can be rewritten in TypeScript? Then, tell everyone that PRs should only be TS? Even the effort required to plan which parts should be rewritten first is pretty significant, as I’m sure you know.
More on the note with which you open your message above, ES6 is perfectly suitable for a modern functional programming project; TypeScript is not strictly speaking necessary. When exploring it to see if we should make the switch, I found that many of the problems TS is supposed to mend are actually already fixed/highlighted in our quite decent IDE (which has a ton of plugins) and ESLint. Surely, TS has additional strengths, but the ultimate question is, are they worth the cost?
Here’s an excerpt from a good and well researched article on the subject, from a respected author:
“Most TypeScript advocates don’t seem to have a good understanding of what TypeScript is competing against. The development tool choice isn’t TypeScript vs native JavaScript and no tooling. It’s between TypeScript and the entire rich ecosystem of JavaScript developer tools. Native JavaScript autocomplete and error detection gets you 80% — 90% of the benefits of TypeScript when you use autocomplete, type inference, and lint tooling. When you’re running type inference, and you use ES6 default parameters, you get type hints just like you would with type-annotated TypeScript code.”
There is a lot more in the article than just the idea in the excerpt, so I’d encourage anyone evaluating TS for an existing, large project with multiple contributors to read it.
5 Likes
I found the cost very low, typescript is already supported by deno and maybe node will also support it nativly.
I know elliots article, but i found his argument that the tooling support of native javascript is already near as good simply not true. Of course, his example with object literals is true and a good practise, its not true when you need to transform objects. In particular UIs are basically big transformations from data to interface (e.g. a dom): you get data in (e.g. from graphql or rest) and transform it to some UI. In these cases, type annotations are very important (which you can auto-generate with apollo, which is awesome).
as for the meteor-codebase: i just did one small pr to the code-base where i needed to add an option to the meteor tool. It was super hard, because similar config-objects where passed around, desctructured, reconstructured and passed along. I had to add my property to multiple places. And it was hard to know where to add these. Harder than it needs to be. With type annotations, this would have been much easier. Also i think, thinking in types leads to better and simpler code, it makes you think more about what actual entities you deal with in your application. Said configuration for example was just one entity after all, but slightly modified on multiple places.
2 Likes
Maybe there’s something I’m missing. Are you saying that rewriting an existing JS project in TS has a low cost? Because was my assertion was to the contrary. Everything I’ve learned until now tells me that rewriting Meteor using TS, as of now, means we’ll have to wait a long time for other much needed improvements.
I understand your argument for PRs being more difficult, and not being a contributor to Meteor, I trust you know better than I do. But wouldn’t you rather have Tiny putting all the efforts into Galaxy for a while, which is a much better guarantee that Meteor will be here for the long run? There will be a time when Meteor.ts will come to be, no doubt, but I’m of the opinion it shouldn’t be a priority today.
On a different note, I guess I never got bitten by types when transforming data into DOM because we perform an automated schema check at data insert (in DB) and then at data rendering (in the component) reusing the same schema, which typically lives in a js file shared between client and server. Yeah, TS would be more helpful documentation wise in a case like this, but I find reading a JSON schema easy and not a huge downside for now.
No doubt TS is very helpful, I’m just not entirely sure if it’s worth converting large, existing projects.
1 Like
to be fair, i had new projects in mind. Using TS in a new project is easy and i would strongly recommend that.
For existing projects, its also not a big effort:
- make sure that your build-pipeline supports TS
- configure it so that both js and ts works
- start refactoring by renaming files to .ts
- every js code is also ts code, so you will just get warnings about missing annotations, but you already get type inference in some places and your code still works
- in case of literals, you can also derive types from that (using
typeofoperator), which can be handy for config objects or similar
to give an example, here is a (unmerged) PR of mine highlighting a problem with the current code base: https://github.com/meteor/meteor/pull/10605/files
the change is absolutly trivial, but notice how many times i had to add the allowSettingsFromEnv property. It looks trivial, but it took me some time to find out how this config object was passed along. If i’d had a type somehwere where i could define the shape of the config objects and added the allowSettingsFromEnv to that type, i would get error when i forgot to reassign this property.
Adding a type there would be very easy to do. i am sure there are similar cases. To be honest, i was a bit put off by the codebase to do another contribution and i think Typescript would help meteor to get more contributors
4 Likes