DEV Community

Cover image for React templates - Deno
Michael Currin
Michael Currin

Posted on • Edited on

React templates - Deno

Deno template

Here I use Deno, which is a new alternative to Node.

GitHub logo MichaelCurrin / react-deno-quickstart

Starter template for a React app built on Deno - including docs and CI ⚛️ 🦕 📦

React Deno Quickstart ⚛️ 🦕 📦

Starter template for a React app built on Deno - including docs and CI

Deno CI GitHub tag License

Made with Deno Made with React

Hosted with GH Pages Made with GH Actions

Preview

This template project uses Deno to build a React app and output static assets. No Node.js or NPM used there.

The app gets deployed with CI using GH Actions. Then it is served as a static GitHub Pages site.

This is what the demo site looks like:


View site - GH Pages

Use this template

Sample usage

Start a dev server:

$ make serve
Enter fullscreen mode Exit fullscreen mode

Create a bundled minified JS file of all your app code and depenendencies.

$ make build
Enter fullscreen mode Exit fullscreen mode

The output JS file then can be loaded in the browser using a index.html page. Which means you can host your rendered React application as SPA web app anywhere, such as on GitHub Pages (like this project) or Netlify.

About this template

Overview

  • Provides a basic template project so you can quickly setup your own React +…

No need for Node here.

No need for NPM to manage packages.

No need to install additional packages to handle JSX, TypeScript, linting, formatting or bundling. Deno can do it all. 💪 🚀

Imports

As with the Frontend approach in the previous post, you can do imports by URL in Deno.

import React from "https://dev.jspm.io/react@17.0";
import ReactDOM from "https://dev.jspm.io/react-dom@17.0";
Enter fullscreen mode Exit fullscreen mode

You don't even need an install command - Deno will download the packages when a script is run and then cache them for repeat runs.

How do you avoid duplicating a long URL all over your app and avoid inconsistent versions numbers - like 17.0.1 in one file and 17.0.2 in another? You can centralize your dependencies. The convention in the Deno community is to use a deps.ts module (by the way, import maps are also possible).

e.g. deps.ts

export { default as React } from "https://dev.jspm.io/react@17.0.1";
export { default as ReactDOM } from "https://dev.jspm.io/react-dom@17.0.1";
Enter fullscreen mode Exit fullscreen mode

Now that you have say React loaded by URL and exported, you can import it in another script with a short local module path.

e.g. index.tsx

import { React, ReactDOM } from "../deps.ts";
Enter fullscreen mode Exit fullscreen mode

Start dev server

Assuming you have make installed, you can run commands defined in the project's Makefile. This is my preferred way of replacing the scripts section of package.json, but also works great for Go, Python, Rust, etc.

Run this command:

$ make server
Enter fullscreen mode Exit fullscreen mode

This task will do two things:

  • Prepare the assets and create a bundled JS file with Deno, updating it continuously on any changes.
  • Start a dev server with Deno, serving the build output directory.

That uses the Deno CLI internally, to run two commands like this in parallel.

$ deno bundle --watch src/index.jsx build/bundle.js
$ deno run --allow-net --allow-read static.ts
Enter fullscreen mode Exit fullscreen mode

Deno requires you to be explicit with permissions like read, write and network access. So using make CLI and a Makefile is a great way to abstract away the verbose commands.

CI

As with the Node template in this post series, GitHub Actions is used to build and deploy static content to be served with GitHub Pages. Instead of NPM, the Deno CLI is used - through the make commands.

Who should use this template?

I'd recommend looking at my Deno template if you already know Node but feel that package management, bundling, and other dev tooling are causing you anxiety and needs to be simplified.

Also, the Frontend template and this Deno template have similarities in managing packages by URL in scripts, so it is useful to have a look at those two projects side by side.

Tell me more about Deno!

Deno is still in its early days (only in version 1) and it is controversial (some call it the "Node killer" and others think not so much).

So I'm not going to go into the details of Deno here.

Yes, it does add convenience, but, it also has its learning curve and its own way of doing things, and it is unstable (some CLI commands require use of --unstable so that they work).

Though, the Deno homepage and the blog posts out there do a good job explaining its purpose and some pros and cons. But make sure you balance a variety of opinions before making a judgment. And keep your opinion open to change based on more info and your own experience.

Top comments (0)