Migration from CoffeeScript

[ghost]

[j-f1]

I’m in favor, but I’m not sure how necessary this is.

[simon04]

A pull request is welcome!

but I’m not sure how necessary this is.

This.

So far, only 4 commits to the app code originate from non-members: https://github.com/freeCodeCamp/devdocs/commits/master/assets/javascripts/app

[ymeine]

Would TypeScript actually bring a real added value (higher pros than cons) over JavaScript?

What was the initial motivation of using CoffeeScript over JavaScript and would it make sense to use TypeScript to cover the same requirements, instead of pure JavaScript or the current CoffeeScript?

I'm honestly giving feedback based on an experience in a team collaborating directly with the Angular team, working around Angular for promotion/support/development inside a 10K people company: TypeScript sometimes (often maybe) brings more struggles to us than it solves. We are experts in UI web frameworks, it's not that we don't know how to use it.

The maintenance and community are important criteria to make a choice, but clearly not the main ones. Motivation should arise from a "personal" (to the project) requirement, something technical or things like comfort in coding for instance.

So if TypeScript would actually brings something valuable, and not be just chosen because it's more hyped and widely used (otherwise why not switch to Angular too? Spoiler alert: we're trying to move away from it because it's heavy and over complex while simpler, more logical alternatives exist).

I'm just bringing feedback though I'm not contributing to the project, just following it. It will never be doomed if you choose TypeScript, but it might not be a good thing either, just make a more considered choice.

[ymeine]

Sorry, but I didn't say it was just a hype. I said it is sometimes adopted just because it is popular, which is an important difference.

Regarding your points:

• for refactoring it is true, it is a strong point of TypeScript (static typing systems in general)
• easy to contribute: can be if it is just for consumption of the APIs. To add new ones, typing can sometimes happen to be quite cumbersome. It goes against the flexibility and conciseness of the dynamic aspect of JavaScript. Something which could have been expressed in docs and validated in tests, will now have to be expressed in static types and sometimes it is tricky. But I talk from a library developer perspective, where being generic and compatible is key, so it is even more difficult
• for warnings in production, this should not happen if the product has proper tests, commercial and viable products already existed far before TypeScript existed. It is another way to help development, but not a reason to think there would be warning in production otherwise.

TypeScript also brings a potentially slow compilation step (though that's always relative) and a maintenance regarding tooling and its configuration.

In the context of DevDocs though, the "negative" points might not be that important. Once again I just wanted to share my experience to make sure it's not "switching just to switch because other switched". For some projects, we went by default with TypeScript because we were used to do that in other projects, and we regretted, since making highly flexible APIs became a nightmare (or we would use any most of the time and lose the purpose of TypeScript)

[ghost]

Also, I don't favor TypeScript particularly, but migration of Devdocs from CoffeeScript is better.

My point is migration from CofeeScript, even if it's to just plain JavaScript

[ymeine]

Ah yeah I didn't ask why CoffeeScript was an actual issue? I'm curious about the actual, rational motivations (myself I'm using LiveScript in personal projects)

The main points I see are:

• if migrating to something closer to JavaScript, avoid some learning curve for users who would be new to the language (though TypeScript can sometimes have a stiff on)
• if maintenance is not high, it's more likely that CoffeeScript won't integrate new features from JavaScript which are directly available through the syntax of the language (this is for instance the case for LiveScript with ES module import/export which are not built into the language)

[ghost]

Sorry for confusing everyone about typescript, i just added as a suggestion, migration from coffee to javascript itself helps new contributors and mainatainers alike

[ymeine]

I was not referring to TypeScript in particular in my latest question (it's not because I used it as an example of learning curve that it means that it was the main topic), I was focusing on why getting rid of CoffeeScript would help contributors and maintainers (with properly explained arguments) I hope my statement is clear enough this time

[dimas-cyriaco]

Just my 2 cents: I think migrating from CoffeeScript wound be a good thing for the future of the project. I myself was thinking about contributing to the project, and I probably wont because of CoffeeScript. It's, unfortunatly, just not a usefull skillset to acquire nowadays. I (and i imagine that's true to a lot of people) don't want to spend time learning something that would not be usefull otherwise.

Just take a look a this graph:

And i'm not saying to use Typescript. Vanilla javascript would be fine.

I understand that this is a difficult decision for open source projects, but I think, to keep the project alive, you have to modernize the stack. If you don't, five/ten year from now noone will be willing to touch the codebase, and peogle will just reimplement the features in another project. And that would be a waste.

[simon04]

People wanting to work on this task might want to try the following tool: https://decaffeinate-project.org/repl/

[PATHAKABHISHEK]

Can I work on this task ?

[jmerle]

Someone already tried to do this a few years ago: rockon999/devdocs-es6 and the relevant Gitter conversation.

As for my 2 cents (I'm one of the people who has done extensive work on the CoffeeScript code): while I also prefer TypeScript over JavaScript over CoffeeScript, this issue would take quite a lot of time. I would certainly not label it as a good first issue, because:

• There is a lot of CoffeeScript code, almost 6,000 lines in 76 files according to cloc.
• The CoffeeScript code contains no documentation and no automated tests and you'd ideally not want to change any of the existing functionalities or add any new ones in this conversion, so you'd need to do extensive manual testing.
• When converting to TypeScript instead of JavaScript, you'd surely want to make use of TypeScript's types and ban the use of any unless there is no other option. Considering the current codebase isn't typed, this will take quite some time too.

I do however agree that moving away from CoffeeScript to something more mainstream may cause more new contributors to contribute to the project.

[ewlsh]

I'm still around and interested in this - if I recall correctly the major blockers were the build pipeline being quite challenging to update as it was a semi-custom mix of components from the Rails-adjacent stack that were not receiving a lot of community support at the time (and this was ~2 years ago)

[ghost]

https://dropbox.tech/frontend/the-great-coffeescript-to-typescript-migration-of-2017

[ewlsh]

In terms of not doing this in one gigantic de-coffee like I prototyped I think the following needs to happen:

• Use a defined module system (preferably ES imports) instead of the custom object-based one.
• Get rid of Sprockets. Sprockets 4 supports babel transpiling and ES6 but it is a rather inflexible frontend build system. Luckily it is at least somewhat maintained now, but even so I don't think Sprockets 4 is the best choice.
• Replace Sprockets with Webpack and enable CoffeeScript/JavaScript interop
• If TypeScript is desired, I would start with a permissive TypeScript configuration which allows a lot of "any" assumptions. From there, convert to a more strict TypeScript configuration as the project progresses.

As a workflow for converting CoffeeScript to TypeScript:

• Use decaffeinate
• Remove CoffeeScript "quirks"
• Add any necessary typing

The big hurdles are going to be the custom object-based imports and stripping out the Sprockets-dependent code.

[ewlsh]

You could, theoretically, do a massive decaffeinate eventually...

But I think getting the import system and build system issues resolved first would make it significantly easier and less prone to breakage.

[bsides]

It's been a while, is this still relevant / wanted? I could start working on it if Typescript or pure Javascript is decided. Or event the build, we could use something easier like vite to build the whole thing if possible. Thanks!

[simon04]

Yes. I'd prefer vanilla JavaScript over other languages that require an additional build step.

My PR (which is linked above) is half-finished, but is somewhat stalled for the remaining app.Views since JavaScript constructors must call super() as the first statement, and in CoffeeScript plenty of init stuff happens beforehand.