Forem: Brian Barbour

Believe In The Web

Brian Barbour — Tue, 26 Sep 2023 20:01:40 +0000

I grew up marveling at the web. From the first moments of exploring websites with AOL and dial-up, to building my own websites and forums in the early 2000s.

Those experiences drove me to learn how to code and fuel my love for JavaScript. It has fueled my career and growth.

Nothing matches the thrill of seeing my code come to life on the browser, and the satisfaction of sharing it with others with relative ease.

The web has always been more than just a collection of pages and links. It has been a platform for creativity, innovation, and collaboration. It empowers anyone to express themselves, learn new skills, and connect with others. A platform that is open, accessible, and democratic.

The Way of the World Wide Web

The web was created with a vision of being a universal information space. The designed was for flexiblity, adaptablity, and above all else: resilience. Upon that we built standards that ensure interoperability, compatibility, and security. All with the principles that promote decentralization, neutrality, and transparency.

As our friend Din Djarin says: "This is The Way."

The web has evolved over time, but it has never lost The Way. It has enabled countless innovations, from e-commerce to social media, from online education to telemedicine, from gaming to art. The web has transformed every aspect of our lives, from how we communicate to how we work, from how we learn to how we play.

Seek Minimalism

As the web has grown in complexity and diversity, so has the challenge of developing for it. Web developers deal with multiple browsers, devices, frameworks, libraries, and tools. We must balance performance, usability, accessibility, and security.

In this context, minimalism can be a powerful approach. It's not just making things simple or plain, but about making them essential and elegant. It's about focusing on what matters most, and eliminating what doesn’t. Through pursuing minimalism, we tend to find the optimal solution for the problem at hand.

One way to apply minimalism to web development is to use server-rendered web apps.

Please don't recoil... Hear me out.

Server-rendered web apps generate HTML on the server-side and send it to the browser as a response. This gives them several advantages over client-rendered web apps. They are by far faster to load and render. They don’t require downloading or executing large JS bundles. And typically, they do not suffer from latency or network issues.

We don't have to build an API and a front end separately. Fullstack engineers rejoice.

This makes them easier to maintain and debug. There's no depenency on complex state management or data synchronization. There's almost zero compatibility issues with different browsers or devices.

Maybe not as important, but still a benefit: server-rendered web pages are more accessible and SEO-friendly. They don’t rely on JS for functionality or content. They won't run into problems with indexing or crawling by search engines or bots.

Sprinkle JS

The harder step for most is using as little JS on the front-end as possible. JS pays my bills, but I often warn against its sorcery. Despite its strength, it also can also become a source of problems.

Too much JS can affect performance and user experience negatively. It increases loading time and memory consumption. Sometimes it brings about seemingly random jankiness or unresponsiveness. There's also how it can pose security and privacy risks . There can be malicious code hidden isnide libraries that can access sensitive data. Nefarious folks can also use it to track or manipulate user activity or information.

Then there's the random side effects. Don't mention those.

Now a days I advise using JS sparingly and responsibly on the front-end. This follows the principal of Progressive Enhancement, which moves the web forward without leaving anyone behind. This means providing a basic functionality and content for all users using HTML and CSS only, and then adding JS as an optional layer for enhancing the user experience.

The Dream Is Obtainable

There are libraries like HTMX and templating engines that let us dynamically build webpages and serve little JS. HTMX allows us to access AJAX, CSS Transitions, WebSockets and Server Sent Events using HTML attributes.

Combining HTMX and server rendered pages, we can create web apps that feel like single-page applications without the overhead of a front-end framework. We write HTML templates on the server-side, and use HTMX to add interactivity and dynamism on the browser-side. Also, we can use HTMX to make partial updates to the DOM without reloading the page, to add transitions and animations, and to communicate with the server using Server-Sent Events and Web Sockets.

Here's how we use HTMX to load a new page when a user clicks on a link, without reloading the page:

<a href="/about" hx-get="/about" hx-swap="outerHTML">About</a>

Here's how we submit a form and update a section of the page with the response, without reloading the page:

<form hx-post="/submit" hx-swap="innerHTML" hx-target="#result">
  <input type="text" name="name" placeholder="Enter your name">
  <button type="submit">Submit</button>
</form>
<div id="result"></div>

Here's how we use HTMX to add a fade-in effect when a new element is added to the page:

<div hx-trigger="load" hx-swap="afterbegin" hx-get="/new-element" hx-swap-oob="true" class="fade-in"></div>

I recommend Pug/Jade for a templating engines because it falls in line with minimalism. I use it to write HTML templates in a more concise and readable way:

doctype html
html(lang="en")
  head
    title My Web App
    script(src="/htmx.min.js")
  body
    h1 My Web App
    p Welcome to my web app!
    a(href="/about" hx-get="/about" hx-swap="outerHTML") About
    form(hx-post="/submit" hx-swap="innerHTML" hx-target="#result")
      input(type="text" name="name" placeholder="Enter your name")
      button(type="submit") Submit
    div#result
    div(hx-trigger="load" hx-swap="afterbegin" hx-get="/new-element" hx-swap-oob="true" class="fade-in")

My point is simple. With just a few simple tools we can create web apps that are fast, elegant, and error-free. We can leverage the power of the web as a platform, without sacrificing performance, usability, or accessibility.

It's Up To Us

The web is an amazing platform that offers endless possibilities for web developers. However, it also poses many challenges and complexities that require careful consideration and planning. By adopting a minimalist approach to web development, web developers create web apps that are fast, simple, and elegant. All the while following best practices and the standards of the web community.

When to Branch Your Code (Git)

Brian Barbour — Mon, 31 Jul 2023 12:00:00 +0000

Version control systems like Git are fundamental tools. They provide a way to track changes to our code, collaborate with others, and, importantly, experiment without fear. Branches have a special role to play. The best way to understand the importance and correct timing of creating a new Git branch is to picture it as a science experiment.

Branches - The Science Experiments in Code

In a lab, scientists run experiments to test hypotheses, trial new approaches, and probe the unknown. They carry out these investigations in a controlled environment where, if things go awry, the whole lab isn't blown to smithereens. Instead, they can adjust their hypothesis, tweak the method, or simply discard the experiment and begin anew.

Git branches provide a safe environment for your codebase. They allow you to work on new features, bug fixes, or entirely experimental code, separate from your stable, primary codebase. Like a lab experiment, a new Git branch is something you can create without fear and abandon if it doesn't pan out as planned.

Merging - Strengthening the Codebase Tree

Just like successful experiments that contribute to scientific knowledge, well-executed Git branches eventually get merged back into the main project. This merging signifies that your 'experiment' was successful, be it a new feature implementation or an innovative solution to a bug. This successful experiment then becomes a part of your codebase, strengthening and enriching it; akin to adding a new, robust branch to a tree.

When Should You Branch?

