I do game development consulting now and then (speedrun mode, leaderboards, randomizers, supporting infrastructure, etc.) and it's really nice to see Godot mentioned here. I don't often make projects from scratch but it is genuinely a pleasure to use.
In regards to developing your own engine - it's almost never more efficient to do so nowadays, but it is almost always significantly more fun. If the author has enough wealth accumulated to quit their job and work on a passion project full time, I imagine they can afford to do something just for fun as the baseline.
Most hackers I know write software for pretty much any other OS because of how much easier it is than writing software for Windows, not because they're uppity. Some may be ideological purists, sure, but I think you'd be very hard pressed to find a hacker that says the developer experience on Windows is easier/nicer/better than the developer experience on Linux or MacOS.
I believe the implication there was that low-performers favored by upper management (for reasons like nepotism) were kept as opposed to productive employees whose performance is not reflected in "tick the box" KPIs.
> Till this day, no one has given me a straight answer on why they choose react beyond the dubious claims of performance++. Or even why build a web app to begin with. Nor have the users been asked if they want native-like apps on the browser.
The main reason is cross platform compatibility for things that don't need to make system calls. Ultimately I would prefer to distribute statically linked Go binaries that are command line applications, but if I was asked all "UI" would be a REST API with a manual. The market finds web applications are successful and lower the barrier of entry, and so they're made.
> I complain but I use react everyday on a web app Im sure no one cares if it loads 400ms faster than a server rendered jinja template.
With NextJS and server side rendering + static optimization I find that time to first (contentful) paint is the same or faster than Jinja without me having to configure a thing.
> Now we have massive overhead, npm libraries for everything and only god knows whats going on in the node modules folder
npm/yarn provides a pretty good developer experience but the way it accomplishes that is a touch horrifying, I agree. Babel and Webpack I find bring it most of the bloat, which is probably a good thing as you're not shipping those dependencies in production bundles. It definitely chews up storage space on the local machine though.
> keeping up with the joneses by using Typescript - why use typescript when Java or C# do static typing so well? I can't ask silly plebian questions like that.
Just to get out in front of it - I do not like Typescript. I find Typescript to be a waste of time. JS's type system is broken as hell, but in just the right way for web development. It makes it flexible and easy to write. With Typescript I feel like I spend most of my time making the compiler happy instead of generating any value for the business or myself.
> I would love to see a clear explanation of why this is viewed as true. I've seen this stated many times, but generally in a way that seems framed to an audience already inclined to accept it as true.
To the credit of those that are skeptical, it is really difficult to explain exactly how much more productive it is without having experienced something it. The closest comparison I can make is how SCSS feels coming from plain CSS - it's like all of the things that you wish were easy are suddenly easy, while still being based off of something that you are familiar and already productive with. For people coming from traditional web development, I find that Svelte is the most comfortable tool for them to learn.
> I've never seen an explanation of this written and framed for people who wrote such applications before things like React or Vue existed, and genuinely don't understand (and want to) why the model they present is viewed as so much simpler.
I wrote such applications before React and Vue existed. I don't think I could ever go back. I would not describe it as a simpler model however - you're effectively writing two applications that communicate together to make one. The benefits you get for that are beyond worth it in my opinion. Assuming that you're using NextJS or something else that removes all of the boilerplate configuration, almost all of that complexity is hidden from you unless you need to modify it.
I don't know if I would be able to do very well explaining it myself, but generally - it allows for a more clean separation between systems. My backend exposes an API that my frontend can communicate with over background HTTP requests. I can swap out that backend on a whim (from Django to Rails to Express to Gin to...you get the picture) as long as it exposes the same API. With traditional web applications, I'd have to port over my templates and structure and state management system.
Most people don't switch backend frameworks on a daily basis though, I know I certainly don't. Some of the things that I enjoy are:
- Easier temporary messages/error handling (flash messages handle a limited version of this in traditional SSR environments)
- Greater control of how my data is structured and posted (forms are simple enough once you learn them, but having your data structure dictated by DOM structure is less clean in my opinion)
- Handling more complicated state is much easier - making a wizard interface with dynamically added and removed sections/questions doesn't need a large series of separate templates
- Component structure is just better to work with than template structure (expanded upon below)
The real selling point for me is removing templating languages from your templates. I don't have to worry about what Jinja considers to be an acceptable replacement for control flow, I'm using a language that I already know and is fully integrated with the entire rest of the environment.
> I've genuinely looked for this, and I've found only either presentations of "here's how it works, doesn't this seem better?" (to which the answer always seems like "no")
Generally speaking, the larger and more complex your business requirements are, the more easily you can justify using an SPA framework. Every presentation I've found on that gives only trivial examples, likely for brevity.
> or exhortations about how CSS and to some extent HTML are obsolete constructs except as tools to be manipulated by JavaScript.
I believe that idea is part of the "make everything JS!" cargo cult. For apps that have very simple interactions, I use plain HTML+CSS and no JS. Use the right tool for the job, and all that. With that same mindset however, I'd be very hard pressed to say that there is no place or justification for the Reacts and Vues and Angulars of the world.
Hacker News is a phenomenal source of hatred for using modern browser features and standards. Any amount of javascript is defined as bloat and should be strictly optional eye candy - completely disregarding the fact that UI and state management frameworks like React have made developing the sort of advanced applications we demand exceptionally easy.
Does a personal blog need React or Vue? No, and my blog is made by a static site generator (Hugo, specifically). Do most web applications built nowadays need them? Almost 100% of the time for non-trivial applications, yes. You can do it without any JS, but with that same ideology you can also write your desktop applications in x86 assembly.
Ignoring your deliberate misgendering of a nonbinary person, they didn't get to keep their job and income. They also permanently lost both of those (and all future potential for those), along with their life.
If you're going to make bad faith comparisons to racists getting fired for being racists, at least have the audacity to point out what you think their offense was here. As far as I can tell, the only thing they did "wrong" was to be emotionally vulnerable and in the sights of a dedicated hate group.
One could provide an overly-reductionist definition of nearly anything to make it sound innocuous. "Gossiping" in this case goes so far as to be incorrect. The post goes into detail on this and says that they targeted Near and the people close to them by doxxing them, harassing them, and specifically seeking out people they thought that they could convince to commit suicide. Gossiping is "rumor or talk of a personal, sensational, or intimate nature." This is a targeted campaign of harassment.
Most would agree that someone who verbally and mentally abuses their spouse to the point of suicide is responsible for their death, or at least played a significant role in bringing it about.
This is not a matter where somebody took their own life to make the point that their opinion is superior to their critics. This is a matter where people sought out and abused someone in an emotionally vulnerable state that saw suicide as their only way to escape from that abuse.
Proton does an excellent job! Something to consider is that many people (myself included) will offer consulting services to help get your game running natively on Linux with as little effort from you as possible. I personally offer that free to indie developers because I love seeing more native Linux support, but this kind of thing is often not very difficult for someone familiar with the target OS.
I'm curious as to what kind of game engine you're using where targeting Linux isn't as simple as choosing it in a dropdown menu as well, most modern engines support that very well.
I'm unsure how I feel about classifying an entire game engine as middleware. For most engines (Godot included!) building your code for a different platform is as easy as changing your target in a dropdown menu.
I'm also deeply curious as to exactly how many indie game developers are writing code that interfaces directly with these low level systems and graphics APIs. In my experience, building cross platform games (I've shipped from Unity, Unreal, Godot, and XNA/MonoGame) is trivial and the framework handles 100% of the complexity of porting. From the sounds of this comment thread, everybody is writing their game in raw shader language and then having to port that to Vulkan or OpenGL.
> Just because you don't feel the weight of electron apps, it doesn't mean it's not there. You just have a powerful computer.
I definitely don't intend to imply that Electron apps aren't inherently heavier - they are, hence the second paragraph of my initial comment.
> I switched from Slack / Discord to Ripcord and, even though the UI is not great, it's much cheaper to run. It's using 80mb of RAM with multiple slack organisations open and multiple discord servers.
I actually switched to Ripcord for Slack myself! I find it doesn't provide a comparable experience to the first party Discord app, but it beats Slack all day every day. Slack is an excellent example of a poorly made and unoptimized Electron application, in my opinion.
Hacker News is probably not the best place to ask this question, as it's very much "JS bad" as a service. Take any advice received here with a grain of salt. With that out of the way - the only correct choice is the one you're more productive in. If you find that QT fits your workflow better, go with that. If you're more familiar with web technology and want to work within your comfort zone, use Electron (or Tauri or Neutralino or NWJS or...you get the point).
QT has much less overhead to it, but it's not exceptionally difficult to create an optimized Electron app that people will enjoy using. Discord and (in my opinion) Visual Studio Code are good examples of well-optimized Electron apps.
All else held equal, I would personally choose Electron (or rather Tauri) if just by virtue of "you are forced to separate the display tier from the business logic."
That definitely works for capturing it! I run my Switch through a capture card for that, but sys-dvr works as an excellent free replacement if you've got a stable connection.