Forem: Joe Sweeney

Deploying a Jigsaw static site to GitHub Pages using GitHub Actions

Joe Sweeney — Fri, 23 Oct 2020 03:28:03 +0000

There are a couple of articles on how to do this already, so I'll put them at the end of this article in case this method doesn't work out for you (and I give them credit as they gave me a starting point and I used some of their code in this article). In the meantime, I want to show you what I believe to be the best and easiest way to deploy your Jigsaw site to GitHub Pages using GitHub Actions after a bit of my own trial and error.

This method assumes that you want to publish one of your personal GitHub projects, or a "project" site. This will probably need to be tweaked for a "user" site, which I don't have any experience with (at least not in GitHub).

It also assumes you've gotten a Jigsaw site that builds properly at least in a local dev environment.

Setup

In your repo's GitHub settings, turn on GitHub Pages, using gh-pages as the branch to build from, and / (root) as the folder to build from.

Then, from your repo's root directory, create a new workflow under .github/workflows/main.yml with the following contents:

name: Build & Publish

on:
  push:
    branches:
      - master

jobs:
  build-site:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Install Composer Dependencies
      run: composer install --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist
    - name: Install NPM Dependencies
      run: npm install
    - name: Build Site
      run: npm run production
    - name: Stage Files
      run: git add -f build_production
    - name: Commit files
      run: |
        git config --local user.email "actions@github.com"
        git config --local user.name "GitHub Actions"
        git commit -m "Build for deploy"
    - name: Publish
      run: |
        git subtree split --prefix build_production -b gh-pages
        git push -f origin gh-pages:gh-pages

This should literally be everything you need to do. You can test this by manually running the action from the GitHub Action tab, or just commit new code to the master or main branch of your project.

If you're using main, which is possible as GitHub is making it the default for new repos, you'll just need to change anywhere master is referenced to main.

Thanks to James Brooks and Max Kostinevich for your helpful articles getting me even started on the right path and saving me tons of time:

https://james.brooks.page/blog/jigsaw-github-actions/
https://maxkostinevich.com/blog/deploy-jigsaw-using-github-actions/

Laravel task scheduling without cron jobs for local development

Joe Sweeney — Thu, 11 Jun 2020 21:23:46 +0000

Since publishing this article, it seems Laravel now has an official way of running the scheduler locally, which is described here:
https://laravel.com/docs/8.x/scheduling#running-the-scheduler-locally

It's very easy to create scheduled tasks in Laravel. They're also pretty easy to run in Linux or MacOS with cron jobs. However, I've been doing a lot of development on Windows lately, and Windows does not have UNIX-style cron jobs. And, there is no mention in Laravel's docs on how to do this properly in Windows. I found this helpful article going over how to do this in Windows using the Task Scheduler, but this felt way too cumbersome. Crawling around arcane Windows settings is not my idea of a good time, and just feels wrong since this is a project-level, not system-level, concern.

So, I found a simple workaround that helps me not only avoid dealing with the Windows Task Scheduler, but also the crontab in macOS and Linux as well! If I were to switch dev computers tomorrow, or bring other people into my project, I have completely cross-platform method of handling scheduled jobs without digging into the guts of my operating system; a NodeJS library.

Using `node-schedule`

So, I'm not sure if this makes me a bad Laravel dev since I'm not building this tool as an Artisan command (or even in PHP), but it's the most effective and reliable solution available right now without doing a bunch of extra work. Since most Laravel devs are using some sort of front-end tooling (such as Laravel Mix or Webpack), we already have Node (and maybe Yarn) installed on our dev machines, making this less of a burden.

Add `node-schedule` to your project

Make sure you're cd'd into your Laravel project root and run either the NPM or Yarn command below, depending on what you've got going.

# NPM
npm install node-schedule --save-dev

# Yarn
yarn add --dev node-schedule

Create JavaScript file for schedule code

Still in your root directory, create a file called dev-scheduler.js, then put the following in that file.

const schedule = require('node-schedule')
const { exec } = require('child_process')

new schedule.scheduleJob('* * * * *', function() {
    exec('php artisan schedule:run', function(error, stdout, stderr) {
        if (error) console.log(error)
        if (stderr) console.log(stderr)
        console.log(stdout)
    })
})

Run the schuduler

Run the new file with Node.

node dev-scheduler.js

