[1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
First paragragh of that document:
> Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
Object.defineProperty(HeaderImpl, "name", { value: "Header" });
export let Header = class Header { }
> Who knows if this kicks Header out of some optimization path in V8
It doesn't.
---
Forgive me for being suspicious of the whole thing because a couple of the rationalizations don't make sense, I'm sure there are some valid points raised there.
The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".
> we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product
Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run.
But perhaps this is something beyond the simpleton comprehension of us novice programmers
My personal experience is that there’s a size threshold where static tying becomes more useful. Below this threshold, the problems solved by static types are still mostly tractable by humans and things like linters. The threshold is different for every program and set of developers.
10K lines is small enough IMO.
> But perhaps this is something beyond the simpleton comprehension of us novice programmers
That’s just flamebait, the comment is better without it.
Here are some key words that many kibitzers here could benefit greatly from internalizing:
> > The target audience is the 5 to 10 people who work on this particular internal system.
> Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run.
Are you one of the people responsible for maintaining those 10KLOC?
> But perhaps this is something beyond the simpleton comprehension of us novice programmers
I believe Ryan Dahl would admit to having made more mistakes in large system design than most of us will ever have a chance to. Who knows, he may have picked up a thing or two along the way that most of us haven't.
This could also just be an internal product decision that really doesn't affect anyone outside the core project team, while some of us here are projecting way too much onto it.
Okay, unsubscribe. This is not the tone you use to interact with the community. This is brash, elitist hogwash.
TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS.
It have never felt about it like something that would make my code better or more organized. It definitely slows me down with very little benefits in return. (Again, can’t stress enough that this is a personal opinion based on personal use cases)
I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks.
Of course I also appreciate when I can identify that an error is coming from a type mismatch, but as I said I learned to program in loosely typed languages first, so I never created that concept of defining types in my head. I’m always extra-aware of types mismatches in my JS code and is usually the first thing I check when something goes wrong. But I have never felt the need to have a way to explicitly define the types that I’m working with. I honestly fail to see the benefit when a large amount of code that you have to interact with (libraries and such) was written in classic JS.
Once again. Probably unpopular opinion, so I don’t mind the downvotes.
You can refactor your entire codebase with a few operations and don't have to worry about anything breaking.
Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone?
Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs?
Where are your dynamically dispatched calls even used, and how do you know you modified them all?
One of the most common operations in building new features is plumbing new state through the system. Types are there to help you in such perilous times.
Types are refreshing and reassuring.
People often say this, and I don't get it. What JS tests are you writing that become unnecessary in TypeScript? I've used a fair amount of TypeScript and plain JS, and end up with similar amounts of tests for each. With JS, I almost never want to verify only that a value is of a specific type; I want to look at its contents, which means I'd need to write the same test in TypeScript.
Usually what I do is that once a project has reached a point of maturity and the requirements merit it I move parts of it to a typed language (go). That’s for things that need to be both performant and maintenable long term without much effort.
I actually benefit from that rewrite in that I have yet another chance to review assumptions and address higher order
I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous to me and cumbersome and makes certain dynamic programming concepts difficult or impossible. I don’t want to give up power just because other developers are sloppy.
I want my code to be readable, and succinct. A lot of times that requires creating functions dynamically at runtime or some other such thing that would void the benefits of a typing system anyways.
I recognize that in working with a team where people have other styles, varying attention to detail levels and skill, they can’t all be trusted to produce bug-free code without the constant nagging and overhead of a pedantic type system.
My solution is not to employ another piece of technology to solve this problem, rather it’s just not to work with those people.
If you can’t write dynamic code without a bunch of type errors at runtime, learn to be a better programmer first before blaming the tools.
For small projects, dynamically typed languages are fine. but as the project grows bigger, the static typing will help and will make thing simpler.
As the project grows, refactoring will be an issue. Static typing will make it simpler to refactor.
Tests are smaller.
Reading the code will be easier since you know the contract of functions.
Fewer runtime errors since most errors will be caught at compile time. Also, the stronger the type system it is, the more it will be caught at compile time.
I don't think it slows me down that much. It's a little more typing, and there is compile time overhead. In some cases, you have to work your way around the type system. But at least with Scala, I am confident my code will work as intended as long as it compiles successfully. I spend less time debugging in runtime and writing tests. I think static typing might save time in the long run but not short run.
Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.
I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity).
Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement.
Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out).
From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.
A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production.
I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address.
The fact is, a large portion of unit tests solve the same problems that strong types solve.
By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality.
Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can?
I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.
If you eliminate a class of errors by doing so, isn't that still less errors overall?
Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.
"Pass in three parameters with a callback in the fourth position. The second param is configuration so pass in a string, but if you need to really customize stuff actually pass in an object instead and by the way if you don't have a third parameter then just chuck the callback there, why not!?"
Typescript is great in that somehow it is technically possible to write types for existing code written like this, but writing new code like that is cumbersome enough to prevent it.
"This is an array of strings, but it could be an object. If it's an object it will have this key and based on the name of the key it's this type. But it could also have or not have this other key and..."
ARghhhh! You can tell what kinda language the back-end was written in with that crap because while TypeScript can actually type most of that stuff it's a huge mess in something like C#, Golang, Java, etc.
The problem is, you'd have to have the documentation open to make the slightest tweak to anything. No help from the type system.
I don't agree with you. I don't think that loose typing is based on opinion, and I do not think it is because people who start out in statically typed languages are unable to "grasp" loose typing. I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects.
Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages.
An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL.
In an untyped environment, only by understanding ALL upstream code are we able to make assumptions about downstream code. We know that the "string URL" is a sequence of characters, and nothing more.
However, if we have a type, we can have a "URL" type. Since we have a type, we do not need to concern ourselves with all upstream code, only the code associated with the "URL" type. So, instead of potentially thousands of places to seek information about our "URL" variable, we have only one: The "URL" type. We look at the implementation of that type, and we know weather or not the URL has been validated.
Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. This makes your application more secure, more readable, and easier to maintain.
Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar?
> I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects.
People are not abandoning or adopting anything, both static and dynamic typing have existed for as long as computers have been a thing. Hell, LISP is older than pretty much every statically typed language still widely used, methinks.
> Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages.
Where's this empiric evidence of all these advantages you mention? I'm a bit shocked that I managed to miss it... And that so did half the industry. Such conclusive study would have ended that and the industry would have coalesced into this unquestionably superior type system you mention.
> An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL.
Can't do that with static languages either. Call it a type (or class), call it a parsing function, ultimately the result is the same. You need something to ensure that it is an url. Those exist in dynamically typed languages and are not obviated in static ones.
> Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application.
Conversely, types substantially increase the amount of overall code one has to write.
These has never been a matter of opinions. The flamewar still rages after decades because what's the factually best type system hasn't been found. Hell, we might be likely closer to prove that that question has no answer.
In short, ultimately everything you said was just, like, your opinion, man.
This is true, and confirmed by the TypeScript team
https://stackoverflow.blog/2020/06/15/talking-typescript-wit...
> Do you remember why the team came up with TypeScript, why you wanted to release something like this?
> A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call “application scale.” Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages— C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling.
> The language experts at Microsoft looked at the situation and said, well, we could try to write a new language like people had done before. There are projects like Script#, which takes C sharp and turns it into JavaScript, or languages like CoffeeScript that said, what if JavaScript had a different syntax? But what they decided instead was to just take JavaScript and add static types on top of that.
> At the time, JavaScript was experiencing a renaissance of growth, where they were adding features to the language again for the first time in a pretty long time. People wanted to use those cool new features, like arrow functions and classes, and they didn’t want to wait for all browsers to adopt them. They wanted to be able to use those features right away. I think those were the three things that TypeScript offered upfront: static typing for error finding purposes, leveraging that static type information for tooling, and providing the JavaScript features of tomorrow, today.
Seriously?
> They wanted to have that static typing available both for conceptual scalability and for the tooling
Sounds like they understood the loose nature pretty darn well.
TypeScript adds additional type checking at transpile time to code. The assumption that the people who can write code with these more rigorous checks can't write the same code with it all removed ... I would examine that a little more closely.
It's the same BS as Python and JS, the lack of typing but fundamental nature of systems that require data to be typed means half my code is checking that everything is properly typed!
Dynamic types have their uses, but in general they're more trouble than just writing typed code to begin with. And when your type system is more a suggestion than anything it provides little benefits.
On the contrary, as somebody who learned programming with a mix of static and dynamic types, I felt like TypeScript showed me what a good type system was capable of in giving me the best of both worlds.
Instead of being pedantry, I felt like the type system was actually on my side for once and helping me to write correct code with fewer unaccounted-for corner cases and unexpected runtime crashes. And it does that while avoiding the feeling I got from previous statically-typed languages I used where the type system felt like a straight jacket incapable of expressing non-trivial concepts and relationships.
I use Typescript everywhere I need Javascript these days, it's a breath of fresh air, and my code feels maintainable, tractable, and much easier to refactor.
They like TS a lot. And it’s obvious why. Having said that, I know no “old” programmer who used to prefer a different paradigm to express a wish to switch to TS.
Rich Hickey put it well in this quote “ Functional programs are desirable because they are simpler and easier to reason about, due to being mathematical i.e. they are free of time and place.”. I agree.
I disagree, though. Instead of going with a lengthy list of why I think TS is great and disproving your arguments, which I assume everyone else will do, I'll admit that types can be hard, and so doing them right, or even doing them as best as one can, will always take some time. For a small project or a small team, that time might be hard to justify. But I think this is resolved with a good understanding TypeScript.
Even so, TypeScript might not make sense for many projects or small teams, but I find it hard to defend that TypeScript won't be a net win for any medium team or medium-size project.
This was my believe before, but I've seen multiple teams go from JS to Flow or TypeScript and the result has always been, when there's expert guidance, extremely positive. Productivity goes up, more bugs are fixed because there's more confidence in the safety of the changes, more people feel confident to work on any part of the codebase (vs just the people that originally built it or have worked more on it), and the defect rate dropped dramatically.
All it takes is once and you'll become a statically typed language evangelist.
People who use types regularly feel the same way about typed languages. Types don't test as many things of unit tests of course, but feedback you get on what they do test is immediate - literally as you type in a IDE. The speed of that feedback is important. It's a well know in quality circles that errors discovered later cost far more to repair. In the case of types in makes you don't write a hundred lines of code under the expectation a type provides method foo(), only do find out later the foo() provided takes an argument argument you don't happen to having lying around.
While payback for types over unit tests is smaller, the effort required to use types is at least commensurately smaller, and the amount of typing required is way smaller, particularly now we have type inference. Also in my experience unit test's need to reach every line of your code forces some pretty tight constraints on how you structure it. Who hasn't had to refactor some block of code so you could test some obscure corner case catering to an unexpected error? Types don't require that - the compiler always sees everything. None of this matters much if you are going to write unit tests anyway of course, but no one does that for small projects. This is another advantage of the type system - it's always there, even for 5 five liner.
Finally, types come with an added bonus. They give the compiler more information to work with, which means the compiler can make programs run faster. Rust talks about cost free abstractions, which the extreme case: the compiler knows so much about what you are doing it generates no code at all. In rusts case it rarely has to check for if a pointer references null before accessing, and greatly reduces the number of array bounds checks, has no garbage collector, and the pattern of a function checking the number and type or argument in order to implement overloads just disappears - along with the runtime overhead of doing the checking.
Ultimately, for any serious work, especially enterprise level work, your team members may include people of different calibers.
In such a case, where you have to work with code written by other members of your team, it becomes a serious problem to develop quality code.
For lone developers, it should not be a problem. But in enterprise settings, I think that is the reason why Node is not popular.
Compile time errors are much quicker and cheaper to detect and fix than runtime errors.
It just happens to be that I have never been exposed to the circumstances that would make me re-evalute TypeScript merits.
Accidentally mixing incompatible types is mostly a problem for junior developers. I'm much more likely to accidentally put on my pants, socks and shoes in the reverse order in my daily life than mix up incompatible types in my code.
The solution is not to add stickers all over your clothes to remind you which way is the front or what order you need to put them on; you don't need more tools, you just need more focus.
> TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations
This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just fine.
These folks are free to do what they want with their project, but this is not a good look, especially to those that are skeptical of the javascript ecosystem.
As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript
I've witnessed teams that have switched from static typing to dynamic typing before, due to complaints about compile times and a lack of ability. It doesn't take long before their testkit balloons and they spend 10x the time on testing, dwarfing any savings they made by eliminating compilation. Or worse, the code turns into something magical but untouchable, lest something break...eliminating the ability that they imagined they would get.
Remove the browser practical monopoly, and JS popularity would vanish.
There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates!
If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.
Lisp programmers use check-type[1] a lot, they proclaim[2] types for performance optimizations and they often deftype[3] if not only for code clarity. And then we have CLOS and its dispatching on types/classes...
[1] http://www.lispworks.com/documentation/HyperSpec/Body/m_chec... [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_proc... [3] http://www.lispworks.com/documentation/HyperSpec/Body/m_deft...
I object, C is that.
On the contrary, I think it shows great maturity in the decision making process. Many highly experienced developers have stayed away from TypeScript for reasons like those mentioned in the article (mostly to do with the build environment, source mapping, versioning complexity, etc...) These are very significant problems and not worth the small benefits which static typing brings.
There are places where no-typescript would be appropriate, but they’re vanishingly small. The idea that the benefits static typing brings are small is just laughable.
The reason this is such a hard choice is because static typing brings great benefits, so choosing to forgo that is not easy.
pshh
This post adds little to what's already said there.
If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.
I have been using GWT, too hard to use comparing to typescript with pretty much same benefits.
It doesn't come with the fp-approach that io-ts takes, and has, in my opinion, significantly better error reporting. Just plugging this here because I believe that zod is grossly underused :)
Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started.
For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript.
tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?
Note that I'm not saying that Elm would be better than TS or any other language or anything like that, just commenting about the runtime checks. Obviously languages have their strengths and weaknesses (Elm has plenty of both) and TS has had good reasons to go with their design goals.
I wish them luck!
One note of concern though: in their design doc they say incremental compilation is the number one problem and list multi-minute compile times. That’s huge! I wouldn’t use TS either of it took minutes to compile my projects. However, I think there’s room for improvement in their tooling if they took some time to explore what other large TS projects do instead of just giving up on it entirely —- VSCode for instance has incremental compilation in hundreds of ms or less.
Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc
Cool project for runtime checking with ts - https://github.com/gcanti/io-ts
Edit: Remove unmaintained runtime type checking library.
const ofId /*: (Sql, number) => Promise<User> */ =
(sql, id) =>
...
Lack of libdefs is not a huge problem in my case. I have strong preference for shallow or no dependencies in projects and for things I use 3rd party code there are types or were converted from ts or simply added. Better support would help here but it was not a deal breaker.
Code editor support is not as good as ts but it does the job.
Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn't need transpilation step, can be edited as is; I'm free to use any directory structure, ie. I often use root directory to drop files, they have natural require/import paths, no configuration etc.
For me, it's a joy to code like this.
I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works!
Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.
1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action.
2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead.
3. They claim that "having two Body classes is obviously wrong" (?!). Of course having two classes with the same name in different namespaces/packages is perfectly fine in properly designed languages (including both JavaScript and TypeScript). Their "Header" shadowing problem also might be due to a lack of understanding of namespaces.
4. They seem to conflate JavaScript vs TypeScript with single file vs multiple files. Of course you can have a single TypeScript file or you can have multiple JavaScript files and bundle them with any JS bundler or just concatenate them.
Given that their codebase seems to be complex according to their compile time claims and that they don't seem particularly skilled given their claims, using a type-deficient language will most likely result in software full of bugs.
I'm with you on the rest of the points, though. I don't quite understand it, either. But then I'm not working in that codebase every day. Easy to criticize people from the outside!
Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescript code at work, I end up just modifying the compiled javascript to debug things because the compile loop is painfully slow.
https://www.typescriptlang.org/docs/handbook/release-notes/t...
Until those languages make themselves feel just like js or completely remove excessive js interlop, they won't be as mainstream.
Sure, if you want to make maximal use of the strong typing of F#, you'll have to annotate JS data as it comes in, but that is necessary complexity, not incidental. And if you're happy with having your F# code "dynamically typed", there's zero ceremony around importing JS stuff.
You do have that class of bug. That's like a cpp programmer saying they don't need smart-pointers because they never introduce memory leak bugs. You're a human.
... choice of programming languages is irrelevant here.
This strikes me as a similar sentiment to “Requirements are for managers, not engineers”
The Haskell community strongly disagrees...
Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?
Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people.
As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.
Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc.
All you're doing by switching from TS to JS, is trading one set of minor problems (which are solvable) to a more vast set of even larger problems that are NOT solvable.
https://github.com/Clay-Ferguson/quantizr
I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
(1) Use a faster bundler like esbuild, here vite's similar considerations [1]
(2) Use Flow [2] and just strip it away before distribution like this Babel module [3]
---
[1] https://github.com/vitejs/vite#typescript
[3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...
But for anyone enjoying to specify their types in detail, have fun!
are you working with a team? if so was it easy to get buy-in?
If the request ends up with the query param as an array, there isn't a runtime to validate the cast and now the variable is typed as `string` but is actually `string[]`.
I think a safer approach is to use a validation library or refine the type with an if stmt and returning an error when it isn't a string.
I use the following lint to prevent all casts except `as const`: https://github.com/typescript-eslint/typescript-eslint/blob/...
Finally people are speaking out against the madness of TypeScript.
Don't get me wrong. It is a technical achievement to put a static type system on top of JavaScript. And for libraries, it is useful. It let's the users of the library get hints and direction from an editor like Visual Studio.
But as a language. It is just not good. No way anyone would end up with a design like that had it been built from scratch without going through JavaScript first.
Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...
(I'm just referring to this nice talk about the regretful mistakes done in Node: https://youtu.be/M3BM9TB-8yA)
As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.
Well, I didn't have a clue what Deno was before, but now it's barely letters in a screen. This post says Deno way too much. Deno.
This is not a language flaw. It is a tooling problem.
TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works.
The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design).
Here's the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code.
You can save a lot of time now writing new code and not using strict typing. OR you can spend a little bit of time now, maintaining your types, and save a MASSIVE amount of time later.
> - TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process
I have a HUGE typescript repo and using a Macbook Pro from 2015...
With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that.
If your build is taking a long time - you're doing something wrong.
> The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files
What? How? That doesn't make any sense. You're doing something wrong here. If all the code is in typescript, you have no additional work to do. If it's in JS you just have to write your own .d.ts files manually.
Honestly it seems like this team just needs to sit down and understand how their tools actually work.
The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types.
Many older projects just don't publish types and if you rely on them, and they refuse to publish types, you're going to be in a bit of pain.
You can write your own types though and we've been doing this internally and for some repos just forking them so it's a bit easier to work with them. They usually lag on publishing their types.
If you want to avoid all this pain you can just use webpack for your build system and Typescript for your code. We use lerna to build a multi-module system with --hoist to avoid duplicate dependencies.
https://github.com/burtonator/polar-bookshelf
... is the project we're working on if you want to check it out. Our internal build system isn't fully published yet as we're in the process of reworking it but we're open source so you can take a look if you want.
But I suppose they are aware of this flag.
A sign of the times I guess that a build system requires 8gb of ram to run. Could be we're doing something wrong, but from what I understand we're using a pretty vanilla setup.
Woah, woah, hold on. This case is showing that in the very specific, atypical case the Deno team are using it in, TypeScript is not the right fit.
I’d rather read something that actually interviews the Deno folks about what they are doing, the underlying document is a pretty free ranging discussion and this writeup is making a few assumptions.
N=1. That is all.
(Though I also think TS is a verbose mess made so that enterprise programmers/managers can feel safe, but even if it was great I still think this would have been a good choice)
That being said I run ts-node all the time with transpile-only and that is decently fast. Even on production where the minimal cost is incurred once when loading the module.
As for their problems mentioned on the document. That Header class has a .d.ts conflict on an interface. That could be solved with having namespaces in .d.ts or having I prefix for class interfaces. We do this all the time in our codebase.
I’m not entirely sure why they have two copies of things. The doc doesn’t give much detail.
If you want things to be fast like nodejs, then the other option is to use //@ts-check comments on JS files, or with compiler allowJS and checkJS settings. Webpack checks all their JS.
TSC now also has an option to automatically generate .d.ts from JS files with jsdoc comments. With declarationOnly compiler flag. Many existing JS projects already do that.
So TLDR is. You don’t have to ditch Typescript totally. Typescript can purely just be a checker that you run at CI time and it will work quite well with existing JS code. Although if you want super strict safety the .ts syntax is less verbose and nicer to write. Even then transpile only mode is much faster than running full tsc.
Remember: TS is a superset of JS. All JS is valid typescript. Sometimes we gotta structure the JS properly and that’s where the issue is rather than the typesystem.
Getting closer to the metal seems good!
Would Deno become the new Node?
Do you see a vibrant ecosystem building around Deno?
What I am interested to know primarily is, is the architecture / stack / goals and vision that resulted in Deno viable in the long term?
Personally, it makes me cringe to see hard-coded HTTP URLs in source code files for loading dependencies. They present it like we're stupid for using package managers all this time. What used to be a simple command line option (changing a package repo) is now a thousand file edit. Excellent.
> TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process
Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript.
> The Typescript structure that they’re using in the source files that create the actual Deno executable and the user-facing APIs is creating runtime performance problems
Then use a better structure?
? TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations https://github.com/denoland/deno/issues/4748
Then consolidate the two classes...? How is the the language's fault?
> The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files
Well, it can be. Fix your build rules.
> They’re maintaining two TS compiler hosts: one for the internal Deno code and another other for external user code even though both have a similar goal
Again, not the language's fault.
---
We've been using Typescript for a couple of years now, and it's been great. By trying to do things the right way, it actually forces us to organize our code better. I think the Deno project would benefit from refactoring their code to solve their issues, instead of blaming the tools.
[edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]
Taking up Typescript then ignoring best practices when trying to use it is unfortunate. This kind of thing would be a teaching moment for a junior engineer.
It's like saying you don't want to use a dishwasher because if you stack bowls on top of each other, it doesn't clean them well. Well, a dishwasher has its faults - a lot of dishes are not dishwasher-safe, etc. - but your reason kind of misses the point.
I think that's the whole point. It's not the right tool for their specific goal.
In their design doc[0], they agree that Rust glue code should not be written in TS: compiled code "full of weird namespaces."
From the design doc discussion[0]:
ry: manually managing the d.ts files has been great - it's very much part of the public interface - we need to have 100% control over it we do not want random compiler-generated __namespace0123 in there This is the same situation - but for the bundle It's not good that we do not have visibility nor control over what code is in there. for example, the TS compiler worker, has 15k lines of code in its bundle - EXCLUDING typescript.js TS compiler worker is about 500 line thing that interfaces between ops and TSC this is caused by our attempt to "self host" the internal code self hosting is cute - but if it's effecting performance and the ability to make improvements - it's an unnecessary feature https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 ^--- here is what we ship for the compiler worker we call this code every time deno runs
lucacasonato: Ok, wow. I hadn't seen this. That changes things...
ry: does the compiler worker really need to generate a UUID? https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#... (no) yes, this is fixable within the current system .. but the point is that we're abstracting away the important parts V8 does not run typescript. It runs JS. We need to have a good handle on the JS we ship If we don't try to self-host, we don't need a sourcemap for the internal code. There's 1mb off the executable right there. The point is the internal typescript comes at a cost - and that cost is too high.
lucacasonato: So the actual issue is the bundling and opaqueness that that brings with it. It makes sense to stick to pure JS in that case. Its annoying that type checking is gone, but youre right. This is not the kind of code that should be in the runtime.
ry: not like the code isn't full of "!" anyway. TS is great, but it gives a false sense of security.
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
"TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process"
and
"The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files"
If you're compiling Typescript, the .d.ts files are output by the compiler. The only time you need to manually keep them in sync is when you're writing .js and manually writing the .d.ts.
Aside from the compiling takes time issue, the rest sounds like trolling.
If the code was organized in a way which is inefficient and confusing, I fail to see why checking types at runtime instead of compile types improves the structure. It’s a completely separate problem.
I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be like Mike”. Errr Linus... Lowrey
They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode.
EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.
> Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
(Almost) all npm packages that are written in typescript expose .js and then .d.ts files, so you can't "just import the .ts". This is because of huge variances in tsconfig.json files.
Why add complexity to a new project which starts from scratch? JavaScript is good enough and there's no need to make it confusing by adding another layer.
To some people, JS itself is relatively confusing, and TypeScript reduces that confusion.
EDIT: And... someone's clarification is saying this is internal framework code, not userland support for TS. Seems like a non-issue, really. They don't want to use it, but want to provide support for others to use it in their projects.
This doesn't change anything, it's for their internals. Why anyone would ditch static typing on a large collaborative project is beyond me though.