Moving LokiJS To TypeScript?

[TeamworkGuy2]

Title makes this sound extreme, but there are some solid reasons to switch.

My viewpoint after writing the definition file for LokiJS (see #167) is that there's no obvious downsides to TypeScript for an OOP JS library like LokiJS, the code doesn't doing anything crazy with prototypes or function argument and makes an excellent target for TypeScript.

Since all javascript code is valid typescript, file extensions can be changed to .ts to move a project to TypeScript. Types can be added when contributer's have the time/desire. There's a dozen tools and IDEs to compile .ts to .js when you save a file or as part of a build process, keeping side-by-side .ts and .js files in the LokiJS /src directory wouldn't take much effort.

TypeScript has the obvious advantage of providing compile time error checking, it has great refactoring support (VS2015's TS tooling is pretty awesome! Check it out if you haven't) and the TS module syntax, shorthand lambdas, classes, etc. (which can all be compiled away into standard JS) merges very cleanly with ES6 making the upgrade easy in future.

What are your, the major contributors to LokiJS, thoughts on upgrading Loki to typescript and pros/cons from your viewpoint?

(based on my experience over the last 6 months working on a large business web app using VS2015 + TypeScript + LokiJS + lokijs.d.ts file linked in #167)

[obeliskos]

Typescript does look interesting... I expect I will be looking into it more over the next few months or so.

I am not sure yet of the major benefits inside the lokijs project itself. Without the benefit of much research into typescript, I would expect that higer level abstractions of lokijs like resultset and dynamic view would be easier to port, while the low level core methods and plumbing are more functional style and may be less able to concretely express? Externally and across api surfaces, the value is obvious and your definitions probably already help for that.

We have been very careful to keep loki as pure native javascript solution not only for deployment purposes, but for development purposes as well. Having said that, this 'common feature set' will likely be fine tuned and tested enough soon that domain specific solutions / forks can pivot that source base into more specific environments like a full typescript rewrite.

I would offer to include your definitions in this project but I assume DefinitelyTyped is the preferred central location for these?

[TeamworkGuy2]

Thanks for your input obeliskos, TypeScript isn't pure javascript, that's true, but it is a superset of javascript, which means LokiJS core level methods could remain unchanged and higher level methods like resultset and dynamic view could have types added to their function parameters and return types.

Yes, the central repository for definitions is DefinitelyTyped. I was thinking I might not always be available or remember to keep the definition over there updated as LokiJS continues to evolve, which was one of the reasons I asked this question.

[obeliskos]

Yes i'm looking over it a bit and looks pretty impressive. Once I learn more I would be willing to help maintain the typescript definitions. Maybe once i get comfortable enough to work with the definitions you created (thanks :) we can coordinate via messaging here or elsewhere.

[TeamworkGuy2]

DefinitelyTyped is open to any contributors, the LokiJS definition hasn't been updated in 5 months, so it could use an update.
My blocker to easily updating the definition is that I don't keep up with LokiJS API changes and minor releases, so I either have to manually go through every commit for the last 5 months to find API changes, or take the current loki.js file and re-convert it function by function to a definition file.
If you keep up with LokiJS releases and API changes, you could help maintain the definition file.

[alexandernst]

Since ES6 (and in a few more months ES7) is already available in all major browsers, there isn't any benefit at all (except type checking) at using TypeScript over plain JS (ES6).

Furthermore, you'll notice that the entire community is 👎 TypeScript as it just makes things harder to debug without any reason. Also, developers just don't seem to want to learn/deal with TypeScript syntax. Just look at the biggest JS project (that I'm aware of): Atom. They started doing it in CoffeeScript and now they are moving to plain ES6.

Just my 2 cents

[rick-agilifly]

I think it would be a huge win to include the updates to the definition file. We are looking to use in an Angular 2 project and we are Typescript all the way

oh and my 2 cents
maybe talk to the Angular 2 team about Typescript (oh and Ionic as well) and Aurelia and .........

[alexandernst]

I'm not saying to not support TS. Supporting TS would be totally fine, if it were possible with some minor effort. My point is that right now, being ES6 already available in all browsers, there are no reasons to switch over to TS (except type checking, which imho is a solution to a non-existing problem). Type checking is a good thing, but be honest with yourself, how many times you actually screwed something because of bad variable assignment? Just a simple example, Python doesn't have type checking, and Python apps are cool, they work fine.

About Angular 2, Ionic, Aurelia, etc... They all chose what they chose based on what was available at the time they started those projects.

On the other hand, TS adds yet another point of failure, as browsers don't run TS, but JS. So you're forced to transpile the code to JS, meaning you're actually tied to yet another component. Let a single bug in the transpiler happen, and you'll be debugging something for hours before realizing you're hunting ghosts.

There is also the fact that just a small subset of the developers that code in JS understand/code TS too. Such a change will scare the vast majority of possible contributors.

Last, but not least important. Your issue is the opposite of the very first rule of coding: Don't touch it if it works. This is not some 300 lines Angular directive. We're talking about 7k lines of code. Odds are rewriting such a big code base will (listen my words, this is not the first time I see such a thing) cause bugs, failures and other odd situations.
But even in the best case scenario, after rewriting the entire code base to TS without introducing a single bug, you'll have wasted precious time which could have been employed in implementing new features in rewriting something that wasn't bad and didn't actually need a rewrite.

My final point, and with that I'll probably stop replying to this issue as I don't want a flame war, TS doesn't offer that much pros compared to all the cons it has, after analyzing the amount of work required to do what you're requesting.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Bessonov]

Hey, @alexandernst, your arguments doesn't hold (anymore).

except type checking, which imho is a solution to a non-existing problem

It's just your personal view. Not the view of community.

and Python apps are cool, they work fine.

And, what would you say with that statement? Assembler works fine too. And cobol. And TypeScript.

Python doesn't have type checking

Python community was interested in type checking for many years (since 2012?). But AFAIK it was hard to support types in not invasive way. Well, finally, https://docs.python.org/3/library/typing.html

About Angular 2 [...] They all chose what they chose based on what was available at the time they started those projects.

That's not true. Angular 2 startet with own script language and then switch to TypeScript.

So you're forced to transpile the code to JS

That is the best of two worlds. But it's not whole true. You can create just type definitions.

meaning you're actually tied to yet another component. Let a single bug in the transpiler happen, and you'll be debugging something for hours before realizing you're hunting ghosts.

There are bugs in browsers, OS and in between. Should we stop developing at all? Anyway, you can just looking at compiled code.

There is also the fact that just a small subset of the developers that code in JS understand/code TS too.

Not hold anymore.

the very first rule of coding: Don't touch it if it works.

It's just your personal rule.

They started doing it in CoffeeScript

https://trends.google.de/trends/explore?date=today%205-y&q=%2Fm%2F0n50hxv,%2Fm%2F0hjc5m0

you'll have wasted precious time which could have been employed in implementing new features in rewriting something that wasn't bad and didn't actually need a rewrite.

Yeah, it's like not to write tests, because in meantime you can implement new features...

I totally agree, that rewrite whole code base is a huge deal. I even understand, that there is no time for improvements like this. And it can't be expected for open source projects. But I think there is a room to look at this feature request again. Fortunately, there are at least tree way to support TypeScript:

1. Rewrite whole code base (well, unrealistic)
2. Define typings (least effort, is enough to make TS guys happy)
3. Rewrite code base piece by piece (I think this is the best way)

Personally, I can't imagine to developing with JS instead of TS anymore.

[alexandernst]

My very first statement was: “I’m not saying to not support TS”. From there on everything is just my POV. I’m sure the dev team will be more than happy to review your patch and merge it. 👍

[obeliskos]

I see @techfort mixed things up by adding stale bot ;)

Guys we have already embraced Typescript within the (next gen loki) LokiDB. @Viatorus put in a lot of work to make that happen.

As it stands now we are refactoring critical code paths and adding new ones. Hopefully that should be in a (non-beta) supported upgrade path from lokijs soon. Packages are currently being emitted to es6, so if you prefer javascript you should be able to utilize that along with full type definitions for your editor.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.