There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.
Yes and no. For example, maybe you want to initialise a temporary directory on the filesystem for writing files to, for some caching mechanism. The pointer to the cache directory (maybe a const x = {}) can exist anywhere, but spinning up the directory itself in the static class block ensures that it's set up once and only once for all instances of the class. So, any instances get to reuse the directory without worrying about checking for initialisation first.
Just another tool in the toolbox, best evaluated on a case-by-case basis
There's a better example here: https://v8.dev/features/class-static-initializer-blocks
You could also use it for initialising generated constants.
class MyClass {}
export const myClassSingleton = new MyClass()
Static blocks only run once, like the class declaration itself:
class User {
constructor(public name: string, public age: number) {}
static {
console.log("Hello from class User static block")
}
}
const a = new User("a", 1)
const b = new User("b", 2)
class User {
constructor(name, age) {
this.name = name;
this.age = age;
}
}
(() => {
console.log("Hello from class User static block");
})();
const a = new User("a", 1);
const b = new User("b", 2);I guess it's a good way to bring back that behavior with the added bonus of being useful by itself in some limited but legitimate cases (sibiling comment mentioned cache initialization, also a good point).
module.exports =
class MyClass
{ // ...
static init ()
{ // ... do something, like create and
// cache a Singleton etc.
return this;
}
} . init();
Do static blocks allow me to do something more?
It seems like a minor convenience, but it might play well with inheritance or mixin classes?
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!
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.
57mb is big, but not an issue when it's for personal use.
Somewhat related, I haven't used rust, but I read that it can produce an executable including the run time for edge that is less than 1mb,. I couldn't find the source, but this article shares how an extension was reduced from 12mb to 4.5mb.
And to top it off there's yet another bonus to this approach: having Fetch included out of the box enabled me to mock out what eventually became my frontend requests, by running them headlessly and worrying about the form logic later.
I haven't actually gotten to using TypeScript with it personally (it's among a few things built into Deno that I've been meaning to try now that I can run them with zero config), but when writing JS I've found myself reaching for it in some of the same scenarios I (anecdotally) see people point to for Python -- bulk file manipulation, scraping, programmatic requests, etc.
The types feel soooooo good.
I'd love to be able to develop backend services by pushing source code to some url as I develop, and then have the production instances of the service notified of the changes and reload themselves immediately for a super-tight feedback loop.
In theory, building this kind of workflow in Deno should be very feasible, so I'm hoping to give it a shot in the not too distant future, but I'm wondering if anyone else has already tried it?
https://en.wikipedia.org/wiki/Capistrano_(software)
https://gist.github.com/rchampourlier/1281506/a22148264c457ebb69259261f117548569be6bef
https://pm2.keymetrics.io/docs/usage/deployment/
It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.
For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.
IMO the possibility for an air-tight feedback loop is _the_ killer feature for interpreted languages vs compiled ones. I can always feel my productivity plummet whenever I work in an environment that takes that away from me. I wish more people would try to take advantage of it.
Arguably a delineation like this is better, even if just a single flag separating the behavior in the server, since it allows production to not worry about some file copies/changes forcing lots of reloads that aren't needed, which isn't really a problem in most development environments.
Heck lets get this headless browser running in Ring 0 and skip to the end of Gary Bernhardt's dream.
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
I'm pretty happy with Node.js. What would be some good reasons to switch?
> NodeJS compatibility, what is our high-level strategy, goals, next steps?
> Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation)
> If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer
I really wish they go for a better compatibility with Node and sell themselves as a replacement that is strictly better.
When you load a library you can load a newer version or an older one. It's up to you. You can use both.
1. Same. 2. Better.
You can't have both. Since getting better involves change, which is the opposite of staying the same.
If you’re a hobbyist or an academic or starting a totally new project that won’t have dependencies/doesn’t need a large community of modules, then I recommend deno. Otherwise I highly recommend sticking to node until deno comes out with something to make the switch more appealing.
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
Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
Precisely this. I'm compiling TS using `Deno.emit()`, which can be directly configured, but it would be nice to just configure Deno's linting/compiling behavior at the project level so that the same issues don't appear in VS Code with the Deno extension.
Edit: + Electron + the JS runtime used for Windows ecosystem based on Chakra (not sure if that's still alive though?) + a few other similar ones in that vein for desktop or mobile OS'.
+ whatever is available for embedded & similar devices, (I guess there will be a few but I know little about that area).
+ various [highly] specialised business/academic/hobby/PoC/etc runtimes, but they're not realistically things that many people care about.
My current top feature request is that I wish Deno would have the same permission model for the repl.
I highly recommend listening to this recent podcast with Ryan Dahl: https://changelog.com/podcast/443
REPL is particularly useful when trying out things "live" as they come into your mind.
TLDR: The memory is never moved, the pointers to it are just detached from one isolate, and instead passed to another.
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.
Mutual TLS is where both the server and the client must present certificates and both must verify the others' certificate in order for them to communicate. It's useful for backend server to server communications mainly.
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?
You get a fairly sane type system, good performance, easy deployment (it doesn't count as easy if it's a pain on Windows), supports single file scripts with third party dependencies, and no compilation to deal with.
There aren't really any alternatives that offer all that as far as I know.
That's good news. The main thing holding me back from seriously looking at Deno was the lack of config for the formatting. The default settings weren't right for me, and I tend to avoid projects where you have to fight the tools. I'm going to take another look now.