Develop Reference

Is there a thing such as "packaged web app"?

Let's say I have a HTML/JS application, which is on a website and runs without any server-side component (except the web server, of course). So it's basically just a bunch of .html, .css and .js files (and some others, like images or SQLite databases)
Someday, an user comes to me to ask me if I can make an offline version, so they can access the app when they are offline.
My first reaction would be to provide them all the files of the app in a .zip file or something, but this is not really good: it's not "clear" to an average user, and the files and code are apparent (which could be "dangerous" if the user edits or deletes them by accident).
So I was wondering: is there a kind of format that would makes me able to store the files of the app in a packaged file?
The file would be something like a .zip file, but when you click to the file, instead of opening up the archive, it opens the /index.html (or similar) which is inside.
So for the user, it would be similar to open an .exe or a single .html file, but still that's not a native app, as that's still a browser app.
Given that I know about:
Apache Cordova; but most of the time, I just use the browser functions, and I don't have a need to use advanced native functionalities;
UWP and PWA, but I don't know if it's exactly what I want (I imagine it as a mix of website and mobile app, but I'm surely wrong);
Open Web App (a standard from Mozilla), but based on what I've read about it, it seems deprecated and not used anymore. Plus, I don't really look forward to "certify" my app... I just want to package some files.

PWA I don't think is a solution to your problem as you wont be able to redistribute the code as an executable package.
UWP would be too Windows specific and might make you lose the platform independence that you already have since you are using plain HTML and JS, plus from what I understand you would need to distribute the app on Windows Store.
I believe packaging as an Electron app would be the best solution as you can provide executable files that can be executed in almost all platforms.

Electron would be the best solution for you. I had a client that first wanted to run app on php server and eventually they figured out they need it as a desktop app. It was easy to rewrite php stuff to node and package as Electron app. You have access to everything files, system etc. so you can do more if needed.
Another solution would be to just inline everything into a single html file.

Reading a collection of external files locally in JavaScript

I'm working on an app that needs to access a collection of external files. It's basically a music player. It works as-expected under a web server, but I also want it to work locally in the browser.
General overview:
index.htm (Small index file with markup, gather external js, css)
index.js (All the app code here)
dir.js (An array of file paths of all music files)
/AHX/ (location of the music files)
ahx.js (music player code)
The two main difficulties for this are:
JavaScript cannot list directory contents, even if it is a child directory. Instead I express file paths as an array of strings.
Loading external files only possible using XMLHttpRequest, which has security restrictions when running local/offline, but works in other environments (under HTTP or Chrome App, perhaps other platforms, not sure).
Oddly, in the latest Firefox, 2) is not an issue anymore. XMLHttpRequest works locally without disabling security.fileuri.strict_origin_policy. I'm not sure if that is standard behavior, but Chrome doesn't appear to allow it.
In any case, my current solution is generating a list of file-paths in a .js file (previously I used a txt file that required XHR), and using XMLHttpRequest to load the music files. This of course means I need to keep the folder structure and the file-path database in sync, using a shell script to rebuild the dir.js file.
XHR is only supposed to work over HTTP, so the app requires a web server. I want the app to work locally (and not just force the user to install as a Chrome App). So I am asking this question to find alternative methods of reading the data.
One alternative I tried is encoding all 1000 files in base64 strings and storing it in a JS object. This produces a rather large 8MB .js file. It doesn't appear to be slow to load, but I am assuming it isn't exactly efficient... Plus it is a pain to update/maintain.
localStorage, IndexedDB and Web SQL are all options, but there is no way to pre-populate the storage before the app runs. Perhaps utilize File API for a one-time setup of the storage database.
So back to my question: What are some solutions to accessing a large collection of binary files (200+ files, over 6MB etc) locally (i.e. opening the .html file directly)?
Edit: The app in question on GitHub, to clear up any confusion on my use case. But in general, I'm looking for ways to automatically read these music files from the app locally, without cross-origin errors. Also, here is the 'js-database' version. It stores all 1000 files in a 8MB js file likes so:
[{data:"base64-string-of-data-here",path:"original-path-here"}, ...]
In that way it bypasses the need for XHR.
Edit2: A solution using jszip and IndexedDB appears promising. It is not possible to load multiple files from multiple selected folders, but if the directory tree is zipped, jszip can access an array of all files in the format /FOLDER_HERE/FILE_HERE. The paths and binary data can then be imported into IndexedDB in a one-time setup. It also works fine on file:// URLs which is important.
It is also possible that jszip could be used to effectively build/update a large JSON structure of BASE64 strings of the contents, which doesn't require any setup by the user. Still need to be tested though.

