DEV Community: Max Niederman

On the Width of Webpages

Max Niederman — Thu, 14 Jul 2022 04:56:23 +0000

Websites should never be wider than their viewports. I think that most people understand this, but it’s incredible how often I come across sites which get this wrong. It seems that every other site I read on my phone looks like this:

An actual phone, of course, cannot simply render the content outside of the screen. Instead, browsers handle overflowing by allowing users to move the viewport by scrolling.

This is a good default for horizontal overflow, but it's usually bad for vertical overflow. When mobile users scroll vertically, it is easy to accidentally scroll horizontally as well, which can be extremely distracting from the content.

Most web developers test their sites primarily on desktop browsers, where the viewport is much wider, so it's easy not to notice the issue. Even when developers test using desktop browsers' mobile emulation tools, they typically use a mouse or touchpad, so they are less likely to accidentally scroll horizontally.

Web developers should adopt the following priniples:

Whenever possible, the design should respond to the viewport's width rather than rely on users to scroll.
Failing that, large elements should scroll individually, using overflow-x: scroll, rather than force the entire body to widen.
Websites should be tested in an environment as close as possible to the one in which they will be used.

ttyper - a Terminal-Based Typing Test

Max Niederman — Mon, 15 Mar 2021 20:32:48 +0000

Originally published here on my blog.

TL;DR: here's the project on GitHub and it's installable as ttyper from Crates.io.

Motivation

I was already pretty happy with the typing test I used to use, monkeytype; however, I'm a big fan of CLI tools, so I wanted to be able to practice my typing without reaching for a browser or even a native application. I searched around for terminal-based typing tests, but none of them were quite what I had in mind.

Since there weren't any pre-existing tools which meant my needs, I thought it would be a good opportunity to learning about TUIs (terminal user interfaces) to make one myself. I decided to use Rust with tui-rs, after being inspired by tools built with it such as gitui, bandwhich, and diskonaut.

A Minimal Typing Test

I decided to go with a fairly simple, tried-and-true design: a list of words and an input box where you type each word one-by-one. I wanted an experience similar to typings.gg or 10fastfingers, but with the ability to return to a previous word after submission.

Here's what the final interface for the test input looks like:

Finding WPM and Accuracy

Calculating the results of the test was far harder than I had originally expected, althouhg this may be due in part to the fact that I wanted more insights into my typing performance, such as keywise accuracy and WPM data, as well as a WPM graph.

First of all, I represented the test, more or less, as such:

struct Event {
    time: std::time::Instant,
    key: termion::Event::Key,
    correct: Option<bool>,
}

struct Word {
    text: String,
    events: Vec<Event>,
}

struct Test {
    words: Vec<Word>,
}

You can read the real code here.

In this way, each "event" (keypress) can have a correctness value. Then, to find the accuracy, we can divide the number of correct events by the total number of events with correctness.

We can also find the WPM per each event from its time and its predecessor's time.

There's still a lot of things I want to change with ttyper's results calculations and UI, like adding a WPM over time graph and fixing weirdness with the overall WPM calculations, but it's working well enough for someone like me, who doesn't care too much about the exact WPM as long as I'm improving.

Test Contents

For the test contents, I added an optional argument to specify a file to read, which is then split at whitespace and carriage returns. Then, I added functionality for automatically generating test content. It works by reading a language file and populating a list with a certain number of random lines from that file. Currently, english100, english200, and english1000 are installed automatically. In the future, I'd like to add weighted language files based on n-gram analysis to make the test contents more realistic.

Try It Out

If you want to try ttyper our for yourself, you can install it with Cargo:

cargo install ttyper

Netlify vs. Vercel: A Comparison

Max Niederman — Sun, 04 Oct 2020 17:03:53 +0000

Netlify and Vercel are serverless deployment platforms for web applications, both designed to allow you to deploy as quickly and easily as possible. Both have very similar feature sets, so which one should you use? In this article, I'll be answering that question.

Build + Edge = 💕

The core feature set of both Netlify and Vercel is the build + Edge stack. Essentially, you trigger a build step either by using Git or uploading manually. Once built, your app is automatically deployed to Netlify or Vercel's Edge Network to ensure a fast UX. This makes it incredibly easy to steup a static site (e.g. a blog like this one), since all you have to do is push your code. They're fairly equal in this matter, so I wouldn't consider either to be better.

Serverless Functions

