I’m not a web dev, typically speaking, I’m not a fan of most web stacks. That said, when it comes to CMSs my options are limited. Ghost looks pretty solid, but if I can be that much more secure with Deno, that would be preferable.
Some pertinent posts I found…
To add some context, deno was released 3 days ago, and as a general rule of thumb, there are some hurdles it has before it will be adopted for production.
I’m not a core developer of Ghost, but I am pretty confident in saying they deno won’t be supported for a while. Here’s why (note - some of these points are also discussed in the article @denvergeeks linked to):
Ghost supports active LTS versions of node, so it will be a few years before they can use ES modules in the core product. Since deno doesn’t support common.js require statements, you have to at least wait until that happens.
Ghost is composed of quite a few components. Some of the components are lazy-loaded for performance. Since lazy-imports in es-modules are async, this would require some architectural changes to Ghost (though Deno seems to have a workaround for this)
Ghost uses many open-source libraries. These libraries will need to be updated (e.g. single file export rather than multi-file requires) to support deno
My understanding is Deno’s permission boundaries are limited to the application-level rather than the module level. Ghost will need access to most if not all of the permissions that deno restricts, so you won’t be gaining security from that perspective. Ghost already uses a lockfile for module resolution, meaning people that install ghost will be using the same dependencies as the people that develop ghost.
So to summarize: we will have to wait, it’s going to require a decent amount of work, and from a security perspective, it won’t provide much (if any) benefit.
Wow. Scholarly. Thanks for this cogent analysis, @vikaspotluri123!
Thank you very much, looking forward to when Ghost gets to the point!