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
And let's just take a quick moment to examine the usual response of "React can be fast enough!"
Yes, good craftspeople don't blame their tools. They also don't bring shit tools to the job site.
What's being proposed concretely is the high-cost, low-confidence path based on little more than reckons. This is a demand that you to spend more to get less. And that's the optimistic version!
=> 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 👏👏👏
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@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
@slightlyoff Besides that, if there's any conversation allowed on overall architecture, I would argue that anyone who recommends (or blindly accepts) JS-first SPA architecture without a host of well-researched reasons to back up the strategy (and is obviously aware of the alternatives which were presumably rejected) is indeed bad at their job.
=> More informations about this toot | More toots from vanillaweb@intuitivefuture.com
@slightlyoff
I had a coding challenge for an interview to write a very simple spa that reads from an API and renders a page showing the results as cards. I wrote it in vanilla JS webcomponents (about 100 lines?) and used one of those drop in CSS style sheets (like water or something). I will never forget that the evaluation saying "This is not good coding because you didn't use a modern web framework like React or Angular but instead used legacy JS that is hard to maintain" (I argue using modern JS is definitely more modern than React). It had 100% scores on lighthouse, speed was amazing, file size was negligible.
=> More informations about this toot | More toots from koire@hachyderm.io
@koire 🤦🤦🤦
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@koire @slightlyoff "Use of a modern framework was not specified as a design requirement; if use of a large popular framework was important to you, you should have written it as a requirement.
As it is, the code passes all its functional and acceptance tests. It conforms to the language standard and minimizes resource use and dependencies in accordance with good software development and lifecycle management practices."
=> More informations about this toot | More toots from arclight@oldbytes.space
@koire @slightlyoff FWIW, I'm planning out the next release of some vendor-supplied safety analysis code. It will take substantially less than the 22 months it took to V&V and containerize the code the first time around - ideally I won't be waiting 6-8 weeks for IT to revise their procedures and get around to pushing things live this time.
Still, the process will likely take 3-4 months, mainly spent on review, evaluation, and documentarion. V&V will be more intensive in certain areas so there will likely be another big pile of questions (and possibly answers) sent back upstream. Ideally the release effort would be reduced to 4-8 weeks; any lower than that probably means the V&V process is being shortcut or the release isn't substantial enough to warrant an upgrade. We probably shouldn't be updating the production code more than once every 9-15 months unless there are critical bugs or there's a feature desperately needed by the code's users (safety analysts). Upgrading more frequently than annually is disruptive to the safety analysis process - our job is to support the engineering work being done. The software is a tool, not a product.
I do not miss web systems. At. All.
=> More informations about this toot | More toots from arclight@oldbytes.space
@slightlyoff What is the alternative to React?
=> More informations about this toot | More toots from danielinoa@mastodon.social
@danielinoa https://infrequently.org/2024/11/if-not-react-then-what/
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@slightlyoff Interesting article, will read 👍
=> More informations about this toot | More toots from danielinoa@mastodon.social
@slightlyoff
genuine question from someone not fully up2speed with the high speed carousel that is FE dev...
what's a reasonable alternative for your not too fancy admin / db backed UI?
HMTX?
=> More informations about this toot | More toots from oschonrock@mastodon.social
@oschonrock Server-side templating (Rails, Django, etc. etc.).
Moving logic to the client is wicked expensive, and requires the utmost care (and evidence-based justification):
https://infrequently.org/2024/11/if-not-react-then-what/
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@slightlyoff
right yes
... that was implied when I said HTMX, which is HTML on the wire..
for me this is "back to 2008".. and what I am actually much more comfortable with
=> More informations about this toot | More toots from oschonrock@mastodon.social
@slightlyoff
Because I'm currently waiting for a medical exam I want to share a war story 😅:
I work as a full stack eng for an online shop, being only 1 of 2 people caring for frontend.
Around 2018 the problem was "cart page is too slow, do something".
Being on the crossroads we opted for... drums
1/2
[#]warstories #webdev #frontend
=> More informations about this toot | More toots from haroha@gruene.social
@slightlyoff
"Render frame first, ship data as json when ready and render on frontend".
"With mustache".
Ahahahaha 😂
I'm in pain ever since.
If you have to, use htmx.
Not, that I was new in the field then... 🤦
Noth' said, It's live and learn, baby, live and learn 👍
2/2
=> More informations about this toot | More toots from haroha@gruene.social
@slightlyoff @haroha Me a few days ago in our IT team chat. (translation in alt text)
=> More informations about this toot | More toots from fluchtkapsel@nerdculture.de
@fluchtkapsel
Yeah, that's the stuff! I'm all in on: why burn electricity on wordpress when all you do is ship static html all the time. 😅
I'm using https://getpublii.com . It's really enough for a blog. It provides a serviceable UI with wysiwyg, if you wish. Only downside is multi user is a bit hard.
@slightlyoff
=> More informations about this toot | More toots from haroha@gruene.social
@slightlyoff I don't think this is how that happens.
A (web*) developer starts off with a fast computer and fast internet due to the nature of their job (rapidly making and editing a web app)
so they tend to have better monitors, processors, RAM, and internet.
thus they don't notice how slow and bulky their code is.
=> More informations about this toot | More toots from risottobias@tech.lgbt
@risottobias That is exactly what I have been blogging about as the frontend privilege bubble[1]. But it's all facilitated by a software culture that sets no expectations of grounding, and apportions no responsibility for outcomes.
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@slightlyoff see that seems more accurate. it's an un-examined systemic bias of developers.
it's not as your first toot says "the correct response to realizing computers are fast is not to make your software slow",
it's that web developers own F1 engines while everybody else owns ride-on lawn mowers.
=> More informations about this toot | More toots from risottobias@tech.lgbt
@risottobias This is literally what React's developers did. It's what they continue to make excuses for, and never apologize or clarify about. They had global knowledge that React was unworkable for the low end and mobile without extreme care, but only sold upside and (always false) dreams of cheap client compute. That's worthy of ridicule and comment.
=> More informations about this toot | More toots from slightlyoff@toot.cafe
@risottobias @slightlyoff In the 90s, I developed on a decent PC, but always tested on a previous gen PC.
=> More informations about this toot | More toots from Lydie@tech.lgbt
@slightlyoff Realizing that performance is accessibility is what made me understand why it's underfunded.
=> More informations about this toot | More toots from twifkak@mas.to
@slightlyoff
Always code for good performance on the slowest hardware or average-worst latency. I just assumed that was obvious!
=> More informations about this toot | More toots from tomjennings@tldr.nettime.org
@tomjennings This is a lost lesson in the contemporary frontend discourse.
=> More informations about this toot | More toots from slightlyoff@toot.cafe This content has been proxied by September (3851b).Proxy Information
text/gemini