We recently updated CxJS website and decided to replace our Germany-based web server with a hosting service offering CDN. Our use case is somewhat strange as CxJS website consists out of several JavaScript applications:
All applications are based on modern technologies such as CxJS itself, React, TypeScript, Babel and webpack. The output is made out of static resources only, such as images, CSS and JS files.
In case of a composite website like this, there are two options: Either to use a sub-directory for each app or to use a sub-domain. Each option has its pros and cons.
If sub-directories are used, everything gets published at once. That means, for example, that Documentation gets published even if there is only a small change in Gallery.
An additional git repository is needed to collect outputs of all applications and special routing rules are required. The good news is that you manage only one domain with one https certificate.
The hosting service is probably charging per domain, so this approach is much cheaper in the end and you can add more sub-directories along the way.
I would recommend using sub-domains if you have only one app besides homepage. It’s cleaner. Different parts can be published and controlled separately.
The downside: it’s more work for you if you’re managing certificates by yourself. If you’re using a paid service, this will also cost more.
We use Surge regularly to share stuff so it was natural to try surge first.
Surge offers a number of cool features, but the highlight is the command line interface (CLI) which allows you to publish something in a matter of seconds.
This also works well with build servers, as it’s possible to authenticate using a token.
We used Surge during development to test our Homepage and that went well. At that point, we were not sure if we’re going to use sub-directories or sub-domains.
After investigating more, we figured out that Surge would not fully support client side routing for sub-directories approach.
Surge enables top-level client-side routing using /200.html file, but this approach doesn’t work for a sub-directory, e.g. /docs/200.html.
After investigating a little more, we found Netlify. This is the most extensive service we found and probably the best choice, even if we didn’t end up using it in the end.
Netlify offers a number of great features such as Free SSL, complex redirect/rewrite rules, GitHub/GitLab build integration, SEO optimization through pre-rendering. The basic plan covers all this and costs $9/month.
What went wrong? The first problem we encountered was related to using a naked domain — cxjs.io.
Netlify recommends using a sub-domain, such as www.cxjs.io. Naked domains are also supported, but your DNS provider must support so-called ALIAS records (CNAME records on the root level).
After receiving great support from Netlify and trying out a couple of DNS providers, we ended up using CloudFlare for DNS, which is a story for itself.
The second issue is related to caching. Netlify caching is based on ETAG, which means that the browser will cache the content, but it must validate it next time it wants to use it.
This works great as you see your changes instantly after publishing and you can also rollback to a previous version. However, our needs are slightly different. We use webpack with filenames configured for long-term caching.
If contents change, the hash in the filename also changes, so there is no point to validate the content.
We also experienced performance problems with Netlify on two occasions, so we decided to explore other options.
We didn’t really use CloudFlare, but it deserves to be mentioned. Once we switched to CloudFlare DNS, all our content was suddenly served from CloudFlare CDN. It took some time to figure out how to bypass CloudFlare CDN.
In the end, we were wondering if we did the right thing. CloudFlare offers a number of amazing services designed to improve performance of your website.
We could have left our Germany-based server and use CloudFlare proxy on top of it. That would have worked well too.
In the end, we decided to use Google Firebase. Firebase provides the best mix of features we were looking for.
Some things were better with Netlify though:
I would recommend all four services mentioned here. I like the simplicity of Surge, advanced features of Netlify and advanced content serving options of Firebase.
CloudFlare is a great solution for optimizing many aspects of your (static or dynamic) website. What you end up using depends on your requirements. It’s worth mentioning that all services offer a generous free tier which you can use to experiment.
If you’re building advanced JavaScript applications, check out CxJS. Form widgets, data grid, charts, client-side routing, advanced layouts, and many other features are available out of the box.