[Roboprog]

That seems to be pretty common statement about JavaScript, but strangely not one I share.

I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half)

Typescript solves problems I don’t have. The Jetbrains IDEs do autocomplete just fine on vanilla JS, and the documentation window automatically shows the initialization and any JSDoc for most every symbol the editor cursor touches. I avoid writing code with thousands of global symbols.

OOP languages like Object Pascal and C++ are good for making lemonade from the lemon of manual memory management, but if you have efficient garbage collection, use functional programming techniques rather than OOP bloat, and many self inflicted problems go away.

I hope TS doesn’t turn JS into Enterprise Java, The Next Generation.

Nothing personal, most people seem to prefer that style. Just understand, there is a reason some people run away from the C++ / Java / C# / TS milieu.

[kingdomcome50]

> I hope TS doesn’t turn JS into Enterprise Java, The Next Generation.

No chance. And frankly, I don't get the comparison you are making to C++/Java/C#. TS is fundamentally different than those languages. From structural typing to a default functional/imperative paradigm, it really is just JS with better static analysis.

Your IDE is not as good for JS as it would be for TS. The entire impetus for TS is/was to provide better tooling/ergonomics around JS. Whether or not you need better tooling is a subjective matter.

[moocowtruck]

honestly the IDE could be using TS typings for their JS. Visual studio does this for javascript we use at work, and we don't use TS

[nicoburns]

Have you used TS much? In my experience idiomatic TS isn't much different to idiomatic JS and a far cry from Java style OOP code (the Angular ecosystem which was admitedly an early adopter of TS is an exception and best avoided).

[cryptica]

I used TS for several years and also don't like it. Nothing wrong with the language itself but the transpilation step adds significant complexity and is very slow so it breaks my train of thought and slows down my development iteration speed significantly. In addition to slow iteration speed, I got tired of encountering source mapping issues in some environments, version compatibility issues and TS config issues (especially when config property names change with the versions).

Also, static typing adds no value at all to programming if your project code is well structured. It's only useful for spaghetti code monoliths. If you make your code modular with good tests, you won't need type safety because your modules will be simple enough that your tests will easily catch these errors.

My view is that TypeScript encourages developers to write overly complex spaghetti code because it encourages devs to pass around active object references instead of simple primitives like strings, numbers or other primitive data types.

Alan Kay, one of the founders of OOP himself said that the point of OOP is not objects, "The big idea is messaging". Passing around complex typed instances goes completely against that. An instance is not a message. Complex instances (which have their own state and methods) are not messages; they should generally not be used for messaging between different components (I.e. as arguments or return values).

[robpalmer]

This is interesting. The things you list as problems are the same set of things we tried to solve:

- automatic compilation that is fast

- sourcemaps work

- decoupling of packages to help compatibility

- automatic tsconfig management

I wonder if you would have a different conclusion with these things taken care of.

I agree that TypeScript makes it easier to have functions with complex parameters - because they are now documented and more understandable. So yes, this demands more discipline on the API designer to keep APIs simple.

[smrtinsert]

For simple method and field references sure, but once you push it with method chains and transformations it becomes pretty underwhelming quickly. Typescript also isn't invincible to this, but it's better. If you are going into a small well scoped code base vanilla js should be fine. For a large code base with plenty of package sharing, good luck in either. To me the investment in TS sounds like someone crossed their arms and said "I'm not doing java". Their loss, as a java dev I rarely think about languages. Stuff gets done fast, with few or no errors and no need for special tooling or forced approaches. Kotlin is an area of interest for me these days but that's about it.

[IshKebab]

> The Jetbrains IDEs do autocomplete just fine on vanilla JS

I find that hard to believe because it's not a solvable problem without type annotations.

[ralmeida]

Maybe not in the general case, but practically speaking, static analysis can infer the types of probably most completion you would need in day-to-day development.

[uglycoyote]

This is contrary to my experience. For instance if the types of function parameters aren't specified, the IDE won't have any way of knowing what the types of those parameters are and will therefore not be helpful with completions.

[cryptica]

What I've found is that senior developers with 10+ years of experience with many different paradigms and projects tend to enjoy JavaScript and many hate TypeScript (particularly because of the build step and complexity that it brings). But for some reason Microsoft is running a lot of propaganda campaigns to promote TypeScript. My guess is that they're trying to push all the JS devs to TS and then once they have enough adoption, they can slowly start diverging from JS standards and take ownership of the ecosystem - This is an old Microsoft trick.

[robpalmer]

The scenario you are describing (TypeScript diverging from JavaScript) is unlikely in my opinion.

Orta, a member of the TypeScript team, describes the reasons why in his video "How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem" https://www.youtube.com/watch?v=qr0TnQ2mHwY

It directly answers the question of "What would a malicious version of TypeScript look like" and explains why this is unlikely to occur.

[darksaints]

I have found the exact opposite.