Javascript was built for an environment that needs to do everything not to fail, just like HTML. A javascript engine will do everything to save a bad script from yielding an error. Javascript wasn't build with code correctness in mind. In that perspective, the language is a success. I personnally don't like languages that allows the developer to add a string to an integer without yielding a type error.

Typescript can help but it is still javascript underneath. And it doesn't correct the libraries you use that are written in Javascript.

Luckily, we don't have to conduct this thought experiment, we lived it from the release of JavaScript in 1995 to the release of TypeScript in 2012. The result was a decade and a half of spaghetti JS scripts and JQuery and unstable frontends. Universally true? No, of course not, it's always been possible to write good frontend code, but people who do that have been exceptions, not the rule.

> The point is not where does that come from, the point is it can exist and if I need to deal with it I need to do a deep dive in something that I do not have interest nor energy to invest on and in the mean time slows me down considerably.

Look, I completely disagree with you about the value of types, I think they're an incredible tool that rules out the existence of an entire class of bugs which are incredibly common in JavaScript frontends. But you don't have to agree. You don't have to like types, and you don't have to like or use TypeScript. But it's a tool that allows me to reinforce the basic structure of a webapp so that it's reasonably stable with far less work than vanilla JS. You seem to object to the existence of TypeScript and don't realize you can just... not use it?

Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly.

But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong ideas, wrong libraries, wrong constructs, wrong design principles, tooling hell, etc, etc.. Which is IMHO the real issue with JS/TS. For some reason TS proponents seem to live in a world where 'TS solves everything'.

For me TS is just writing 20% more code and regularly needing to use the 'any' keyword to avoid spending hours on getting a basic line of code working. Everything I write non-professionally is not TS, I cannot think of 1 single reason to give myself that burden.

The best thing TS has given me is even more jobs. With Agile front-end developers spend at least 1 day a week in the meeting room, now with TS they spend 20% of their time left to hassling with types. It's hilarious. Especially all those managers that have no clue what's going on, why front-end development gets slower and slower.

Typescript is a solution to the jank-fucking-tastic type munging JS does (see: [1] About 1:20 in) and the problems that ensue.... if all you are doing is just making menus appear/disappear on click, by all means keep to JS.

The build steps/tooling are useful when you want to build actual applications rather than decorate a marketing page, and also when you need to support legacy browsers, being able to work with modern sensibilities and get code that'll work in IE11 is a blessing.

> the unnecessary complexity of the Javascript ecosystem is mostly about gatekeeping and aesthetics and i will die on that hill.

JS has much more of a "flavour of the week" problem than more mature ecosystems like PHP, I put that down to a relatively poor stdlib by comparison, rather than aesthetics or gatekeeping.

    1. https://www.destroyallsoftware.com/talks/wat

See, that's the really sad thing about JavaScript: it's a Blub.

In addition to JavaScript, I've written C, Python, Ruby, Perl, Go, C++, Java, Common Lisp, Scheme, HyperTalk, Visual Basic, Lua and shell (I'm probably forgetting something). I've played with Erlang and Haskell. Every one of those is better than JavaScript. Most are much better than JavaScript.

What are my issues?

Well, there's the whole hasOwnProperty hack when iterating over an object used as a hash table. Then there's the default variable scoping. Then there's == vs. ===. The default fallthrough in switch. The lack of integers. The goofiness of details of the object mode (I'm not objecting to prototypal inheritance; I'm objecting to the myriad subtly different ways to do prototypal inheritance). The lack of a metaprogramming facility. The lack of a standard package or module facility and its consequent explosion into a myriad subtly-different systems.

And there's the callback hell of the browser runtime, but that's not necessarily JavaScript's fault.

When I write JavaScript, I feel like I'm back in the bad old days of C, where a single error will be undetectable by the compiler and result in simply a core dump, leaving my to single-step through my code looking for what went awry.

If it weren't The Language of the Web™ it'd be about as popular as Befunge.

Exactly, it makes it "more palpable".

> The idea that TS is great but JS sucks is silly.

Just to be clear, I absolutely did not say that. Instead, I'd rather agree with your statement that TS only makes things better. But there is only so much it can do in that ecosystem, even if a good type system does notably improve things.

Everything that's below that is still what it was.

No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong.

>To me, this sounds like the belief that only one language can solve a problem which I disagree with.

I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant.

>TypeScript is not a silver bullet.

Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing.

>They are all just tools.

Sure, but some tools work better than others.

>Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana.

I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.

This is spot on. I prefer type-driven development. But maintaining these typings is costly. Maintaining the definitions upstream is also difficult. GOing back to my redux / router example. There was one class they were going over again and again. Because it had a number of permutations and didn't meld well with a type system.

