that's a very high quality question, in comparison to the others.

here is what you're missing, and is very easy to miss:

the third party, unaffiliated, developer experience is better on an EVM than it is is on a traditional centralized database. Than it is on a shared database with a bunch of signers. Than on any "web 2.0" cloud platform. the developers continue to bring their entire audiences with them, even though those audiences are quite small, they've grown in aggregate to be large enough.

in web3, of which EVM platforms dominate and are the most mature, there is a tiny payment for deploying your application once, and then it exists in perpetuity for free at unlimited levels of bandwidth. your users pay to update the state of your application, and in many cases you can earn from them doing that.

there is absolutely nothing in the cloud world that achieves the same thing at the same cost. the payment paradigms are entirely different, you have to pay for hosting, deployment, the thing that handles your deployment, additional workers to unbottleneck your continuous deployment, the bandwidth, bandwidth spikes, and get nickel and dimed on a ton of more things, or paying a premium to a service that handles all that for you.

additionally, the concept of "composability" is attractive in the web3 space, again spearheaded by standards on EVMs, the concept is that third party applications are automatically compatible with each other. there are infinite permutations of combinable operations one can do or enable amongst deployed applications. you can compose, or combine, applications in a far less cumbersome and less fragile way, than with REST and APIs of different people's apps in the web 2.0 world.

and on top of that, if one of those permutations becomes useful and you make it user friendly to do so, you can collect a toll for others doing that operation. this is just financial services, where "basis points" are collected by intermediaries.

a common application are forms of lending. initiating borrowing, trading the opportunity, and closing the loan within a split second, leveraging 3 - 10 financial services at once, is something that's better faster and cheaper than what has been possible outside of the blockchain space. the ability to do so is gatekept by the other financial industry and payment rails in ways that are no longer necessary to debate. now you can do these things with $3 in capital instead of needing $3 million dollars to pursue getting an API key from some old slow moving organization.

the compelling reason to create a new EVM are to change some basic parameters. block time, the size of contracts (the aforementioned operations) that can be deployed, and which standards are included into that chain, and of course the governance model - how are new standards deployed and how are transactions added. making stablecoins a first class citizen would need a new blockchain. how your governors/validators/nodes and RPCs function under load would need a new blockchain.

it is very attractive to developers that they can deploy applications "in the cloud" that have a very nominal cost, doesn't cost them to maintain even amongst spikes in bandwidth. they don't have to incorporate or do any formalities while having unlimited financial upside, solely because there is already hundred of billions of dollars in notional value sloshing around in that space to cater to already.

edit: I'd actually like to work with Stripe or other web3 organizations again on these kind of applications, now that I notice how boutique it still is to understand what's going on, email in bio

▲

kji 6 days ago | parent | next [-]

> the third party, unaffiliated, developer experience is better on an EVM than it is is on a traditional centralized database.

This is definitely a take, given how easy it is to write a program with security bugs using Solidity due to specific concerns like reentrancy that only exist due to the unique way smart contracts work. The inability to "undo" a fraudulent or mistaken transaction without requiring all validators to fork the chain also makes this a non-starter for many developers.

> your users pay to update the state of your application

Also a weird thing to call a "feature" for developers when this actively drives away potential users.

	▲	yieldcrv 6 days ago \| parent \| next [-]
		> Also a weird thing to call a "feature" for developers when this actively drives away potential users. while being a funnel of 1 step for the users already in the ecosystem that find your application the ecosystems turns the entire Web 2.0 marketing funnel industry on its head because the initial call to action is a payment. All of the mystery of converting to a paying customer is obsoleted in favor of unbridled commerce this just points out another way its optimal for developers with ideas, when aiming for revenue in a web3 architected project for crypto natives. they have frictions, you solve them, they pay you. If you aren’t catering to crypto natives already, don’t launch a web3 application. the space is already big enough to ignore other potential users, and if you want that to be your cause to help the UX to grow the space, you can do that too. > security bugs using Solidity To your other point, I don't see 2016's smart contract coding problems as show stopping criticisms, because this is the lowest hanging fruit of experience for anyone learning solidity, all while standardization of open source methods has solved those building blocks just like in other languages. additionally, you can write an insecure application in the web 2.0 space as well. There are enough and a growing number of developers that aren't afraid of deploying code on a blockchain. a lot has happened in the last ... decade? developer tooling has improved.
	▲	whimsicalism 5 days ago \| parent \| prev [-]
		yes, the developer experience is better on a platform where you can write code (potentially with bugs) than a platform where you can’t write code or do anything programmatic at all.

▲

kortilla 6 days ago | parent | prev [-]

The developer experience is irrelevant when it comes to handling money in volume.

Take the spacex example above. They are using a stablecoin to abstract away a bunch of illiquid and unstable foreign currencies. Getting rid of that huge pain of carrying 100 countries’ currencies via various banks is the value prop. The API could be cobol and it wouldn’t matter.

▲

yieldcrv 6 days ago | parent [-]

and yet, when you look at what comprises a stablecoin alongside the frictions unstable foreign countries have, you'll see why they occur on EVMs and not some other architecture

> The API could be cobol and it wouldn’t matter

you can probably get cobol to transpile to bytecode that EVMs can use. I get the point you're trying to make that excludes blockchains, but you don't make that point

	▲	kortilla 2 days ago \| parent [-]
		If you thought I was trying to exclude blockchains, reread what I said because it wasn’t that. I’m saying the API can be complete trash and whether it’s a blockchain or a traditional bank, the thing that will drive the decision is money. >the third party, unaffiliated, developer experience is better on an EVM than it is is on a traditional centralized database. The developer experience is completely irrelevant when millions of dollars a week are on the line. The API doesn’t matter.