The correct response to realizing computers are fast is not to make your software slow, because:
a.) you won't benefit as much as you hope
b.) if you break pro-user norms, so will every other site/app/library, and your thing will feel slow even if it's "fine" in isolation
c.) HW bounty is not evenly distributed, so your product becomes less usable non-linearly below some resource floor
Pretending constraints don't exist is not engineering, it's bullshitting.
=> More informations about this toot | More toots from slightlyoff@toot.cafe
Software cultures that indulge in ignorance of constraints facilitate magical thinking, which eventually erodes the foundations out from underneath even conservatively-constructed experiences if left unchecked.
This is bad for users, but also business. A great shame of frontend's lost decade is that we lost the ability to adapt because so much of the community was high on frameworkism.
=> More informations about this toot | More toots from slightlyoff@toot.cafe
And I don't know how to say this any more directly than this: any frontend engineer who brings React or Angular on premises (without an honest bakeoff & guardrails), in 2025, is de facto bad at their job.
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@slightlyoff I made you proud the other day in a meeting where the person with the money said “…and for the frontend we are probably going with react” and I managed to talk them out of it.
=> More informations about this toot | More toots from janl@narrativ.es
@janl May I ask what you talked them into instead?
=> More informations about this toot | More toots from mandelhorn@mastodon.social
@mandelhorn it was a discussion about an R&D project and I made the case that the frontend tech choice needs to be part of the R.
=> More informations about this toot | More toots from janl@narrativ.es
@janl @mandelhorn I spent yesterday digging through our procedure for upgrading and releasing acquired software. The whole process starts with a needs assessment - understand what we need the software to do before selecting the software to do it. Greenfield or upgrade, you have to ask what your needs are, have they expanded or changed since your last release. Needs drive software selection and requirements, requirements drive tests. This is fundamental software lifecycle management and you ignore it at your peril. It's only made worse by the expectation that code can be released as fast as it takes the unit tests to pass - it shortcuts the review and evaluation process which cannot be automated away.
Resources have a limit and a cost no matter how much those costs and limits are buried or masked by 'scalability'. Do you ever look at your code's memory or disk or CPU or network use when there's not an obvious performance issue, just to understand what your code consumes under normal operation? Thus isn't a matter of optimization, it's about getting a basic understanding of your code's resource usage.
=> More informations about this toot | More toots from arclight@oldbytes.space
text/geminiThis content has been proxied by September (3851b).