[1]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

Also, I've been doing web dev for 25+ years now and I don't like the trend backward to waiting for code to "compile".

Although if you're going to have to compile, Svelte looks like a nice middle-ground.

How do you suggest addressing this in a 10 dev team when developing in js?

Hit me up in the e-mail in my profile if you want to discuss this further, would be happy to help and discuss my reasoning further. I've been doing a LOT of TS code recently on all the major target platforms for React - browser, electron, and react-native. I manage a team who's built several applications now and we use TS for everything, including an automatically-generated TS api interface that exposes types from our C# REST backend using swagger directly to the client code.

You can leverage ocaml/ml as well as js ecosystem. Mix different files and syntax.

Bsb is also faster than tsc.

- non-standard ordering of arguments between belt/standard library

- Ocaml's standard library actually generally avoiding the Option/Result type, in preference of exceptions, which is unexpected and a pain since it's an ML.

- package management involves manually adding things to the bsconfig (has this changed?)

- things randomly break between relatively minor Bucklescript versions, they broke something pretty important in like a .x release when I was messing around with it

- server side isn't good. It technically works but all the bindings are old or terribly documented, and you never really know if it's not going to blow up at some point.

Otherwise, I actually quite like it! None of those are actual core language complaints.

It's much worse than just using TypeScript (only at runtime, PropTypes aren't that useful anywhere else, PropType syntax doesn't match Flow, TS, or jsdoc, ESLint can't check any PropTypes you spread in), but it can get you by in a pinch.

I had some negative experiences with typescript in a large React project but in that case the most negative experience was that often the type definitions provided by React and common type libraries didn't match our needs, which made doing something that would normally be quick difficult and long.

The reason for types not matching was often that we needed to generate HTML emails as part of things, which means you need a lot of deprecated attributes, so probably you won't have this problem.

For example I contributed to Typescript's definitely typed project in the past. To make typescript more useful. But I ended up spending so much time writing type definitions. After all, I rather have some NaN or "undefined is not a function" exceptions during development.

That said, in proper type safe development at least your own API comms should be type safe. It's easy if you use the same language on client and backend, which is possible with Typescript, Reason/Ocaml, Scala, Rust, etc.

The problem with Typescript is that it's half assing type safety in the language itself and people generally half ass type safety in other aspects of development too. You just can't expect to reap the benefits of real type safety with such an approach.

I like letting my tools do stuff for me. If a tool can go look up what arguments this function expects, and their types, and tell me that, rather than my having to go check, and then also warn me if I typo one of them, then also take me straight to the definition of the function if I decide I want to read it, without my having to go hunt it down manually, all at zero cost (again, these things should be documented anyway), then why the hell not?

[EDIT] I guess I just don't understand why people consider it burdensome. You probably ought to know your function's going to take a string. Is it that hard to type "string" in the signature? You're gonna have to figure out what it's supposed to return—when you do, write it down. It's a little more work for more complex structures but it still amounts to typing out things you already have to think through anyway, and the more complex the more important it'd be to record that somewhere, so may as well be machine-readable type information. In return, when you accidentally try to treat your string like a number you'll immediately know you've missed a step, you'll get comprehensive autocomplete on hashes and classes and such, jump-to-definition, instant typo-spotting, automatic refactoring, and so on, and you can hand it over to someone else and they'll get those same things, instantly. The payoff is 10x, at least.

Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, then some level of transpliation is inevitable. Yet, I didn't find debugging that much difficult with correct setup.

ES6/2015, sure; ES2021, though...

For the latest useful JS features, you need a compiler, whether it's TypeScript or Babel or...

If you're using ESLint, I'm quite sure you'd like TS as well, so if that is the case, you might want to give it an actual chance.

If your comment were code, TypeScript would have caught your typo at compile time, versus JavaScript where your users would have experienced this (potentially catastrophic) error at runtime.

This is the main value we get out of TS. If we rename a property on a viewmodel, we then update a TS file containing all the models. In this trivial example an auto refactor might propagate the change, but if it didn’t we get type errors all over the application telling us to change this. In JS, there’s an overwhelming possibility we miss one of these, and it isn’t picked up until production.

Real-life example: I recently came across some code that checked for a rare error. It was in the form,

    if (object.property === CONST_ERR_CODE) { /* handle it */ }

This class of issue is probably my least favorite thing about js at any type of scale. It's so incredibly permissive that even simple tweaks need to be scrutinized carefully, whether by human eyes or unit tests. Using human eyes means I can't write js when I'm tired at the end of the day (otherwise the perfect time for small, no-functional-changes refactoring), and unit tests for trite details are boring -- I'd rather spend that effort up front, to appease the compiler.

On the other hand, js is incredibly nice for prototyping, before I have to care about edge cases.

Modern static ESModule JS is quite good. I have several projects north of 30KSLOC written in modern JS. I'm not living in "undefined hell" because I use named-export ESModules, I check types all over, and I write quality tests. A little discipline goes a long way.

Which is something you rarely need to spend time on if you're using TypeScript.

https://en.wikipedia.org/wiki/Lindy_effect

Transpilers definitely aren't Lindy. CoffeeScript, GWT, Elm, among others form a huge graveyard of de facto defunct languages targeting JS.

The type war was "won" by TypeScript, and I expect it's just a matter of time before types make it into the standard. The benefit of winning so completely and having such enormous popularity is that its ideas are very likely to make it into the standard such that no transpilation will be necessary.

I hope so too. TypeScript has done so many things right in its design and implementation - starting from Anders Hejlsberg, with expertise in creating numerous languages; backward compatibility to allow gradual and seamless migration from JS to TS; structural typing; editor/IDE integration via language server; good documentation; corporate backing (maybe not necessary, but like React, I think it was a big factor in its wide adoption).

so in 2016 typescript was around for 4 years, and here we are now 4 years later. its still around. seems to be holding.

You solve scripting language problem with better code organization? While in the first place the language was designed to solve scripting problems, DOM manipulations, now you can use JavaScript to build backends and SPA's hybrid apps, and most importantly some huge code base of libraries like Gatsby, vscode, where large teams are collaborating in the same project. How would you solve all the runtime errors? How would you solve expending the capability of your code editor? How would you solve refactoring? Just to name very few of what something like Typescript is capable of.

It's an unhappy situation for all involved really. JS should be a language that targets some kind of bytecode that the browser executes rather than being a direct target.

Perhaps WASM will some day replace all webpage scripting allowing everyone to use languages of their choice.

Non platform languages introduce those extra layers, while bringing along their own FFI issues, idiomatic libraries and other set of issues to care about.

I only use TypeScript alongside Angular, as one could somehow consider Angular to be the platform, for anything else Web related, pure JavaScript with script tags (yes I don't bother with JavaScript transpilers either).

I think that'd be super cool.

Their point seem to be that no matter what language you prefer to be compiled to JS, in ends up being JS anyway so you might as well write JS directly, because of the reasons provided in the last post. I don't agree with them (ClojureScript is the language of choice for me), but you're not arguing with good faith here.

That being said, the commenter above them could've also been referring to old old JavaScript where no transpilation is needed to reach practically every target environment.

It seemed to me that the author was describing the (somewhat common?) practice of writing client code directly in ES5 and perhaps polyfilling any missing features for any targeted browsers that required specific fills.

I, personally, find ES6 to be ugly and requires me to pretend all sorts of things that are not true for the targeted runtime. It's like a whole fake world, so I'll prefer to avoid it unless there's some obvious reason to use it, as in an existing front-end build toolchain and a spec to use ES6, etc. Greenfield? I guess Svelte and such will use it, but if Typescripting, then one will just write Typescript, right?

I will be happy when I leave wart-land, but only when I really leave wart-land, not when it's just "lipstick on the wart"-land.

Types and classes sound nice, but only if they really exist, and not as mere compiler advice. A type is really a memory shape/size/structure in compiled languages.

Ok, having said all of this heretical nonsense...

(and yes, I've used React, Vue, etc. I tend to like Mithril best, and avoid JSX as I've no problem with hyperscript, and have even made my own lousy reactive hyperscript that I don't use (lol) in favor of Mithril)

... i DO have to say that Typescript seems like a nice/useful tool for teams, were transpiling to be accepted for the project needs, after weighing the costs/needs. I am recently rather fascinated by Svelte, and I'm mostly trying to break things and see what generated code looks like, etc. I'll admit that ES3 get's a bit useless, hence the polyfill. Minified JS with single-letter variables is usually a hoot to read.

What runtime are you using that you can't run ES6/2015 natively in the console?