#no-build for JS: Embracing the Era of Import Maps and HTTP/2

Complex build processes have dominated the web development world for years. JavaScript module bundling, transpiling, and management have become critical tasks for tools such as Webpack. However, what if there was an easier method? 

It is time for us to "un-learn" old tricks and rid ourselves of the baggage of old knowledge! Modern browsers support HTTP/2 and "import maps" for javascript modules and this is an absolute game changer!

In the past, web browsers had trouble comprehending contemporary JavaScript features and had trouble loading many small files quickly. Webpack and other build tools addressed these problems by:

• Bundling: Putting several JavaScript files together into a single, bigger file to cut down on HTTP requests.
• Transpiling:transforming current JavaScript syntax into an earlier iteration that works with an earlier browser.

Although these technologies were helpful to us, they increased complexity:

• Build Configuration: Build procedures frequently cause disruptions to the development workflow, necessitating continuous rebuilding and waiting. 
• Development Workflow Disruption: Build configurations can be time-consuming to set up and manage.

But all modern browsers (Chrome, Firefox, Safari, Edge) support HTTP/2 and "Import Maps" for JS modules. 

• Import maps enables us to use alias for full JS module paths - it is a method of creating a central registry that associates module names with their real locations is. This makes things clearer and more versatile by removing the requirement for you to write whole file paths in your code (across multiple files). 
• HTTP/2 is a more effective and rapid method of sending data across the internet. It makes it unnecessary to bundle files because browsers can handle several tiny files well. Instead of opening many connections to the server (like having many waiters running around), HTTP/2 uses one connection. Thus, multiple JS files can be downloaded concurrently, speeding up page load times.

Ruminating on SSL and encrypted URLs

Recently, a colleague of mine asked an innocuous question that was quite interesting. We all knew that SSL protects the URL and hence it is not possible to snoop details out of the URL - for e..g GET params, resource path on server, etc.

But if the URL is encrypted by SSL, how does DNS work? How will the DNS server route the request to the right server?

The way it happens is as below:

1. When a HTTP client (browser / API client) makes a request to a HTTPS URL, it only send the server name part of the URL to the DNS server. For e.g. if you are making a request to https://myserver.com/secret_path/secret_resource, then the HTTP client would only send 'myserver.com' to the DNS server for lookup. 
2. The DNS server responds back with the actual IP address of the server. 
3. The HTTP client then makes a call to the server using the IP address. What follows is the SSL handshake protocol and a secure connection is established with the server.
4. Then the HTTP server makes a request for the actual resource on the secure pipe/tunnel. 

Quite simple actually, if you break down the steps :)

Overcoming the 2 connection limit in browsers

The HTTP 1.1 protocol dictates that browsers cannot make more than 2 connections per domain name. This limitation can cause slow page loads for pages containing a lot of images or other references to external resources.
To overcome this limitation, we can create sub-domains and serve other static content from these sub-domains, so that the browser can create extra 2 connections for each sub-domain.
This trick is explained in the following links:

http://brainspl.at/articles/2006/12/29/speed-up-page-loads
http://www.die.net/musings/page_load_time/

Actually the above technique is only useful if there are a lot of external resources that need to be loaded by the page. HTTP 1.1 also brought in the concept of HTTP pipelining. This means that over those two connections the browser can send the requests back-to-back before even before receiving a single response. This completely eliminates the dead-time between getting back the last packet of the previous request and then sending the next request. Instead, all the requests are queued at the server, which sends out responses as fast as TCP/IP would allow. If HTTP pipelining is enabled, then the page load speed improves dramatically.

But unfortunately, HTTP pipelining is disabled by default in IE/Firefox- bcoz not all proxies and servers support it still. To enable pipelining in Firefox type "about:config" in Firefox's location bar and enable the "network.http.pipelining" preference.