Hacker News Reader

> personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem.

There are a bunch of nice languages featuring good FP support that compile to JS that are have viable sized developer communities and longer histories than TS. For example ReasonML, ClojureScript, Flow and Elm. Then you have the bunch of languages that compile to asm.js or WebAssembly. Not to mention the majority of Node and FE developers who continue to use JS.

Reason, ClojureScript are separate languages with their own computation models and conventions. They are designed to have their own ecosystems rather than integrate smoothly with the JS ecosystem.

TypeScript integrates with the JS ecosystem, often major JS libraries include typescript definitions in the box, or are even written in typescript.

Flow has been obsolete for a while now (yes I said it).

I only have experience with ClojureScript, there the npm ecosystem support is good thanks to recentish improvements, at least for consuming, and we routinely use libraries from there. Usually encapsulated by some ClojureScript shim to keep functional interfaces (and kebab case!).

ClojureScript (and the other mentioned languages) really are in a different category than TypeScript. You can think of TypeScript as a linter for JavaScript that you help by adding some annotations to your JS, rather than an entirely different language. Deno merely strips those annotations for you before executing the remaining JavaScript.

The TS language semantics would seem to preclude a stripping based implementation, no? Eg generics seem to be a whole new area of semantics [1].

I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS.

[1] https://www.typescriptlang.org/docs/handbook/2/generics.html

Generics in typescript do not affect codegen, they are only visible to the typechecker.

The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.

What about this article, which says the type level programming features constitute a turing complete system: https://mjj.io/2021/03/29/type-level-programming-in-typescri...

Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation.

(More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833)

Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".

See the last paragraph of zarzavat's comment :) They wouldn't be added today, and they aren't widely used any more (they have non-codegen alternatives now). In other words, breaking changes in semantics shouldn't be a worry any more, since the TS team has consciously decided to attempt to avoid them a few years ago.

> Not to mention the majority of Node and FE developers who continue to use JS.

I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript

I've never used TypeScript. I've also never heard of this survey before, and I certainly didn't fill it out. I don't think these two facts are unrelated—according to their data, the vast plurality (48%, almost a majority) of the people who filled out that survey did so because they were on the mailing list for it. It's by no means a random or representative sample of the community. People who are more interested in surveys & new technology and are more likely to sign up to answer future surveys.

Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them.

I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.

I’m curious on how you manage large code bases without some kind of static typing and other checks that typescript provides, like object properties, etc.

Personally I find hard and scary to change things in js and being confident that it would work without breaking anything, with typescript I have that, some function rename, change parameter type, add/remove/rename object fields etc.

I found a couple of times when migrating some files to typescript misspelled names that would be hard to catch and passed the code reviews, that’s and easy task for the computer but harder for the developers, also using tools that makes your code reviews easy its great.

I have used TS in the past and want to use it more in the future, so I'm probably counted in that 78%... but for the vast majority of projects I'm not using it. Based on most comments, questions, examples in lib code, etc. I'd say that the number of people using TS is waaaay less than 78%.

It supports typescript, but you're not required to use it.

1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

> Python is much better as 'general purpose' right now

Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful.

> Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

You've certainly convinced me that Deno's single binary deployment is a useful feature.

> yeah but mostly node is used as a server software.

As a frontend dev, I use node tooling every day that has nothing to do with server code.

> Python is much better as 'general purpose'

Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem.

That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever.

Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable.

But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.

1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's.

3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies.

I haven't used CodeArtifact, but is it something you can deploy on-premise?

Why ship node_modules? Because you want to ship the complete app. At least rsync comes to the rescue for quick deploy of 10000 tiny files remotely.

That seems incredibly wasteful and time-consuming.

You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks.

Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.

[deleted comment]

This is something often overlooked by fans of typing. On the surface it may appear to some as being strongly typed, but it's a mirage [1] and frequently requires a lot more lifting, e.g. writing specific typings to work around shortcomings, just to make the types play nice together. That's not a feature of a strongly typed language, it's a feature of statically type-checked languages or schemas.

I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS.

[1] https://news.ycombinator.com/item?id=15090561

I've seen this take so many times an I simply don't get it. The notion that TypeScript can't be (some form of) strongly-typed because Javascript is (some form of) weakly-typed is just silly. CPUs are entirely weakly typed in this sense and this doesn't impact the typings of languages built on top.

JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types.

TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding.

In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.

> I've seen this take so many times an I simply don't get it.

That may sincerely be, because how it feels as you're using it doesn't align with the objective truths of how it behaves. The definition of a strongly typed language has been well-cemented for some time. TypeScript does not completely align with that definition, thus it cannot be considered truly strongly typed.

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

Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment.

The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.

The definition of a strongly typed language has been well-cemented for some time

What is it? Is e.g. C++ strongly typed in that sense?

I didn't like TypeScript when writing frontend only code, because the the iteration speed is just so fast in the browser.

But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.

Typescript is miraculously productive on the front-end as soon as you've got people writing at different "layers"—someone writing a frontend library, someone else handling state and actions, someone writing components for re-use, someone making it look pretty and using those components. You can be sitting right next to someone using code you wrote but rarely need to discuss it because the types communicate everything so damn well.

All typing is a mirage, enforced at various levels by various tools, whether that's a compiler during the build or a VM during runtime.

Everything gets compiled down to the same machine code in the end.

It's no more, or less future-proof. And as much as counting productivity of a programmer in LOC doesn't make any sense, your take on typescript does not either. It's extra security that matters. Typescript just prevents you from shooting your foot off (btw. show me, even small program, where Typescipt added 50% LOC)

> feels like TS is where its at.

Yes. It seems the majority of engineering decisions are tighly coupled to this expression right there. Future be damned because a Medium.com ex-FAANG said TS is where it's at

Bless them and the hype train, woe to developers 5 years from now.

> personally I don't see why you'd want to use anything other than Typescript right now.

Ditto. It's also important to remember that TS transpiles to JS, so you're not locked in in that sense.

(I've actually seens TS-to-JS-transpiled code that is much better than code that was written in/as JS in the first place.)

> personally I don't see why you'd want to use anything other than Typescript right now

A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.

How are you conscious of types without any tooling? And if you use tooling, then what's the difference?

When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it.

For example, JavaScript default args are really helpful for avoiding type errors:

const nameString = (name = {}) => { return `${name.first} ${name.last}`; };

Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).

...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change.

Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor

> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case,

Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.

IMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.

  basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.

Yes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).

Not to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be

So you do it manually? That's exactly what Typescript was created for, to use tooling and automation to handle these and it's been repeatedly proven to reduce bugs and increase productivity because of it.

Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.

How is TypeScript a crutch for API design?

API meaning data API/structure, not a public/restful API.