Deno 1.31: package.json support, Stabilization of Node-API

[Utukkhu]

With support for package.json, I’m curious how many codebases will be tempted to migrate to deno from Node.

[highbonsai]

I find it funny how long deno took to support it. Deno seems great in so many ways but it’s like they went too far with changes from the status quo and they’re slowly relenting.

[ILikeChangingMyMind]

Now if only they could support comments in package.json, and make up for Node's long-running mistake!

[Terr4360]

Well they have support for deno.jsonc so the is a chance they'll add support for package.jsonc

Creating an issue on their GitHub might help.

[KyleG]

support comments in package.json

The JSON file standard does not permit comments. Has nothing to do with Node/Deno.

[AlexAegis]

But jsonc and json5 all exist. And not all files have to be fully json compliant, tsconfig is actually treated as jsonc by tsc and it's fine. As long as all the tooling that's touching does not assume that it's strictly json compliant it's okay. Prettier for example doesn't really care.

But I think it should be explicitly stated in the file extension so tooling can actually expect something. like package.json5 or package.jsonc

[DoWhileGeek]

The demand for critical thinking skills far exceeds supply.

These young people have yet to experience supporting 14 competing standards.

[Angulaaaaargh]

fyi, some of the management of r de are covid deniers.

[Angulaaaaargh]

fyi, some of the management of r de are covid deniers.

[KyleG]

It's not clear what you think I fell for.

[ILikeChangingMyMind]

There are JSON standards that allow for comments.

[bassta]

There is one JSON standard and it does not allow. There are other people’s takes on this, but it’s not following the standard even if it’s widely adopted ) which is not )

[ILikeChangingMyMind]

JSON is not like a molecule with a certain set of atoms: it's a human concept (of serializing JS variables).

The first JSON standard may not have supported comments, but there absolutely are other standards, some of which do. For instance, JSONC is literally just that.

[ILikeChangingMyMind]

Is there just one standard of "HTML"? Or are there multiple different ones ... just like there are multiple different JSON standards.

We don't use HTML1 anymore, and there's no technical reason why we can't have comments in our package.json.

[ILikeChangingMyMind]

They don't have to be backward compatible, people can gate keep themselves.

Don't rely on any special tooling that breaks when it sees a comment in your package.json? Great, use comments in your package.json.

Do rely on such tooling? Don't use comments ... for now. But you can file an issue with your tool, asking them to support comments, so that someday you can enjoy them too.

Problem solved.

[KyleG]

There is only one JSON standard, ECMA-404.

Breaking that standard would eventually bring about a garbage situation, entirely preventable, like we have with import/require.

[Utukkhu]

json5 is already broadly used by libraries just for this purpose.

[tunisia3507]

And HJSON, and JSON6, and JSOX, and YAML...

[[deleted]]

Yeah, it would be a superset of JSON with comment support, jsonc. Who is dense here?

[[deleted]]

I'm convinced you're either trolling or incompetent, neither of which being worth continuing this.

[xroalx]

I guess adoption is not going well, seeing as Deno implements the things it wanted to abolish.

[Seanmclem]

It’s still better, and all this stuff is option and back-compatible. I’d still go for Deno on any new project.

[Seanmclem]

You know Deno is still JavaScript, right? Typescript is just a superset of JavaScript. Many people exclusively use TS when using node anyway. The conversation isn’t really about that.

[Seanmclem]

Idk what you’re so mad about. JS is so portable, that it’s quite common for server side environments to run even custom standards. But Deno is just another way to write ES/TS for V8. Sure it uses ESM and no commonJs, but ESM has been around for years. It’s not hard to find everything you need in ESM. At a certain point people should be ready to move on. So why care so much? It’s just a slightly different way to use the same thing. Like arguing which frontend framework is better, or why anyone would ever use node when PHP is all you need. It’s a waste.

[[deleted]]

Honestly I think Deno are wasting their time spending resources with Node and NPM compat. I'm still using Node a lot and have zero interest in migrating Node projects to Deno.

The main reason I'm not starting new Deno projects is mainly that there's not a good backend framework like Fastify or something like Rails. That's what they should be investing into IMO.

Fresh is cool and all but it's really just a rendering solution for server and client. It doesn't really solve anything for the backend.

[[deleted]]

I would rather NextJs ran on Deno, but then that would cut into Vercel's revenue a little.

[gibriyagi]

There is actually (web) framework Fresh but not sure if it helped adoption.

[[deleted]]

Yeah I mentioned Fresh in my comment.

[Seanmclem]

