I tend to be pretty vocal about the problems client-side JavaScript cause from a performance perspective. We’re shipping more JavaScript than ever to our user’s devices and the result is increasingly brittle and resource-intensive experiences. It’s… not great.<\/p>\n
But that doesn’t mean I don’t like JavaScript. On the contrary, I enjoy working in JavaScript quite a bit. I just wish we were a little more selective about where<\/em> we use it.<\/p>\n <\/p>\n What excites me is when JavaScript starts reaching into parts of the technical stack where it didn’t live before. Both server-side programming and the build tool process weren’t exactly off-limits to front-end developers, but before Node.js and tools like Grunt, Gulp, webpack, and Parcel came along, they required different languages to be used. There are a lot of improvements (asset optimizations, test running, server-side adjustments necessary for improved front-end performance, etc) that required server-side languages, which meant most front-end developers tended not to go there. Now that those tools are powered by JavaScript, it’s far more likely that front-end developers can make those changes themselves.<\/p>\n Whenever we take a part of the technology stack and make it more approachable to a wider audience, we’ll start to see an explosion of creativity and innovation. That’s exactly what’s happened with build processes and bundlers. There’s been an explosion of innovation in no small part thanks to extending where front-end developers can reach.<\/p>\n That’s why I’m really excited about edge computing solutions.<\/p>\n Using a CDN is one of the most valuable things you can do to improve performance and extend your reach. But configuring that CDN and getting the maximum amount of value has been out of reach for most front-end teams.<\/p>\n That’s changing.<\/p>\n Cloudflare has Cloudflare Workers<\/a>, powered by JavaScript. Akamai has EdgeWorkers<\/a>, powered by JavaScript. Amazon has Lambda@Edge<\/a>, powered by JavaScript. Fastly just announced Compute@Edge<\/a> which is powered by WebAssembly. You can’t write JavaScript at the moment for Compute@Edge (you can write TypeScript if that’s your thing), but I suspect it’s only a matter of time before that changes.<\/p>\n Each of these tools provides a programmable layer between your CDN and the people visiting your site, enabling you to transform your content at the edge before it ever gets to your users. Critically, all of these tools make doing these things much more approachable to front-end developers.<\/p>\n For example, instead of making the client do all the work for A\/B testing, you can use any one of these tools to handle all the logic on the CDN instead, helping to make client-side A\/B testing (an annoyance of every performance-minded engineer ever) a thing of the past. Optimizely’s already using this technology to do just that for their own A\/B testing solution<\/a>.<\/p>\n Using a third-party resource? Edge computing makes it much easier to proxy those requests through your own CDN<\/a>, sparing you the extra connection cost and helping eliminate single point of failures.<\/p>\n