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

Deno 1.6 supports compiling TypeScript to a single executable

github.com

Post reply on HN
Print view View original

251–260 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#251

Post by wperron »

nikisweeting wrote: post #67
jimmyspice wrote: post #57

Earlier quoted context omitted.

why not use artrifactory or similar proxy so you always have a local mirror?

That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.

to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really)

The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from

Re: Deno 1.6 supports compiling TypeScript to a single executable

#252

Post by 205g0 »

ameliaquining wrote: post #170
205g0 wrote: post #144

Earlier quoted context omitted.

> then in many scenarios it'd be a lot easier to deploy It's not. Most advanced deployments nowadays use container orchestration where deploying is as easy. For simple deployments (eg SSGs) there're enough products on the market. Integrating the build step hides it at the same time (good for beginners) but creates many other problems in the long run if we just talk about repackaging the run-time.

I think you're underestimating the diversity of environments out there. Not everyone's using cutting-edge deployment tech; lots of folks are just SSHing or RDPing into a physical or virtual server, copying stuff there, and running it. Certainly, that's how things were done at my last job. And it can get worse; some of these environments are locked down in some way or another, by security policies that limit what you…

> Not everyone's using cutting-edge deployment tech; lots of folks are just SSHing or RDPing into a physical or virtual server, copying stuff there, and running it

Maybe a decade ago, tbf IDK anyone who deploys like this in 2020, people user either Docker and/or k8s or a stupid-simple netlify/surge/vercel push. Then, there's also server-less stuff but yeah, you get the idea.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#253

Post by the_gipsy »

bartlomieju wrote: post #32

Hey, Bartek from deno.land here. I'll be more than happy to answer your questions about Deno and its development.

What's your plan for importing other typescript packages, natively?

Last I remember is that every project/library has vastly different tsconfigs.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#254

Post by 205g0 »

mark_and_sweep wrote: post #209
205g0 wrote: post #148

OT: After reading and discussing this feature in this thread, I realize, it's not about the feature or if it's good or bad. This Deno update and the whole thing shows once again that we want a node successor but Deno as great as it sounds doesn't offer enough benefits or is 10x better than just using node + Typescript in order to leave latter and their huge ecosystem. Even worse, it creates the notion that the Deno t…

> Deno as great as it sounds doesn't offer enough benefits (...) Deno feels just like an opinionated node/Typescript distribution with too little improvements Node is 11 years old. In the beginning, it was rough around the edges, too. I think you need to be a bit more patient until Deno reaches a similar level of maturity.

When node came out it was a perfect storm: Ryan did a brilliant job, right timing, right product, laser-sharp focus and x times better than the past (I liked node right from the beginning) and he was fast. All things I miss from Deno.

But I don't blame Ryan, he is a great guy, created the biggest server-side dev ecosystem and it's hard to top such an achievement but at least he tries and this is why I like him.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#255

Post by wperron »

z3t4 wrote: post #195
bartlomieju wrote: post #53

Earlier quoted context omitted.

Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…

Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files. Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs. Loading module…

It's important to remember that while, yes, CommonJS made Node popular, it did so because it filled a void in the Javascript syntax and specs. There was nothing to formalize the concept of a "package" back then.

That's not true any more, ES Modules have made it into the spec, so that's what Deno is using.

As for package-lists, the current convention in the community at the moment if you have a decently sized library is to have a `deps.ts` file where you re-export all of your dependency, making it an equivalent to package.json and helps with upgrading dependencies across a codebase.

TypeScript is already optional in Deno! it will run any .js file just fine, and you even skip the compilation part.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#256

Post by no_wizard »

205g0 wrote: post #248
no_wizard wrote: post #242

Earlier quoted context omitted.

I know providing a fully baked compiler API isn’t high on their list (think babel). I couldn’t find any information from the Typescript team regarding anything you’ve stated about 3rd party build systems and the compiler being provided only for convenience. Do you have anything you can point to from the team about this?

It's right in their wiki, "non-goal" number 4 in their TS Design Goals which is also referenced again in some issues: [a non-goal] Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I think I interpreted this differently than the parent poster

Re: Deno 1.6 supports compiling TypeScript to a single executable

#257

Post by cjonas »

chrisweekly wrote: post #230
feanaro wrote: post #220

Earlier quoted context omitted.

No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend. A further limitation of CORS is that certain requests are allowed even if they are not fr…

I'm so fuzzy on the details but isn't this what client certs are for?

The cert couldn't obviously couldn't be static in this case (otherwise it would be trivial to get the private key).

Creating a cert during "install" probably adds a good bit of complexity (especially if the map has multiple env targets)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#259

Post by galaxyLogic »

feanaro wrote: post #220
cjonas wrote: post #155

Earlier quoted context omitted.

Wouldn't proper CORS be enough? I guess you would have to avoid putting any sensitive data in GET requests

No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend. A further limitation of CORS is that certain requests are allowed even if they are not fr…

IKs there a good simple way to keep it secret?

I assume someone could have a look at the JavaScript on the browser and see hey this must be the secret stored here because it is passed to the server on every request. Then write there XSS attack to use that.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#260

Post by ben509 »

svnpenn wrote: post #149
dguaraglia wrote: post #142

Earlier quoted context omitted.

Sure, and you can do something similar with C and obtain a ~10kb executable, or even less if you put some effort. Or write that in Java and need a complex setup including the JRE and a bunch of packages to support it. The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.

My point is, what is even the point of using Deno? If its for static typing... well Go has that. So what is the benefit?

If you wrote a browser client in Javascript / Typescript, then it makes sense to write a backend in it as well since it's easy to share code and data between them.

Now you can also write CLI tools that are trivial to deploy and can also share code with everything else.

This is the same motivation behind other languages that do the reverse; compile to JS / WASM.

Post reply on HN