TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Deno will stop using TypeScript

241 点作者 diablo1将近 5 年前

52 条评论

inimino将近 5 年前
There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn&#x27;t ever considered some obvious solution you came up with in 0.7 seconds.<p>[1]: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4&#x2F;preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS...</a><p>First paragragh of that document:<p>&gt; Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don&#x27;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&#x27;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&#x27;t draw any broader conclusions.
评论 #23601214 未加载
评论 #23594803 未加载
评论 #23595805 未加载
评论 #23596859 未加载
whoisjuan将近 5 年前
This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal.<p>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.<p>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)<p>I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks.<p>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.<p>Once again. Probably unpopular opinion, so I don’t mind the downvotes.
评论 #23592621 未加载
评论 #23592787 未加载
评论 #23592625 未加载
评论 #23592814 未加载
评论 #23596034 未加载
评论 #23592850 未加载
评论 #23592640 未加载
评论 #23592817 未加载
评论 #23592755 未加载
评论 #23593008 未加载
评论 #23593396 未加载
评论 #23593751 未加载
评论 #23592624 未加载
评论 #23597451 未加载
评论 #23592595 未加载
评论 #23593340 未加载
评论 #23593068 未加载
评论 #23595949 未加载
评论 #23596092 未加载
评论 #23592571 未加载
评论 #23595162 未加载
echelon将近 5 年前
Why such a large, important project would want to drop static types is beyond me.<p>&gt; 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<p>This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just fine.<p>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.
评论 #23592622 未加载
评论 #23592843 未加载
评论 #23592596 未加载
评论 #23595006 未加载
评论 #23593787 未加载
评论 #23592869 未加载
评论 #23592696 未加载
vimslayer将近 5 年前
Here&#x27;s the Deno Design document with the reasoning and some discussion about the decision: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4&#x2F;preview" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS...</a><p>This post adds little to what&#x27;s already said there.
diffrinse将近 5 年前
I&#x27;m a little shocked at some of the outcry in this thread. People are making it sound like they&#x27;re switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol&#x27; JavaScript. You still can&#x27;t trust function parameters to be what they say. It&#x27;s a Babel configuration with inline doc annotations.<p>If people are serious about types, then why isn&#x27;t more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they&#x27;re getting the benefits of (strong?) types when they&#x27;re just populating the auto-complete in VS Code.
评论 #23594432 未加载
评论 #23593746 未加载
评论 #23593816 未加载
评论 #23594645 未加载
jakear将近 5 年前
I’m a long time fan of TS, but I think this is a very exciting decision —- I have always been of the opinion any reasonably large project should workout a doubt use TS, so hearing about how this goes for them in 2&#x2F;5&#x2F;10 years in terms of how easily people are able to maintain code they didn’t create, how readily large refactorings can be made, how often runtime type errors occur (not just the literal TypeError, but all the things TS can catch, like null checks, index typing checks, etc) will be quite interesting.<p>I wish them luck!<p>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.
评论 #23593020 未加载
searchableguy将近 5 年前
They should just use deno to run their setup, there would be no compilation if they did that. ;)<p>Someone is trying to rewrite tsc in rust for speed up here - <a href="https:&#x2F;&#x2F;github.com&#x2F;swc-project&#x2F;swc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;swc-project&#x2F;swc</a><p>Cool project for runtime checking with ts - <a href="https:&#x2F;&#x2F;github.com&#x2F;gcanti&#x2F;io-ts" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gcanti&#x2F;io-ts</a><p>Edit: Remove unmaintained runtime type checking library.
评论 #23592721 未加载
mirekrusin将近 5 年前
I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn&#x27;t work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type declarations and when declaring functions and pretty much nowhere else. The code has interesting haskell&#x27;ish feel to it, ie. most of the code looks something like this:<p><pre><code> const ofId &#x2F;*: (Sql, number) =&gt; Promise&lt;User&gt; *&#x2F; = (sql, id) =&gt; ... </code></pre> I&#x27;m very happy with it after using it on quite complex projects, writing libraries (ie. functional combinators for parsers, assertions&#x2F;runtime types, template sql generators; and the rest from apis, business logic to anything that is needed).<p>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.<p>Code editor support is not as good as ts but it does the job.<p>Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn&#x27;t need transpilation step, can be edited as is; I&#x27;m free to use any directory structure, ie. I often use root directory to drop files, they have natural require&#x2F;import paths, no configuration etc.<p>For me, it&#x27;s a joy to code like this.
评论 #23594912 未加载
zdragnar将近 5 年前
&gt; It’s worth mentioning that Deno will stop using TypeScript only for the internal Deno code: the Deno user code will still be in TypeScript and thus type checked.
devit将近 5 年前
It seems it might be an issue with their development abilities or problem-solving motivation:<p>1. It seems that they write a &quot;.d.ts&quot; file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them &quot;it was too much overhead and complexity when we attempted it before&quot;, which caused them to give up, a very dubious course of action.<p>2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn&#x27;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.<p>3. They claim that &quot;having two Body classes is obviously wrong&quot; (?!). Of course having two classes with the same name in different namespaces&#x2F;packages is perfectly fine in properly designed languages (including both JavaScript and TypeScript). Their &quot;Header&quot; shadowing problem also might be due to a lack of understanding of namespaces.<p>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.<p>Given that their codebase seems to be complex according to their compile time claims and that they don&#x27;t seem particularly skilled given their claims, using a type-deficient language will most likely result in software full of bugs.
评论 #23593528 未加载
评论 #23592741 未加载
评论 #23592832 未加载
评论 #23594042 未加载
eatonphil将近 5 年前
I don&#x27;t remotely see TypeScript as the end state of statically typed JavaScript. I think it was the first major project to prove how static typing could work and benefit browser applications. Flow and TypeScript are just the first generation. In the future I expect the type system to be integrated with the runtime. While there are projects that give you this (Elm, Reason, Bridge.net, Fable, etc.), they are nowhere near as universal as TypeScript nor is that really their aim.
评论 #23592870 未加载
root_axis将近 5 年前
&gt; <i>I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous</i><p>You do have that class of bug. That&#x27;s like a cpp programmer saying they don&#x27;t need smart-pointers because they never introduce memory leak bugs. You&#x27;re a human.
brown9-2将近 5 年前
&gt; One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations<p>... choice of programming languages is irrelevant here.
nathancahill将近 5 年前
Needs &quot;internally&quot; at the end of the title.
pvg将近 5 年前
Discussion from two weeks ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23462506" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23462506</a>
koolba将近 5 年前
Why remove it entirely rather than split off compilation and type checking? I’m not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.
评论 #23597428 未加载
IBCNU将近 5 年前
I used Typescript for 2 years, and I&#x27;m happy to report I&#x27;m dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there&#x27;s more disadvantages than advantages re: time.
评论 #23593687 未加载
评论 #23593402 未加载
评论 #23596715 未加载
RivieraKid将近 5 年前
I wish Dart was more popular as a JS alternative. I&#x27;ve been using it recently it&#x27;s really surprisingly productive and fun.
评论 #23595960 未加载
评论 #23594060 未加载
pjmlp将近 5 年前
So it happens again, yet another project discovers that whatever improvements a guest language brings into a platform, using it also has its costs versus using the main language of the platform.
WClayFerguson将近 5 年前
Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up.<p>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.<p>All you&#x27;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.
评论 #23594058 未加载
fbn79将近 5 年前
This is a great victory for Ecmascript. Typescript is a great hinting support language, I use it with JsDoc to check my (not transpired, vanilla js) code. But it cannot replace JavaScript and is not a JavaScript superset. I think If anyone what to accept the drawbacks of have transpiration of source files can choose better alternative to typescript.
smhmd将近 5 年前
Everyone is drawing conclusions without much context. Read the design doc[0].<p>[0]: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4&#x2F;preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1_WvwHl7BXUPmoiSeD8G83JmS...</a>
holtwick将近 5 年前
I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results:<p>(1) Use a faster bundler like esbuild, here vite&#x27;s similar considerations [1]<p>(2) Use Flow [2] and just strip it away before distribution like this Babel module [3]<p>---<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;vitejs&#x2F;vite#typescript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vitejs&#x2F;vite#typescript</a><p>[2] <a href="https:&#x2F;&#x2F;flow.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flow.org&#x2F;</a><p>[3] <a href="https:&#x2F;&#x2F;babeljs.io&#x2F;docs&#x2F;en&#x2F;babel-plugin-transform-flow-strip-types" rel="nofollow">https:&#x2F;&#x2F;babeljs.io&#x2F;docs&#x2F;en&#x2F;babel-plugin-transform-flow-strip...</a>
k__将近 5 年前
&quot;Always bet on JavaScript&quot; holds true, I guess.
thayne将近 5 年前
There are tools to transpile typescript only, without doing typechecking, which dramatically reduces &quot;compile time.&quot; It&#x27;s very useful for a quick development iteration cycle, and then do a full type checking pass before merging and during CI.
zvmxczxvmcz将近 5 年前
I&#x27;m doing a medium&#x2F;large project in Coffeescript 2 and it&#x27;s totally awesome. Rarely a type related bug and I&#x27;m progressing waaay faster than having to deal with TS in my way.<p>But for anyone enjoying to specify their types in detail, have fun!
评论 #23594580 未加载
hakcermani将近 5 年前
Was using JS for about 6 yrs now and decided will start using TS for a new Node.js project. Admitted it has its warts ... hit my first bottleneck rightaway when parsing the request query param. TS Express bindings declare it as string | string[] | ParsedQs | ParsedQs[]. Ok extract it &#x27;as&#x27; string and move on. But I find as I am using it more and more it is getting better (or I am getting more disciplined!) .. maybe I am reading this wrong re the long compile time reported, could the code not be broken into modules so the compile is more isolated ??
评论 #23592673 未加载
gjpowell将近 5 年前
It seems weird to ask other projects to use Typescript when running on Deno when Deno isn&#x27;t using typescript internally? If you&#x27;re the Deno team wouldn&#x27;t you want to dogfood Typescript?
评论 #23595980 未加载
评论 #23593988 未加载
Peteris将近 5 年前
This seems to lend more credit to ReasonML. Compile times are faster and it doesn&#x27;t bring the associated complexity of object types while still retaining the benefits of static typing.
chvid将近 5 年前
Thank you.<p>Finally people are speaking out against the madness of TypeScript.<p>Don&#x27;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&#x27;s the users of the library get hints and direction from an editor like Visual Studio.<p>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.<p>Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...
j1elo将近 5 年前
I just hope in 5 years we&#x27;re not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that!<p>(I&#x27;m just referring to this nice talk about the regretful mistakes done in Node: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;M3BM9TB-8yA" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;M3BM9TB-8yA</a>)
jeswin将近 5 年前
Typescript may not work for all types of applications - in fact there is no language that does. So picking one project and generalizing it often comes out of inexperience.<p>As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn&#x27;t mean it&#x27;s good for your project.
oliwarner将近 5 年前
You know when you say a word over and over again and it starts to lose meaning?<p>Well, I didn&#x27;t have a clue what Deno was before, but now it&#x27;s barely letters in a screen. This post says Deno <i>way</i> too much. Deno.
mikl将近 5 年前
&gt; While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. It has flaws like any other language.<p>This is not a language flaw. It is a tooling problem.
burtonator将近 5 年前
I&#x27;ve migrated to Typescript and have been using it for about 2 years now. Maybe 1.5...<p>TS is the best language I&#x27;ve used. It supports frontend and backend and strict typing and it&#x27;s scalable so I can refactor and know that my code still works.<p>The one thing its not good at is ML where Python is better but that&#x27;s mostly because Python has better library support (not language design).<p>Here&#x27;s the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code.<p>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.<p>&gt; - TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process<p>I have a HUGE typescript repo and using a Macbook Pro from 2015...<p>With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that.<p>If your build is taking a long time - you&#x27;re doing something wrong.<p>&gt; 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<p>What? How? That doesn&#x27;t make any sense. You&#x27;re doing something wrong here. If all the code is in typescript, you have no additional work to do. If it&#x27;s in JS you just have to write your own .d.ts files manually.<p>Honestly it seems like this team just needs to sit down and understand how their tools actually work.<p>The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types.<p>Many older projects just don&#x27;t publish types and if you rely on them, and they refuse to publish types, you&#x27;re going to be in a bit of pain.<p>You can write your own types though and we&#x27;ve been doing this internally and for some repos just forking them so it&#x27;s a bit easier to work with them. They usually lag on publishing their types.<p>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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;burtonator&#x2F;polar-bookshelf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;burtonator&#x2F;polar-bookshelf</a><p>... is the project we&#x27;re working on if you want to check it out. Our internal build system isn&#x27;t fully published yet as we&#x27;re in the process of reworking it but we&#x27;re open source so you can take a look if you want.
评论 #23595331 未加载
jimbob45将近 5 年前
Is there a reason we can ONLY use JavaScript in the browser? The world would immediately become better if we added a different language compiler on in instead.
评论 #23596111 未加载
wufufufu将近 5 年前
Has anyone else experienced these issues? This reads more like product placement for Deno than a sincere criticism of TS.
评论 #23592795 未加载
untog将近 5 年前
&gt; While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not.<p>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.<p>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.
评论 #23592567 未加载
评论 #23592700 未加载
errantspark将近 5 年前
I&#x27;m stoked on this change, frankly the TS layer being included in Deno felt like a mistake from the get-go and I&#x27;m glad they&#x27;ve come around on it. I&#x27;ve seen many transpile-to-JS languages come and go. Javascript is eternal.<p>(Though I also think TS is a verbose mess made so that enterprise programmers&#x2F;managers can feel safe, but even if it was great I still think this would have been a good choice)
nojvek将近 5 年前
When Deno initially mentioned they run Typescript directly I was intrigued. It’s like running GCC every time you want to invoke the script.<p>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.<p>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.<p>I’m not entirely sure why they have two copies of things. The doc doesn’t give much detail.<p>If you want things to be fast like nodejs, then the other option is to use &#x2F;&#x2F;@ts-check comments on JS files, or with compiler allowJS and checkJS settings. Webpack checks all their JS.<p>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.<p>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.<p>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.
dbnoch将近 5 年前
I felt like the article and associated google doc were fishing for reasons to remove TS until ry finally mentioned &quot;typescript provides an extra 500 lines and the namespaces make the code harder to reason with (V8 ingests these files directly)&quot;. IMO that was the only solid reason for the change.
aogaili将近 5 年前
Always bet on Javascript.
chadlavi将近 5 年前
oh I thought at first that this meant they were dropping _support for_ typescript, not that they were stopping using ts under the hood.<p>Getting closer to the metal seems good!
kumarvvr将近 5 年前
HN gods, an off topic question.<p>Would Deno become the new Node?<p>Do you see a vibrant ecosystem building around Deno?<p>What I am interested to know primarily is, is the architecture &#x2F; stack &#x2F; goals and vision that resulted in Deno viable in the long term?
评论 #23596855 未加载
moogly将近 5 年前
Has anyone seen any comments by the TS team on this? Maybe they would be amenable to helping out if the Deno team contacted them.
评论 #23592988 未加载
评论 #23593038 未加载
underdeserver将近 5 年前
Due respect, these are issues with how the Deno team uses Typescript, not with the language itself.<p>&gt; TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process<p>Umm, you can compile single files, and serve them individually. It&#x27;s no different from bundling (e.g. with webpack) Javascript.<p>&gt; 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<p>Then use a better structure?<p>? 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 <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;4748" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;4748</a><p>Then consolidate the two classes...? How is the the language&#x27;s fault?<p>&gt; 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<p>Well, it can be. Fix your build rules.<p>&gt; 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<p>Again, not the language&#x27;s fault.<p>---<p>We&#x27;ve been using Typescript for a couple of years now, and it&#x27;s been great. By trying to do things the right way, it actually <i>forces</i> 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.
评论 #23593594 未加载
评论 #23592938 未加载
评论 #23595719 未加载
seemslegit将近 5 年前
Why Deno ?
评论 #23595787 未加载
jackjeff将近 5 年前
I’m very perplexed about the reasoning.<p>Aside from the compiling takes time issue, the rest sounds like trolling.<p>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.
jbverschoor将近 5 年前
Yeah. Same same. Not working, so let’s just fix it by creating another ecosystem instead of fixing compiletimes etc.<p>I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be like Mike”. Errr Linus... Lowrey
评论 #23592598 未加载
chmln将近 5 年前
&gt; TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process<p>They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;flatpickr&#x2F;flatpickr" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;flatpickr&#x2F;flatpickr</a>
meowzero将近 5 年前
We were actually considering Deno because of its TypeScript support. We have a sizeable TypeScript codebase written for Node. This will probably make us more likely to stay in Node.<p>EDIT: I didn&#x27;t read the article thoroughly. It looks like they&#x27;re still supporting Typescript user code.
评论 #23592956 未加载
评论 #23593001 未加载
cocktailpeanuts将近 5 年前
Thank God, I would really appreciate this. The TypeScript usage was the one thing that I didn&#x27;t like about Deno.<p>Why add complexity to a new project which starts from scratch? JavaScript is good enough and there&#x27;s no need to make it confusing by adding another layer.
评论 #23592550 未加载
评论 #23592633 未加载
评论 #23592549 未加载