ERC-20 token is a de facto standard in Ethereum world. It is supported by all wallets, exchanges and applications. Yet, ERC-20 token is a standard, and there are a few different implementations with their own nuances.
EOSIO.Token is a standard for a token and concrete implementation at the same time. EOS token itself is a prime example of EOSIO.Token contract.

ERC-20 token standard defines the following interface:

name
Returns the name of the token - e.g. "MyToken".

symbol
Returns the symbol of the token. E.g. "HIX".

decimals
Returns the number of decimals the token uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation.

totalSupply
Returns the total token supply.

balanceOf
Returns the account balance of another account with address _owner.

transfer
Transfers _value amount of tokens to address _to, and MUST fire the Transfer event.

transferFrom
Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.

The transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies.

approve
Allows _spender to withdraw from your account multiple times, up to the _value amount.

allowance
Returns the amount which _spender is still allowed to withdraw from _owner.

Events

Transfer
MUST trigger when tokens are transferred, including zero value transfers.

Approval
MUST trigger on any successful call to approve(address _spender, uint256 _value).

As you can see ERC-20 standard handles a few things at once:

  • Create your own token with name, symbol, decimals and supply.
  • Query balance for an address and total supply.
  • Transfer tokens between accounts.
  • Allow third parties to manage tokens on user's behalf using the combination of approve/transferFrom methods. Allowance can be checked as well.
  • Transfer/Approval events which are fired for every transfer and approval methods calls. Thus providing a complete history of operations.

Now, let's look at EOSIO.Token. It defines the following interface:

void create( account_name issuer, asset maximum_supply);
Creates token with a name, symbol and max supply.

void issue( account_name to, asset quantity, string memo);
Issues a certain amount of tokens to an account.

void transfer( account_name from, account_name to, asset quantity, string memo);
Transfers tokens from one account to another.
      
inline asset get_supply( symbol_name sym) const;
Gets the total supply for a token.
         
inline asset get_balance( account_name owner, symbol_name sym ) const;
Gets token's balance for an account.

EOSIO.Token interface has way fewer methods and as a result, it can be used for:

  • Create your own token with name, symbol, and supply.
  • Issue tokens within max supply to an account.
  • Transfer tokens between accounts.
  • Query balance for an account and total supply.

ERC-20 and EOSIO.Token share same functionality, but ERC-20 can do everything EOSIO.Token does and more. Specifically, it allows third parties to manage tokens on user's behalf and generate Transfer/Approval events on every action.

Why there are no events at EOSIO.Token? EOS blockchain doesn't have events at that moment. So it is not possible.

Why there is no third parties capabilities at EOSIO.Token? I would say it is a good thing, because an extra functionality is the source of additional attack vectors, like 'ERC20 API: An Attack Vector on Approve/TransferFrom Methods'.

EOSIO.Token is a minimum viable version of a token, which reduces its attack surface. At the same it is not going to cover all potential needs, so we are definitely going to see new token contracts for EOS, which will have additional features as pausable, mintable, burnable, and etc.

Related: