23 ms·
Deno 1.6 supports compiling TypeScript to a single executable
- svnpenn 6y agoYeah, and the executable is 47 MB. You can do the same thing with Go: package main import "os" func main() { for _, s := range os.Args[1:] { o, _ := os.Open(s) os.Stdout.ReadFrom(o) } } and the executable is 1 MB.
- ameliaquining 6y agoIf the 47 MB executable has no dependencies other than the kernel, then in many scenarios it'd be a lot easier to deploy than if you had to separately install a language runtime. Of course, Node.js can also do this with pkg, and also I don't know whether executables produced this way really are dependency-free (although depending only on widely-available shared libraries would be almost as good).
- 205g0 6y ago> 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.
- ameliaquining 6y agoI 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 can do. In those environments, having the executable be fully self-contained is really helpful. (For the record, I am a proponent of things like containerization and serverless, and generally try to bring them into use wherever I can. This doesn't require me to ignore the reality that lots of places don't use them, and that this will remain true for a long time to come.)
- qeternity 6y agoI’m not sure this should be encouraged...
- 205g0 6y ago> 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.
- PaulBGD_ 6y agoThis would be more comparable to packaging a Java program into an executable, which would have to also contain the JIT. I don't think it's fair to compare a JIT'd language to a AOT'd language.
- pjmlp 6y agoA Java program can be AOT compiled to native code, no need to package a JIT.
- dguaraglia 6y agoSure, 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.
- svnpenn 6y agoMy point is, what is even the point of using Deno? If its for static typing... well Go has that. So what is the benefit?
- Soremwar 6y agoWhat's even the point of using Go? If it's for static typing Rust has that So what's the benefit? Same can be said about any language really, it's personal preference
- throw_m239339 6y ago> So what is the benefit? A better type system(covariance, dependent types) than Go's and generics, a richer ecosystem, deploying the same codebase on the server and in the client...
- fareesh 6y agoGuessing here - is there any value from a team / engineering point of view to having shared code for custom classes / data structures between client and server? Here I assume client to be mean browser
- ben509 6y agoIf 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.
- txdv 6y agoWhy is Go's binary so big?
- mrkurt 6y agoThis is such a good feature. Go has been great for shipping single purpose binaries (like the CLI for https://fly.io https://fly.io), but I really enjoy writing TypeScript more than Go.
- echelon 6y agoA lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.
- qeternity 6y ago> With a single binary, containers get even slimmer. Not really. I agree on the other benefits of binaries but our containers usually only have the final layer change (the source code). This means that all the lower layers, python base image, requirements, etc are cached. So we can ship 100 times and add maybe 100mb of new container overhead. Binaries will ship 100% every time.
- loosescrews 6y agoDo they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.
- qaq 6y agoOnce ecosystem grows a bit Deno will be a very good alternative to Node. This particular feature is great for simpler deployment.
- corytheboyd 6y agoJust throwing it out there for visibility, ncc will compile a TS entrypoint down to a single file as well, without having to use Deno https://www.npmjs.com/package/@vercel/ncc https://www.npmjs.com/package/@vercel/ncc Edit: I completely missed that this Deno release packaged the runtime as well, disregard this as an alternative! Guess I’ll eat the downvotes I deserve :P
- jonny_eh 6y ago> without having to use Deno But you need to use ncc? What's the relevant difference?
- tardismechanic 6y agoYou need `ncc run` to run the generated file. https://github.com/vercel/ncc#commands https://github.com/vercel/ncc#commands
- corytheboyd 6y agoI was wrong.
- mdtusz 6y agoThis still requires a node runtime. As far as I understand, the deno usage creates a single executable - batteries included.
- corytheboyd 6y agoYep, that’s the detail I missed. Thanks for raising it.
- kungfufrog 6y agoNot sure ncc is an equivalent. I think nexe or pkg are comparable, they bundle a runtime into the exe whereas ncc just reduces the code down to a single distributable code file in that you still need node installed to run it on the target host.
- offtop5 6y agoDoes this offer a speed increase vs running the the code directly using $ deno test.js ( not sure what the exact command is )
- CraftThatBlock 6y agoNot really (at least yet, I think). This simply bundles the Deno binary and the script (I think the pre-compiled, as in TypeScript -> JavaScript, then possibly as pre-compiled AST). This is why the output binary size is the original Deno binary + the script size (roughly). So it's functionally equivalent to running using deno test.js
- lucacasonato 6y agoCorrect. We are currently working on reducing size for these `deno compile` binaries. From preliminary testing we think we can reduce size by around 60%. Regarding speed, we are investigating V8 snapshotting of the user code, which would give it a great boost in startup time. Actual runtime performance would be the same.
- offtop5 6y agoWould it be theoretically possible, to end up using this as sort of a scripting language for rust or whatever. I'm imagining Deno somehow getting complied down to Rust and then running at Rust speed. I basically want low level performance without writing in a difficult language
- lucacasonato 6y agoNo this is not possible. JS is too dynamic for that to work.
- mark_and_sweep 6y agoNot really, I think. Startup of a "hello world" seems to be 5ms faster on my Windows machine: https://gist.github.com/MarkTiedemann/c2f4013c3a60bb28df50059f61327cb8 https://gist.github.com/MarkTiedemann/c2f4013c3a60bb28df5005...
- dirtnugget 6y agoI wish there was a NestJS equivalent to Deno, then I’d consider using it for projects
- Kaido 6y agoCheck out https://github.com/liamtan28/dactyl https://github.com/liamtan28/dactyl Its based on Nest
- j1elo 6y agoI'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 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 who have integrated this option directly into the runtime.
- galaxyLogic 6y agoI'm using vercel/pkg as well. I have a Node.js server which generates HTML and opens a browser on Windows which then asks the server for that html at 127.0.0.1. So browser will be my GUI and Node.js packaged with vercel/pkg my back-end. It is more flexible than say Electron because GUI can be anything I want it to be. My concern is only will users accept a local server running on their desktop. I've tried to configure the executable so that the server accepts connections only from the same host as where the http-requests are coming from. I assume the same situation would exist with Denon, if you build a product with it and want to use the browser as your front-end. Are users OK with a server running on their PC?
- Couto 6y agoThis reminds me of the server that Zoom used to have. Accepting connections only from 127.0.0.1, alone, isn't enough, since any request from the browser would match that IP, even if the request was being made through a XSS attack. I'm sure someone with more knowledge in security would better chime in.
- jjnoakes 6y agoWhat I do is generate a random token, pass it to the browser I spawn, and only accept requests that include the token.
- galaxyLogic 6y ago
- bartlomieju 6y agoHey, Bartek from deno.land here. I'll be more than happy to answer your questions about Deno and its development.
- nikisweeting 6y agoLast time I tried deno there was some friction with depending on npm packages that didn't natively support deno without vendoring, is that easier nowadays? Can we seamlessly import anything from npm inside deno-run code and use the deno stdlib side-by-side with node_modules code? We love the Deno direction and would even willing to donate $ to grow its development, but for us it's pretty much non-starter to switch to a different runtime until we can use the wealth of packages available on npm without any additional friction. The Deno docs here almost seem to purposefully avoid answering this question: https://deno.land/manual@v1.6.0/examples/import_export https://deno.land/manual@v1.6.0/examples/import_export
- bartlomieju 6y agoThat really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node. It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting better.
- nikisweeting 6y agoThanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. 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 & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.
- jimmyspice 6y ago
- SiVal 6y agoNode is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict what will work out and what won't in the future, and this was one of those frustrating cases like carving in stone, where every mistake you make is permanent. But a combination of various factors made the web an enormously impactful medium. It's too important to take the approach of "well, let's just add some good stuff to the bad and live with it" where we don't have to. We have to in the browser, but we don't have to on the server. I want to see the "benefit of hindsight, rebuild it better" design of TypeScript matched with a server-side equivalent, which looks like Deno. I hope Deno succeeds.
- tantalor 6y agoWhat are you talking about?
- wmf 6y agoI'm pretty sure multicore was a thing in 2009, though.
- josephg 6y agoIt was, and since 2009 the recommendation has been to run an instance of nodejs per CPU core. The justification is that if you're already scaling your app between servers, you shouldn't need a separate mechanism to scale across multiple cores in a single server. I'm not sure when the cluster API was added, but its been in nodejs's core for a long time. (Not that you need to use it, but still.) https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html
- chrisweekly 6y agoyeah `pm2` has even made this painless since (many years ago)
- naiveai 6y agoI find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?
- lucacasonato 6y agoFull release notes can be found at https://deno.land/posts/v1.6 https://deno.land/posts/v1.6 :-)
- nchudleigh 6y agoWhooooo! Lets go! This is huge!
- jariel 6y agoQuestion for those who know better: wouldn't this better be accomplished by some kind of archive/bundle? ie keep the packaging structure intact, but just archive it?
- breatheoften 6y agodeno seems really amazing. This is essentially single file distribution of a secure runtime for application code -- that is a lot of platform-capability-bang for the distribution-reach-complexity buck! This has to already be the best server container format for typical application code in terms of the security possibilities doesn't it? I'd almost like to see deno grow some kind of puppeteer based browser api as server-app platform -- http request -> deno server process runtime (with secure sandbox) and puppeteer-like handle to the client browser for state transfer -> client ui render ... it would be quite interesting to think of the client browser page tabs as a "child process launched by the server" rather than as as a stateless request from an http client -- as most server rest api architectures tend to push you towards ...
- peanut_worm 6y agoWow that’s really cool. I have a lot of hope for Deno, seems very promising.
- kumarvvr 6y agoI wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem. I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM
- rodrigoj42 6y agoYMMV but I think F# fills that gap nicely
- andyfleming 6y agoF# is interesting but still pretty different from TypeScript.
- natchy 6y agocreator of TS was a maintainer of F# at microsoft when he created it. I see lots of parallels in the type systems.
- T-A 6y ago> I want something like Python https://ironpython.net/ https://ironpython.net/
- manojlds 6y agoWell, there's IronPython - https://ironpython.net/ https://ironpython.net/
- Riverheart 6y agoIt exists and is called Powershell
- motyar 6y agoHow to make it work for mac?
- josephg 6y agoI really like this. I've been thinking a lot over the last few years about Docker. Arguably docker is just another abstraction for "statically linked executable". But we've had static executables for years; and they work well, and the ABI for the linux kernel is very stable. So increasingly I'm not convinced docker is worth it, compared to just building and deploying bundled executables. And executables can be run anywhere, they don't need a separate testing environment, they can be debugged easily[1], and so on. [1] Well, if you like systemd or have a reasonable replacement.
- jerrygreenest 6y ago47mb executable for a simple cat command? Huh, there's huge area for improvements indeed
- slmjkdbtl 6y agoYou should never use deno to make small programs like cat where you don't absolutely rely on deno features. Tons of other languages / tools can give you 100kb and faster binaries.
- 205g0 6y agoPlease help me to understand: If I deploy my apps as Docker images anyway why would I need this? Deno 1.6 just packages the runtime creating a huge file, still smaller than a Docker image but with latter I have a better deployment experience meaning there's a huge ecosystem and tooling around. No rant, just trying to get what I miss.
- iamAtom 6y agoYou are talking about server side use cases mostly. This executable will come handy for variety 3rd party apps.
- gscho 6y agoI think you already answered the question. You don't need to introduce docker cli, docker daemon, a container registry, etc. Not saying theres anything wrong with docker but having options for application packaging is nice!
- danenania 6y agoExactly. The fewer moving parts, the better. Even if you still use Docker, a container wrapping a single binary is simpler than a container with dependencies and source files. It’s also good for closed source use cases (blasphemy, I know).
- 205g0 6y agoOk, the Docker client stuff is not always exciting but once you want to deploy something small, say, an app server, a DB and something like nginx or Traefik you need some orchestrator, eg k8s and then you need again images. If you prefer containerd over Docker also good. What I am saying is which orchestration and deployment system does favor single executables atm and has a huge ecosystem? You still need to create images and do double the work. I like real binaries like Go creates but repackaging the run-time doesn't sound like a sophisticated idea but rather making the black box even bigger. As a sibling said, for client side/3rd party apps, yeah this might be a nice-to-have but this space has rather other challenges.
- np_tedious 6y ago
- 205g0 6y agoOT: 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 team desperately tries to climb back on stage and get our attention with minor improvements. Maybe I am ignorant but Deno feels just like an opinionated node/Typescript distribution with too little improvements but not like the successor we hoped for. Besides, I wonder if the Deno team solved all the performance issues which popped up the last time I've read about Deno. There were some debates with the ws community but can't remember details anymore.
- SquareWheel 6y ago> Even worse, it creates the notion that the Deno team desperately tries to climb back on stage and get our attention with minor improvements. That seems an uncharitable interpretation. Ultimately they're creating tools for our benefit. They may or may not be useful to you personally, but the creation of value should still be applauded, not dismissed as attention seeking.
- mark_and_sweep 6y ago> 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.
- 205g0 6y agoWhen 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.
- lemax 6y agoWe use vercel/pkg to distribute our product as a standalone executable that runs in on-prem windows environments. Our product is actually comprised of multiple NodeJS servers that are spawned as child processes in one master Node procees, and that module gets built using pkg. We also have a windows installer that configures a windows service to run the executable/keep it up. It’s proven to be a really simple way to distribute our app to the enterprise that’s been working for a few years. It doesn’t really protect source code, but provides a decent enough level of obsfuscation for our needs.
- thisjeremiah 6y agoWe’ve been following a similar process for our internal tools and have found it to be a good solution. Manually including native libraries is probably the only lousy part. Out of curiosity, what are you using to achieve the windows service installation? We’ve been using nssm, which has worked okay, but I’m curious if there’s a better way of doing it.
- lemax 6y agoYep, we use NSSM as well, it does the job.
- sandGorgon 6y agoWhoa! Potentially this can make React Native hit the same performance as Flutter+Dart. as the Dart team claimed - https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf >Dart is one of very few languages (and perhaps the only “mainstream” language) that is well suited to being compiled both AOT and JIT. Supporting both kinds of compilation provides significant advantages to Dart and (especially) Flutter.
- tarruda 6y agoWhat this deno feature does is not AOT, but simply packaging the JS as an embedded resource in the executable. JS is still parsed and compiled at runtime.
- silverwind 6y agoI guess optimizations like storing the v8 compiler cache format in the binary should be possible.