JavaScript libraries should be written in TypeScript

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

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

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.