UPDATE! - May 13, 2021 - Glitch has made it official by publishing details of the new features on their blog (my Vue starter project was even mentioned in that post!), you can read it here.

It's 30th March, 2021, and I am about to sleep.


I take a look at my phone.

There's a new email in my inbox, with the title, "Preview a part of the new Glitch & tell us what you think!"

I think I got this feature preview email from Glitch because I had signed up for such emails when they were about to release boosted projects (Glitch projects with extra disk space, CPU and cool features, see https://glitch.com/pricing). Anyway, Glitch was launching "a refresh of our “Create Project” menu apps offerings." So for those who are unaware, Glitch had 3 starter projects from which all projects started. It's kinda obvious from the name, "starter projects".

For long, they've been the base of every Glitch projects, except for those directly imported from Git. They still are. But Glitch decided to listen to what the community had to say, and decided to create 3 more starter projects that were totally needed.

  • ~glitch-hello-website is a simple static website and reboot of the existing ~hello-webpage starter, with more SEO tags to drive people crazy
  • ~glitch-hello-react is a generated static site using React.js
  • ~glitch-hello-eleventy is a generated static site using Eleventy, a static site generator that’s great for building a blog or simple CMS

Now, there are a lot of really good community-made starter templates that work perfectly, it isn't that hard to add meta tags and set up React, and this email was about to go to Gmail Trash Central (it's an empty and scary place) when something caught my eye. Notice how two of the three new starter projects have the phrase "generated static site"? I was ecstatic.




1. feeling or expressing overwhelming happiness or joyful excitement.

Ok, so the thing is Glitch introduced static sites a few months back, where if your site does not have a package.json, glitch.json or a requirements.txt, it will be considered a static site, meaning it won't count towards your Project Hours. But that isn't entirely fair, because frameworks like Vue and React have a package.json while in development mode, but after everything is done, you end up with a static site with static files without a package.json. While it isn't impossible to set up a workflow where you can switch between production and development/a static site and a dynamic site/no package.json and package.json, it is really tough. I've tried it before, and honestly, it's not worth it. The process is slow, inefficient and time consuming.

SO I SENT AN EMAIL. I love emails. It feels professional. Although I always insert lame jokes or puns whenever I write emails to the awesome folks at Glitch.

Hi Glitch,

The new feature, where static sites are online 24/7 is really awesome!

But classifying a project as static or dynamic based on the existence of a package.json or glitch.json is kinda unfair because frameworks like Vue and React result in static websites, and so technically, they are static sites. But they also require a package.json for building files and for dependences and hence, on Glitch, they become classified as non-static projects. I know its hard to identify if a project is a Vue or React application, but maybe you could look for certain dependencies installed like the Vue package or the React package. For reference, this identifying has been done by other services like Netlify and Vercel based on your package.json.

This is a feature I would like to see in the future! And keep being an awesome platform for developers!

Have a great day,
Khaleel Gibran

Some emojis were lost while copy-pasting. Let's have a moment of silence for the lost emojis.

And I waited and I waited and I waited and I waited. Actually, I didn't have to wait that long, they replied the next day! Hooray! And then they said:

Thanks for the suggestion! I am going to pass this along to the team who worked on the static sites project to see if this can be implemented. I'm not sure when they will be able to take a look, but as soon as I get a response from them, I will let you know!

And I waited. And the next day:

Our Product team was happy that you brought this up because it is something that they have been discussing lately.

Here is an update from them to you:
As you pointed out, we do have a strict definition of static sites right now that doesn't include anything that needs to be built or compiled first, and we make that determination based on files present. However, we are thinking about how to support projects that result in static sites after being built. It doesn't share the same architecture for us on the backend so it wasn't the first step we took when launching static sites, but it's really useful to see that users like yourself are interested in it!

I hope this info helps you! If I get additional information about improvements we are making to static sites, I'll let you know!

This was good news! I knew that it was going to take some time for the Glitch team to implement this feature because they had just launched the whole Project Hours/static vs dynamic site concept.

And months later, it happened!

  • The feature is unofficially called generated static projects. Unofficial because Glitch has not yet publicly released this as a feature, other than the fact that it was used in the new starter projects.
  • You can make a project by adding a glitch field in the package.json
  • These options above gets reflected in a hidden file called .glitchdotcom.json. You can see the contents of the file by running cat .glitchdotcom.json in the terminal.
  • According to my observations, you need to manually build the files using the build command for the first time, after which Glitch will automatically build. (need to experiment further!)
  • The buildDirectory field is optional, the default build directory is build.
  • similar to static projects, development time count towards Project Hours. After 5 minutes of no edits, the container shuts down and the buildDirectory folder is served from S3 and that hosting doesn't count towards Project Hours.

If you have any more questions, you should probably ask here.

Thanks to jenn for the clarification on many aspects of this new feature!