[Cthulhu_]

IMO it really depends. There's a lot of big companies that have more than enough resources to be able to pay multiple dev teams to build and maintain apps across operating systems.

From a few years ago, Twitter and Facebook were famous examples. They pushed so hard to try and build their apps using web technology but kept running into performance issues (thanks to infinite scrolling). After spending fuck knows how much they finally admitted that maybe native components are better.

But this is Facebook, who have so much resources they can afford to build their own version of PHP three times over. I just don't understand why they put so much effort into trying to fit a square peg into a round hole instead of just going with native development.

But, I'm not an insider, I don't know the thought processes behind it. Long story short, IMO people overestimate how complex it is to build multiple native apps in parallel.

[iainmerrick]

people overestimate how complex it is to build multiple native apps in parallel.

I agree, although there are now more platforms to deal with than back in the days when it was just Mac and Windows: add iOS, Android, desktop web, mobile web.

I think it also helps when it's easy to share code between platforms, which again, used to be easier when you were just targeting the desktop (just use C or C++).

Now it's a bit harder because there are no great languages that span all platforms easily without a bit of hacking. Most languages are managed and memory-safe now; that's a good thing, but it makes them more heavyweight and less portable. They generally want to drag in their own frameworks (e.g. Flutter, React Native) rather than letting you put your own UI layer on top.

[pjmlp]

I remember the days of Apple II, TSR-80, Commodore 64, Commodore 128, ZX Spectrum, ZX Spectrum 128K, ZX Spectrum 128K +2A, ZX Spectrum 128K +3A, Atari, Atari ST, Amiga 500, Amiga 600, Amiga 1200, PC CGA, PC EGA, PC VGA, PC PS2,.....

Platform fragmentation exists since ever.

[iainmerrick]

You’re right, of course! It’s amazing to think how many 8-bit and 16-bit games got ported to a whole bunch of different computers.

I was thinking mainly of the 90s and early 2000s, I guess, and for desktop apps where the main platform of interest was Windows, followed by a long tail of Mac, X-Windows, BeOS, etc... All those platforms could “easily” (i.e. with effort, but no rocket science required) be handled by a single C/C++ codebase with platform-specific #ifdefs.

I think the equivalent for today’s platforms would have to be Javascript. Unlike the C/C++ approach, you lose direct access to platform features.

[SkyPuncher]

> I just don't understand why they put so much effort into trying to fit a square peg into a round hole instead of just going with native development.

I think in the case of something like Facebook, the sheer complexity of their product drives a need for a singular code base. It would slow their engineering organization to a halt to ensure feature parity with largely seperate code bases.

[menckenjr]

This is only true if you're working with multiple completely separate teams each working in a silo to develop their own product and then post hoc some manager decides they have to have the same feature set. If they do it the right way around, specifying the common feature set comes first and then the dev teams do the app architecture on their separate platforms. As the features are developed and change requests inevitably arrive, the same sequence applies and you have an orderly process and the same app on two or more platforms without having to graft a third party dependency octopus onto your codebase.

[iaml]

> performance issues (thanks to infinite scrolling)

This problem is already solved by virtualized lists available in any decent framework. Why people don't use it is beyond me.

[amw-zero]

It’s not built into any frontend web framework by default that I know of. It’s the default approach on Android on iOS.

[iaml]

It's not built-in, but plugins exist for react, angular, vue; svelte even has a first-party one.