32 ms·

I still run into libraries written in Coffeescript, and hate it when I do, because I don't use it and have a hard time following it. Javascript libraries shoul

I still run into libraries written in Coffeescript, and hate it when I do, because I don't use it and have a hard time following it. Javascript libraries should be written in Javascript. Worship the one true God!

cpitman 11y ago
Except this really isn't an issue for TypeScript, it reads that close to JavaScript.
- yuchi 11y ago
  It reads closely to JavaScript. But it is not.
- sametmax 11y ago
  It's not about reading, it's about the tooling you need to set it up. JS initial strengh was ease of dev for beginers. Throw in a transpiler, a dependancy manager, a package manager, a bundler with FS watching, and source maps and what you got is wall for the very same type of dev that were producing all those fantastic jQuery plugins 10 years ago. And actually even for me. I do know how to install and use all those. I just don't want to take the afternoon to do so. Why ? - Only one project out of 5 are big enough to justify it. - The stack will change in 6 months; - I will need to train anybody who gets on board, and document it, and maintain it. - All this tooling integration is terrible in JS, because they are an agglomerate of stuff we are stacking after the fact to compensate JS bad initial design. The same stack for any other language is 10 times easier to setup and maintain (the stdlib is here for you in Python, you don't need to load a deendancy to generate a uuid), or it's just here out of the box (type hints ? embded in Php) or event completly uneeded (nobody use transpilers in Ruby hence no source maps, etc). So yes, it's annoying.
  - lloyd-christmas 11y ago
    > It's not about reading, it's about the tooling you need to set it up. npm install typescript -g This is the only addition on top of vanilla js, which is what you should be comparing with instead of the massive crap of build-tool-of-the-month. All said and done, if you're using those build tools in typescript, you'd be using them for javascript as well.
    - talmand 11y ago
      Wait, you mean I can start up a brand new Windows machine and type "npm install tsc -g" and stuff magically happens?
      - lloyd-christmas 11y ago
        "On top of vanilla js" meaning node. I understand what you're saying, but it's completely contextual. The title of this article is "All javascript libraries...". Maybe it's just that I'm not a front-end-only developer. I have no clue about the development process for exclusively front end libraries, but I don't see many people develop them without node/npm. Hell, JQuery has a package.json, and: "In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later" https://github.com/jquery/jquery https://github.com/jquery/jquery
      - Avenger42 11y ago
        Visual Studio 2015 and Visual Studio Code both support npm. I don't even think you have to type "install", I think it's just a matter of listing "tsc" in your package.json file. (I haven't tried it myself yet, but I just got back from VS Live in Vegas where the ease of package management in VS 2015 was brought up in several sessions.) Check it out here: http://webtooling.visualstudio.com/package-managers/npm/ http://webtooling.visualstudio.com/package-managers/npm/
    - jasonkester 11y ago
      I love the irony in this comment (and a couple of its siblings). It's as though crazy javascript tooling is so deep into the bones of javascript developers that they can't even tell when they're using a tool. I expect you were genuinely sincere in your suggestion.
      - lloyd-christmas 11y ago
        You're criticizing a comment making an assumption about javascript tooling, on a thread specifically ABOUT javascript tooling? If you aren't using javascript tooling, wouldn't a change in that tooling have no impact on you? Seems like an odd criticism to me. Regardless, the only thing I mentioned was npm. I don't consider node/npm to be "crazy javascript tooling". So yes, I was genuinely sincere. "In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later. Earlier versions might work, but are not supported." Welcome to [1]2011, where the most prevalent front-end codebase requires node and it's package manager to contribute. Feel free to peruse the countless other commonly used libraries. Maybe you can point out a widely used front-end codebase that doesn't use node/npm/git? The only one I could find was BabylonJS, which uses bower. Conveniently to my point, bower is dependent on node/npm/git. Writing code in a text editor and saving it with the extension .js makes for a javascript file. We know that. Using that file in the browser means using some a <script> tag. Whether its from the server or through a cdn, that script tag contents/url will still have to be in javascript, even if you used typescript to develop it. No negative impact on text-editor user-land. [1] https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7c3542ffd1b19257a8e5e https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7...
  - davedx 11y ago
    You don't need tooling to use libraries written in Typescript. NPM libraries distribute the compiled source.
  - MadcapJake 11y ago
    WRT Ruby, there's actually Crystal and InfraRuby (off the top of my head) that both seek to add typing to Ruby. For Python there is mypy. > Only one project out of 5 are big enough to justify it. No, any library author could benefit (strong set of features, added type safety, additional usability for TS users from proper .d.ts files). Key point here, TFA is about libraries not projects. >The stack will change in 6 months; TypeScript has been around longer than 6 months and has only gained traction. > I will need to train anybody who gets on board, and document it, and maintain it. Learning TypeScript takes a day at most. And if you really need to justify that lost time, just remember that outside of types, everything else is just ES6/ES7 features. Document it? Ever heard of self-documenting code? Maintain it? It sounds like you really don't know what TypeScript is about.
  - grumblestumble 11y ago
    you say "only one project out of 5 are [sic] big enough to justify it", and then complain that the perks that tooling provides aren't part of the core language. do you see the inconsistency there?
- forthefuture 11y ago
  Maybe we'll agree to disagree but this [0] doesn't read very close to Javascript at all. [0] https://github.com/Microsoft/TypeScriptSamples/blob/master/todomvc/js/todos.ts https://github.com/Microsoft/TypeScriptSamples/blob/master/t...
  - lloyd-christmas 11y ago
    That does though. Skip to line 120 where code is actually written, and it's ES6. The top part is type definitions, which could just as easily be thrown at the bottom. I'd argue it should for exactly this reason.
- SonicSoul 11y ago
  Except it really isn't. As soon as you convert to .ts you'll get a boat load of errors and have to re-declare your types and input parameters as vars for TS to ignore them. Also not sure what would be the point of using pure javascript in this context other than marginal benefit of a compiler detecting javascript syntax errors. Not arguing pro or against TS just pointing out it's not the same as using javascript
lloyd-christmas 11y ago
Typescript isn't all that differentiable from ES6. While I'm generally on the vanilla train, feeling fairly compelled to use it when messing around with angular2 has made me very much appreciate it. Change your .js filename to .ts and it will still run, which makes the typing just an added bonus.
- dobs 11y ago
  Which leaves me wondering why I'd use Typescript over sticking with ES6, especially with tools like Babel making many future features available right now and libraries like React actively making use of them.
  - lloyd-christmas 11y ago
    You shouldn't. My comment was in regards to readability of typescript vs coffeescript vs es6-javascript. If you don't want the added benefit of type-checking with minimal overhead, don't bother.
  - squeaky-clean 11y ago
    > especially with tools like Babel making many future features available right now and libraries like React actively making use of them. You get all of this with Typescript, as well as optional types. If you're writing any Javascript at all, technically you're already writing Typescript.
  - agumonkey 11y ago
    People told above, think of TS as a strong linter over normal ES6. Static typecheck is often very nice.
mattferderer 11y ago
Simple solution - offer the compiled file in the library. Everyone wins.
- davedx 11y ago
  This is the default way of doing things on npm that I've seen. http://stackoverflow.com/questions/29738381/how-to-publish-a-module-written-in-es6-to-npm http://stackoverflow.com/questions/29738381/how-to-publish-a...
blakeyrat 11y ago
This is like the fourth or fifth post in this thread where people are confusing CoffeeScript and TypeScript. Why is that? They're totally different.
slang800 11y ago
Then just compile the library and everything will read like really well-written JS.

cpitman 11y ago

Except this really isn't an issue for TypeScript, it reads that close to JavaScript.

yuchi 11y ago
It reads closely to JavaScript. But it is not.
sametmax 11y ago
It's not about reading, it's about the tooling you need to set it up. JS initial strengh was ease of dev for beginers. Throw in a transpiler, a dependancy manager, a package manager, a bundler with FS watching, and source maps and what you got is wall for the very same type of dev that were producing all those fantastic jQuery plugins 10 years ago. And actually even for me. I do know how to install and use all those. I just don't want to take the afternoon to do so. Why ? - Only one project out of 5 are big enough to justify it. - The stack will change in 6 months; - I will need to train anybody who gets on board, and document it, and maintain it. - All this tooling integration is terrible in JS, because they are an agglomerate of stuff we are stacking after the fact to compensate JS bad initial design. The same stack for any other language is 10 times easier to setup and maintain (the stdlib is here for you in Python, you don't need to load a deendancy to generate a uuid), or it's just here out of the box (type hints ? embded in Php) or event completly uneeded (nobody use transpilers in Ruby hence no source maps, etc). So yes, it's annoying.
- lloyd-christmas 11y ago
  > It's not about reading, it's about the tooling you need to set it up. npm install typescript -g This is the only addition on top of vanilla js, which is what you should be comparing with instead of the massive crap of build-tool-of-the-month. All said and done, if you're using those build tools in typescript, you'd be using them for javascript as well.
  - talmand 11y ago
    Wait, you mean I can start up a brand new Windows machine and type "npm install tsc -g" and stuff magically happens?
    - lloyd-christmas 11y ago
      "On top of vanilla js" meaning node. I understand what you're saying, but it's completely contextual. The title of this article is "All javascript libraries...". Maybe it's just that I'm not a front-end-only developer. I have no clue about the development process for exclusively front end libraries, but I don't see many people develop them without node/npm. Hell, JQuery has a package.json, and: "In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later" https://github.com/jquery/jquery https://github.com/jquery/jquery
    - Avenger42 11y ago
      Visual Studio 2015 and Visual Studio Code both support npm. I don't even think you have to type "install", I think it's just a matter of listing "tsc" in your package.json file. (I haven't tried it myself yet, but I just got back from VS Live in Vegas where the ease of package management in VS 2015 was brought up in several sessions.) Check it out here: http://webtooling.visualstudio.com/package-managers/npm/ http://webtooling.visualstudio.com/package-managers/npm/
  - jasonkester 11y ago
    I love the irony in this comment (and a couple of its siblings). It's as though crazy javascript tooling is so deep into the bones of javascript developers that they can't even tell when they're using a tool. I expect you were genuinely sincere in your suggestion.
    - lloyd-christmas 11y ago
      You're criticizing a comment making an assumption about javascript tooling, on a thread specifically ABOUT javascript tooling? If you aren't using javascript tooling, wouldn't a change in that tooling have no impact on you? Seems like an odd criticism to me. Regardless, the only thing I mentioned was npm. I don't consider node/npm to be "crazy javascript tooling". So yes, I was genuinely sincere. "In order to build jQuery, you need to have the latest Node.js/npm and git 1.7 or later. Earlier versions might work, but are not supported." Welcome to [1]2011, where the most prevalent front-end codebase requires node and it's package manager to contribute. Feel free to peruse the countless other commonly used libraries. Maybe you can point out a widely used front-end codebase that doesn't use node/npm/git? The only one I could find was BabylonJS, which uses bower. Conveniently to my point, bower is dependent on node/npm/git. Writing code in a text editor and saving it with the extension .js makes for a javascript file. We know that. Using that file in the browser means using some a <script> tag. Whether its from the server or through a cdn, that script tag contents/url will still have to be in javascript, even if you used typescript to develop it. No negative impact on text-editor user-land. [1] https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7c3542ffd1b19257a8e5e https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7...
- davedx 11y ago
  You don't need tooling to use libraries written in Typescript. NPM libraries distribute the compiled source.
- MadcapJake 11y ago
  WRT Ruby, there's actually Crystal and InfraRuby (off the top of my head) that both seek to add typing to Ruby. For Python there is mypy. > Only one project out of 5 are big enough to justify it. No, any library author could benefit (strong set of features, added type safety, additional usability for TS users from proper .d.ts files). Key point here, TFA is about libraries not projects. >The stack will change in 6 months; TypeScript has been around longer than 6 months and has only gained traction. > I will need to train anybody who gets on board, and document it, and maintain it. Learning TypeScript takes a day at most. And if you really need to justify that lost time, just remember that outside of types, everything else is just ES6/ES7 features. Document it? Ever heard of self-documenting code? Maintain it? It sounds like you really don't know what TypeScript is about.
- grumblestumble 11y ago
  you say "only one project out of 5 are [sic] big enough to justify it", and then complain that the perks that tooling provides aren't part of the core language. do you see the inconsistency there?
forthefuture 11y ago
Maybe we'll agree to disagree but this [0] doesn't read very close to Javascript at all. [0] https://github.com/Microsoft/TypeScriptSamples/blob/master/todomvc/js/todos.ts https://github.com/Microsoft/TypeScriptSamples/blob/master/t...
- lloyd-christmas 11y ago
  That does though. Skip to line 120 where code is actually written, and it's ES6. The top part is type definitions, which could just as easily be thrown at the bottom. I'd argue it should for exactly this reason.
SonicSoul 11y ago
Except it really isn't. As soon as you convert to .ts you'll get a boat load of errors and have to re-declare your types and input parameters as vars for TS to ignore them. Also not sure what would be the point of using pure javascript in this context other than marginal benefit of a compiler detecting javascript syntax errors. Not arguing pro or against TS just pointing out it's not the same as using javascript

lloyd-christmas 11y ago

Typescript isn't all that differentiable from ES6. While I'm generally on the vanilla train, feeling fairly compelled to use it when messing around with angular2 has made me very much appreciate it. Change your .js filename to .ts and it will still run, which makes the typing just an added bonus.

dobs 11y ago
Which leaves me wondering why I'd use Typescript over sticking with ES6, especially with tools like Babel making many future features available right now and libraries like React actively making use of them.
- lloyd-christmas 11y ago
  You shouldn't. My comment was in regards to readability of typescript vs coffeescript vs es6-javascript. If you don't want the added benefit of type-checking with minimal overhead, don't bother.
- squeaky-clean 11y ago
  > especially with tools like Babel making many future features available right now and libraries like React actively making use of them. You get all of this with Typescript, as well as optional types. If you're writing any Javascript at all, technically you're already writing Typescript.
- agumonkey 11y ago
  People told above, think of TS as a strong linter over normal ES6. Static typecheck is often very nice.

mattferderer 11y ago

Simple solution - offer the compiled file in the library. Everyone wins.

davedx 11y ago
This is the default way of doing things on npm that I've seen. http://stackoverflow.com/questions/29738381/how-to-publish-a-module-written-in-es6-to-npm http://stackoverflow.com/questions/29738381/how-to-publish-a...

blakeyrat 11y ago

This is like the fourth or fifth post in this thread where people are confusing CoffeeScript and TypeScript. Why is that? They're totally different.

slang800 11y ago

Then just compile the library and everything will read like really well-written JS.