info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Parsing javascript file off the main thread
47 views
Skip to first unread message
georgko...@gmail.com
Sep 16, 2016, 9:30:30 AM9/16/16
to
Hey!
I wonder if it is possible to parse a javascript file off the main thread. If it is possible, is it possible across all modern browsers?
Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If the Unity-asm.js-source is parsed the whole browser freezes. Which is not a nice UX. The loading and parsing wouldn't be a problem because we do it in background but the freezing of the whole UI is a big problem.
I know Unity is not really "web-ready" but we have to deal with it because we have a quite huge code base written in Unity. As a technical detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if this makes a difference for my question.
Are there any ways around? Would it also be possible to cache the byte code of the parsed script somehow?
Thanks a lot for your ideas
I wonder if it is possible to parse a javascript file off the main thread. If it is possible, is it possible across all modern browsers?
Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If the Unity-asm.js-source is parsed the whole browser freezes. Which is not a nice UX. The loading and parsing wouldn't be a problem because we do it in background but the freezing of the whole UI is a big problem.
I know Unity is not really "web-ready" but we have to deal with it because we have a quite huge code base written in Unity. As a technical detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if this makes a difference for my question.
Are there any ways around? Would it also be possible to cache the byte code of the parsed script somehow?
Thanks a lot for your ideas
Evertjan.
Sep 16, 2016, 11:43:52 AM9/16/16
to
georgko...@gmail.com wrote on 16 Sep 2016 in comp.lang.javascript:
> Hey!
A good afternoon to you too.
> I wonder if it is possible to parse a javascript file off the main
> thread. If it is possible, is it possible across all modern browsers?
What does "parse a javascript file off the main thread" mean [to you]?
> Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If
> the Unity-asm.js-source is parsed the whole browser freezes.
Which browser? Is the browser doing this "parsing"?
A "js-script" being a script, what is a "js-source"?
Do you mean "compiling" by "parsing"?
> Which is
> not a nice UX. The loading and parsing wouldn't be a problem because we
> do it in background but the freezing of the whole UI is a big problem.
>
> I know Unity is not really "web-ready" but we have to deal with it
> because we have a quite huge code base written in Unity. As a technical
> detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if
> this makes a difference for my question.
>
> Are there any ways around? Would it also be possible to cache the byte
> code of the parsed script somehow?
>
> Thanks a lot for your ideas
>
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
> Hey!
A good afternoon to you too.
> I wonder if it is possible to parse a javascript file off the main
> thread. If it is possible, is it possible across all modern browsers?
> Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If
> the Unity-asm.js-source is parsed the whole browser freezes.
A "js-script" being a script, what is a "js-source"?
Do you mean "compiling" by "parsing"?
> Which is
> not a nice UX. The loading and parsing wouldn't be a problem because we
> do it in background but the freezing of the whole UI is a big problem.
>
> I know Unity is not really "web-ready" but we have to deal with it
> because we have a quite huge code base written in Unity. As a technical
> detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if
> this makes a difference for my question.
>
> Are there any ways around? Would it also be possible to cache the byte
> code of the parsed script somehow?
>
> Thanks a lot for your ideas
>
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Georg Kothmeier
Sep 16, 2016, 7:16:53 PM9/16/16
to
To clearify what I mean:
by source, I mean the JavaScript file which is sent to the browser. This is already minified and in ASM.js format.
By parsing I mean the step which is done by the browser when the JavaScript file is interpreted and compiled to some kind of byte code which then is used by the browser to run the code.
And by "off the main thread" I mean, a mechanism of parsing/compiling which does not block the whole UI. So basically to switch the parsing/compiling to some background thread, away from the main thread.
Does this make sense? If not I'll try to explain it better
by source, I mean the JavaScript file which is sent to the browser. This is already minified and in ASM.js format.
By parsing I mean the step which is done by the browser when the JavaScript file is interpreted and compiled to some kind of byte code which then is used by the browser to run the code.
And by "off the main thread" I mean, a mechanism of parsing/compiling which does not block the whole UI. So basically to switch the parsing/compiling to some background thread, away from the main thread.
Does this make sense? If not I'll try to explain it better
Georg Kothmeier
Sep 16, 2016, 7:18:50 PM9/16/16
to
Evertjan.
Sep 17, 2016, 4:47:38 AM9/17/16
to
Georg Kothmeier <georgko...@gmail.com> wrote on 17 Sep 2016 in
comp.lang.javascript:
so please for the group and according to Netiquette,
quote what you are replying on!
> by source, I mean the JavaScript file which is sent to the browser. This
> is already minified and in ASM.js format.
So that is the 'Javascipt script'. Mimifying is not apparent to the
executing engine, it just speeds up the transmission, and gives an illusion
of encription to the unwary.
> By parsing I mean the step which is done by the browser when the
> JavaScript file is interpreted and compiled to some kind of byte code
> which then is used by the browser to run the code.
In my vocabulary, 'compiling' is producing an executable code that can be
distributed. Javascript in browsers does not work like that, imho.
That is why it is a 'script' and not a 'source'. Scripts are executed by an
execution engine.
'Scripts', in the usual parlance, are executed as is, or though an
intermediate code that is made u[p real-time and destroyed immediately after
use, and are probably not readable by another type of execution engine,
depending on the specific browser and version.
> And by "off the main thread" I mean, a mechanism of parsing/compiling
> which does not block the whole UI.
'UI' meaning 'browser UI'?
Present Javascript engines in browsers, AFAIK, are still single-threaded.
You must give the illusion of 'non freezing up' by clever coding, giving the
user someting to do, see or read, or dividing up the 'parsing'. Google is
rather clever in that in its large applications, mesupposes.
> So basically to switch the
> parsing/compiling to some background thread, away from the main thread.
There is no compiling, the 'parsing' is done in real time, that's why it is
called a 'script' and not a 'source'.
> Does this make sense?
Yes, but for the missing quote. Usenet servers are not time-coherent in the
sense that they maintain order in the messages, so quoting is essential to
maintain a thread.
> If not I'll try to explain it better
comp.lang.javascript:
> To clearify what I mean:
This is Usenet, not email, nor a Google group,
so please for the group and according to Netiquette,
quote what you are replying on!
> by source, I mean the JavaScript file which is sent to the browser. This
> is already minified and in ASM.js format.
executing engine, it just speeds up the transmission, and gives an illusion
of encription to the unwary.
> By parsing I mean the step which is done by the browser when the
> JavaScript file is interpreted and compiled to some kind of byte code
> which then is used by the browser to run the code.
distributed. Javascript in browsers does not work like that, imho.
That is why it is a 'script' and not a 'source'. Scripts are executed by an
execution engine.
'Scripts', in the usual parlance, are executed as is, or though an
intermediate code that is made u[p real-time and destroyed immediately after
use, and are probably not readable by another type of execution engine,
depending on the specific browser and version.
> And by "off the main thread" I mean, a mechanism of parsing/compiling
> which does not block the whole UI.
Present Javascript engines in browsers, AFAIK, are still single-threaded.
You must give the illusion of 'non freezing up' by clever coding, giving the
user someting to do, see or read, or dividing up the 'parsing'. Google is
rather clever in that in its large applications, mesupposes.
> So basically to switch the
> parsing/compiling to some background thread, away from the main thread.
called a 'script' and not a 'source'.
> Does this make sense?
Yes, but for the missing quote. Usenet servers are not time-coherent in the
sense that they maintain order in the messages, so quoting is essential to
maintain a thread.
> If not I'll try to explain it better
Michael Haufe (TNO)
Sep 18, 2016, 1:55:07 PM9/18/16
to
On Friday, September 16, 2016 at 8:30:30 AM UTC-5, Georg Kothmeier wrote:
> Hey!
>
> I wonder if it is possible to parse a javascript file off the main thread. If it is possible, is it possible across all modern browsers?
>
> Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If the Unity-asm.js-source is parsed the whole browser freezes. Which is not a nice UX. The loading and parsing wouldn't be a problem because we do it in background but the freezing of the whole UI is a big problem.
My first question is where in the HTML document the <script /> is referenced.
> Hey!
>
> I wonder if it is possible to parse a javascript file off the main thread. If it is possible, is it possible across all modern browsers?
>
> Our use-case is a 25mb (6 mb gzipped) Unity-asm.js-export of a game. If the Unity-asm.js-source is parsed the whole browser freezes. Which is not a nice UX. The loading and parsing wouldn't be a problem because we do it in background but the freezing of the whole UI is a big problem.
If it's in the <head> tag, then that's one major problem right there.
> I know Unity is not really "web-ready" but we have to deal with it because we have a quite huge code base written in Unity. As a technical detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if this makes a difference for my question.
<script src="data:text/javascript,alert('hi');" type="text/javascript"></script>
> Are there any ways around? Would it also be possible to cache the byte code of the parsed script somehow?
>
> Thanks a lot for your ideas
Georg Kothmeier
Sep 19, 2016, 3:28:56 AM9/19/16
to
Am Sonntag, 18. September 2016 19:55:07 UTC+2 schrieb Michael Haufe (TNO):
>
> My first question is where in the HTML document the <script /> is referenced.
> If it's in the <head> tag, then that's one major problem right there.
>
No it is at the end of the body.
>
> My first question is where in the HTML document the <script /> is referenced.
> If it's in the <head> tag, then that's one major problem right there.
>
> > I know Unity is not really "web-ready" but we have to deal with it because we have a quite huge code base written in Unity. As a technical detail, Unity loads the 25mb JavaScript via a blob: URL. Don't know if this makes a difference for my question.
>
> Are you referring to the following?
>
> <script src="data:text/javascript,alert('hi');" type="text/javascript"></script>
<script src="blob:https://.../a0f22f6d-b1e3-4577-ad03-90f77cfd5e3b"></script>
I could change the way the script is added to the DOM but this is the Unity default. Don't know if this is the best way.
>
> > Are there any ways around? Would it also be possible to cache the byte code of the parsed script somehow?
> >
> > Thanks a lot for your ideas
>
> Modern browsers are probably already doing this, depending on the details of how you're including the script in your application.
Michael Haufe (TNO)
Sep 19, 2016, 11:15:18 AM9/19/16
to
On Monday, September 19, 2016 at 2:28:56 AM UTC-5, Georg Kothmeier wrote:
> Unity (https://unity3d.com/) is adding the script as follows:
> <script src="blob:https://.../a0f22f6d-b1e3-4577-ad03-90f77cfd5e3b"></script>
>
> I could change the way the script is added to the DOM but this is the Unity default. Don't know if this is the best way.
Object Urls are pretty new, and there may be some efficiency issues relating to it, but I have seen no statistics one way or another.
> Unity (https://unity3d.com/) is adding the script as follows:
> <script src="blob:https://.../a0f22f6d-b1e3-4577-ad03-90f77cfd5e3b"></script>
>
> I could change the way the script is added to the DOM but this is the Unity default. Don't know if this is the best way.
What alternative methods are available? If you can add the script to the dom in a more traditional way we could at least discount/confirm that as an issue.
This could be an issue of what you're script is doing that is locking up the thread instead of just the loading of the script. Too much being done up-front?
> I read something that adding async or defer attribute to the script tag could help, but I'm not quite sure how this works and how it works across browsers.
Thomas 'PointedEars' Lahn
Sep 19, 2016, 1:47:08 PM9/19/16
to
--
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.
Michael Haufe (TNO)
Sep 19, 2016, 2:01:05 PM9/19/16
to
On Monday, September 19, 2016 at 12:47:08 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > When the script tag is at the end of the body there is no need to use
> > defer or async.
>
> Nonsense.
Present your reasoning. His script is inline within the src attribute and right before the </body> tag. How is async or defer going to change the semantics here?
> > When the script tag is at the end of the body there is no need to use
> > defer or async.
>
> Nonsense.
Thomas 'PointedEars' Lahn
Sep 19, 2016, 2:42:21 PM9/19/16
to
Michael Haufe (TNO) wrote:
> On Monday, September 19, 2016 at 12:47:08 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > When the script tag is at the end of the body there is no need to use
>> > defer or async.
>> Nonsense.
>
> Present your reasoning. […]
> On Monday, September 19, 2016 at 12:47:08 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > When the script tag is at the end of the body there is no need to use
>> > defer or async.
>> Nonsense.
>
Trying to shift the burden of proof? Present *yours*.
Michael Haufe (TNO)
Sep 19, 2016, 2:53:47 PM9/19/16
to
On Monday, September 19, 2016 at 1:42:21 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > On Monday, September 19, 2016 at 12:47:08 PM UTC-5, Thomas 'PointedEars'
> > Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >> > When the script tag is at the end of the body there is no need to use
> >> > defer or async.
> >> Nonsense.
> >
> > Present your reasoning. […]
>
> Trying to shift the burden of proof? Present *yours*.
RTFM:
> Michael Haufe (TNO) wrote:
>
> > On Monday, September 19, 2016 at 12:47:08 PM UTC-5, Thomas 'PointedEars'
> > Lahn wrote:
> >> Michael Haufe (TNO) wrote:
> >> > When the script tag is at the end of the body there is no need to use
> >> > defer or async.
> >> Nonsense.
> >
> > Present your reasoning. […]
>
> Trying to shift the burden of proof? Present *yours*.
<https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer>
Thomas 'PointedEars' Lahn
Sep 19, 2016, 5:59:00 PM9/19/16
to
Michael Haufe (TNO) wrote:
Yes, you should *read* that to clarify your misconceptions.
Thomas 'PointedEars' Lahn
Sep 19, 2016, 6:01:30 PM9/19/16
to
Michael Haufe (TNO) wrote:
reasoning”.)
Yes, you should *read* that to clarify your misconceptions.
(JFYI: Posting a URI without further comment is _not_ to “present [one’s]
reasoning”.)
Michael Haufe (TNO)
Sep 20, 2016, 3:00:13 PM9/20/16
to
Thomas 'META-COMMENT' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > RTFM:
> > <https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer>
>
> Yes, you should *read* that to clarify your misconceptions.
You've yet to point out the misconception, or even submitted a counter-point.
> Michael Haufe (TNO) wrote:
> > RTFM:
> > <https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer>
>
> Yes, you should *read* that to clarify your misconceptions.
Michael Haufe (TNO)
Sep 20, 2016, 3:02:46 PM9/20/16
to
Thomas 'PointedEars' Lahn wrote:
> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
> reasoning”.)
Just a reminder, you snipped my justification in your earlier response. The referenced link looks to me to be aligned with my reasoning.
> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
> reasoning”.)
Thomas 'PointedEars' Lahn
Sep 20, 2016, 3:26:47 PM9/20/16
to
[I am not going to follow-up on your follow-up to my superseded posting.
Please use a newsreader that observes NNTP.]
Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
>> reasoning”.)
>
> Just a reminder, you snipped my justification in your earlier response.
There was no justification. You wrote, what I did not quote because I found
it irrelevant to the question at hand:
| His script is inline within the src attribute and right before the </body>
| tag. How is async or defer going to change the semantics here?
shift the burden of proof by asking (me) a question in return. Therefore,
whether the “referenced link” (you mean the referenced/linked _resource_
instead) is *actually* *objectively* aligned with your reasoning or only
seems to be so *to you* (“looks to me”) remains unknown.
Proper reasoning would go along the lines, “these are the $FACTS of the
situation, and from $STATEMENT(S) in $RESOURCE (I think that) it follows,
given these $FACTS, that …”. Only from that a constructive discussion could
ensue.
HTH
Please use a newsreader that observes NNTP.]
Michael Haufe (TNO) wrote:
> Thomas 'PointedEars' Lahn wrote:
>> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
>> reasoning”.)
>
> Just a reminder, you snipped my justification in your earlier response.
it irrelevant to the question at hand:
| His script is inline within the src attribute and right before the </body>
| tag. How is async or defer going to change the semantics here?
> The referenced link looks to me to be aligned with my reasoning.
You have not presented your reasoning so far. Instead you have tried to
shift the burden of proof by asking (me) a question in return. Therefore,
whether the “referenced link” (you mean the referenced/linked _resource_
instead) is *actually* *objectively* aligned with your reasoning or only
seems to be so *to you* (“looks to me”) remains unknown.
Proper reasoning would go along the lines, “these are the $FACTS of the
situation, and from $STATEMENT(S) in $RESOURCE (I think that) it follows,
given these $FACTS, that …”. Only from that a constructive discussion could
ensue.
HTH
Michael Haufe (TNO)
Sep 20, 2016, 8:38:27 PM9/20/16
to
On Tuesday, September 20, 2016 at 2:26:47 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> [I am not going to follow-up on your follow-up to my superseded posting.
> Please use a newsreader that observes NNTP.]
>
> Michael Haufe (TNO) wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
> >> reasoning”.)
> >
> > Just a reminder, you snipped my justification in your earlier response.
>
> There was no justification. You wrote, what I did not quote because I found
> it irrelevant to the question at hand:
>
> | His script is inline within the src attribute and right before the </body>
> | tag. How is async or defer going to change the semantics here?
>
> > The referenced link looks to me to be aligned with my reasoning.
>
> You have not presented your reasoning so far. Instead you have tried to
> shift the burden of proof by asking (me) a question in return. Therefore,
> whether the “referenced link” (you mean the referenced/linked _resource_
> instead) is *actually* *objectively* aligned with your reasoning or only
> seems to be so *to you* (“looks to me”) remains unknown.
>
> Proper reasoning would go along the lines, “these are the $FACTS of the
> situation, and from $STATEMENT(S) in $RESOURCE (I think that) it follows,
> given these $FACTS, that …”. Only from that a constructive discussion could
> ensue.
>
> HTH
That is now five posts in a row of no useful reply from you on the topic at hand. If you wish to continue in such a manner, you can continue alone. Such noise adds nothing. By now you could have expanded on what you disagreed with specifically but have instead chosen to engage in shallow meta-discussion; again.
> [I am not going to follow-up on your follow-up to my superseded posting.
> Please use a newsreader that observes NNTP.]
>
> Michael Haufe (TNO) wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> (JFYI: Posting a URI without further comment is _not_ to “present [one’s]
> >> reasoning”.)
> >
> > Just a reminder, you snipped my justification in your earlier response.
>
> There was no justification. You wrote, what I did not quote because I found
> it irrelevant to the question at hand:
>
> | His script is inline within the src attribute and right before the </body>
> | tag. How is async or defer going to change the semantics here?
>
> > The referenced link looks to me to be aligned with my reasoning.
>
> You have not presented your reasoning so far. Instead you have tried to
> shift the burden of proof by asking (me) a question in return. Therefore,
> whether the “referenced link” (you mean the referenced/linked _resource_
> instead) is *actually* *objectively* aligned with your reasoning or only
> seems to be so *to you* (“looks to me”) remains unknown.
>
> Proper reasoning would go along the lines, “these are the $FACTS of the
> situation, and from $STATEMENT(S) in $RESOURCE (I think that) it follows,
> given these $FACTS, that …”. Only from that a constructive discussion could
> ensue.
>
> HTH
Scott Sauyet
Sep 20, 2016, 10:24:59 PM9/20/16
to
-- Scott
Thomas 'PointedEars' Lahn
Sep 22, 2016, 12:46:41 AM9/22/16
to
I have given you, again, an explanation as to why this discussion cannot be
a constructive one (cannot lead anywhere) based on your arguments so far,
and hints as to how you (and only you) can turn this discussion into a
constructive one. (That was useful advice even though it was not on the
topic.) I have offered to you to have such a discussion with you. If you
are not willing to have it, and insist on your previous fallacies and on
committing new fallacies instead, then that is *your* problem.
<https://yourlogicalfallacyis.com/burden-of-proof>
<https://en.wikipedia.org/wiki/Philosophic_burden_of_proof>
Michael Haufe (TNO)
Sep 22, 2016, 8:53:44 AM9/22/16
to
On Wednesday, September 21, 2016 at 11:46:41 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> > That is now five posts in a row of no useful reply from you on the topic
> > at hand. If you wish to continue in such a manner, you can continue alone.
> > Such noise adds nothing. By now you could have expanded on what you
> > disagreed with specifically but have instead chosen to engage in shallow
> > meta-discussion; again.
>
> [...]
> > That is now five posts in a row of no useful reply from you on the topic
> > at hand. If you wish to continue in such a manner, you can continue alone.
> > Such noise adds nothing. By now you could have expanded on what you
> > disagreed with specifically but have instead chosen to engage in shallow
> > meta-discussion; again.
>
>
> I have given you, again, an explanation as to why this discussion cannot be
> a constructive one (cannot lead anywhere) based on your arguments so far,
> and hints as to how you (and only you) can turn this discussion into a
> constructive one. (That was useful advice even though it was not on the
> topic.) I have offered to you to have such a discussion with you. If you
> are not willing to have it, and insist on your previous fallacies and on
> committing new fallacies instead, then that is *your* problem.
Six
> I have given you, again, an explanation as to why this discussion cannot be
> a constructive one (cannot lead anywhere) based on your arguments so far,
> and hints as to how you (and only you) can turn this discussion into a
> constructive one. (That was useful advice even though it was not on the
> topic.) I have offered to you to have such a discussion with you. If you
> are not willing to have it, and insist on your previous fallacies and on
> committing new fallacies instead, then that is *your* problem.
Thomas 'PointedEars' Lahn
Sep 22, 2016, 8:43:01 PM9/22/16
to
Michael Haufe (TNO)
Sep 23, 2016, 12:30:15 PM9/23/16
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > Six
> Michael Haufe (TNO) wrote:
>
>
> Score adjusted
Predictable as usual
0 new messages