And…that's it. Keep in mind this is not for production. Use cron jobs for that.

Enjoy this time-saver!

Twilio Hackathon — Connecting the elderly to more people in their local community

Joe Sweeney — Fri, 01 May 2020 01:09:23 +0000

I have a neighbor whom I've worried about on occasion, but much more so now that COVID-19 is upon us. She is 80 years old and, while still very independent and able to do most everything she wants, is quite vulnerable to this pandemic. I also found out she doesn't have the Internet, or even a computer. Or a smart phone. Or a phone that can text! She just has a landline phone.

It made me realize that there are probably a lot of people out there who need help, but don't have the ability to reach out and ask for help as easily. Of course, hopefully most of those folks can call on family or other trusted people nearby, but if not, they need some other way to ask for help that isn't an immediate emergency, but are very much needed nonetheless (getting groceries or prescriptions, having something delivered across town, etc.).

After seeing the announcement for this hackathon, I dug through the Twilio APIs looking for some inspiration and came up with this idea after looking through the Voice documentation.

What I built

The project is called "I Need Help", and it is a Node-powered web app that allows people to simply make a phone call to a number, and a bot asks them what they need help with. It only asks for the person to introduce themselves and state their needs, it doesn't ask for any other personal details. The caller's request is recorded, then published on the "I Need Help" website (with their direct consent, of course. If they don't agree to the terms, the call will end and the interaction isn't recorded).

Once the recording is on the website, a registered and logged-in user can assign that need to themselves. This user, which I've been calling a "helper", can call the person in need via an anonymous number (to protect the person-in-need's phone number), and the person in need can also reach out to the helper with their own anonymous number. They can call each other with those same numbers as long as the task is in progress (similar to an Uber driver/rider interaction).

When a task is in progress, a helper can either mark the task as complete if they successfully helped the person or they can put it back in the queue to allow someone else to help. Also, I made the design decision to only allow one task to be worked on at a time, for both technical reasons and to help the helpers avoid taking on more than they can handle. Each person who needs help should get their undivided attention. Also, the person who calls in a request can only request one thing at a time per number, until that task is resolved.

There is a very basic stats page that the signed-in user can look at to see how needs they have fulfilled, so that they are more motivated to continue.

How I built it

I started building the app on April 8th. I didn't formally plan it too much, I just started writing code and playing with Twilio's API immediately. I'm organizing my work just using Github's issue tracker with the project repo. As of right now, the app seems pretty stable but could probably use more features. As you'll see if you look at the commit history, I worked on it pretty heavily for 10 days then took a break before cleaning it up for final submission.

The app is built using Adonis (a NodeJS framework), MySQL (or any relational database compatible with Knex.js), Mithril, and Bootstrap. There are even some websockets in there! I wanted to stick with a stack I'm comfortable with, since I've never used Twilio's API before and didn't want to spend too much time learning too many different things at once. I also didn't want to spend much time fussing with front-end build tools, so all the scripts, assets, and other dependencies are just CDN'd onto the pages.

The websockets are used to update the front-page in real-time with the most up-to-date tasks so that users don't have to constantly refresh the page to see new tasks they can help with. And, when tasks are marked as in-progress or completed, they're removed from that page so no one else can accidentally claim the task.

I'm using two features of Twilio right now; the Programmable Voice API to handle the initial phone call and recording, and the Proxy service to make phone numbers anonymous.

Video demo

Link to code

You can find the repository here, with setup instructions so you can host your own instance:
https://github.com/jcs224/ineedhelp

Also, I'm looking at other people's submissions and am very impressed. There are a lot of brilliant, creative devs out there. Great job!

Introducing Podrain, a web-based, offline-capable podcast app

Joe Sweeney — Sat, 14 Mar 2020 01:41:09 +0000

I've been a fairly avid listener of podcasts since 2005, which is around when Apple introduced them to iTunes. I was pretty embedded in the Apple ecosystem back then, so I didn't really care that there wasn't a good way of listening to podcasts on non-Apple devices.

Over the years, however, I have been distancing myself from Apple more and more, to the point where I now only use Apple devices when I need to build and deploy iOS projects. I've been developing an allergy to monopolistic lock-in and censorship of which apps can run where. I've embraced the web as much as possible, as both a user and a software developer, because it is the most device-agnostic standard out there today. If your device has a screen, and a web browser, the chances of a web-based app working on it are actually pretty high.

