I just looked up Deno and it’s part of an NPM stack.
It’s not. It supports NPM modules for backwards compatibility, but the whole point is that it doesn’t inherit the NPM tooling mess. You can go from a new Linux install to a running Fresh project in 3 commands.
Deno: this is a replacement for Node and NPM and prettier and some other tools. So one aspect is that it’s a more modern Node, using standard web APIs instead of Node specific stuff. And the other aspect is it is more streamlined modern tooling - no node_modules, no complicated build steps, built in Typescript support, etc. In fact you can use a single file as a script, similar to Python… but unlike Python you can use third party dependencies, which makes it fantastic for stuff like CI scripts, etc. where you might have suffered with Bash or Python before.
Fresh: this is just a web framework targeting Deno. Honestly I haven’t used it much but I really like what I’ve seen so far. I always found React to be confusing and overkill for most sites, which should really be rendered server side, but also I really like the way you can compose components with JSX/TSX in a real language with full type checking. Fresh gives you both!
It has them, but you can’t use them from a single-file script. You have to set up a pyptoject.toml, create a venv and then pip install . in it. Quite a lot of faff. It also makes some things like linting in CI way harder than they should be because the linters have to do all that too.
With Deno a single .ts file can import third party dependencies (you can use any URL) and Deno itself will take care of downloading them and making them available to the script.
Some other languages have this feature to certain degrees. E.g. I think F# can do it, and people are working on it for Rust, but Deno is at the forefront.
As you allude to there are tools in python to help (I tried pex briefly once, for example). It hasn’t really been a pain point for me but I can see why people would spend time on it. I imagine this strategy has its share of tradeoffs and gremlins.
I haven’t actually used pex but it doesn’t look like it solves this - it’s more of a way of distributing full programs. The .pex files aren’t editable, which is something you need for this use case.
I imagine this strategy has its share of tradeoffs and gremlins.
As far as I know there are no downsides. It’s basically win-win.
It’s not. It supports NPM modules for backwards compatibility, but the whole point is that it doesn’t inherit the NPM tooling mess. You can go from a new Linux install to a running Fresh project in 3 commands.
Okay, I’m interested. What stack is it part of? What kind of servers does it use?
There’s two things:
Deno: this is a replacement for Node and NPM and prettier and some other tools. So one aspect is that it’s a more modern Node, using standard web APIs instead of Node specific stuff. And the other aspect is it is more streamlined modern tooling - no node_modules, no complicated build steps, built in Typescript support, etc. In fact you can use a single file as a script, similar to Python… but unlike Python you can use third party dependencies, which makes it fantastic for stuff like CI scripts, etc. where you might have suffered with Bash or Python before.
Fresh: this is just a web framework targeting Deno. Honestly I haven’t used it much but I really like what I’ve seen so far. I always found React to be confusing and overkill for most sites, which should really be rendered server side, but also I really like the way you can compose components with JSX/TSX in a real language with full type checking. Fresh gives you both!
In what sense does python not have third party dependencies?
It has them, but you can’t use them from a single-file script. You have to set up a
pyptoject.toml, create avenvand thenpip install .in it. Quite a lot of faff. It also makes some things like linting in CI way harder than they should be because the linters have to do all that too.With Deno a single
.tsfile can import third party dependencies (you can use any URL) and Deno itself will take care of downloading them and making them available to the script.Some other languages have this feature to certain degrees. E.g. I think F# can do it, and people are working on it for Rust, but Deno is at the forefront.
Oh I see what you mean. Interesting.
As you allude to there are tools in python to help (I tried pex briefly once, for example). It hasn’t really been a pain point for me but I can see why people would spend time on it. I imagine this strategy has its share of tradeoffs and gremlins.
I haven’t actually used pex but it doesn’t look like it solves this - it’s more of a way of distributing full programs. The
.pexfiles aren’t editable, which is something you need for this use case.As far as I know there are no downsides. It’s basically win-win.
I found it in the docs https://docs.deno.com/runtime/manual/basics/modules/#importing-by-url
Not sure if that generates like a lockfile or how it handles peer deps. Intersting nonetheless.
It can optionally use a lock file. Not sure about peer dependencies tbh.