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).
> 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.
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.
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.
> 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.
I'm a freelancer, I change team every month or so. You have been spoiled with your team members, working only with professionals that know the JS ecosystem and have defined process and a good management.
You think that most people publishing lib are unit testing them ? JS is the language with the least unit tested code I know. You think people writting JS use node ? Man, you need to quit working for L.A. start up, there is an entire world out there that is learning about stuff as basic as AJAX calls and making libs anyway because they have knowledge about their job they want/need to share.
I work with american clients right now. Well, they are working on an open source code base they got from Africa. The code is not remotly close to your fancy standards.
I worked with people working in the geography field 2 weeks ago.They learned Angular JS. Choosing between the minified and the non minified file was the struggle here. No, they didn't have Node installed. They don't even know what it it. Yes, they will produce JS libs, they have knowledge only they got, and they will share it.
I worked with a friend in porn 3 month ago. He is still using jQuery and manual JS files. Because it works, because it's simple. He is never going to use type script, he doesn't even have the time to read about it. People reading HN are an exception, a microcosme. Yes, he published a lib to generate visual hashes for passwords.
"Everybody should be using typescript, it's so simple" clearly ignore completly the heterogeneous world we work in.
> I'm a freelancer, I change team every month or so.
This isn't an excuse to be disorganized or fail to do a proper onboarding. You're justifying incompetence.
> You have been spoiled with your team members...
I've never worked with shitty people. Either I'm the luckiest idiot in the world, or I actually take the time to do research before accepting job offers. I'm leaning towards the latter.
> You think that most people publishing lib are unit testing them ?
One's that people use? Yes. If you aren't unit testing published libraries, you're doing nothing else but shitting in a bucket and tossing it on the street. If you're using those packages without validating them, you're the one licking that street. If you have a wall of script tags of random libraries used to do each piece of your application, it's nothing better than copy and pasting from stack overflow. All you're doing is stacking wood for an eventual bonfire. I just took a minute to look at the libraries we use. All but one has tests. Funny enough, we aren't actually using it. Thanks for helping me clean up my scripts. So... I guess my life tip is to pick better libraries.
> JS is the language with the least unit tested code I know.
It's also the most tested one I know. Oddly enough, it's the most used language in the world. Weird how numbers work.
> You think people writting JS use node ? Man, you need to quit working for L.A. start up
Yep. I actually work in NY. Maybe there's a serious difference between the two cities. From what I see, companies that last more than 3 months tend to have even the most basic of organizational skills. Companies that don't last 3 months typically don't publish packages. But hey, to each their own.
> They don't even know what it it.
I'd love a list of the companies you've worked for so I can avoid anything they've built. As you've said, ignoring the ecosystem we work in is ignorant.
> Yes, he published a lib to generate visual hashes for passwords.
so... a single function? Wall of script tags, bonfires, failing application, debugging hell, over-dependence, etc. As a freelancer, I have a tip for you that might save you some time and increase your income. Spend less time googling for packages and spend 10 minutes building them.
> "Everybody should be using typescript, it's so simple"
I'm not arguing for the first part. I'm arguing for the second part. Simply put, if a person publishing a package doesn't understand the whole javascript ecosystem (node included), I have no interest in consuming their product. Maybe it's just me, but I don't enjoy spending time debugging a package that I have no control over. If it's internal, I can yell across the room to the person who built it (and marked it with their contact info. You built it, you own it). If it's external, I expect to be able to run their tests (hence why we all have node) so I can easily find a point to debug from, and submit an issue if it's truly an issue from them vs. me. If it's me using their api wrong, that's the perfect example as to WHY you should use typescript. It's self-documenting, so I would be able to see the issue quickly without running their tests. Again, as a freelancer, I'd expect you to want to save time.
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.
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.
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.
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.)
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"
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.
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?
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.