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

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?

The idea of JSX is I think genius.

If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.

But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.

This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.

https://github.com/chentsulin/awesome-react-renderer

So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.

This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)

sorry about last part, old programmer wandering.

I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.

I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.

I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.

What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!

> 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’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.

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..

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.

I'm still designing on paper with crayons (not a joke)

I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion.

Are your designs huge ?

One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together.

Like a super low budget Balsamiq

I'm kinda digging the idea.

Maybe I'll show HN, it's one of those ideas I have that just feels "too dumb" to be useful outside of my universe.

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.

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.