The new Meteor Roadmap is out

announce
45

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
46

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
47

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
48

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 typeof operator), 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
49

Object shapes are really the benefit of typescript.

A lot of the time in javascript, you’re passing an object full of key value pairs, and if it’s not part of the public API, it’s not documented what’s actually in it.

51

I’d like to add a reliable accounts package for React to this list. I’m currently using https://github.com/royGil/accounts-react, but this is not maintained anymore. Changes in React and changes in react-meteor-data force me to upgrade, but then I’ll have to drop the accounts package, as it depends on react-meteor-data@0.2.26, as discussed here: ReactMeteorComponent and React 16.11.

In my humble opinion, there should be stable and officially supported versions of accounts packages for every supported UI framework, as having an out-of-the-box account system is (at least was?) one of the key selling points for Meteor.

5 Likes
52

I’d like to add a reliable accounts package for React to this list

Hi, can you create a PR in the roadmap adding this item? Are you willing to take the lead on this?

2 Likes
53

This would be amazing.

2 Likes
54

Official accounts support for Postgres / mySQL would be great as well.

55

The bus factor is much higher than 1, since it’s open source. You mean to say that the free-labor factor is only 1 on the main branch. If Ben got hit by a bus, there are plenty of us who could continue on as normal.

56

Hi @filipenevola,

happy to create a PR on the roadmap.

Regarding the lead: tbh, I don’t consider myself as being a “top-notch” React developer, so I don’t think I’m the right candidate to lead the development of such a crucial feature.

57

Still hope this won’t happen. Knock on wood.

3 Likes
58

If anyone who has an understanding of the Meteor codebase could provide even a high level diagram of the codebase, or a few paragraphs to help a newcomer like myself to start to get my head around the project as a whole that would be great. I have forked the repo and have started looking through the code. And will continue to do so on my own. but any help would be really appreciated. relying on a small group of people isnt sustainable for any open source project so getting some new blood would be a good thing, the new people just need to be mentored so theyre ready to help after some time preparing

7 Likes
59

You could also request community maintenance by filing an issue in the Meteor Community Organization repository.

1 Like
60

We’re just talking about a UI for a login and registration for the accounts package, right?

Are we just replicating the blaze one? That should be easy enough to do.

61

I would actually argue that everyone should just build those 3 components themselves and there shouldn’t even be a package to maintain. Way too much hassle…

4 Likes
62

This might be true for pro developers. But I still remember well when I started into Meteor development, coming from a pure frontend background. I was stunned by having setup a whole app including accounts within 30 minutes. If you try to figure this out yourself, it will take you days. Keep in mind there’s a lot of use-cases to consider: login, logout, password reset, etc.

3 Likes
64

Again, I would argue that you absolutely need to take the time to figure this out yourself and understand what’s going on, otherwise you’re playing with fire (and your customers credentials). Having all that stuff set up for you is nice but should only be used with caution for mvps and such, never in production apps.

65

Well, that’s exactly why I’d prefer an official package, built by pros :slight_smile:

3 Likes
66

I would argue that everyone writing this themselves would open more sites up to security issues, because you are now only utilizing the brain of one person rather than the community.

10 Likes