Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31383 > unrolled thread

Parsing javascript file off the main thread

Back to article view | Back to comp.lang.javascript

Contents

  Parsing javascript file off the main thread georgkothmeier@gmail.com - 2016-09-16 06:29 -0700
    Re: Parsing javascript file off the main thread "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-09-16 17:43 +0200
      Re: Parsing javascript file off the main thread Georg Kothmeier <georgkothmeier@gmail.com> - 2016-09-16 16:16 -0700
      Re: Parsing javascript file off the main thread Georg Kothmeier <georgkothmeier@gmail.com> - 2016-09-16 16:18 -0700
        Re: Parsing javascript file off the main thread "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-09-17 10:47 +0200
    Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-18 10:55 -0700
      Re: Parsing javascript file off the main thread Georg Kothmeier <georgkothmeier@gmail.com> - 2016-09-19 00:28 -0700
        Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-19 08:15 -0700
          Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-19 19:46 +0200
            Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-19 11:00 -0700
              Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-19 20:42 +0200
                Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-19 11:53 -0700
                  Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-20 00:01 +0200
                    Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-20 12:02 -0700
                      Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-20 21:26 +0200
                        Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-20 17:38 -0700
                          Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-22 06:46 +0200
                            Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-22 05:53 -0700
                              Re: Parsing javascript file off the main thread Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-23 02:42 +0200
                                Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-23 09:29 -0700
                  Re: Parsing javascript file off the main thread "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-20 12:00 -0700
                    Re: Parsing javascript file off the main thread Scott Sauyet <scott@sauyet.com> - 2016-09-21 02:24 +0000

Page 1 of 2  [1] 2  Next page →

#31383 — Parsing javascript file off the main thread

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

[toc] | [next] | [standalone]

#31384

georgkothmeier@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)

[toc] | [prev] | [next] | [standalone]

#31386

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

[toc] | [prev] | [next] | [standalone]

#31387

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

[toc] | [prev] | [next] | [standalone]

#31391

Georg Kothmeier <georgkothmeier@gmail.com> wrote on 17 Sep 2016 in
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. 

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

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#31399

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.
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>

> 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.

[toc] | [prev] | [next] | [standalone]

#31401

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.
 
> > 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>

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. 


> 
> > 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.

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.

[toc] | [prev] | [next] | [standalone]

#31403

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.

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.

When the script tag is at the end of the body there is no need to use defer or async.

[toc] | [prev] | [next] | [standalone]

#31404

Michael Haufe (TNO) wrote:

> On Monday, September 19, 2016 at 2:28:56 AM UTC-5, Georg Kothmeier wrote:
>> 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.
> 
> When the script tag is at the end of the body there is no need to use
> defer or async.

Nonsense.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31405

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?

[toc] | [prev] | [next] | [standalone]

#31406

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*.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31407

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:
<https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer>

[toc] | [prev] | [next] | [standalone]

#31409

Michael Haufe (TNO) wrote:

> […] 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:
> <https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer>

Yes, you should *read* that to clarify your misconceptions.

(JFYI: Posting a URI without further comment is _not_ to “present [one’s] 
reasoning”.)

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31418

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. 

[toc] | [prev] | [next] | [standalone]

#31419

[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

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31420

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.

[toc] | [prev] | [next] | [standalone]

#31424

Michael Haufe (TNO) wrote:

> On Tuesday, September 20, 2016 at 2:26:47 PM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> > 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.

<https://yourlogicalfallacyis.com/tu-quoque>

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>

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31428

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.
>
> [...]
>
> 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

[toc] | [prev] | [next] | [standalone]

#31432

Michael Haufe (TNO) wrote:

> On Wednesday, September 21, 2016 at 11:46:41 PM UTC-5, Thomas
> 'PointedEars' Lahn wrote:
>> 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

Score adjusted

-- 
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.

[toc] | [prev] | [next] | [standalone]

#31436

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > Six
> 
> Score adjusted

Predictable as usual

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web