Web: Packaging assets to a binary the web way

We have a game in html with a bunch of images and sound effects. Instead of having a bunch of requests, we want to package all the asset files into a single binary, download it and extract the files. Something like tar/zip but... been there done that.

So lets follow the ancient philosophy of a header and payload. To be more exact: magic bytes, version, header length, (for each file) path size, path, file size and all the file contents concatenated in the end.

Lets use 4 byte integers for all to simplify life, and we have the ArrayBuffers and DataView ready to implement a C struct like parser.

Ok lets start with the magic bytes.... but wait a second this is the web, is packing bytes really the thing that we need? I mean just downloading the file will take couple of orders of magnitude of time more than parsing it. So lets do the exact opposite of packing bytes: lets do JSON!

Lets put all the header data in a JSON object and then we have: magic bytes, header size, JSON dump, file contents. Yeah... but it could be nice to just have the JSON object and then the file contents.

What is the most used operation in the world of js: split once. All we need is a delimiter, what is never used in a JSON object: all the non printable characters, lets take the first the null byte (0x00).

So we have it: JSON header object, byte 0x00, file contents.

Which if you think about its agnostic to the actual content, you can put whatever you like in the header and whatever you like in the binary part.

I shall name it JHBF (json header binary file).

done_

Web: Bundle and deploy with php and make

 We want to put all the things into a single index.html and then uploaded. We just:

index.html: index.php $(shell find src -type f)
    php index.php > index.html

upload: index.html
    cp index.html /run/user/1000/gvfs/ftps:host=[website]/project/
    touch upload

We dont have php in the server, we just use php to bundle all the html, js and css files into one file using php statements like this:

    <style>
    <?php foreach (glob("src/*.css") as $i) include $i ?>
    </style>

And then we let make file generate the index.hml and we upload to our server with a cp (linux things) when changes have been made

done_

Html: Write the tags of your dreams

Lets say we want to write some quick html and js thing to test something. We want a text field and a button to login with a username and if logged, some text with the username saying hello.

Ok, we skip all the html, head and body tags and we just write this:

<login>
    <input type="text">
    <button onclick="login()">Log in</button>
</login>

<hello>
    Hello <username>
</hello>

We add and a script tag in the end and we are done (and it works, this is not a joke)

It may not be obvious but we are not following the law of the "Valid custom element names" and if we then define some components with these name you are going to get the "Failed to execute 'define', 'hello' is not a valid custom element name".

Very important check, image this check not being there all the bad things that could happen. Like when you try to create a component "icon" but there is no hyphen there, so you spend all day trying to figure out if "a-icon" or "icon-" is the least ugly of the two, and then you are unable to sleep thinking that there must be some other way to cheat the system... there must be... Thank you whatwg.

done_

Techniques: Multiple localhost sessions

Lets assume you have an web app with some sort of login system, and you are testing things on a local web server bound to "localhost" and you want to test multiple logged in users at the same time.

We start by creating multiple "domains" pointing to the localhost via the /ets/hosts file:

127.0.0.1  localhost1
127.0.0.1  localhost2
127.0.0.1  localhost3
127.0.0.1  localhost4
127.0.0.1  localhost5
127.0.0.1  localhost6
127.0.0.1  localhost7
127.0.0.1  localhost8
127.0.0.1  localhost9

Because the session and local storage is instanced per domain name (or even the cookies for the old school) using the localhostX will each be isolated.

Then you fight with your web server that definitely will not like requesting http with something different than localhost, but you can win.

And then you fight with the OAuth callback redirect url and... you lose the fight... and you go back to the firefox containers.

done_