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

61–70 of 115 posts

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

#61

Post by yakshaving_jgt »

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…

> This cones as no surprise to me

If your comment were code, TypeScript would have caught your typo at compile time, versus JavaScript where your users would have experienced this (potentially catastrophic) error at runtime.

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

#62

Post by uasi »

eatonphil wrote: post #25

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

They are considering switching from tsc to a TypeScript compiler written in Rust[0][1], and `deno fmt` subcommand already uses it internally.

[0] https://github.com/denoland/deno/issues/5432 [1] https://github.com/swc-project/swc

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

#63

Post by giantDinosaur »

searchableguy wrote: post #54
thegreatpeter wrote: post #48

Earlier quoted context omitted.

Check out https://reasonml.org - created by Jordan Walke, the creator of React. Reason offers the best of both worlds - type safety without getting in the way and faster JS than what you'd write by hand.

As much as I would shill reasonml. Think before you adopt - it still requires more upfront work than typescript (you will have to write bindings for most things even popular stuff. You might end up fighting it too.) but as parent said, you get more expressiveness (algebraic types, powerful pattern matching, immutability, partial application etc) and sound type system with a speedup on both transpile times and actual…

To add to this, there are at least 3-4 pain points which... are just a pain with ReasonML, that can kinda counteract its type system.

- non-standard ordering of arguments between belt/standard library

- Ocaml's standard library actually generally avoiding the Option/Result type, in preference of exceptions, which is unexpected and a pain since it's an ML.

- package management involves manually adding things to the bsconfig (has this changed?)

- things randomly break between relatively minor Bucklescript versions, they broke something pretty important in like a .x release when I was messing around with it

- server side isn't good. It technically works but all the bindings are old or terribly documented, and you never really know if it's not going to blow up at some point.

Otherwise, I actually quite like it! None of those are actual core language complaints.

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

#64

Post by pjmlp »

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…

Same here, exactly for those reasons.

Non platform languages introduce those extra layers, while bringing along their own FFI issues, idiomatic libraries and other set of issues to care about.

I only use TypeScript alongside Angular, as one could somehow consider Angular to be the platform, for anything else Web related, pure JavaScript with script tags (yes I don't bother with JavaScript transpilers either).

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

#65

Post by ddek »

yakshaving_jgt wrote: post #61
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…

> This cones as no surprise to me If your comment were code, TypeScript would have caught your typo at compile time, versus JavaScript where your users would have experienced this (potentially catastrophic) error at runtime .

Had the original typo been corrected, TS would have also caught your reply and told you to update it.

This is the main value we get out of TS. If we rename a property on a viewmodel, we then update a TS file containing all the models. In this trivial example an auto refactor might propagate the change, but if it didn’t we get type errors all over the application telling us to change this. In JS, there’s an overwhelming possibility we miss one of these, and it isn’t picked up until production.

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

#66

Post by colinjoy »

BigDogS wrote: post #59
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?

These issues seem to be a symptom of bad/inexperienced developers rather than the tooling. Proptypes and linting may also help with some of your type/prop issues but competency will trump tooling most times.

I can make them use typescript more easily than I can make them good developers, I guess ...

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

#67

Post by speedgoose »

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?

Instead of writing types, you write tests.

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

#68

Post by cutler »

tanilama wrote: post #19
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, t…

Why? ES6 has been widely supported for quite some time now.

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

#69

Post by alangpierce »

untog wrote: post #2

This is quite difficult to make sense of beyond the initial description so I’m not sure about the current status. But it would be a shame to lose valuable type info because compile times are long... isn’t there a tool out there that does nothing except strip types from TS files? If you used that you could get quick rebuilds when developing but retain type checking when you do a full build. EDIT: Sucrase! That’s what…

Hi, Sucrase author here. I'm also having a hard time understanding the rationale here, but it looks like it's maybe a nuance around self-hosting. In general, for any regular TS project, I'd certainly recommend decoupling typecheck and transpile as separate operations and running typecheck alongside lint. IMO one of the nicest things about TypeScript is that you can run your code before you've figured out how to get the types to check out.

They do consider swc (which has roughly the game goal as Sucrase) in the conversation, so it seems like there's some consideration of a transpile-only approach. TypeScript's built-in `transpileModule` is probably the most reliable and officially-supported way to get the equivalent, and is much faster than running TSC with typechecking.

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

#70

Post by Vinnl »

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 think if you call it a DSL and are comparing it to CoffeeScript, you might be misunderstanding what TypeScript is/does for you, and you might be missing out.

If you're using ESLint, I'm quite sure you'd like TS as well, so if that is the case, you might want to give it an actual chance.

Post reply on HN