The golden rule is: branch when you're about to begin work that could potentially disrupt your main codebase, even if the risk is minimal. It's like putting on safety goggles before an experiment. You might not always need them, but you'll be glad you have them when things unexpectedly splatter.

Here are a few common instances when you should create a new branch:

When you're adding a new feature: This new feature is your hypothesis. Test it, refine it, and when it's ready, merge it back in.
When you're fixing a bug: Consider this as a corrective experiment. Make sure the fix works perfectly before integrating it back into your main code.
When you're experimenting: Maybe you're trying out a new programming approach, or perhaps you're testing how a new technology fits into your project. Branch out, and don't be afraid to discard the results if they don't meet your expectations.

Remember, branching is your safety net in the world of code. Make it a habit to branch often, merge successful 'experiments,' and fearlessly winnow those that didn't work out. It's all part of the process of nurturing and growing the tree that is your codebase. So branch wisely and branch often!

I Self-Published a Sci-Fi Novel on Kindle

Brian Barbour — Mon, 06 Feb 2023 02:55:53 +0000

As fall 2022 rolled around, I sat down and started writing a science fiction novel. During November, National Novel Writing Month began and I challenged myself to make it as far as I could. I put in the extra hours and broke 50,000 words before the month ended. That momentum carried me, and I finally finished the first draft, ending at roughly 93,000 words, just before Christmas.

I learned so much during this experience. So, I figured why not share and explain the various tools I used to go from a rough draft manuscript to a full Kindle eBook.

The first tip I can give, and the biggest one that helped me finish my first draft, was writing an outline. I know some people like to write by the seat of their pants, but in the past, it only led to my stories falling apart. To make it to the end, I needed a guide. Starting with a bunch of world-building, I jotted down as many ideas and character concepts as possible, filling a Word document with notes. Lacing together a plot, I broke the story beats down into each chapter. Each chapter was further broken down into various component scenes. This granular organization kept me on track, consistent, and focused on the fun part: storytelling.

Editing is the most challenging and vital part of writing a novel. This was a hobby project, so I didn't hire an editor. I read extensively about self-editing; there are hundreds of articles, books, and videos on the web.

Through my studies, I picked up some nice tricks along the way. One big thing is to give the story a rest. Most conventional advice says to give your first draft a whole month's rest. I gave it a couple weeks while I worked on the outline of my next novel.

Distance from your first draft will help you catch things you didn't see before. When I was finally ready, I returned to my prose with a sharp axe. Chopping away 10,000 words made the story flow cleaner, honed my voice, and kept the language succinct. Feel free to remove things that distract from your story, even if you love them. "Kill your darlings," Stephen King once said in his book On Writing.

Grammarly is a popular writing assistant software. I ended up getting a subscription, and I'll admit, I wasn't disappointed at all. Grammarly caught so many more typos and mistakes than the built into Word editing tools. No algorithm will ever replace a real editor. Many times I disagreed with its suggestions and skipped them. But it did help me clarify many sentences and avoid using a passive voice.

There are bound to be minor typos and spelling mistakes in my published draft, but I am confident they are at a minimum, thanks to Grammarly.

Once I was satisfied with my draft, I experimented with making a cover for my book myself. It's something you could commission, but it was a fun challenge for me. I am confident in the design experience I received from working in web development, so I looked around at some similar books in the sci-fi genre and got inspiration. I bought the rights to a piece of art I liked and used the site Pixlr, a streamlined photo editor in the browser, to modify the image. It took less than an hour and turned out great.

To get my book on the Amazon Kindle store, I created an account on Kindle Direct Publishing. It's free and easy to get started. You can add your book easily to your Bookshelf. The entire process, along with tips, is well-documented in the site's help section. The UI and flows have an AWS feel, so I felt right at home.

Amazon gives you a few options when uploading your story. They accept .docx files if you don't want to mess around with .epub or .mobi formats. I wanted a more professional feel to my book, so I opted to make a .epub.

I found Reedsy, a handy web app. It allows you to upload your manuscript and generate a .ePub. The other huge benefit is the template system, allowing an author to add frontmatter, a table of contents, and backmatter. The entire UX on Reedsy is top-notch and intuitive. It took me a half hour in total.

To make sure my .epub looked good on different devices, I used a free software by Amazon called Kindle Previewer. It reminds me of an Android or iOS simulator. I've used those extensively during dev work to build and test React Native apps. With Previewer, you upload your .epub and can immediately preview it on the Kindle mobile app, tablets, and e-readers.

The general self-publishing process wasn't nearly as complicated as I thought. Have any of you published your own book on the Kindle store, and what was your experience like?

For those interested, my novel is called Phasematter. It's an action-packed sci-fi adventure.

Here's the description:

Fahon Drakk dreamed of joining the Argent Knights since childhood and claiming his family's Caster to become a Bonded. Upon doing so, he will wield the superpowers of Phasematter and become one of the most powerful warriors on the moon. A new era of peace secured by Fahon's grandfather and nurtured by his father has become threatened by a detractor who thinks conquest is the only way forward for humankind. Fahon is at a disadvantage with a childhood spent training to become a scholar. Now he must quickly learn to master his nascent abilities before entering the Knight's Tourney and getting swept into a murderous plot to overthrow his family.

Phasematter in the Amazon Store

