A couple of months ago we covered Deno, a new JavaScript runtime that is attempting to dethrone Node.js as the de facto runtime for executing JavaScript. Ironically, Deno is being developed by Ryan Dahl, the same developer who made Node.js back in 2009.
Here’s that article if you're looking to learn more about our take on Deno:
https://codesphere.com/articles/say-yes-to-deno-23fa587e3877
While Deno has a lot to offer, such as built-in TypeScript support and a simpler dependency system, the biggest hurdle to its adoption is the plethora of dev tools and frameworks that are dependent on Node.js. As Deno gains traction, however, developers have begun creating new frameworks that rely on Deno instead of Node.js.
This is where Aleph.js comes in. The two most popular React frameworks for creating production-ready apps are undeniably Next.js and Gatsby; Both of which are dependent on Node.js, Aleph.js attempts to create an equivalent React framework that is fast for users and convenient for developers. In their own words:
Aleph.js gives you the best developer experience for building modern web applications:
TypeScript in Deno, ES module imports, file-system routing, SSR & SSG, HMR with Fast Refresh, and more. No config needed.
If you’d like to hear about Aleph.js straight from the horse's mouth, you can check out their documentation here:
How Aleph.js make React Deno-friendly
While it is technically possible to create a React application using Deno instead of Node.js, create-react-app by default is going to use NPM. Aleph.js offers that same sort of quick-start as CRA but allows you to have your React application already set up with Deno.
In fact, all it takes is a few command lines to have your Aleph.js app up and running:
deno install --unstable -A -f -n aleph https://deno.land/x/aleph@v0.2.28/cli.ts
aleph init my-app
cd my-app && aleph dev
In this respect, Aleph.js is paving the way for Deno to become beginner-friendly and not just a niche runtime for early adopters.
Aleph.js is essentially just Next.js built on Deno
In order to make React more SEO-friendly, Next.js was released in 2016 as a React framework that enables server-side rendering(SSR) and static-site generation(SSG). Both of these tools allow pages to be rendered relatively quickly for search engine crawlers meaning your page will rank higher.
Aleph.js seems to be open that they are essentially Next.js for Deno. They say themselves:
Aleph.js (or Aleph or א, /ˈɑːlɛf/) is a React Framework for Deno, inspired by Next.js.
Just like Next.js, Aleph provides SSR and SSG out of the box in order to allow developers to create SEO-friendly apps. In addition, Aleph provides some other built-in features that don’t come out of the box in Next.js, such as:
- Hot Reloading (Using React Fast Refresh)
- ESM Import Syntax (No need for webpack)
- TypeScript-Ready
Obviously, the main differentiating factor between Next.js and Aleph.js is Deno. Since Aleph is built on Deno, you have access to all the benefits of the runtime, however, you may not be able to easily use every NPM package that you want. While many packages are compatible (See here how to use them in Aleph), many packages rely on Node-specific functions, meaning they will not work in Aleph.js.
So, What’s Our Verdict?
So, what’s our verdict? Well, Aleph.js seems like a great framework, but you shouldn’t quite bet the farm on it yet. As with any early adoption, there’s going to be a lack of documentation and compatible libraries that is going to make it hard for you to do everything you need to do. Most of these issues we think you’ll encounter however are not because Aleph.js is new, but because Deno is. If Deno succeeds in becoming an industry standard, however, then Aleph.js could be the next big React framework.
In other words, we’re all for giving Aleph.js a try for your next pet project. If you’re deciding on your company's tech stack, however, Deno probably isn’t where it needs to be yet in order to suit all your needs.
Will you be trying Aleph.js out?
Top comments (9)
Deno can be 100 times better it will never take off, imagine python having multiple runtimes or any other interpreted language... someone needs to stop this craziness and concentrate on one official JS runtime best would be if TC39 or who ever is in charge takes this job and in the end we have 1 runtime 1 latest syntax 1 official compiler and 1 language we all speak
Python also has other runtimes / implementations (JPython, IronPython, PyPy). Many other languages have multiple runtimes or implementations. Ruby has Topuz, jRuby, Rubinius, CRuby etc. It's not a big deal at all.
True but I still would argue that one official runtime would help the ecosystem become a bit cleaner.
Thanks for your insights! Definitely can see the pros to having one official runtime as well as for multiple runtimes.
If you have any questions regarding Codesphere, happy to answer them.
I think Deno/Node.js shouldn't be used for the front-end at all, in favor of a lighter / faster engine such as Cloudflare Workers. Ditching Webpack might also be not a good idea, especially if you're building a large app and need to split it into "federations". Code example:
github.com/kriasoft/react-starter-kit
Waiting for Deno version for Nuxt.js come by!
How do you like Nuxt.js as a Vue framework?
It's pretty much just Next.js but Vue, it also got a quite a nice ecosystem.
alephjs.org/