Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

docs.google.com

Post reply on HN
Print view View original

21–30 of 115 posts

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#21

Post by irjustin »

temporallobe wrote: post #13

This cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain old JavaScript and have never really seen the benefits of DSLs like this. Coffeescript was especially pointless to me when I had to use it on a project. My reasons are simple: debugging becomes much more difficult when you add a layer of abstraction. It compil…

At this point, I don't believe it would be unrealistic for MSFT to make TS to get its own engine or a fork of V8 similar to how PHP became HACK over time for FB.

I think that'd be super cool.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#22

Post by mikewhy »

CGamesPlay wrote: post #10
dfabulich wrote: post #6

JS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types

It's interesting, I wonder why the proposal doesn't talk about leaving TS code and simply ignoring the syntax using something like babel to preprocess it out (without needing to run the type checking outside of CI).

tsc can also do that, but I think there's something else here.

I'm not really sure what this post is getting at. I trust Ry knows the issue better, but from what I've read I have the same questions as everyone else here:

- Why is Deno defining interfaces and classes like that?

- Will this mean losing type checking in projects using deno?

- Why not strip types in development and only check at commit/push/build times?

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#23

Post by Andrex »

Agent766 wrote: post #17
temporallobe wrote: post #13

This cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain old JavaScript and have never really seen the benefits of DSLs like this. Coffeescript was especially pointless to me when I had to use it on a project. My reasons are simple: debugging becomes much more difficult when you add a layer of abstraction. It compil…

My team started development of a React SPA. It was initially written with jsx. As we're starting to implement more, I'm finding more and more cases where the js code was wrong; property names that don't exist, wrong types being passed around, and non-existent props being used. How do you suggest addressing this in a 10 dev team when developing in js?

Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#24

Post by hn_throwaway_99 »

fearingreprisal wrote: post #18

At what point are people going to just admit that implementing applications in Javascript outside the browser is a poor idea? The ecosystem has been in this poor state for years. It's not like the ecosystem is getting worse. This is the best it's ever been, and it's still horrible. There's so many better, more mature alternatives with much better ecosystems: Python, Java, C#, Ruby, Go, Haskell, Perl... The list goes…

Your comment is somewhat incomprehensible, because this article is not about building end user applications in Typescript. It's about building the container itself in Typescript. I switched to Node from Java a couple years ago, and to Typescript within the past year, and I have never been on a team that has had this level of productivity.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#25

Post by eatonphil »

I started using Evan Wallace's TypeScript [0] implementation (and bundler) written in Go and it's pretty fast (there are benchmarks too). I'm surprised this kind of thing is not something Deno's pursuing. Having used esbuild I see the future of web tooling as not necessarily written in (or compiled to) JavaScript.

[0] https://github.com/evanw/esbuild

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#26

Post by hn_throwaway_99 »

dfabulich wrote: post #6

JS engines should be able to ignore TS annotations, out of the box. https://github.com/samuelgoto/proposal-pluggable-types

FWIW Flow actually let you write type annotations as comments so that the code was syntactically valid JavaScript. I'm not sure if TS ever had something like this.

https://flow.org/en/docs/types/comments

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#27

Post by jakelazaroff »

Andrex wrote: post #23
Agent766 wrote: post #17

Earlier quoted context omitted.

My team started development of a React SPA. It was initially written with jsx. As we're starting to implement more, I'm finding more and more cases where the js code was wrong; property names that don't exist, wrong types being passed around, and non-existent props being used. How do you suggest addressing this in a 10 dev team when developing in js?

Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.

How would that catch a misspelled prop name?

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#28

Post by fearingreprisal »

hn_throwaway_99 wrote: post #24
fearingreprisal wrote: post #18

At what point are people going to just admit that implementing applications in Javascript outside the browser is a poor idea? The ecosystem has been in this poor state for years. It's not like the ecosystem is getting worse. This is the best it's ever been, and it's still horrible. There's so many better, more mature alternatives with much better ecosystems: Python, Java, C#, Ruby, Go, Haskell, Perl... The list goes…

Your comment is somewhat incomprehensible, because this article is not about building end user applications in Typescript. It's about building the container itself in Typescript. I switched to Node from Java a couple years ago, and to Typescript within the past year, and I have never been on a team that has had this level of productivity.

What part of it couldn't you comprehend? I understand what the article is saying. I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript.

In response to your personal experience, I'll share my own: I switched from C++ to Java, to .net, to Node.js, to Typescript. Working on Node/TS I have never been on a team that wastes so much time fixing silly problems that a better language would simply not allow to happen in the first place. I have also never worked on a team that spends so much time dealing with issues in poorly written community packages, or arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#29

Post by gameswithgo »

Andrex wrote: post #23
Agent766 wrote: post #17

Earlier quoted context omitted.

My team started development of a React SPA. It was initially written with jsx. As we're starting to implement more, I'm finding more and more cases where the js code was wrong; property names that don't exist, wrong types being passed around, and non-existent props being used. How do you suggest addressing this in a 10 dev team when developing in js?

Enforce shared ESLint rules on commit, and use Airbnb+React with most of the defaults set.

a sufficiently complex linting process is a transpiled language, with the same downsides

Re: Design Doc: Use JavaScript instead of TypeScript for internal Deno Code

#30

Post by karatestomp »

temporallobe wrote: post #13

This cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain old JavaScript and have never really seen the benefits of DSLs like this. Coffeescript was especially pointless to me when I had to use it on a project. My reasons are simple: debugging becomes much more difficult when you add a layer of abstraction. It compil…

One of the best things about TypeScript is that it compiles to very normal-looking JS. Its compilation step is almost entirely just stripping out type data, by design. I went through coffeescript pain before and like many didn’t expect to ever be happy to use a compiles-to-JS language, but TS really is different. If they change direction and start to add tons of stuff that doesn’t translate cleanly, I’ll get worried. Until then it’s very nice and comes with an escape hatch of just taking its output and making that your new codebase. It’s that clean-looking.
Post reply on HN