The difference is for proprietary features, you can just charge that subset of users that care for its maintenance, using that money to hire additional developers, etc. For OSS you instead have a relatively fixed budget of time & resources and have to balance competing interests in a zero-sum manner. On the flip side, there's nothing preventing the vocal minority from forking if the feature is important enough to them!
There are a good amount of lower power ones (e.g. with an N100 CPU) that draw ~15W usually and not that much more at full bore, and some of them are starting to come with USB-PD power inputs (even if they come with a DC power adapter some will accept USB-PD on another port).
i have a passively cooled Quieter 4C [1] with N100 and a 4TB [dram-less] nvme [2] and it draws 4.5W total at idle running EndeavourOS w/ KDE Plasma. at full load (Handbrake 1440p transcode) it draws ~10W.
i left it at stock bios settings and did not put it into higher TDP mode though, since i use it as an htpc and it mostly idles, i'd rather it stay at more comfortable operating temps.
the nvme cost me more than the pc, which for $207 includes 16GB ram, 512GB nvme, and a Win11 Pro license. insane.
i'm mostly converting 4k from a phone to 1440p and cutting [backup] storage by 6x. most of these vids are < 3min, and i can do quite a few in a batch job overnight. im in no rush. it does about 4fps with the 1080p30 HQ preset with the only additional change to up the res to 1440p. i would not use it for batching feature length films, but you can do one in a pinch :D
Ugh, yes. My kids play this one at school and when I read about the game mechanics I was super disappointed. Luckily they stopped begging me to subscribe eventually since I wouldn't budge.
Then middle and upper class people will just keep on polluting at marginally lower rates. The only real solutions to this problem are ones that get the will & finances of the upper classes involved.
So what? I'm suggesting pricing in the externalities.
It's not a problem that you want to release a ton of CO^2, if scrubbing and permanently sequestering a corresponding ton of CO^2 is included in the price.
Instead the EU wants to micro-manage the market, and only address some sources of pollution.
They're not banning gasoline engines in general, and notably doing nothing about non-automotive gasoline engines, which relatively speaking are much bigger polluters.
Having two completely unrelated UIs – one for mobile, one for desktop - isn't really responsive. When done that way there's some point (e.g. 1199px width in the OP's example) where you suddenly have a tiny mobile web site with a ton of blank space on either side (or worse, it stretches it all out to fit and all the blank space is within every single button and widget).
There should either be several progressively more "mobile" breakpoints, or even better, use component queries so individual chunks of the page can rearrange their contents as their available area shrinks.
This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement.
And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.
I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem. Starting with a framework that has widgets you can reuse is much more interesting and motivating.
That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.
GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.
Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.
> I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem.
I don't think it's worth beginners learning the road rules and safety protocols, because of the "time to being responsible for a heavy, fast motor-vehicle sharing a road with other people" problem.
I'm surprised to not see NEXT.js mentioned. For anyone comfortable in the React world it pushes a much more classic <a> tag link model throughout the app while still allowing reactive and responsive behaviours.
reply