This is why PROFILING is critical for high performance JavaScript

[@JoshuaMorony]

Next newsletter goes out tomorrow, join here: mobirony.kit.com/4a331b9076

[@AlainBoudard]

Great use of the flame graph ! Not easy to use ... Nice content Joshua 👍

[@Brumry]

this was very good. I would like to see more videos on browser debugging Angular code, as overall it is hard to find resournces on this topic.

[@thegreatxc]

Liked before watching. Kept the like after watching I recently explored flame graphs for the first time and noticed a lot of forced reflows happening. A video about those will be amazing!

[@RasmusChristensen-n5j]

I really like your game dev videos :) and the new drawing in exalidraw is really good :)

[@tertiusdutoit9946]

Dude that was super useful, Thanks!

[@TheTugBoat]

Great video...the algorithm strikes again as I was JavaScript profiling yesterday for the first time ever! (In 20 years!)

[@michalwroblewskimobi]

This is a really good explainer for performance tab!

[@nikpil93]

I want to really thank you for providing this level of helpful and informative content!

[@leonardozivieri1449]

Thanks Joshua for all the videos. They are helping me a lot with coding and with my english.

[@marcwinner567]

Thanks for showing good profiling! The video makes it looks so easy though :D

[@kubagrott]

damn, the visual aspect of your game is so much improving with time, keep going! Honestly i couldnt complain if you would try some more commercial engine like godot in the future. Godot is super light and if im right there is some implementation of signals. I would love tutorial or recorded journey of you learningit like I absolutely love all of your other videos (you are on my top 3 list of angular yt channels, beside ngconf and manfred steyer).

[@JoshuaMorony]

Thanks! I considered using more typical game engines, Godot definitely would have been a contender, but partly I wanted to stick with JS for the challenge of it and pushing my knowledge of JS more. Hopefully I don't end up regretting it, but I'm getting into stuff like WASM now for performance optimisations so I think I probably won't hit any unsolvable performance bottle necks for this game

[@Novalifee]

Super cool video Joshua! I love watching other Angular devs going bananas outside the classic CRUD webapp! I'm really curious of your journey. What parts of the game are Angular components? Every lazy route is a scene, or...? Looking cool mate!

[@JoshuaMorony]

At the moment the only Angular component is the inventory bar, but most/all of the UI I add to the game will be Angular. Most of the game architecture is handled by Phaser, and Phaser is just rendered onto a canvas in the main app component. Then I also have some Angular services for handling data/communication between Angular and Phaser.

[@Novalifee]

@@JoshuaMorony That's interesting! I will keep a close look, if you make a series about this! I once tried something similar, but far more basic than this one. One question I'm curious about. Did you have a significant performance boost after going zoneless? Are u using signals in combination, or just RxJs? I wonder if there is any impact at all with the change detection, if Phaser gets the control of most of the inputs and the render is within a canvas...maybe manual change detection is enought? Enjoy the journey, and let us know how it goes! 😄

[@TheBswan]

Great video, though surprised you commented on console.time inaccuracy without also mentioning the browser performance API which solves the issue.

[@JoshuaMorony]

I'd forgotten about its existence, I'll try to remember to give that a go next time

[@vredurs]

I’m currently working on an enterprise application where some of the backend code/business logic is from 2008 up to now. We have several sql queries that can take very long time and this results to that some api calls takes a very long time. This is not something that we can do something to fix in a short time. How would you say that using the profiling tools in the browser to inspect the performance in our angular frontend would work? Would it be easy to exclude the actual time for request/response and focus only on the frontend application?

[@JoshuaMorony]

You can use the Network tab to see how long the request/response is taking, and I imagine likely it is the backend that would be taking a long time to respond and you would see that in the Network tab. But if the request is executing quickly enough, then you could use the Performance tab to see what might be causing the slowdown on the front end

[@diadetediotedio6918]

Usually the problem of performance is not a memory leak, but rather a "processing leak", you generally want to search in any kind of thing that does bulk processing of some sort (in this case, it was an event handler). A memory leak usually starts to be a problem in gigabytes of wasted memory. Also, talking as a fellow functional programming appreciator, have you used ECS? It is an imperative architectural thing, but I personally thing that if some imperative code is very close to declarative code, ECS would be it. Maybe you would have some fun trying it and checking the patterns that evolved with people using it.

[@JoshuaMorony]

I keep bumping into ECS actually and got the sense that maybe it's a pattern I should check out/might like or perhaps would be better than what I'm doing. I probably will look into it at some point.

[@JoshuaMorony]

Also, you seem like the kind of person who might have used Haskell, it has been calling to me lately and I probably need someone to convince me going down a Haskell rabbit hole is a bad idea

[@diadetediotedio6918]

​@@JoshuaMorony ECS is very fun to work with, hah, you tend to start working with components as 'triggers' and signalers, and as it induces tiny components it also tends to induce very composable code in the end, it is good for complex games with a lot of reusable parts (and I think in general as well). It also makes you think a lot on how to architect a given problem (like declarative code usually does), it is a "different way of thinking". And about the second comment, actually I never used haskell. But you are not totally off, I have used some functional languages like F# and OCaml (I quite like them both, F# is very inspired by OCaml and OCaml has a great amount of good ideas and implements some very interesting concepts like effect systems). Both are considered more "pragmatical functional languages" tho, which is more of my personal style, so if you want to have the "pure FP" experience you are probably better trying haskell. But if you want to experience some of those niceties of functional languages and have some fun I highly recommend using either OCaml or F# (those are the ones I can directly recommend by having used to higher degrees). F# is more "OOpy" as it is closer to C# (and has many things like classes and inheritance that you may or may not be happy to have) but in programs I almost never use this OOP side of things. OCaml is more "raw" and in my opinion a bit less intuitive to get started on (but it has cool stuff, like what I mentioned earlier and ad hoc unions). Of course, I'm only talking about the shiny things, there are difficulties in doing FP, and the mentality to code needs to shift a bit in order to make sense of things (like using recursion, getting used to the automatically curried functions, custom operators, putting to good use the powerful type systems, etc), but as long as you understand the quirks (as in any paradigm) you will be fine. This is what I can say, hope it is of some help hah, if you go down this route I think you will like it.

[@JoshuaMorony]

@@diadetediotedio6918 that's a great overview thank you, and definitely helps give some clarity - OCaml was another one that has been calling to me, and I think might just give me what I'm looking for in regard to FP, without (I assume) torturing myself by learning Haskell likely to no real practical end (though I'm sure it would still be a useful experience)

[@geekybruce4819]

what is shallow and retained size in laymen's term?

[@JoshuaMorony]

Shallow is how much memory the object itself is using directly, and retained is how much memory in total it is causing to be held via other objects it is holding a reference to (and therefore preventing those from being garbage collected)

[@edbzn]

Nice video as always, but please stop translating the title and everything, it's so weird in French, we don't even use those terms actually 😄

[@JoshuaMorony]

Unfortunately KZbin is doing this automatically, I don't think I'm able to prevent this from happening

[@soyaaroncervantes]

Oh gosh… I hope they can let you decide if you want to do it. it’s really annoying when it starts in Spanish 😂😂

[@zero14111990]

beautiful

[@PileOPoop1]

Idea here, why not create the particle emitter only after the item is triggered to emit particles? If the emitter is not on, it doesn't need to exist.

[@JoshuaMorony]

Yeah that's definitely something I could do, though with the number of emitters I have at the moment (at least when they are being cleaned up) it doesn't seem to be a problem

[@mynameismads2516]

High performance javascript is an oxymoron