First of all, I want to make my point more clear: It's not changing from one language to another. The key is bringing strong typing system into current JavaScript code. That's what TypeScript designed for.
Otherwise it probably > reduces the willing of contribution. Thus a simple language might be > better, suppose they do not know them well. Only if our developers say so. About this point. I want to quote what author of vue says in his article about rewriting vue with TypeScript [1] "The codebase is also now written in TypeScript. Although this will make proficiency in TypeScript a pre-requisite for contributing to the new codebase, we believe the type information and IDE support will actually make it easier for a new contributor to make meaningful contributions." 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? It will be merged to master only when all the codebase are written in TypeScript. 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. I think TypeScript has shown its relibility since it has been working well in a bunch of large project, like Angular, for a very long time. > Program language does not determines how good a program is. > The program design, the understanding of requirements, the testing work > does A good language help us write a good program. It reduces the possiblity of having bug in collaboration. Especially when wen need to grow our community. And the design of code are heavlily based on the feature of programming language. [1] https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf On Tue, Oct 29, 2019 at 11:50 PM SHUANG SU <sushuang0...@gmail.com> wrote: > 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 > > > -- Yi Shen Apache ECharts(incubating) PPMC