Static sites are all well and good, but most applications need a backend to function. For this purpose, both Netlify and Vercel offer serverless functions via AWS Lambda.

Netlify

For Netlify, you create a functions directory in your project folder. You can then add AWS Lambda handlers in JavaScript or Go. Routing is handled based on the directory structure. You can read more at the official documentation here.

Vercel

Vercel has a very similar interface, using an api directory in your project, but it pulls out ahead in the features department with its support for Python and Ruby as well as JavaScript and Go, and it also supports a custom Express.js-like (req, res) => {...} format for JavaScript functions, as well as optional Edge caching for responses.

Server Side Rendering

Server-Side rendering, or SSR, is a huge win for Vercel, as it's just not really feasible with Netlify. On Vercel, you can deploy a server-side rendered Next.js application within minutes.

Authentication

Netlify has a built-in authentication platform based on the GoTrue API which you can easily setup. With Vercel, you'll have to setup authentication some other way.

Backend for Static Sites

Netlify provides three features which make it trivially easy to add common functionality to your site:

Netlify Forms: Manage forms and submissions without setting up any backend
Netlify Analytics (Paid): Server-side analytics you can setup with no client-side code whatsoever
Split Testing: Netlify allows you to easily A/B test two deployments

Pricing

Both Netlify and Vercel have generous free plans. You can see the full pricing info here, here, and here, but here's a quick comparison:

Build

Vercel is ahead here, with a soft limit of 100 build hours / month for free and 400 with the Pro plan ($20/month per member) compared to Netlify's 300 build minutes / month free and then $7/500 minutes. Most projects won't need anywhere near this much time anyway, so it probably won't matter for you.

Edge

Both Netlify and Vercel give you 100GB of bandwidth free (although that's a soft limit for Vercel). Netlify sells additional bandwidth at $20/100 and Vercel gives you 1 TB with the Pro plan (also a soft limit).

Serverless Functions

Netlify bills based on the number of invocations, whereas Vercel bills based on GB-hours since you can customize your serveless function instances. Netlify gives you 125k invocations free, and then charges "$25+ when exceeded" (your guess is as good as mine). Vercel gives you 100GB-hours free, and 1000GB-hours with the Pro plan.

Netlify Forms, Identity, and Analytics

Forms get 100 free submissions, then cost "$19+ when exceeded." Identity gives you 1000 free monthly active users, then charges $99 when exceeded. Analytics costs a flat rate of $9/month.

Conclusion

We can see a clear divergence of interests between Netlify and Vercel, two extremely similar products at first glance. Netlify is focused on making it easy to create client-side, static applications, and delivers on that goal wonderfully. Vercel, on the other hand, focuses on making back-end work simple. If you're creating a static site, Netlify is the clear choice, but if you need more server-side functionality and you don't mind spending a little time, Vercel is the way to go.

Why you should try using Deno

Max Niederman — Sun, 27 Sep 2020 18:18:18 +0000

Originally published here on my blog.

From Deno's website:

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

Secure by default. No file, network, or environment access, unless explicitly enabled.

Supports TypeScript out of the box.

Ships only a single executable file.

Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).

Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std

Deno aims to replace Node.js as a JS runtime for servers. It's even led by the original creator of Node.js, Ryan Dahl, and it's created with the goal of fixing the biggest problems with Node.js.

The Main Advantage of Deno

Have you ever started working on a Node project and ended up spending upwards of 15 minutes just to setup all of your additional tooling like comilers (TypeScript, Babel, CoffeeScript, etc.), testing frameworks (Jest, Cypress, Mocha, Chai, etc.), linters and formatters, and more. I know I sure have, and it really sucks. I want to get coding as quickly as possible, and Deno is vastly superior to Node in this matter. Deno has the following features built in, no configuration necessary:

Built-in TypeScript Support

Deno will run your TypeScript code without ever having to touch a tsconfig.json file. This way you can focus on your code, rather than transforming it to JS. You can also use your existing JavaScript code as well.

Built-in Testing

Deno has a built-in test runner that you can use for testing JavaScript or TypeScript code. You can write tests inline in your files like this:

Deno.test("1 plus 2 equals 3", () => {
  const x = 1 + 2;
  assertEquals(x, 3);
});

And run all tests using the deno executable:

deno test

You can read more about Deno's tests here.

Built-in Linter and Formatter

Deno has both a linter and formatter built-in, available through the deno binary. You can read the linter docs here and the formatter docs here. No need to setup your own unless you want to.

