Hacker News Reader

Comment by russellbeattie | Hacker News Reader

I'm sorry but all those examples and Deno's documentation in general should be in JavaScript. I respect the devs right to choose which ever language they want, but Deno seems to want to be the standard bearer for the power of scripting and web standards [1]. If that's the case, then they are causing more harm than good by focusing exclusively on TypeScript, which isn't a language as much as a set of macros on top of JS. TS should remain a niche for those projects that can benefit from type safety, not promoted as some sort of better alternative to JavaScript, because it's really not.

1. https://deno.com/blog/v1

View on HN

> not promoted as some sort of better alternative to JavaScript, because it's really not.

This leaves me skeptical if you have extensive experience with Typescript. It's way more than "oh this is a number not a string." It's "you forgot this property on an object's return type that you built from a response value" or "your Redux reducer doesn't handle all of the possible action types so it will crash at run time"

"your Redux reducer doesn't handle all of the possible action types so it will crash at run time"

And what are all these dr. Strange multiverse possibilities you speak of? Any semi seasoned JS dev has spidey sense for watching out for null and undefined, and generally you should know the type of what you are returning. Is there that much variability in what you are dealing with? If it’s an array of objects, that’s not hard to hold in your brain, just watch out for empty arrays or null/undefined items.

> Is there that much variability in what you are dealing with?

Yes.

I don't mean any disrespect but again it sounds like you really haven't tried Typescript.

Spidey sense can, often and will fail.

I am not a web dev at all but having something for automatic verification (even if limited) sounds more reliable than the variability of any given dev's "spidey sense".

> Any semi seasoned JS dev has spidey sense for watching out for null and undefined

That comment reeks of the same biases that C/C++ developers make when they admit that a majority of C/C++ bugs are related to hard-to-detect pointer/memory safety issues, but claim that they're a good C/C++ developer because their own code doesn't have such bugs, despite the bugs by their very nature being hard-to-detect.

Deno attempts to provide a standalone tool for quickly scripting complex functionality.

That's from Deno's home page. What I'm talking about isn't whether TypeScript is useful for some projects, as that has been proven beyond question. What I'm saying is that as a tool for "quickly scripting", as claimed by Deno, it is unnecessary and counter productive to JavaScript as a whole.

My point is that the Deno project is a high profile JavaScript engine which, in my opinion, is misguided in their end-user focus on TypeScript and I think it's a shame.

Devs are always searching for the "right" way to do things, and can be easily convinced to do things like misuse "const" because some pedantic fool convinced them it was sorta like type safety, and therefore not using it was "baaaaaaad". And the sheep followed and now const is used everywhere, despite the clear and unambiguous intended functionality of the feature's designers, who added it as a way of tracking, incredibly, constants and nothing else.

It would be nice if we saved a generation of devs another debacle like const, NoSQL databases and UML.

There is zero practical downside to using `const` whenever possible, and my (Fortune 100) team's backend has been using a NoSQL database for years which has saved us an absolute ton in hosting costs. Hardly a "debacle."

Our solution is the right way to do things... for ourselves. Sorry that it upsets you.

How are NoSQL databases "bad" and should in general? The term "NoSQL" in itself is very inclusive and might include databases such as redis, elasticsearch or apache cassandra.a

It's important to choose the right tool for the job and SQL/ relational DBs fit many usecases but are not always the right choice. Especially when handling massive amounts of data, that can fit into structures such as wide-column stores, databases like scylla or columnar storage with clickhouse, can help massively.

NoSQL is a good solution for the 1% of projects that need it. It sounds like you had great success with it, congrats.

Otherwise, it just ends up being a big flat in-memory table with a badly implemented version of SQL welded on top, written by developers who never bothered to learn SQL or database management in the first place. Then a bunch of fad followers jump on the bandwagon, and before you know it, we have a decade of idiots blathering on about "web scale" technologies.

That's the debacle I'm talking about. Millions of man hours wasted.

It’s essentially a subjective question, but FWIW I disagree. I’ve written quite a bit of JS and quite a bit of TS, and I find TS so much better. I’m more productive, generate fewer bugs, and have more fun when writing it.

