This is what the creator of node is doing in his new project. Specifically sandboxing the runtime unless certain capabilities have been whitelisted

They're pretty close https://deno.land/benchmarks, usually within 10% by the graphs.

I think that's pretty impressive, being less than a year old vs a 10~ year project with a decade of optimisations & work :), I assume we can expect it to match node performance in the future.

The current "standard" of Deno modules has been to have a deps.ts file where all dependencies are listed:

export { Response, serve, ServerRequest } from "https://deno.land/[email protected]/http/server.ts";

export { basename, extname, join, isAbsolute, normalize, parse, resolve, sep } from "https://deno.land/[email protected]/fs/path/mod.ts";

And then in the rest of your code you would import from that deps.ts file. For example:

import { join } from './deps.ts'

As a C and C++ programmer myself, I always feel the need of something more from C and a lot less from C++.

Rust fill that niche pretty well.

The object system is amazing and one of my favorites so far, because it forces you to think on terms of data and the behaviour you attach to that data.

Also favours composition over inheritance. Which is a huge deal. No more those huge multi-layer objects that makes your head spin.

You also have _amazing_ projects like Tokio! which gives you an asynchronous future based multi-threaded non-blocking I/O engine. Which leaves Java, Go and Node.js on the dust.

It is also made for the long future. The world is shifting from bulk processing loads to low latency micro loads. Where everything should have the least amount of lag and customised per user. That is where GC languages don't perform very well.

And last, Ryan dahl, the creator of Node.js (which is one of the most popular software development framework on US and EU markets) choose Rust and Tokio to build the runtime of his current project and Node.js successor Deno (https://deno.land/)

I hadn't heard about Deno before today.

So, based on my read, this is a redesign of Node using modern concepts that didn't exist when Node was first created?

Could be potentially useful.

But as I read further... I see a glaring issue that will keep me from ever using it: importing directly from urls.

Horrible, horrible idea. Even their suggested fix is absolutely horrible for production level code.

My take: Deno appears to be a fine for sysadmins to build scripts that are more complex than a shell script can handle, but I sincerely do not see it ever being used for major applications such as web or even CLI applications.

You directly import them from the internet, smth like

import { Application } from "https://deno.land/x/oak/mod.ts"; const app = new Application();

vs

const express = require('express') const app = express()

So basically nodejs without needing a package.json. Imports work like this instead.

import * as log from "https://deno.land/std/log/mod.ts";

Plus typescript out of the box plus some security guarantees by sandboxing and restricting access to the system.

Seems like a solid improvement on node in theory. I wonder how it will play out.

https://deno.land/manual.html#philosophy

Deno doesn't download anything that isn't imported, so "publishing" isn't like it is on npm where the whole packages is downloaded. The README will be on deno.land, but it wont get downloaded because it won't be imported.

I really hope your research extends beyond asking reddit to actually searching for some of these answers.

No
The deno manual
Skypack offers a way to get most browser-compatible packages as deno-compatible
Other than the above, there is this official kit from the deno std
Deno testing is built in
No
Deno lint is built in, works with the VS Code plugin

The "no"s above are afaik

From deno's website: https://deno.land/manual#philosophy

> Deno aims to be a productive and secure scripting environment for the modern programmer.

I don't think there's undue emphasis from deno here claiming "it's rust, it'll be fast!". Rather, it's a blank slate to make different design decisions. Rust was chosen for security rather than performance I expect?

Having said that a lot of the deno built ins seem to be getting performance body from being rust vs JS which is nice

There was an issue about permissions per module, but it was closed because, among other reasons, semantics, the current permission model works like browsers and "If you're going to import some file/package you should be responsible for checking what permissions it requires.".

I agree that semantics for that is complicated, but I think the adopting browser permission model is bad because browsers have per-site isolation but how Deno is going to do that for applications that require executing external binaries? Also, even if you would whitelist some binaries, there are Deno packages, such as deno-puppeteer, which don't list what permissions it requires, instead it instructs users to enable all permissions using -A. By the way, why just -A? Why not --unsafely-enable-all-permissions (like Chromium's --unsafely-treat-insecure-origin-as-secure)?

