Comment by regularfry
3 days ago
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.
I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.
Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
> The majority of web developers today suck
Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.
I do not even know if they would classify as "junior" devs.
This does not apply to ALL web developers, but many.
They still existed and wrote shitty code 20 years ago, or 30 years ago.
> React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year
proceeds to shame and suggests changing to the new paragdigm of the year.
> For a framework meant for serious adults
I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time.
And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.
Nice try, though!
mithril is hardly the new paradigm of the year
> Also, React is a nightmare.
I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.
However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.
React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.
https://mithril.js.org/
I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?
4 replies →
I've seen this happen many times:
Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.
PM: Looks great! Okay, the next thing is...
Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.
PM: This looks fine. Let's move on to the next thing..
If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.
But the system persists because both people are complicit.
Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page.
https://balsamiq.com/product/
When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
5 replies →
[dead]
How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?
Why don't those developers that care put important things the AC/DoD?
Maybe they're not doing Scrum?
That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.
The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.
I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.