I don't know how many of you follow the updates put out by @blocktrades for his team^. They are more technical in nature and not everyone can follow, but the language is sometimes more accessible to the regular people.
^) For readers coming from outside Hive, Blocktrades is the leading team in developing the blockchain core of Hive (and now additional frameworks and tools, like HAF)
The latest update was intended for programmers' eyes, not for the regular people.
The post is a guide to set up a HAF server for developers, plus a description of what HAF is and how it helps developers create decentralized apps much easier on Hive.
Basically, they can write their back-end code in any language that supports SQL queries, using a PostgresSQL database.
Even php works with PostgresSQL databases, and that's a language often used to handle the server-side programming of websites. That's to mention another language not mentioned as often as python or C++ here on Hive.
Introducing a database layer between the blockchain core and the dapp programmers is the best thing that can happen for the ease of use of the technology - on the programming side - and it will likely lead to a growing number of dapps in the Hive ecosystem.
The focus was wisely chosen, in my opinion. Don't focus on end users directly, focus on dapp creators which will bring end users. Much more impactful!
And HAF was blocktrades' team main focus since the last hard fork.
What does HAF mean for the regular person on Hive?
Directly, nothing. Indirectly, immensely.
HAF eases development, which means development will go faster AND it will become accessible to a broader category of programmers.
Which means we will likely see more dapps on Hive and more reliable (as in with fewer bugs), because by using HAF the developers use SQL queries - which they probably familiar to -, not the blockchain technology directly.
This is certainly the opposite direction than Ethereum has taken. Instead of forcing ALL developers learn a language used less frequently, and open the smart contracts to vulnerability because developers do not master the language and inherently produce buggy code, do the opposite. Allow the developers use the languages they are most comfortable with and put at their disposal tested and optimized SQL code they can use without worrying about bugs or performance issues.
Which do you think is better? I certainly vote for the flexible (and safe) solution.
Posted Using LeoFinance Beta