Sounds like you've been at this since I have (mid-late 90s as well)! I somewhat agree with you on the state of tooling compared to web dev today but I'm not su

Sounds like you've been at this since I have (mid-late 90s as well)! I somewhat agree with you on the state of tooling compared to web dev today but I'm not sure it matters or is terribly relevant to the point OP is making. I've been in this space one way or another for five years so prepare for a (somewhat anecdotal) "dump" that you may (hopefully) find useful for the new project that you've been put on. You mentioned Solidity so let's assume an EVM compatible chain and ecosystem. At this point I'd call anything actually on chain the "back backend". Of course Solidity is the smart contract language but due to costs, speed, etc of the chains themselves the data is all over the place... That's how we've ended up with things like The Graph[0], Ceramic[1], etc. As you've likely already experienced interacting with the chains themselves in any capacity is remarkably creaky hence the plethora of somewhat ironically centralized API providers and solutions with many layers of insane amounts of code and backend infrastructure to make things actually work for anything beyond a toy (like the various Alchemy APIs I provided an example of). This is before you get into anything like IPFS, Filecoin, etc but once again the typical interaction with these is via heavily abstracted libraries and HTTP gateways that do their best to look like any other web2 service. Smart contracts, by their nature, are rarely written and rarely deployed. If you look at some of the biggest "apps" in the space smart contracts represent a tiny fraction of the amount of dev work compared to the overall solution. Take OpenSea (as one example) they've deployed a smart contract twice in five years of operation AFAIK. If you look at their frontend and API docs it becomes clear really quickly they've done a lot more work in areas that at the risk of deploying "No true Scotsman" I would say at least 95% of the dev work in web3 is effectively web2. Now that we're talking about smart contracts, the stakes are so high there is actually a fairly robust amount of tooling IMHO. Maybe not robust compared to the state of 30 years of web development but between OpenZeppelin[2], Hardhat[3], Truffle[4], etc there's a lot out there. From everything I've seen in the space over half my decade by the time you import a bunch of OpenZeppelin contracts there's almost always very little Solidity left to be written. As traditional cryptography devs have learned "writing your own crypto" is almost always a really bad idea. If you were to look at LOC for anything in the web3 space my original point is backup up by the data. Metmask is used by 30 million people and it's all web dev (backed by an Ethereum JSON-RPC[5] interface hosted by MetaMask sponsor Infura by default)... The rest of any user facing application is your frontend pulling in ethers[6] and MAYBE a bog standard web2 service/microservice backend. Then you're off to the races. There is SQL, NoSQL, etc all over the place in web3. From my personal experience and everything I've seen I'd venture to guess that maybe 1/50 devs in the space ever touches Solidity (likely much higher). Everyone else is doing what they've always done by reading the docs for whatever JS/TS libraries they're using. I've personally worked on many projects where web2 devs became "web3/blockchain devs" in an hour - to my original point of saying you're a "blockchain developer" because you're using ethers is really funny to me. My overall point being (and to assuage the concerns of OP) the vast majority of devs that start in web3 feel right at home in web2 and vice-versa. I know exactly one dev who I would call a serious "blockchain developer". They came from a web dev background and they're all in on Cardano which meant picking up Haskell (which would send most web devs running for the hills). If a dev were to start with Cardano + Haskell I have no idea where they would end up if they left "blockchain development". [0] - https://thegraph.com/en/ https://thegraph.com/en/ [1] - https://ceramic.network/ https://ceramic.network/ [2] - https://www.openzeppelin.com/contracts https://www.openzeppelin.com/contracts [3] - https://hardhat.org/ https://hardhat.org/ [4] - https://trufflesuite.com/ https://trufflesuite.com/ [5] - https://geth.ethereum.org/docs/rpc/server https://geth.ethereum.org/docs/rpc/server [6] - https://www.npmjs.com/package/ethers https://www.npmjs.com/package/ethers