But, as far as podcasts were concerned, I found it really tough to find a non-Apple app that had everything I wanted. Ease of use, offline listening, ability to back up and sync with other devices, and run on any device. I'm an Android user now, so I've been using Podcast Addict, which is a great app. But, it's exclusive to Android. I wanted to give Pocket Casts a go, but the reliability was so-so according to reviews, and I need something I can trust. I tried Stitcher, but it was just too hard to listen to podcasts without being distracted by all the advertising and non-podcast-related stuff. I use Spotify for music, but their interface just isn't well-suited for podcasts, and besides, I want to support podcasts as an open web standard that no big entity seeks to control, which even Apple respects (in regards to podcasts).

So, I decided to scratch my own itch and take a crack at this problem myself.

Introducing Podrain

Podrain is a web-based podcasting app with some very basic features:

Offline listening
Episode queue that spans across podcasts
Pure focus on audio podcasts (no radio, video podcasts, news, etc.)
Sync backup to a cloud server

App structure

The app was built with my "trusty tools", Parcel, Mithril and Tailwind. I've been using this stack lately for almost every new project.

Challenges

It took me about three weeks of part-time effort to build this app, which I open-sourced yesterday. It's still pretty rough around the edges and needs more documentation, but it works well enough and I've replaced my current podcast app with it! Besides regular web development woes, here are some of the challenges I faced and how I overcame them.

The offline problem

I've actually tried to build this app before, but as a web app that completely relied on having a really good internet connection the entire time. This obviously doesn't work for someone who spends much of his time in one of the most rural areas of the United States. So, I had to take a different approach and ensure that this app could work in a way that didn't need any Internet connection after the initial app was loaded. After all, I listen to podcasts quite often while driving in areas with not so much as a 3G cell signal. To solve that, I used PouchDB which made it really easy to store all the needed podcast metadata in browser storage, and have it persist even when the app web page is closed.

In addition, I needed the actual audio files to be saved to the device, rather than streamed. This is very important for both maintaining an uninterrupted listening experience as well as to avoid risking extra charges for excessive cell data usage. I used localForage to give the user the option to store the audio files in their browser's IndexedDB storage system as binary Blobs.

Unfortunately, the audio file download feature won't work well on iOS because they only allow 50-megabyte files for domain, when a single MP3 file for a podcast episode could easily be twice that. Will probably have to disable the feature for iOS browsers unless Apple has a change of heart.

CORS for podcast feeds and media

This was actually a very tough problem to solve that seemed to have only bad options. The easiest way was to disable CORS in my browser (using a browser plugin), but that's very unsafe as I would be quite vulnerable to XSS and other nasty attacks if I visit other websites. The other option is to use a proxy, but downloading hundreds of megs data using a public proxy would easily overwhelm many of these proxy sites and I might even have my IP address banned.

However, there is a Node server called CORS Anywhere that can take all requests to a domain, and forward them with different CORS headers that allow the browser to accept content from different domains via XHR. It turns out there is an excellent pre-configured Heroku dyno anyone can spin up and run their own proxy, likely for free! So that's what I did. Then, in the app, I put the URL to this proxy and I'm off to the races. I may find a better way of setting that up more automatically down the road, but once it was set up, I'm able to start adding podcasts and listening to episodes!

Future

The app has some real rough edges, but they will be worked out over time. Eventually, I want to add service workers and a web app manifest file to make it a true PWA. Also, the interface needs to be optimized for tablet/desktop, since it was built mobile-first for the smallest screen (where I use it the most).

Hopefully, this app can help serve as one of many examples of just how far you can take pure web technologies if you give them a chance.

Switching back to a monolith

Joe Sweeney — Thu, 30 Jan 2020 21:52:56 +0000

A couple of years ago, I finally decided to dive head-first into some of the newer JavaScript technologies that I've been putting off for a while, such as Webpack, Vue, and NodeJS.

Before I was "enlightened", when I wanted to include JS or CSS in my regular ol' web app (built with Laravel), I would just include it in a script or link tag in my HTML. Pretty simple. And, I was perfectly content doing this. I even used Gulp a little bit, mostly for minifying my own JS and compiling Sass stylesheets. But, it was becoming clear that there was this huge ecosystem of things happening in JS-land and I was feeling at risk of falling behind if I didn't at least try to learn some of it.