Please check out the book if you're interested in reading it or supporting me. It's free to add to your library if you have Kindle Unlimited. Drop a review if you read it and like it (or even if you don't like it). I'm always looking for feedback to make me a better writer.

Creating a MERN stack app that uses Firebase Authentication - Part Two

Brian Barbour — Tue, 25 Jan 2022 14:09:05 +0000

My favorite stack to use is the MERN stack. For those of you who aren’t sure what the acronym stands for its MongoDB, Express, React, and Node. These are frameworks and libraries that offers a powerful way to bootstrap a new application. Paired with Firebase it’s relatively simple to deliver a safe authentication system that you can use both on the back end and the front end of your application.

This article series will cover the following things:

Creating an Express server with a MongoDB database connected and using Firebase Admin SDK. Check out Part One.
Setting up a client side React App that uses Firebase for authentication.
If you just want take a look at the code and can divine more from that, check out the public repo I created.

React Front End

One important note, for the Front End I used Vite to bootstrap the application, but you could easily use Create React App as well.

client/src/main.jsx

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./App";
import { StoreProvider } from "easy-peasy";
import store from "./stores/store";

ReactDOM.render(
  <React.StrictMode>
    <StoreProvider store={store}>
      <App />
    </StoreProvider>
  </React.StrictMode>,
  document.getElementById("root")
);

This is the main entry point into our application. Everything here is pretty standard for React, but one important thing to note is we’re using a library called Easy Peasy. It essentially is a state management library and is very simple to setup, being a wrapper around Redux.

client/src/stores/store.js

import { createStore, action } from "easy-peasy";

const store = createStore({
  authorized: false,
  setAuthorized: action((state, payload) => {
    state.authorized = true;
  }),
  setUnauthorized: action((state, payload) => {
    state.authorized = false;
  })
});

export default store;

This is our setup for Easy Peasy. We’re tracking just a single state variable, but you could easily add more things to store here. Once we’re logged into Firebase or there’s a change in the auth state, we’ll be using the functions here to update and modify the boolean on if the user is authorized. If Easy Peasy isn’t your speed, you could easily replace this with Redux, Recoil, Mobx, the Context API, or any other state management solution.

client/src/services/firebase.js

import { initializeApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: "",
  authDomain: "",
  projectId: "",
  storageBucket: "",
  messagingSenderId: "",
  appId: ""
};

initializeApp(firebaseConfig);

const auth = getAuth();

export default {
  auth
};

Much like our Back End, we have to setup our Firebase service. The firebaseConfig is something you will get when you create a new project and add a web app to your project. I left it blank for a good reason as I didn’t want to share the information on my Firebase project. That being said, all you need to do is copy and paste your information from Firebase and you should be good to go.

client/src/App.jsx

import "./App.css";
import UnauthorizedRoutes from "./routes/UnauthorizedRoutes";
import AuthorizedRoutes from "./routes/AuthorizedRoutes";
import { useStoreState, useStoreActions } from "easy-peasy";
import firebaseService from "./services/firebase";
import { useEffect, useState } from "react";

function App() {
  const [loading, setLoading] = useState(true);
  const authorized = useStoreState((state) => state.authorized);
  const setAuthorized = useStoreActions((actions) => actions.setAuthorized);
  const setUnauthorized = useStoreActions((actions) => actions.setUnauthorized);

  const authStateListener = () => {
    firebaseService.auth.onAuthStateChanged(async (user) => {
      if (!user) {
        setLoading(false);
        return setUnauthorized();
      }

      setLoading(false);
      return setAuthorized();
    });
  };

  useEffect(() => {
    authStateListener();
  }, [authStateListener]);

  return (
    <div className="App" style={{ padding: 16 }}>
      {loading ? (
        <p>Loading...</p>
      ) : authorized ? (
        <AuthorizedRoutes />
      ) : (
        <UnauthorizedRoutes />
      )}
    </div>
  );
}

export default App;

In our App.jsx we tackle a few different things. First off we make sure we show a loading indication when the app first renders, because we’re essentially showing certain routes depending on we’re authenticated or not. The authStateListener function monitors through a useEffect the Firebase authentication state. If there’s a user, it sets the global state to true through Easy Peasy, otherwise it’s false.

client/src/routes/AuthorizedRoutes.jsx

import { BrowserRouter as Router, Routes, Route } from "react-router-dom";
import AuthorizedNav from "../components/navigation/AuthorizedNav";
import DashboardPage from "../components/pages/Dashboard";

export default function UnauthorizedRoutes() {
  return (
    <Router>
      <AuthorizedNav />
      <Routes>
        <Route path="/" element={<DashboardPage />} />
        <Route
          path="*"
          element={
            <main>
              <p>Not found.</p>
            </main>
          }
        />
      </Routes>
    </Router>
  );
}

If we are Authorized through Firebase Authentication, we have access to these routes. Right now it’s a single route with a dashboard page being rendered. One could easily add more routes that can only be seen while logged in, such as a Settings page, or anything that is relevant to the type of app it’s supposed to be.

client/src/routes/UnauthorizeRoutes.jsx

import { BrowserRouter as Router, Routes, Route } from "react-router-dom";
import UnauthorizedNav from "../components/navigation/UnauthorizedNav";
import HomePage from "../components/pages/Home";
import SignInPage from "../components/pages/SignIn";
import SignUpPage from "../components/pages/SignUp";

export default function UnauthorizedRoutes() {
  return (
    <Router>
      <UnauthorizedNav />
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/signup" element={<SignUpPage />} />
        <Route path="/signin" element={<SignInPage />} />
        <Route
          path="*"
          element={
            <main>
              <p>Not found.</p>
            </main>
          }
        />
      </Routes>
    </Router>
  );
}

If we are logged out, we can only Sign Up, Sign In, or see our Homepage. Just like with our authorized routes, you could easily add more routes, things like a forgot password route, about page, contact page, and etc….

client/src/components/navigation/AuthorizedNav.jsx

import { Link } from "react-router-dom";
import firebaseService from "../../services/firebase";

export default function AuthorizedNav() {
  const logUserOut = async () => {
    await firebaseService.auth.signOut();
  };
  return (
    <nav>
      <ul style={{ listStyleType: "none", display: "flex" }}>
        <li style={{ marginRight: ".5rem" }}>
          <Link to="/">Dashboard</Link>
        </li>
        <li>
          <button
            style={{
              textDecoration: "underline",
              border: "none",
              backgroundColor: "inherit",
              fontSize: "1rem",
              padding: 0
            }}
            onClick={logUserOut}
          >
            Sign Out
          </button>
        </li>
      </ul>
    </nav>
  );
}

Our navigation reflects the routes we have while we are authenticated. However, our sign out performs and action through Firebase. This will trickle back up to our App.jsx and kick us out of any authorized routes.

client/src/components/navigation/UnauthorizedNav.jsx

import { Link } from "react-router-dom";

export default function UnauthorizedNav() {
  return (
    <nav>
      <ul style={{ listStyleType: "none", display: "flex" }}>
        <li style={{ marginRight: ".5rem" }}>
          <Link to="/">Home</Link>
        </li>
        <li style={{ marginRight: ".5rem" }}>
          <Link to="/signup">Sign Up</Link>
        </li>
        <li>
          <Link to="/signin">Sign In</Link>
        </li>
      </ul>
    </nav>
  );
}

This is our navigation for the unauthorized routes. We can only visit the Sign Up, Sign In, or Home page.

client/src/components/pages/Home.jsx

export default function HomePage() {
  return <h1>Home</h1>;
}

Right now our Home page is a simple header, just to provide an example.

client/src/components/pages/SignIn.jsx

import { useStoreActions } from "easy-peasy";
import { signInWithEmailAndPassword } from "firebase/auth";
import { useState } from "react";
import { useLocation, useNavigate } from "react-router-dom";
import firebaseService from "../../services/firebase";

export default function SignInPage() {
  const location = useLocation();
  const navigate = useNavigate();
  const [fields, setFields] = useState({
    email: "",
    password: ""
  });
  const [error, setError] = useState("");

  const setAuthorized = useStoreActions((actions) => actions.setAuthorized);

  const handleChange = (e) => {
    setFields({ ...fields, [e.target.name]: e.target.value });
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    try {
      const user = await signInWithEmailAndPassword(
        firebaseService.auth,
        fields.email,
        fields.password
      );
      if (user) {
        setAuthorized();
        navigate("/");
        console.log("Called");
      }
    } catch (err) {
      console.log(err);
      setError("Invalid email address or password.");
    }
  };

  return (
    <main>
      {location.state && location.state.message ? (
        <p style={{ color: "green" }}>{location.state.message}</p>
      ) : null}
      <h1>Sign In</h1>
      <form onSubmit={handleSubmit}>
        <div>
          <label htmlFor="email">Email Address</label>
        </div>
        <div>
          <input
            type="email"
            name="email"
            value={fields.email}
            onChange={handleChange}
            required
          />
        </div>
        <div style={{ marginTop: "1rem" }}>
          <label htmlFor="password">Password</label>
        </div>
        <div>
          <input
            type="password"
            name="password"
            value={fields.password}
            onChange={handleChange}
            required
          />
        </div>
        {error ? <p style={{ color: "red" }}>Error: {error}</p> : null}
        <div style={{ marginTop: "1rem" }}>
          <button type="submit">Sign In</button>
        </div>
      </form>
    </main>
  );
}

On the Sign In page we have a very simple form where we are collecting the user’s email and password. When they click the button to sign in, it then fires Firebase auth function that alters the state of whether or not we are authorized, and also returns the user. And then the function navigates us away from Sign In to the / route, which should take us to our Dashboard page.

client/src/components/pages/SignUp.jsx

import { useState } from "react";
import { useNavigate } from "react-router-dom";
import axios from "axios";

export default function SignUpPage() {
  const [fields, setFields] = useState({
    email: "",
    name: "",
    password: "",
    confirmPassword: ""
  });
  const [error, setError] = useState("");

  const navigate = useNavigate();

  const handleChange = (e) => {
    setFields({ ...fields, [e.target.name]: e.target.value });
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    if (fields.password.length < 6) {
      return setError("Password must be at least 6 characters in length.");
    }
    if (fields.confirmPassword !== fields.password) {
      return setError("Password and confirm password must match.");
    }

    try {
      const req = await axios.post("http://localhost:4444/api/user", {
        email: fields.email,
        password: fields.password,
        name: fields.name
      });
      const message = req.data.success;
      return navigate("/signin", {
        replace: true,
        state: {
          message
        }
      });
    } catch (err) {
      const errMessage = err.response.data.error;
      return setError(errMessage);
    }
  };

  return (
    <div>
      <h1>Sign Up</h1>
      <form onSubmit={handleSubmit}>
        <div>
          <label htmlFor="email">Email Address</label>
        </div>
        <div>
          <input
            type="email"
            name="email"
            value={fields.email}
            onChange={handleChange}
            required
          />
        </div>
        <div style={{ marginTop: "1rem" }}>
          <label htmlFor="name">Name</label>
        </div>
        <div>
          <input
            type="text"
            name="name"
            value={fields.name}
            onChange={handleChange}
            required
          />
        </div>
        <div style={{ marginTop: "1rem" }}>
          <label htmlFor="password">Password</label>
        </div>
        <div>
          <input
            type="password"
            name="password"
            value={fields.password}
            onChange={handleChange}
            required
          />
        </div>
        <div style={{ marginTop: "1rem" }}>
          <label htmlFor="confirmPassword">Confirm Password</label>
        </div>
        <div>
          <input
            type="password"
            name="confirmPassword"
            value={fields.confirmPassword}
            onChange={handleChange}
            required
          />
        </div>

        {error ? <p style={{ color: "red" }}>Error: {error}</p> : null}
        <div style={{ marginTop: "1rem" }}>
          <button type="submit">Sign Up</button>
        </div>
      </form>
    </div>
  );
}

Our Sign Up page also contains a form that gathers information from the user. We are getting their email, their name, their password and confirming that password. After clicking Sign Up we use axios to make a post request to our API endpoint to add the new user. If there’s any errors, we handle those as well and display them on the screen for the user.

client/src/components/pages/Dashboard.jsx

import { useEffect, useState } from "react";
import firebaseService from "../../services/firebase";
import axios from "axios";

export default function DashboardPage() {
  const [loadingUser, setLoadingUser] = useState(true);
  const [user, setUser] = useState(null);

  const getUser = async () => {
    try {
      const token = await firebaseService.auth.currentUser.getIdToken(true);
      console.log(token);
      const req = await axios.get("http://localhost:4444/api/user", {
        headers: {
          authorization: `Bearer ${token}`
        }
      });
      console.log(req.data);
      if (req.data) {
        setUser(req.data);
        setLoadingUser(false);
      }
    } catch (err) {
      console.error(err);
    }
  };

  useEffect(() => {
    getUser();
  }, []);

  return (
    <>
      <h1>Dashboard</h1>
      {loadingUser ? (
        <p>Loading User</p>
      ) : (
        <div>
          <p>Name: {user.name}</p>
          <p>FirebaseID: {user.firebaseId}</p>
          <p>Email: {user.email}</p>
        </div>
      )}
    </>
  );
}

The final page we look at is our Dashboard, which if you remember can only be accessed while you are authorized and authenticated by Firebase. On this page we make a request to our api to get the user data and conditionally display it on the screen.

As you can see through these code examples, in a MERN stack application it’s not very difficult to integrate Firebase auth. We can use it on our Back End to protect our api routes and on our Front End to protect which pages and components we want to render to the user. We can pass our token along in the process each time we make HTTP requests. While it was out of scope for this guide, you could even integrate OAuth providers through Firebase as well, adding even more power to the arsenal. I hope these examples are useful to anyone trying to integrate with Firebase in their MERN stack application.

Creating a MERN stack app that uses Firebase Authentication - Part One

Brian Barbour — Mon, 24 Jan 2022 17:36:35 +0000

This article series will cover the following things:

Creating an Express server with a MongoDB database connected and using Firebase Admin SDK
Setting up a client side React App that uses Firebase for authentication. Check out Part Two
If you just want take a look at the code and can divine more from that, check out the public repo I created.

Express Back End

src/server.mjs

import express from "express";
import cors from "cors";
import config from "./config/index.mjs";
import db from "./config/db.mjs";
import userRouter from "./api/user.mjs";

const app = express();

db(config.MONGO_URI, app);

app.use(cors({ origin: true }));
app.use(express.json());
app.use("/api/user", userRouter);

app.listen(config.PORT, () =>
  console.log(`App listening on PORT ${config.PORT}`)
);

We start by importing all of our dependencies to get the server setup. Initialize that app and call our database function to connect to MongoDB. Then we connect the middleware we’re going to be using and begin listening on our PORT, a pretty standard Express app setup.

src/config/index.mjs

import dotenv from "dotenv";

dotenv.config();

export default {
  PORT: process.env.PORT,
  MONGO_URI: process.env.MONGO_URI,
  FIREBASE_PROJECT_ID: process.env.FIREBASE_PROJECT_ID,
  FIREBASE_PRIVATE_KEY_ID: process.env.FIREBASE_PRIVATE_KEY_ID,
  FIREBASE_PRIVATE_KEY:
    process.env.FIREBASE_PRIVATE_KEY &&
    process.env.FIREBASE_PRIVATE_KEY.replace(/\\n/g, "\n"),
  FIREBASE_CLIENT_EMAIL: process.env.FIREBASE_CLIENT_EMAIL,
  FIREBASE_CLIENT_ID: process.env.FIREBASE_CLIENT_ID,
  FIREBASE_AUTH_URI: process.env.FIREBASE_AUTH_URI,
  FIREBASE_TOKEN_URI: process.env.FIREBASE_TOKEN_URI,
  FIREBASE_AUTH_CERT_URL: process.env.FIREBASE_AUTH_CERT_URL,
  FIREBASE_CLIENT_CERT_URL: process.env.FIREBASE_CLIENT_CERT_URL
};

We use dotenv to pull in our environmental variables, of which includes our port, our MongoDB URI, and all of Firebase certificate information we need to use the Firebase Admin SDK.

src/config/db.mjs

import { MongoClient } from "mongodb";

export default async function (connectionString, app) {
  const client = new MongoClient(connectionString);
  try {
    await client.connect();
    app.locals.db = client.db("mern-firebase");
    console.log("+++ Database connected.");
  } catch (err) {
    await client.close();
    throw new Error("Database connection error.");
  }
}

This is our db function that we called inside of our server.mjs to connect us to MongoDB. We then attach it to our app as a variable under app.locals.db. This will allow us to quickly access the database from any of our endpoints under req.app.locals.db.

src/services/firebase.mjs

import admin from "firebase-admin";
import config from "../config/index.mjs";

const serviceAccount = {
  project_id: config.FIREBASE_PROJECT_ID,
  private_key_id: config.FIREBASE_PRIVATE_KEY_ID,
  private_key: config.FIREBASE_PRIVATE_KEY,
  client_email: config.FIREBASE_CLIENT_EMAIL,
  client_id: config.FIREBASE_CLIENT_ID,
  auth_uri: config.FIREBASE_AUTH_URI,
  token_uri: config.FIREBASE_TOKEN_URI,
  auth_provider_x509_cert_url: config.FIREBASE_AUTH_CERT_URL,
  client_x509_cert_url: config.FIREBASE_CLIENT_CERT_URL
};

const firebase = admin.initializeApp({
  credential: admin.credential.cert(serviceAccount)
});

export default {
  auth: firebase.auth()
};

To setup our Firebase Admin SDK to be used, we pass in the certificate information from Firebase that we stored within config file and .env. And then we export the service with invoking auth so it's ready to be consumed where ever we import it.

src/middleware/authenticate.mjs

import firebaseAdmin from "../services/firebase.mjs";

export default async function (req, res, next) {
  try {
    const firebaseToken = req.headers.authorization?.split(" ")[1];

    let firebaseUser;
    if (firebaseToken) {
      firebaseUser = await firebaseAdmin.auth.verifyIdToken(firebaseToken);
    }

    if (!firebaseUser) {
      // Unauthorized
      return res.sendStatus(401);
    }

    const usersCollection = req.app.locals.db.collection("user");

    const user = await usersCollection.findOne({
      firebaseId: firebaseUser.user_id
    });

    if (!user) {
      // Unauthorized
      return res.sendStatus(401);
    }

    req.user = user;

    next();
  } catch (err) {
    //Unauthorized
    res.sendStatus(401);
  }
}

This workhorse function will help us validate the Firebase tokens sent from the front end. Once validated we tack on the user document we fetched from MongoDB onto our request as req.user. On the endpoints we use this middleware, we can always ensure that there’s an authorized user by checking req.user.

src/api/user.mjs

import express from "express";
import authenticate from "../middleware/authenticate.mjs";
import firebaseAdmin from "../services/firebase.mjs";

const router = express.Router();

router.get("/", authenticate, async (req, res) => {
  res.status(200).json(req.user);
});

router.post("/", async (req, res) => {
  const { email, name, password } = req.body;

  if (!email || !name || !password) {
    return res.status(400).json({
      error:
        "Invalid request body. Must contain email, password, and name for user."
    });
  }

  try {
    const newFirebaseUser = await firebaseAdmin.auth.createUser({
      email,
      password
    });

    if (newFirebaseUser) {
      const userCollection = req.app.locals.db.collection("user");
      await userCollection.insertOne({
        email,
        name,
        firebaseId: newFirebaseUser.uid
      });
    }
    return res
      .status(200)
      .json({ success: "Account created successfully. Please sign in." });
  } catch (err) {
    if (err.code === "auth/email-already-exists") {
      return res
        .status(400)
        .json({ error: "User account already exists at email address." });
    }
    return res.status(500).json({ error: "Server error. Please try again" });
  }
});

export default router;

For this example, we are creating two routes in our user.mjs file. The first one gets a user from req.user, which we added in the authentication middleware and sends the document back.

The second one is our sign up route, which creates a new user and adds them to the collection. We do very simple validation on the request body to make sure the fields necessary are there. Much more expansive validation can be done if you want, a good library for that is express-validator. For the sake of this example, we’re not going to use and keep things simple. After validating the body, we then use the Firebase Admin SDK to create the user. This is something that can be done on the front end, but the reason we do it on the back end is the next piece, relating the Firebase account to our user document in MongoDB. We then return a message to the front end saying the user was created, or if there’s any errors we send those instead.

Moving on from here, we will take a look at the front end implementation and how we consume our endpoints and use Firebase to login and protect the information inside our app from those that are unauthorized.

Making SetTimeout Async Friendly

Brian Barbour — Wed, 21 Oct 2020 13:46:38 +0000

I love using the Async/Await syntax in ES6+ javascript. It keeps things simple and clean. I try my damndest avoid callbacks where possible in my code (unless a library I'm using expects or uses them--like with Express.js.)

I just want to say, I am by no means the author of this snippet, nor the first person to think it. Still, this is one of my favorite helper functions and I thought, why not share it--might make someone else's life easier too.

export const asyncTimeout = (ms: number) => {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
};

A simple function, that simply takes in the amount of milliseconds you wish to wait as a parameter. We then immediately return a new Promise, which is resolved when setTimeout completes.

In action, it may look like this.

async function doStuff() {
// doing stuff up here...

await asyncTimeout(1000);

// After waiting a second, continues doing stuff.
}

If anyone else has any awesome async helper functions they use, please share them!

Top 5 Web Developer Youtube Channels

Brian Barbour — Sun, 15 Dec 2019 18:11:39 +0000

I watch a lot of web development related Youtube channels. So I figured, why not share my favorite ones and explain why. Keep in mind this is obviously an opinionated list. However, I intend to provide as adequate justification for my picks as I can.

I ranked these channels based on the value I think they provide to me as a developer. Each one provides different types of content and a different point of view. The preference is towards unique content creators, who have a personality and opinions all of their own. Either that or the content they churn out has to be high quality and informative.

Traversy Media

I would not be the developer I am today, without discovering Brad Traversy's channel. I am a big fan of his videos, so much so that I actually became one of his patrons on Patreon. I've spent hundreds of hours watching his videos, learning, experimenting, and building based off what I learned from them.

I own all of his Udemy courses and have finished three of them. For those that I haven't finished, I still reference them all time to learn specific things.

Brad comes across as a humble developer, who loves sharing what he's learned. Never once does he claim to be the best or even to have all the right answers or methods. That doesn't matter, as he's here to help everyone develop a baseline understanding of various web technologies. Brad is down to earth, enjoying teaching and exploring new concepts. His devotion and curiosity helps to inspire my own, getting me excited and leading me to experiment.

There's a variety of different types of courses that he releases. Most are crash courses, focusing on introducing frameworks, libraries, and programming languages. I've learned the basics of all the Javascript frontend frameworks, a few CSS frameworks, Node.js, and Python from him. Also, on occasion he will drop an advice video that gives the right amount of realistic commentary and helpful motivation.

Junior Developer Central

I found this channel yesterday and already it's shot up to the number two spot for me. The discovery is what inspired me to make this blog post, as in my amazement, I wanted to get the word out. I think Junior Developer Central deserves hundreds of thousand of more subscribers. The value this channel offers to anyone learning web development is equal to buying a half dozen top notch Udemy courses.

You pay nothing for a wealth of useful tutorials, it's all there--for free. And the best part is they give in depth explanations not only on what to do, by also on why you do things.

If you don't look at any of the other people on this list, at least check this channel out and subscribe. I doubt you will regret it.

The Javascript How-Tos playlist will give someone just learning frontend development a lot of useful tricks and tips that often take time to learn or figure out.

I watched a few videos out of their Node.js Essentials playlist, and it cleared up some questions that had been plaguing me. I plan on going through the Command Line Tutorials playlist next, as it's never a bad idea to touch up on tool that is vital to my role.

Chris Hawkes

Chris is a feisty dude who often rambles about the web development industry. Normally this sort of content wouldn't attract me, a person looking for knowledge. His raw experience and honesty drew me in, enthralled me and I watched a slew of his videos afterward. Now I find myself excited whenever he releases a new video, eager to hear what he has to say next.

Chris has been a web developer for over 10 years. He's built apps that have made money for very real companies. He isn't just a Youtuber, and still works in the industry as developer with a day job. This makes him very relatable.

Yes Chris seems tired at times, perhaps a little jaded. But, we all are--as that's part of life in any career. Still, his passion comes across in spades. I would never question Chris's love for programming and web development. I find his fervor reinvigorates my own.

I may not always agree with everything he says, but I respect him for saying things--hard things, truthful things. Your mileage may vary, but give him a chance and really listen to the things he's saying. They often make more sense than many people are willing to admit.

I should note that Chris has some excellent tutorials too. Recently he released a ASP.NET Core tutorial that I went through and it was excellent.

Frederick Christenson

"Who is this guy in his bathtub?"

That was my actual first thought when I stumbled onto one of Frederick's videos. Curiosity drew me in to see more. A wealth of illuminating lectures is what keeps me coming back to his content.

Frederick mostly answers software development related questions from viewers. He tends to pick the most thoughtful and nuanced topics to touch on, approaching them from a careful and deliberate thought-space. This is all done from the perspective of a Senior Developer.

The value for me is in Frederick's wisdom, as he's been in this space for a long time. He understands different requirements, from both a business standpoint and also an engineering one.

Being someone who aspires to be a wise Senior Developer someday, I feel that learning from Frederick via osmosis will only accelerate that process for me.

Coding Tech

Dropping new videos multiple times a day, Coding Tech is the place I love to go to watch new developer talks from all sorts of different conferences and events.

There's not much more to say about this channel other than that. The videos always have excellent audio and video quality, a feat if you ask me. Most of the talks are live and on stage at the time of recording. I've never been to a tech conference, but hope to attend one in the near future. For now, I can experience a myriad of talks and follow the trends of the ever evolving industry we work in via this channel.

My First Year Of Code

Brian Barbour — Thu, 07 Nov 2019 14:28:45 +0000

This morning I sat down at my desk and was reviewing emails, notifications, and preparing for stand up--when it hit me.

It's been a year.

November 2018 was when I first sat down to learn code. Back then my curiosity was weak, my determination thin. I wanted to create a dynamic website, but I knew I would have to learn to code to do so.

Being someone who spent most of his career in IT, code was something I always brushed against--but shirked away from. C++ had destroyed me in a highschool class. I didn't think I was smart enough, as I'm not college educated. All the "computer science" I learned was on the job, fixing hardware, troubleshooting applications, and configuring networks.

Despite not knowing any code, I had just started to morph how I looked at learning and life goals in general.

I gave myself one year to learn Javascript enough to make dynamic websites the way I dreamed of. Not to be a Software Developer--in fact I didn't realize that was possible until months later.

I fired up Codecademy and started plucking away at their lessons.

Fast forward and I am now a Software Engineer. Not only have I transformed my life, but the code has transformed me. I no longer fear learning anything, nor trying new things. In fact, I am eager and embrace experiences as much as possible. My hunger has not subsided, in fact it has increased--ravenous for knowledge and creative expression.

It's hard to even remember the past year, because it was a whirlwind of learning and study. I feel a shred of remorse, a bittersweet sadness that I didn't set out to this earlier in life. That I let my fear and doubt control me for so long.

If I could change anything, I would have started down this path at a much younger age. Took my time, learned through organic experimentation.

Cramming knowledge into my brain at a breakneck pace is something I shouldn't have done. I should eased off, but I was just so excited and eager to unscramble the mysteries of code. Even now I'm still dealing with a slight sting of burn out (and figuring out that life/work balance.)

I am so glad for the opportunities that this journey of curiosity presented me. Also, for the bright future I see for myself now. I have a purpose, a truth that sets me forward, each and everyday.

Not being addled with the thought of "what am I going to do with my life", is something to celebrate alone.

To all of you learning how to code, who are setting out on this journey like I did. Slow down a little bit, savor those exponential increases in ability and skill. That is when it's the most fun. It drops off, as you get to a certain point. From there you will start expanding out, learning more about similar but very nuanced things (different languages, paradigms, and patterns.)

The first time you figure out how to use the Singleton pattern isn't nearly as awesome as the first time you iterate with a for loop. Having a computer do work on hundreds or thousands of pieces of data in less than a second blew my mind back then.

Closures: Modules

Brian Barbour — Fri, 25 Oct 2019 18:54:26 +0000

Modules are probably the most practical use of closures you can find in Javascript. By breaking your code up into separate files and "importing" what is needed, you tap into the super powers that closures give you. This notion is what I discussed in the first article of the series. In a nutshell, you can keep functions and variables "private" and inaccessible.

Traditional Object Oriented languages--for example C# and Java have access modifiers like private, public, and protected to achieve a similar effect. For example, a public method or property on a class can be accessed by other classes. This is very similar to exporting a function or variable in Javascript. (It's not a prefect comparison, but I see them as being two ways to reach a similar goal.)

The best way to understand is to study how the Javascript community converged around the module pattern as a way to isolate and protect code before modern approaches. Libraries like JQuery used the module pattern pattern to isolate and create an API for their users.

var mod = (function() {
  //private function and variable
  var status = 'is cool.';
  function logName(name) {
    return `${name} ${status}.`;
  }
  return logName;
})();

console.log(mod('Brian'));

We have an immediately invoked function that returns an anonymous function. It then spits back the logName function. It's a pass through, called by mod instead of itself. logName itself a single parameter in name. The variable status can't be accessed or changed from outside of this script, meaning its "private."

A module like this simple one could be thrown into a script file on any HTML page. When it loads, it will attach the variable mod to the window object, which can be used to call its function anywhere else on the page, even by other scripts.

The module pattern simple trick, albeit a powerful one. There are closures in the wild, all over the place! Once you understand the concept, they start revealing themselves all the time.

Note: There are differences between the module pattern and how ES6 modules work--as it's a built in feature of the language. However, for the most part it is still the same concept.

Auth0 First Impressions

Brian Barbour — Mon, 07 Oct 2019 12:19:14 +0000

Building a full stack web application can be a daunting challenge. One made much easier when you break it down into smaller pieces, tackling them one at a time. You need your server for an api and your front end GUI for user interaction. More than likely a database will be needed to persist data.

Security is also a huge concern and one I don't take lightly. I've worked a long time in the IT industry and have seen the damage that security breaches can cause to people and companies. Making sure user data is safe and contained is very important too.

This was the most intimidating part of the planning process for my project.

Sure, I learned how to hash passwords with bcrypt and how to use Node email libraries to send out recovery emails. Understanding sessions and JWT was something else I delved into as well. I built a few prototype APIs for practice, did my best to test them--only to feel a measure of uncertainty that I was building a truly secure application.

I'm still relatively new to software development. I've never built an enterprise or serious authentication system myself. Reaching out to some of my mentors, a lot of them suggested that I practice (as I have been), but never roll a system I made myself into production.

At least their reassurance made me feel better as far as my lack of confidence. That meant I needed to use someone else's service. My first instinct was to go with Firebase, which I had used before with previous projects. But, decided to do some research.

I had seen other tutorials and postings from Auth0, a service specializing in helping people delegate the process of authentication.

Note: I have no relation to Auth0, I was just a curious customer. Funny story though--I discovered them months ago because of a job ad they posted. I sent my resume and never heard anything at all back. I bet my resume fell into the ATS abyss, or they found an engineer way better than me.

Documentation & Ease

For my experiment, I decided to roll a Node and Express server with Vue.js as my front end library. Immediately upon creating my account with Auth0, and I was presented succinct examples using said technologies.

Doesn't get much easier than that.

I followed the walkthrough and was able to get the front end setup within a few minutes in a new Vue.js instance and integrate the auth with protected routes. Everything I needed to secure my little client side application was done.

I couldn't believe it.

Documentation is a huge thing for me as a developer. I tend to shy away from libraries or products that aren't well documented. For example, I also looked towards Okta, another similar service--and their documentation didn't seem as straight forward or well presented. So, kudos to Auth0 there.

Not to knock on Okta. Because, both services are way better than Firebase, which in my previous experience left me bewildered, confused, and Googling for hours. (In fact, it's kinda a weird universe where I need to Google to find out how to use a Google product, but I digress.)

The attempt wasn't without issues. I had a few things pop up, but mostly due to my own errors and not configuring things correctly inside of my Auth0 dashboard. Once I fixed those, it was smooth sailing.

Securing API on the Node/Express side of things was even easier than the Vue setup. Keep in mind--if Node isn't your flavor of serve-side code, they have similar tutorials for just about all the major frameworks in all the major programming languages.

Auth0 really cares about making the developer experience simple, fast, and intuitive.

They win at that goal, in my mind. Their documentation is probably second to only Gatsby's, which I've raved about before in other impression articles I've written.

Product Depth

There's more to Auth0 than just a simple authentication service. You can link up social logins from all your favorite OAuth providers, as well as having your users register with email and password.

I tried out using Google OAuth and also the default email and password authentication provided by Auth0.

Data is imported to build a profile for you in the client side of your app. Also, you can add metadata fields for the other data need about your user. For example, if you want a field for a user's light/dark theme preference--it's easily added to the profile.

Also, they give you the ability to implement roles--which falls into the authorization side of things. I didn't toy with that much (I'm still in the planning stages of my app), but I can already see that being a huge boon.

I remember having to come up with my own way of doing that with Firebase authentication.

Auth0 has a smorgasboard of other features--for example SSO integration, logging, hooks (which let you write logic that happens, much like a database trigger), and multi-factor authentication.

All in all, if it's an important or well known authentication or authorization feature, they've implemented it.

Price

The elephant in the room. All the features in the world are amazing, but if something is too pricey--no one is going to use it. As with most cloud providers these days, Auth0 offers a very generous free tier. It lets you play around with their product and learn--without requiring an up front investment.

The price is going to vary depending on how big your app is. I am thinking I may never need to pay them a dime. However, if my app does grow, the next tier is only $23 a month for 1,000 active users. It should more than pay for itself at that point.

If you're looking to use it in enterprise, the price is somewhere around $1k a month or more. I have no idea if that's reasonable or not, as I've never built an enterprise scale application. I guess at that level it depends on how much development time you want to spend rolling your own authentication and authorization. You probably could save a lot of time and money simply handing that responsibility off to the experts, who do it well.

Example App

This example app is nothing crazy but it will give you an idea of how it works and what the code looks like. Most of it can be found in the documentation, but here's what I put together in a few hours of messing around.

Live Version: https://vue-express-auth0.herokuapp.com/

Github: https://github.com/steelvoltage/vue-express-auth0

I plan to use this example as a boilerplate for future applications.

I'm a huge fan of Auth0 now. What do you guys think? Has anyone else played around with their service or have any insight?

Why I Love The Syntax.fm Podcast

Brian Barbour — Fri, 27 Sep 2019 14:07:01 +0000

I have a long commute everyday and there's nothing more satisfying than firing up an interesting podcast or audiobook for the drive. I am an audio learner, so it's especially useful for me. I've gone through quite a few developer podcasts (many of which I found right here on Dev.to) constantly searching for new ones I want to add to my list.

Usually, I give them a couple of episodes and end up stopping. However, I always come back to Syntax, every week--like clockwork. In fact, this morning I turned off another podcast to go listen to the new Syntax episode from Wednesday.

That got me reflecting on my favorite parts about Syntax and why it always draws me back.

Subject Matter

The hosts of the show, Scott and Wes teach web development for a living. Because of this, the duo discuss a wide breadth of technologies. They have entire episodes dedicated to Javascript, Node.js, React, CSS, security, Wordpress--so on and so forth. There are well over a hundred of them, a nice backlog to march through as a new listener.

I've listened to like eighty percent of them at this point, I think.

I love the episodes where they dive deep, weighing pros and cons. Yet, its nice that they sprinkle in Potluck episodes where they go over a broad range of listener prompted questions. I think what matters the most is that they tend to approach web technologies as the tools they are. They are't pushing a dogma.

Of course, its clear they have opinions on different technologies, yet they don't let that bleed through or overwhelm the message. For example, I have gotten the impression that neither Scott or Wes care for PHP much, or maybe are tired of it. Yet, they've expressed how instrumental it was during their early careers working in Wordpress and Drupal.

One of my favorite episodes was where Scott taught Wes about Vue.js. Wes had never used it before and is an experienced React developer--so I was able to relate. It led me to learning more about Vue in my spare time. So, kudos there to Scott.

Many other podcasts tend to do an interview format. I don't mind an occasional interview, but it grows old when done consecutively. I would rather have hosts that are consistent, than a different voice each episode. Part of the charm is getting to know the people you listen to every week. I feel like Scott and Wes are my friends, even though I've never met them or talked to them.

I never really felt that way with other podcasts, so they're doing something right.

When the duo do interview people, they ask pointed and in-depth questions. I've listened to other podcasts where they spent the entire episode inflating the ego of the person they have on as a guest, or asking easy questions that they can knock out of the park. Since Wes and Scott teach new web developers, they know the sorts of questions students ask and can frame them.

It's great, especially if you've never delved into a particular technology.

Humility

I could be wrong. But, my impression from listening to over a hundred episodes is that Scott and Wes are truly humble and earnest people. Developers have a tendency to like to flex their mental muscle at times. I get a sense that many who do podcasts have pride and certain agendas they wish to push. This can bleed through in very obvious ways, so much that it makes me cringe.

This has never happened when listening to Syntax.

Now, let me say--we all have an agenda at the end of the day. I know that Scott and Wes do too, still they swing that hammer lightly.

If I had to guess, their agendas are to attract people towards their respective learning platforms. Even so, they show that the best teachers/mentors aren't the ones who show off or gloat--rather the ones that guide and mold their students.

I don't feel like the entire podcast is one big sales pitch. Even with the ad reads and the shameless plugs.

I'll admit, I've glanced at their courses quite a few times--especially if they introduce one on a subject I'm interested in. Yet, I've never bought anything from either host. Well, I did take Wes's Javascript 30 course, which is free (I highly recommend it.) Scott also has a bunch of free stuff on his Youtube channel.

Humor

I find Scott and Wes hilarious. Both have goofy personalities. Wes can't pronounce ternary and every time it brings a smile to my face. Their jokes and sponsor ad read transitions have made me laugh out loud in my car like a buffoon. Often I look forward to the reads these days, especially with how Scott slides his way into one in a clever and pun-filled manner. Seeing as both of them are the about same age as me, I think there's some similarity in what we find funny. I doubt everyone will laugh as much as I do.

Production Quality

Scott and Wes sound like crisp and clean radio hosts. They have awesome mics (as is necessary for professional video course makers.)

Scott's deep voice and Wes's charming Canadian accent make a stark and pleasant contrast. I've listened to other podcasts where I had no idea who was talking, as people sounded similar and droned together.

They don't interrupt each other, or talk over each other. If they do, I imagine those parts are clipped out in post production. Either that, or they have a good synergy--something hard to measure or even figure out.

I'm not knocking on other podcasters, who maybe can't afford good equipment or have sound engineering experience like Scott does. All I'm saying is, the audio and editing is icing on the cake. I've listened to their live episodes, which have lesser sound quality, and still had a good time.

Checkout https://syntax.fm/ if you haven't. Give it a listen! I hope you enjoy it as much as I do.

Framework Hell

Brian Barbour — Tue, 17 Sep 2019 13:09:47 +0000

As I learned Javascript over the past year, I was focused mostly on the front end. I think that tends to be the direction that most learning materials and new developers go. That's what Javascript is notorious for. Also, everyone wants to make badass interactive websites.

The past two months or so I've taken a sharp detour to study more of the back end. For me that means delving into Node.js in earnest, rather than just using it to transpile my front end and run a dev server. I also learned Apex, the back end language for Salesforce--which I'm involved with during my day job.

Ultimately, the goal is to be able to call myself fullstack. Not even just for the job title (and pay), but for my own self interest. I have dozens of project ideas, and to be able to code them all from start to finish, back to front, is a very enticing notion.

One huge thing I must admit, is that I'm loving the back end. There's something fun and addicting about handling requests and data, formulating responses and interacting with databases. Maybe I'm just a nerd. I can't stop thinking about all the cool things that the back end lets me dream up. In fact, I'm flooded with creativity because of it.

That's ironic because I got this impression at first that back end development was this stuffy and non-creative place. Sure, the front end makes pretty and flashy things. The back end is where plenty of magic happens and the power of an application is generated.

There is also one other huge advantage I found on the back end.

Stability.

In searching for resources, I found blog posts and articles Node.js from early 2010's. They are still relevant for the most part, except for minor things. For example, having to include the bodyparser module with Express. It's built in now and you don't have to import it separately

Compare that to the front end. If I look up articles from that era, I'm suddenly in foreign territory. I'll find stuff about JQuery and Angular.js, or possibly early React.

The front end is an ever shifting landscape, filled with chaos and uncertainty. Mind are some advantages there, for newbies, as you can easily "catch up" your knowledge to the industry standards. And you will be having to do that continually.

I recently watched a very good video by Cris Hawkes, one of my favorite web dev Youtubers.

This video helped me realize why I liked Node.js so much, for its stability. I have nothing against React in particular. The video is shooting at it, because it's the big dog. However, I feel the overall message is about framework hell in general.

The wheel keeps getting reinvented on the front end.

I don't know what the solution is, but do have some thoughts.

As I said before, I work in Salesforce development and they built their own front-end framework based on Web Components called Lightning Web Components, and follows all of its rules. Except, it also integrates with the platform to make querying and inserting data much easier. Thus, it would kinda pointless for outsiders to use unfortunately.

Svelte is awesome, without the virtual dom, and is much smaller than React. The fact that it has to "compile" Javascript into older Javascript shows that there is fundamental problem. That problem is backwards compatibility and browser support.

I think eventually, we will probably use Web Components instead of these virtual dom frameworks.

Still... Hasn't compatibility always been the big elephant in the room with web development? There really is no easy solution, other than the passage of time as more people adopt newer browsers. Those browsers will then introduce newer features and the cycle repeats itself. We are always on the bleeding edge as developers, and we don't want to wait for the rest of the world to catch up to us.

So, we take shortcuts with our frameworks. At what cost?

Our own sanity more than likely.

I know personally, I am going to look into things like Polymer for future front end projects. Maybe I could get ahead of the curve, and future proof some of my own applications.