Hacker News Reader

Comment by user3939382 | Hacker News Reader

25 years of working with it and I still hate JavaScript. Its behavior is unpredictable, I can only figure out what my code is going to do by running it.

“classes are objects!” I’m good. Just look at the local state of a JS app when it’s running in a debugger, the amount of global state you’re presumably supposed to keep track of.

All these transpiled compiled webpacked source mapped etceteras make it even worse, more indirect, more automagic, more unpredictable.

All this turtles-all-the-way-down flexibility JS provides isn’t necessary for a programming language, other languages accomplish the same tasks without it. The cherry on top is that you’re forced to use it basically because it’s baked into the web.

Sorry for the rant.

View on HN

> Sorry for the rant. On the contrary, thanks for it! I haven't been developing with Javascript that long but I also share same feelings and worse. On top of that there an astonishing number of frameworks that all claim the same: fast and under N KiB in size. On top of that people always on the edge using the latest craze out there, just because it is trend. It feels like Java in 2000 or C++ in the 90's but much worse. But the cherry on top are the TypeScript fanatics. I do pretty well with JS and maybe a light framework on top of it, thank you very much. I do not need TypeScript nor its guarantees. Why? Well because if you comply to your interfaces and add tests and docstrings that is enough to have things in place with decent robustness. When I see something like this:

type NestedPartial<T> = { [K in keyof T]?: T[K] extends Array<infer R> ? Array<NestedPartial<R>> : NestedPartial<T[K]> }

Honestly, WTF is that? Do I need THAT in JS to write good code? How much time do I need to spend to get up and running and learn that thing? But again, some people are blindly praising it as the silver bullet to robust FE code... To me that looks C++. Good luck with that. If one thing I wished to not be out there is TypeScript.

Edit: Also sorry for the rant.

Aside from C++, you can also have typing atrocities in Java, and I bet in C# and other strongly typed languages I haven't tried, too...

No one is saying TypeScript is as robust as a baked-in typing system, but it's a godsend for ~98% of code one writes in JS.

As a fan of typescript, I have to say, no you can't be THIS crazy with types in C++, C# or java

The reason ts can be unreadable is actually same to why haskell, scala, ocaml etc are: the type systems are much more expressive so people keep pushing it.

C++ has a much more complicated (Turing complete) type system than C# and Java.

Lol yeah the TypeScript syntax is insane. It's great for primitive types and simple inheritance and extensions, but the generics and stuff... unreadable

> When I see something like this

Where do you see something like this? It's rather unusual for app developers to write code like this; such code tends to be abstracted into libraries.

> Honestly, WTF is that?

A nested partial, as the name of the type helpfully suggests. I.e. a type that will check whether a deeply nested object, which has just a subset of the fields of a parent type, still has fields that are compatible with the parent. Should be useful if you want to deep-merge such a fragment with the full object, thus overwriting a subset of full object's fields.

> Where do you see something like this?

I have seen that code in Stackoverflow. Someone was asking something about it. I do not have the link, just grabbed the snippet some long time ago. 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.

> A nested partial, as the name of the type helpfully suggests...

Ok, good for you that you can proficiently understand it! Note that I'm not saying this in an arrogant way, honestly good for you that you have another tool in your belt, which is something always valuable.

I just do not want to deal with that (same that I do not want to deal with type hints in Python, I don't need it) but I increasingly see the industry (in general terms) praise for it. I prefer to stick to: "If it walks like a duck and it quacks like a duck, then it must be a duck".

Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?

> Think about TypeScript the other way round. What if TypeScript wouldn't be out there? What can you do to bring more stability to your FE code?

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?

> Luckily, we don't have to conduct this thought experiment...

You're implying that with TypeScript you will get your codebase spaghetti free which is obviously not true. You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.

> TypeScript and don't realize you can just... not use it?

I don't but the places I've seen TypeScript code bases still suffered from much more critical issues than type issues. Like using wrong ideas, wrong patterns, no tests, spaghetti code, but hey you know what? We use TypeScript and is great, and believe it or not that is becoming the rule, not the exception.

TypeScript solves one single problem and is pretty good at it given the dynamic complexity of JS language. Trying to justify its usage as "fix-all band-aid" and then not liking the tool because it can't do that is not very productive. You can use wrong ideas, wrong patterns, no tests and have spaghetti code in literally every other language, that's not something for TypeScript to handle.

> You're implying that with TypeScript you will get your codebase spaghetti free

I am not. I'm saying I don't have to imagine a world without TypeScript, I've lived it.

> You can have a code base that hasn't a single type error and yet be full spaghetti. This also holds true when working with any framework, backend or frontend.

Sure. I don't disagree. I'd still rather have the codebase without the type errors.

Types make expectations on behavior explicit instead of implicit. They nay not feel needed when you feel like you master the language, but they sure do help communicate and quickly grok some aspects of the code without having to interpret it in your head(which might be easy when you've just written it but less so in many situations).

Reply on news.ycombinator.com