LiskArchive / lisk-elements

⚙️ Library for sending Lisk transactions from the client or server
https://lisk.io/
GNU General Public License v3.0
250 stars 64 forks source link

Implement strict type system #417

Closed toschdev closed 5 years ago

toschdev commented 7 years ago

Typechecking will make the implementation more secure. e.g. https://flow.org

Aimed for Lisk-JS 1.1


Updates: A decision has finally been made for TypeScript. Aimed for Lisk-Elements 2.0

Child Issues

alepop commented 7 years ago

I propose to consider Typescript instead of Flow

alepop commented 6 years ago

My points to use Typescript:

kazzkiq commented 6 years ago

In addition to @alepop, I would like to take some points where TypeScript shines over Flow:

TypeScript on the other hand is at another level, it managed to build a terse language set around JavaScript itself, and extend JavaScript to the point it can compete with mature languages, while maintaining the dynamic features of the JS ecossystem.

The work Microsoft made in TypeScript was surprisingly good (not usual if you take into account their historical open-souce decisions), and by assigning personalities like Anders Hejlsberg to work on it only shows its commitment to the language.

So, back to Lisk. Since we're talking about an (awesomely) huge project, aimed to handle serious money and serious code in form of dApps I cannot think of a better option for the job than TypeScript.

Bit-Shifts commented 6 years ago

The argument of Typescript vs flows totally depends on what you are trying to accomplish. If you are just looking for a strict type system I would suggest flow as this is just a think layer on top of your JavaScript code, where Typescript is a fundamental shift away from pure ES and is becoming its own language. Also Typescript is not out of the box ready for React. Yes Typescript does have added functionality but is also not ecmascript compliant in many cases. Typescript was originally designed so C# developer could wrap their head around JavaScript where Flow was created to help JavaScript developers.

This all depends on what you are aiming for with future development.

Flow: If you are just looking for strict types Typescript: If you want to take advantage of some of the added features typescript has

vitaly-t commented 6 years ago

B.t.w., pg-promise comes with comprehensive TypeScript support out of the box: https://github.com/vitaly-t/pg-promise/tree/master/typescript

jondubois commented 6 years ago

I'm not a huge fan of compile-to-js languages for large/complex projects because:

Also source mapping isn't always smooth sailing when it comes to debugging; especially in more complex environments like Node.js.

I would vote against (for Lisk core) but if everyone else wants this then I can cope :p TypeScript code completion is nice if your IDE supports it.

If I have to pick one, I would choose TypeScript over Flow because of maturity/stability.

vitaly-t commented 6 years ago

TypeScript also compensates for the lack of tests a lot.

For example, you make a change a repository method, and forget to update the code somewhere where it is used, and that's not yet test-covered. TypeScript will stop you right there, if there is any parameter or return type mismatch. So it adds to a much more robust code. Type checking is a powerful thing :wink:

jondubois commented 6 years ago

@vitaly-t Good point. For me this almost makes it worth the pain points I mentioned above. Almost ;p

I find that if method names are meaningful then it's not usually difficult to find all references in the source using text search commands/IDE shortcuts. I guess it depends on personal taste and tooling of choice.

shuse2 commented 6 years ago

Additonal to what @JakeSimmons89 said, I think it's like relationship between JAVA(Typescript) and Scala(plane javascript). If we refactor it to Typescript, there will be architectural differences. Of course we can organize it in the same way, but I think TypeScript has it's own way of coding.

I think what @jondubois and @vitaly-t said applies to both TypeScript and Flow, both needs build step: flow needs to remove typedef, and typescript needs to compile to JS (although flow is bit faster imo) for type definition: flow also doesn't have defined type, so might need to add, or you leave it as dynamic. (which is similar to TypeScript) using strict flow, does compensate for some testing.

Partial refactoring using TypeScript is harder than using flow. Additionally, to completely replace it, it takes time and it might introduce new bugs.

On the other hand, flow does work on top of the current project. Therefore, it has immediate effect. Unless we want to make significant architectural difference, I would vote for full ES6 feature with babel and flow, which will have immediate effect than TypeScript with less effort.

webmaster128 commented 6 years ago

+1 for Typescript because of it's popularity. Every Angular developer is familiar with it and on StackOverflow it is 50k vs. 1.3k.

tobiaslins commented 6 years ago

@webmaster128 Popularity should not be the reason why we or someone should use a specific technology. Neither Stackoverflow questions (could also mean that TS is more complicated for example)

Even tho there are more Pure JS devs then TS devs I guess.

I would not force people to use Typescript. For example, I would not contribute anymore if it would be changed.

Flow is just an extra layer that will not change the way everything is coded.

GarrettS commented 6 years ago

No, typechecking will not make anything more secure.

But you’ve gone on for so long talking about your favorite JavaScript libraries while providing no example of why not type checking makes your JavaScript less secure indicates that you really don’t know what the flip you’re doing.

It might appease the insecurities of developers who don’t know JavaScript.

webmaster128 commented 6 years ago

Type checking usually does not make code more secure, but it makes it safer. It is way easier to spot bugs or inconsistencies when the compiler or even your IDE tells you that you put in a variable of one type where another type is expected. And it is very easy to do this kind of bugs. For example: what type is a hash? Sometimes it is a hex string, sometimes it is a Buffer. There are many methods that work on both types, so even when running the code it is not guaranteed you spot a bug.

For everyone who criticizes type checking and never worked with it: give it a try. Start a simple Angular project (or whatever framework you like), use TypeScript and use Visual Studio Code as an editor. Don't stop using it after a day. Do it for 1 month and let your project grow. Do refactoring with the support of a type system. Productivity goes up quickly because you don't need to run tests very often. You avoid a lot of bugs. Your code becomes easier to read for the future you. You'll love it.

willclarktech commented 6 years ago

A decision has finally been made for TypeScript. We will aim to include it in v2.0.0 of Lisk Elements. To everyone involved in this conversation, thank you very much for contributing to the discussion. The decision in the end rested on two main points: (1) the increasing dominance of TypeScript vs Flow as a typing solution for JavaScript, and (2) the compatibility with other libraries in the Lisk ecosystem (in particular pg-promise and oclif). To everyone who was arguing in favour of Flow, sorry to disappoint you. We hope you can respect our decision.