But, aren't you folks web2?

> How could you guarantee that a file was stored and available for many years and do so such that no central party could arbitrarily take the content down?

As far as I can tell there’s no guarantee that blockchain data will be available without people actively sharing it…which makes it absolutely no different than something like BitTorrent which, ironically enough, is exactly what people who want their data to survive being taken down use to ensure it doesn’t go away.

Those big leaks of government data? BitTorrent.

Those digital libraries of questionable legally? BitTorrent.

My company put me on a "web3" project recently, and as someone who has done some kind of web development, at least at the hobby level, since 1999, I can tell you that there's quite a bit of difference with web3. I think the web skills from a decade ago translate better to web-dev today than web-dev today translates to web3 development. With web3 you have to consider the different ways to get on-chain data, and the state is all on the blockchain. Testing is a nightmare and the tooling around development and deployment are still immature.

And that's before even getting to solidity or other languages you use for the "backend"

People criticize technology all the time on this forum. Is this pointless because useless technology would die on its own anyway? Maybe eventually, but only after wasting resources.

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/

[1] - https://ceramic.network/

[2] - https://www.openzeppelin.com/contracts

[3] - https://hardhat.org/

[4] - https://trufflesuite.com/

[5] - https://geth.ethereum.org/docs/rpc/server

[6] - https://www.npmjs.com/package/ethers

But Yao42 works at Coinbase, and I want to know his point of view on why he says this.