I am afraid I do not agree with it. I like TypeScript too, but do not support to refactor echarts to TypeScript, at least do not support to start the refactor work now, until some more strong and reasonable arguments or points appear. Basically, I think it brings little benefits but has some downsides and brings heavy cost of a big surgery.
*[About the bugs and issues]:* The bug [1] can be find by TypeScript. But bugs like [1] are very rare since echarts be born. And even if TypeScript can make sure the type checking for interfaces, it still can not ensures the content of the parameters is correct. Essentially, test cases and regression testing is what we need to cover this cases. If test cases cover them, this kind of bug can be found, no matter JavaScript or TypeScript is used. Testing work is annoying but worth to take the time, comparing with the heavy workload of refactoring to TS. Most of the typo issues in [2] are either: - Typo in comments, which are nothing to do with the programming language selection. - Spelling problems but the logic of the code is correct, where TypeScript does not help. - Spelling problems and cause buggy code, which can be found by code checking tools like ESLint. TypeScript is not necessarily needed. In the experience of maintaining echarts, most of the issues or bugs (in GitHub) are about the logic itself or about understanding of the user requirements or about program design. Changing to TypeScript can not resolve these issues. TypeScript can help to find some of grammar and coding problem when programing, but very little. And in most cases the code checking tools is enough for JS dev in echarts. I think we should better write more test cases to cover the features rather than considering change a programing language to improve the quality. *[About the developers]:* The user of echarts contains not only the well-trained "front-end developers", but also lots of developers from various technical background. echarts is just one of the libraries in their system or in their big work. If they meet some problem, some of them need to check the code to debug, some of them need to modify the code to fix some defects. And then they might wish to contribute them to echarts. I think we should not bring more burden in language learning or make them hesitate about the detail of the language features. Otherwise it probably reduces the willing of contribution. Thus a simple language might be better, suppose they do not know them well. Yes a programmer who have the basic knowledge of Object-orient programming may understand the code what ever the code write in JS or TS (in echarts case), but they probably have different willing to modify the code and feed back to echarts if they have to take lots of time to learn a language. In addition, JavaScript has been developing for twenty years and might be a little more worth of the time to learn it for a non-front-end developer. *[About the steps]:* > 1. The easiest part, create a new branch and renaming all the files from > .js to .ts. If everything goes well, we can use TS compiler to compile > these files already. > 2. Add typings for our fundamental modules. Like `List`, `Graph`, > `graphic`, `View`, `Model` etc...These modules will be used in almost all > components. > 3. We can add typings in our components, which has the most of the logic > code. > 4. Adjust our code structure to be more TypeScript. I am afraid I think the progressive way is not practical. The reason is: we can not prove it do bring benefits to echarts if just making little changes, but bring the code to a mass state in a long duration. Now we have the code standard [3] code checking based on JavaScript, which is the guide when adding or modifying code. If part JS part TS, how to guide the contributors? If we think that some work can be handled in future, if it is not urgency, it will probably not be handled for long time, where the code will keep part JS part TS style. Things change fast. *[About the goal]:* The goal of echarts is to build a good data visualization lib. I think we should keep focusing on that. Change a language is a huge work. If making a thorough change, it will bring lots of bugs. If only changing a little, not worth to do that. So we need to think of them carefully. If a language feature is reliable (the spec endorse them) and benefit echarts a lot, we might use them. If it is not enough, we can wait. Do not need to be in hurry. Program language does not determines how good a program is. The program design, the understanding of requirements, the testing work does. Now that there are so many issues and features need to be handled or fixed, I do not think changing a language is an important thing at the current stage. We have been using JS for more than four years in echarts. I still can not convince me that if we change the language with a great cost, what it really resolves? Is it really need to change a language to resolve them? [1] https://github.com/ecomfe/zrender/pull/480 [2] https://github.com/apache/incubator-echarts/search?q=typo&type=Commits [3] https://echarts.apache.org/en/coding-standard.html Thanks, ------------------------------ Su Shuang (100pah) ------------------------------ On Tue, 29 Oct 2019 at 15:08, Yi Shen <shenyi....@gmail.com> wrote: > Hi, > > It's a very big topic and may sound terrifying. > > I started this discussion because I'm using TypeScript a lot recently. And > realized a strong typing system really helps a lot when writing the code. > So I'm thinking about if we can refactor our code with TypeScript. > > Of course, there will be a lot of work for the whole codebase. So I > suggested separating the process into 4 steps, and hopefully, this can be > done progressively: > > 1. The easiest part, create a new branch and renaming all the files from > .js to .ts. If everything goes well, we can use TS compiler to compile > these files already. > 2. Add typings for our fundamental modules. Like `List`, `Graph`, > `graphic`, `View`, `Model` etc...These modules will be used in almost all > components. > 3. We can add typings in our components, which has the most of the logic > code. > 4. Adjust our code structure to be more TypeScript. > > Personally speaking, the first 3 steps the most needed. It looks to be > easy, but during the process of adding typings. We may need to rewrite a > lot of code to meet the purpose of strong typing. > > Here are some pros and cons of changing the code to TypeScript I can think > of: > > Pros are mostly come from strong typing: > 1. We can avoid bugs like argument mismatching [1], variable naming typo > Bugs like these easily happen when we are refactoring the code. I can find > a lot of commits about fixing the typos [2]. > 2. Developers know what the interfaces look like of each module, which > makes it easier for them to contribute. > 3. VSCode has a really wonderful intelligence on the TypeScript. I enjoy it > a lot when I'm writing TypeScript. > > Cons: > 1. Honestly speaking, it's a lot of work. And it's hard to keep the > TypeScript branch updated with the master branch before merging. > 2. Developers may need to learn TypeScript. But I think it's not a big deal > comparing to learning how echarts works. > > At last, as I said first, the word refactoring may sound terrifying. But I > believe it worth it. I hope we can all enjoy writing our code with the help > of excellent intelligence. > > Regards > > [1] https://github.com/ecomfe/zrender/pull/480 > [2] https://github.com/apache/incubator-echarts/search?q=typo&type=Commits > > -- > Yi Shen > Apache ECharts(incubating) PPMC >