Built-in Bundler

Deno has a built-in bundler to package your code, so you don't need to setup your own bundler either.

Deno also has some other advantages over writing in Node:

Secure by Default

Access to the filesystem, network, environment, and the ability to run subprocesses all must be explicitly enabled with CLI options. You can even allow access to only certain hosts or files.

Browser compatibility

Node.js lacks a lot of browser APIs. For instance, if you wanted to fetch a resource over HTTP, you could just use the fetch api. In Node, you would have to import a whole library just to do this. This is not the case for Deno. Deno includes the majority of browser APIs. In fact, Deno code is designed to be as compatible as possible with the browser. Anything specific to Deno is under the Deno namespace, so if you remove that from your code, it should run in any modern browser. It can also run WebAssembly binaries.

These are some of the reasons that I personally use Deno rather than Node whenver I can.

Web analytics from scratch - Part 2: The Client

Max Niederman — Sun, 20 Sep 2020 19:10:36 +0000

Originally published here on my blog.

This is Part 2 of this series. You can read the first part here

Tracker Client

Now that we have a server which can keep track of our analytics data, we need to add a client which will tell the server the page has been loaded.
This is extremely simple since we only have to send a single request with two JSON properties when the page loads:

var analytics = async (apiBase) => {
  await fetch(`${apiBase}/tracker`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ url: location.href }),
  });
};

Then we can just load and call it like this:

<script src="analytics.js"></script>
<script>
  analytics("http://yourserver.com");
</script>

And that's really all it takes to implement our super-simple analytics on the client side. This has the added benefit that the bundle size of the client is negligible (<250B unminified).

Getting Analytics Data

We have a way to collect and store analytics data, but now we need a way to get it.

We can already look at the data using redis-cli like this:

> HGETALL <YOUR_HOST>:resources
1) "/"
2) "42"
3) "/index.html"
4) "7"

However, this isn't a great solution for quickly looking at analytics data. We want some way to present this data to the user nicely. We can do this by adding an endpoint to our API to get this data:

fastify.get("/data", async (req, reply) => {
  const resources = await fastify.redis.hgetall(`${req.query?.host}:resource`);
  return { resources };
});

Now if we call this by making an HTTP request with a host query parameter and get back some JSON like this:

{
  "/": "42",
  "/index.html": "7"
}

Now you might notice that the numbers are, in fact, strings. This is because Redis stores everything as a string, so we'll need to cast it to a number:

// Helper function to cast Object values
const castValues = <T>(
  object: Record<string, unknown>,
  castFn: (value: unknown) => T
): Record<string, T> =>
  Object.fromEntries(
    Object.entries(object).map(([key, val]) => [key, castFn(val)])
  );

fastify.get("/data", async (req, reply) => {
  const resources = await fastify.redis.hgetall(`${req.query?.host}:resource`);

  // Cast values to numbers
  return { resources: castValues(resources, Number) };
});

Now it'll reply this:

{
  "/": 42,
  "/index.html": 7
}

In the next part of this series, we'll add more statistics and work on a visual dashboard.

Web analytics from scratch - Part 1: Page Views

Max Niederman — Sun, 13 Sep 2020 20:18:05 +0000

Originally published here on my blog.

Google Analytics is used in nearly 70% of websites for a good reason. It's a very powerful tool, and more importantly, it's free and easy to use, but there's a downside: Google owns and uses all of your data. "Just use Matamo or Open Web Analytics!" I hear you say, and you're right, that's the easiest solution, but I think we can all agree it's no fun.

In this series we'll be creating a simple website analytics service from scratch. This part will be about creating a basic API to keep track of raw page views, but more statistics will obviously be added later.

Setting up a Web Server

First we'll need to setup a basic web server. I'll be using Fastify, but it shouldn't be too difficult to use Express or another framework.

import fastify from "fastify";

const app = fastify({ logger: true });

// Routes
app.get("/", async (req, reply) => {
  hello: "world";
});

const port = Number(process.env.PORT) || 3000;
app
  .listen(port, "0.0.0.0")
  .then(() => console.log(`Listening on port ${port}`));

Now that we have a web server, we can add a route the client will use when it loads the page:

import { FastifyPluginCallback } from "fastify";

const plugin: FastifyPluginCallback = async (fastify, opts, done) => {
  fastify.post("/tracker", async (req, reply) => {
    if (typeof req.body !== "object") return;

    // Record client data

    return { success: true, message: "Recorded analytics data" };
  });

  done();
};

