DEV Community: Melissa McEwen

The best classless CSS frameworks in 2021

Melissa McEwen — Tue, 09 Mar 2021 00:13:36 +0000

Ever need style for some plain HTML? Then classless CSS frameworks are for you. I started using these when working on code examples for our Best Date Libraries post. The plain HTML examples looked distractingly ugly, but writing I didn't want to write any CSS. I found Sakura, a classless CSS framework. With just one CSS file my examples looked far more polished. And I didn't have to change the HTML at all.

What is a classless CSS framework?

Classless CSS differs from other types of CSS frameworks that target classes. For example, with Bootstrap (the most popular traditional CSS framework) you need to add class="blockquote" to your blockquotes to style them. Or WYSIWYG.css, a "class-light" CSS framework. WYSIWYG.css targets basic HTML elements, but only within a container with class="wysiwyg".

Who are classless CSS frameworks for?

Classless CSS frameworks are ideal for demos, proofs of concept, minimalist sites, and code examples.

Beyond that, their lack of precision limits design options and can override other CSS, making a larger site design look weird. Furthermore they don't offer much contextual flexibility. For example let's say you want to have headers look different when used on a sidebar vs. the body of a blog post. It's also almost impossible to have a layout beyond a basic single column without using classes.

Testing classless CSS frameworks

We picked eleven classless CSS frameworks to test in Codepen. Want to see what they look like when applied to the same page? Toggle them in our Classless CSS Tester Codepen:

Our favorite: Sakura

I ended up picking Sakura for use in examples in Codepen. Sakura covers most HTML elements I use in examples such as headers. Most importantly, Sakura makes HTML look tidy and readable, but isn't distracting.

For prototyping: MVP.css

If you're building a prototype, MVP.css is a great choice. MVP.css allows you to construct basic user interfaces with plain HTML. If you're at a hackathon or just hacking a side project, check this one out:

For bloggers: holiday.css

If you're building a simple blog and want basic style, holiday.css looks clean and styles the semantic elements commonly used in writing. Plus it has a cool dark mode!

What to look for in a classless CSS framework

Readability

Ideally, a classless CSS framework should make text much more readable. Some things to look for are:

Spacing: Does the framework use spacing to improve readability and convey hierarchy?
Fonts: Does the framework use fonts designed for the web? For example Why You Don’t Use Garamond on The Web explains why some fonts aren't suited for use on websites. Are the font sizes readable and do they have a clear hierarchy? That can be complicated to judge but I like the pointers laid out in The Responsive Website Font Size Guidelines .
Color contrast: Color can make a difference in how legible text is. Check out the accessibility section for more on this.

Coverage

It's worth thinking about what HTML elements you want to style. Not all frameworks style the same elements. When I write blog posts I like to use the <aside> element for tips and other tangential information. Many classless CSS frameworks do not style asides, which makes them look like part of a paragraph. On the flip side, there may be elements you do not want to style. MVP.css styles <section> elements which might be confusing on a blog.

Size

Most classless CSS frameworks are small, ranging from 1.3 to 5.1 kb. The exception is those that use custom fonts. Classless css frameworks that use @import for custom fonts are usually around 200-600kb. You have to decide whether those fonts are worth their size.

Theming

A classless CSS framework can be as simple as a single CSS file, but others use tools like SASS that output CSS as part of a build process. The advantage of the more complex tool chain is the ability to "theme" the final output. For example, with Sakura you can create your own theme by changing variables in a SASS file. Holiday.css has both light and dark modes and switches based on prefers-color-scheme.

Accessibility

Is CSS really part of accessibility? Definitely! Let's take the humble <a> element for example. If only styled with color, colorblind users may not be able to distinguish links from regular text. WebAIM's Links and Hypertext guidance recommends styling links with an underline. And if links aren't underlined, have higher contrast and hover effects. For further reading on this topic see the WebAIM Contrast and Color Accessibility guidelines.

Some other common CSS accessibility issues:

Color contrast is too low — for example light blue text against a slightly less light blue background.
User interface elements difficult to use — such as buttons that are too tiny to click.

Style

Do you want to go for a minimal look or a more stylish sparkle ✨? Most classless CSS frameworks are minimalist. But there are a few with a distinctive style like Tufte.css, based on the work of data visualization pioneer Edward Tufte.

Resources

How to create a horrible screenshot

Melissa McEwen — Fri, 19 Feb 2021 02:59:40 +0000

If you write about web development you probably use screenshots. Whether it's for tutorials or documentation, a good screenshot can help guide readers. A bad screenshot can confuse them. I challenged myself recently to create the WORST screenshot just to think more about what makes a screenshot bad.

I gave myself a caption to make a screenshot for. I chose "Start writing a new post on Dev.to". Here is my work of "art":

It has several key horrible elements:

EXTREME JPEG compression so it's really blurry and hard to read.
Tons of distracting clutter. I made sure to get every part of my screen and especially those juicy distracting browser elements like my bookmark bar and downloads.
Infuriatingly off-center from the desktop in the background.
Poorly drawn arrow in a color that doesn't stand out from the background

Then I tried to create a "good" version:

This is a lot less fun but it has:

Higher image quality.
I used Cleanshot's "highlight" feature to deemphasize the other elements of the page.
A big bold arrow in a contrasting color.
Zoomed in (using browser zoom) but not so far in that it deforms the user interface.

Then I thought about how I could make ANOTHER bad screenshot. But include elements of the "good" one:

Zoomed in so far you see a user interface that most users would never see, I.E., it no longer looks like the Dev.to homepage.
Pixel blur, which is a feature that seems kind of cool but confuses some users. I'll never forget the time I made a tutorial for my dad that used pixel blur and he thought the pixel blur was covering up things that were "censored" like bad words 💀

