search

gopherjs / gopherjs.github.io

GopherJS Playground
https://gopherjs.github.io/playground/
23 stars 12 forks source link

Playground: Pull all packages in one XHR request #8

Closed ajhager closed 8 years ago

ajhager commented 10 years ago

There is a noticeable pause when loading the Playground, where an XHR request is being fired off for every .a file. While this is happening, the UI is frozen. It should be possible to gzip all of them and use just one request.

dmitshur commented 10 years ago

Three thoughts:

  1. Compressing the .a files seems to make them significantly smaller, so it's definitely worth it!
  2. Often users may take time before actually pressing the Run button, long enough that if this XHR request is done async in background, it will be able to finish by the time they press Run. But loading it in background will allow users to start typing code/interactiving with the UI sooner. Of course, if they do press Run while the request isn't finished, it will need to wait for it. Only downside I see is extra implementation complexity.
  3. I think it would be super helpful and neat to include (or allow them to be fetched in case they are imported) some very common GopherJS libraries, like XHR, DOM, WebSocket, etc.
ajhager commented 10 years ago
  1. The time it took to unzip 2mb of data far outweighed the time it takes to download 8mb of data. Instead, I have simply tar'ed the directory. It is able to build the package index before the code displays, but I am also disabling the compile button until it finishes. Either way, the UI is responsive from the start.
  2. Another optimization could be saving the package directory to localstorage, and only repopulating if the xhr mod time has changed.
  3. I agree about this, but I think it probably needs careful consideration. Hopefully some day we will have a web focused std library that is cohesive like dart's. Until then, users of the playground shouldn't have to implement an interface to, for example, Websockets just to explore them.
ajhager commented 10 years ago

Also 3. Part of my playground work is to make a command that lets you generate a playground archive with whatever packages you would like.

neelance commented 10 years ago
  1. Seems like GitHub's CDN did not apply gzip transfer encoding to the .a files because it considered them as binary files that can't be compressed well. I applied a workaround by giving them the extension .a.js instead. Now gzip encoding is applied according to the Chrome Dev Tools network tab.
  2. In general, the frozen UI is not because of the file downloads, those happen in the background. It's because processing the .a files takes a long time and since it is JS, the UI can not continue as long as JS code is running. Not much that we can do about it, as far as I can see. I already tried to optimize this as far as I could. It's also only downloading and processing the .a files that it actually needs, further packages are loaded on demand when required. On page startup, it loads the packages for the initial example, because I wanted to rather have a delay at page load than when the user clicks on "Run", because it makes a bad impression if it takes so long for the code to execute.
  3. As already mentioned in 2., the .a files are loaded on demand. So we can easily provide more packages without impacting the performance.
dmitshur commented 10 years ago

Until then, users of the playground shouldn't have to implement an interface to, for example, Websockets just to explore them.

Well, they don't have to, since js package is there. But once you're used to using the dom or websocket packages (and all your local code uses them), it is annoying having to fall back to rewriting it the raw low-level js calls. For me, it's often a deterrent that stops me from using the playground for a particular small experiment.

ajhager commented 10 years ago

Sorry for the noise @neelance. The pause was indeed from the processing, not the requests. It is clear you have put a lot of thought and work into the playground. I may come back to this later after the new features are done.

neelance commented 10 years ago

No problem. It's good that you are looking into these kinds of issues. :-)

broady commented 8 years ago

Still a problem with HTTP/2 being a thing?

dmitshur commented 8 years ago

I think having packages be separate files is actually benefitial if we're using HTTP/2.

For that we need to support HTTPS and HTTP/2 on server. I know it's easy when hosting your own site with Let's Encrypt and a Go web server, but now sure about GitHub Pages.

Nevertheless, the difference between the two approaches is not very significant, and HTTP/2 is the future, so I think it's fine to assume we'll eventually have it. So there's no point in trying to switch to one large file now.

dmitshur commented 8 years ago

I'll close this because of above, but if someone has additional thoughts, feel free to comment or reopen.