Move JavaScript

wblz

You could move any html / view-source output generated by JavaScript to an external file?

Pollux

Ehm, no.

Javascript gives a page interactivity, which is fundamentally different from static webpages. There is not one output of javascript, there is an indefinite number of possible different outputs.

It's like suggesting to replace a wordprocessor with screenshots of written letters.

Pollux

Excuse me, if I sound rude, maybe I just haven't understood your suggestion.

wblz

no problem, maybe maybe I was not exactly... I'll explain it better:
- this part of outpute/html code... moving to external file .js

<script>
        document.getElementById('flarum-loading').style.display = 'none';
                try {
                  var app = System.get('flarum/app').default;
          var modules = ecc...ecc....

Pollux

wblz

Ah, I understand. Well, there are reasons to place javascript inline and reasons to write it into dedicated files.

Have a look here: https://stackoverflow.com/questions/19002690/why-inline-javascript-is-bad

From the selected best answer:

Caching a static resource reduces the size of page loads – thus increasing the page load speed – for returning visitors. However it comes at the cost of an additional HTTP request which should be avoided.

Whenever the static resource is so small that the additional size is negligible in comparison to a HTTP request, then it's actually recommended to keep that resource inline.

It's usually a good idea to keep javascript libraries in external (cacheable) documents, while keeping small amounts of scripts inline.

So, in response to your headline – inline javascript isn't bad per-se. It's a balance whether or not it's worth a HTTP request to cache the resource.

An important aspect against having javascript inline is the need to load this code with every page request, which could be cached by the browser when placed in a separate file. Flarum however doesn't request new pages in the conventional way, as it is a single page application (SPA). This means, consecutive webviews are rquested via api calls, which deliver xml data and don't contain the javascript code we are talking about. Only when reloading a page, a request of the initial webpage with its html-structure (and the javascript) is made.

clarkwinkelmann

I'm wondering if this would have any impact on performance at all, if done right.

document.getElementById('flarum-loading').style.display = 'block'; is run directly on the page so it runs at the very first possible moment, I don't think it would be wise to move it to a file.

However the javascript code at the bottom of the page is only run after the two compiled scripts (app and language) are loaded, so it's clearly not put there to run at the same time the source page loads. I think it's made that way because it needs to wait for these two files to load, and loading a third file just for that would probably have a bad performance impact. as pointed out by Pollux

But if the code was changed so both app and language are in the same external file, then all this bootstrapping code could be embedded in that file as well.

Maybe a first step could be to move everything except app.boot inside one of the external files. It's really only the boot that needs all the other dependencies loaded before running.

wblz

?
of course, then moving to external files could compromise proper operation and slow down performance...

Pollux

wblz of course, then moving to external files could compromise proper operation and slow down performance...

It probably won't compromise operation, but performance would be worse, I guess.

wblz

maybe I'll try to see how it reacts,
and especially if it works ?

Pollux

So you are an adventurous kind of guy ?

But keep in mind, that your changes may be easily wiped out the next time the software recompiles.

wblz

Pollux ?

wblz

clarkwinkelmann You know that at this time I can not answer all this, but a way is to get it all right without complicating. I'm doing other things right now, but I'll be back on it. ?