don't take this as a definitive answer, this subject interests me too, if people around dont want to take time to elaborate an answer, please comment, it will be more useful than votes..
from what i learnt in javascript resources, consider that you cannot really bypass the security aspect of the question. Even open source, you should warn explicitly if you didn't take in account the security. People could distribute a modified version of the resources for example. It depends on what is done with the resources.
If this is for a player i recommend treating it as a data resource, not as a script resource, because of security (as long as you don't eval strings or such). JSON data could do the job here, but that would need to process the 1000 files. Not so hard to write a script that processes the files though.
HTML5 file API
I haven't used it yet, so i can just give you one or two links. With the downside that it restricts your player to recent browsers.
https://www.html5rocks.com/en/tutorials/file/dndfiles/
HTML5 File API read as text and binary
(i know, not an answer) use a library:
Except that in this case, this might be an answer, just because there is no real universal data retreivement in javascript. A good library would add that and a support for old browers.
Among these solutions, for example jQuery JSONP allows to do dynamical cross-domain GET requests. With data formatting (and not script), it is much safer to inject. But keep in mind that you should be aware in detail what your player does with the binary, and in which way it can be a risk.
http://api.jquery.com/jQuery.getJSON/
direct inclusion of script: not recommended
<script src="./sameFolderFile.js"></script>
As for direct script inclusion in a local folder structure, it actually works in local. IE says there is ActiveX content and asks for use permission, but it works in firefox and chrome. The tag can be dynamically added, but there is a big security risk here: malicious javascript code added in the resources will be executed. This can lead to risks for the users

Loading local files via jQuery (part 2)

Ok, here we discussed the essence of the problem: in some browsers like Chrome and Opera HttpRequests to local files is turned off by default.
Now the question is: how to build such HTML+javascript viewer of HTML documents, that:
would run locally on any (or most of) browser(s) without additional tuning;
would not use frames;
would have an ability to work with many different files(5-10k);

It can't be done in straight HTML/Javascript if you want to load files via Javascript using AJAX requests. There are good security reasons to not allow local files script access to other files on the local system (see my answer here for more details), so most browsers will not allow this without special user configuration.
So your options are:
Don't load files with Javascript, use frames or another mechanism. If, as you state in the other question, you're shipping all this on CD, you might want to consider using some sort of build system that allows you to create static files using templates and either a database or flat-file content - Jekyll is one option I know of.
Ship an executable along with the files that can either run a local webserver or run HTML files in an application context. I think Appcelerator Titanium might fit the bill.

How to handle javascript & css files across a site?

I have had some thoughts recently on how to handle shared javascript and css files across a web application.
In a current web application that I am working on, I got quite a large number of different javascripts and css files that are placed in an folder on the server. Some of the files are reused, while others are not.
In a production site, it's quite stupid to have a high number of HTTP requests and many kilobytes of unnecessary javascript and redundant css being loaded. The solution to that is of course to create one big bundled file per page that only contains the necessary information, which then is minimized and sent compressed (GZIP) to the client.
There's no worries to create a bundle of javascript files and minimize them manually if you were going to do it once, but since the app is continuously maintained and things do change and develop, it quite soon becomes a headache to do this manually while pushing out new updates that features changes to javascripts and/or css files to production.
What's a good approach to handle this? How do you handle this in your application?

I built a library, Combres, that does exactly that, i.e. minify, combine etc. It also automatically detects changes to both local and remote JS/CSS files and push the latest to the browser. It's free & open-source. Check this article out for an introduction to Combres.

I am dealing with the exact same issue on a site I am launching.
I recently found out about a project named SquishIt (see on GitHub). It is built for the Asp.net framework. If you aren't using asp.net, you can still learn about the principles behind what he's doing here.
SquishIt allows you to create named "bundles" of files and then to render those combined and minified file bundles throughout the site.

CSS files can be categorized and partitioned to logical parts (like common, print, vs.) and then you can use CSS's import feature to successfully load the CSS files. Reusing of these small files also makes it possible to use client side caching.
When it comes to Javascript, i think you can solve this problem at server side, multiple script files added to the page, you can also dynamically generate the script file server side but for client side caching to work, these parts should have different and static addresses.

I wrote an ASP.NET handler some time ago that combines, compresses/minifies, gzips, and caches the raw CSS and Javascript source code files on demand. To bring in three CSS files, for example, it would look like this in the markup...
<link rel="stylesheet" type="text/css"
href="/getcss.axd?files=main;theme2;contact" />
The getcss.axd handler reads in the query string and determines which files it needs to read in and minify (in this case, it would look for files called main.css, theme2.css, and contact.css). When it's done reading in the file and compressing it, it stores the big minified string in server-side cache (RAM) for a few hours. It always looks in cache first so that on subsequent requests it does not have to re-compress.
I love this solution because...
It reduces the number of requests as much as possible
No additional steps are required for deployment
It is very easy to maintain
Only down-side is that all the style/script code will eventually be stored within server memory. But RAM is so cheap nowadays that it is not as big of a deal as it used to be.
Also, one thing worth mentioning, make sure that the query string is not succeptible to any harmful path manipulation (only allow A-Z and 0-9).

What you are talking about is called minification.
There are many libraries and helpers for different platforms and languages to help with this. As you did not post what you are using, I can't really point you towards something more relevant to yourself.
Here is one project on google code - minify.
Here is an example of a .NET Http handler that does all of this on the fly.

How many javascript link I can have in Facebook?

Is there a limit of how many js file I can include () in facebook? I include 5 files. no problem.. the 6th one not loaded. Then I have to put the code in the 6th one into the 5th file. then works. so, is it 5 files in max?
BY THE WAY, I'm developing the apps now, not in production. so it is not in the stage of compressing JS / minizing it. :)
so it is kinda annoying to got missing js files or files not loaded..etc
so, what is the limit from FB? what is the file size limit? I know that the JSON request call back data limit is 5000.. but not sure about the js include.

Yes, Facebook should not do anything within an IFrame app. Okay even for an FBML app, there are some things that might cause the issue:
script tags must be ended by a separate closing tag, they do not work like link tags.
Some browsers for instance IE limit the total number of link tags that are included on a page (IE link tag limit seems to be 31). I am not really sure if there is some hard limit like that on the number of script tags too, but I would check that too. Searching on the web, did not yield anything.
While javascript files are loaded and run, every other parallel file download from that domain is disabled, so make sure that some javascript file that you have included is not blocking others from being downloaded.
Also only two-six files are downloaded in parallel from a domain, and as an extra precaution only one javascript file is downloaded at any given time. Hence make sure you do not have an excessively big js file/ unreachable js file that is hogging the pipeline.
To circumvent point 5 you can dynamically script js file downloads, because the hard limit of 2-6 parallel downloads only pertains to HTML scripted files. So using javascript to load additional files will increase the number of parallel downloads that can happen.
From my experience I just concatenated all the 30 or odd files into 3 files and included these 3 files in production environments and continued to use the individual files for development.
It seemed to me that Facebook was timing out somehow and trying to reload the page in the earlier case, when the network latency to download some of the js files was high (cannot prove this theory though).

From a user perspective, you should be loading as few as possible, not trying to see how many you can shove in there. More independent files means more HTTP Requests for the client which means a slower page load.
Also, I'd minify your script before pushing into production, less bytes means a faster page as well.

I have 29 scripts loaded on development environment and just recently have I started seeing issues with the files not being loaded and stuff.
But if you are writing a iframe based app then I cannot reason out why/how facebook will limit the number of JS files loaded. Check out network latency though because, with a very slow connection facebook might try reloading the whole page and in the process refetching all of your static assets unless they are cacheable.
Browser caches can also be a factor. Firefox 3.6 does very aggressive caching and frankly speaking it has more glitches than any thing else. Hence check to see if your incomplete js files are already cached by the browser.