Alas, web development "decided" to completely reinvent the wheel for all this stuff, leading to a new generation of heading-to-native toolkits derived from browser-based technologies, such as Electron, React Native and Flutter.

Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.

Does it matter if N is 10 instead of (say) 5 ? I don't know.

Does it matter if the N is segmented into "derived from 90s widget models" versus "derived from 2010's web models" ? I don't know.

Is there any chance of a single toolkit that covers native desktop environments (which continue to be important for creative apps, high performance apps, browsers etc.), native mobile and browser based apps? I don't know, but it seems ... unlikely.

They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen.

The best open ecosystem we have on the planet is being body snatched by the closed-as-can-be native app world.

The post here is a more developer-centric view of open & I think that's so valuable. It feels like we really used to have a more share-early share-by-default spirit.

I think that's one thing that kind of agitated so many folks about webdev, is how share-centric it was.

We didn't have established experts, there were no well established patterns, everyone was collectively figuring it out. Finding libraries that might work for you or doodling around with an idea was lead by sensibilities fit & taste. Throw it against the wall & see what sticks.

The web today has really become a far far far more hyperindustrialized system, with far more popular (not enforced) norms & conventions. The random lead devs at a company are no longer necessarily intrepid explorers navigating an open sea of possibility. Everything is more set. And we no longer have that spirit of it just being us in the room, of sharing by default. The expectation is there's very very smart far off people building libraries, and we're just working on our app. The mindset has shifted, the culture has shifted, in a way where open is no longer the collective exciting happening place that we are all a part of.

Take your example of the Open Web. I wouldn't be in software without the Open Web. I hand-write HTML and CSS to this day! But many people hate the web stack. They hate the ergonomics and enjoy better ecosystem for nearly every possible thing implemented in the web. I think ultimately, that's ok and it's "worth" having competing standards, because the alternative is - pardon the dramatics - authoritarian.

edits:

> #2) Check for prior art first. The problem may have been solved before...

I generally take issue with the statement "this is a solved problem". It ends up killing critical thought on the vine. I think everyone is better served thinking critically, and yes maybe something off the shelf is the right choice. But think critically, and freely, first.

> #3) "be opened-minded to other approaches"

contradicts the idea of building one-thing all-together no?

Such a weird take on this, really.

There is probably a reason why many working in Tech or specifically software is heavily leaning into certain political spectrum which relates to the above.

https://www.analog.com/en/products/max78000.html#product-ove...

This has all the freedom one could need and amazing computing power. If one needs a non-propriety way to reach iOS users use a webpage.

Nobody is stopping anyone from making the next big thing.

> In the world of mobile development (though likely also elsewhere), we sink so much engineering talent into making tools that are great within-ecosystem, but as we don’t bother making them available to other ecosystems, everyone ends up reinventing the wheel.

I get the frustration with software churn and substandard tooling when you have to code for multiple platforms, but this is a very hand-wavy admonishment. Leaving aside who "we" are and what our cross-platform responsibilities are for the moment, how would this even work? Different platforms have different capabilities. Cross-platform tooling will therefore always be more complex and less capable than platform-specific tooling.

One could then argue that we should consolidate platforms, which generally will be more efficient, but who will be responsible for this platform? Whether closed or open, you are now in a situation where one platform has to be all things to all people, and that means there will be tradeoffs that hurt someone. I'm a happy iOS user, but I'm sure glad Android exists because diversity is healthy.

Technology will always trend towards consolidation because bits are cheap and easy to move, and there's always an incentive to harness economies of scale. The problem is mono-cultures are brittle. Some amount of "reinventing the wheel" is just the cost of a healthy and diverse software ecosystem. The OA should be careful what he wishes for.

Having an open ecosystem can often mean you have no moat around your business.

> The lack of interest in Unimodules taught me that it’s not enough to come up with an opt-in common standard.

It's a tough sell if it offers no immediate value to the developer. If there's no immediate value for the user or a big push, they aren't going to be asking for it either. This can turn into a vicious cycle Apple keeps avoiding and Microsoft keeps falling into.

> Given it’s far too late to convince each framework to redesign their native module interfaces from the ground up for compatibility, it may be worth exploring a top-down approach instead. That is, producing tools to translate modules from one ecosystem to another “whether they like it or not”.

That's the gold standard, IMO. Once you need people to do anything for your feature to work, your work becomes a lot harder. "If everyone would adopt it you'd see the benefit!" doesn't convince many users OR developers. By removing the requirement for developer opt-in, you're suddenly avoiding a huge part of the viscous cycle (no users because no devs, no devs because no users), which is a huge part of Apple's ARM success and probably a good part of Microsoft's ARM failure.

Users care about unique value.

Vertical integration and differentiation lend themselves to building something unique and valuable.

Imagine if we were all building upon the state of the art at all times and upgrades were free and things don't break between upgrades.

Make your offerings available via an API. Make the actual content stream with whatever DRM standards you (the "platform") need to feel comfortable.

Let me wrap all my streaming services with a single platform, having decent search and ability for me to do automatic price arbitrage. Why rent on Netflix when it's free this week on Hulu?

It could be so much better, but it's not.

Is it any surprise that tech is the way it is with this in mind? Is it frustrating? Absolutely. Is it as expected? Yup.

It sounds ideal in a developer POV, but this is not open source territory.

You can only choose between having your own closed ecosystem, or being part of someone else's larger closed ecosystem.

https://itsfoss.com/open-source-alternatives-android/