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

Deno 1.0

deno.land

Post reply on HN
Print view View original

421–430 of 598 posts

Re: Deno 1.0

#421

Post by torb-xyz »

gunn wrote: post #107
_bxg1 wrote: post #84

So it's an alternative to Node? Sounds incredibly cool, honestly. This: > Supports TypeScript out of the box. Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).

You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript

It doesn't really help that much with TypeScript native NPM-packages being published with JS and D.TS (TypeScript-definitions) instead of the original source, does it?)

Re: Deno 1.0

#422

Post by drbw »

bgdam wrote: post #127
batmansmk wrote: post #117

Earlier quoted context omitted.

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

Or use something like Nexus or Artifactory to host a private copy of dependencies.

Re: Deno 1.0

#423

Post by fbn79 »

The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want...

Re: Deno 1.0

#424

Post by alienspaces »

littlestymaar wrote: post #186
bgdam wrote: post #127

Earlier quoted context omitted.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).

Go dependency management is quite good now with "go mod", plus your dependency tree isn't going to look anything like your typical JavaScript dependencies, otherwise you're doing it wrong..

Re: Deno 1.0

#425

Post by torb-xyz »

turblety wrote: post #136

As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…

It's the inclusion of TypeScript by default that allows it to have a much nicer developer experience compared to Node/NPM.

And as others have noted: there's no downsides for those who wish to simply use straight JavaScript.

Re: Deno 1.0

#426

Post by torb-xyz »

marijn wrote: post #400
greggman3 wrote: post #299

Just a random though but if they want speed they could consider making a typescript JIT instead of typescript -> javascript. Typed languages can run much faster than untyped. Maybe that's impossible with current typescript given anything can be changed, eg (30 minutes into running something does Math.floor = ... etc, but maybe some kind of escape analysis could help or maybe push for some new keyword to mark code as…

Building a new JIT for a dynamic language, if it is supposed to be competitive with JS compilers, is a project several orders of magnitude bigger than building a runtime like this. TypeScript's design is very much that of a typing layer over a dynamic language. It's unsoundness and various loopholes to escape typing mean it's not much of a help for typed compilation.

Microsoft _do_ have the research project Static TypeScript that does try to do this with a subset: https://www.microsoft.com/en-us/research/publication/static-...

But your point stands I think this subset will be incompatible with how many (including myself) writes TypeScript.

Re: Deno 1.0

#427

Post by alain_gilbert »

fbn79 wrote: post #423

The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want...

Do you hav any example of valid javascript that is not valid typescript ?

Re: Deno 1.0

#428

Post by hombre_fatal »

fbn79 wrote: post #423

The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want...

This is such a weird point to me, maybe pedantry at best. Typescript is, to 99% of people, just Javascript with types. With few exceptions, TS compiles 1:1 to JS.

That blog article just looks like an intro for beginners who don't quite know what static typing entails. Yes, static typing is different from runtime checks, that's why it's static.

Re: Deno 1.0

#429

Post by alessioalex »

nkozyra wrote: post #169
polishdude20 wrote: post #163

Earlier quoted context omitted.

But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings…

I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.

> People in JS/frontend world are willing to drop the world for the latest new thing

Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.

Post reply on HN