It comes down to package distribution.

Chrome had already solved the hard problem of "how do we support webcams on linux, windows, and mac" and you as the dev just needed to use the Javascript webcam api. ( https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... )

In C++ land, you are ultimately going to either need to cook up your own webcam library or look for a 3rd party (which, in 2010, likely didn't exist) to provide it.

Today, there are a few easy to discover rust crates which provide cross platform webcam apis. But further, rust does cross platform better than C/C++ IMO. It's really easy to change how code is compiled based on the target. That was all well thought out because rust was supposed to be a language for browsers.

▲

bluGill a day ago | parent | next [-]

A cross platform webcam library isn't that hard to build at C++. I mean, it's tedious, and having to support multiple different operating systems makes it harder, so it certainly is going to cost a small pile of money, but this is not hard. The pile of money needed won't be all that large. Mind you, I prefer to use something that's off the shelf rather than writing my own, but it would not be hard to write my own.

The hard part of all webcam libraries is all the different webcams running all their different proprietary protocols.

	▲	MindSpunk a day ago \| parent [-]
		Write the code or build the code? That's always the problem with C++ libraries. It's not that difficult to write cross platform C++ code. Consuming the dependency is always painful. What build system does it use? What compilers does it support? How do you get the code? There is 0 standardization for these things. C++ code isn't always that portable either. Old code in a new compiler is very likely to break on warnings, especially if the old code made the high quality decision to hard code -Werror in their build system. From personal experience Rust as a package and ecosystem is far more portable than C++.

▲

pjmlp 2 days ago | parent | prev | next [-]

Qt is easily obtainable via vcpkg or conan.

▲

edoceo 2 days ago | parent [-]

Was that true in 2012?

▲

pjmlp 2 days ago | parent | next [-]

Depends, it was easily obtainable via OS package managers, and installers in 2016.

However that has been true since 2016, and here we are, 10 years later.

▲

justincormack a day ago | parent [-]

For Linux, but not for Windows and Mac

	▲	pjmlp a day ago \| parent [-]
		I mentioned "and installers" for a reason, I know Qt since KDE exists.

▲

Krutonium 2 days ago | parent | prev | next [-]

Very yes.

▲

bluGill a day ago | parent | prev [-]

Neither existed in 2012, so of course not. On the other hand, QT has always been really easy to download from QT. I don't remember who owned QT in 2012. They've changed hands a couple times over the years, but in 2012 I was downloading QT from whoever on them. QT was large, so you needed a decent sized computer to build it, but in 2012 this was not a big deal.

People get too hung up on package managers. When you're building your own proprietary you don't really need a package manager, you just need a central place to download the tarballs from. Or you could do a monorepo and just build everything locally - in 2012, that means you start your build before you leave Friday afternoon, and when you come back Monday, everything's built.

▲

jpc0 a day ago | parent | prev [-]

It is 2026 and regardless it has been quite a while that cmake fetch content had been usable.

The only reason why a cross platform well supported C++ package/module isn't available is because nobody has bothered to build it.

If it really is something that bugs you then be the one to do it, throw your clanker of choice at it and integrate it into a project you run in production.

"Chromium ahips with it" isn't a valid excuse these days, that is likely an hour or two away with a modern LLM, building and packaging electron is more work.