This document is an attempt to capture thoughts on the future direction of Compiler Explorer. Last updated May 2021.
A number of the open issues are to add more languages, libraries and compilers. Continuing to make it easier for others to submit PRs to add new compilers is very important. This has improved, but not all compilers are installed using the new approach. There's documentation on adding a compiler, adding a new language and adding a library.
As the site is getting used more and more, and in different ways to the initial intention, we would benefit from being able to support multiple files in compilations. That is, C++ source files, and header files compiled together, or even multiple C++ files compiled and linked together. This would let us showcase technologies like link-time optimization, or C++ modules.
A project like Compiler Explorer thrives best when many people can easily contribute. There are many languages, libraries, use-cases, and visualisations that the "core" team doesn't have experience with. In order to remain supportable and keep serving various programming communities, we need to make the project easy to work with. We can improve code quality (e.g. move to transpiling from Typescript or similar to give us stronger types), testing (increasing coverage, adding client tests), and documentation to make it easier to on-board new contributors and keep it easy to support existing code.
There's an inherent tension between the standalone, run-it-yourself version of CE and the scalable, AWS-backed CE instance. Care must be taken to keep the standalone version usable.
Above all, the priority is to keep the main CE site up, stable and dependable. That also means that URLs should live forever once they are created, which places a burden on us to keep existing compilers and libraries available forever.
Compiler Explorer will remain open-source and non-commercial. There are no plans at all to add "freemium" content. We do have a Patreon site, Github sponsors, Paypal donations, and some corporate sponsors. Funds from these source help support the cost of running the servers, and incentivize the core team. Previously our goal was to remain "ad-free", that has been relaxed slightly to allow up to three company sponsor logos visible at the top right of the screen.
- Login support. Support logging in to the site with GitHub, Google, etc. We will never force you to log in for basic features, and of course will update the Privacy Policy. I won't be selling anything to do with user info etc, either: Logging in will be purely used to make your life easier and allow you to manage things like shared settings and configuration, listing short URLs you've created (and potentially being able to remove them); and maybe being able to make user-named short URLs (e.g., "godbolt.org/u/mattgodbolt/ctad-example"). This goal is a personal pet project of Matt's.
- Multi-file support. Multiple file compilation units to open the door to seeing LTO and maybe modules. This may
include being able to use a
CMakefile to build things. - Modernising the codebase. Moving the codebase to TypeScript, or something similar that will allow us to worry less about differences between front-end and back-end code (old Javascript versions), and help us attract more people to the project.
- More compilers and libraries. Plus finishing off the last stragglers of installation.
Was: Finally tackle small screen device support.
How did we do?: a tiled, single-page read-only view was implemented. Our mobile support is about the best we could hope for given the limitations of space and our current reliance on Microsoft's Monaco editor, which doesn't support mobile at all.