Users don't know about this performance gap, but there is a gap, and that gap is an economic opportunity.
Since the current practices are so inefficient, users are having to pay for this from pocket as hardware expenses. Buy a $1000 smartphone, to get the same experience as last-year's.
A different stack (don't need to reinvent the universe), can be branded as brutally efficient, uses slim hardware, and strict engineering practices to provide a much better experience at a fraction of the price (1/5 possible.)
I believe nobody is doing that yet since there are two main barriers:
1- Risk of no-market (I think this might be proven unfounded, given the current trend in price hikes)
2- Capital investment necessary to get started (But this also can be solved given the obvious appetite for the next-big-thing money being poured left and right, without anything catching on yet)
I think people confuse two important things.
1- Energy consumption of the lower stack versus total of a single implementation (could possibly be very low)
2- Energy consumption of the lower stack multiplied by everywhere it is deployed
1- Yes, optimizing for lowering this consumption by an app-developer can definitely be an ill-advised endeavor economically (you're saving 0.1-10% of your cost.. by adding a huge investment of time, possibly larger than the application development itself)
2- Optimizing across all deployments, can definitely move the needle, in a very significant way, against the effort required, since you're automatically deployed on 1000-1M places.
It's the same reason library developers (especially system/langugage/heavily-used-libraries) have a very good reason economically (and therefore ecologically as well) to optimize. Competition here is a huge benefit to everyone, including the environment.
If you spend 80 hours you're being inefficient.
If you spend 20 hours (and they're being charged for value,) they feel they were deceived.
Selling your hours to anyone truly seems like a lose-lose situation.
I meant more like 80 hours a week. It is, in my experience, difficult and cumbersome to charge for more than 40 hours a week since it kinda disrupts the usual cadence. You can do it sometimes for deadlines but wouldn't want to make a regular habit of it
I'm not smart enough to go into the technical details, so I'll use an example instead.
Machine learning is very effective in categorizing things - for example, given an image estimate whether it pictures a cancer cell or not.
On the other hand, machine learning sucks where you need to predict things instead of categorizing - for example, given a set of factors, figure out your risk of getting cancer within 5 years.
Any such machine learning predictive system will be useless due to under- or overfitting.
(Again, I'm not an expert, just a guy who has many years of experience trying to build such predictive systems.)
Very tangential question that hit me while reading the comments:
Is the current scenario possible: company A owns 10% of company B, and company B owns 10% of company A.
Does that mean getting the valuation of both companies require solving algebra?
Or is this outright prevented by other methods, like the board of A owns most of A and 10% of B?
There’s no reason why such a structure shouldn’t exist. I believe this how a lot of Japanese conglomerates are structured: different companies structured around a central company bank with each company owning a piece of all the others.
I hope Matrix 4 explores how Neo expresses disgust with humanity, as in, becoming more like Smith, and Trinity now kills him.
Anything that continues the saga with a goody-two-shoes Neo at this stage is... boring. He's too powerful not to be a villain?
Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism.
The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated.
I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up.
Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack.
I would not dread doing frontend development, if allowed to do things correctly.
Since the current practices are so inefficient, users are having to pay for this from pocket as hardware expenses. Buy a $1000 smartphone, to get the same experience as last-year's.
A different stack (don't need to reinvent the universe), can be branded as brutally efficient, uses slim hardware, and strict engineering practices to provide a much better experience at a fraction of the price (1/5 possible.)
I believe nobody is doing that yet since there are two main barriers:
1- Risk of no-market (I think this might be proven unfounded, given the current trend in price hikes)
2- Capital investment necessary to get started (But this also can be solved given the obvious appetite for the next-big-thing money being poured left and right, without anything catching on yet)