TypeChain: TypeScript Bindings for Ethereum Smart Contracts | Hacker News Reader

TypeChain: TypeScript Bindings for Ethereum Smart Contracts

blog.neufund.org

95 pointsbobbrown10 comments

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

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!

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.

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

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.

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

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.

Understanding Ethereum Smart Contracts | https://news.ycombinator.com/item?id=15786780

HN user jatsign shared some of his inital gotchas two weeks ago.

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

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

Reply on news.ycombinator.com