
TypeChain: TypeScript Bindings for Ethereum Smart Contracts - bobbrown
https://blog.neufund.org/introducing-typechain-typescript-bindings-for-ethereum-smart-contracts-839fc2becf22
======
buybackoff
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
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
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.

------
ChrisRus
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)

------
eximius
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
Solidity needs formal verification much more than syntactic sugar. There's a
chance solidity is already too sweet as it is.

~~~
eximius
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
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.

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

