4 ms·

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

by cpitman 11y ago

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...
      - jasonkester 11y ago
        For what it's worth, jQuery doesn't need npm. You can grab the .js or link it from the CDN as you prefer. https://jquery.com/download/ https://jquery.com/download/ I haven't come across any .js library that doesn't offer the same.
        lloyd-christmas 11y ago
  - sametmax 11y ago
    No. First you need to install node. Then you need to install typescript. Then you need to setup something that watch the typescript files and transpile them when they change. Because no, running a command everytime you change a letter in the file is not acceptable. Then you need to integrate that in your static assets pipeline (minifiers, linters, git hooks, i18n extraction, whatever). Because files changes and are generated on the fly, and you probably use a framework that already interact with them in some way. Then you need to make sure it's part of your deployment process, including continuous integration. Because the typescript command now must be in your builder scripts, travis files, docker container, etc. Then you need to setup your browser to read the source map. Because debugging a transpiler without a source map is hell on earth. Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script. Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others. What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ? What's that you have a concurrency problem between several FS watchers ? What's that, somebody commited the transpiled files on the git repo by mistake and now some edge case made the travis build fail ? Saying "it's just npm install" is disrespectful, at best. It's NOT a 5 minutes job. It is work.
    - lloyd-christmas 11y ago
      >First you need to install node. The article doesn't really apply to you if you aren't using node. If you're only using a script tag, it will have to be consumed as javascript anyway. Any library that is written in typescript will have a transpiled javascript version available to you, or there would be no point in writing it in typescript. > Then you need to install typescript See above > [more irrelevant complaints] See above. > Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script. PHEW. This may have been my most difficult google search of the week: http://lmgtfy.com/?q=typescript+editor+support&l=1 http://lmgtfy.com/?q=typescript+editor+support&l=1 > Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others If you're have issues surrounding this, typescript should be the least of your worries. > What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ? Heaven forbid you have an onboarding process that is documented and methodical. My entire team runs the same version of node. We keep track of issues surrounding operating systems and IDEs so we have reference material when others bump into similar issues. If you're not doing this, there's no way in hell I'd want to use anything you're producing. The article and commentary is about PUBLISHING libraries, not consuming them, and it's not about eliminating javascript from private repositories. If you're publishing an open-source library and aren't using node nowadays, color me impressed, given that most of the major testing frameworks are built around node. Even jQuery has required node to contribute since 2011 because of that. I have struggled to find a popular front end-only library that doesn't utilize node in it's development process. Those libraries HAVE to include a js file, since that's how the the browser consumes it. So... the world kept on spinning after you made a mountain out of a pebble. Failing to read/understand the article, and subsequently huff and puffing a list of irrelevant objections is disrespectful, at best. Clearly nothing here applies to you, and you've managed to take that as an opportunity to point out how inept your team is. Congrats.
- 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

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

by 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...
    - jasonkester 11y ago
      For what it's worth, jQuery doesn't need npm. You can grab the .js or link it from the CDN as you prefer. https://jquery.com/download/ https://jquery.com/download/ I haven't come across any .js library that doesn't offer the same.
      - lloyd-christmas 11y ago
- sametmax 11y ago
  No. First you need to install node. Then you need to install typescript. Then you need to setup something that watch the typescript files and transpile them when they change. Because no, running a command everytime you change a letter in the file is not acceptable. Then you need to integrate that in your static assets pipeline (minifiers, linters, git hooks, i18n extraction, whatever). Because files changes and are generated on the fly, and you probably use a framework that already interact with them in some way. Then you need to make sure it's part of your deployment process, including continuous integration. Because the typescript command now must be in your builder scripts, travis files, docker container, etc. Then you need to setup your browser to read the source map. Because debugging a transpiler without a source map is hell on earth. Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script. Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others. What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ? What's that you have a concurrency problem between several FS watchers ? What's that, somebody commited the transpiled files on the git repo by mistake and now some edge case made the travis build fail ? Saying "it's just npm install" is disrespectful, at best. It's NOT a 5 minutes job. It is work.
  - lloyd-christmas 11y ago
    >First you need to install node. The article doesn't really apply to you if you aren't using node. If you're only using a script tag, it will have to be consumed as javascript anyway. Any library that is written in typescript will have a transpiled javascript version available to you, or there would be no point in writing it in typescript. > Then you need to install typescript See above > [more irrelevant complaints] See above. > Then you need to setup your IDE to understand typescript. Yeah, most editors don't understand type script. PHEW. This may have been my most difficult google search of the week: http://lmgtfy.com/?q=typescript+editor+support&l=1 http://lmgtfy.com/?q=typescript+editor+support&l=1 > Then you need to document that, and train yours colleagues. They don't have the same OS, versions, editors, experience than each others If you're have issues surrounding this, typescript should be the least of your worries. > What's that, you spend 2 hours trying to help a new commer in your team on skype to find out you just don't have the same version of type script ? Heaven forbid you have an onboarding process that is documented and methodical. My entire team runs the same version of node. We keep track of issues surrounding operating systems and IDEs so we have reference material when others bump into similar issues. If you're not doing this, there's no way in hell I'd want to use anything you're producing. The article and commentary is about PUBLISHING libraries, not consuming them, and it's not about eliminating javascript from private repositories. If you're publishing an open-source library and aren't using node nowadays, color me impressed, given that most of the major testing frameworks are built around node. Even jQuery has required node to contribute since 2011 because of that. I have struggled to find a popular front end-only library that doesn't utilize node in it's development process. Those libraries HAVE to include a js file, since that's how the the browser consumes it. So... the world kept on spinning after you made a mountain out of a pebble. Failing to read/understand the article, and subsequently huff and puffing a list of irrelevant objections is disrespectful, at best. Clearly nothing here applies to you, and you've managed to take that as an opportunity to point out how inept your team is. Congrats.
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