So, I incorporated some Vue into my existing project, without Webpack or build tools of any kind. I really enjoyed how Vue handled reactivity and DOM updates. Compared to jQuery, it was like magic. I was able to throw away so much spaghetti jQuery on a page and basically create a full-blown mini-app with just a simple Vue instance.

After that great experience, I started looking into how Vue is used out in the wild. While my particular use-case as a simple add-in to a traditional server-rendered web app was actually pretty common, it became evident that Vue is really built with single-page apps in mind. This led me down a rabbit hole of Webpack, Node, single-page app architecture, NPM, new authentication schemes, new data-fetching schemes (REST, GraphQL)…

Despite having to learn all these new things, I decided to do a rewrite of my Laravel side project in pure JavaScript using AdonisJS and Mithril after playing around with them a bit. And, I learned a great deal from that experience. I built a front-end single-page app in Mithril, backed by an Adonis API. This allowed me to create a really interactive experience in the front-end, and made the app feel more like an "app" rather than a "website". It did, however, present a lot of new challenges.

Secure authentication

Authentication is actually not very straightforward to implement, if I truly separate my API from the user-facing app. I have to be very careful how I store and use auth tokens (such as with OAuth and JWT), and I have to be conscious of more threats than with session-based backends protected by CSRF. In other words, there are a lot of ways to mess it up.

Efficiently fetching data

With a single-page app, usually it would fetch data from an API, or multiple APIs. However, I have to be careful to only grab the data I need, when I need it. I would often grab too much and have more data than I need, or, I would grab too little and have to make multiple, inefficient requests. Solutions like GraphQL are meant to address this, but it adds another layer of concern to both the front and back-end.

Decoupled architecture

While this can be very beneficial if I want to offer a suite of end-user products (web, mobile, desktop, toaster, etc.), it does make it more expensive early in the project to basically have to build a minimum of two products in order to get to release. This makes distribution a bit more complicated, and can be a bottleneck early on when I really want to be moving as fast as possible.

Testing

I've only recently really embraced test-driven development when building my own web apps, but now I have to write tests for two apps (single-page app, API) instead of just one. End-to-end tests are easy on the API, but I have to always make sure the test mocks on the front-end match my API, assuming I want to test the SPA and API independently. A change in one of the apps usually means I have to change the other one as well.

With a "traditional" web app, all the unit and end-to-end tests can be included in the same test suite.

Final thoughts

While I did learn a ton creating an API/single-page app architecture (and likely will again in the near future), I've decided to go back to doing things "old school", but with some "new school" sprinkled in for my current project. I'm doing a V3 rewrite as a Laravel app again, without an API. You could say I've embraced the Majestic Monolith.

However, the templates for the app will actually be a single-page app thanks to InertiaJS, an innovative library that allows me to write my templates in Vue, React, or Svelte without having to use an API. I'm literally getting the best of both worlds; the stability and simplicity of a traditional Laravel app, combined with the cutting-edge, interactive UI of a single-page app. Perhaps I'll write more in-depth about Inertia in the future, but in the meantime, you should check it out!

Benefits of contributing code to your favorite open source project(s)

Joe Sweeney — Sun, 10 Nov 2019 22:30:49 +0000

Open-source software is extremely pervasive. Many of you reading this probably benefit directly from it to help you do your jobs. End users experience the benefits when they surf the web or use a free alternative to prohibitively-priced software (such as Godot game engine or GIMP). Also, many of us simply like to examine the source code of our favorite projects to learn a bit more about how they work.

These are all great reasons to use open-source. However, the real power lies in not just consuming all of this great work, but actually contributing something back. Events like Hacktoberfest help incentivize us to actually try doing that, but personally I get far more out of it than a free t-shirt.

There are also many other ways to contribute to open source (documentation, evangelizing the project, etc.) but in this article I want to focus on code contributions specifically.

Here are some of the benefits that I've personally experienced.

Getting a better in-depth understanding of the project

As you can imagine, you'll learn a lot about the project codebase if you're trying to fix a bug or add a feature. Even if you don't ultimately succeed in figuring it out and making the change, you will undoubtedly learn a lot from the experience.

If you do get stuck, don't be afraid to ask for help by raising an issue on Github, or whatever communication channels are preferred by the project.

Also, don't feel like you need to be an expert in the project. Most of my changes are about two lines of code. Sometimes that's the difference between code that works and code that doesn't.

