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

51–60 of 115 posts

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

#51

Post by bryanrasmussen »

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?

I think most of this can be solved by proptypes, although true proptypes is not as thorough as TypeScript.

I had some negative experiences with typescript in a large React project but in that case the most negative experience was that often the type definitions provided by React and common type libraries didn't match our needs, which made doing something that would normally be quick difficult and long.

The reason for types not matching was often that we needed to generate HTML emails as part of things, which means you need a lot of deprecated attributes, so probably you won't have this problem.

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

#52

Post by [deleted] »

tuckerconnelly wrote: post #14
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.

[deleted]

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

#53

Post by eyelidlessness »

nailer wrote: post #47
mikewhy wrote: post #35

Earlier quoted context omitted.

This also works in TypeScript's favor. Meaning you can skip writing tests that simply check you're giving the correct props.

I don't think anyone /does/ write tests that simply check they're giving the correct props. They write unit tests, and props are part of that.

This also works in TypeScript's favor. You get test coverage which you would never write. A "simple" component that doesn't have any logic and doesn't warrant a test still checks its prop types, and you don't have to do anything other than make the compiler pass.

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

#54

Post by searchableguy »

thegreatpeter wrote: post #48
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?

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 run time.

You can leverage ocaml/ml as well as js ecosystem. Mix different files and syntax.

Bsb is also faster than tsc.

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

#55

Post by reificator »

fearingreprisal wrote: post #28
hn_throwaway_99 wrote: post #24

Earlier quoted context omitted.

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 n…

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

Excuse me for asking the obvious, but if they would never pass a technical skills test at the company you work for, why are the people who did pass using code that these maintainers wrote?

It sounds like the right approach is to sidestep them and fork the project yourselves. That way you'd clearly have a much more competent team maintaining it, and implementing all the features you need.

That is if you trust code written by someone of such standards in the first place. Really you should just rewrite it from scratch so that you know it's never been touched by anyone not at the competency level of your elite squad of code monkeys.

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

#56

Post by AaronFriel »

francis36012 wrote: post #31
tuckerconnelly wrote: post #14

Earlier quoted context omitted.

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.

Typescript has been around since 2012. Going by the quote, it is likely to still be around in the next 8 years.

TypeScript has been around since 2012, and it has since won in the marketplace of ideas, becoming the single most popular language to transpile to ES# and beating a well-resourced competitor in Flow.

The type war was "won" by TypeScript, and I expect it's just a matter of time before types make it into the standard. The benefit of winning so completely and having such enormous popularity is that its ideas are very likely to make it into the standard such that no transpilation will be necessary.

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

#57

Post by itsnotlupus »

pkukkapalli wrote: post #43
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 there is a way to get all of the "good parts" of Typescript, mainly type checking, without introducing the bad, mainly transpiling. I recently started just running Typescript on Javascript files, where all of the types are specified via JSDocs. It was a refreshing experience, and I highly recommend. The Typescript website[1] has pretty good documentation for it. [1]: https://www.typescriptlang.org/docs/handbo…

Unfortunately their jsdoc stuff only exposes a subset of their typing capabilities, so you're leaving some advanced type goodies on the table.

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

#58

Post by hkai »

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…

In my entire experience as a programmer, I can't recall writing a prototype that was not eventually used as production code. If I wrote prototypes in JavaScript, I'd have to start all over again to rewrite them in TypeScript.

Meanwhile, people would be on my ass trying to understand why I can't just simply hook up that decent looking prototype to API and release it.

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

#59

Post by BigDogS »

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?

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.

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

#60

Post by yawaramin »

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

Esbuild isn't a typechecker, it's a bundler.
Post reply on HN