Why Bitcoin apps are hard, and are Ethereum apps easier?
They covered a few different topics, primary among which was the relative easy of building Ethereum apps as compared to Bitcoin apps. They lamented at the dearth of compelling Bitcoin apps currently deployed, and identified the primary culprit to be the limited Bitcoin scripting language.
To be specific, the apps in question were decentralized Bitcoin apps. That is apps which do not depend on a trusted third party to function . Traditional centralised apps, like gambling sites, marketplaces and exchanges have flourished, and are clearly easy to build — if only insecurely.
Its not about the scripts
There is certainly a space of decentralized apps which are an order of magnitude simpler to build on Ethereum due to the difference in the scripting language (although their utility I am less optimistic about), but this is not the driving factor behind the absence of fully developed apps on Bitcoin today.
I have personally been working on a decentralized Bitcoin app — JoyStream, for close to two years now. Of the close to 60.000 lines of code in our code base, less than 50 have anything to do with actual scripting. Looking at other decentralized Bitcoin  apps indicate a similar story.
- Storj/Sia — Decentralized cloud storage
- OpenBazaar/Bitmarkets — Decentralized e-commerce
- Alexandria/LBRY — Decentralized media platform
- Bitsquare/Mercury Exchange — Decentralized crypto currency exchange
None of these rely on sophisticated scripting, and none would significantly benefit from the more powerful Ethereum contract language. So what gives? Why are these apps taking so long, and why are there so few of them?
By analogy to the web, building a Bitcoin application today often involves building your own browser, rather than just your website.
Looking at what these apps have to get working, beyond scripts, tells a more accurate story of what makes these apps hard to build.
- Wallet: While there are many consumer wallets, many Bitcoin libraries don´t actually offer a flexible wallet library, leaving many projects to build their own minimal application specific wallet.
- Daemon: For web apps, programmatic control can be done using the same interface which drives the browser. For decentralized apps, which run fully client side by definition, this is an extra interface which has to be explicitly built.
- CLI: A human operator may need to manage an app instance for maintenance or analysis purposes, this requires a command line interface.
- Custom p2p messaging protocol: Almost all require a new messaging standard for coordinating application specific activities.
- Secondary p2p system: This is stuff like another blockchain, BitTorrent, a DHT, IPFS or Tor.
- Centralized support: Be it reputation, full nodes, indexing service, wallet services or double spend detection, most also require some centralized support to function well and be easy to use.
- Deployment: Packaging, installing and running binaries, securely, requires significant effort. The install process has to be simple, yet allow customization, and the running application as to interact nicely with the host operating system and desktop environment.
- Auto updates: It is essential that all participants use the latest interoperable version of whatever protocol your application defines, hence one has be able to push updates in some manner, and this has to be done securely.
- Usage & error analytics: This is trivial for web applications, yet a very unexplored issue for decentralized applications, as it does conflict to some extent with the goals of such applications.
All of this has to work across multiple operating systems and desktop environments.
Yes, Ethereum apps are easier
Not withstanding other issues with the Ethereum technology and ecosystem, I do believe it currently may be easier to build apps on that platform. The primary reason is the very innovative and user friendly Mist browser. It ameliorates a number of the challenges described above, and in particular making it all work cross platform. Sadly, in the Bitcoin space, there is a lot of wasted effort across these apps, dealing with infrastructure issues which have little to do with the app. This means there are fewer apps, and they take longer to build and improve.
What can be done?
Application developers would have a much easier time building, distributing and maintaining their apps, if there was a general purpose browser which standardized a lot of the grunt work. It should include some sort of application framework which standardizes solutions for
- Namespace — Blockstack, Namecoin
- Identity — Blockstack, Netki, uPort
- Payments — Bitcoin, Lightning, Zcash
- Privacy — Tor, I2P
- Smart contracting — Ethereum, Counterparty, Rootstock
- Storage — Storj, Sia, Filecoin
- Publishing & distribution — BitTorrent, IPFS
- Key management — A Bitcoin HD key store with a BIP44 like convention for multi app support
- API generation — The application should be able to define an API which could get exposed through a variety of IPC/RPC channels.
- Application updates — Signing by one or multiple parties to push out a new version.
- Analytics —Something like the permission system on Facebook or the Android/Iphone app store, where the developer must be granted some well defined and standardized privileges.
Its hard to say how this sort of thing should be put together, given how little work has been done on the application level so far, but it seems inevitable that something like this will emerge. Brian Armstrong recently wrote about the need for such a browser like infrastructure, and Blockstack Inc has been making noise about something like this in the works.
Hopefully this will go a long way in closing the difficulty gap between traditional web applications and decentralized applications, and only then do I think the Bitcoin scripting language has a chance of becoming a primary constraint.
 I know this is not a really crisp definition, but bear with me.
 Some of these are actually not strictly Bitcoin apps, but they were included because they use a Blockchain which is sufficiently similar in terms of scripting to demonstrate the point.