JavaScript Is Eating The World

JavaScript and NodeJS are single handedly eating the world of software.

Once only thought of as “hipster” technology, NodeJS is quickly becoming one of the most commonly used environments for building web applications.

This article has a list of 5 huge companies who have adopted NodeJS for use inside high traffic, high profile production projects.


  1. Tomi Engdahl says:

    JS code at the network edge. Oh, you’re still here and not running, screaming? Read on
    Cloudflare Workers offered to customize content

    Bit caching biz Cloudflare on Friday teased website publishers with the prospect of being able to run JavaScript at the edge of its content delivery network, a capability that promises performance, security, and reliability improvements.

    The outfit puts copies of customers’ websites and content at various locations around the globe to enable speedy delivery and provides an efficient path to customer servers. It also does other things, like protect against malicious web traffic.

    Making its edge points programmable would be appealing to customers, because it would allow them to run code designed to address local issues that aren’t necessarily relevant elsewhere.

    “Service Workers were designed to run in browsers, but it turns out that the Service Worker API is a perfect fit for what we wanted to support on the edge,” he explained in a blog post.

    On Friday, Cloudflare began accepting signups for those interested in beta testing Cloudflare Service Workers, server-side JavaScript code executed using the V8 JavaScript engine developed for Google Chrome.

    Introducing Cloudflare Workers: Run JavaScript Service Workers at the Edge

    Every technology, when sufficiently complicated, becomes programmable.

    Cloudflare is about to go through a similar transition. At its most basic level, Cloudflare is an HTTP cache that runs in 117 locations worldwide (and growing). The HTTP standard defines a fixed feature set for HTTP caches. Cloudflare, of course, does much more, such as providing DNS and SSL, shielding your site against attacks, load balancing across your origin servers, and so much else.

    But, these are all fixed functions. What if you want to load balance with a custom affinity algorithm? What if standard HTTP caching rules aren’t quite right, and you need some custom logic to boost your cache hit rate? What if you want to write custom WAF rules tailored for your application?
    You want to write code

    We can keep adding features forever, but we’ll never cover every possible use case this way. Instead, we’re making Cloudflare’s edge network programmable. We provide servers in 117+ locations around the world — you decide how to use them.

    After looking at many possibilities, we settled on the most ubiquitous language on the web today: JavaScript.

    We run JavaScript using V8, the JavaScript engine developed for Google Chrome. That means we can securely run scripts from multiple customers on our servers in much the same way Chrome runs scripts from multiple web sites — using technology that has had nearly a decade of scrutiny. (Of course, we add a few sandboxing layers of our own on top of this.)

    But what API is this JavaScript written against? For this, we looked to web standards — specifically, the Service Worker API. Service Workers are a feature implemented by modern browsers which allow you to load a script which intercepts web requests destined for your server before they hit the network, allowing you a chance to rewrite them, redirect them, or even respond directly. Service Workers were designed to run in browsers, but it turns out that the Service Worker API is a perfect fit for what we wanted to support on the edge. If you’ve ever written a Service Worker, then you already know how to write a Cloudflare Service Worker.

    Here are some examples of Service Workers you might run on Cloudflare.

    Remember: these are written against the standard Service Workers API. The only difference is that they run on Cloudflare’s edge rather than in the browser.

  2. apteka says:

    I’m not sure why but this weblog is loading extremely slow for me.
    Is anyone else having this problem or is it a problem on my end?
    I’ll check back later and see if the problem still exists.


Leave a Comment

Your email address will not be published. Required fields are marked *