I think someone will try to ressurect that issue when it gets popular at the point some package gets hacked and used to distribute malware. It might take more time than it took to npm as Deno is less popular than Node and because many packages lock their version numbers in the import examples from their documentations (deno-puppeteer does it, i18next doesn't), but it's just a matter of time.

Just released v4: redd.it/hnq2bt

// here's the code if you need it for some reason import { opine } from "https://deno.land/x/opine@main/mod.ts";

function denoVersion() { return new Promise((resolve, reject) => { opine().use((req) => { resolve(req.headers.get("User-Agent")?.substr(5)); }).listen(3000);

fetch("http://localhost:3000").catch(reject); }); }

if ( await denoVersion() === "1.1.2" || await denoVersion() === "1.1.1" || await denoVersion() === "1.1.0" || await denoVersion() === "1.0.5" || await denoVersion() === "1.0.4" || await denoVersion() === "1.0.3" || await denoVersion() === "1.0.2" || await denoVersion() === "1.0.1" || await denoVersion() === "1.0.0" || await denoVersion() === "1.0.0-rc3" || await denoVersion() === "1.0.0-rc2" || await denoVersion() === "1.0.0-rc1" || await denoVersion() === "0.42.0" || await denoVersion() === "0.41.0" || await denoVersion() === "0.40.0" || await denoVersion() === "0.39.0" || await denoVersion() === "0.38.0" || await denoVersion() === "0.37.1" || await denoVersion() === "0.37.0" || await denoVersion() === "0.36.0" || await denoVersion() === "0.35.0" || await denoVersion() === "0.34.0" || await denoVersion() === "0.33.0" || await denoVersion() === "0.32.0" || await denoVersion() === "0.31.0" || await denoVersion() === "0.30.0" || await denoVersion() === "0.29.0" || await denoVersion() === "0.28.1" || await denoVersion() === "0.28.0" ) { console.log("You are NOT on the latest version! Updating..."); Deno.run({ cmd: 'deno upgrade --version 1.1.3'.split(' ') }) } else { console.log('You are on the latest version!') }

As far as I know, there's no list, but try looking on Pika. It's a CDN for all the NPM modules that publish ES modules, if it works in the browser it's likely to work in Deno.
Import and re-export all of your external dependencies from a deps.ts file, and import from that file when using them within your project, then you have a single point to change for version control across the project.
Yes, I think so.
It's not that big of a deal, --allow-all is the same level of security that Node has by default, but you should try to set the fewest privileges possible
Install Denon, it's Nodemon for Deno.

I believe you are thinking of a svelte component template for deno. As of yet I am not familiar with anything of that sort. There exists a compiler for Deno so you could create your own template and use that as a base (or search github to see if someone else has done it). The compiler for Deno is called Snel: https://deno.land/x/[email protected]

This company is probably using the framework Express (which is one of the top most popular framework).

I don't see an issue using Express for non-FAANG companies. If anything, you would just spawn more nodes in your cluster to handle bigger scale. Working in Javascript is annoying but Typescript makes the programming experience a whole lot better!

If this is your first offer, I would take it. NodeJS is used in pretty much all modern front end development (React and Angular projects are typically Node projects; I doubt you'll find a project that uses CDN to import the dependencies).

Typescript is growing in popularity to the point where the "supposed" NodeJS replacement (Deno) supports Typescript out of the box. This popularity will stay for a while as the other "javascript-transpiler" languages aren't gaining any tractions.

The concepts you'll learn from doing backend engineer will transfer from language and frameworks. If anything, you'll at least be able to be pick up other languages / web frameworks extremely fast. Though, chances are, you'll probably find another job that uses the same stack...

So the issue is that Response wants the body upfront, the setCookie in /std/http wants to operate on a Response, and you want to build your cookies before you make your Response.

So let's look at the setCookie signature: https://doc.deno.land/https/deno.land/[email protected]/http/cookie.ts#setCookie

Turns out that `setCookie` doesn't need `Response` at all, it just wants `.headers` to be a `Headers` object. So perhaps a construction like this:

import { setCookie } from "https://deno.land/[email protected]/http/cookie.ts";

async function handleRequest() {

const headers = new Headers(); setCookie({ headers }, { name: 'deno', value: 'runtime', ... });

return new Response(myHtml, { headers }); }

I haven't tried running that, it's just based on the types.

Here is the relevant part of the manual: https://deno.land/[email protected]/tools/compiler

You probably just need to run

deno compile --allow-net --target <TARGET> path/to/script.ts

for each platform (target) you want. That should create a binary that your students can just double click to run.

The second paragraph in their manual states that not all the features are ready yet: https://deno.land/[email protected]/runtime/stability.

For me that's enough to wait till it progresses a bit more. However, something being production ready is really subjective so that probably depends on what sort of application you have in mind.

If we apply your specifier "instead of using node.js", my guess would have to be "probably not". Still, all you're really going to get from people is opinions. Opinions which are based on varying levels of experience with Deno.js. Why not jump in and try it out for yourself on an app you have in mind?

well, there is a promising SQLite wasm on deno that makes it system-independent and can be sandboxed.

You could find it less useful in front-end, but it truly is a game changer for back-end usage. No need to tie in your app to a runtime anymore.

> It doesn't seem feasible that you for instance know each and every tech, except the most well known things in Java.

It definitely does, most people do not know much at all in the space of every tech. For instance, I don't expect most people to know about for instance Kestrel, or Deno either. But going to any of these websites tells you what it is within one line and what it solves in bullet points.

Most people in this sub do not know what the post is about. Instead they will look into what it is, what it solves, and what differences there are to competing solutions. WildFly website at a glance doesn't answer any of that, instead there's lots of bloat with a website design from a decade ago.

So I get the "packages are URLs" thing... but what I'm still not sure about is... is there an efficient way to find out what packages exist (in one place), and get their URLs?

NPM workflow is:

Search on https://www.npmjs.com/
Paste the npm i <packagename> command into a terminal.

What about Deno?...

???
Paste the URL into deps.ts/deps.js as an export, and in the rest of your code, import from there.

I see there's https://deno.land/x ... but the list is small enough it just fit them on all one web page immediately. I guess it's still early days, but I'm not sure if setting up a competing registry system is going to help adoption.

Maybe there should be some kind of flag that package devs can put in package.json or something that marks as "works with deno". And then maybe NPM can modify their website to:

Tell you if a package works in Deno or not
If it does, somewhere near the npm i text you can copy already, also add a version for the Deno import

I think if there isn't an easy thing like this, it's gunna be tedious having to look for packages in 2+ different places.

Also if a lot of the packages available on NPM aren't going to work, and I want to switch to something other than Node, it'll probably be Rust. Although I do see some talk in the Deno github issues about compiling to binary, so that's a pretty cool thing to keep an eye on.

Node? That's old news. The cool kids use Deno now. ^((sarcasm))

Here is Ryan Dahl's conference talk where he discusses all of his regrets creating Node.JS and why he is creating Deno.

Most websites that present the directory metaphor, that aren't for git, let you right click on a link, and choose "Save link as" to download the actual file. Especially if hovering over the link indicates that the linked resource has the expected file name and extension.

Examples:

I've tried that and ran into a bug where it couldn't install dependencies for some reason. Gave up on it.

Plus it's undeniably shitty that to use dependencies you have to pick between 3 or 4 different incompatible project management systems, and run your code in a custom environment. Disgusting.

Compare that to Deno:

#!/usr/bin/env deno run --allow-net // Imports are versioned URLs, no need for any config files. import { listenAndServe } from "https://deno.land/[email protected]/http/server.ts"; listenAndServe(":8000", (req) => new Response("Hello World\n"));

You can literally just chmod +x it and then run it.

I'll try to pick some of your topics without repeating the other answers:

Some languages have dominance on the market but that doesn't mean they are perfect. That's the main reason to create a new language. I'm been developing with C++ for 7 years and it's an amazing language but has issues. Some of those issue, Rust tries to solve.

About your topics: Backend: Rust is a great option for it. You develop faster in node but Rust has some benefits: - Safety - Type safe, explicit optional values, explicit ownership - Performance - It's almost unfair to compare - You should check https://deno.land/, it's a node replacement in Rust. I think by the creator of node.

Games/Hardware: There are other comments about this.

Operating System: The "why" is your problem, you should find a project you like, whatever it is.

Web/Webassembly: Looks like you're a web developer that wants to look into Rust. You won't be able to do a fair comparison if you think about all the javascript ecosystem, it's already well developed, Rust is getting to it.

You should check https://www.arewewebyet.org/, specially the Yew library.

^ This

OP seems to look out for tools in a “Node.js manner”. Though this is not the point of Deno. Deno has batteries included in tries to get rid of these unnecessary arbitrary decisions you need to take with Node projects (linter, testing, bundler, etc.)

Just simply leverage the Deno standard library and guideline. I believe this opinionated view of Deno is its beauty.

I wrote these: https://deno.land/x?query=feoblog

feoblog_client is the client library, and the other 3 are tools that use it to grab data from RSS/Mastodon/Twitter.

deno is just another runtime for js, not a different language

think of it like node vs the browser

deno is an outside-the-browser runtime, just like node, but on the other hand it intentionally tries to be compatible with web apis (e.g. fetch, web workers, WebSocket)

about typescript and how deno compares - you'd be pleased to learn that deno has out-of-the-box support for typescript, jsx and tsx, a built in linter, formatter, test runner, code coverage tool, and an extensive standard library you can use

the deno manual is short and easy to understand, so you can start working with deno right away

I tend to follow the Deno contributors' style guide:

> Top level functions should use the function keyword. Arrow syntax should be limited to closures.

I also like to make use of hosting, which can make helper functions nicer:

export function doTheThing(items) { return items.filter(exclude).map(transform);

function exclude(item) { return !!item.y; }

function transform(item) { return item.x; } }

The return on the very first statement of the function makes its intent clear. Of course, often those helper functions can be just moved outside the containing function. But sometimes it's nice to keep them private, especially while you're still iterating.

Use fetch instead of axios, read Blob (file passed to the form) and set your headers with fetch options, headers usage example (you have to scroll a bit), basic headers handling sample:

const headers = new Headers(); headers.set('x-api-key', 'my-api-key')

The best practice is to put dependencies in a deps.ts file as explained here: https://deno.land/[email protected]/examples/manage_dependencies . The virus concern that you have is mitigated by using the security flags including --allow-write and --allow-read for file access and --allow-net for network access. These flags allow you to specify what files or network sites the program can use to minimize attack surfaces. Node does not have this mechanism, and history has taught us that npm can harbor rogue libraries.

Hey,

So it should be compatible with Windows already, as the UI is a web app that supports all modern browsers (tested in Chrome and Safari).

Running the whole thing on Windows is possible with Docker for Windows, or Deno.

It's probably not the most intuitive thing to set up, but I know a lot of Plex users run it in Docker, so it should be quick to get up and running for at least a few people.

Re watched movies, that might be useful, although the movie everyone else wants to watch might be one you've seen already 😅.

JavaScript is the language that runs in your web browser. ECMAScript is the standard that it's based on. You can mostly consider these terms synonymous, as they are often use interchangably, but they are not technically the same (for instance, there are other languages based on the ECMAScript standard, such as JScript and ActionScript).

TypeScript is a language that extends JavaScript, adding additional functionality (in particular static typing) while still being compatible with JavaScript (i.e. almost all valid JavaScript code is valid and equivalent TypeScript code).

You're pretty much correct that the reason why you usually can't run TypeScript directly is because JavaScript engines typically only support JavaScript, for instance this is the case in web browsers and Node.js. However, deno (built by the same guy who made Node.js) is a runtime that supports both JavaScript and TypeScript, using V8. I believe it does this by automatically compiling TypeScript to JavaScript when you run code, so you don't actually need a separate engine to do it, though.

I'm not sure if it would've helped in this case, but deno is an interesting middle ground here - it's a standalone runtime like node, but with a permissions/sandboxing system not unlike browsers.

Honestly, I'm confused by the sorcery that is the server in the standard library.

import { serve } from "https://deno.land/[email protected]/http/server.ts";

const s = serve({ port: 8000 });

for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}

I understand that this uses Async Iterators. I understand how Async Iterators work. What I don't understand is how this code can accept requests concurrently. Just hear me out here... what happens when we have 2 simultaneous requests to the following setup?

for await (const req of s) {
  await sleep(1000); // sleep for 1 second
  req.respond({ body: "Hello World\n" });
}

Does it process both requests in parallel? Does it stall for 1 second before accepting the 2nd request?

I set to find out.

It handles both, simultaneously.

It uses a mechanic called a Multiplexed Async Iterator. The code for which is pretty easy to understand. It basically takes multiple async iterators and combines them into 1, but uses some kind of trickery to continue accepting new requests.

But here's the kicker... if you copy/paste that multiplexer into Node.js as-is, and run two async iterators on it... they run 1 at a time because of that await sleep(...) statement.

What manner of sorcery is doing this?

Deno has sort of solved this with https://deno.land/manual/linking_to_external_code/import_maps

You would essentially treat this very similarly to a package.json dependencies. Unfortunately, it still has the problem that it doesn't support any semver style stuff.

IMAGE-TO-TEXT TRANSLATION (TYPESCRIPT[DENO]):

import { opine } from "https://deno.land/x/open@main/mod.ts";

opine().use((req) => { console.log(req.headers.get('User-Agent')?.substr(5)) window.close() }).listen(3000)

fetch("http://localhost:3000")

If you’re writing something like a CLI (any discreet non-long running thing), you can use the Deno Permissions API to request and revoke permissions (https://deno.land/typedoc/classes/deno.permissions.html)

I’d hope module writers could wrap any method requiring permissions in a request/revoke sandwich so permissions don’t leak out into other code. This likely wouldn’t happen until the API becomes stable though, and requires module writers to put in the legwork (so no help to end users potentially if they haven’t). It would also only really be practical for CLI like tooling as requests require manual intervention (and to use expect scripts to auto-grant would just defeat the purpose!)

Why? Deno was made by the main author of nodejs. Making node deprecated will only happen naturally as the project progress and beat node (hopefully) on pretty much every benchmark. Making npm deprecated could be an another issue that being said.

Now, since package.json doesn't exist with the ability to install third party library on the system, how the community will actually deal with:

being unable to share their custom tools in a traditional way(eg. npm install ...)
having to call deno when using a specific module(see unix cat)
maybe having to make a custom "alias" script for every deno third party module? Making a simple bash alias for every deno utils would be easy enough: alias deno_cat=deno run --allow-read https://deno.land/std/examples/cat.ts

I guess, this could also open the door for someone to make their own package manager to deal with this(alt version of npm) and then... the cycle restart? At this point, not sure if this idea hold well with the new deno philosophy of "being secure" and actually not using the same concepts as npm. I guess we could simply use an alias system to map a specific commands to specific deno toolings with some sort of "alias manager".

Such "alias manager" would make it easy to see which tools has permissions flags such as --allow-read, etc.

> From my understanding (or hope), scripts you import don't have explicit dependency chains. A packaged deno library doesn't really tell deno what it needs and is, instead, a actual pacakge with everything it needs inside.

This sounds like you're referring to deno bundle, but most packages I've seen on https://deno.land/x, for example, are not packaged in this way. Each module (JS or TS file) imports its dependencies, and Deno fetches (and caches) them as it becomes aware of them.

You’ve actually got me interested in it to be honest, if you do have a play with it let us know your findings :p I guess Deno is easier to setup compared to Node and Python, you run 3 commands to install and that’s literally it

I get what you mean, obviously Python and Node are the ‘safe’ options due to the maturity, but if you haven’t already have a look at Deno’s third party modules: https://deno.land/x/, see if there’s anything there that can help your decision

One good rule of thumb is to use arrow functions only for closures, as described in the Deno coding style guide.

This does not sit me well:

>Deno, just like browsers, loads modules by URLs. Many people got confused at first when they saw an import statement with a URL on the server side, but it actually makes sense — just bear with me:
>
>import { assertEquals } from "<code>https://deno.land/std/testing/asserts.ts</code>";
>
>What’s the big deal with importing packages by their URLs, you may ask? The answer is simple: by using URLs, Deno packages can be distributed without a centralized registry such as npm, which recently has had a lot of problems, all of them explained here.
>
>By importing code via URL, we make it possible for package creators to host their code wherever they see fit — decentralization at its finest. No more package.json and node_modules

It then goes on to explain that:

>Since it’s not a centralized registry, the website that hosts the module may be taken down for many reasons. Depending on its being up during development — or, even worse, during production — is risky.
>
>As we mentioned before, Deno caches the downloaded modules. Since the cache is stored on our local disk, the creators of Deno recommend checking it in our version control system (i.e., git) and keeping it in the repository. This way, even when the website goes down, all the developers retain access to the downloaded version.

Isn't that the opposite of what you want?

> the lack of a coherent packaging story just means that people are going to do the easiest set of things

This is the biggest flaw I can see so far. While it's easy to add a version string to the import URL, it also depends on the upstream package actually tagging/branching diligently and so on. Maybe if the deno executable included a simple package management script e.g. deno add https://deno.land/std/http which would automatically add the full string with latest version tag or commit to your dependency file... but it may take a bit more time for conventions/workflows like this to emerge.

From the manual:

> It will always be distributed as a single executable - and that executable will be sufficient software to run any deno program. Given a URL to a deno program, you should be able to execute it with nothing more than the 50 megabyte deno executable.

Something about this unreasonably excites me. I actually quite like TypeScript the language, but the JS ecosystem always frustrates me to no end. Having such a minimal new beginning which is compatible with TypeScript sounds awesome.

> Deno explicitly takes on the role of both runtime and package manager. It uses a standard browser-compatible protocol for loading modules: URLs.

This will be interesting; it brings some of the simplicity of go get, but all the examples already include versions, so it quickly sidesteps at least that problem. But versions are a tricky beast, so we'll see how it goes...

You should check out Deno. The person that created Node is working on Deno right now and it looks promising. It will only work with Typescript as far as I know.

Instead of writing it in C++, he is using Rust. He started out using Golang, but switched to using Rust because he was worried the garbage collection in Golang would be a problem. Also, Rust is just a better language for this kind of thing IMO

https://deno.land/

Since you are using unversioned URLs it's totally expected that the code can change from under you. If the URLs were pinned to the specific version then they would still work with newer version.

I haven't run the code, but it should look something like this (with latest pinned version of deno_std): ``` import { serve } from 'https://deno.land/[email protected]/http/server.ts'

esbuild.serve({ servedir: './' }, {}).then(() => { serve(async (req) => { const { url, method, headers } = req if (url === '/esbuild') { req.write = (data) => { req.w.write(new TextEncoder().encode(data)) req.w.flush() } req.write( 'HTTP/1.1 200 OK\r\nConnection: keep-alive\r\nCache-Control: no-cache\r\nContent-Type: text/event-stream\r\n\r\n' ) return clients.push(req) } const path = ~url.split('/').pop().indexOf('.') ? url : /index.html //for PWA with router const res = await fetch('http://localhost:8000' + path, { method, headers }) const text = await res.text() await req.respond({ body: text, statusCode: res.statusCode, headers: res.headers }) }, { port: 3000 })

setTimeout(() => { const open = { darwin: ['open'], linux: ['xdg-open'], windows: ['cmd', '/c', 'start'] } if (clients.length === 0) Deno.run({ cmd: [...open[Deno.build.os], 'http://localhost:3000'] }) }, 2000) //open the default browser only if it is not opened yet }) ```

Let's unpack some of your questions.

From your background, you may like to take a look at Deno , it's node alternative written in Rust. Rust is great for backend dev with some crates already in production level.

For frontend, the current state is not great but promising. The tooling for wasm is pretty good but it's not my area so I cannot give details. You may like to take a look at https://yew.rs/

College degree is not a requirement, I also don't have it (in CS), but you should be able to demonstrate your skills. Opensource projects are a plus but also not a strict requirement.

Working remotely is a changing market, I'm currently remote but my company wants to go back to office as soon as possible. This is more a per company policy then a tech choice.

About getting a job in Rust. Rust is still a growing language, there are not many work options but there are not many developers either. Most rust positions will have some flexibility about your Rust knowledge level, depending on your other language skills.

In any case, learning Rust may help you sharpen your programming skills. It was great for me and eventually I got a Rust job.

Dunno who down voted me and why, when Deno explicitly state the difference between itself and Node.

If the op has a Node app, it must be using native node modules or npm packages, which would not carry forward to the Deno app.

You can create a single file (usually called deps.ts) where you import all external dependencies. You can then import this deps.ts file in your source code. If you want to change one package version or change it's source, just do it from the deps.ts file.

//deps.ts export * as log from "https://deno.land/x/[email protected]/mod.ts";

//main.ts import {log} from "./deps.ts";

If you don't like using a single file to manage your dependencies, you can still use your IDE to find and replace the URL in all your source files.

Deno cache every package you try to import. It will download it from URL only if he can't find it locally. It's the same issue with other package managers.

I think the only improvement deno can make is to let us declare a "node_modules" equivalent in a local config file or something. It's sometimes useful to deploy a node application without running "npm install" and shipping it with a full "node_modules" folder.

Indeed. I found I still want to drop Node though. Node's sibling Deno is just a single executable sitting on PATH that can pipe css through various ES modules on CLI including PostCSS with plugins and rust/go tools.

deno run postcss/import.ts -i "app.pcss" | tailwindcss -i - --minify > final.css

And if tailwindcss ever gets ported to Rust? Can switch without a care in the world. Don't like cssnano? Can use esbuild instead and have it done 2x faster and then perhaps gzip-it.

deno run postcss/import.ts -i "app.pcss" | tailwindcss -i - | deno run postcss/autoprefixer.ts | deno run "https://deno.land/x/esbuild/mod.js" --loader=css --minify | deno run compression/gzip.ts > final.css

Or I can write the whole thing in a single `.ts` file including watchers. Separation of concern works magic here.

Wow, this looks fairly well implemented and quite usable. I wouldn't want to release a library that uses it, but it could definitely be helpful for prototyping or one-off codegen for a program. It reminds of Servo's CSS parser, a bunch of which is generated using Mako files.

I am also definitely amused at how cursed the concept of running JavaScript "inside" the Rust compiler is.

BTW, are you aware of Deno?

Javascript in Deno, 459/293

Cleaned up solution is pretty tiny:

import {readLines} from "https://deno.land/std/io/mod.ts";

function isPart1() {
    return Deno.args.length == 0 || Deno.args[0] == "1";
}

const grid = new Map();

for await (const l of readLines(Deno.stdin)) {
    const points = l.split(" -&gt; ")
    const [x1, y1] = points[0].split(",").map(x =&gt; parseInt(x, 10));
    const [x2, y2] = points[1].split(",").map(x =&gt; parseInt(x, 10));

    if (x1 == x2 || y1 == y2 || !isPart1()) {
        const dx = Math.sign(x2 - x1);
        const dy = Math.sign(y2 - y1);
        for (let x = x1, y = y1; x != x2 + dx || y != y2 + dy; x += dx, y += dy) {
            const key = `${x},${y}`;
            grid.set(key, (grid.get(key) ?? 0) + 1);
        }
    }

}

console.log(Array.from(grid.values()).filter(x =&gt; x &gt;= 2).length)

I could be wrong, but I think any ES modules that run in the browser also run on Deno. You only hit problems when using CommonJS, which neither Deno nor the browser understand natively.

There is a chapter of the Deno docs on Node compatibility if you're interested.

But really, the question is... what are you trying to do? I don't know the use cases for the Deno bundler all that well. Deno always struck me as a backend thing, whereas for frontend bundling I tend to use Vite or Snowpack.

GitHub could do better. Look at this page: https://deno.land/[email protected]/examples

It has a similar interface to GitHub. If you click one of the file links it brings you to a preview page for the file. If you hover over a file link it looks like a file link. However, if you right-click and save as, it actually saves the file, not the HTML page.

I assume by now you already know, but successfully installed it using the install command:
curl -fsSL https://deno.land/x/install/install.sh | sh

Deno was installed successfully to /home/pi/.deno/bin/deno

Manually add the directory to your $HOME/.bash_profile (or similar)

export DENO_INSTALL="/home/pi/.deno"

export PATH="$DENO_INSTALL/bin:$PATH"

Run '/home/pi/.deno/bin/deno --help' to get started

Deno addresses a lot of that by pushing Typescript, providing a decent standard library, having module versioning, signing, giving the runtime no permissions by default, fixing the exponential module tree hell etc.

I'm not a big JS guy, especially not on the backend, but if I were to write JS/TS services I'd pick that over Node.

I’d like to merge a module I made with the std. I don’t think it fits in collections because it contains generators not functions that return arrays. What are your thoughts on this? https://deno.land/x/[email protected]

Much more modern API that aligns more with the core language itself. Node started at a time when JS was a hot mess. JS has changed a lot since then.

Not to say Node is useless, because it definitely moved the entire world, and has a massive ecosystem. If Deno could somehow become compatible with every Node module at some point in the future, and effectively absorb the ecosystem, then it Deno would be the logical successor. It looks like they’re headed that way, so it makes sense someone would consider Deno to be the future.

> My inner impulsive side looks at anything that imports directly from a URL and recoils in disgust.

That was my initial reaction too, but it has some pretty big advantages:

Decentralised - no arguments about package names / namespaces.
No need for a Cargo.toml or dependencies.txt just to specify dependencies (this is great for single-file scripts)
Easy to host private packages registries.

And if you think about it it's not really any different to package.json or Cargo.toml - there you're already using URLs; just with a hard-coded host.

You might think "but what about vendoring dependencies?" or "importing from URLs is ugly and verbose" or "what about security?" but there are solutions to all of those: https://deno.land/manual/linking_to_external_code#faq

>[T] he colloquial pronunciation is the preferred pronunciation by definition.

Preferred by the originator, not the masses. I chose preferred instead of "correct" to help explain it better, but feel free to make that substitute on your own if you're still confused by what I meant.

>[T] hat doesn't appear to be happening after 8 years of effort.

Again, longer than that. Still doesn't diminish the effort or desire and 30+ years it hasn't changed the way I pronounce it or scoff at those who use a hard "G." Potato - potato.

Whoever coins something is absolutely the authority on the matter, it just may not be readily adopted. Another example in the making right now is Deno. Created by Ryan Dahl, and despite having himself pronounced it as d-eh-no early in development, he has said before release and ever since, that it should be pronounced d-ee-no, like the dinosaur, Dino, and rhyming with Reno.

I follow Ryan Dahl's preference as the originator of Deno, just as I do with Steve Wilhite's preference for GIF. If you know what was desired by the originator, and in both of these cases it isn't open to dispute because they have it on record, it is respectful to recognize what they desired; after all it is a product of their good graces that we have these technologies in the first place.

Hi :)

I tried running the TCP example using windows, and it's working as expected. The manual on the main branch provides better instructions for Windows: https://deno.land/manual@main/getting_started/first_steps#tcp-server. Let me know if you're still having issues.

Deno has recently revamped a lot of the HTTP/WebSocket stuff under the hood, so it wouldn't surprise if some random, not that actively maintained websocket library has become incompatible with current versions of deno.

May I suggest using the "official" ws library that is found in the deno std modules; that's maintained by the deno devs and should be up to date with latest developments: https://deno.land/std/ws/README.md

Given that ws.send is an async function and that your error is complaining about uncaught error in a promise, didn't you have to await ws.send()?

I use the sqlite module and wrote a function that returns the rows from the sql query as an array of { columnName: value } objects

Deno download dependencies in a platform-dependent cache directory or DENO_DIR so I think you can control it by that environment variable (I've never tried though)

https://deno.land/manual/linking_to_external_code

I never tried it myself, but I heard some good things about the Deno LSP. Not sure how/if it integrates with Nodejs projects though, maybe someone knows.

Hi there! I archived the repo since I don't have much time to improve on it and also in the end I ended up not liking the overall architecture (too much OOP style) because lately, I'm hopping over to the FP bandwagon (I may give it another go someday and build a new task scheduling library for deno 🤷‍♂️).

Anyway, the only library I know of is `deno_cron` but it does not have database sync support (for your tasks).

You can always use this archived lib (https://deno.land/x/[email protected]) but I definitely don't recommend it for prod applications.

Hi guys,

The lib can be found here: https://github.com/FSou1/fsquery (and here).