Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Within the software development profession, front-end development is one of the remaining areas that has a very large pool of self-taught developers active. Many from what was originally a web design position and are having trouble grasping further than the basic concepts of a foreach loop or if conditional branch. I knew a guy like that who would just zone out at the mere mention of the words 'class' or 'method' and balked at the notion of having to use source control solutions.
He was genuinely good at design, but the market forces these people to adapt and move into developer positions they are - sorry; cold hard truth - simply not qualified for.
Yet these are the very same people that are the most likely to reach for and grab frameworks like React or Vue, as for them it's simply the replacement for things like jQuery back around the turn of the century when jQuery was still the hip thing. For them - just like with jQuery - it's the lowest common denominator to "do what I want" and get to the finish in as straight a line as possible. And they're not going to be hindered by any form of knowledge of how many eggs they're breaking to make that particular omelet.
And that's why and how you get performance suckers. These people are essentially like cavemen who've just discovered fire; and you hand them nuclear power and expect them to use it wisely.
React is just about the worst of the bunch in that respect too. It's the C++ of web MV* app frameworks. It has so many footguns strapped to it, that it's damn near impossible to finish building anything with it without losing a toe or two to incidental self-introduced performance problems, unless you first internalize entire dissertations on how its updating mechanisms exactly work and are intimately familiar with all its ins and outs and do's and do-not's.
It's the one framework a novice should NEVER be using for production-grade applications cold-turkey. Yet conversely it's the most popular one and as such many novices are drawn to it to make their workload easier. Which - admittedly - it does. But, at the expensive of everyone else's experience with the final product.
Oh and btw. after bringing back up the old days and jQuery.
If you're in for a good laugh, pop open a dev console on the Steam community domain and try this:
Yup. That's fossil gold[security.snyk.io].
That's what browser rendering engines internally already do.
The HTML document tree is not at all the same as the tree used to render the content. A lot of stuff gets merged (or split) based on its layout properties and by heuristics that determine whether it could be subject to particular types of change.
Modern CSS has specialized instructions to drive that splitting logic, for those cases where browsers get it wrong. Which happens, basically, in sporadic edge cases.
The problem with stuff becoming sluggish lies elswhere.
Firstly: JavaScript.
Tons of it and in particular the sick notion that everything has to be a "SPA" (bonus puke points if you actually pronounce it as a spa) with browser-side view-template rendering based on DOM diffing; observable data bindings; and tons more abstractions to plug all kinds of gaps and accelerate development and time-to-market.
Great for silly little small applets; limited-time offers or campaigns; and low-complexity line-of-business apps for form entry. Not so good for big long-term applications with performance concerns.
No; React isn't fast. In fact; all solutions based on virtual DOM have a breaking point where the sheer size of the sub-tree they have to diff starts weighing heavier than just invoking the HTML parser and replacing the entire thing whole-sale.
Case in point; just the other day I did this with a piece of logic that is meant to display mostly passive, non-interactive data. But a lot of it. A big list of items with lots of properties to display.
I kicked out the JS based view template rendering of individual listed items and replaced it with straight up pounding in raw HTML that came in pre-rendered from the server. So yes; HTML-in-JSON; one string of HTML per item in a JSON array. Ooh! Scary and bad, right? Except the end result was 30 times; thirty times faster and consumed a mere fraction of the RAM.
The second killer: animating HTML elements.
Animations are extremely expensive stuff. Browsers can't cope with predicting how or where something will move, unless you're precise about it. Moreover, it can't use hardware-acceleration to make it fast unless you keep to a very limited set of CSS properties to animate. Roughly: those that correspond to not messing with the boundaries of the render tree. (Remember that thing I mentioned before? Document tree != render tree. Here is where that matters.)
That means you can put a 2D or 3D transform on an element. And you can change its opacity. And that's it.
Changing its height? No. Changing its color? No. etc.
It requires very elaborate set-ups to pull of certain types of animation in a hardware-acceleration friendly manner. And most won't bother.
And then there are other types of animation, such as an in-flow fold-out needing to affect height, which basically can't be done wit hardware-acceleration ever.
And then the third killer is related to the second: animated content.
Specifically GIFs and other animated image formats.
Unironically an animated GIF avatar of 40x40 pixels would be several times slower and more resource-intensive to display than a WebM video based avater thrice the size.
Yes. Really. Not a joke.
But even then; you're supposed to do this stuff sparingly, because it can still place quite a load on a GPU to have to decode 20+ animated pieces of content simultaneously. Much heavier than hardware-assisted decoding of one Full-HD resolution movie clip, even. And e.g. Steam uses a lot of these things. Which taxes your system quite a bit.
The last one, and one of the more important ones:
the sheer size of the document that is loaded. Nothing kills a browser engine dead with more speed than a huge document tree and an infinite scrolling timeline. (Case in point: Reddit. Open 5 or 6 tabs and listen for your fans to spin up to full blast.)
But they're hip and engaging; so you've got to have that, right?
No matter that it makes the entire thing tank and stutter once you've scrolled down 5 desktop screen lengths due to the sheer volume and density of data smushed into that poor browser's face to handle...
And of course if you want double-the-money; double-the-fun, then pair #4 with #1 and client-side virtual DOM diffing of that entire thing kicking in with each mutation of the data and each additional 'page' loading and being appended when you scroll down far enough. Happy times!
--------------
Now, if you've followed along this far and have reached here, then you've probably also deduced that the Steam client pretty much ticks all the boxes here. I.e. it's sort of a perfect storm situation.
Yeah, you pretty much outlined all of the problems that I was alluding to.
One of the other problems is of using canvas elements or effects that update every frame and cover the entire visible area. At that point, your webpage is basically an embedded game running at high framerate. Yesterday I was on some newspaper's website and I noticed Chrome was using about 10-15% of my RTX 3080 just sitting there with a static view. I resized the window and the usage went down with pixel count. From what I could tell, they were running some JS that was constantly re-rendering a blurred version of the background on every vsync, which on a 144Hz monitor was enough activity to register quite clearly.
If you give people hammers and don't teach them what a nail looks like, you end up with a lot of broken stuff.
The only solution will be regulations that force publishers to say how much power their apps or content consume. We do this with hardware, and we need to do it with software, or there will never be any accountability and thus no change.
Like, imagine playing new game that eats memory like crazy even if you have 32 gb, you still would try to free as much ram as you want for it, right? nobrowser launch option allowed it, now not anymore.
Though ofc its more dramatical for those with outdated weak hardware.
If I cared about streamers I would be on twitch or youtube.
My inventory gets bombarded by items a lot of which I can't sell or delete creating a bunch of junk I can't do anything with or get rid of.
The store never loads for me with all the box art and the bright lights give me a migraine. I have been more willing to go to other stores and if I can't find the game there I will get the game by "other" means (so congradulatons on pushing me into piracy I guess? which is pretty ironic considering gaben wanted to try and combat piracy).
I don't care what is new or curators or inventory items I just want to be able to play the damn game. If I wanted to watch streamers I would much rather go on youtube or twitch than Steam.
I rarely use Steam and I will never spend money ever again on Steam since you forced this mobile induced UI on us and keep taking away useful tools like being able to skin the library now taking away a tool that very few know about but you can't stand people found a way around your bloated browser.
You say tell us why you are using these tools but if you have been paying attention these past 3 years you already know why. You has been given feedback about how bad this was for 3 YEARS but failed to and still fail to respond so no idea why I even bothered.
Valve has become so anti-consumer I should not even be shocked this is happening they are so petty.
It's not healthy when bells and whistles get in the way of main, core purpose of Steam client: launching games. People have been asking for small more for a long time, but currently Steam mode still launches Electron bloat in background, even when user has started Steam client in small mode, and never switched to main more, nor launched any feature that requires Electron.
I don't think much of you said here is actually correct.
I'm pretty sure the task manager is aware of what the CPU and GPU power stages are and accommodates them in the usage graph. Otherwise your usage would look like a ragged straight line.
Also, the webhelper is always out of focus when I check its resource usage, kinda by definition, since I use another app to check that.
The only thing I'll acknowledge is that, yes, obviously, the live GPU processor usage does depend on what's being actively rendered. However, the bloat we're talking about here is mostly to do with RAM and VRAM usage, though yes it's best if the client defaults to minimizing-to-tray during gameplay so that no active rendering outside of the game needs to be done.
(It actually kinda blows me away that this hasn't been a priority from day 1 of Steam. The best launcher to run your games should be the launcher where your games run best.)
It is notably bad at scaling with big libraries, with recurring crashes.
"-no-browser" (and maybe "-noreactlogin" ?) is a way to mitigate the problem.
Removing this option is anti-consumer.
That's the problem is they are not giving any option to disable the bloat/lights/ads. Atleast when we were able to make skins we could customize the library but Valve don't give a ♥♥♥♥ anymore outside of making money.
And before any corporate shill comes on to say "but they business and need to make money" they can make money without turning users to other stores by using anti-consumer decsions. Plus they have been making record profits so excuse me if I don't care about the ♥♥♥♥ they keep spewing.
All I want is to play my games without too much hastle which Valve is proven to be too complicated despite being a billion dollar company.