I'm pivoting from C# and unity to java and webdev because i want to start getting a job in 2025. I still want to make games and i draw pixel art everyday in the evening, so i hope react and node is a good place to start. At least my portfolio will transfer enough to get webdev job, maybe
modern devs not caring about performance which results in constant need for hardware upgrade is big enough problem already, please don’t make me buy 4090 to play a platformer game
With Tauri V2 its even easier to build for Desktop mobile app from a website/apps it would be great if these rendering engine webkit chromium gekko are as optimize as possible to be close enough to native rendering
I'm really hoping that the servo view ends up coming along soon. I am wanting to get WebGPU-powered games that happily run on Steam, on Windows/Mac/Linux, via Electron, to run on SteamDeck. Chromium has issues using the controller as anything other than mouse/keyboard, without the game owner making admin flatpack permissions edits. Deno + SDL is fine, but there's a lot of "Deno doesn't do WebAudio, so carefully write a service that juggles the browser version WebAudio, and FFI bindings for _______, and manage the build system that will swap them out" going on. The FF / Safari webviews aren't ready yet, wgpu is and has been behind the spec, for the API and shaders, et cetera. Very long road for one controller. And I am sure, no sooner than I replace it, that Chromium will fix it.
@@JSLegendDev not exactly, but the result is the same. Chromium, the browser, has issues with Flatpack (the Linux package server). The lib that Chromium uses to read the gamepad state is blocked in Flatpack, by default (basically; legacy IO/security concerns/etc). Steam has custom controller configs, so Chrome browsers have a profile that binds the left stick to WASD and bind the D-pad to arrows, and the mouse and scroll wheel are the trackpads... But to get it working as a dual-analogue, the user needs to go into desktop mode and enable features from a sudo command. You can Google for Reddit users finding solutions for getting GeForce Now (electron) working with SteamDeck. This could be a solvable problem, switching the gamepad reader to a different lib on Linux, but also, it's Google. Who knows when that will be a high enough priority, on Linux, to happen.
Hey man, I appreciate your tutorials, they are super helpful! One thing I haven't seen you implement is rotation (maybe you have, I just don't know where). Like making a topdown zombie game, where the player image rotates in its center, based on the mouse position. How would you implement that?
What do you mean exactly? Are you referring to WebGL builds that you can get with Unity/Godot, rendering your game in WebGL with a game framework like Kaplay/Phaser/Excalibur or making your game in raw WebGL?
the whole point of react was solving the problem that full page rerenders are too slow on the web. Games are inherently realtime so react is by definition unnecessary. If you really want something react-like for gamedev you should implement immediate mode UI where the UI is defined with jsx nodes
Implementing immediate mode UI where the UI is defined with jsx nodes, seems like a lot of additional work while I could just use React. React works well for what I'm trying to do (Use it for the UI on top of an existing game). While my games are often realtime my UI is often not, I only need to update it when certain events happen in my game. The draw of using React is the ease with which you can handle UI states and break down your UI into reusable components. Also, there are plenty of game types where they are not inherently realtime. For examples, games like Ace Attorney, Professor Layton, (insert visual novels of choice), BuriedBornes - Dungeon RPG, etc... So in the end, it's about checking the specific requirements for the game you want to make and see if you gain from using React or not.
"unnecessary", sure. But you can also hand-write your own WOFF/OTF/TTF/etc parser and SDF builder, and your own typesetting and rendering library, and your own accessibility library, and your own rect layout and styling library, and your own raster-effect library, and your own tweening library, which supports all color / sizing / layout / UI state-change happenings in your dynamic and animated and accessible menu systems and subsystems... or you could do not that. John Carmack himself became an advocate for just using React, versus the in-engine solutions offered by, say, Unity, due to productivity increases. In 2017. Not even modern React; 7 year old React. Not even browser games; Oculus Rift UI.
@@SeanJMay Not saying you should make you own renderer from scratch, I just don't understand the problem react is solving here. If you're using a renderer like canvas then instead of implementing a react-canvas layer you can simply rerender your entire app on every frame and ditch all the weird signals and vdom diffing stuff. The only way I can't see that being objectively better is when you also need to support a slow fallback renderer like tty or DOM But if what you're getting at is that you should be using a webview for UI instead of a native renderer: I personally disagree as CSS limits creative freedom. I love when games have unique UI, and by using web tech we're making that significantly harder to accomplish. But hey I know every AAA studio under the sun does it these days so that's just a personal gripe I guess
@@pokefreak2112 you don't have to build the rest of the game in React at all, though. And you don't have to do any of the v-dom diffing. And your canvas doesn't need to be inside of a react component. React is 100% good with being bound to from the outside. When I use React, either in a WebView, or on a page, directly, it listens for an event, loads the correct view according to however you wish to route it, and fires back user interaction events, and I will give it access to a "singleton" (by convention, not construction, for system-level fetching of information from the actual game state). Regarding creativity, if you wanted to have your actual viewport canvas draw literally anything and everything, while the React is just doing text and button and input rendering, you can do that. Also, with WebGPU, you can have hundreds of canvases bound to the same device, all updating as fast as you can feed the command encoders into the queue on a single thread (really, really fast, if most of your work is render+compute). So you could put transparent canvases in the React view (real time graphics-settings slider adjustment feedback), or on top of your primary canvas, behind the React view, or whatever you would like. Personally, I think CSS is plenty powerful, given that writing a text compositing and constraint-based layout system that scales to any arbitrary size or shape (for multiple screens), on top of handling pretty much any user event aside from joystick based button-navigation... css has gotten stupidly powerful in the past few years... to the point where you could do kinematic animations with it, if you wanted to declare all of the trig in CSS... Yes, if you want to build a custom particle system that your text is made out of, and when you select an option, it blows up into the voxels (AI autouncorrect has a long way to go) the text was made of, and blows away in the wind, sure... CSS can't do that with OpenType font rendering. But you are going to be hard-pressed to find something that CSS physically can't do, these days, that isn't stateful, or can't be trivially achieved by positioning text/buttons above a canvas, for cases where you want to do the Persona 5 (it was 5, right?) remake menu, but do all compositing 100% live. CSS can even do most compositing, on its own... most. Doing a 100% bespoke, by-hand menu, is fine. But again, a library is not going to give you that, and not going to give you a leg up on React and CSS... if you want bespoke, for it to feel bespoke, then you are doing it bespoke. Lack of creativity isn't because they're stuck with CSS and React. They would be just as devoid of creativity if they were using UI nodes in Unity, and have even less expressive tools for being creative, using those nodes.
I think webdev is better paid than gamedev in general. You can use React or JS to make games as a hobby or try various monetization models. You can for example, wrap your JS game as a desktop app and sell it on Steam. You can try making a gamified SAAS. For example, a gamified language learning app and earn money via monthly subs, etc... Anyway, time spent learning gamedev in React or JS is not wasted since you're still developing a skillset that is valuable for getting webdev jobs.
please make more videos related react
I'm pivoting from C# and unity to java and webdev because i want to start getting a job in 2025.
I still want to make games and i draw pixel art everyday in the evening, so i hope react and node is a good place to start. At least my portfolio will transfer enough to get webdev job, maybe
What you want to achieve makes sense. I think doing gamedev in JS/TS + React is so close to webdev.
modern devs not caring about performance which results in constant need for hardware upgrade is big enough problem already, please don’t make me buy 4090 to play a platformer game
hi, i have an idea, a tutorial of a isometric game, like Hades, what do you think?
i love your videos, keep going
Have you tried ct.js?
I'm trying to create a platform similar to duolingo, but struggling with the stage select screen, do you have any tip on it? :/
Well, can you provide more details on what you're trying to achieve?
With Tauri V2 its even easier to build for Desktop mobile app from a website/apps
it would be great if these rendering engine webkit chromium gekko are as optimize as possible to be close enough to native rendering
I'm really hoping that the servo view ends up coming along soon.
I am wanting to get WebGPU-powered games that happily run on Steam, on Windows/Mac/Linux, via Electron, to run on SteamDeck. Chromium has issues using the controller as anything other than mouse/keyboard, without the game owner making admin flatpack permissions edits.
Deno + SDL is fine, but there's a lot of "Deno doesn't do WebAudio, so carefully write a service that juggles the browser version WebAudio, and FFI bindings for _______, and manage the build system that will swap them out" going on.
The FF / Safari webviews aren't ready yet, wgpu is and has been behind the spec, for the API and shaders, et cetera.
Very long road for one controller. And I am sure, no sooner than I replace it, that Chromium will fix it.
@@SeanJMay Electron doesn't support gamepad controllers by default on the steam deck? Did I understood this right?
@@JSLegendDev not exactly, but the result is the same.
Chromium, the browser, has issues with Flatpack (the Linux package server). The lib that Chromium uses to read the gamepad state is blocked in Flatpack, by default (basically; legacy IO/security concerns/etc). Steam has custom controller configs, so Chrome browsers have a profile that binds the left stick to WASD and bind the D-pad to arrows, and the mouse and scroll wheel are the trackpads... But to get it working as a dual-analogue, the user needs to go into desktop mode and enable features from a sudo command. You can Google for Reddit users finding solutions for getting GeForce Now (electron) working with SteamDeck.
This could be a solvable problem, switching the gamepad reader to a different lib on Linux, but also, it's Google. Who knows when that will be a high enough priority, on Linux, to happen.
Please make more platformer games using kaplay
Hey man, I appreciate your tutorials, they are super helpful! One thing I haven't seen you implement is rotation (maybe you have, I just don't know where). Like making a topdown zombie game, where the player image rotates in its center, based on the mouse position. How would you implement that?
I'm preparing something regarding this.
@@JSLegendDev Awesome! Always looking forward to your tutorials
Here you go! I just published a written tutorial going over this : jslegenddev.substack.com/p/how-to-implement-top-down-shooter
Why not use WebGL builds for games ?
What do you mean exactly? Are you referring to WebGL builds that you can get with Unity/Godot, rendering your game in WebGL with a game framework like Kaplay/Phaser/Excalibur or making your game in raw WebGL?
@@JSLegendDev Yeah I mean the WebGL builds you get from Unity/Godot and embed them in your webpage like itch does.
@@RobinTheHoo They're slow usually.
the whole point of react was solving the problem that full page rerenders are too slow on the web. Games are inherently realtime so react is by definition unnecessary.
If you really want something react-like for gamedev you should implement immediate mode UI where the UI is defined with jsx nodes
Implementing immediate mode UI where the UI is defined with jsx nodes, seems like a lot of additional work while I could just use React. React works well for what I'm trying to do (Use it for the UI on top of an existing game). While my games are often realtime my UI is often not, I only need to update it when certain events happen in my game.
The draw of using React is the ease with which you can handle UI states and break down your UI into reusable components. Also, there are plenty of game types where they are not inherently realtime. For examples, games like Ace Attorney, Professor Layton, (insert visual novels of choice), BuriedBornes - Dungeon RPG, etc...
So in the end, it's about checking the specific requirements for the game you want to make and see if you gain from using React or not.
"unnecessary", sure. But you can also hand-write your own WOFF/OTF/TTF/etc parser and SDF builder, and your own typesetting and rendering library, and your own accessibility library, and your own rect layout and styling library, and your own raster-effect library, and your own tweening library, which supports all color / sizing / layout / UI state-change happenings in your dynamic and animated and accessible menu systems and subsystems... or you could do not that.
John Carmack himself became an advocate for just using React, versus the in-engine solutions offered by, say, Unity, due to productivity increases. In 2017. Not even modern React; 7 year old React. Not even browser games; Oculus Rift UI.
@@SeanJMay Not saying you should make you own renderer from scratch, I just don't understand the problem react is solving here.
If you're using a renderer like canvas then instead of implementing a react-canvas layer you can simply rerender your entire app on every frame and ditch all the weird signals and vdom diffing stuff.
The only way I can't see that being objectively better is when you also need to support a slow fallback renderer like tty or DOM
But if what you're getting at is that you should be using a webview for UI instead of a native renderer: I personally disagree as CSS limits creative freedom. I love when games have unique UI, and by using web tech we're making that significantly harder to accomplish. But hey I know every AAA studio under the sun does it these days so that's just a personal gripe I guess
@@pokefreak2112 you don't have to build the rest of the game in React at all, though. And you don't have to do any of the v-dom diffing. And your canvas doesn't need to be inside of a react component.
React is 100% good with being bound to from the outside. When I use React, either in a WebView, or on a page, directly, it listens for an event, loads the correct view according to however you wish to route it, and fires back user interaction events, and I will give it access to a "singleton" (by convention, not construction, for system-level fetching of information from the actual game state).
Regarding creativity, if you wanted to have your actual viewport canvas draw literally anything and everything, while the React is just doing text and button and input rendering, you can do that.
Also, with WebGPU, you can have hundreds of canvases bound to the same device, all updating as fast as you can feed the command encoders into the queue on a single thread (really, really fast, if most of your work is render+compute).
So you could put transparent canvases in the React view (real time graphics-settings slider adjustment feedback), or on top of your primary canvas, behind the React view, or whatever you would like.
Personally, I think CSS is plenty powerful, given that writing a text compositing and constraint-based layout system that scales to any arbitrary size or shape (for multiple screens), on top of handling pretty much any user event aside from joystick based button-navigation... css has gotten stupidly powerful in the past few years... to the point where you could do kinematic animations with it, if you wanted to declare all of the trig in CSS...
Yes, if you want to build a custom particle system that your text is made out of, and when you select an option, it blows up into the voxels (AI autouncorrect has a long way to go) the text was made of, and blows away in the wind, sure... CSS can't do that with OpenType font rendering. But you are going to be hard-pressed to find something that CSS physically can't do, these days, that isn't stateful, or can't be trivially achieved by positioning text/buttons above a canvas, for cases where you want to do the Persona 5 (it was 5, right?) remake menu, but do all compositing 100% live. CSS can even do most compositing, on its own... most.
Doing a 100% bespoke, by-hand menu, is fine. But again, a library is not going to give you that, and not going to give you a leg up on React and CSS... if you want bespoke, for it to feel bespoke, then you are doing it bespoke. Lack of creativity isn't because they're stuck with CSS and React. They would be just as devoid of creativity if they were using UI nodes in Unity, and have even less expressive tools for being creative, using those nodes.
Hello, do you think we can earn a good amount of money in game development with React or JS? I would be glad if someone knows how to do this.
I think webdev is better paid than gamedev in general. You can use React or JS to make games as a hobby or try various monetization models. You can for example, wrap your JS game as a desktop app and sell it on Steam.
You can try making a gamified SAAS. For example, a gamified language learning app and earn money via monthly subs, etc...
Anyway, time spent learning gamedev in React or JS is not wasted since you're still developing a skillset that is valuable for getting webdev jobs.
Cool thumbnail😊
Thanks! Drew it myself.
@@JSLegendDev very cool !!
thanks'
if there is one thing where react is shit, is game development
don’t do this please
react is a moving target, no thanks