Show Posts
1
Off Topic / Re: Software engineering trends that annoy you
« on: May 02, 2024, 09:36:00 PM »You know well that smartphones are not the devices we are talking about here. Nobody is going to gripe about devices which are by design not intended for multitasking. It's entirely apples and oranges.My point was: if the average phone can run many of these applications at once, then the average computer should be even better at it. Unless you are implying that desktop computers are somehow on average worse??
On desktop will be running multiple applications (not including the 2 upwards of 3 digits worth of daemons/services that will be running in the background) all at once, most of which will not have the luxury of writing application state to disk when it's not in use. It simply does not work that way.
Having your webapp or website consume 100 MB to 2 GB of memory just because "everyone has at least x GB of memory" is absolutely inexcusable and is an awful mindset for any developer to have. It's also inconsiderate to the end-user because they will want to use other applications without having to throw down $250+ for a new set of 32 GB DIMMs. But as you said; you do not care.
And the fruits of the 3 have manifested in busy CPUs and monopolized memory space.
Remember, we are talking about a framework that is made for creating interactive UIs: most users cannot context switch between like 8 different graphical apps at once. I'll be running 4 MAYBE 5 different electron apps at once. Hell, even in worst case scenarios (running 10 vscode instances because ??) I've been able to use dozens of instances of these programs with no problem.
I don't think a few hundred megabytes is that big of a deal anymore when the average image on the internet is like 50mb.
JS has been JITted to hell and back and yet still lags significantly behind other scripting languages like Lua and Squirrel. Sure, you can throw every last SIMD instruction, data-oriented design technique, -Ox flag, and inlined function at the problem for both the parsing and bytecode evaluation, but the end results still speak for themselves.
Can you give me the source for this claim? I cannot find anything saying JS is significantly behind every interpreted language.
Almost every single recent article and benchmark proves that the V8 engine behind Chrome and NodeJS makes one of the fastest interpreted language (and I haven't even mentioned the Bun runtime). Your knowledge on the subject seems to be lagging by like 5 years. Lua and LuaJIT have similar or worse performance.
This is my criticism of people who still complain about things like this: JS has already come out of it's dark age and has emerged as THE web standard but people still harp about stuff that has been fixed ages ago. The V8 engine for JS literally has teams of people at Google working around the clock to make it the fastest interpreted language because they have the incentive to make their browser the fastest. If what you said was true, what would've prevented another company from making a browser that had a different scripting language and then swaying the W3C to change the standard because their stuff is faster?
And again, all these benchmarks are incredibly close. The people who obsess over them are microptimizing code. The average website doesn't need a 4% speed boost by using C or C++, the ones who do need it for graphics performance can just use WASM.
Quote
WASM's IR is a step forward but still lags behind Oracle's Java bytecode and Microsoft's CIL from the few benchmarks I've seen. I don't hold it against that though, as it's still young and still has a lot more time to get better.It's fairly new but it's becoming really good at an alarming rate because the potential upsides. The value proposition of sandboxed apps running on every platform ever is a really good incentive to work on it.
Quote
This was what I was trying to get at. Clearly there's a gap between the tools used and how they're actually being used, given the monument of issues plaguing web development. I doubt neither the developers or the companies are going to budge, so changing the tools to fit the demands of the modern web is the most clearest option, at least in my eyes.I know from your perspective this statement seems like it makes sense, but there are a lot of problems with it. This is like saying "The unreal engine editor is hard to use and it's really easy to make slow games on it, instead of improving the UI and patterns to fit what the devs need, lets replace it overnight with Unity and make all the devs port everything to it."
The real issue behind devs not optimizing stuff is because it is really easy to get into web development, which leads to an oversaturation of bad developers. It's because the tools for the job where really poorly made up until ~5-7 years ago and all the bad developers never updated their skills. For example, a lot of developers still reimplement their own "deep object cloning" algorithms or import one from libraries (ballooning their memory footprint) when the function to "deep object clone" has been a part of web APIs for years now. These kinds of development mistakes will not stop happening until the developers get better and the resources on the internet get updated. Javascript is unfortunately plagued by the fact that most of the content on the internet about it is wrong/outdated (or just lies), and that breeds an environment that creates bad developers.