This reads like you’ve never written a serious app in either JavaScript or Typescript. Willingly using JavaScript over Typescript in 2022 is insanity. There’s a reason Typescript won out over Dart and Flow - and why Javascript preprocessor languages and type checkers like Typescript even exist. It all boils down to one incontrovertible truth: JavaScript really really sucks.

Some part of me wonders if they wrote some clear optimizations for defined types that translate easily to Rust. I could give two shits about types honestly, but I’m also one of those weirdos that keeps function arity low, and object definitions concise.

How did people write semi elegant Ruby or python all these years, why wasn’t there such a massive push for types in those languages? Most likely because backend people chose the backend language of their choice, but on the frontend they detested JavaScript (you have no choice, you must JavaScript you anti authoritarian shit heads) so much they had to drown it with some kind of ketchup to make it edible (Typescript).

After using typed backend languages like Rust and even Go (which is painful in its own right, in my perspective) I would hate to work again on a big Ruby or Python codebase. They feel just as disgusting, to use your metaphor, as using plain Javascript instead of Typescript.

> why wasn’t there such a massive push for types in those languages

Are you just choosing to ignore all of the history of type checking Python and Ruby?

Look, this is going to back and forth. Take a time machine to pre Web 2.0 and explain to everyone why OOP programming sucks. I’d dare you to take it off your resume. But we’re here now right?

It’s not hard for me to imagine the reversal of this trend inevitably where everyone goes ‘the fuck are we writing all these verbose types for this dumb web app for?’.

I really don't see what the back and forth is. Types are not inherently a fad - but there can be people who promote them with fanaticism as a cure-all or for problems they can't solve. There were people skeptical and critical of OOP when it was popular. I don't believe that OOP is inherently a fad either - it has its place. Different paradigms just get caught in the windstorm of fad interest.

> [why] are we writing all these verbose types for this dumb web app for?

You can take anything to the extreme, but types are a zero risk, low effort investment that has a quick return. If someone over-types something it's hardly a problem compared to an over engineered OOP codebase.

I guess thats my main deal breaker. It’s simply another foot gun to allow people to over abstract. I have no issues with modest typing, it’s nice, it’s clear. I have issues with what entropy inevitably does.

So why are we in disagreement then? I am not advocating fanaticism, you simply seem to have implied and inferred that.

Sometimes it takes a discussion, I’m not in the business of upvoting or downvoting :p

The problem with OOP is that there is not a single definition.

There are a bunch of people claiming this and that are OOP. To me OOP is encapsulating a mutable state inside a dynamic namespace (an object, an instance of class), with functions that can access the state and the ability to inherit / extend namespaces.

And I absolutely don't need it, I don't agree with the view some things are better done with OOP. Even gaming or GUI programming, domains typically considered to be the best for OOP, turned to ECS (which is very functional) and Elm style APIs.

Going back at OOP: I consider mutable state to be a necessary evil to be limited as much as possible; inheritance makes it hard to track what code is being run.

The best practice for writing OOP revolves around limiting mutable state and inheritance, so why even bother with OOP in the first place?

I can have encapsulation with namespaces / modules in functional languages as well. I don't need much else and I can live happily without `this` and using composition instead of inheritance.

OOP was the first marketing wave focused at developers and it's gone.

You're a bit late to the party...Web 2.0 was this phase.

Deno can handle plain JavaScript just fine. In what way is targeting TypeScript harmful? How do you differentiate between a project that can benefit from type safety and one that cannot? Why should Deno's documentation be in JavaScript?

What does is mean to "respect the devs right to choose which ever language they want"?

The idea of TS is not bad, but they had to forbid any and other ways to escape the type system. I get tons of runtime errors on my TS projects as well because someone down the chain decided they couldn't be bothered with types.

Also, having to do type definitions for modules which don't have types is a massive pain. Overall, I appreciate the type safety, but I don't think TS delivers on that promise and I'd rather use a real typed language.

Reply on news.ycombinator.com