TypeChain: TypeScript Bindings for Ethereum Smart Contracts (opens in new tab)

(blog.neufund.org)

95 pointsbobbrown8y ago10 comments

10 comments

9 comments · 4 top-level

eximius8y ago· 3 in thread

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.

itsnotlupus8y ago

Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.

eximius8y 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.

1 more reply

krzkaczor8y ago

Sorry, this is for communicating with the already deployed contract.

buybackoff8y ago· 2 in thread

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

krzkaczor8y 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!

buybackoff8y 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.

ChrisRus8y 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

azr798y ago

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

j / k navigate · click thread line to collapse

10 comments

9 comments · 4 top-level

eximius8y ago· 3 in thread

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.

itsnotlupus8y ago

Solidity needs formal verification much more than syntactic sugar. There's a chance solidity is already too sweet as it is.

eximius8y 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.

1 more reply

krzkaczor8y ago

Sorry, this is for communicating with the already deployed contract.

buybackoff8y ago· 2 in thread

krzkaczor8y ago

Hey, TypeChain author here.

buybackoff8y ago

ChrisRus8y ago

azr798y ago

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

j / k navigate · click thread line to collapse