Hyperapp: Rewrite in Typescript?

[jorgebucaran]

TypeScript is awesome, it is a superset of JavaScript and the only features we would be using are probably function types, param types, and interfaces.

It's difficult to keep up with the type definitions as the library evolves, but that could also be the result of the churn. If we rewrite the entire library in TypeScript we get types out of the box.

On the other hand, rewriting Hyperapp in TypeScript may alienate some users and some people may even draw the wrong conclusion that Hyperapp can only be used with TypeScript.

What do you think?

[whaaaley]

No thanks.

[jorgebucaran]

@whaaaley How does this affect you (or anyone else) as a user?

[whaaaley]

@JorgeBucaran As a user it doesn't.

What it does affect:

• Perception of the project from the outside. (How? I'm not sure.)
• How easy it is for people to learn the codebase. (I certainly don't know TypeScript.)
• How easy it is for people to contribute to the codebase.
• You're dependent on TypeScript to output good code.

In the end it just seems to solve a rather small annoyance via nuclear blast.

[SkaterDad]

@JorgeBucaran What are you finding the most difficult about maintaining the typings?

[jorgebucaran]

@SkaterDad Keeping up with the typings, but in hindsight, this would require a build step, which is one of the things I've been trying to avoid like the plague, at least as far as this project is concerned.

[alber70g]

If I got some spare time I'll see if I can do a rewrite in TypeScript.

Some comments on @whaaaley points:

Perception of the project from the outside. (How? I'm not sure.)

Not sure either, but if you look at the most respectable code bases/libraries out there, they're usually written in TypeScript or Flow. Right now TypeScript seems to have won the war, so let's not underestimate the value it can bring.

How easy it is for people to learn the codebase. (I certainly don't know TypeScript.)

The code is fairly the same, only param/variable types are added, shouldn't be that much of a dealbreaker to read the code.

How easy it is for people to contribute to the codebase.

To be honest, as any decent programmer it shouldn't be hard to contribute when this is in TypeScript. The code base itself will stay fairly easy to comprehend as the general architecture/API of Hyperapp is simple in itself

You're dependent on TypeScript to output good code.

It might even save bytes if the google closure compiler uses the types

[alber70g]

@JorgeBucaran Keeping up with the typings, but in hindsight, this would require a build step, which is one of the things I've been trying to avoid like the plague, at least as far as this project is concerned.

Why avoid the build step? You need to run the tests already for each release, so why not a build step for the source?

[zaceno]

@Alber70g

as any decent programmer it shouldn't be hard to contribute when this is in TypeScript.

Sure, probably not, but they'll have to learn typescript first. Probably not too hard for a "decent programmer", but still a threshold and barrier to entry.

[alber70g]

My bad, I formulated that badly. What I meant is: you don't really need to learn TypeScript in order to contribute since the types will speak for itself basically. If you'd want to do a full refactor/rewrite however, it might be harder. But I think that's out of scope for just a contribution.

[okwolf]

I may not have been molested by static types like Rich Hickey seems to have been, but I do agree with his criticisms and the conclusion that types should be a la carte and only applied where the value they add is worth the verbosity they introduce.

I also agree with the hierarchy of programming problems he introduced, in which static types are a solution to the least important problems in programming:

[jorgebucaran]

Thanks for the link @okwolf! I loved that talk.

[jorgebucaran]

@Alber70g Why avoid the build step?

Because a build step (compilation) introduces complexity. I will probably use a build step to create apps, but Hyperapp itself can get away without one and that's amazing.

You need to run the tests already for each release, so why not a build step for the source?

True, but it's not the same. 😉

Users don't need to deal with our test suite, only contributors to Hyperapp do. Having said that, I want to find a way to test Hyperapp without babel (but still use ES modules).

EDIT: I will be using esm and testmatrix for testing in the future.

[vladshcherbin]

I really hope this will never happen and I'm pretty sure there will be users who'll lose interest to this project just because of TS.

[okwolf]

@VladShcherbin I really hope this will never happen and I'm pretty sure there will be users who'll lose interest to this project just because of TS.

⚔️

[jorgebucaran]

@VladShcherbin I hear you, I used to feel the same way when I'd encounter a TypeScript project. I guess this is another one that we are not ready for and there's also this comment.

[alber70g]

@VladShcherbin I really hope this will never happen and I'm pretty sure there will be users who'll lose interest to this project just because of TS.

If this is the case, I really don't mind that the source will stay in Javascript despite my comments, IF the typings will be updated with each release, of course

Just to be clear: I really like Typescript, but as long as there are typings it's fine by me to have it in javascript. Also I doubt if it would help with Jorge's problem of updating typings, since the actions typings are different when you define them, as compared how they're used in the internals of hyperapp.

[mecurc]

I think we lose control of hyperapp size with TS.

what about Flow?

[jorgebucaran]

👋Everyone thank you for your feedback. I'm going to keep things the way they are (Hyperapp will not be rewritten in Typescript) and make sure (I'll try!) to keep the type definitions up to date.

@dmitry-vakhnenko Absolutely nothing against flow, but nope, I don't want to use flow this time.

[kosirm]

I'm late to the party :) Anyway, it's core team debate I suppose... Just wanted to add my opinion as totaly new hyperapp user. Feelings are divided. Keep entry point as low&simple as possible, this is the rule. I would definetely skip over some library, which require from me to learn new syntax just to test it. On the other hand, after I started to read about hyperapp, my first thought was "wow, it would be great if this would be typed". That's how I found this thread. I don't know how much would it take to maintain two libraries (js and ts) in paralel for limited amount of time and see what is downloaded/forked/used more?

[Mytrill]

@kosirm Hyperapp actually has typings for typescript. I believe the debate here is: keep js + typings separate VS rewrite in typescript.

[kosirm]

@Mytrill thanks for clarification. That's even better. You have my vote for the decision you have already made :)

[kyegupov]

I believe rewriting in Typescript is not a matter of taste, it's a necessity. Modern frontend development is extremely, ridiculously complicated. Not having proper type support is like being a blind mouse running through a maze.

Rewriting things in TypeScript is easy and pleasant. I'd certainly vote for doing so. If I have spare time, I'll write a PR to do so (maybe I should wait for HA v2 to be released?..)

[zaceno]

@kyegupov Type definitions should be enough for you, though, right? There's no need to rewrite the code in typescript, is there? I mean, if it gives you a kick, by all means knock yourself out -- but I'm 99.9% sure a PR would not be accepted. (Jorge has been clear in the past wants to keep it hand-crafted and backwards compatible javascript).

[kyegupov]

@zaceno I'm curious as to what "backwards compatible" means - the code begins with the export keyword, which is only defined in ES6. So, if you target older JS runtimes, you need transpilation anyway. So you might as well transpile from TS, with all its excellent documentation and features?

TS code is more readable and easier to follow. The reasons to convert to TS were outlined by Jorge himself: why not inline types, why not have more type safety during development. Moreover, having the project written in TS would encourage authors of plugins to use TS as well (e.g. I'm suffering right how because hyperapp-forms does not have TS bindings).

[jorgebucaran]

@zaceno Correct! 💯

@kyegupov Yes, for a time I thought about rewriting Hyperapp in Typescript. But I don't want to anymore. I do need help with the type definitions, so help that way is more than appreciated.

[zaceno]

@kyegupov Yeah "backwards compatible" was perhaps not the best word. I meant: old-browser-compatible. The export statement in there is the only es6-ism, and it's only there because we use rollup to make a bundle that can be imported via CDN or require. That's the only processing that happens. That and uglify of course.

[WitoldSlawko]

Actually that's a super great idea!
See the repo for comparsion : https://github.com/joseluisq/hyperapp-starter
Creating components with well defined interfaces is very clean.