I whole-heartedly disagree. TypeScript, Flow, and Babel are all ways to address JavaScript's weaknesses. You could argue Babel is a result of out-dated browsers, of course. But fragmentation of targets is certainly an issue of the language -- earlier versions didn't have to be so poorly designed.

Would we have all these transpilers if we were using a fully-formed, general-purpose language for the web from the start? No. If JS had a type system, there would be no TypeScript, Flow, NativeScript, PureScript, etc. If JS had a sane way to handle parallelism from the beginning, Babel wouldn't be nearly as useful.

Yes, it's true that JavaScript wasn't designed for what it's being used for now. That doesn't mean it's a good language (or ever was).

Interesting.

Not having to define types makes JS feel very fluid to me when using it to jump into a problem and quickly test out ideas.

You can figure out solutions fast, and I suppose with that power comes irresponsibility for those who don't care to clear up the chaos they are able to leave behind in the fast iterations towards discovering the implementation they seek. In short - it takes discipline, and your argument it seems is that typescript enforces a certain degree of discipline... pros and cons to both.

Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years.

My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc.

And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither.

Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce.

And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit.

JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly.

If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.

* No exceptions (practically) * no built-on ways of providing abstractions * No concurrency at all for a very long time * No way of dealing with binary data

Those things were added later (classes, webworkers, arrays) when they became absolutely necessary. But it started and lived for a very long time as very minimal language.

> I have never once run into a problem that isn't easily solvable with Javascript.

Swallowing errors. Code quality. Solvable with typescript and others, but I wouldn't call it "easily sovlable".

JavaScript is consistent. Expressive languages such as JS are consistent in their permissiveness. It doesn't stop developers from doing irrational things like comparing objects with numbers just like TypeScript doesn't stop developers from writing all other kinds of flawed logic.

TypeScript basically only protects code from typos. The worst bugs I see in production systems are almost never caused by typos or by comparing incompatible types; usually they're caused by issues in the flow and manipulation of data; for example the same instance is being modified in two different parts of the code without the other part of the code being aware of it; or in the case of pure FP a function is using outdated instances because a change in the underlying data source did not propagate through correctly, etc...

TypeScript is to a software developer what a spell checker is to a book author; it's convenient but once you run the final product past your editor-in-chief (whose analogy in the software world are unit/integration tests), the spell checking didn't actually add any value; at best it saved your editor-in-chief some time. It has no bearing at all on whether or not you'll get a Pulitzer Prize or a top ranking on Amazon.

The downside to TypeScript is compile time and this is a significant drawback IMO because it slows down iteration time significantly. Time spent waiting for the build to finish is time that was not used to add new tests and new features.

If you add up all the time that all developers on a project spent on waiting for the build (or lost their focus/train of thought as a result of waiting for the build to complete), how many extra unit or integration tests could have been written using that lost time? I think if you do the math, you will find that TypeScript is a net liability to the project.

Hello. I'm a JavaScript programmer who cut my teeth on Java twelve years ago, followed by C++ two years later and throughout the course of my Computer Science program, and over the years I've done personal work in half a dozen other languages including Rust, Clojure, Python, C#, etc.

Despite all of that TypeScript remains by go-to general-purpose language of choice, for any arbitrary project without particular constraints.

Take your flame-bait elsewhere, please.

Javascript's ubiquity and portability does not change the fact that on its own, it is a pretty bad programming language. There are a plethora of reasons to choose Typescript, most prominently is the much much better development experience Typescript give you.

I'm not sure if you've used Typescript, but using Typescript still gives you the portability and ubiquity of javascript because all it does is compile down to Javascript.

Remember that this all compiles down to JavaScript where it's all dynamic/weak types. Someone coming from C/C++ should definitely appreciate TypeScript over just plain JavaScript.

I think honestly TS is a poor representation of this guarantee, it's extremely easy to trick the compiler and it often doesn't offer you the guarantees you think it does. Because of JS being so widespread TS has become a lot of people's interpretation of this idea. It's not to say it's a bad language and can't help a lot on larger JS projects but I think it shouldn't be put into this category of languages.

Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so.

I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers.

I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.

It would be if machine code were another high-level text-based language completely unrelated to either Lisp or Haskell with its own semantics, execution model and type system rather than a more directly machine-readable format of those languages themselves.

Javascript is fundamentally different enough from a bytecode for any arbitrary language that, at least to me the distinction matters. I can accept that it works well enough that most people don't care, even though I suspect most of the use cases for doing so (error checking, type checking) could be better served with linters or editor tools for JS itself.

But the decision to avoid actually writing javascript at all costs has contributed a great deal of complexity in the JS ecosystem, which translates into the bloat in the web that everyone complains about, because all of that javascript is wasting time and cycles simulating other languages.