> but transpiling it down into a language that isn't as type strict just seems silly to me You obviously have no idea what you're talking about. Almost all statically typed languages get compiled to something much less type-strict. This is one of the reasons for writing compilers in the first place! Case in point: Haskell gets compiled to assembler. You can't get a much bigger difference between typing disciplines th…
Good point, but is the first sentence necessary? :(
JavaScript libraries should be written in TypeScript
211–220 of 285 posts
Re: JavaScript libraries should be written in TypeScript
#212Nothing all stoping, DIY, in fact encouraged. I agree .ts is great, and who ever desires a lib to be .ts, the only questions is: if you desire it, than make it so.
Re: JavaScript libraries should be written in TypeScript
#213Earlier quoted context omitted.
In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for. This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations…
You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :) Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs
Re: JavaScript libraries should be written in TypeScript
#214Earlier quoted context omitted.
Defensive coding in JavaScript? That's absolutely not how most libraries are implemented.
If you're expecting one type and get another, you have to handle it, right? Documentation is important in JavaScript by virtue that code contracts are never enforced due to implicit typing.
Depends. You could debate the same philosophy wrt C and null pointers. Should you check all your arguments to see if they're null, if the documentation/specification says they should never be null, or accept undefined behaviour and segfault?
In practice, most code assumes everything is checked, sanitized and used correctly at the outer most API boundary.
Re: JavaScript libraries should be written in TypeScript
#215I think this is a bit of a hasty claim with a bit of truth to it, sort of like if someone said "All JavaScript libraries should be authored in CoffeeScript" in 2010. A cambrian explosion occurred, then the community eventually coalesced. Coffeescript itself isn't (and wasn't) perfect, but it pioneered an approach that led to a whole lot of progress in JS. A better framing of this is: "Type systems are good. The JS co…
Re: JavaScript libraries should be written in TypeScript
#216Earlier quoted context omitted.
If Elm didn't also exist, I'd almost agree with you.
In an ideal world I'm sure a lot of us would love to work with Elm, but the reality in a commercial situation is often that the choice of language is driven by factors like: how widely used/well known it is, what the availability of libraries for it is like, how easy it is to hire developers with experience for. This unfortunately makes languages like Elm and Clojurescript unlikely to be chosen in a lot of situations…
Re: JavaScript libraries should be written in TypeScript
#217Earlier quoted context omitted.
I have not used TypeScript personally, just read and try some demo of it. But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent. For after look at the v8's C++ code, I can't imagine anyone would write that with C. But when a new language's ego sys…
That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.
declare var _: {
each(arr: T[], f: (elem: T) => U): U[];
delay(f: Function, wait: number, ...arguments: any[]): number;
template(template: string): (model: any) => string;
bindAll(object: any, ...methodNames: string[]): void;
};
declare var Store: any;
If there is bug in this code, I won't know how to debug it.I have no clue on what the JS generated by it looks like.
If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers.
If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery.
But that's me, like I said, I am too old... :-)
Re: JavaScript libraries should be written in TypeScript
#218> There is a culture in the JavaScript community that “types don’t matter”
I don't think that's the case, particularly among seasoned developers: we do care about types and interfaces, but we just don't think writing them down in code is as big a deal as Typescript claims it to be.
> We are already linting because we believe it makes better code.
Linting doesn't require you to write non-javascript, it just works (after configurations). It doesn't force you to write code in any particular ways (see ESLint for example). That's why we find it more acceptable.
> Types are stronger. Types matter.
TS isn't automatically stronger, since TS is a superset of JS, developers can still omit the types. So you either write in proper TS-style and get its benefits, or don't.
And referring to earlier points:
> The types are there. Instead of leaving them implicit, you can just make them explicit.
IMO: there are many ways to setup this contract. And I question the % of type-related issues within a library when you have 100% test coverage and proper linting already.
> Often in JS libraries, the types are vaguely defined as an afterthought when writing docs.
TS can't force you to write strong types, just as JS can't force you to write good doc. You need a stronger will, not a better nag.
My case for writing your next popular library in vanilla JS: your users will already know how to contribute. And you get to choose how to enforce good variable types.
For TS vs JS details, see http://stackoverflow.com/questions/12694530/what-is-typescri...
Disclaimer: my libraries are nowhere as popular as angularjs or immutablejs, but I do intend to maintain them to a degree that may serve thousands of developers.
(Plus the author uses one of my library so I guess they are not that bad)
Re: JavaScript libraries should be written in TypeScript
#219Earlier quoted context omitted.
Good point, but is the first sentence necessary? :(
Are you implying that it's factually incorrect? Also, the word "silly" appeared in the BinaryIdiot's comment first. You have to be prepared for not exactly polite responses when you do something like this.
Not everyone is capable of looking past personal attacks like yours. It is the first step to a flame war.
You have something to say? Great. Just say it, no need to talk about how little the other person knows.
Aside from "two wrongs don't make a right," do you really feel that this is comparable?
I love the idea of type script but transpiling it down into a language that isn't as type strict just seems silly to me.
And..
You obviously have no idea what you're talking about.
If you honestly, in your heart of hearts, feel that both statements are ballpark same level of cordiality, then ok.
Re: JavaScript libraries should be written in TypeScript
#220While type errors are a small part of problems in software reliability, we should take everything we can get. At least in things thousands of millions of users are going to rely on.