That's how I try to deal with it. Also if you're not sure which thing is better do POCs with both solutions. Alternatively if you're working on a greenfield project and a week in things don't feel right don't be afraid to try rewriting it with one of the alternatives you were considering, it'll be a slight hit to productivity for a day or two but it'll pay off long term
By following these guidelines I've never felt on a project that I've painted myself into a corner with the tech stack, or chosen something very bad that is not reversible.
Let's say you are a great poker player. When you get dealt a good hand, you play it and end up loosing - does that make you a worse player?
Turns out even the best of all players loose quite frequently. What distinguishes them from others is that they make the best choices with the limited information they have at the time. They later go back and learn from any mistakes they have made and move forward.
[0] https://www.econtalk.org/annie-duke-on-the-power-of-quitting...
Here's another way of looking at that problem:
How many of those tools and technologies existed 1, 3, 5, 10 years ago?
Would you trust a six month-old tool on github to form the nucleus of your -- probably mundane, in the good way! -- project? Would you risk it all for the chance to have a slightly different way of rendering CSS or generating HTML?
... I didn't think so. React's been around for a long time now and it's got a lot of momentum and people who know it. So that's a pretty safe bet. Rinse and repeat.
Not all tools are critical and you do have some leeway. But when in doubt, pick something you can easily hire people to help you accomplish; that has been around a while; and that feels established.
That was true for jQuery as well; and yet, it is clearly no longer the right thing (tm) to choose for a project. Not because it's no longer cool; but because the underlying technology — the web browser — has gotten so much better it is no longer relevant.
Same fate may await React. At least, with jQuery it's pretty straightforward to gradually wean oneself off of it. I don't know how firmly we are going to be stuck with React when its time comes.
The concern is abandoned projects that no one knows how to use, not that something is a bit old. React is beyond that point. It's not just the tech junkies hopping from the latest fad using it. There's been enough widespread adoption that there will still be React projects in 20 years.
It was that someone put in the time to write a JS preprocessor that went along with their framework. That was React’s novel addition
Without a preprocessor, users of your framework either use plain JS to generate HTML (i.e. jQuery) or you use templates.
Both of them always looked really ugly on frontend
With React’s JSX preprocessor, you can write HTML by… writing HTML. And you can mix custom components without doing some weird and ugly syntax
Does React use a shadow DOM? Yes, but so could have jQuery or Handlebars.js too, and it wouldn’t have mattered. People don’t care how it works as long as it works. As far as libraries go, what gets adopted is what looks and feels the nicest — as it should be
No. You must be confusing it with virtual DOM.
As for React, what we are currently observing is that 1) it's a fairly large library in itself (~50kB of minified gzipped javascript); 2) it has a relatively slow DOM update mechanism; 3) it rerenders too eagerly, making it too easy to further degrade performance; 4) it's a lock-in into a non-standard jsx syntax, forever tying you to preprocessors.
What conclusions an architect would make looking at all this, I do not know.
You chose the latest and greatest web framework? Great! How many developers at your company will know how to use it? How long will it take for them to learn it? How big is the talent pool you can hire from? How much time will it take to migrate your products to it? Who will support it, is it "wild west" open-source or does it come with commercial support? How does it fit with your deployment model? Has it gone through rigorous threat modelling? There are about a billion factors that may affect your choices and finding the right solution will always be a central part of the problem.
To actually answer your question about how I deal with this, this is why I do research. Let's say our product people come up with a brilliant new product idea that we don't have an existing solution for, then I'll spend some time on finding information about the available options and take notes on the benefits and drawbacks. I will try to find people who are experts in the subject and get their opinions.
What I can not do, is to actually go and gain a deep understanding of every single language/platform/framework/library there is, I'm just a human after all.
Choosing between mysql, sqlite and postgresql may be (do we need row level security? Would mysql multimaster benefit us? Do we expect to deploy many, small instances where the simplicity of sqlite will shine) etc.
There are many decisions to make building a solution - the architecture part has to do with fulfilling the requirements.
The tech-lead/senior developer/team lead part has to do with implenting the architecture - our team knows vue, so we go with that to implement the app. We're invested in ms sql so we prefer that to postgres - but sqlite would be a poor fit.
I generally try to keep design out of architecture. It’s what you need to satisfy product or service needs. The technology gets into how you want to implement. I try to leave that to the tech lead for the team.
You cannot predict the future. It is impossible know which choice will result in better outcomes. Whatever you choose has probably about equal chance of success or failure. So just make a choice, with a general idea of what you will do when the choice fails. Most choices are not make-or-break, so you should really not be agonizing over most choices.
It's a common fallacy to assign 50/50 probability to unknown distributions. Furthermore, many choices are not binary, or may not be as simple as right/wrong in hindsight.
But I agree with the idea of amortizing your perspective over many choices.
Realize that if you had chosen another solution, you would have other issues. Not "no issues". Probably not even "fewer issues" or "less severe" issues - just as high a chance
Realize that most technology choices actually have very little impact on the business. If one uses A or B, it does not matter much to do whatever it is your company does. Very few tech choices have the potential to kill the company/unit/product.
Realize that once a choice has been made, worrying about it does not help anyone.
So the goals are not perfection. Not anywhere close. Just something that:
1) lets us move forward now (avoid decision paralysis)
2) not worse than before (if so, just stick with what you got)
3) good _enough_ to deliver the needed business value
4) does not paint ourselves into a corner. Then we can always fix and improve things later
I have invested in some of these technologies. The biggest commonality is that they ALL have their faults and weaknesses. The key is ensuring everyone makes best use of whatever framework/package/tooling that you have invested in via a set of best practices and standardised processes. Over the last 20+ years, i've found you should only switch to something else if there are significant gains to be had. Otherwise it rarely offers more value.
How do you deal with the burden of knowing/predicting what the right thing (tm) is / will turn out to be? I am constantly agonising over choices I'm about to make, and almost invariably come to regret some of the choices that I, or our team, have made (which include, but are not limited to, React, Gatsby, Flow, Stylus, Enzyme, Jest, SCSS, single-page app architecture, possibly graphql, etc. etc...). Not that I'm an architect; but still. How do you cope?