The main problem is who gets to decide on the one anointed approach. Diversity ends up being a good thing, and also makes everything more messy and more complex.
Take your example of the Open Web. I wouldn't be in software without the Open Web. I hand-write HTML and CSS to this day! But many people hate the web stack. They hate the ergonomics and enjoy better ecosystem for nearly every possible thing implemented in the web. I think ultimately, that's ok and it's "worth" having competing standards, because the alternative is - pardon the dramatics - authoritarian.
edits:
> #2) Check for prior art first. The problem may have been solved before...
I generally take issue with the statement "this is a solved problem". It ends up killing critical thought on the vine. I think everyone is better served thinking critically, and yes maybe something off the shelf is the right choice. But think critically, and freely, first.
> #3) "be opened-minded to other approaches"
contradicts the idea of building one-thing all-together no?
I think the point is that the decisions on direction shouldn't be made behind entirely closed doors by insiders. Outside input should be taken seriously, with invitation to dialogue, rather than chasing some narrowly-supported vision.
As a web developer myself, I too am baffled by the folks who don't like the Web stack, but fine.
And good points, I guess I wasn't too concrete on "unify on one approach" vs. "consider all options". So to solidify my thoughts, I do think diversity in approaches is a good thing. It would just be great if any parts could be shared so that others could iterate on the same idea.
For an example of a missed opportunity for diversity, if only React Native had originally architected itself as Reactless Native + React, we could've had equivalents for each different renderer by now (e.g. Vue Native, Angular Native) based on that Reactless Native base.
For an example of the merits of unifying on one approach, see Yoga Layout. Flexbox has proven to be an agreeable layout model, and because it's so solid (apart from where it varies from the spec, which I do grumble about) various different cross-platform projects have benefitted from unifying around it as a reliable building block.
I guess my grumbles with Yoga's spec deviations echo your distaste for the "it's a solved problem" sentiment, too. Even established solutions should be open to improvement and evolution, and I had that partially in mind when talking about being open-minded.
Not everybody who's coding is doing it in a tech company on a complex multiple-person team project. I'm a software mechanic: I do really small scale tweaks for small businesses (I mean SMALL - my current project is for a business with one owner and 2 employees), non-profits, libraries, etc.
In those use cases, there can be good business reasons to do things this way: Part of my current project is building something where odds are there won't be another tech person around regularly and it needs to last for several years (the information is evergreen). For something I want to run for 8+ years with minimum fuss that doesn't require storing user data and that may need to be ported from LMS to LMS or eCommerce platform to eCommerce platform/won't be broken by updates (because again, no regular dev to maintain it and check compatibility), using basic HTML, CSS, and even vanilla JS can make sense. I can write something in HTML/CSS/vanilla JS and it will probably run in browsers until the heat death of the universe.
I count writing JSX as hand-written as the child comment mentions. Also HAML in rails. I realize this perhaps is a fuzzy definition as we move along the spectrum of automation and abstraction.
What I mean to say is I still have a more-or-less 1:1 relationship with both HTML and CSS APIs to affect user interfaces. Like how do make round corners I need to know `border-radius: 100%`, or `borderRadius: 1rem`, etc
(And you're right, in all projects where "I have my way" meaning it's personal or in a small-group, I have the freedom to choose low-level vanilla primitives. Less so at work in large teams where everything is a build pipeline.)
I think writing a React component using JSX counts as "hand-written" HTML and CSS. Definitely when you're writing the low-level components that other stuff is built on.
Take your example of the Open Web. I wouldn't be in software without the Open Web. I hand-write HTML and CSS to this day! But many people hate the web stack. They hate the ergonomics and enjoy better ecosystem for nearly every possible thing implemented in the web. I think ultimately, that's ok and it's "worth" having competing standards, because the alternative is - pardon the dramatics - authoritarian.
edits:
> #2) Check for prior art first. The problem may have been solved before...
I generally take issue with the statement "this is a solved problem". It ends up killing critical thought on the vine. I think everyone is better served thinking critically, and yes maybe something off the shelf is the right choice. But think critically, and freely, first.
> #3) "be opened-minded to other approaches"
contradicts the idea of building one-thing all-together no?