Hey there!
You might notice that this email's gotten a fresh coat of paint; more on that in a bit!
Over the years, I've helped quite a few friends take their first steps into front-end development. One of the most common stumbling blocks is the terminal.
Most people don't know how to use a command-line, and yet every README on Github assumes that readers will understand what "run npm install our-package" means. Nobody ever takes the time to explain what the terminal is and how to use it.
Of course, there are dedicated resources for learning to use a terminal. But, here's the thing: shell languages like Bash are as complicated as any other programming language. Most of the resources I've seen go way way deeper than necessary.
If you're trying to become a React developer and have been frustrated by all the assumed terminal knowledge, this blog post is for you. I tried to focus on the critical, must-know fundamentals. There's no fluff in this one. We focus on the concepts and commands you need to know to do common development tasks, so that you can get onto the fun stuff: building user interfaces.
This is the blog post I wish I had when I was just getting started with JavaScript frameworks. Hopefully, it'll help clarify all of the terminal mysteries that everyone assumes you already understand.
Now, I do realize: this is a beginner-focused blog post, and most of the folks who receive this newsletter are further along. If you're reading this, odds are good that you're already comfortable with the terminal!
If that's the case, you probably won't learn too much in this one (though I did sprinkle in a few obscure tips and tricks!). But, I bet you have friends or colleagues who are earlier in their development journey. Please send them the link! I really think they'll benefit from reading it.
Alright. Let's talk about this new email layout.
If you've ever tried to create HTML-based emails, you know it's a huuuuge pain. It's hard to overstate how ridiculously painful it is.
HTML emails rely heavily on the <table> tag for layouts, a method that was already well on its way towards becoming obsolete on the web when I started tinkering with HTML/CSS, back in 2007 (!!). All of the wonderful modern CSS you know and love, things like CSS Grid and even Flexbox, aren't supported in HTML emails.
In other words, writing CSS for emails is like writing CSS For the web 20 years ago. Except there aren't 3 or 4 or 5 browsers to support; there are dozens of email clients. And none of them are really working to support modern CSS.
Caniemail, the email version of caniuse, helps us track CSS support across modern email clients. Outlook, one of the more popular options, only scores about 25%. 😬
For the past few years, I've had a pretty laissez-faire attitude about the whole thing. While I did create a table-based layout that would look good on most clients, I just didn't have the energy to hunt down every edge-case on every email client. And so my lazy solution has been to link to the web version of the post at the top of each email. If the layout's all borked up, at least there's a link to read it on the web. 😅
And so, I've spent the past week rebuilding my email system from the ground up. The core technology I'm using is MJML, a framework built specifically for HTML emails. It provides a set of components that compile to email-friendly table-based HTML.
I'm also relying on some additional tools, including mjml-react (React bindings for MJML), MDX (for a nice Markdown-like authoring experience), and Next.js (to compile and serve the raw HTML).
Would you be interested in hearing about how this whole flow works? I haven't seen many other resources out there, and there were some tricky things I had to figure out! Let me know if this is something you're keen on learning more about.
(And please do let me know if this email isn't rendering properly for you! I'm realllyyyyy hoping MJML is as universally-supported as it claims.)
On the personal side, I'm happy to share that after ~2 years, I'm no longer working from home! I've purchased a small condo I'll be using as a secondary residence / personal office.
As I've shared before, remote work isn't synonymous with working from home. Remote work means having the freedom to choose your ideal work environment, whether that's from your couch, from the local library, from a co-working space, or from a dedicated workspace.
Granted, over the past couple of years, remote work has pretty much meant working from home. The pandemic isn't over yet, but I'm hopeful that we're about to enter a new era of remote work, one in which we're all able to customize our work environment so that it's perfect for us.
It's spring-time where I live, and it's so nice to be able to go outside without a heavy coat. If you're in the northern hemisphere, I hope you're having a delightful spring. 🌻
Until next time!
-Josh