export default plugin;

And then register it in app.ts:

import fastify from "fastify";
import routes from "./routes";

const app = fastify({ logger: true });
app.register(routes);

const port = Number(process.env.PORT) || 3000;
app
  .listen(port, "0.0.0.0")
  .then(() => console.log(`Listening on port ${port}`));

Storing data

Now that the client can send us information, we'll need a way to store it. Since we won't be storing personal data as per the GDPR and CCPA, we'll essentially just be storing a bunch of counters. I decided Redis would be perfect for this.

With Fastify, we can share a single Redis client using the fastify-redis plugin:

import fastifyRedis from "fastify-redis";

app.register(fastifyRedis, {
  host: process.env.REDIS_HOST || "127.0.0.1",
  port: Number(process.env.REDIS_PORT) || 6379,
});

Then we can keep track of views like this:

fastify.post("/tracker", async (req, reply) => {
  if (typeof req.body !== "object") return;

  await fastify.redis.incr("views");

  return { success: true, message: "Recorded analytics data" };
});

If we then call this endpoint a few times we can see the count in our redis console like this:

> GET views
"3"

Pageviews

We'll obviously want to store more data, like views per-page. First, we can add a resource property to the tracker endpoint:

fastify.post("/tracker", async (req, reply) => {
  if (typeof req.body !== "object") return;
  const url = new URL(req.body.url);

  await redis.hincrby(`${url.hostname}:resources`, url.pathname, 1);

  return { success: true, message: "Recorded analytics data" };
});

Stay tuned for the next part of this series, in which we'll be creating a client that can log this information, and endpoints to get analytics data once it's recorded.

How anyone can make and deploy a modern website for free

Max Niederman — Sun, 06 Sep 2020 18:34:31 +0000

Originally published on maxniederman.com

Making a website today is easier than ever. With tools like Squarespace and Wix you can easily create an appealing (if boring) website using no code at all.

This is a great solution for most; however, it comes with some disadvantages:

Cost: Most site builders will cost you at least $10 per month.
Lack of Customization: Services like Squarespace provide numerous themes. These are good, but Site Builders usually lack granular control over your site.
Dynamic Content & Functionality: Site Builders like these won't allow you to add custom functionality to your site or give you the ability to serve dynamic content.

For the slightly more tech-savvy, there's a better solution anyone can do for free: using website templates you can host for free using services like GitHub Pages or Netlify.

I'll be demonstrating how you can quickly and easily setup and host a website using Gatsby, a static site generator which pre-renders React components, along with Netlify for hosting. It's popular for simple static websites and has an extensive template library which we'll be taking advantage of. There are many other alternatives you could use, like Jekyll.

First, we'll need to install the Gatsby CLI:

npm install -g gatsby

Using a Gatsby starter

Now, we'll need to find a Gatsby template from the Starter Library. I'll be using Leko Arts' Cara Theme. Each starter will have different instructions for modifying their content, so you should follow the instructions for your starter. I'll show the process for the Cara theme.

Then, download your starter:

gatsby new my-awesome-website https://github.com/LekoArts/gatsby-starter-portfolio-cara

The next part will be different depending on your template, but generally you'll need to modify some files with your content. Most starters will have instructions to modify the content. Run:

gatsby develop

to see your changes whenever you save. You don't even have to reload!

Modifying the starter

Templates are great, but sometimes you need to tweak the template to fit your needs. Thankfully, Gatsby makes this super easy with Shadowing! Shadowing allows you to overwrite files from your theme. You can read the full guide here but essentially you create a directory inside src/ with the name of your theme. For my template, it would be src/@lekoarts/gatsby-theme-cara/. Any file you put there will shadow (overwrite) the theme's source code.

Deploying

Once you're happy with your site you'll need to host it. Thankfully, Netlify has made this process a breeze.

First, upload your site to GitHub or GitLab. This isn't a requirement but it'll make deployment much simpler. Then, you'll need to create a free Netlify account here. On your Netlify dashboard, you'll see a button to create a new site from Git. Click that and select the repository you uploaded.

Click "Deploy site" and you're done!

Going Further

You can create your own Gatsby site from scratch, by adding React components in the src/pages/ directory. If you want to serve dynamic content without rebuilding, you'll need to use a different React site generator like Next.js or if you don't care about server-side rendering, Create React App.