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

41–50 of 115 posts

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

#41

Post by jeffmcmahan »

jdxcode wrote: post #40
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…

Do you use Babel to polyfill JS? Minify? Concatenate? You’re transpiling. And not much more than TS. There is very little logic change that TS does and most of it is essentially the same as what Babel would do for polyfill reasons.

I'm not OP, but in my case, no. I don't. I write a roughly ES7, and if you're on an ancient phone/PC, oh well. I really don't care. Not because people using those devices don't matter, but because I am writing code for a company in which I have a say in what hardware/software is provided to employees. I don't have to support IE. That's true of a lot of developers, for whom Babel is a waste of time.

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

#42

Post by Andrex »

gameswithgo wrote: post #29
Andrex wrote: post #23

Earlier quoted context omitted.

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

I would advocate for as much simplicity as possible then. :)

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

#43

Post by pkukkapalli »

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/handbook/jsdoc-supported...

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

#44

Post by zelly »

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.

Lindy effect

https://en.wikipedia.org/wiki/Lindy_effect

Transpilers definitely aren't Lindy. CoffeeScript, GWT, Elm, among others form a huge graveyard of de facto defunct languages targeting JS.

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

#45

Post by zelly »

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…

The fact that 90% of your code (i.e., business logic sans OS) can run in a Chrome Dev Tools window is pretty powerful. There really isn't anything that competes except PHP on a LAMP server in 2007. The ease of "getting started" is a big part of the network effect and the number of npm packages out there. Yes, the quality of those packages is terrible, but you don't find that out right away.

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

#46

Post by zdragnar »

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…

> arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.

So why on earth are you using their packages?

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

#47

Post by nailer »

mikewhy wrote: post #35
ngerrity wrote: post #34

Earlier quoted context omitted.

linting wouldn't, but if you're writing unit tests, that kind of problem would be caught pretty quickly.

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.

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

#48

Post by thegreatpeter »

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?

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.

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

#49

Post by yashap »

This makes me generally curious about Deno’s architecture/design. Anyone known much about it? Would love to learn more!

I know the JS engine is V8 (C++), and the rest is Rust and TypeScript, but which parts are Rust, which parts TypeScript? Why 2 languages? Is it mostly Rust, mostly TypeScript, or a bit of both?

Also, what are the hardest problems that Deno solves internally? Like if you’re working on Deno, are you mostly working on ... the dependency resolution/package management? Automatic compilation of user TypeScript code? The standard library? Something else entirely?

Post reply on HN