7 ms·

TypeChain: TypeScript Bindings for Ethereum Smart Contracts

95 points by bobbrown 9y ago

eximius 9y ago
Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc? I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.
- itsnotlupus 9y ago
  Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.
  - eximius 9y ago
    Formal verification is needed but syntactic sugar is not inherently the problem. The problem is that there a a million gotchas because it looks high level, but isn't. Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract. Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly... I am not equipped to exhaustively lament it as a language, but it is not a pleasant experience.
    - j_s 9y ago
      Understanding Ethereum Smart Contracts | https://news.ycombinator.com/item?id=15786780 https://news.ycombinator.com/item?id=15786780 HN user jatsign shared some of his inital gotchas two weeks ago.
- krzkaczor 9y ago
  Sorry, this is for communicating with the already deployed contract.
ChrisRus 9y ago
I wrote ARCcore.filter to solve many of the issues discussed. And, because it works at the JavaScript function level to normalize/validate function I/O it works well with _everything_ to solve the runtime data problem. And, it opens up a new world of type-based runtime metatemplate programming to JavaScript developers. https://encapsule.io/docs/ARCcore/filter https://encapsule.io/docs/ARCcore/filter
buybackoff 9y ago
We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state channels implementation (implemented in a sibling repo). The concept of TypeScript code generation is very valid, saves a lot of time during rapid prototyping and contracts become self-documenting, with IDE errors after signatures change. Generated contracts are isomorphic and work well from Node.js and a browser while being simply packed with NPM. https://github.com/dbrainio/Soltsice https://github.com/dbrainio/Soltsice
- krzkaczor 9y ago
  Hey, TypeChain author here. Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar). Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it develops further!
  - buybackoff 9y ago
    Hi! Thanks! I will replace truffle-contract with web3 1.0 contracts API. Current web3 1.0-beta doesn't work well with TS. The dependency was accidental since I was already using it, while writing codegen stuff took very little time and was just a helper script in a contracts repo initially. Our public API is plain async TS, truffle-contract is only an implementation detail. Need for such solution seems so obvious given that we have Go ABI gen tool for a similar purpose and JS is the main language for DApps (and probably Node.js for backend is more popular than Go). Also, truffle migration looked like a fragile black box, and testing with `jest --watch` instead of truffle suite is much nicer and faster.
azr79 9y ago
TypeScript is the present and the future of web, not web assembly

95 points by bobbrown 9y ago

Something is not clear to me: can I use this in any way to generate EVM bytecode to deploy a contract? Or is this solely for use after deployment using the ABI generated by solc, etc? I think it is the latter, but I was really hoping for the former. I welcome any improvement over solidity.

itsnotlupus 9y ago
Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.
- eximius 9y ago
  Formal verification is needed but syntactic sugar is not inherently the problem. The problem is that there a a million gotchas because it looks high level, but isn't. Defaulting to `storage` instead of `memory` for variables is one huge issue that can let you silently corrupt your contract. Lack of builtin manipulation of datatypes, weird types that are cumbersome to use correctly... I am not equipped to exhaustively lament it as a language, but it is not a pleasant experience.
  - j_s 9y ago
    Understanding Ethereum Smart Contracts | https://news.ycombinator.com/item?id=15786780 https://news.ycombinator.com/item?id=15786780 HN user jatsign shared some of his inital gotchas two weeks ago.
krzkaczor 9y ago
Sorry, this is for communicating with the already deployed contract.

ChrisRus 9y ago

I wrote ARCcore.filter to solve many of the issues discussed. And, because it works at the JavaScript function level to normalize/validate function I/O it works well with _everything_ to solve the runtime data problem. And, it opens up a new world of type-based runtime metatemplate programming to JavaScript developers. https://encapsule.io/docs/ARCcore/filter https://encapsule.io/docs/ARCcore/filter

buybackoff 9y ago

We wrote a library with the same code generation purpose almost on the same day (1st commit). I just found myself typing the same TS code using truffle-contract lib over ERC20 methods. Using it in production and will release v.1. as soon as web3 is v.1. (a blog post was due on v.1 date :) ) We also have a number of strongly typed helper methods included such as ethereum-utils, keythereum and fast signing for state channels implementation (implemented in a sibling repo). The concept of TypeScript code generation is very valid, saves a lot of time during rapid prototyping and contracts become self-documenting, with IDE errors after signatures change. Generated contracts are isomorphic and work well from Node.js and a browser while being simply packed with NPM. https://github.com/dbrainio/Soltsice https://github.com/dbrainio/Soltsice

krzkaczor 9y ago
Hey, TypeChain author here. Yeah that's funny :D I was looking for a tool like that, haven't found anything so I wrote my own. Now it seems like there is a couple of tools doing similar things (also 0x is working on something similar). Good luck with your project — your approach is a little bit different since you wrap around truffle contract where we decided to come up with our own api. I am excited to see how it develops further!
- buybackoff 9y ago
  Hi! Thanks! I will replace truffle-contract with web3 1.0 contracts API. Current web3 1.0-beta doesn't work well with TS. The dependency was accidental since I was already using it, while writing codegen stuff took very little time and was just a helper script in a contracts repo initially. Our public API is plain async TS, truffle-contract is only an implementation detail. Need for such solution seems so obvious given that we have Go ABI gen tool for a similar purpose and JS is the main language for DApps (and probably Node.js for backend is more popular than Go). Also, truffle migration looked like a fragile black box, and testing with `jest --watch` instead of truffle suite is much nicer and faster.

azr79 9y ago

TypeScript is the present and the future of web, not web assembly