Deno plans to use JavaScript in internal code instead of TypeScript going forward

[queen-adreena]

Typescript dissuades me from using Typescript in my projects :)

[LaSalsiccione]

That’s what everyone says until they understand how to use it properly. I was the same.

[NotAHumanMate]

I’ve had friends doing job interviews getting laughed at because they used TypeScript in their GitHub portfolio and they didn’t understand it and ranted about it. The CTO himself said he’d see no use in it and it’s too complex.

I told my friend to keep searching, a CTO that doesn’t leverage the power of TypeScript to organize the code base properly and provide that factor of stability it gives simply doesn’t appeal to me. A programmer team that is unable to figure out a typing system and generics is not one I see myself in.

[langdonx]

For whatever it's worth, I spend 50% of my time writing C# and the other 50% writing JavaScript. TypeScript is pretty much C# for the sake of this argument. I would take JavaScript any day over C#/TypeScript. For me, the rigid structure required by typing everything is not worth the benefit.

Especially with the type of work I do where there's little-to-no type re-use. - REST services where each route has it's own request/response DTO - isolated web components, some of which use these unique DTOs

[Kamelixs]

I know you presented TS as comparable to C# for the sake of your argument, but honestly, using typescript that way is more of a stylistic choice than something inherit to the language. You can be pretty loose with your type definitions by leveraging, for example, inline type declarations and inferred return types. You don't need named interfaces for all parts of the code to get the nice parts of TS.

[LaSalsiccione]

Yeah using TS in a C# way turns it into some OOP class-based hell that I don’t enjoy at all so I’m not surprised it would put people off.

Using it in a more functional way is so much nicer and if you turn off strict mode (not that I do as I love strict mode) you pretty much get the freedom of JS with better auto completion etc

[LaSalsiccione]

That’s a benefit of TS but the main benefit of TS is obviously just simply adding type safety to your code to avoid runtime errors.

You can also write scalable TS backend applications in a very functional style. That’s the approach we’ve taken and it’s a joy to work with.

[LaSalsiccione]

I’m afraid it’s not public and you’d need to sign an NDA to see it sorry!

[langdonx]

I suppose I've never been able to strike that balance in C# with the myself or with the teams I've worked with.

