Hey! I’ve been using Glitch for two years or so already, and I’ve been quite pushing its limits as it helped me on my work projects as well as on my personal toys. Pretty good service overall, and I love it, especially for how much it encourages people to code, share and hack! However, I did hit some walls along the way, some of which I believe could be improved upon:
-
Provide up-to-date containers: It is way too often that I’m concerned about security vulnerabilities and missing runtime features looking at my Glitch projects. For instance, projects still ship with Ubuntu 16.04.6 and NodeJS 12.0.0, software with known memory corruption and DoS exploits, as well as missing features as basic as
fs.rm. Personally, I think using the latest stable Alpine as a base for projects would be a nice idea, particularly since it can translate into storage, memory and performance improvements too. - Support runtimes other than Node.js: while Glitch projects ship with a wide variety of languages, their support is non-existent, leading to server strain, disk usage waste, broken projects and an overall value loss for Glitch as a service. Making sure the required runtimes and project build systems are up-to-date and don’t count for storage usage would go a long way. The addition of a few ones, like SBCL, would also be neat. WebAssembly/WASI on Node.js might be a potential solution/option here.
-
Provide full ICU: as soon as you find yourself wanting to deal with internationalization, you might quickly notice there’s missing language and regional information. For instance, I found out
Intl.DateTimeFormatwas unable to spit out dates properly. Currently, to fix this, you have to figure out you need to install missing ICU data and configure your project properly. At the very least, new Glitch projects could havefull-icuas a dependency, but I think it’s a better idea to include it on the project container and ship it for all languages, no custompackage.jsonrequired. - Increase storage limit for boosted projects. While the free tier is sufficient to build all kinds of small applications at 2 cores with 512MB of RAM and 200MB of storage (good stuff!), the boosted project offering increases storage to a mere 400MB, hardly enough for services used on the daily which host any kind of files. I consider users are thus not encouraged to upgrade to Pro, as the free tier can still be used for development, while deploying to a VPS is cheaper and gives you better hardware. I find this particularly appalling since storage is so plentiful on any VPS plan (try to find anything with less than 10GB!), and furthermore, compression techniques can be used to provide more to all users within the same drive/RAID space.
- Provide a Pro option to choose base system image. On top of updated images, better language support and extra space, Pro users could be given the option to deploy their own Docker images when creating a new project. These projects might be locked to Pro users only, perhaps by requiring them to be private. Storage limits should apply proportionately.
- Support autocompletion via LSP language servers. I’ve seen time and time again people I work with wanting autocompletion, as it makes it a lot easier to know what the user can do in code and how. LSP language servers are a standard way to smoothly address this – it’s as easy as implementing a JSON-RPC protocol and installing the corresponding language servers. Check SDKs listed by Microsoft here: SDKs for the LSP
- Support EditorConfig. Just a small quality of life improvement, as suggested here.
Overall, I think these are all feasible ideas that would make for a huge improvement for users overall, as well as making people like me more incentivized to pay for Pro. If you want me to create topics for each individual suggestion, please let me know. Thank you in advance!
