How many runtimes are there for JS? They seem to pop up once a week...
Deno 1.14
31–40 of 111 posts
Re: Deno 1.14
#32Earlier quoted context omitted.
Probably not, but Deno has Oak, which is Express-like and the combination of those two will get you close. But most node libs are not compatible and similarly node projects.
Isn't there a compatibility layer available, or are there reasons that in principle make this impossible?
There is a compatibility layer but it is not complete.
One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port
Re: Deno 1.14
#33Earlier quoted context omitted.
Thanks, I usually do, but in this case they are typescript issues and have tickets in the ts repo. For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record ` when used with conditional types to mean "any non-primitive value".
This comment right here is enough for me to become suddenly much less keen on Deno. If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way…
I agree wholeheartedly with the argument: tools getting in a way is the ultimate annoyance; in fact, struggling to force Jest to play nicely with ESM modules and TypeScript was the final straw that pushed me towards Deno for library development.
However, the argument can be made against any tool, and I'd say Deno here is the least deserving: in most cases it has just adopted the "defaults" set by tsc, eslint, or prettier, and just like them it allows ignoring these rules where necessary.
That said, I also think Deno made the right choice by enforcing these by default. Hopefully, it will fight the tide of low-quality code that plagues NPM. I do have to wrestle the linter, but it's mostly because I'm writing libraries that by themselves are pushing the limits of the TS type system, e.g. in structurae[1] I make an extensive use of mixins extending built-in objects, and mixin support is still nascent in TS. This is far less common in day-to-day production code, where, for example, using `any` or `object` is more often a sign of sloppy thinking rather than a necessity.
Re: Deno 1.14
#34I tried out Deno last weekend for a fun little hack project (syncing a local Markdown file to a formatted Google Doc), and it was awesome. Writing TypeScript code for Deno feels a lot like writing Go (which is a very good thing to me): - opinionated build/fmt/deps - well-designed stdlib - no need for scaffolding files (.eslintrc, babel.config.js, jest.config.js, mocha.opts, etc.) If that sounds good to you, try Deno!
I also tried it out recently, because I wanted to make a small utility for myself and liked the idea of it providing a single executable (and bypassing the node/NPM ecosystem for learning a JS/TS based system appealed to me). It delivered on that beautifully, as all I did is switch from running "deno run" as I was for testing to "deno compile" and it delivered to me exactly what I was looking for. A bit large at 57 MB but that's not too bad for a fully bundled JS runtime and no library dependencies except glibc that I could see.
As someone that's barely touched node for dev and always been put off by NPM and how that works (and the heavy build chain for some stuff), I find it much more palatable.
Re: Deno 1.14
#35Earlier quoted context omitted.
Isn't there a compatibility layer available, or are there reasons that in principle make this impossible?
There is a compatibility layer but it is not complete. One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port
Who doesn't love being removed even further from the platform they're running on?
Re: Deno 1.14
#36Earlier quoted context omitted.
"Easy" is highly subjective. If you're proficient at picking up new architecture paradigms for familiar languages, you're adept with ESM syntax, and refactoring is a skill; then you might consider it easy. It's a paradigm shift, so there's always going to be some friction in migration. For your express needs, check out Oak https://deno.land/x/oak@v9.0.0
Could you clarify what is the paradigm shift? Static types? (If so I agree, but using Node does not imply not using TS)
Probably more the removal of nodejs apis in favour of browser apis. For everything. (modules/imports included).
Re: Deno 1.14
#37Anyone using Deno in production? Would love to hear how it's going for your team.
We tried it for a couple months, it was basically a huge hassle getting our stuff to work especially anything that has bindings to CPP (any of the node gyp packages). Also felt like we were putting in a lot more effort to try to get packages with docs for node to work similarly in deno, and weren’t really feeling any value from using deno over node. If you’re a hobbyist or an academic or starting a totally new projec…
I honestly think the switch (being getting node libraries working in deno) won't happen.
I believe it will be a much better if the community puts time into making a larger module pool that is upto the standard of node
Re: Deno 1.14
#38It's always worth reading the Deno release notes even if you're not using Deno because it's such a fascinating collection of interesting ideas.
I always learn something new from them.
In this case it was the existence of the URLPattern web API: https://pr8734.content.dev.mdn.mozit.cloud/en-US/docs/Web/AP...
Also that Mutual TLS is an alternative term for client authentication.
Re: Deno 1.14
#39Looks good. Interesting that they are "bringing back" mutual tls (after browsers pretty much axed it..).
Is there support on the (deno http) server-side too? Eg: easy to set up mutually trusted, private-/non-ca tls between a deno client and deno server? Perhaps via a self-signed/private CA?
Re: Deno 1.14
#40How it is the zero-copy ArrayBuffer transfer function implemented?
ArrayBuffers are just views on underlying memory owned by the thread a V8 isolate is running on. (Each worker runs on a separate thread, each with its own V8 isolate). When we transfer an ArrayBuffer, we detach the underlying memory from the isolate in the sending thread, and move ownership of the memory area to the receiving thread, where a new JS ArrayBuffer object is created that points to that memory area. TLDR:…
Hats off to you, helping Javascript programmers break out of the matrix ;)