I’d argue that it’s not so much won as ceased to matter. ARM which makes up basically all of the mobile market is bi-endian (oh, the heresy!). In the sense that x86 basically “won” the desktop market I suppose you could say that little endian won but I think given the overall code depth (shallow) and abstraction (lots) of many of today’s applications, it’s much less of an issue than it used to be. I don’t recall endianness really coming up in my Computer Architecture class.

I suspect that many developers aren’t even aware of endianness or why it’s important. Because for the vast (and I mean vast) majority it’s utterly irrelevant to their daily working environment. This was different 30 years ago when everyone was coding much closer to the metal as opposed to manipulating text files on a screen in fancy and dramatic ways.

My general suspicion is that Object Oriented Programming was the beginning of the end of caring about endianness since the layers of access and abstraction in a good OO system hide implementation details from the user. Since implementation includes endianness, people got used to it not being an explicit factor.

Addendum: zxcdw mentioned portability being concern. However, what has arisen with a vengeance in the last 20 years? Programming Languages built on virtual machines. Sure the virtual machine endianness might matter but it can be made very consistent for that one language to the point where it’s basically a non-issue. Only the VM implementors would even have to worry about endianness from a portability standpoint.

No, nobody has won. We as a species we have failed to standardize the order in which we store our bytes, along with the direction we write and the side of the street we drive on.

As a consequence, anyone who wants to transfer data between two different systems over a network or in a file, has only about a 50% chance of the reasonable initial version of their data dumping code being correct in their environment, and even if it works, has a 50% chance of working in their customer’s.

To deal with this you need to go look up platform specific functions with names like “htonl” in headers with names obviously dating back to the 70’s like “arpa/inet.h”, because the situation has not improved since then and probably never will.

Endians only really matters when you are transferring binary data systems.

With the advancement of processor speed (and much much lower cost of storage) binary data interfaces are becoming rarer so you don’t notice them at the application layer. You are either using a textual transfer format (XML/JSON) or you are using data layer abstraction that takes care of the translation for you (so you don’t even notice that there is a translation).

But when you are coding at the binary data layer you do notice and it is very important. For example When I worked at VERITAS (Symantec now) I was building software that was being built on 25 different hardware platforms (not only big/little endian there are other types).

There is still no consensus:

• The majority of larger computer systems (server/desktop/laptop) currently use little-endian architectures
• The majority of smaller computers (tablets/phones) use an endianness-independent processor architecture, but run operating systems that use little-endian order

So at the hardware level, LE is far more common. But:

• Most inter-computer communication is carried out using protocols that specify big-endian order
• A very large proportion of the world’s software runs on a virtual platform that defaults to big-endian order whenever data is written to external storage.

Both orders are going to be with us for the foreseeable future.