Feeling of empowerment

If the project is on Github, you'll probably notice that there are far more stars (people who show some tangential interest in the project) than contributors (people who actually have committed code). If you become a contributor, however small your contribution, you become a member of an elite club. Someone who cares and takes action, and doesn't just sit on the sidelines waiting for others to improve the project.

Building a stronger connection with the project community

When you pay for a proprietary software product with dollars, you want to see a return on your investment in terms of more dollars than you put in (usually). When you make a change or add a fix to your favorite open-source project, you're making an investment with your time, but it's more personally enriching as it helps you learn and brings you closer to people who work on this project purely out of the joy they get from working on it. If you end up making multiple contributions to the project over time, you'll likely be interacting with the same people on a regular basis.

Valuable experience in collaboration and communication

With remote work on the rise, especially in the tech industry, the ability to communicate effectively and collaborate with others will be of utmost importance. When you participate in an open-source project, whether with Github issues, the project's Slack/Discord channel, or even a mailing list, your ability to interact with people of vastly different backgrounds and situations will become paramount. The better you are at this, the more desirable you will be by potential employers and customers/clients. What better way to practice this than by helping improve a project you care about?

Also, if there are contribution guidelines (often in the form of a CONTRIBUTING.md file in the project repo) you will be able to demonstrate that you're able to properly follow instructions and care about doing things right.

Résumé builder

If you're on Github, a large portion of the things you do on that platform are public. Use this to your advantage by always putting your best foot forward when you're making pull requests and communicating with fellow contributors. As software devs, we are fortunate to have this avenue to demonstrate our work, so make the most of it!

Final thoughts

There are so many ways to benefit from contributing to open source, that I wished I started doing it sooner. I hope that you can find some time to participate in improving one of your favorite projects and experience at least some of the same benefits.

How to actually make your life easier with Docker

Joe Sweeney — Thu, 31 Oct 2019 22:21:12 +0000

When Docker came out in 2013, the benefits being touted were pretty clear. "Full isolation from host machine and other apps", "perfectly-reproducible environments", and the "works on my machine" chant finally a thing of the past. Considering that most of my time troubleshooting issues was getting my code that works perfectly in development to run in production properly, Docker seemed like a great antidote.

However, what held me back from adopting it for another, like, 5 years, was that it was just too difficult to understand. I don't like working with tech stacks that I don't understand, because that's just another issue I'd have to troubleshoot down the road when things don't go totally perfectly. Despite having to do a little more work to configure the server where my code would ultimately live and run, and sometimes deal with some painful config issues, at least I had encountered many of those issues previously and knew how to fix them.

Today, Docker is so pervasive that it's actually become quite difficult to avoid. It seems like just about every project on Github has a Dockerfile and instructions in the readme on how to use it. Fortunately, it has, in my opinion, started to live up to its promise of actually making our lives as devs easier. I still haven't quite gone "all-in" with Docker, but there are areas where it has genuinely improved my happiness and productivity.

My sweet spot with Docker

There are certain stacks that I find a huge pain to set up again and again, when switching computers for example. These tend to be things like relational database (MySQL and Postgres) and any type of app that normally has a really crazy setup procedure (like self-hosted Gitlab).

How many times have you run into issues setting up MySQL on your computer? Especially on Linux? I always seem to struggle with that one. Adding the right package repository in Ubuntu, getting through the CLI installation unscathed, and booting it up. All of the different configuration possibilities allow a lot of things to get messed up on that initial install and bootup.

Or, I can just do this, and have a fully-working MySQL server ready to go!

docker run --name mysql-5 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5

From there, I just use my favorite MySQL editor (Sequel Pro, HeidiSQL, etc.) and I can connect any service on my machine that needs MySQL, Docker or not, to use it as needed. And, I can boot up as many as I want (or as many as my hardware would allow) and just change the exposed port on those new instances (like 3307, 3308, etc.) so there isn't any conflict.

Also, I like to test emails on my local machine without relying on en external service to handle it. Instead, I can just throw in a quick SMTP trapping service called Mailhog that allows me to actually see the output of my locally-tested email!

docker run --name my-mailhog -p 1025:1025 -p 8025:8025 -d mailhog/mailhog

