Anecdata from a JS developer who has been in this ecosystem for 14 years.
I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.
Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.
Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.
Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.
Make sure you have a run of govulncheck [1] somewhere in your stack. It works OK as a commit hook, it runs quickly enough, but it can be put anywhere else as well, of course.
Go isn't immune to supply chain attacks, but it has built in a variety of ways of resisting them, including just generally shorter dependency chains that incorporate fewer whacky packages unless you go searching for them. I still recommend a periodic skim over go.mod files just to make sure nothing snuck in that you don't know what it is. If you go up to "Kubernetes" size projects it might be hard to know what every dependency is but for many Go projects it's quite practical to know what most of them are and get a sense they're probably dependable.
I'm going almost the same direction, for the same reasons. Golang seems very interesting. Rewriting some hobby projects to get an understanding of the language and ecosystem. I'm on Node/webpack now and don't love where things are going.
Honestly, the fact that we have models that can coherently reason about this problem at all is a technological miracle. And to have it runnable in a 1.15GB memory footprint? Is insanity.
But the fact that we have convinced a pig to dance, and trained a dog to provide stock tips? That can be improved upon over time. We've gotten here, haven't we? It really is a miracle, and I'll stick to that opinion.
This is a confusing comment. Interoperability and bad actors are separate concerns, because you get bad actors in systems of all kinds, not just in interoperable systems. Paywalling a system does not necessarily mitigate bad actors, either.
It says something about modern Congress that when one of the powers explicitly granted to Congress became relevant for the first time in 100 years, their first instinct was to delegate it away to the President.
Well, in React specifically, you're describing the Flux architecture, which I've implemented manually back in the day. Its modern-day successor is Redux, which does exactly what you describe, but we found that it introduced more complexity rather than remove it.
I don't know about the other UIs, but on the web, some things impinge on the model you (and Redux) are proposing.
One thing is: you, in the gamedev world, have the luxury of having a frame buffer to write to. You fully control what gets rendered. Unfortunately, React and its cousins all have to deal with the idiosyncracies of the legacy browser environment. You have CSS, which applies and cascades styles to elements and their children in often non-obvious ways, and is a monster to deal with on any given day.
In addition to CSS, you have multiple potential sources of state. Every HTML slider, dropdown, input field, accordion, radio button, checkbox has its own browser-native state. You have to control for that.
On top of all of this, the browser application is usually just a frontend client that has to interact with a backend server, with asynchronous calls that require wait-state and failure-state management.
One thing that's in common with all of the above problems is: they're localized. All of these things I'm describing are specific to the rendering layer and therefore the component layer; they are not related to central state. A central state trying to capture all of these problems will fail, because component state has to be wrangled locally near where the HTML is; CSS also is component-level; and the network states are often very closely related to each component. If we maintain a central "game state", the data complexity just proliferates endlessly for each instance of the component.
So, the default these days is to keep state very close to each component, including network state, and often business logic also gets sucked into the mix. I try to avoid putting business logic in components, but people do it all the time unfortunately. But it does add to the complexity.
In other words, there is -real- complexity here, stemming from the fact that the web was never built to be a distribution+execution layer for rich applications, but evolved to become exactly that. It's not just bad application architecture or bad decisions by React maintainers.
Maybe I'm wrong, since I'm not a game developer and don't see what you're seeing on your side.
I'm sympathetic to "it's the browser's fault", to some degree. I understand that the browser locks you into certain constraints, and I understand that I don't understand much about those constraints, because most of the extent of my experience with web development is using a canvas and a couple of fundamental APIs to render my games via WASM as web is one of my build targets (and I do know that approach is undesirable for regular web pages). I can see how there might be unavoidable complexity there.
What I still don't understand is why the browser is that way in the first place, and why all of the native, not-browser GUI frameworks that people use are also that way. People opt into using React Native, even! But the regular run-of-the-mill frameworks that are widely used for native applications are also annoyingly complex to work with, so much so that I've repurposed my engine for when I want to create native applications and have been working on building a desktop UI framework within it that follows the same model I use for games (albeit nowhere near production-grade, just covering "the cases I need").
> the browser application is usually just a frontend client that has to interact with a backend server
I will note that this is a constraint that is shared with gamedev. Most multiplayer and even many singleplayer games these days are server-based.
It is rare to find a comment on shunyata on HN. I wanted to deepen the discussion on that, instead of move into geopolitics or the justification of status quo reality. I think youre very correct that war is unnecessary, if only we realize the illusory nature of many of the things we desire or hate.
Shunyata means everything is empty. Empty of what? Empty of inherent, independent existence. That means everything is connected -- not only connected, but mostly illusory, sitting on top of a reality that cannot be understood in terms of objects, processes, distinctions, or boundaries between objects. Sometimes, this connection takes on strange forms.
For example: The horrible reality of war was a direct cause for your compassionate unease. I.e. war acted as a cause for compassion. This is strange. How do we reconcile this disturbing relationship, where a compassionate response is directly the child of war? In other words, horrific war has given rise to compassion, and this is a causal relationship, in the same way that a child arises from a mother. So, violence and love can arise from each other? What? Are they not supposed to be opposites?
The next step is a bit more provocative. Shunyata seems to imply that, since everything lacks inherent and independence existence, then suffering is not a part of the human condition. Instead, it is a mental construct. It isn't that the suffering of humanity does not exist; it's that it is constructed by the mind.
Deleuze and Guattari offers an interesting viewpoint on this. There are various intensities that do arise naturally. Injury, for example, is an intensity. But, suffering itself is not "really-real" unless we reify the intensities as suffering. And eliminating suffering partially involves the non-reification of intensities into suffering.
Obviously, easier said than done.
Anyway I'll leave it there. It's probably quite easy to destroy my points here, so I would appreciate it if people steelmanned my comment instead of strawmanning it. Shunyata is a genuinely useful discussion from a mental health and human flourishing standpoint. And has some very interesting and rigorous logic behind it. (see Mulamadhyamakakarika by Nagarjuna)
This is a great idea! I'm building something very similar with https://practicalkit.com , which is the same concept done differently.
It will be interesting for me, trying to figure out how to differentiate from Claude Cowork in a meaningful way, but theres a lot of room here for competition, and no one application is likely to be "the best" at this. Having said that, I am sure Claude will be the category leader for quite a while, with first mover advantage.
I'm currently rolling out my alpha, and am looking for investment & partners.
I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.
Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.
Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.
Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.
reply