Deno 1.6 supports compiling TypeScript to a single executable
github.com
github.com
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.
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?
I'm sure someone with more knowledge in security would better chime in.
No modern browser allows access to localhost without that header.
But it's still possible to forge a request using curl or whatever to bypass CORS. So as the parent post suggest - use a token of some sort.
I also recommend using a strict Content-Security-Policy to stop X-site injection attacks. (eg someone adding an image to your page/app with src="/api/cmd=rm -rf /"
A further limitation of CORS is that certain requests are allowed even if they are not from an allowed origin.
To conclude, you definitely need a secret.
Creating a cert during "install" probably adds a good bit of complexity (especially if the map has multiple env targets)
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.
I would say that users don't mind. They want a working application, that does what it promises, and is dependable. Things like having an underlying server is just an implementation detail, nobody really cares (talking about the big public here, not the more technical users of HN who might have a say about the technology choices, but are overall a very small portion of potential users)
That doesn't mean the implementation should be sloppy, though! Make sure to iron out all those security concerns regarding 127.0.0.1, because it could cause a data breach or some other severe damage. Other than that, just aim to provide the best user experience.
It will not trigger the mixed content errors (for Chrome and Firefox – Safari does not do this for now, but it is in the works: https://bugs.webkit.org/show_bug.cgi?id=171934 )
I have seen some companies do the following too: They embed a snake oil certificate and instruct people to disable web security, don't do this. Some other companies do something like purchase a foolocal.com https certificate (spotify and dropbox do this I believe), but that certificate might be revoked afaik.
As to CORS, you need to check that the incoming request comes from your own remote machine, otherwise if you enable cors for all, other sites can scan and get your user's data (ebay was recently doing this, scanning ports: see https://blog.nem.ec/2020/05/24/ebay-port-scanning/ )
These days everybody is used to their smartphone asking things like "Do you want to allow App-X to use your microphone" etc.
Feels like one of us is misunderstanding something. Electron lets you run any web technology - so when users open your app, they are greeted with whatever you can show on a webpage.
You can also have Electron run in the background as a server if that's something you're into ;)
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 you don't have to use a different language for the backend. It helps.
BTW. "Electrino" in the linked-to article seems interesting too.
If you have to write a front end (website) that works with more browsers, you have to put in moro work.
This sounds pretty cool -- is there a way for the deno runtime to restrict the server process to only be able to generate the legal types of http traffic that a browser could generate if allowed to open a connection to a specific url (or set of urls)?
If so i'd feel more comfortable about running the embedded server -- ideally the security risk of running the server would be closer to the risk when running an embedded set of daemon browser tabs -- rather than the risk when exposing all the unfettered power of a unix process ...
Or is there à better way there?
One problem is however that there is no easy way to get Safari to run in chromeless/app mode (without browser/url bar etc), which you can do in most other browsers using --app=url flag
I hope they'll fix it soon.
One of my gripes with PKG (and all other node.js packaging tools) has been that it's a pain in the ass to package when your dependency includes a native module, for example SQLite.
Since Deno has a different architecture and works in different ways, thought I would ask just in case there's a solution for this on Deno, that would be great.
It might be best to try alternatives like wrappers around leveldb as a baseline, which of course isn't sql and has its' own drawbacks.
https://github.com/sqlite/sqlite/blob/610f11de25993960ff616e...
Of course, a different kind of database, similar to say leveldb could work in single-process mode.
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 but encourage the community to compete and complement. Integrating build systems is good for beginners who struggle with them but for the rest? IDK.
Or in other words, Deno wants to be more than just an opinionated node-Typescript-distribution nobody cares about but then they need to create this ecosystem and focus on the core (what's their core and value add other than repackaging node and TS would be the next discussion).
With integrating the build step they do the exact opposite, they shut-down an ecosystem before it can even start. There's a night and day difference between good and bad build systems and only competition and a rich ecosystem can bring up the best solutions.
FWIW, there're tons of ways to compile TS, every with different trade-offs and it's good that we have these options.
I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any of the billion obvious reasons it's a stupid project for stupid people, it saves me a ton of time. Otherwise, it's a waste of time and effort, and all you have to do to convince yourself of that is look at the contribution history of the most prominent contributors on github.
I have never, not once, in my life as a developer wanted a project to die so badly.
> What is this? A center for ants?
I hope you're either self employed, or that you run your own company. If not, this comment is a red flag for potential recruiters; you might want to consider editing it.
So win-win, Your happy, they are happy.
Do you have anything you can point to from the team about this?
[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...
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.
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.
Not everyone is using Linux with glibc linking issues.
Regardless of how we scope it, Go is still the only mainstream language capable of producing statically linked Linux binaries without libc while still allowing full use of the standard library.
I haven't figured out anything better than a git pull script to update things. I can't imagine there is nothing better in 2020.
As a developer for more than 30 years, I find that statement quite interesting. When I was a kid I was very happy to find a way to compile Basic to an executable like I was doing in Pascal and C++. For me is the standard way of thinking about applications.
Is it a common experience to actually have to ship many files for one application? I thought that it was just common for the web as it fits how HTML evolved not for anything else.
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 sailed a loong time ago) and compilation (we have 10000x as powerful computers now).
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 static linking was the main option.
Yeah, but for non-embedded deployments i.e. 99% of Java code out there?
> Still, Python and Perl bundlers exist since around 2000 as well.
I don't know the Perl one, but the Python ones definitely aren't mainstream. They're finicky and relatively hard to use and definitely not distributed with the Python distribution, which would make them ubiquitous and well supported.
> Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where static linking was the main option.
Every language in the olden days had static compilation support :-))
That's why we had articles such as these: https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... (which I agree with)
100% of commercial JDKs have support for AOT compilation, what you are getting nowadays on OpenJDK is the free beer version of it.
> I don't know the Perl one, but the Python ones definitely aren't mainstream.
They surely were mainstream on Windows back in .com days, specially via py2exe and ActiveState tooling.
> Every language in the olden days had static compilation support :-))
Many of which are still mainstream languages.
It was (is?): PHP, Javascript, Java, Python, Ruby, C# or nothing.
Especially the dynamic languages are extremely popular, primarily with smaller companies and startups.
Zope and AOL Server teached me that those dynamic languages are really only good for OS scripting tasks anyway, but that isn't the subject of this thread.
For many developers, maybe the majority, those languages are their objective reality. They haven't used anything else, they might not ever use anything else.
So things which extend the range of their tools are very much appreciated.
They're not going to shun their existing programming languages because other people don't like them and they're not going to switch to OCaml or to commercial Java compilers, either ;-)
[0] https://nts.strzibny.name/making-a-ruby-executable-with-ruby...
With internet speeds of today and immense storage sizes, the main attractiveness of dynamic linking vanished.
And given that shared libraries need to be installed and updated separately and they have to ship the entire code of the library (whereas a static binary can be link-time-optimized to get rid of unused code) it might not always be a win in terms of total bandwidth.
- Languages like Rust which have an ecosystem that evolves very quickly (and uses complex symbol mangling schemes that would break all the time) wouldn't fare very well with dynamic linking in the first place. What good is dynamic linking if you need a different version of your .so file for every binary?
- Dynamic linking is not quite as useful today a it was in the past. Code size is not usually very significant, either on cold storage or in RAM. Actually for RAM it's cache usage that matters most, and static linking can usually be more efficient here through LTO.
- Over the past ~2 decades a new generation of developer arrived and many of them (in my experience) barely use "low level" compile-to-machine-code languages. They often specialize in scripting languages or languages that require a framework. Some of these developers are now learning Go or Rust and for them the idea of shipping a single ELF binary that packages the entire app might be seen as a novelty or maybe even as an innovation.
Linux distributions need to be able to backport security fixes to shared libraries, test them and deliver updates to all users quickly.
With static linking it becomes practically impossible.
It's a little more complicated, but modern Node development is a huge step forward to the old days of sadly attempting to get the LINPACK header configuration correct in your C project.
Sure but most web apps are more than a single binary. There's generating static files, a database, background worker / cache, and more. Then there's wanting to be able to develop that project as a whole on Windows, macOS and various Linux distros as well as deploying it to a specific distro of Linux (most likely). Then there's the distribution of the binary across a network in a reasonable way.
Docker and its ecosystem of tools solves all of those problems once your app is containerized. And if you want to go 1 step further and run a distributed system with load balancers and friends, container orchestration tools let you solve this problem at a level above your application.
And the best part is you can do all of that in the same way with any tech stack.
jlink has shipped since JDK 9 and can package all dependencies and the JRE into a single file. Hello world clocks in at about 22 MB.
What’s old is new is old again!
Ex: I maintain an 'old' PHP / JS application while building a new Go / TS one. With the old one, I change a file, it gets automatically ssh'd to my dev server, and my changes work instantly. I'm sure that if the PHP and JS had to be comp/transpiled, it would take a minute or so (it's just under 100K LOC, some files 13K LOC).
For the new application, I get the same fast feedback because Go does incremental compiles and create-react-app with TS also does incremental compiles with live reload (without requiring a full page reload).
For production builds, the old is pulled through tools like ioncube and uglify, the new one churns out an optimized binary and webpack-flavored .js files.
I mean if you zoom out enough there's no noticeable difference.
Except the single bundle trimmed off unused part from the standard runtime
Size was not really a goal for the first pass of the feature.
But I honestly don't mind up until about 100MB.
We are currently working on reducing size for these `deno compile` binaries though. From preliminary testing we think we can reduce size by around 60% - maybe even more.
I'll be more than happy to answer your questions about Deno and its development.
The Deno docs here almost seem to purposefully avoid answering this question: https://deno.land/manual@v1.6.0/examples/import_export
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. It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting better.
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
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 a path you can tell Deno to change that cache dir. And these files are cached indefinitely; Deno will not try to fetch them again on next run (unless you opt into it with --reload flag).
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 URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.
[1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/
The real appeal of Deno for our org is the stdlib, which as a side effect means we can depend on fewer packages. The wholesale removal of the package manager seems like an unwanted pain that will only keep us away from switching and gaining the stdlib benefits.
deno run --allow-write=~/.myapp https://myapp.io/install.ts
It works quite well as secure scripting runtime.
It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well).
I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.
The 1.0 announcement post the team mentioned:
> For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno.
and:
> Over time, we expect Deno to be able to run more and more Node programs out-of-the-box.
I don't think they've ever claimed to be an immediate drop-in replacement.
https://www.npmjs.com/package/@import-maps/generate/v/0.1.0
This way you'd get both the benefits of web standards compliance with the generated explicit import maps, and backward compatibility and ease-of-migration for npm/yarn users.
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.
Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed.
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 repository.
Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.)
And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though.
In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...
Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_map...
Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no?
"imports": {
"moment": "/node_modules/moment/src/moment.js",
"lodash": "/node_modules/lodash-es/lodash.js"
}
No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't.
> Deno would be a drop-in replacement and we could move our whole codebase over to it overnight
The reason that you cannot move your existing codebase to Deno tonight is essentially the poor web compat of the existing Node ecosystem.
I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"...
I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node, I suspect it will be enough to make Deno a drop in replacement soon. Now it just needs support for normal `import` statements from node_modules instead of just `require()`.
How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object!
> Now it just needs support for normal `import` statements from node_modules
Deno will never ever do that (other than by using standardized import maps) since that's not normal (normal meaning standardized).
import $ from "jquery"
Why would Deno take such an antagonistic approach to supporting the most common setup that everyone uses with npm? Wouldn't it be trivial to just fall back to checking node_modules for named packages? I want to use Deno! This seems like it's deliberately making transitions difficult for anyone using npm.
The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap.
In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better.
This is no surprise since web compat is a core goal of Deno. Node compat is not.
> Wouldn't it be trivial to just fall back to checking node_modules for named packages?
No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.
:'( That's a shame, it would make such a good node replacement with a great stdlib and Typescript support. I hope they reconsider in the future.
These (and other) disruptive breaking changes are about fixing mistakes that cannot be fixed (or at least, are hard to fix) in Node.
Maybe, in a few years, you'll say something like "Oh, I wish legacy Node would be more Deno compatible" because Deno will be the de-facto server-side JS scripting runtime. Equally, it's possible that Deno will fail, but that many good ideas will be incorporated into Node as breaking changes.
Node and Deno as well as their environments can grow further together or further apart. I think it's too early to tell which future is more likely.
My understanding is these are loaded from URLs if they are not in the cache. If a domain changes hands, you could be served anything.
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.
You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.
I'm getting on this boat after mongoose changed its type definitions and ruined a whole morning of work for me.
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.
Looks like Deno can run .ts files without first compiling to .js. What are the other benefits?
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 has built-in permission system that by default runs your code in full sandbox allowing to opt-in into breaking out of sandbox (eg. to read a file from disk)
- As you've mention Deno can run .ts files without explicit build step
- Deno comes with a full toolchain in a single binary (formatter, linter, test runner, bundler, doc generator)
I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.
I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users.
> I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.
Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over.
If you write a library, you need to support several export types for node packages. In your `package.json` you must include a `main` `module` and `exports` object and provide two compiled outputs, one commonjs and one es modules.
Then you need to worry about mutating import paths to include the file extension, which can cause trouble when you keep the commonjs and esmodule files in the same folder.
Also the esmodule loader in node doesn't have access to things like `__dirname`, so certain things can break.
not to mention node_modules...
It's like IE support but on the back end.
Then you step into the front end and it's another whole layer of chaos.
Give me opinionated compilers with minimal configuration and let me write code.
This is a hassle, but didn't used to be true for node - you could say the same as all the above for commonjs, wasn't it nice to have a single opinionated standard.
In the short term, deno avoids this by dropping backwards compat, great! But in the long term, I don't see how it doesn't end up in exactly the same place as soon as the next big change to JS modules comes out, or the next new build environment or wasm integration becomes bigger or...
Unless they have a fundamentally different strategy for the future (either 'we will never evolve' or 'we will evolve with ecosystem-wide breaking changes') they're going to end up in the same state as node today, eventually. I haven't seen any discussion of such a strategy at all. It's just a temporary reset - unlike node, they get to break backward compat and support the One True Format because they're new, that's all.
Nobody forces you to use the deno dev tools. You can still run eslint, prettier and closurescript, if that's your sort of thing.
Personally, I prefer deno lint over eslint and deno fmt over prettier since they are much faster. I'm even using dprint (which is a standalone project for code formatting, https://dprint.dev/) in Node projects.
Similarly, before deno test, I created my own deno testing tool. Now I use deno test instead since it's just better - not because anyone's forcing me to use it.
The integrated dev tools are a convenience feature. I hope that's kinda obvious.
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 modules from URL's is a cool concept! ES modules helps here, but you could also have a package-list file that lists all dependencies of dependencies as well as download mirrors, or hashes with peer-to-peer distribution.
A permission system is nice, modules should not have system access by default.
Not everyone wants to use TypeScript. It will probably become obsolete once optional type annotations gets added to JavaScript.
An opinionated toolchain is nice, but should be optional IMHO.
I'm not sure what you mean by "bad practices like include files" so I can't comment on that.
I've found most Javascript developers prefer the await syntax with promises to using callbacks. It gives the code the appearance of being synchronous with the ability to do things more asynchronously if you need. I haven't encountered many who actively prefer the callback style. It gets unruly fairly quickly.
I can't see optional type annotations ever being added to Javascript. They would have to be checked at runtime which isn't something I'd imagine browser vendors wanting to implement.
The feeling that I get is that the standards committee is trying to bring Javascript to be the best dynamic language it can be and if people want more comprehensive guarantees then there are excellent tools like Typescript which give that option.
The fact there have to be multiple implementations of the standard in the various JS runtimes makes it a hard sell to evolve Javascript too far.
Its in Typescript 3.8, Node 14.8 and probably in your Babel setup. I probably wont get to use Node 14 in prod for a while but I get by with a `main` function that has everything in that gets called at the bottom.
You don't have to use TS. Deno runs plain JS, too.
> [TypeScript] will probably become obsolete once optional type annotations gets added to JavaScript.
What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS.
> An opinionated toolchain is nice, but should be optional IMHO.
It is optional. You don't have to run deno lint, deno fmt, deno test, etc. But at the same time, they are pretty good tools so you might want to try them.
It has already been tried with Dart. Dart was made because JS lacked a type system, preventing further optimisations. Support for Dart was added in Chrome.
Another popular JS transpiler is CoffeeScript, most of it's syntax is now in JavaScript.
Support for Dart in Chrome was added before Dart was popular (if you can even consider it popular at all). Since TypeScript is already popular now, I think if Chrome added support for stripping the types and running TS code as JS, most devs would welcome that.
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.
1. https://github.com/denoland/deno/issues/1891
edit:
partial webcrypto/wasm option already available
Last I remember is that every project/library has vastly different tsconfigs.
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
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 ...
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
But you need to use ncc? What's the relevant difference?
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.
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.
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.)
Traditional JS with new features added, or traditional Node with new features added is the opposite case, where the old standard is being extended, unlike the TS or C+asm case, where the new standard has a mechanism for calling back to the old if necessary. (Deno could still be what I'm talking about even if they added a Node-emulation-library to allow it to call modules written for Node, but I have no idea whether such a thing is planned.)
I love TS as much as the next person but I don't think it's particularly good example to use here.
Anything even remotely successful has to commit to its previous choices, even when they were unfortunate (did anybody say C++?).
One of the reasons why Node had the impact it had was that it used plain JS and committed to supporting the standard language.
I myself prefer writing in statically-typed languages, but the JS direction is frankly commendable; ES6 looks nothing like OG JS, and the fact you can run basically the same code on the browser and on node is a massive bonus.
With that said, I hope Deno succeeds as well, having more choices is a good problem to have!
So it's functionally equivalent to running using deno test.js
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.
I basically want low level performance without writing in a difficult language
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
>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.
Its based on Nest
This is huge!
package main
import "os"
func main() {
for _, s := range os.Args[1:] {
o, _ := os.Open(s)
os.Stdout.ReadFrom(o)
}
}
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).
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.
(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.)
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.
The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.
So what is the benefit?
So what's the benefit?
Same can be said about any language really, it's personal preference
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...
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.
It gets packaged inside of the executable.
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).
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.
Then obviously for CLI tools, this is SUPER nice.
> Even server side, not everyone uses Docker.
IDK, tried to find alternatives the last years but for a bit more sophisticated app you can't ignore images and container orchestrators like k8s. And latter is still easier than anything I've seen and has by far the biggest ecosystem. If I want to host some minimal app, I just push an SSG to netlify/surge/vercel, it's not an integrated build step which makes my life easier.
> just pop the executable in there
Otherwise you would just need one more line in your build file (npm install).
> Then obviously for CLI tools, this is SUPER nice
Also, yes no, Deno "binaries" have huge file sizes compared to an npm install -g and rarely used CLI tools can be fired off with npx, so which problem is exactly solved? That I can offer CLI tools to folks who won't have node installed? Then I rather write my CLI tool in Go and offer an appropriate package size.
I welcome competition and hence Deno but think this feature doesn't fulfill any (relevant) use case. Only beginners who struggle with the build step (which can indeed get hairy) profit from this design decision but a bit more advanced users will miss the control they had before.
As for CLIs, the Deno executable overhead is about 47 MBs. Not nothing, but also ... that’s like a few extra seconds of download time for the tool, and insignificant disk space when people have hundreds of GBs on their laptops. If I’m writing some sort of command line tool, the tool being 50 MBs bigger probably does nothing to hurt adoption. But it having zero external dependencies WILL help adoption, vs. npx and screwing around with proper node versions and whatnot.
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.
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.
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.
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.