For professional documentation you probably want to go with content skeleton-style placeholders. These are illustrations where the elements are simplified so it's still recognizable as the user interface but much easier to understand. As far as I know you'd have to hand-draw or hand-code some CSS (unless there is some solution I don't know about).

Anyway, some links that inspired this post:

If you have any tips for making the "bad" one worse or the "good" one better, let me know in the comments.

The best JavaScript date libraries in 2021

Melissa McEwen — Tue, 16 Feb 2021 15:28:33 +0000

Wrangling dates and times in JavaScript can be a headache. JavaScript date libraries provide user-friendly APIs and useful utilities that alleviate some of that pain. But with so many options how do you pick the best one? In this post we delve into the world of JavaScript date libraries to help you choose. Our top pick, date-fns, delivers the best feature set combined with an elegant modular architecture.

Our picks

Best overall: date-fns

date-fns offers great documentation, functional architecture, and utilities that handle almost any task you can think of. If dates are a critical concern for your JavaScript application, use date-fns. Each feature has clear documentation written in ESM (ES Modules) for the browser. Logical and consistent function names encourage readable code. A modular architecture allows build tools to trim away unused code for a slimmer final build.

Best for time zones: Luxon

If time zones or localization are your primary concern, we recommend Luxon. Luxon leverages JavaScript's Intl for speed and slimness while providing what Intl doesn't: an immutable user-friendly API. Concise, well-written documentation eases the learning curve for getting started.

Best minimalist option: Day.js

For basic handling of dates, Day.js is a minimalist library that offers an excellent API without much overhead. While Day.js has fewer features than Luxon or date-fns, it's much smaller in size.

The Research

When to use a JavaScript date library
Our previous pick: Moment.js
How we picked
Our picks in detail
- Date-fns
- Day.js
- Luxon
Other JavaScript date libraries
Useful Resources

When to use a JavaScript date library

Why not just use JavaScript's built-in Date object? A good JavaScript date library provides a clear advantage over JavaScript's Date in several ways: immutability, parsing, and time zones. In addition, JavaScript date libraries offer useful utilities for date manipulation and formatting, which can save developers time and energy.

ℹ️ Maggie Pint's blog post Fixing JavaScript Date describes how Javascript's Date was based on a Java (nope, not a typo) API from the 1990s. That Java API is long gone from Java but its problems live on in JavaScript's Date.

JavaScript's Date is mutable, which can lead to unintentional bugs. Let's say you create a Date object named currentTime. You display it on top of the website. Another developer comes in and wants to create a widget that displays next weeks events. They use currentTime.setDate(currentTime.getDate() + 7) at the top to the widget to display next week's date. However it also changes the date in the header! Oops. With an immutable date library, adding a week would create a new instance so the original would not change.

While Date has a parse method, MDN documentation for Date's dateString notes that usage is "strongly discouraged." An excellent answer in the Stack Exchange question Why does Date.parse give incorrect results? describes in detail differences in formatting standards and browsers lead to inconsistent and unreliable results. If you need to parse, a date library is a must.

ℹ️ UTC is enough for everyone..right? is an incredible interactive presentation by Zach Holman on how dates work in programming

Time zones are another major frustration. Date in the browser always represents the local system date stored as milliseconds since January 1st, 1970 in UTC. A Date can rendered as a string in a different time zone using Intl, but the Date itself is always the local system time.

Date also lacks utilities for common tasks like creating human-readable relative dates. Using library utilities for such tasks can save a lot of time.

ℹ️ TC39, the major JavaScript standard's committee, is working on a new modern API called Temporal (see the proposal here) that solves all of the above issues. The Future of Date and Time in JavaScript by Christofer Eliasson is an excellent read of the history behind Temporal and what it means for JavaScript.

In the meantime, be aware of the limitations of Date and use a library when you need one.

Our previous pick: Moment.js

For a long time Moment.js was king of the JavaScript date libraries, but in 2020 Moment.js's maintainers published a Project Status announcing they consider Moment.js a legacy project.

The maintainers argued that there was no way to refactor Moment.js to meet the demands of modern JavaScript development such as immutability and tree shaking. Lighthouse (Chrome's built-in auditing tool) warns against using Moment because of its large size (329 kb).

For these reasons, we do not include it as one of our recommended picks. If you are looking for a replacement to Moment.js that closely matches its API, try Day.js.

How we picked

We looked at data from Skypack and NPM trends to identity the most popular and trending libraries and evaluated them against these core criteria:

Browser-friendly: We evaluated JavaScript date libraries for use directly by the browser rather than the Node.js backend.
Great documentation: Users look to this to implement the library correctly. We looked at the parts the facilitate this process: organization, search, examples, and the individual pages relating to the methods we tested.
Modularity + Tree shaking: Modular architecture allows you to shrink your library size by "tree-shaking" out any library code you're not using. Common build tools capable of tree-shaking include Webpack, Snowpack and Rollup.
Features: Feature-richness was just one factor. We also considered whether a library was especially good at certain tasks.
Performance: Measuring performance gives us a clue at how fast each library performs common operations. This usually isn't noticeable but in large, complex apps can cause lag.
Size: One of the biggest problems people had with Moment.js was size. A large library can substantially increase page load times.
Anti-bug features: Immutability, readability, and informative error messages can help prevent bugs. When code is readable, you can learn a lot about what it does by reading it. Format, syntax, and naming conventions can make all the difference in readability.

How we tested

When evaluating each library we made a CodePen using Skypack. We attempted to pick out common use cases that illustrate differences between libraries:

Rendering the current date & time
Rendering the current date using a custom format
Modifying a date to add/remove time
Working with timezones
Parsing arbitrary date strings

First we implemented these cases using JavaScript's Date:

We wrote up examples for performance testing on perf.link and all of the tests and code are available in the Date/time performance examples GitHub repository. If you have a specific use-case, you can modify one of the provided examples. JavaScript date libraries contain hundreds of methods and features that we couldn't test them all. Instead, we opted to test the same methods demonstrated in our Codepens.

A chart of the performance data is also available on CodePen. The data doesn't indicate a clear advantage for any one library. Each JavaScript date library implements different features differently, so that's not surprising.

⏱ For other performance comparisons see

Why you shouldn't use Moment.js...

You don't (may not) need Moment.js

The sizes listed on each review are based on loading via the Skypack CDN. If you're using a build tool to tree-shake and the library is tree-shakable (like date-fns), the size will depend on what parts you use. For evaluating libraries with tree-shaking we recommend Bundlephobia.

A caveat to our testing is we did not consider back-end Node.js use. Many JavaScript date libraries rely on browser APIs so may not work correctly on the back-end.

Other cases to test

Depending on your needs there are lots of other tests you could do. If you'd like to test other features not covered here, you can make changes to any of the examples in our embedded Codepens or CodePen date collection.

For example:

Does it let us know if we have an invalid date when we pass in invalid items? For example moment(undefined) behaves like moment() and doesn't output an error, which could lead to bugs.
How well does it handle different languages and locales?
Can it render relative dates (like "4 days ago")? Can it do this in different languages?
Does it work in older browsers?

Our picks in detail

Date-fns

Size: 58.9 kb (tree-shakable)

date-fns is a pleasure to use, offering all the benefits of a modular architecture and covering almost any date use case. Our example shows the power of good naming and syntax in conveying information. Code like add(now, {days: 7}) is straightforward to understand even if you're unfamiliar with date-fns.

To get the most out of date-fns's modular architecture, use a tree-shaking build tool (see our criteria section) and import only the features you need:

import { format, add, getHours, parse } from "https://cdn.skypack.dev/date-fns@2.16.1";

In the example above, a tree-shaking build tool would remove all code from date-fns that's not used in format, add, getHours, or parse. The final build would be much slimmer. Still at 58.9kb for the whole package, it's not giant in the first place.

date-fns doesn't package a browser build for NPM (see the related GitHub issue) and therefore only works on CDNs that transform for the browser like Skypack and ESM.run. However, documentation has examples labeled for the browser as both ESM(ES Modules) and ES2015. This ensures developers don't get confused trying to run Node.js backend code in the browser.

Limitations

Although we liked almost everything about date-fns, it is not for everyone. For starters, date-fns seems geared towards experienced developers working with a professional tool chain. Working without a build tool, the tree-shaking advantage disappears.

Note that our CodePen example starts with a const now = new Date(), which is the default JavaScript Date object. As noted in our Date section a Date is always the current system's time zone. date-fns has a separate library for working with time zones using helper functions. We found the documentation and examples for these helper functions less consistent than the main date-fns. Our resulting code is less readable than the rest of the examples. Our time-zone example for date-fns is 4 lines of code, compared to 1 for Luxon.

Another quirk we encountered was if you Google "date-fns parse" the top results take you to the v2.0.0-alpha docs for parse, which no longer work (the current version is 2.16). We found ourselves using Google because the documentation's built-in search seems to search only title and descriptions of sub-pages. The information architecture of the menu could also use improvement, as we would it overwhelmingly long. On occasion, a modal advertising "Get awesome JavaScript jobs to your email" covered the menu's bottom.

The hardest part of implementing date-fns Codepen examples was parsing, since they use different format tokens from other libraries. Furthermore, some tokens are not compatible with other tokens and the compatibility table is a Google doc that is hard to read.

Day.js

Size: 4kb

If Date fulfills almost all your needs but you don't want to deal with its downsides, Day.js is a great choice. Day.js's small size makes it ideal for build-tool free environments like CodePen and plain JS/HTML/CSS projects. If you're forced to support older browsers, Day.js 's Readme says it supports IE as far back as IE 7, though we did not test these capabilities.

The Day.js documentation claims "If you use Moment.js, you already know how to use Day.js", which would make migrating easier. You can see direct comparisons at the excellent You don't (may not) need Moment.js. The code in our example CodePen is readable with the exception of the parsing and time zone cases.

A well-organized menu helped us find what we need in the Day.js documentation. In addition the documentation search gives great results organized by type. We liked that most documentation pages have example code.

Limitations

Like date-fns, Day.js builds on top of JavaScript's Date, so time zone support requires another library. But unlike date-fns, Day.js relies on a plugin system that we did not find intuitive. You not only need to import the plugin but you also need to enable it by running dayjs.extend(plugin_name).

There is a stark contrast in our CodePen example between the time zone example and the other examples. The time zone example is much less readable and you'll also notice we commented it out. That's because it gave us incorrect results. It could be because our example time zone is an edge case or we did something wrong, but we attempted to follow the documentation. We recommend Luxon instead if you need to deal with time zones.

We encountered a few minor issues in the docs. The documentation does not contain any ESM (Es Modules) examples. This is especially apparent in the documentation for loading plugins in the browser, which recommends loading via script tag and then extending via the window global. In general for readability and browser compatibility, we prefer to avoid globals.

Unlike the other libraries you don't indicate a format with tokens when parsing. This worked fine in our CodePen but we wonder how correctly it would handle ambiguous formats. We felt the documentation could use more examples, specifically the parsing page. It took us a minute to realize parsing isn't its own method: you use dayjs() and pass in a string. Unfortunately this syntax makes the code less understandable at a glance.

Luxon

Size: 29.5kb

If time zones are high on your list of concerns, go with Luxon. Dealing with time zones is never fun, so it's nice to use a library where it just works. Most date libraries don't have a built-in time-zone support because adding a time zone database is complex and adds a lot of weight to the final size. To get around this problem, Luxon hacks into JavaScript's Intl API, which most browsers support. It's the only JavaScript date library we evaluated that does not extend Date, instead using its own DateTime class. In our experience this makes working with time zones less bug-prone.

Luxon's creator Isaac Cambron is a Moment.js maintainer. In Why does Luxon exist he says "Luxon started because I had a bunch of ideas on how to improve Moment but kept finding Moment wasn't a good codebase to explore them with."

Luxon's documentation is divided up into a Manual and Reference. Since the more technical API documentation is in the Reference, the Manual is much more readable. Most importantly the Manual is well-written and organized into clear sections, with browser-friendly install instructions for ESM (ES Modules). The resulting code in our CodePen example is remarkably readable, particularly for the time zone case.

ℹ️ "Can't we just get rid of time zones?" A common developer refrain, usually after dealing with a time zone related bug. So You Want To Abolish Time Zones is a great read on why that's not a panacea.

Limitations

We recommend date-fns for date dependent applications because compared to Luxon it has a larger feature set and is tree-shakable. If feature set is not a major concern, Day.js is a better pick because it's ~7 times smaller than Luxon (29.5kb for Luxon vs. 4kb for Day.js). Except for time zones, Luxon doesn't offer a clear advantage.

We noted above that Luxon relies on Intl and that most browsers support it, but this doesn't include older browsers. A polyfill is available, but this will increase the complexity and size of using Luxon.

A minor quibble is Luxon's documentation search doesn't seem to index the entire text.

Other JavaScript date libraries

Here are two interesting JavaScript date libraries that we didn't have time to evaluate:

Useful Resources

Experiments with code: drawing with Rough.js

Melissa McEwen — Sun, 07 Feb 2021 05:09:02 +0000

One of the top reasons I never blog is because I always feel obligated to make images for my blog posts. And then I spend too much time making images. I decided to generate one using JavaScript. It turned out super weird looking but it was fun to make.

Anyway, I used Rough.js in Codepen using Skypack. Rough.js is a nifty library for making canvas and svg graphics with a hand-drawn appearance.

I started with a picture from a vintage cookbook (James Beard's Fireside Cookbook). I added a rough polygon for a background and then some circles as decoration.

It was pretty fun experimenting with different options even if some were pretty hilariously ugly. I call this one "diseased cookies":

Finally I used the regular Canvas browser API to add some text.

If you'd like to play around with it, here is the CodePen I used:

Shift Shift Forward: Incidents

Melissa McEwen — Thu, 14 May 2020 16:22:22 +0000

Shift Shift Forward is a podcast that showcases everything that makes Glitch the best place to create on the web. Subscribe on Apple Podcasts, Breaker, Google Podcasts, Overcast, Pocket Casts, RSS, Spotify, Stitcher

We’ve all experienced it before -- you go to your favorite website, but it’s not loading. Or you try clicking on a link to complete a transaction, but your browser times out and you get an error message. It can be frustrating to deal with outages and similar issues from a user perspective, but let’s see what it looks like from the other side. What happens when these incidents occur, and what does it take to get everything running smoothly again?

On this episode, we look at incidents from three different angles: infrastructure, support, and leadership. Mads Hartmann, Cori Schlegel, Antoinette Smith, and Emmett Walsh take us through how their team fixes outages and other issues, while senior support engineer Tasha Hewett shows us how she gracefully handles support issues, and we end things off with a few words from our CEO, Anil Dash.

Looking for bonus content? Our app collection for this episode is where it's at, including links to Glitch apps, profiles, articles, and other information mentioned in this episode!

Executive Producers: Maurice Cherry, Keisha "TK" Dutes

Editor: Brittani Brown

Engineer: Keisha "TK" Dutes

Mixing: C.

Transcript

Jacky Alciné:

This is Shift Shift Forward, a new podcast for Glitch that showcases everything that makes Glitch the best place to create on the web. I'm Jacky Alciné and I work in a platform team. In this episode, we're taking a look at what happens when websites go down, including ours. We talked to Tasha Hewett, our senior support engineer, and learn what it's like communicating information to users during an outage or incident. Later, we hear from our CEO Anil Dash, who gives us thoughts on these issues from a leadership perspective. But first, TK sat down with some members of infrastructure team. They're the ones who not only get notified first when site issues happen, but also help identify and fix those issues to get things back on track.

[SEGMENT 1]

Mads Hartmann:

My name is Mads Hartmann and I'm a site reliability engineer at Glitch.

Emmett Walsh:

My name is Emmett Walsh and I'm a site reliability engineer at Glitch.

Cori Schlegel:

My name is Cori Schlagel and I'm a site reliability engineer at Glitch.

Antoinette Smith:

My name is Antoinette Smith and I'm the engineering manager of the infrastructure team at Glitch.

Keisha "TK" Dutes:

What is the process of response for when an incident happens?

Antoinette Smith:

It really depends. When an incident occurs, typically, if it's something that we have an alert for, then whoever the person who is assigned to feed the pager holder is the first person that it gets alerted and that handles it.

Keisha "TK" Dutes:

About the pager, is there a literal pager that goes off or an email notification?

Antoinette Smith:

There is no literal pager. There's a site called PagerDuty and everyone has an account on PagerDuty. And then, you can download the PagerDuty app or it'll go to your email. It'll also go to our Slack channels, but no physical pagers.

Emmett Walsh:

When the page first goes off, I think maybe the most uncomfortable experience is if you're getting woken up three in the morning, I would say, my first response is just pure confusion. I don't know what's happening. It's happened before. You get called by PagerDuty. You have to answer the call to acknowledge it. It's happened before. I actually can't remember what a phone is or how to answer it for the first 10 seconds. Normally, it's just complete debilitation. And then shortly after that, it is normally cases like, "Oh, God, is this a bad one or is it a good one?" Because you don't really know until you get logged onto your computer, so it can be a minute or two of mounting trepidation where you're like, "Oh, is it going to be a sticky one or not?" Until eventually, you get stuck into it. And then, you very quickly try and figure out what the scope of the impact is. Is it something that's really urgent? Is it something that you can snooze both figuratively and literally, or is it something where you need to call in the cavalry and get more support?

Keisha "TK" Dutes:

What's the difference between a good one and a bad one? What's sticky? What's snoozable?

Emmett Walsh:

The kind of page I see and I'll feel relief is one that is narrow in scope, I understand it really well, and I've seen it before. It's a bit annoying that I'm being woken up to deal with something that we know is a problem, but we haven't had a chance to do a more automated fix. But, at least I know exactly what to do and I know I'll be able to get back to sleep very soon. A scary one is one where everything's down, so all users are affected and I don't know why. It's novel, it's unfamiliar, the signals I'm getting from it are confusing. We have different ways of measuring how things are doing. I think that's the case where it's a bit of a tricky one.

Cori Schlegel:

Once you get to the point where you know what the problem is and at least a possible solution, a candidate is something that we can try to resolve things. In some cases, it's still going to be hours and hours before we can recover. That's a little dread-inducing, right? Even if you're confident that you can fix it, but you're looking forward to the other eight hours of monitoring things and restarting services or restarting the hosts, restarting servers, which is one of the things that takes a long time at Glitch. We have a lot of servers. If something affects all of the servers that are serving user projects, that's a thousand servers that we have to recycle. We can't do it quickly. We can only do, I don't know what the rate is, but a few hundred an hour, so that's a 10-hour, an eight or 10-hour outage if it takes us that long to get to basically restart or recreate every single server that's serving a user project. Those make for very, very long days.

Keisha "TK" Dutes:

There's several different time zones across the team, so how do you all manage that? I'll go to you, Mads. When you're receiving the page, are you eating a sandwich or sleeping or what?

Mads Hartmann:

Sometimes, I'm definitely eating a sandwich when I get a page. The way that we have set it up at Glitch is that we have working hours coverage. That means I will take the page during my normal working hours, which is nice because it means that the Americans can sleep a little longer and hopefully don't get interrupted. But, we also have another schedule, which is primary. For that, I am on call at night or in the morning and for all the hours in a day for a week. That might wake me up. Everybody who's on the rotation has a primary like that where they will have to cover the night-time shift as well.

Keisha "TK" Dutes:

How does each person know their role in fixing the incident?

Mads Hartmann:

The way that we have it set up is that there is an initial person who will get the page and it's that person's responsibility to escalate if necessary. That person might initially have a look at it and see if they can fix the problem themselves and go back to sleep or back to work. If they can't, then they can escalate to the secondary on-call. If that person, when that person joins, they'll try to fix it together. If that doesn't happen, you start calling in the cavalry and just pinging everybody and trying to get as many people in who might be able to help.

Cori Schlegel:

There are some cases where even the working hours on-call and the primary on-call and the secondary on-call might all -- some of whom may be the same person occasionally -- will get on together at the same time and they'll be able to isolate where the problem is, but they're not a person who is equipped to fix it. And so, that's when we'll interrupt somebody or get somebody else on a different team, often, out of bed or out of whatever zone they happen to be in to join in and try to figure out what the best way to fix the problem is.

Emmett Walsh:

When we decide who to call, if you're the person who picks up the page first, things we have intention, we don't want to interrupt people who don't necessarily need to be interrupted because we want to keep shipping new features and bug fixes against the very massive concern. If it's the outage that users are being impacted by, then that's a pretty high priority. Normally, we will prioritize getting people off their normal work to address those things at least when we're trying to understand what's going on and maybe all the way through to resolution.

Keisha "TK" Dutes:

In this moment, you're fixing it and it's taking all day. How are you feeling?

Cori Schlegel:

How you feel really depends on what kind of incident and what phase of the incident. When you're in the nobody-can-access-Glitch state and nobody's projects are running because those are two different things. There's at least three different things. Nobody can actually create an account or create a new project. Nobody can edit their existing projects. Then the third type is the projects that everyone has already created. None of those are running. It's kind of three different categories, at least three different categories. When you don't know what's going on and everybody's affected in any one of those categories, that is fear-inducing and stress-inducing. Panic-inducing maybe is the right phrase, at least for me.

Cori Schlegel:

Once you've sort of figured it out or at least you have a little bit of a direction to go, then it can be a little...You might know that it's going to take you awhile to figure it out. But at least you have a pathway and you can feel a little more confident. There's still a lot of pressure. We need to try to fix this as fast as possible, but it's not panicky. It's just "Let's just see how we can do this quickly" rather than "I have no idea what to do", which is that those are the ones that it's...especially at 3:00 AM. I have no idea. I don't even know where I am because it's 3:00 AM. I also have no idea what's going on.

Mads Hartmann:

To me, at least, it is like you're feeling stressed throughout the whole thing, but it can also be quite fun. What you're doing during this incident response is you're trying to figure out what's wrong with the system. That means you're coming up with hypotheses of what might be wrong. Then you're trying to prove or disprove them together with the team. That is extremely challenging and extremely fun for the most of it, I think.

Mads Hartmann:

It's also where you learn a ton of stuff about your systems. You learn more about your systems when they're broke than when they're working just fine. I think that part is really fun and can be very rewarding. Finally, once you've gone through the whole incident and you figure out what's actually wrong with the systems and you fix it, then you're done. That can be extremely fulfilling. I think, at that moment, I'm feeling at least always extremely proud of the team that worked on the incident and proud of myself for dealing with it without breaking down. I think that is what makes it in the end worthwhile. Being on the on-call rotation is that it's not just threat and stress. It can also be very fulfilling and challenging and fun and a great way to bond with your teammates who are in it with you if you're trying to fix the systems.

Keisha "TK" Dutes:

How does the user know that the incident has been resolved?

Antoinette Smith:

Well, what's really helpful is more recently we have a support team. I mean, we've always had a support team, but we haven't had a support team that was actively involved in our incidents. That's been a process change over the past few months. We have a support team and when an incident occurs, they'll update status page at IO so that people will know that Glitch is down or some part of Glitch is down. They also handle communicating with people on social media, with people in our forums. They are part of handling the incident and their major task is making sure that people outside of our team and people that are the users that are interacting with Glitch know what's going on. Once things are resolved, once our team is like, "Oh cool, this is done. Things are looking good," then they say, "Okay, this is resolved." They let everybody know.

Emmett Walsh:

Maybe I could talk more generally about the process things.

Emmett Walsh:

When we have an outage or some dropping function out at Glitch, it's not over when we get things recovered again. The job isn't done. Afterwards, we have a follow-up process. We go through an instant retrospective. We first try as best we can to understand what happened. Sometimes we'll have a really good idea in the middle of an incident. Sometimes we'll never quite get to the bottom of it. Either way, we try to figure out the best we can. Then we get together everyone involved or people who are interested, who might have domain expertise, even if they weren't involved. We'll discuss what happened. We'll try and pick out things that went well in how we dealt with the incident. Be that from how we noticed it to how we dealt with it in the moment to how we communicated about it.

Emmett Walsh:

Likewise, we'll think about things that didn't go so well. Then we also think about where we just got lucky, which depending how you think about it might be a "didn't go so well", depending how cynical you're feeling. Then we'll try and come up with some actions. We try and not be hit by the same thing twice. We'll say, "Hey, in this case, the problem is the way we configure these servers." We change the configuration this way. We make sure this kind of problem won't happen again. Then we try and prioritize when we can get that work done alongside our normal work in shipping new features or trying to do maintenance reliability work.

Keisha "TK" Dutes:

Given all that each of you do on a daily basis to make sure Glitch isn't experiencing issues, running smoothly, what would you like the users to know?

Mads Hartmann:

Alright. One thing I would love the users to know is that sometimes incidents happened because we make mistakes. We ship bad code, we don't follow a process correctly, and it's totally our fault. We try to fix that as quickly as we can. Unfortunately, in other cases, people out to get us. They are trying to use Glitch in ways that is malicious, both for other sites of the incident, but also for Glitch. They might try to use Glitch to attack us or take down another site. In cases like that, it will look the same to you. Your Glitch will be down. The project will not work. But for us, it's very different. We're doing our best to also take care of those cases. It's not always easy.

Emmett Walsh:

When there's an incident and Glitch is down, I would love users to know that we really care and we really hate it when Glitch is down. We work very hard and very quickly to get it back again.

Cori Schlegel:

I guess, as far as what I'd like Glitch users to know, I'd second definitely what Emmett says. We care. We're Glitch users. When Glitch is down, it affects us as well. We do dogfood our own product. Most of us use Glitch for things that are not necessarily in our day-to-day jobs. Support has really engendered this across the board -- Glitch is pretty stable. We don't have a lot of really big incidents. I'd like for users to remember that it's unusual for Glitch, especially Glitch projects, to be down and not responsive.

Antoinette Smith:

I guess what I would like users to know during times when the site is down or some key functionality is down is that Glitch is a really small company still. Our team that are handling these incidents are very small. In addition to shipping features to make Glitch better, on top of that, the team is also handling these incidents. Everyone is working, I feel, as hard as they possibly can. We want Glitch to be stable. That's the thing that we want the most. We're getting there, but it will take us time.

Antoinette Smith:

And we're getting there, but it will take us time.

[SEGMENT 2]

Jacky Alciné:

When the website goes down, our support staff is right there on the front line. Next up is Tasha Hewett, our senior support engineer.

Tasha Hewett:

Incident response is a team effort, but more specifically, it's like being part of an orchestra because everybody has their own part to play. And while we all know what each other's role is, we might not necessarily know how they physically play their part. So we have to sit back and let everyone play their own instrument. You have to leave alone the people who are fixing the actual issue, let them do their thing, while still paying careful attention to what's going on and then playing your part when it's your turn.

Tasha Hewett:

So basically what that turns into for me is a whole lot of lurking and slack, just watching the wheels turning, the suggestions for how we're going to fix it come up, and letting the engineers who are responding do their thing. And then my part in the orchestra is like the gong player. I don't play much, but when I do, it's very important and the audience is going to hear it. So I have to sit and wait and wait. And when is it my turn? Okay, here's my turn. I'm going to do a status update, or I'm going to post on Twitter. And it has to be at the right time and it has to be accurate. So it can be a lot of pressure, but it's an important role.

Tasha Hewett:

My name is Tasha Hewitt and my role at Glitch is senior support engineer. So that makes me responsible for making sure that users are getting the help that they need quickly and consistently, also representing the Glitch community when features, policies, and processes are being worked on. During an incident in particular, my responsibilities are making sure the community is informed about what's going on, making sure that anyone who is experiencing a problem directly related to the incident is getting the help they need. And also letting the rest of the incident response team know about any user-facing issues that they haven't already identified.

Tasha Hewett:

When I hear about an incident, I immediately am going to vet the issue that's been reported. I'm going to see if I can replicate it myself. I'm going to see how many reports are already coming in from users. Our users are really great about detecting things because they're using our site all the time and letting us know if something isn't working.

Tasha Hewett:

It is stressful because for me in particular, being the gong player, you don't want to mess up the whole orchestra. You don't want to hit that gong or send a message at the wrong time, and that can be stressful. But when incident response is going well, and when you have a really good playbook for how these things play out, you know what your part is. You have a good idea of what you need to do and when you need to do it. And when you do it well, it feels really good to be able to give that information to your users. Even if it's not what they're looking for, if we're not saying, "Hey, look, this issue is still happening. We're still looking into it. It hasn't been resolved yet." Just to be able to let them know we're there, and we're seeing what they're seeing, feels really good and makes all the pressure worthwhile.

Tasha Hewett:

Once an issue has been resolved, it's really important for support to verify that that is true. And then we need to communicate that to our users. Really important is to be honest, don't over promise anything. If we've made a mistake, for example, if we said things were resolved too soon and they weren't, we need to own up about that. We need to be transparent, because that helps you build trust between yourself and the users.

Tasha Hewett:

The really important thing is never gaslight your users. So if you're going to say things are resolved, make sure that you can say that or make sure you're prepared to say, "Whoops, that was a mistake." Because the last thing you want to do is pretend like everything's okay when your users know it isn't.

Tasha Hewett:

Users can be more disgruntled about issues depending on the severity or type of the incident. But I think it's more related to how the particular incident directly affects the user. If you have a user who is repeatedly telling you that something is wrong and we unintentionally decide it's user error or make them feel like it's user error, that can be really frustrating to them. So it's always important to pay attention to your users and listen to the things they're saying regardless. Always vet their issues. Always check with them to see if what they're seeing is something that we can see too and investigate it. When users realize that you care specifically about how they're being roadblocked by an incident, they will have more trust in you to fix it for them.

Tasha Hewett:

When an incident happens, we'll receive reports from our users via social media and also our forum and email, and the thing I want to communicate to them, and the most important thing I want them to know, is that we care. We feel for them, we know it stinks to be in the middle of working on something and suddenly have to stop for reasons that are out of your control, and for them to know that we are looking at it and we're not going to stop until it gets fixed. Sometimes that happens in 15 minutes. Sometimes it can take a day to really sort out, but we will not forget about it. We are going to make sure that we can get all our Glitch users back on the platform and working on the apps of their dreams, instead of wondering what the heck is going on.

[SEGMENT 3]

Jacky Alciné:

When incidents happen, it affects all parts of the company, including leadership. Now here's a word from the person at the top.

Anil Dash:

Hey everybody, I'm Anil, and I'm the CEO here at Glitch. And whenever we have any downtime, incidents or problems, it's ultimately my fault. But we always try to say that we are a blameless culture. We try not to point the fingers. And so people are very kind not to point fingers at me. But you know what? I think everybody at Glitch feels that way. If there's ever a problem, if there's ever an incident, if there's ever a downtime, I think everybody takes it so seriously and personally, because we just all feel that responsibility and that obligation to keep everything working. We love the apps that people build. We love everything people make on Glitch.

Anil Dash:

And so any minute where you can't get to it or access it or do your work or make your project is stressful. We feel it. And it's odd because everybody in tech has this issue. There's no website you've ever used, even Google, even Facebook, they have all gone down at different times. They've all fallen over some time. And so it's a universal experience, but everybody acts like it's totally outrageous. It never happens. It's really rare. It is not.

Anil Dash:

... outrageous, it never happens, it's really rare. It is not rare, and it's wild because it even can become part of the culture of a site. Like I go back in time and I look at, seven or eight years ago, Twitter used to not be able to handle its traffic load all the time.

Anil Dash:

I mean, who could blame them? They had gone from nowhere to everywhere in, like, five minutes and it's hard to keep things running. But it would be especially true when there was a big event, awards show, or a news event, or something like that. You would get this error message that had a drawing of a blue cartoon whale on it, and they called it the fail whale, that was when Twitter fell over. It was sort of like this running joke that every time you would go to check out Twitter during something important, you would get the fail whale.

Anil Dash:

I talked to people that helped fix it there and they felt really terrible about it, and the truth of it is, look, if people are, well, hooked enough on your service that they get mad when it falls down, that's probably a good sign. But you don't feel that way at the time, you feel like you're letting them down.

Anil Dash:

I think it's easy to forget that it's just humans. There's just people that are running around, probably frantically trying to keep this thing running, and that's a perspective that's easy to lose unless you really think about the human part of it.

Anil Dash:

We spent some time at Glitch trying to do that towards the end of 2019. It was a huge year for us. I think we went from a million apps on the platform to probably 5 million. I mean, it was just outrageous. We also saw the first big spam attacks, people trying to use the site to build lots of spam apps or things like that.

Anil Dash:

So it was hard. It's hard to scale anything. It's hard to grow anything. I mean, we had growing pains in every part of the company, and the technology infrastructure was no exception to that. Even though we had this incredibly brilliant tech team, you still have incidents and outages and downtime.

Anil Dash:

So I think by the end of the year, people were really feeling it. They were kind of feeling the pressure of it, and I wrote about it a little bit publicly, which was frankly kind of scary, because I wanted to make it more clear that we're just people trying our best, and that we're going to try and make everything great and bulletproof, but we're not always going to succeed.

Anil Dash:

I mean, our name, Glitch, means a problem. It means a bug. So hopefully that helps people feel more comfortable with the fact that sometimes things are going to break, and hopefully everybody who creates on Glitch sees, one, is there's people that really, really care and are really doing everything to try and make sure that everything you build is there, and works, and is fast and reliable and all that.

Anil Dash:

But also, people create on Glitch all the time and are like, "Oh, man, my code is bad, and my app broke, and ... " You know what? Us, too. It's no different. There's always somebody who's just on the other side that is trying to keep things running and make this thing work, and they really, really try, and that's inspiring.

Anil Dash:

The other part I look at is the community, and I'm like, don't worry if it's not perfect every time and it falls over sometimes, because, like I said, that happens to us, too.

Jacky Alciné:

That's it for this episode of Shift Shift Forward. Visit us online at glitch.com/ssf. Follow us on Twitter. Our Twitter handle is @glitch, and let us know what you think about this episode by using the hashtag #shiftshiftforward.

Jacky Alciné:

If you really liked the show, then subscribe to us on Apple Podcasts, Spotify, Google Podcasts, or wherever you find your favorite shows. Leave us a rating and review. Shift Shift Forward is produced by Maurice Cherry and Keisha "TK" Dutes, with editing by Brittani Brown, sound design by Keisha "TK" Dutes and mixing by C. Special thanks to the entire team at Glitch.

Jacky Alciné:

Here is what's coming up on Shift Shift Forward. We are watching a lot of movies and TV these days, and it's interesting to see how apps, websites, and other consumer tech are portrayed. Some directors set their entire production within desktop screens, mobile phones and webcam footage, and others use onscreen texting to show conversations and nonverbal interactions between characters. And yet, none of them really feel or look the like tech we actually use in our day-to-day lives. Why is that? We'll take a closer look and find out.

Automating My Deploys From GitHub to Glitch

Melissa McEwen — Tue, 21 Apr 2020 15:23:55 +0000

Programmers love automation. Anything we have to do over and over again? Automate it! One of these tasks I've been working to automate is deploying code from Github to Glitch. Here's my latest process. It's a work in progress, but check it out and let me know what you think.

Why Github to Glitch?

Glitch is a great tool for writing and testing full stack apps online. But I also love GitHub's tools for code review, especially when I'm working on a team. My ideal flow is to work on a Glitch remix, push to GitHub, review with my team, and deploy to the main Glitch project.

This is important once I've promoted a Glitch app. I don't want to edit and test Starter-Discord while there are users actively looking at it and remixing it.

My original solution was a Probot. It used the Glitch API to import the code from Github. The issue is the Glitch API isn't public. It's not at a stable point where we recommend building your own tools with it. I knew some API changes were coming down the pipeline to the endpoint I was using. Since I wouldn't be able to use it anymore, I needed a new solution.

Full warning: this is a proof of concept that uses arcane and forbidden Git knowledge. And I'm not even that good at Git. Use at your own discretion. Feedback from more knowledgeable people welcome.

Git Hooks to the rescue?

Since Glitch projects each have their own Git repo, I wondered if I could use that instead. I knew there was something called Git Hooks that could automate some action in response to repo activity. But I'd never used them before.

A couple of hours of reading and testing later, I had a working prototype that would deploy any new code into the Master branch.

But that didn't solve the GitHub part of the equation. For that I decided to try something else new: GitHub Actions. I read some docs and tried a couple before deciding on git-sync by wei. I had some random bugs mainly dealing with authentication that took me a couple of hours to figure out.

The workflow

Let's say I want to update the Dev.to handbook Glitch project. I don't want to edit it directly while people are using it, so I:

Remix it on Glitch
Make my edits and commit them to a new branch
Push the new branch to the GitHub repo
On the GitHub repo I create a PR for the new branch into master
Then my team and I review the changes
Once approved, we merge

Now here's where the automation starts

The merge triggers the Github Action
The Github Action pushes the code into the Git repo of the main Glitch app
When the Git repo of the main Glitch app receives it, that triggers the Git Hook
The Git Hook replaces all the current code with the new code

How to set it up yourself

Just a warning that this will wipe away any code in your Glitch project and replace it with the code from Github, so use with caution!

You'll need:

a "main" Glitch project the code will deploy to
a public Github repo for that project that the code will deploy from

Step 1: In the Glitch terminal

Go to the Glitch terminal
Run git config receive.denyCurrentBranch ignore
create a githook in the terminal using your favorite text editor. I used Vim so vim .git/hooks/post-receive
Put this bash script into your hook:

#!/bin/bash
unset GIT_INDEX_FILE
git --work-tree=/app  --git-dir=/app/.git checkout -f

Give your hook execution permission chmod +x .git/hooks/post-receive

Step 2: Create a GitHub secret

Head back to your Glitch project and click tools --> Git, Import, and Export
Copy Your project's Git URL: this contains an auth token so keep it secret!
Since it's a secret head to your Github repo and to the "secrets" section
Paste the whole thing into a new secret and name it glitch_git_URL

Step 3: Create a GitHub Action

Head to actions and create a new workflow from "Set up a workflow yourself"
This is the code for using the git-sync action with your secret. Replace the value in SOURCE_REPO with your https GitHub URL (something like https://github.com/glitchdotcom/devto.git).

on: 
 pull_request:
  types: [closed] 
jobs:
  repo-sync:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - name: repo-sync
      uses: wei/git-sync@v1
      env:
        SOURCE_REPO: "https://github.com/glitchdotcom/devto.git"
        SOURCE_BRANCH: "master"
        DESTINATION_REPO: ${{ secrets.glitch_git_URL }}
        DESTINATION_BRANCH: "master"
      with:
        args: $SOURCE_REPO $SOURCE_BRANCH $DESTINATION_REPO $DESTINATION_BRANCH

Step 4: Test it!

Now for the magic moment. Update your GitHub code anyway you choose. And click on Actions to see it in ...action...

The Future?

Now you know how to set up automated deploys from GitHub. If you're interested enough in this, we may set up a way to automate away all those steps. If there is anything better than automation, it's automation of automations. For now, try it out and let us know what you think!

Give your Glitch apps superpowers - keep them awake, lift rate limits, and get more memory and disk space.

Boosted Apps: Glitch Apps with more power!

Melissa McEwen — Wed, 15 Apr 2020 15:11:42 +0000

For years users have asked how they can support Glitch and how they can get more power for their apps. We've heard you loud and clear! Today we're excited to introduce Boosted Apps, which have all the goodness of Glitch but with more power. I’m going to share what Boosted Apps are and which of my apps I chose to boost.

What are Boosted Apps?

Boosted Apps are a paid subscription feature that allow you to grant up to 5 apps extra power in memory, space, rate limits, and uptime.

Keep your apps awake 24/7 (usually Glitch apps go to sleep after 5 minutes)
No rate limits, so if your app becomes super popular it can handle the traffic
Extra memory, so memory hungry apps (I’m looking at you Webpack) work faster and better
More disk space, which makes it easier to run non-Node apps on Glitch such as Python and Go. Or working with huge data sets.

What I Boosted

I was super excited to test Boosted Apps because there are a couple of apps I’ve built on Glitch to test that don’t work properly without 24/7 uptime.

The first app I boosted was my portfolio. I wanted visitors to see it right away rather than hitting a “waking up” screen. It also uses Webpack when I’m developing it and it’s much faster when boosted.

The second was my Twitter Bot, accessible-ascii, which generates an image with a caption for ascii memes. Before boosting it didn’t work most of the time. The reason why is that Twitter bots like this need to watch Twitter for replies. It couldn’t do that when asleep. Now it's watching Twitter 24/7 so it can always reply.

The third was my Discord Bot starter, which works in a similar way as the Twitter bot. It's now awake and ready to talk all the time.

The fourth was an App where I'm currently playing around with Vale, a prose linter written in Go. I needed to unpack some larger files and so it was very useful to have the extra space.

What will my fifth one be? I'm not sure yet but I'm excited to build it.

What Will You Boost?

We've seen our earliest subscribers boost everything from weather bots to crop monitoring applications. If you're interested in building and boosting apps on Glitch, go here. We'd love to see what you make so share in the comments or tweet us @glitchdevs.

Beyond the script tag: what the heck's a Bundler and why would you use one?

Melissa McEwen — Tue, 07 Apr 2020 15:22:38 +0000

Modern JavaScript development can be confusing — especially the jump from learning to include JavaScript via a <script> tag to a workflow with JavaScript tools like bundlers. I mean what even is a bundler? Why do I need to use one? Here's a quick explainer of why we bundle with some Glitch examples you can explore.

The original purpose of bundlers was to take all your development Javascript and bundle it into a single file. But these days common bundlers like Webpack, Rollup, and Parcel do much more.

So why do we use them? The "explain it like i'm five" explanation I give is "it turns the stuff you made into stuff the browser likes"

A basic example

Let's start with an example that doesn't use a bundler: hello-express on Glitch.

It has a JavaScript file public/script.js. It's served by an Express server and included on the webpage with a script tag <script src="/script.js" defer></script>. The JavaScript you write in public/script.js is the JavaScript that runs in the browser.

This works great so far, but here are some situations where a bundler might come in handy.

I want to use ✨ new JavaScript

JavaScript is an ever-evolving language. And the JavaScript version that runs in the browser is often behind the newest version of the language available. And some browsers support new JavaScript better than others.

What to do? Well, you can use the newest JavaScript and have your bundler run a compiler to translate it (called transpiling) into more browser-friendly JavaScript. The most popular one is called Babel.

For example, here is hello-parcel-simple. It uses a bundler called Parcel that by default applies Babel transforms without any configuration.

The cool thing about Parcel is we're still using that script tag, but Parcel reads it and automatically applies Babel as well as a few other things. Parcel is a great choice if you definitely don't want to configure anything.

📂 I want to organize my code into separate files and folders

script.js is fine for hello-website. It just has a single function that prints "hello world" to the console. But when you start making an entire full stack app, that file could get pretty long and complicated.

A newer JavaScript feature that can come in handy is modules. This allows you to divide your JavaScript into many different files and import as needed. While browser support for modules is growing, it's still uneven. To complicate things further there are multiple js implementations of modules with different syntax.

The art of organizing code could be an entire separate article. So let's go with a typical example. The React docs have one that's organized with each component in a separate file.

📂 components/
└ Avatar.js
└ Feed.js
└ FeedStory.js
└ Profile.js
└ ProfileHeader.js

The bundler then takes all those and puts them into one file, so that all browsers can run the code correctly.

If you'd like to use modules, you can use a bundler that's focused on converting the CommonJS syntax to browser friendly Javascript. Here's hello-rollup that uses a bundler called Rollup. It takes the main.js file and any code it imports and bundles it into one file.

🛍 🛒 I want to install and use a bunch of code I didn't write 🛒

Don't we all. Let's say you want to use React. You can include it with a script tag, but if you're running more than just basic React, managing via script tag can get complicated fast.

So let's say you have a file called button.js that uses React.

import React, { Component } from 'react';
class Button extends Component {
  render() {
    // ...
  }
}
export default Button; // Don’t forget to use export default!

Your button won't work without React. Luckily a bundler can make sure when it makes the bundle, it also includes all dependencies like React.

For example, here's a project that uses the Parcel bundler to include React:

🔨 I want to use tools like TypeScript, SASS, CSS Modules, etc.

So you want to style your new components. You could do it via the style.css file, but what if you want to use tools like SASS or CSS modules? The bundler can turn it into code the browser can understand.

Here is an example that uses the Webpack bundler to turn TypeScript to JavaScript (it's called transpiling):

🐎 I want my code to load faster!

Now our code is getting a bit complicated, so we probably want to use some tools to make our file size smaller. It would require a whole other article to really dive into these topics but here are a few strategies:

Minification: Ever looked at the browser developer tools and noticed some JavaScript was all one line? That’s minified code. And it’s smaller (and thus faster to download and parse) The original code wasn't written that way, the bundler converted it.
Tree shaking: No, not like literal trees — your code's structure. And shaking to dislodge the parts that are not connected to anything. In this case, we’re talking about unused code, so your final bundle is smaller.
Code splitting: Originally bundlers bundled your JavaScript into one file, but now some can bundle into multiple files. That way, you only serve the files needed by a particular page, browser, etc. An example is the module-nomodule pattern

🎁 Other goodies

Most bundlers can also do chores that task runners do (Grunt, Gulp). These might include copying assets or renaming files.

To bundle or not?

As you can see, bundlers can do a lot! They are an essential part of the web development process of many websites including Glitch. If you're interested in trying different bundlers, here's a collection of some of our favorite Glitch bundler apps to remix.

We're launching some exciting new features on Glitch real soon. Be the first to know.

Eight Ways We Connect Remotely at Glitch

Melissa McEwen — Wed, 18 Mar 2020 16:13:16 +0000

About half of the developers at Glitch are remote. I'm one of them, working from Chicago, so we've gotten a lot of practice trying to make sure everyone feels like they're a part of the team. As more and more companies move to working from home, we'd love to share how we connect and collaborate remotely.

🥝 Kiwihouse

Named after our mascot from back when we were Fog Creek, Kiwihouse is a remote meetup over Zoom for small talk. You might see Esteban's adorable new puppy. Or cute babies! Chat about weekend plans or fun baking experiments. Kiwihouse happens twice a week because we have employees across so many time zones.

🐠 #Aquarium channel

We use Slack as both an important collaboration tool and a virtual watercooler. #Aquarium is Slack channel for casual chat but there is also a tradition of sharing status emoji. Like a hamburger if you're having one for lunch or a rain cloud if you're starting work on a rainy day. It's not mandatory but it's a simple a fun way to stay connected in each other's daily lives.

☕️ Coffeetime

Coffeetime is an app that pairs co-workers for weekly remote video chats. It was originally a Ruby app but now is a Slack bot hosted on Glitch. I love how it pairs me with people on different teams that I don't always work with so I can get to know them.

📚 Reading clubs

We've had several remote reading clubs where we read a chapter every few weeks and discuss on Google Hangouts.

Business reading club: Shape Up: Stop Running in Circles and Ship Work that Matters
Javascript reading club: Eloquent Javascript
SRE reading club: Google's Site Reliability Engineering book

Sometimes we don't finish a book, but that's OK. Plus there are fiction book clubs too. I'm in the sci-fi one where we read The Left Hand of Darkness by Ursula K. Le Guin and Kindred by Octavia E. Butler.

📖 Library hour

Do you feel like you get more work done if you're at a library or coffeeshop? Our library hour is like a virtual library where you can work quietly on Google Hangouts and see your other coworkers doing the same.

🧣 Conference Hygge

A biweekly Google Hangout where we watch a conference talk and discuss it online. Hygge is a Danish word that roughly translates to "coziness and comfortable conviviality". Some talks we watched include:

It's almost as good as going to a real conference together.

🎁 Remote care packages

Our office admin Hosanna Tolman puts together cute and fun care packages that she sends to us. You never know what you'll get. Will it be a Glitch mug or a gummy heart Krabby Patty? We often post our reactions in Slack.

🍵 Tea club

Glitch is a rare software company because we have more tea lovers than coffee lovers! The leader of the tea club creates random pairings and we send each other our favorite tea. It's like a year round Secret Santa.

Having options helps!

All these options are well, optional. Whether you prefer to connect via Slack or over video, at Glitch you chose what's right for you. And there is always the option to "remix" any of these and create your own. For example, the Javascript reading club was created based on the SRE one.

Check out our handbook for more info on how we work remotely and our new Glitch for Remote hub!

How do you connect with your colleagues remotely? Let us know in the comments.

We're launching some exciting new features on Glitch real soon. Be the first to know.

Nevertheless, I Coded: Life after "I just don't want to be a software developer anymore"

Melissa McEwen — Fri, 06 Mar 2020 01:08:48 +0000

In 2017 I wrote I just don't want to be a software developer anymore. The post went viral and continues to get traffic. Some people have asked where I am now. Reader, I'm a software engineer.

At the time I wrote the post, I didn't feel comfortable writing all the details of my situation. I had been working at an agency and accepted a voluntary transfer to work on the "embedded" team at Google in Silicon Valley. I wasn't going to be a Google employee, but I thought it would be good for my career. I rented my apartment out, had a goodbye party, and sold/gave away a ton of stuff. I figured since housing in Silicon Valley would be expensive, I wasn't going to have much room. I got temporary housing in San Jose.

A week before the move my soon to be manager invited me to a meeting. With Uber. He was changing my placement from Google to Uber in San Francisco. San Francisco was quite a ways away from San Jose. AND this was the "strange year at Uber" year so the idea of being the only embedded dev at Uber gave me pause. They informed me that I worked for the agency so I'd work where they wanted me.

It all came to a head my last day of work. I got a Slack message telling me I needed to take a code test for Uber. It was one of those "take home" exercises that claims it takes 2 hours but actually takes 6. I asked for an extension and they demanded I do it during the PTO I was taking for my move.

I made many mistakes. I took a bad relocation package that not only required me to take PTO, but didn't specify the terms of my placement. I felt my only choice was to quit. And I did.

I started interviewing but at that point I just didn't have the morale to go through the software interview process. Software interviewing is broken and even at my best I found it demoralizing. Since I had savings I took a break. Unfortunately I was really really really depressed. And it's not easy to change your career in that situation.

I did therapy, a vocational leather work program (turns out I'm not very good at it), saw doctors and tried to figure out next steps. I found myself coding for fun quite often. Evenutally I had to accept the fact that I liked coding and it was fun for me. It's also a good career. And I didn't have any other realistic career prospects. Paying for health insurance was rapidly depleting my savings. So it was time to think about coding jobs again.

On my post someone recommended the book Developer Hegemony which I enjoyed. I wrote the author Erik Dietrich and started doing freelance developer content marketing for his company Hit Subscribe. This was a valuable experience and I found I enjoyed the intersection between writing and code.

I also built Curlsbot which ended up being somewhat popular in the curly hair community. When I prototyped it, first as a Facebook Bot, I used Glitch and fell in love it it. So when Glitch opened up a content marketing position I applied and joined the team. Their interview process was thankfully not demoralizing! Originally my title was just "Developer Content Marketer" but as the team has grown and evolved and I found myself with the engineer title again. My work is posting here sometimes and also working to show neat ways to use Glitch. So it's a very different job than I had when I wrote "I just don't want to be a software developer anymore."

My health has always affected and been affected by working in software. I got some diagnoses that explained some of my struggles: ADHD and idiopathic hypersomnia (it's narcolepsy's less well known cousin). Getting treated for those has helped a lot though finding the right medication has been ... a journey. I found some things that helped my random pain and migraines (tinted glasses, percussive massage). All these things were expensive so it helps to have a job.

I've gotten so much feedback from engineers, mostly who want to leave. And talked to a few who have left. I'm hoping by working within the industry I can help fix some of the issues that made me want to leave software engineering forever.

Some things I took away from the experience:

Work problems are structural problems that require large scale change to solve, so don't blame yourself if you can't solve them
Putting the burden on the individual to negotiate things like salary (a la "Lean In") or fix hiring practices is a losing strategy. We have to organize and exercise worker power to get fair pay and working conditions
Even if pay is good in general for engineers, unfair working conditions and inequality within a workplace can cause a lot of stress
There are other options for coders who don't want to be product engineers, though it can be hard to break into them

Migrating My Gatsby Site to Glitch

Melissa McEwen — Wed, 26 Feb 2020 15:44:30 +0000

When my computer broke I realized how much I relied on it to update my website. This spurred me to migrate my website to Glitch, where I can update it on any computer.

A couple of months ago my personal computer started making an ominous whirring sound. Being a master procrastinator I simply turned it off and put it on a bookshelf. I added "take Macbook to Apple store" to my long term todo list. But I didn't realize how it would affect other stuff I was doing.

For example, my personal site. It's Gatsby, which is a popular static site generator. Gatsby requires a "build" process which converts all the various js, media, and markdown files into a nice fast website. And I usually ran it on my personal computer.

I would be nice to have a setup where I didn't need to rely on a computer at all. Because TBH node_modules takes up a little too much room sometimes. Also what if I found an error and I could just update it on my phone? Luckily there are lots of good options for doing just that. One of them is Glitch.

Another boon is it's one step towards being able to stop paying for private hosting. I've had this card on my poor todo list for many months:

Moving my Gatsby site to Glitch

A tech portfolio is a perfect use for a static site generator, as I'm the sole content producer and I don't need a content management system. Hosting a full content management system introduces performance and security issues I don't want to deal with.

But Glitch is not my computer. Things aren't necessarily going to be the same. I do know I'll have to adapt the build process to work on Glitch.

I start by remixing the hello-express starter and importing my Github repo to Glitch. This is pretty easy.

But unfortunately the site doesn't immediately work after import. The most obvious error is when I click "show" there is nothing. I check the logs and it says there is no start command in package.json. Glitch looks for a start command when it starts up an app. So I add a Gatsby start command there. But nothing is showing.

So here are two key things about running sites like this on Glitch

Glitch sites should run on port 3000
Glitch sites look for a start script in package.json when you open them

🔑 Curious? You can learn more about this and other arcane secrets in our ⚰️🦇Glitchnomicon🕷🔮 before they appear in regular docs.

In the logs I see the site is running, but on port 9000. So I change the start command in package.json to Gatsby develop --port 3000. Now a page loads...but nothing is there.

My new error is error Generating JavaScript bundles failed. It's not a very clear error but it's yelling about something called Portfolio. I realize that I referenced a React component by that name, but the file name is portfolio. I didn't catch the error became my personal computer apparently didn't care about case sensitivity for some reason?

I change all the instances of typos like this and it builds! Yay!

Updating my Gatsby site on Glitch

Now most Gatsby instances on Glitch run gatsby develop on the command line. This gives devs on Glitch the satisfaction of seeing their changes as they develop. But as this is my main site, I don't want this. Because that means it's constantly building the site. I'm going to first make a production build of my site by opening the terminal and running gatsby build. Then I change the start command in package.json again to gatsby serve --port 3000.

My plan is when I want to update, I'll remix it, and change the start command to gatsby develop. Once I have my changes all done, I'll push to my Github repo then go to my main Glitch project and import the Github Repo. I can automate some of this but that's a subject of another post.

So to summarize to make a change:

create a remix
make changes in the remix
push the remix to the Github repo
go to the main app and pull from the Github repo.

Adding my custom domain

Now here is a chance to try out a Glitch feature I've never used before: custom domains. I'm not a DNS expert but I have a bit of experience with it, most of it bad. I fully expect to bring my site down, but it's my site and it's a Sunday afternoon so I hope no one notices?

I unfortunately make a mistake from the outset. I put the domain as melissamcewen.com. The page says "Not Found" and I spend more time than I like trying to figure out why. Our own help documentation says why this doesn't work. I need www.melissamcewen.com. Oops.

Well here are the correct steps for using a Dreamhost domain with a Glitch app:

Delete the Dreamhost hosting (because otherwise you can't add a new Cname record that Glitch gives you)
Add the custom domain www.yourcustomdomain.com to your Glitch project, you'll get a url like erweriweire.shw.io
Go to the Dreamhost DNS settings and add that as a cname record for www.yourcustomdomain.com
Now go back to the Dreamhost dashboard and click "add hosting" (I know) and instead of adding hosting, add a redirect from mysite.com to www.yourcustomdomain.com

I'm happy I have a site that should be cheaper to host and easier to update!

I immediately update some copy and fix a bug. I'm excited to migrate some more sites to Glitch.

Have you used Gatsby on Glitch? Migrated a site to Glitch? Let us know in the comments. Follow us on Dev.to to get updated on our latest posts. If you're interested in Glitch features coming soon, click here to learn more

Host your Git on Glitch with Gogs

Melissa McEwen — Wed, 22 Jan 2020 17:43:34 +0000

Can it run on Glitch? That’s the question I ask myself every time I see someone mention a cool open source software project. A month or so I saw some discussion of Gogs, a self-hosted git service. It's basically a DIY version of GitLab, Bitbucket, or Github.

The catch? Gogs runs in Go. While Glitch can support almost any language, most of our features are tailored for Node.js. So I was really curious if I could get it to run. We have a couple of sample Go projects like go-example and go-glitch-sample. To make a Glitch app use Go, you put in a special file called glitch.json. It tells Glitch that instead of running the default “npm start” when you open your project, to run whatever is defined as “start” in glitch.json

TFW errors 😱

I installed Gogs from binary¹. And it seemed to work ok. But I hit a snag. There were so many directories in the project that they made the Glitch editor load much slower. So I hid them. To do this I moved to directories with a dot prefix like like “.scripts”. Voila, my Glitch project was much faster.

Then I tried installing and I got a weird error message “Run user isn't the current user: app ->” which didn’t give me much to go on. I tried a lot of random things and nothing worked. I finally went into the gogs codebase and found the line that error came from. It expected an environment variable called USER. I changed my start command in glitch.json to set that.

Our shiny new Gogs ✨

Gogs has many of my fav git hosting features like pull request reviewing and a visual interface for exploring the code and commits.

It has some great features including:

pull requests with a visual interface
issues
wikis
forking

Try it yourself? 🌠

I wanted to make this easy to “remix” which is a Glitch term for getting your own copy. So I added some files and directories to a file called .gitignore, so you won’t get my repositories when you get your own copy. I haven’t gotten email notifications working yet, but I might try Sendgrid for that.

If you try it out let us know what you think in the comments!

Footnotes:

I had to extract the binary on my own computer because it took up a lot of space. I used the 64 bit Linux one from here.. Then uploaded to Glitch. Because binaries end up in the assets section on Glitch, I got the URL from the assets. Then I used wget asset-url. Finally I ran chmod +x asset-file