Hacker News Reader

> fix your shitty code with code that’s only less shitty because your compiler protects you

I mean... Yes? That's exactly what it's for. That's all it's for. That's all I want out of it, and that's what it does. I'm not really sure what you're railing against here.

My point is that I don’t think it fixes your shitty code.

Especially not if you’re not converting your entire project to typescript, and if you’re converting the entirety of it, then why not use a better language?

I think typescript is popular because it’s very java/c# like and I think it’s dangerous because it allows you to write bits of your program with the safety it provides and other bits without it.

So you’ll have programmers thinking they are safe, when they are really not.

TypeScript has structural (not nominal) typing, which makes it very different from Java/C# in practice.

Also, it doesn't fix shitty code. It just lets the compiler warn you when you're either making a mistake or misunderstanding some other part of your code base.

You should really try it before you say it doesn't help.

>I think typescript is popular because it’s very java/c# like

I think at beginning it was mostly used by developers familiar with Microsoft stack (.NET world mostly). But TS was not designed for C# developers, it was designed for JS ones! And I'm super happy it's becoming more and more popular in more "mainstream" frontend community.

I'll just copy my old response to some very old thread that talk about why it not just "a language for C# developers":

" Once sometimes asked me "Isn't Typescript a language for C# developers that don't know JavaScript" It's unfortunate that people think that TS is similar to C# just because it came from Microsoft. Flow language is like 80% similar to TS, but no one says it's similar to C#.

TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one in C#, and it was designed to fit well with JS patterns and idioms (structural vs nominal type system)

If you look at TS code that looks like C#, it's because JS looks like that (classes syntax, classical inheritance, lambda syntax - it's all ES7 (or ES2016/ES2017, or whatever it's called now) "

How is dart superior to TS? This is so uninformed. Just like your view of what a type system does.

Dart is very poorly designed, and they managed that even without the constraint of being 100% compatible with good old broken javascript.

It doesn't have null safety. This right here, is enough said and yet we could continue for hours, like how its standard library made the same 20 years old mistakes as java with things like "immutable collections are just mutable collections that throw exceptions", etc, etc.

Flutter might increase the demand and pressure on Dart quality but it's not a good language by any stretch of the imagination.

>How is dart superior to TS? This is so uninformed.

Speaking of uninformed...Dart is significantly faster for one. It's also not encumbered by being a superset to one of the worst scripting languages ever designed and, thus, does not have to deal with all of the baggage JavaScript brings with it.

>Dart is very poorly designed.

Amusing when you consider the clusterfuck that is JavaScript.

> just don’t write shitty code

Why do you use a screen to look at your code? Sure it helps you see what you are typing but I mean just don't type wrong to begin with and you don't need a screen to see what you just types! Just focus! Don't write that shitty code so you need a screen to keep it from being shitty.

I'm not trying to be snarky I'm trying to make the point that every single tool we use from a compiler, a type system, unit tests, a monitor... are tools we didn't have from the beginning as programmers. And every time a new tool came, there were always people saying "you don't need those crutches, just do it right instead" (Writing machine code, using punch cards etc). Also, they were always wrong.

> Want a number? Then call your argument numWhatever and check your input. It’s really as easy as that.

It sounds like you have reinvented the Hungarian notation - 15 years after it was phased out?

Seconded. I don’t see anything bad with typescript itself, but naive but passionate usage of perceived silver bullets tends to create terrible things. there are many terrible coffeescript/backbone codebases, overwrought usage of redux, etc...

Many of such overcomicated systems come from trying to use the latest coolest thing without thinking about if it improved anything. the tools were never used correctly and the person just moved on, marking JS as a shitty language with a shitty ecosystem.

When there’s always something new on the horizon it’s too easy to assume the previous difficulty was because of the old tool vs taking the time to just learn the tool.

There are many developers who don’t really understand MVC for example and so much pain comes from trying to ham fist a jquery mentality into one.

Typescript is superior for refactoring.

How?

I think it’s inferior because it allows you to rewrite only parts, and unless you convert your entire code base, then you’ll not have type safety. Because the bits that aren’t typescript won’t warn you when you compile.

Typescript will happily check your JavaScript code with “allowJs” compiler flag.

We write all our new code in good ol ES6 flavor of JavaScript and typehint in jsdoc. Typescript as a typechecker serves as very well.

It’s a great incremental adoption strategy.

can you explain how this works ? this is very interesting to us. We have a large react app (created using create-react-app) in ES6 and have been considering adopting TS gradually.

This seems a great first step.

AFAIU, just add typescript to your project or globally then in your project set a tsconfig.json file with the allowJs and esModuleInterop flags set to true. Don’t quote me on this but you can probably leave out most of the rest of the flags besides your source location. For example:

    {
        “compilerOptions”: {
            “allowJs”: true,
            “esModuleInterop”: true
        },
        “include”: [ “src/**/*” ],
        “exclude”: [ “node_modules/**/*” ]
    }

You’ll probably have to tweak that, but I hope it helps.

https://www.typescriptlang.org/docs/handbook/compiler-option...

See https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...

Also Google’s puppeteer project is typechecked with tsc and the type info is all in jsdocs

https://github.com/GoogleChrome/puppeteer

> Because the bits that aren’t typescript won’t warn you when you compile.

You just wrote exactly why static types are great: you get warnings when you forget to refactor your shitty (sic) JS code.

> I think it’s inferior because it allows you to rewrite only parts

That's exactly why it's superior, your project just becomes better step by step without an expensive and complicated full rewrite.

I agree. If you want a statically typed language, then there are plenty of excellent languages that compile to JavaScript. But making JavaScript "more like Java" has already failed back in the 2000s when ES4 was spec'd. JavaScript isn't the most advanced, beautiful, whatever language. Its point is that it's ubiquitous even beyond browsers. By using language extensions you're tying your code to a particular tool chain such as TS or babel, and are already developing not-quite-JavaScript; you could just as well use a better language in the first place.

I think the problem is that people are abusing JavaScript for large projects when JavaScript's purpose is small-scale DOM manipulation in response to UI events.

> Want a number? Then call your argument numWhatever and check your input.

Oh no, please not the ugly Microsoft naming syntax again... I thought that died a long time ago.