This command is even simpler. Just provide a name of your choosing to identify the container, the ports you want exposed (in this case, 1025 for the SMTP port and 8025 for the web portal to see the trapped emails), and the name of the image in Docker Hub (mailhog/mailhog). This command will boot up the server and allow you to see your trapped emails. It's incredibly easy.

So, I could use Docker with my main app codebase, but I just continue to use NodeJS without even worrying about Docker-izing it. Also, these examples aren't necessarily helpful for deploying to production (which Docker can certainly help with, with the right knowledge), they were just to help demonstrate setting up a nice development environment with less fuss.

Final thoughts

If you're finding it difficult to get into and understand Docker, or feeling left behind by the hype train, don't worry. You can make Docker work for you, without feeling like you need to ditch your VMs and anything not totally containerized. I have found a middle-ground that is working very well for me at the moment. As time goes on, I'm sure I'll adopt more and more pieces as it makes sense. I hope you can do the same as well.

The Five-Minute Rule

Joe Sweeney — Mon, 28 Oct 2019 04:11:35 +0000

In the world of web development (or any kind of dev for that matter), there are so many stacks and tools to choose from to accomplish our tasks. But, the paradox of choice can paralyze us. Usually, the choice comes down to:

What we have experience with already
If a certain tool/language/stack/whatever is best suited to the task

However, if we're beginners, trying to tackle a brand-new problem, or are simply curious about trying other things out, we can really get bogged down by all the options.

I've reflected on this recently, as I come up with new ideas for apps sometimes, and I wonder how I should go about building them. I usually like to take this opportunity to experiment with other tools without investing too heavily. If I find a bunch of different options that I think might fit my requirements and development style, I try to give them all a chance.

After doing this for a while, I've come up with an interesting formula that has actually sort of worked for me (when I practice it). I call it the "Five-Minute Rule".

How does it work?

Well, I try to install the stack on my computer. While the timer hasn't technically started yet, I do judge on how easy it is to set up. It has to have great documentation and/or a super-easy, streamlined install process that doesn't require me to reconfigure my machine very much.

Once I have it set up, I try to run a typical "hello world" scenario. At this point, my judging criteria is:

How quickly I could create a working example, however small
See if I can do something slightly more sophisticated and get the expected result
Determine if it fits my "philosophy" of how to further build upon this starting point

It's a little nebulous, but my favorite tools over the years have been determined by this method. It really allows me to try a bunch of stacks without investing too much into any one of them.

Here are some examples of great tools I've discovered through this method, and they span disciplines:

Back-end

CSS

One thing all of these tools have in common is that they have great documentation, very easy setup, or both. Also, these are all fully open-source tools, making this exercise much easier. Other factors include:

Community/popularity
Aesthetics
- Does it "feel good"?
- Attention to detail
What has been built with it already

So, my advice is to simply try a few technologies that you're trying to decide between, and not commit immediately. If you find one that feels right and you are impressed with it, do some further due diligence to make sure it can meet your future needs. Then, commit to success and start working on your project.

Why I choose Mithril.js

Joe Sweeney — Sun, 06 Oct 2019 19:41:24 +0000

These days, it's really difficult to choose a JavaScript framework to begin a new project. It would seem that React is the front-runner, but what about this revolutionary Vue thing? Should I use Angular because Google supports it, making it more appealing to large companies? But it's so much different from the original AngularJS... What about mobile development capabilities with React Native, or NativeScript? Would if React's license changes again? Should I switch?

Honestly, I find this decision-making pretty exhausting, but I also don't want to make the "wrong" choice. However, as I've learned with most things in life, I feel best when I make decisions based on my own values rather than what others purport to be the "correct" or "popular" choice. I've always felt like a little bit of a rebel, but it's only because I have specific requirements that the popular options don't fulfill. In the case of front-end frameworks, it can be quite difficult to objectively field whether a certain framework is best for my project or development style, simply because of the incredible marketing hyperbole behind each of these frameworks.

So, what would an ideal JavaScript framework look like to me?

Simple API

The fewer concepts I have to learn, the less guilty I feel about not knowing all the cool features I'm missing out on that probably aren't relevant to me anyway.

Great out-of-the-box performance

Nobody likes a slow site. And, as a developer, I don't want to have to work unreasonably hard to make a site performant. This should just be the default to start, while perhaps requiring a bit more care as the project grows.

Fast initial load

Less code in the library means saving precious bandwidth when loading it on a web page. This is especially important on mobile.