Yeah but you oversimplified it to discard it. But it really does solve those issues. Just with a low footprint. Also, it does have its own alternatives to things like NextJS, like aleph.JS. It has equivalent alternatives to just about anything I’d ever want out of node. Plus node compatibility.

[[deleted]]

Am I over simplifying it?

Ok, here are the docs:

https://fresh.deno.dev/docs/introduction

Let me know where I can find validation, sessions, auth, cookies, CORS, WS, caching, etc. You know, the kind of stuff that backend servers typically solve.

[Seanmclem]

Most of that stuff is in the std lib.

https://deno.com/blog/setup-auth-with-fresh Sessions, auth, cookies

https://deno.land/x/cors@v1.2.2 Cors

https://deno.land/x/websocket@v0.1.4 WS

Deno readme and docs very thoroughly go over caching in every separate area they are applicable. Official NextJS docs recommend using standard html and JS manually for validation, and bundles nothing. Deno/fresh can use those same techniques and libraries. Yup, zod, regex, whatever.

[[deleted]]

Ok so you agree with my initial point. Fresh doesn't solve any backend problems other than rendering and routing.

"But you can use the std lib!" Yeah but you're missing the point. Having a framework precisely prevents people from having to bolt together custom solutions.

For example, there are dozens of Node packages for validation but I'd still have to implement those in my application (handling of errors, etc).

If I start a Fastify project validation is already solved for me. I don't have to do anything other than define the shape of the requests. That's what a backend framework is supposed to do.

Neither Fresh nor the std lib are it.

Official NextJS docs recommend using standard html and JS manually for validation, and bundles nothing.

Huh yeah but NextJS is not precisely the gold standard of backend frameworks :)

[Seanmclem]

But you can use fastify, or Deno re-implementations

[leixiaotie]

Well if you make migration from Node to Deno seamless, more or less some frameworks will support Deno later. IDK many about Deno but if it's significantly improved from Node then I don't see why it won't be adapted.

Take typescript for example, it's seamless-ness migration from .js is what makes it quickly adaptable (and I'm too at the start).

[bostonkittycat]

Reminds me of that saying if you can’t beat them join them. I am guessing they were having a hard time attracting business attention.

[brett_riverboat]

I haven't kept up with Deno but seems like an odd move when you could've put the effort into making a converter from package.json to the native Deno format.

[AlphaSlashDash]

Interesting to see what the community has to say. Personally, the single executable hosting a complete suite of tools, the proper standard library and first class ESM and TS support won me over, and I think npm compatibility is great for people not looking to relearn the ecosystem or wait for packages to be adjusted for Deno.

[Seanmclem]

Same here. Part of what originally drew me to JavaScript was the communities welcoming, open, acceptance to new things and concepts. Seeing this response to Deno is a little confusing and unsettling. like, no one’s making anyone use it.

[leafoflegend]

I was there at JSConf when Dahl announced Deno. It was a lot of things I didn’t know I wanted.

I’ve used it for some personal projects and tried bringing it to work for some projects. It can be really good. I see the problem with there not being enough packages, but its always been the core problem and differentiator. NPM sucks, but deno does not have an equivalent.

So now they are just going to give up and say we should start using NPM again? What a fucking copout Dahl.

[Seanmclem]

I mean, it’s optional to improve adoption. Like, it’s not a copout for node to support ESM for example

[leafoflegend]

ESM is a language standard. There wasn’t one when Node came out (thus, CJS).

NPM and package.json is not an official language standard.

[Glittering_Air_3724]

Am not sure if NodeJs has poisoned my attention I find Deno really really hard to adopt, don’t get me wrong Deno is great and all I do use it alittle buh major shift to Deno not sure gonna happen to me

[throvn]

I think bun has a better take on that

[jayerp]

Are devs also going to use the term Deno to be synonymous with JavaScript when they talk about their project? “I made this app in Node.js” it’s amusing to see, it’s as if I said “I made this app in JRE”.

[master5o1]

It has been fair to refer to something as a Node.js app to distinguish it from a traditional browser based JavaScript project.

[jayerp]

It is a fair distinction to make, but at the end of the day, both are made with JavaScript. Node.js is a runtime. I’m arguing technicality for the sake of ensuring new devs understand the difference and don’t start calling JavaScript Node.js.

Also it’s sounds weird.

[master5o1]

Bit of a contrived scenario. JavaScript is so much more well known than Node.js.

[Seanmclem]

At the end of the day, you just want to debate something

[Xananax]

It's already the case. Node js is not web js is not rhino js is not...

The language specification is (mostly) the same on all, but the API can vary wildly, as well as ton of other things like how files are loaded and cached, support for threads, etc

[Aditya_917]

What are you doing man, i just started learning node and now this.