GoogleChromeLabs
Consider using jsgo.io for script hosting
Hi!
Good job on this project, the site looks splendid and it serves as a great example of how to use Go and GopherJS, and I imagine it could eventually use webassembly as well.
Anyway, while the script served to me in my testing is around 318K, which is certainly acceptable, I think it'd be interesting to try using jsgo.io to upload and host the scripts, it has some really clever package splitting logic and puts the scripts on Cloudflare. My grpc-web demo site is hosted this way (it also uses myitcv/react): https://grpcweb.jbrandhorst.com.
What do you think?
Yes, great work @housseindjirdeh!
@johanbrandhorst as we discussed on Slack, it looks, from my very amateurish investigation, like https://gohackernews.com is being served via Fastly so I'm not sure there would be any benefit from the CDN-aspect of jsgo.io. Indeed because of the package splitting, the overall size might, as you mentioned, increase slightly.
Thanks so much folks, means a lot :)
I stumbled on jsgo.io a while ago and have been meaning to give it a shot (cheers @dave for building it) but also wondered if it would make much of a difference in performance. If there was a way to defer loading some of the packages that are split, that would be amazing but I don't think that's possible 🤔
Ha loading packages at runtime is definitely possible... I ran some tests a while ago... it’s pretty complex though because you need to get the dependencies for the new package minus the ones you already have. It worked though. I’m going to use this technique for loading editors at runtime in github.com/dave/frizz
I was looking at converting this project to jsgo but got stuck with all the node build stuff. I stay away from node unless absolutely necessary 😉
Aha that's my fault, there really was no reason for me to include the Node build stuff (I might use it to hook into a CI later but it's not necessary for folks to know to get this project up and running). Updated the README.
Definitely going to keep an eye on frizz. Loading the correct packages at runtime would be an amazing thing to see 😍
@housseindjirdeh
If there was a way to defer loading some of the packages that are split, that would be amazing but I don't think that's possible
Is this a problem at the moment?
What impact would you expect the deferred loading to have?
Got it working! https://jsgo.io/dave/go-hackernews
Recompile here: https://compile.jsgo.io/dave/go-hackernews
Source: https://github.com/dave/go-hackernews
@myitcv Not necessarily a problem, just looking for ways to improve performance where possible. The bundle sits at 318 KB gzipped so it isn't the smallest app in the world. Code-splitting and lazy loading/deferring any packages if possible might just help.
But there also things that can probably be solved upstream that might make this a non-issue, such as better dead-code elimination.
Nice one @dave! Total bytes sent did increase slightly which was expected, but still pretty cool to see :)
Yes with a cold cache the jsgo page will be a bit bigger, because it has to disable DCE (dead code elimination). The benefits come when you deploy a new version of your app, and your end users only have to download the JS for the packages that have changes. The go-hackernews app is pretty small so on a fast connection there wont be much of a difference, but as the app gets more complex (e.g. https://play.jsgo.io/ is ~2MB of JS) or with a slower connection it becomes more of a benefit.
BTW if you really wanted to optimise the performance of jsgo, you could take the contents of the loader js and add it to your index page. This would change on every deploy though, so tricky to get into a deploy pipeline.
Also, jsgo could probably do with some additions to support things like the preload and dns-prefetch preconnect hints you have in your HTML.
Agreed, there's always the benefit of being able to preload the more critical packages when they're split up and things are more granular 👍🏾