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

241–250 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#241

Post by strzibny »

pjmlp wrote: post #191
oblio wrote: post #179

Earlier quoted context omitted.

PHP, JavaScript, Python, Ruby, even Java and C# didn't (don't?) have a mainstream way to create a single binary with unused code and unused dependencies removed. Dynamic linking was cool because you could use system dependencies which people don't want to use because you can't rely on them, especially for cross platform apps and also for efficiency, RAM (which people stopped caring about) and, disk space (this boat s…

Java has had static linking support since around 2000, for embedded deployments. C#, yes it has been mostly dynamic. PHP, JavaScript, Python, Ruby, don't count, they are scripting languages, bundled with an interpreter. Still, Python and Perl bundlers exist since around 2000 as well. Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where sta…

Ruby has some options too, one of them being ruby-packer. Here's[0] how I used it to generate single executables.

[0] https://nts.strzibny.name/making-a-ruby-executable-with-ruby...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#242

Post by no_wizard »

205g0 wrote: post #145
j1elo wrote: post #29

I've been using vercel/pkg with great success, in order to achieve a similar target and package a whole application into a standalone executable: https://github.com/vercel/pkg This can be useful for people wanting to do this with Node. It's nice to have a single file that can be started right away without any external dependency. And also, it prevents from having to distribute the full sources. Kudos to the Deno devs…

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

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?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#243

Post by yboris »

feanaro wrote: post #218
galaxyLogic wrote: post #113

Earlier quoted context omitted.

Right. Also each Electron app "comes with a copy of two large software frameworks, Node.js and Chromium" ( https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w... ) Whereas if you build starting from Node.js (or Deno I assume) you can skip the Chromium part. Instead of packaging Chromium with your app you assume that users have a browser and can use that to talk to your app. The benefit of using Node.js is yo…

The additional benefit of this approach is that you can then build your application such that it works with all standards-compatible browsers, such as Firefox.

That's not a benefit - that's a down-side. When writing a front-end for Electron, you only worry about 1 browser and you have a guarantee that it will work the same way across every OS.

If you have to write a front end (website) that works with more browsers, you have to put in moro work.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#244

Post by wperron »

nikisweeting wrote: post #63
bartlomieju wrote: post #60

Earlier quoted context omitted.

> We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with…

Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that U…

The beauty of Deno is that it's agnostic about where you import your code; At the moment deno.land/x only allows tags to be published - no semver range resolution, and doesn't allow versions to be removed/update. nest.land is another popular one, and is build on top of the arweave blockchain, bringing that chain of trust you mention.

The ecosystem is still in evolution but I expect that it stabilize around a few generic registries for smaller libs, and larger libs hosting their code themselves in the long run. The point is; while URLs _can_ be very loosy goosy ways to address code, they can also be made very strict - it will depend on the actual server behind it.

As a side note, npm is already pretty poor at providing those guarantees anyway, I find it interesting that it's usually assumed to be a safe way to install dependencies.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#245

Post by feanaro »

yboris wrote: post #243
feanaro wrote: post #218

Earlier quoted context omitted.

The additional benefit of this approach is that you can then build your application such that it works with all standards-compatible browsers, such as Firefox.

That's not a benefit - that's a down-side. When writing a front-end for Electron, you only worry about 1 browser and you have a guarantee that it will work the same way across every OS. If you have to write a front end (website) that works with more browsers, you have to put in moro work.

It's a benefit from the point of view of the user and for the openness of the web. We shouldn't rely on features exclusive to a single browser anyway.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#246

Post by feanaro »

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?

You could accomplish this with client certs too, sure. A random secret is a simpler solution in many ways and accomplishes the same goal, though.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#247

Post by wperron »

nikisweeting wrote: post #98
mark_and_sweep wrote: post #92

Earlier quoted context omitted.

> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager , but an argument for a central package r…

I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.

_If_ the node library uses explicit file imports, and ESM instead of CJS, it _is_ already possible to just do `npm install` and import from "./node_modules" -- again the problem is that Node's import resolution algorithm is horribly complex and not very explicit, but it's possible to be explicit using Node, and that would make it compatible in Deno

Re: Deno 1.6 supports compiling TypeScript to a single executable

#248

Post by 205g0 »

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

Earlier quoted context omitted.

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

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

Re: Deno 1.6 supports compiling TypeScript to a single executable

#249

Post by wperron »

jay_kyburz wrote: post #89
mark_and_sweep wrote: post #75

Earlier quoted context omitted.

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.

Using URLs is like having an iframe to somebody else's website on your website.

Maybe... it depends on the amount of _trust_ that you put in the remote domain. My prediction is that the Deno ecosystem will aggregate around a few, large repositories that will have good guarantees araound immutability and good track records to addressing vulnerabilities.

For large projects like React, lodash, eslint whatever, I expect some of them will start hosting their libraries on their own networks, like it used to be when Javascript was only frontend and you would have a script tag importing jQuery directly from jQuery's CDN. The reason it worked was because jQuery was sidely known and trusted.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#250

Post by 205g0 »

diegoperini wrote: post #236
205g0 wrote: post #145

Earlier quoted context omitted.

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

If it's good that we have these options, what Deno provides is just another option for us to choose from. I don't see how this is a shut-down for the ecosystem.

I don't think, Ryan wanted Deno to be just another build system for TypeScript but something a bit bigger. And even if it's meant as a build system there're much better options out just for this purpose.
Post reply on HN