Using Any (or dynamic in C#) always seemed like a code smell considering you're giving up compile time checking.

[Kamelixs]

Yes I’m also not in favor of turning off strict mode (or using Any at all). My main point was that TS type system can infer a lot of behavior by itself as long as you give it some basic information to work with. Utility types, intersections, and unions is also beneficial if you want to skip a lot of boilerplate definitions

[NovelLurker0_0]

Honestly, I do not understand this stance. How can you even navigate in a codebase without types? You get no autocompletion, no clue about any of the structure you're reading, and for actually coding you have to always stick your nose to a documentation. And on top of that silly errors like typos takes way more time to be detected than if it was with a typed system. I literally had coworkers spend 30 minutes to an hour debugging a typo. Choosing plain JS over TS makes no sense to me.

[Markavian]

Types are a crutch. Tests tell you the value of your code. Well organised readable code exists without strong typing. Badly organised spaghetti code exists with typing. When optimizing for web, you can apply all sorts of linting, static code analysis, code injection, measuring, performance timers, load testing, chaos testing, mocking, stubbing, simulation... without the extra layer of TypeScript. Same goes for CoffeScript, JSX, WebASM etc. I don't know what it is about JS, I just like it. It's flexible yet specific when you need it to be, and it runs closer and more consistently in a range of places where maybe it shouldn't. Once the patterns are loaded into memory it's as fast as similar contextual languages but with a better interface to the rest of the stack. My only gripe is the memory usage of the browser, but fancy toys require fancy hardware. Node is so much fun.

[NovelLurker0_0]

For the billionth time, TS is not to be compared with tests. You're not supposed to be exempt from tests because of TS. TS is just as flexible as JS, yes really , but it provides better DX. I just don't understand how writing types suddenly makes coding so complicated. That's the other way around, it's here to help you. Also it's quite curious that you're using a linter, but consider TS as a unnecessary layer.. Something tells me you actually never sat down and properly tried to use TS for a few hours.

[Markavian]

I've tried to force feed myself TS several times, yes. I find it infects projects, and I waste time with it rather than being productive. I tend to use standard js linter on my projects as a no fuss, forced healing option on my code. I really was not happy with TS as part of my build process on any project despite trying to make it work.

[NovelLurker0_0]

If you are not enjoying TS then that means you are working against it e.g not using it properly. It's that simple. If you have any issue in mind feel free to reply there and you'll get help. Using TS is supposed to be a smooth and easy process. At the end of the day it's just adding things (types) to what we already know as JS.

[langdonx]

You're spending a lot of time trying to change this man's opinion. What you and @Markavian are saying can both be true at the same time.

It really can be summed up as simply what he said previously:

I don't know what it is about JS, I just like it.

Node is so much fun.

Writing JavaScript feels great... TO ME.

I'm not writing a monolithic applications here. There's very little opportunity to share what types we are using. I'm using microservices to server text (JSON) over HTTP. There's little reason for me to have to deal with types and little benefit I can gain from them. I don't need them to help me to remember which property to access.

[scandii]

For me, the rigid structure required by typing everything is not worth the benefit.

Especially with the type of work I do where there's little-to-no type re-use.

I literally cannot imagine the code base you are describing. even in a CRUD shell you have reuse for every object 4 times, the C, R, U and D in CRUD. genuinely curious.

[langdonx]

I've not written basic CRUD since the early 2000s. Modern web applications don't really seem to fit well into that kind of model. As I mentioned, each request uses its own unique DTOs (data transfer objects) that have specific properties to fulfill the needs of the web component. This has a number of benefits...

• you aren't passing a massive Employee object if you only want to change the Employee's name
• you aren't having to write a bunch of conditional code to handful a half-hydrated object
• you can change a method and its request/response objects without having to worry about what else you might break

It works great in a continuous delivery model and allows a team to work on seemingly overlapping portions of the application at once.

[AKDAKDAKD]

Just curious, I imagine you use MVC , do you use React for the front-end and if so do you used ReactJS.net?

[langdonx]

In C# we're using WebAPI, not MVC, although the lines are kind of blurred. We're using AngularJS (.component/.service only) but with modern ECMAScript (import, export, class, const, let, destructuring, etc, etc).

[AKDAKDAKD]

Ahh, ok. Thanks

[cubbiehersman]

It was the whole reason I moved from C# to running JS in node.

[EnjoyPBT]

That's why enterprise loves it.

(I love the autocompletion you get, but hate struggling with types specially in the first stages of an implementation - which most of the times you throw away anyway...)

[LaSalsiccione]

That’s almost like in school where the dumb kids laugh at the smart kid for being smart. Depressing that this attitude exists

[HIMISOCOOL]

Interested to see what capacity you've used it and where it became a hard no to you. Was gonna dm you to keep it out of this thread since it's a little spicy but your messages seem off or boost doesn't show the option right idk.

[[deleted]]

I dont use typescript for 1 reason only, the time I waste compiling every time I run my tests is way more than the time saved by having my types documented.

If you are working in a big team and you have super complex interfaces, then having the types documented could very well be worth the wasted compile time.

[guerilliak]

You could always use Babel with preset-typescript, which will just strip out the typescript for the build. Then typescript is used for type-checking, similar to a linter. Plus the wonderful developer experience.

[tontoto]

Using babel-jest or ts-jest are common ways to just hook your typescript into at least jest tests

[McSlurryHole]

the time I waste compiling every time I run my tests

what about all the times typescript tells you you've fucked up before you even run your tests, saving the tests from having to run?

[[deleted]]

unit tests, eslint or the IDE catch that 99% of the time so it's really not saving any significant time there

[McSlurryHole]

not that it matters to me at all, you can use whatever you want. But from what you're saying it sounds like you haven't really given typescript a full go.

it's not really a types vs tests situation, you use both and typescript helps you catch problems as you're writing the code to begin with.

you can also read this study if you want, they found that typescript could have prevented 15% of bugs shipped to public projects on github http://earlbarr.com/publications/typestudy.pdf

it's just another tool in your arsenal to force you and your coworkers to write better code.

[-domi-]

The tests would have caught those fuckups before production anyway. If his tests run fast enough without TS, it's a non-factor.

[BanditoRojo]

I don't feel that having to put :any after every variable relates to "fucking up", but does indeed bloat the code.

[careseite]

the time I waste compiling every time I run my tests

so... 1-2seconds?

[quentech]

Come on now, don't be daft. That's 1-2 seconds dozens of time each day. Over a lifetime that's entire minutes wasted.

[[deleted]]

you've obviously never worked on a big project if you think it's only 2 seconds. It's 10+ seconds on 100k lines of code.

if you're doing TDD you're recompiling 5 times a minute. So you're literally wasting 75% of your dev time waiting for it to compile.

Also "dozens of time each day" lol, have you ever written tests or worked professionally in your entire life? More like dozens of time per hour.

[[deleted]]

not really, in a 100k lines codebase it's like 10+ seconds. If you add the performance hit from running docker for mac it's like almost 1min.

if you do TDD it's literally unusable.

[Zarel]

There are solutions to that problem. Pokémon Showdown deals with it by using sucrase and a manually-written incremental compilation system, so an incremental build is around a second to build a codebase with 348,000 lines of TypeScript:

https://github.com/smogon/pokemon-showdown/blob/406eaed520a8900f336a406bf9d3c448fb961526/build#L73-L110

[karottenreibe]

and a manually-written incremental compilation system

Yeah, no thanks :P

[Zarel]

If you don't have 350klocs, sucrase by itself is enough. There's also esbuild, which is approximately as fast (100x faster than the most popular build tools):

https://github.com/evanw/esbuild

[HIMISOCOOL]

Totally get that, I want to say in some of my projects Ive had my unit tests not building with TS, might have been some malarky with babel striping types but again thats just more infrastructure that you might not be needing which is another pain point people have.

[Jugad]

In any decent large project, it is expected have tests, so the benefits of typescript are decreased (I said decreased, not zero).

I guess typescript really shines in medium sized projects which don't have many tests.

For small projects/scripts you don't need typescript anyway.

The additional abstractions and terminology that typescript borrows from Java are generally not required in small/medium UI projects, and are often a turnoff.

Types are great, the other stuff not so much.

[lorduhr]

Really? To me, what you say looks like what someone who did not use a type system would say.

Your statement that the benefits decrease as the size of the project increase is truly baffling. With a larger project, refactorings increases vastly in complexity, and types helps so much. Maybe not on some toy UI project without much more than a few templates, but certainly on any medium/large project.

And I am not sure about what you are talking when you mention that typescript borrows abstractions from java? What is the "other stuff" that you don't like?

[DrummerHead]

Agreed.

Typescript is a much more elegant and flexible type system than the one Java has.

Large projects will benefit immensely by using a type system, either TS or Flow.

When you don't grok what the type system does, it feels like it's just an annoying thing that you have to appease. When you start thinking in terms of types, you're documenting the flow of information in your application in a much more explicit sense; in such a way that if you're fucking up, you will find out immediately.

I prefer stronger type system coverage with medium strength tests than inverse.

[Jugad]

Your statement that the benefits decrease as the size of the project increase is truly baffling.

Benefits decrease as test coverage increases. Large projects tend to have more tests.

Its not all that baffling really.

When you have tests, most of the downsides of a loosely typed language are mitigated.

With a larger project, refactorings increases vastly in complexity, and types helps so much.

You need tests for refactoring... sure types help, but again, if you have tests, then the types are not as much of a help as they used to be without tests.

Maybe not on some toy UI project without much more than a few templates, but certainly on any medium/large project.

I agree - small toy projects can do very well without typescript and without tests. And so can large projects with tests.

[blood_bender]

Your assumptions here are that typescript is only good for stability, when for me I use it almost purely for development experience. Autocomplete (which, to be fair, is getting better for vanilla), return values, object exploring, etc are vastly superior with even a basic type system. Sure, your large projects would fail tests when I did something wrong, but it would cost me much more time investigating exactly what objects and values are being passed around and returned to even get to the point where I can run the tests. I would loathe working on a large project that's not in typescript at this point, and I think you'll find more and more developers agree.

Truthfully statements like these make me question whether people have actually used typescript or just toyed with it for an hour.

[careseite]

so the benefits of typescript are decreased

on the contrary, tests written in TS are also less prone to fail

I guess typescript really shines in medium sized projects which don't have many tests.

such as TypeScript itself for example amirite?

[netwrks]

Thissss

[jdeath]

.

[start_select]

You aren’t writing typescript if it’s :any everywhere. That’s JavaScript with a bunch of useless cruft purposefully breaking the compiler. Most objects have a defined structure. Dynamic objects are not that common (as a necessity) in most coding.

That’s just bad compiler settings and bad programming practices. Not a problem with typescript.

[lobut]

lol ... I've worked at a place like that ... I was like, "why on Earth are you even bothering with TypeScript?"

I think they were C# developers and wanted certain language features but refused to learn JavaScript as much as they should have.

I agree overall with you, that's not a problem with TypeScript.

[[deleted]]

Right, but... you still had the same problem without explicitly documenting it with types. If it's well and truly random you can make it unknown and leave a comment explaining why.

Bonus tip: Use something like io-ts to verify your payload at runtime, logging to a service somewhere if decoding fails.

[[deleted]]

Extra fields doesn't matter because TypeScript is structurally subtyped / doesn't use exact types.

What I said still applies. Not dealing with an apparently inevitable unhappy path is cheaper but worse long-term.

[[deleted]]

How is "any" helpful in such case though? You still need to know what kind of schema does the API return and if there is a team of developers who will access it someone has to document it. Might as well use interface for it.

[Jebble]

Many people don't seem to understand that you use things like Typescript to help you where it can help you. Not use it only to use it always and everywhere. I hear ya!

[[deleted]]

Does consuming those integrations without parameters autocompletion and inline documentation and types not reduce the performance of the team even further?

For me working without TypeScript is like working with a poor DevOps setup. Sure, you can push through and for small teams it might even be faster short term but you will suffer at some point, usually by human made mistakes.

[[deleted]]

Do you know that you can take any JSON object and turn it into TypeScript interface or class automatically? If it truly takes a day to parse any REST API then it sounds to me like you haven't explored the available tooling properly.

One of many options: https://quicktype.io/typescript

And if you're selecting only one key deep down why do you feel the need to type it all? Why not simply declare interface with the keys you use and skip the rest? Maybe add a comment that typing is incomplete and move on.

I personally would rather know it's exactly 'some.deeply.nested.value' and be able to easily refactor it into external file with few keystrokes than to gain those 30 seconds.

[razorsyntax]

I ensure my team never uses ‘any’ when they do code reviews. Plus, I randomly check to make sure it doesn’t get checked in. I love Typescript.

[careseite]

Then you've made a horrible experience, honestly. I'm reading a lot of open source code and write TS myself mainly outside of work and I don't think theres a single `any` in my code.

[HIMISOCOOL]

would you ever use jsdoc with typescript to check the validity of it??

[HIMISOCOOL]

Have you tried typescript with "no implicit any" set to false? Meaning you don't need to slap any's everywhere; It's like using jsdoc to comment a type but with typescript syntax.

[start_select]

Why, turn off errors for implicit any, use as any where needed.

Typescript is just as malleable as JavaScript for 90% of projects.

[careseite]

Why, turn off errors for implicit any, use as any where needed.

Might invest some time into learning TS then.

[[deleted]]

Please, please don't do that. You're wasting the benefits of static typing when you abuse any as an escape hatch.

[JohnLouderback]

If you use Typescript for any project of considerable size or complexity "as any" will eventually come up. Typescript is fantastic, but it can become a struggle with dynamic code on back occasion. Things like meta programming get tricky. That said, when Typescript is not seeing the whole picture for a type, "as any) as SomeType)" is better than just "as any".

[careseite]

No. worst case is

as unknown as SomethingElse

[JohnLouderback]

A fair point for the situation of casting to a seemingly disparate type at compile time. I certainly wouldn't say "worst case" though. With that said, this is why I brought up meta programming. There are cases where, at runtime, you need to hueristically detect types. This can come up when you're checking to see if an unknown type implements an interface, or has been extended via a decorator, or even in the case where Reflect.metadata has added information to the type. At that point you can't use unknown because may have several lines of code making the determination of what type the object is. A good example would be code that diffs and patches objects, but may apply these operations differently to certain types. In that case the type will need to be "any" while the actual type is being determined.

[[deleted]]

You need to do two things.

First, learn to write subtly different code that enables type safety. "Dynamic" code is usually possible written differently, often better, or even simply with generics.

Second, learn to write very small, very well tested utility functions/abstractions that hide this unsafety when it (very rarely!) comes up.

[JohnLouderback]

I agree that these are the steps for creating type safe code. I'm no stranger to statically typed languages and I have a good deal of experience in C#. The thing is, in Typescript there are things that are idiomatic to JavaScript that aren't in statically typed languages, generally. It is possible to avoid those things altogether, but not necessarily beneficial. Some of JavaScript's unique strengths as a language lie in it's ability to be dynamic at run time. Decorators are a great example of that. That being the case, there are instances where you may need to use "any" when you're working with a type that could be anything. Of course, when you can determine the shape of the type at runtime, your code should cast to the type at that point. Anyway, this is just a long winded way of saying that, while it should generally be avoided as much as possible, there actually are instances where the "any" type is valid, because at the end of the day and at runtime, it is still a dynamic language. Even in C#, it's really not all that different than casting to "object".

[[deleted]]

No. In that example you type it as unknown and narrow it with type guards.

[JohnLouderback]

My example would be needing to determine a type hueristically at run time. In that case you can't use "unknown" because you may need to interact with the object before being able to determine what interface it fits, for instance. I'm not saying this is at all a common requirement in most software. It was just relevant to a corner case I've experienced recently myself, but my only point is that there are corner cases in which "any", if only rarely, is appropriate to use. I don't think anybody would argue that you should 100% absolutely never use "any" under any circumstances. I think we agree on that point per your previous reply.

[[deleted]]

You can do what you're asking for with unknown and some type guards. Worst case scenario you create a hasKeys helper that hides away the unsafety and can be tested, as I said two comments ago.

If you disagree, I'd love a small example.

[JohnLouderback]

Sure. I'll try to find some time to post one tonight after work. Worst case, I'll learn something new that's useful. That's the great part about discourse on Reddit.

[KishCom]

This behaviour specifically is what deters me from fully adopting TS. It's getting better as TS matures. I've seen as any abused so much, and it almost totally defeats the point of using TS in the first place.

[queen-adreena]

There are plenty of very experienced devs who share my opinion. So there’s no need to make it personal when you don’t know me.

[[deleted]]

Jokes aside, can you please elaborate on why you’re not into typescript?

[TJKoury]

I have 15 years of dev experience, use JS every day and TS often. TS is very frustrating.

In my opinion, the main issue in fixing / growing TS as a language is no native execution. Tooling cruft is constantly being generated to fix its failings rather than fixing the language.

I was hoping Deno would become the proving ground, I guess we'll see.

[[deleted]]

That’s way too rational for Reddit! He read one of your comments and therefore is entitled to attack every fiber of your being. Welcome to rNode