Doesn't require a build step

Many web pages on the web today are not single-page apps built with Webpack. Sometimes, I just want to throw some JS on a regular ol' web page to add a little bit of dynamic behavior.

Community support

It shouldn't be difficult to find help when I run into problems.

Encourages vanilla JavaScript

I don't believe we need to "apologize" for JavaScript by covering it up with a bunch of duplicate functionality that bloats the code and adds more overhead to our learning. I'd rather spend more time in the wonderful MDN docs learning proper JavaScript.

Interacts with other libraries easily

There is an extremely rich ecosystem of JavaScript libraries out there to help with all kinds of stuff. We shouldn't be afraid to use them if they don't have a framework-specific implementation.

So, is there a framework that satisfies all of these requirements, and more?

Well, yes, I believe there is! This would be a pretty unsatisfying article otherwise, wouldn't it?

Enter Mithril

For the last two years or so, I've quietly (or, sometimes not-so-quietly) been using Mithril in my day jobs where I had complete autonomy over the project at hand. I've used it to build tiny, internal company tools as well as a heavily-visited digital campus map for a university. I've used it both in the context of an existing PHP-rendered application without any sort of build chain, as well as a full-on single-page app with routing, ES6, hot-module reloading, and all that good stuff. It excels wonderfully in both scenarios, and it doesn't pressure anyone into a particular way of doing things.

Okay, enough soliloquy. Let's dive into some code.

This is basically the "Hello World" of Mithril:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <script src="https://cdnjs.cloudflare.com/ajax/libs/mithril/2.0.4/mithril.min.js"></script>
    <title>Hello, Dev!</title>
</head>
<body>
    <script>
        m.render(document.body, m('h1', 'Hello, Dev!'))
    </script>
</body>
</html>

While this example may not be very flashy, it is impressive how little code is needed to instantiate Mithril and render something.

Okay, let's try something a little bit more involved, if not quite common. Here is a todo list app, built with Mithril and Bulma. I'll attempt to demonstrate a complete implementation with as little code as possible:

There is a bit of code for a simple todo list, but the implementation of Mithril-specific stuff is quite low, in my opinion. There are a couple of functions for generating random IDs and finding the index of an object in an array by ID. There is also a data model for storing the todos, as well as logic for adding, deleting, completing, and uncompleting the todos. The only Mithril-specific code involves the layout and rendering of the component, which constructs a virtual DOM that outputs to HTML (similar to most of the other current major frameworks).

If you want to see an example of a Mithril app that I've built that's currently in production, check out the Montana State University digital campus map.

To sum it up, if you're happy with your existing front-end setup, just keep using that. No point switching from something you're comfortable with. But, if you are craving something a bit simpler, without giving up too many productivity benefits, I'll think you'll be quite delighted with it!

In future posts, I'll go over some of the more advanced and nitty-gritty features of Mithril. And, if any of you have more questions about the framework, comment here or in the excellent Mithril Gitter chatroom!

Forem: Joe Sweeney

Deploying a Jigsaw static site to GitHub Pages using GitHub Actions

Setup

Laravel task scheduling without cron jobs for local development

Using node-schedule

Add node-schedule to your project

Create JavaScript file for schedule code

Run the schuduler

Twilio Hackathon — Connecting the elderly to more people in their local community

What I built

How I built it

Video demo

Link to code

Introducing Podrain, a web-based, offline-capable podcast app

Introducing Podrain

App structure

Challenges

The offline problem

CORS for podcast feeds and media

Future

Switching back to a monolith

Secure authentication

Efficiently fetching data

Decoupled architecture

Testing

Final thoughts

Benefits of contributing code to your favorite open source project(s)

Getting a better in-depth understanding of the project

Feeling of empowerment

Building a stronger connection with the project community

Valuable experience in collaboration and communication

Résumé builder

Final thoughts

How to actually make your life easier with Docker

My sweet spot with Docker

Final thoughts

The Five-Minute Rule

Back-end

CSS

JS (front-end)

Build tools

Game dev

Why I choose Mithril.js

Simple API

Great out-of-the-box performance

Fast initial load

Doesn't require a build step

Community support

Encourages vanilla JavaScript

Interacts with other libraries easily

So, is there a framework that satisfies all of these requirements, and more?

Enter Mithril

Using `node-schedule`

Add `node-schedule` to your project