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

11–20 of 115 posts

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

#11

Post by _bxg1 »

esperent wrote: post #7

It's important not to read this as a critique of Typescript. Rather, it's a note that it's not a good fit for this one particular performance critical piece of code. It sounds like they are discussing the central code runner of deno. I would have expected this to be compiled to JS in any case, but it seems like they are compiling the runner, then compiling user code. Of course that's slow. It's also not representativ…

a) Any static type system has things that it can't express elegantly or maybe at all. In my experience, the more "meta" your project is, the more you're going to run up against these bounds. So it makes sense that this could be the wrong use-case for TypeScript.

b) There is a valid, broader point to be made here that while TypeScript itself doesn't carry any runtime overhead (by design), it can in some cases force you to contort your code, so that it can be type-verified, in ways that have a runtime impact. In my experience (a couple of years writing TypeScript professionally) this is uncommon and not a huge problem, but does happen occasionally. It's also worth noting that the vast majority of these cases can be papered-over using //@ts-ignore, "as" casting, etc. if necessary.

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

#12

Post by austincheney »

esperent wrote: post #7

It's important not to read this as a critique of Typescript. Rather, it's a note that it's not a good fit for this one particular performance critical piece of code. It sounds like they are discussing the central code runner of deno. I would have expected this to be compiled to JS in any case, but it seems like they are compiling the runner, then compiling user code. Of course that's slow. It's also not representativ…

I don’t read that as a criticism of TypeScript at all. That is entirely self inflicted due to a name collision between an identity in their definition file and some weird class extension insanity.

I don’t use classes or inheritance in my own code and it’s incredibly liberating. The result is data structures and interfaces that are primitive and independent, which removes so much fragility.

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

#13

Post by temporallobe »

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 compiles to JavaScript anyway, and sometimes it does so in very odd ways that makes it difficult to understand the relationship between what you wrote and what it produced. IMO, straight JavaScript is more than adequate for most scenarios if you know the language well enough, especially with the powerful features built into the more recent versions. In my 20 years as a (mostly) front-end developer, I have not heard any convincing argument in favor of a transpiled JavaScript pseudo-language. Of course there are advantages, but most of these can be solved with better code organization and architecture.

I will say I don’t quite feel as strongly about CSS pre-processors like SCSS, which I really enjoy, however I still prefer plain old CSS for the same basic reasons.

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

#14

Post by tuckerconnelly »

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…

I feel the exact same. Reminds me too of Nassim Taleb's idea that, if something as already existed X years, it's likely to exist another X years. I'm skeptical of the staying power of these transpilers.

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

#15

Post by abraxas »

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…

The reason those transpilers exist is that the target language is so excruciatingly awful. At least to those willing to endure the pain of transpiling.

It's an unhappy situation for all involved really. JS should be a language that targets some kind of bytecode that the browser executes rather than being a direct target.

Perhaps WASM will some day replace all webpage scripting allowing everyone to use languages of their choice.

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

#16

Post by mikewhy »

MBCook wrote: post #3

What is ‘deno code’?

As mentioned, Deno is the new project from the creator of NodeJS.

Here, as far as I can tell, "Deno code" specifically related to the code shipped to the developer / user using Deno, the compiler / runtime.

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

#17

Post by Agent766 »

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?

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

#18

Post by fearingreprisal »

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 on.

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

#19

Post by tanilama »

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…

Typescript helps you to avoid most obvious bugs(wrong classes, non-existent properties, basically to escape the undefined hell) that is the point of it, which I really like and find enormously helpful for medium-size JS project (10k-50k LoC)

Also I don't think the transpiler argument holds in today's JS ecosystem. Everything is transpiled. Unless you are developing in barebone ES5 syntax and avoid babel as a whole, then some level of transpliation is inevitable. Yet, I didn't find debugging that much difficult with correct setup.

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

#20

Post by NetOpWibby »

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…

I find TypeScript incredibly useful in reminding me my code is terrible. I use it to save me from myself.
Post reply on HN