This low-entropy, repetitive coding is not limited to the user interfaces. We do tend to describe the same structures and logic over and over again in front-ends, backends, and databases.
I am currently building an open-source project that tries to make the definition of applications from database structure to business logic to user interfaces, much more declarative and compact. If you are interested, you can try it on https://sql.ophir.dev
I usually see this in places/cultures that value code-beautification projects rather than delivering value to the customer. Sometimes, they even want to do the latter, but actually do the former.
If you work somewhere that focuses on delivering value, the devs constantly complain about technical debt that will never, ever get fixed. That's the only sucky part.
The problem is, of course, that simplicity follows complexity, not the other way around. Because of that, it's mostly "trivial" and "repetitive" tasks that receive polished tools for easy and compact expression. Anything new and non-trivial usually grows ugly and uncouth for quite some time.
Usually simple, lean, and logical is also beautiful; beauty is not a random quality. But sometimes too simple and too lean is not flexible enough; then that's a case of a wrong abstraction, or of premature optimization.
Stanley worked for a company in a big building where he was Employee #427.
Employee #427's job was simple: he sat at his desk in Room 427 and he pushed buttons on a keyboard.
Orders came to him through a monitor on his desk telling him what buttons to push, how long to push them, and in what order.
This is what Employee #427 did every day of every month of every year, and although others may have considered it soul rending,
Stanley relished every moment that the orders came in, as though he had been made exactly for this job.
It was a sobering moment when I realized that accurately described most of my job too.https://thestanleyparable.fandom.com/wiki/Dialogue#Introduct...
Even just the free demo! The demo is incredible as a standalone experience, and does not have identical dialogue / experience as the full game. It is in fact a meta-experience of the game.
Value, or short-term value? When the codebase gets hard to manage, the value is there.
Cheers and good luck!!!
Which browser/device are you using, and from where ?
The worst I'm able to get when manually disabling the cache and simulating a slow 3G connection is this: a blank page first, then text in the browser's font, then the text re-renders with the right font, then the icons load. The user should never see completely unstyled content.
The site uses "font-display: fallback" so this happens only on slow network connections. If the font loads fast enough, then the fallback never appears.
You can probably just use the system font for the title, and nobody would ever notice the issue.
Case in point I'm in the middle of, let's just call it what it is, an argument, because a new page in a new section of our app has a different design for form elements, specifically single check boxes (think TOS, affirmations, etc). Well we have shared components obviously, so we're reusing the component. No sense taking half a day or more to reskin this one checkbox on one page.
The amount of grief and manhours wasted discussing this checkbox would astound you. Thousands of dollars in payroll over multiple meetings so far with no end in sight because this particular check box just has to be slightly different. The ticket which has been feature-complete for over a week has no chance of being merged in November.
There is the old story about Steve Jobs and the Mac calculator app, where they made a calculator toolbox to build one in order to prevent him demanding seemingly arbitrary changes all the time.
https://www.folklore.org/StoryView.py?story=Calculator_Const...
This is 100% incorrect. Users do care about software being built for them, in a language they can understand and use, and they very much want it to be usable and accessible to them. You'll have to provide me with some citation showing otherwise for me to take that argument seriously.
> I would argue that i18n and l10n belong outside your language's framework (and obviously outside CSS).
Obviously Frameworks and CSS disagree with this assertion. Considering you've presented no argument though, I don't see why you would think that, for example, it wouldn't be important to style your site differently for different languages. Are Americans routinely reading rtl?
Edit: It just occurred to me you think this way because most everything you create is specifically created for you and those like you. You care, you just don't realize you care until it's taken away.
That's because they don't know what they are. They suffer the consequences of not having them though.
"stop" "STOP" “Stop” "STAHP"
These all mean different things even though it's just one language. To suggest that the way symbols are presented doesn't carry its own symbolic communication is willful ignorance at best, and at worst a kind of arrogant imposing that "my way of seeing things is the only correct way."
In a thread about the "bits of information transfer successfully encoded by AI on a UI implementation," I would expect an experienced engineer to notice the bandwidth of communication (or lack thereof) being demonstrated.
We know this, you don't need to tell us (and it makes your argument weaker that you did...).
The problem is, for every user it's a different 10%.