Meanwhile, a ton of apps and games are completely agnostic to those cutting edge platform differences and are going to thrive in least common denominator sandboxes. And making those sandboxes easy to use for some specific style/genre/skill-level is always going to be the competitive difference between them. So the big high-level things are always going to exist too.
But… so are the near-metal abstractions that let you cut through and interleave cross-platform and platform-specific code even in high-performance paths.
You wanted the last group to “win”, but the ecosystem inevitably involves all three. There will always be something like Metal, there will always be something like Unity, and there will always be something like SDL. Winning isn’t necessary.
Yeah, I’m not buying that. It’s the story they tell you of course, but I think that’s a marketing lie.
Let’s be clear first that hardware is the platform. Your comment seems to agree with that. Note that for quite a long time, the Windows and Mac world used the same hardware (same CPU, same GPU), and therefore the same platform. They could have went together and specified a common API to work on both MacOS and Windows, and they could both expose all the hardware has to offer. Heck, if they really wanted to expose all the goodness hardware has to offer, they would give us the actual data sheets. They don’t, for various reasons that are generally tied to "IP".
They tell us sweet words about innovation, but let’s be honest they just want to lock us in.
How would programming in C++ be less pain than programming in JS / HTML / CSS? At the very least, JS code won't write past array bounds, or smash the stack.
From relevant olden times, Lisp and Smalltalk environments were closest to the ideal. They were expensive though, and nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code. But worst of all, they'd likely run even more poorly on consumer PCs circa 1995.
So, enjoy Typescript, V8, flexbox, canvas, web workers, etc. You could end up having a worse deal.
A native ABI doesn't mean you have to use C++ though. I can use Qt from Python if I like, or even from the JVM (slightly fiddlier, but doable). I can't do that with the browser.
> nobody distributed them for free, as Netscape did with the browser. They also notably lacked any protections against untrusted code.
The JVM avoids both those problems though - it had a robust security model and was distributed for free. What killed it was that corporations refused to install Java Web Start on their computers because it's a scary "application runtime". But they would happily install web browsers because that's just a "document viewer". Even though they both do the same thing!
Electron has an annoyingly heavy download size but it's not the only option for native releases of web-based apps. Windows and some other OSes have built-in browser widgets that can be used with Tauri.
The other, slightly less important thing is petty rejection of cross-platform APIs (e.g. Apple's refusal to allow Vulkan support in macOS). It's fine to additionally have platform-specific APIs, but there should be a least common denominator cross-platform standard. But middleware can smooth over this problem, while the security problem is something only OS vendors could fix.
Unfortunately, the position of gatekeeper turned out to be so profitable that vendors don't actually want to improve their security to the point where it's unnecessary. And they're also incentivized to prevent the web from improving to the point where it would threaten their gatekeeper status.
Unfortunately running things in a browser is no guarantee, even for those that would otherwise consider that a good option.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element#ob...
The things you linked are only advised against for new code:
> These features are likely stable because removing them will cause backward compatibility issues and break legacy websites. (JavaScript has the design goal of "don't break the web".) Still, they are not cross-platform portable and may not be supported by all analysis tools, so you are advised to not use them [...]
html/css/js (and the frameworks on top of it) seem like a pretty low bar to build games and business logic for a variety of apps which, despite huge efforts from OP, could run on pretty much any modern platform.
There is nothing for free. Abstractions cost performance and confuse troubleshooting.
I mean, I get it, but we also might not need Electron if you could stuff everything into a single HTML file and let users download that as your "app."
If Google doesn't give up on it I think it's going to be a much better stack for cross platform applications than the browser is.
Flutter apps don't look or work like native apps, and the only people who will put up with that are people who have to do so because their enterprise mandates it. Flutter apps have horrible battery performance. Flutter apps are always at least six months behind what is possible with native toolkits and SDKs. Flutter apps use a language that literally no one other than Sass or Flutter developers actually want to use and that offers exactly no benefit over the dozens of other possible languages out there.
Flutter is Java Swing, but worse in pretty much every way.
When I read this, I don't know if you're saying it's not ready yet or something. Is it close but not there yet? Do you experience bugs?
Examples
- SDL
- GLFW
- Openframeworks
- Monogame/FNA/XNA/etc
- Haxe
You will still suffer with notarization and appleness, Android stuff being pressured by Play Store policies changing constantly, and every platform/store specifics, adapting controls, form factors, gestures...
Flash also was this.
Now the browser is just a bloated pile of crap.
Or framed this way: your dream exists and it's called Qt and can be used to make some absolutely fantastic applications[1]. What's deficient about it and why?
> Similar to developing for macOS, a Mac is pretty much required for developing for iOS and there’s the $100 per year developer membership fee. I think the combined income of both iOS and macOS (95% of which comes from iOS) barely covers the cost of the membership fee and the cheapest Mac Mini.
I think this contextualizes the post well, seems like overall revenues might be in the <$10k or even <$5k range. That's extremely hobby territory (/buying lottery ticket territory). Feels like at that scale a 'build whatever makes you happiest' heuristic is healthier for the individual and cross-platform support works against you.
Just say’n.
https://howtomarketagame.com/2022/11/28/the-median-indie-gam...
Figuring out how to do production code signing on Windows, and where to go to get your app trusted after signing, is also way harder on Windows. In contrast, implementing Apple's code signing is both cheap and easy.
It's not a protection racket...
If you just get a regular (cheaper) code signing certificate I realise SmartScreen will still block you anyway until enough people have installed it, but how many is "enough"?
Also, previously: "Microsoft Defender SmartScreen is hurting independent developers" https://news.ycombinator.com/item?id=23392404
I think some types of games (think factory building, zachtronics style puzzle games, ...) might have a bigger percentage, though that's only a feeling I have, I don't have numbers myself, I just see such games more often have a Linux release on Steam that seems appreciated.
I'm sure the hardware survey is biased towards Linux, but it's still a surprising result! Especially so, given that I originally only released the game on Windows (and later added Linux support after getting multiple requests to port the game).
You could consider having a donation "DLC" for the game, I would happily pay for it.
ninja edit: the lack of vim mappings is killing me
1%->2%
The browser provides Local Storage, but that isn't reliable as a "source of truth" since browsers (mostly on iOS, I think) may delete the data periodically (thanks, iOS, for deleting my Wordle history!) or when clearing browser history. Aside: the worst situation is when publishing on itch.io and playing on an iPad--your data appears to get saved to Local Storage but is actually wiped immediately to prevent cross-site tracking (itch.io hosts HTML5 games in a frame with a different domain).
Publishing on Steam, on the other hand, gives you durable file system storage and you can add cross-device syncing via Steam Cloud very easily. I'm holding out hope that something like remoteStorage will eventually catch on for browsers, but for now I don't really see a convenient solution.
If anyone has ideas for managing save data in a browser game that don't involve hosting user data myself (and dealing with account recovery, GDPR, etc.), let me know!
I wonder how that compares to using an engine like Godot, Unity, or UE for cross-platform support? I love Electron and WebView is nice too, but neither would be my first choice for creating a video game. Personally, I'd prefer a native app that compiles to WASM for web support.
I'd assume webview apps could be more accessible rather easily, and it would take care and attention to make a native wasm app accessible.
I suspect that what he means (in both cases), is that sales are low on both platforms, and they are not worth the effort to port to.
If I want to play a WebGL game, I use the browser.
But it seems like a lot of the other Mac issues are related to Steam.
A normal Mac app sold online or through the store wouldn’t need special entitlements for dylib loading, and Xcode could easily handle all the signing for you. Xcode cloud could help too with builds.
I don’t think the game being Electron would matter there.
I found this which sounds like it's not the default, but is in fact a result of compatibility testing:
> If your game has gone through Steam Deck compatibility testing and the testers reported that the native Linux version didn't work (because of #579), then it might have been flagged to run the Windows binaries via Proton by default, instead of the native Linux version.
per https://github.com/ValveSoftware/steam-runtime/issues/585
Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
(Or more background, my details are very vague here)
It absolutely isn't unless you hate your users.
> you can static link everything _except_ opengl
You don't need to statically link OpenGL - it has a stable ABI and most functions need to be loaded at runtime anyway.
> This is similarly an issue with containerizing graphical apps: last I read you needed to have the same version graphics libraries both on the host system and _within_ the container due to the weird linking issues.
You don't need to worry about containers when distributing native Linux games.
> Does anyone know if there's any efforts to improve this situation? Is there some ideological issue in linux that prevents standardizing or presenting a generic interface?
Yes, for one you could stop spreading FUD.
Same experience for my iOS games.
Apple should more friendly for sole indie developers. (But maybe they really don't need to care about this now?)
> Currently all HTML5 games on itch.io are set up to only take payments as donations
Seems like a big hole on the market? Anyone interested in setting up a online games payment gateway?
Windows on X86 and Linux on ARM
Everything else is a waste of time.
For revenue I'm going with http://itch.io
Brb going to download idle industry
It's getting some improvements soon (at least from Chrome), currently requires renewing approval on every page load. https://bugs.chromium.org/p/chromium/issues/detail?id=101153...
It works well for my use case. If you want to see it in action: https://web.zquestclassic.com
The problem of course is not all browsers support. As a backup, I use either indexdb or local storage.
Wow, thanks for the warning about that itch.io problem. It's discussed here: https://itch.io/t/2636350/localstorage-doesnt-work-for-html5... and behaviour of Safari's default-on "Prevent Cross-site Tracking" here: https://stackoverflow.com/questions/63922558/safari-localsto...
So this is happening because itch.io hosts the game on a CDN subdomain such as v6p9d9t4.ssl.hwcdn.net which may change at any time? If it doesn't change, it sounds to me like there should be no problem, but I suspect I misunderstand. And sounds like it's Safari, not just iOS?
I'm about to start letting users export their games to html5, almost all of which will end up on itch.io, so really need to solve this too.
* WebRTC and NAT traversal to let the user sync files (complicated but viable for my use case but pretty dumb for gaming). * Cloud storage and anonymized social logins with E2E encryption (cue key management horror stories) * Download a file on exit, upload on resume (terrible UX)
https://www.orientsoftware.com/blog/flutter-vs-react-native-...
While the framework had issues with accessibility in the past, seems like they've been adding a lot to improve it.
https://www.kodeco.com/35275067-flutter-accessibility-gettin...
Dart is a simple, no-frills language. It's not used outside of Flutter but what is wrong with its semantics or anything inherent about it?
Users are used to apps that don't look much like the out of the box platform toolkit by now. Even apple isn't very consistent about this anymore.
Native is better if course if you have the luxury of writing your app twice or three times but not many of us do.
Some of the issues you are describing would still exist even if I wasn't using a cross platform library.
In fact, the best way to expose any hardware improvements is to give us the data sheet. Gate keeping direct access to the hardware with an API effectively reduces user access to innovation.
One could criticise how I conflate hardware and platform. I’ll just note that all the goodness we’ve seen the past 40 years were made possible by hardware. Personally I saw precious little innovation coming from software specifically. So even if a platform is more than just hardware, actual innovation mostly comes from hardware anyway.
You've also got a bunch of deprecations for things that were in the spec, will almost certainly be supported forever, but are now seen as bad API design for one reason or another - usually because they don't handle edge cases correctly for historical reasons, or the name doesn't reflect what the function actually does. Unless any of these features actively leads to a security issue, they're very unlikely to be removed.
That is ‘a bit’ minimalistic, but it is “just a single stable, non-bloated, reliable, portable platform that could be used for when you just want to Write Once and then know that it will Run Everywhere _forever_ […] Would not even have to be an entire API”, and it could run on hardware that has no chance to run Win32.
Small fry need not apply; if they insist, they should at least clear the threshold of owning a Mac and paying $100/year for the App Store license.
Indeed. And that is (one reason) why Mac will never be more than a third-rate platform. As I said, they're shooting themselves in the foot.
Of course not 100% true but wherever I look its like >50% true at least.
Not to mention being the most valuable company in the world, sitting on _not_ the majority of users _but_ the majority of user revenue/wallet sizes, and having more cash to spend at hand than nearly every other company in the world has in total revenue, to the point of surpassing small/medium countries' GDP.
So far, "shooting themselves in the foot" I would not 100% agree with. And depending who you're asking, the Mac is the #1 platform, and is even growing since M1 chip releases.
Can you elaborate what you mean by shooting themselves in the foot?
Do you see them as a centipede who sacrificed one foot in exchange for all the riches in the world?
Or do you mean that if they were more open to developers they'd somehow be even bigger? What's bigger than a trillion dollar company? Would they be intergalactic?
From a quick search I do not get the impression that .NET has been deprecating parts of the API, including Core APIs, in the past, e.g.:
https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
Open source, powered by Skia, backed by JetBrains, and quite battle-tested at this point for small to medium-sized apps. In theory perfectly capable for enterprise as well, since it's basically a spiritual successor to WPF, which has been an industry standard for about 15 years.
They're diving into mobile and WASM well, but that's more of a recent effort and I haven't tested that yet.
Users follow other users, if they can.
I've been thinking about doing something like this recently but I'm not a heavy mac user these days. Any tips on what people are looking for in small tools?
Ask yourself, what tools can I build that are not only useful to me, but maybe useful to others, and start there.
That was 30 years ago. Since then everyone has been copying Java:
C#, WASM, Go, Rust... nothing even scratches the surface.
And it never was insecure, it was removed by the same people that leverages consume only devices and root certificates.
That said I'm actually a proponent of bringing back the MIDlet, J2ME was the best software platform ever created.
No, I can't develop Applets, they are disabled in all browsers.
(Yes, there were occasional sandbox escapes, but there are occasional sandbox escapes in web browsers too. Few security mechanisms are perfect)
wasm is that ABI for browser. Yes it would make everything bit slower, but I am fine given a lot more added security.
(No, not all of them, of course.)
Microsoft's money, buying NexT instead of Be, NeXT employees takeover from inside, having Steve Jobs back at the helm, ...
The browser standards are open only in name. The sad fact is, implementing those standards are flat out impossible if you’re not a megacorp. They’re just too damn big: I recall someone counted like more than a hundred million words.
Now using those standards is easy, you can implement a subset. But the number of browser engines that actually supports enough of those standards will only decrease.
There won’t be. Since IE6 the standards have grown to inhuman proportions, and implementing a new browser engine is even more difficult than it was then.
So yeah, maybe we’ll get another engine somehow, but if we need again another agressive tech giant to pay for that, thanks but no thanks.
By now, you also have WebGL and WASM, if JS's JIT is not fast enough for you.
How are we supposed to describe these native apps? What's faster than screaming fast? ear shatteringly quick?
And you of course have nontrivial examples to prove that? Or as always source: trust me, bro?
That said the WebGL/WASM stuff is generally very nice in my experience and is very much changing my opinion. I'm interested to see what comes in the future!
I don't think they are currently successful in the computer business. Them making shiton of money on overpriced mobile fashion doesn't really change that.
Try building an operating system or browser engine in Javascript and you'll see what the parent is saying. I'm just giving you these examples because these are some of the last remaining native applications everybody still uses, but pretty much any native application will be much faster than the Javascript version. The reason browser wins is that we got to a point where the performance is "good enough" and the development cost is significantly lower.
if there's some great innovation it can be introduced in a fork of Firefox/Chrome/etc.