Ancestors

Written by Alex Russell on 2025-01-21 at 20:27

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

Written by Alex Russell on 2025-01-21 at 21:18

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

Written by Alex Russell on 2025-01-21 at 21:23

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

Written by Alex Russell on 2025-01-21 at 21:30

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

Toot

Written by Koire on 2025-01-22 at 07:09

@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

Descendants

Written by Alex Russell on 2025-01-22 at 10:42

@koire 🤦🤦🤦

=> More informations about this toot | More toots from slightlyoff@toot.cafe

Written by arclight on 2025-01-22 at 13:54

@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

Written by arclight on 2025-01-22 at 14:17

@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