4 ms·

> 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 wha

> 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
      Right, but that link won't change even if they switch to typescript, which is where my point lies. The benefit comes to package contributors, consumers looking for accurate documentation, and anyone that uses a build tool/IDE/or even a text editor with basic syntax highlighting. All of this while having no negative impact on people who only click your link. I'm not encouraging everyone to adopt it. I just struggle to see any objectionable aspect from anyone that is solely on the consumer side. Basically, if you aren't using any tooling, the world will keep on spinning.
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.

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
    Right, but that link won't change even if they switch to typescript, which is where my point lies. The benefit comes to package contributors, consumers looking for accurate documentation, and anyone that uses a build tool/IDE/or even a text editor with basic syntax highlighting. All of this while having no negative impact on people who only click your link. I'm not encouraging everyone to adopt it. I just struggle to see any objectionable aspect from anyone that is solely on the consumer side. Basically, if you aren't using any tooling, the world will keep on spinning.

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.