Should we expand this into a full-fledged framework?

[uzyn]

There are currently these popular Ethereum DAapp frameworks: Truffle, Dapple, Embark.

I'm wondering if there is room for another one, an expansion of this repo, that keeps the following visions:

1. Friendly to JavaScript developers, esp. frontend devs.
2. Minimal reinvention of wheel, use what's already out there and familiar for today's frontend devs.
3. Instead of trying to be minimal just like this example repo, include familiar and popular tools today to allow frontend devs to get started on dapps development without much relearning.

Some tools and features that could be included:

• ES6 & Babel
• Bootstrap
• Webpack (obviously)
• Test suite, for both smart contract and frontend dapps.
• React
• maybe Redux

Any opinions and suggestions?

cc: @graup

(UPDATE: strikeout some of the opinionated features. See discussions below, we have decided for the framework to be as un-opinionated as necessary)

[graup]

I've been thinking about this for a while. I have been using the Webpack approach for 2 months now in a project, so I have a good idea of what features I find useful and what features are not really necessary.

As you said, the main advantage of this Webpack approach is that it is friendly to developers who already have some experience with frontend development. They can reuse the tools and frameworks they are already familiar with. The Webpack ecosystem is also really good. For example, half way through my project I was able to add webpack-dev-server with minimal effort. Being able to do this is a key advantage over the other existing frameworks!

For me, the main (new) problems in Ethereum dApp development are these steps:

• Build
• Test (and debug)
• Deploy

If we make a framework, it should solve these well.

The current approach is already pretty good for building. I really like using .sol files as explicit dependencies in Javascript. Libraries and dependent contracts are now also resolved.

Testing could be much improved. In our project we wrote more than 1000 lines of test code, and better utilities would be really useful. Examples:

• API to re-deploy a contract before a test
• API to set/reset blockchain state/snapshots (I think it's possible with testrpc)
• Contract debugging features (Where did the contract throw? How much gas was used? Development on these are also done in other projects like Remix or Browser Solidity)
• Helpers for async tests (events). Would be much easier when we get promise support in Web3

I actually haven't looked much into dapple yet, but their testing approach is also interesting. I'd like to think more about the pros and cons here.

For the final step, deployment, it is already possible, but I would like to see some better documented, more obvious process for it. How exactly do I deploy to the real network? When my dApp is live, what do I need to deploy a new version? Maybe there could be a CLI tool for this. It could also handle deployment with Swarm in the future. Or push the build to github pages.

However, we should be careful in not adding to much "wrapper APIs". I would love if developers using our tools can immediately benefit from new features in web3, testrpc etc. without us needing to update anything. Truffle, for example, uses Pudding which is a nice abstraction that hopefully becomes unnecessary in the future. I am not sure if it is a good idea to be doing this.

I don't think we should make the decision for a frontend framework (React, Angular, Meteor, ...). We could actually have examples for each, but in the end it should be possible to use all the nice development features with any framework you like. Same goes for styling – we can have a bootstrap example but it shouldn't be a main part. "Making frontend apps" is a problem that is a) already solved in many ways and b) will also be solved in new ways in the future, so we shouldn't pick one solution or even add another one.

I would like to see if it would be possible to continue the route of developing useful features as extra modules (maybe also CLI tools), and then providing several example projects that just plug everything together. Cookiecutter just came to my mind for providing example projects / dApp starting points.

Maybe we can collect advantages/disadvantages or differences for the existing solutions, to be able to offer a unique and hopefully better new solution :)

[JacobEberhardt]

Personally I would really like to see that, as - after testing all of the tools mentioned - I found the webpack approach the most fitting. It integrates well with the development and build workflow and being able to directly require .sol files is a great abstraction.

More support for testing would be great. A first step could be to extend the configuration options of the web3-loader. (Re-)Deployment patterns and dedicated test providers could be conveniently added this way. If possible, the framework should not be opinionated on how tests are specified and support most of the existing approaches (e.g., Mocha/Chai (Truffle), Solidity (dapple)).

However, I would hope that the framework does not make any decision regarding frontend libraries/frameworks. The benefit of using webpack in the first place is that those can easily be integrated. Thus, being opinionated here, would introduce overhead without providing much value.

[uzyn]

Thanks for sharing your thoughts @graup @JacobEberhardt

Points are clearly taken that we should not be making a decisions on unnecessary frameworks, esp. front-end ones. I initially had the same intention, which is why the sample is done in vanilla JS without any CSS preprocessors.

I've always wondered what does a 'framework' offer that this example does not provide as this example is not opinionated beyond the loaders (obviously), but without one, this webpack-based approach, though arguably is more streamlined to today's frontend devs, might be overlooked by new devs looking to dabble in dapp buildings.

So is this 'framework' a CLI that helps with certain common dapp development, testing and deployment process?

[graup]

Yes, I think that's a good idea.

How should be move forward?

We could start collecting information on what the other frameworks do (with pros and cons) and define our own feature list.

[uzyn]

Is CLI the way to go? Many Ethereum frameworks or collection of tools seem to take this approach.

We can also refer to https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html Which is somewhat a similar problem as ours – too many steps to start an Ethereum dapp dev with webpack, so they created some sort of a quick CLI-based helper.

Ours could include some additional helpers beyond just project initializing such as helping with deployment, etc.

[graup]

I also saw that blog post. It's a very similar problem indeed. They have one create-react-app command to setup the project, and some helper tools in react-scripts, but without any real lock-in 👍🏼

We could even have multiple setup scripts, like create-dapp, create-dapp --type react, ...

What I really like about the whole react/redux environment is that it's very transparent. There is no magic, with a little bit of time you can easily follow everything that's happening. I think this is something we could improve over the existing frameworks. (As long as the documentation is clear enough to also enable beginners to use it.)

[uzyn]

I'm starting to run into some of the usability issues esp. deployment like you have mentioned.

I'm working on a dapp that involves both UI and a service (server) component. Both should share the same deployed contract. Starting to struggle with using webpack for non-frontend's case, esp. with multiple entries.

A few useful commands on top of the initialization ones would be:

• start: Start a hot server + watch process that compiles and deploys contract and does other webpack stuff. Ideally intelligent enough to handle multiple entry points including frontend and nodejs.
• build: Similar to start, without the watch process and results in build/ that clearly separates the files for frontend (ui) and backend – which ideally are just web3 and the contract instances.
• deploy: Deploy to an Ethereum chain before doing build and generates a state file that tracks contract changes. If contract does not change, no further contract deployments are required when only JS files are changed.

Just a rough dump on some issues I am encountering. Let's clean it up and we might be able to start our work on this.

[graup]

The first two should be pretty easy to do with just Webpack (multiple entry points and chunk splitting), although I'm not sure how you can target two architectures (browser and node) in the same config. Should be possible somehow.

Deploy to an Ethereum chain before doing build and generates a state file that tracks contract changes.

I had the same idea. The state file would track the contract's address, right? It should be possible to re-build without re-deploying, also for testing. Maybe build and test can deploy the contracts automatically if there is no previous deploy, but only re-deploy when passed a --deploy flag.

A pro feature would be if we could somehow find out which contracts we need to deploy. I wrote a "base class" contract that another extends, so the base does not need to be deployed. Could be possible with the dependency graph (only deploy contracts that are used somewhere else: imported in js or called in sol). A more simple solution would be to have a config to --deploy-only ContractA ContractB LibraryC. The linker could then throw an error if you forgot a contract that's used somewhere in Solidity.

[uzyn]

Adding another feature wishlist as I'm working on it:

1. Useful to have a interactive console with instantiated contracts for quick debugging.

[kristianmandrup]

Listen guys, I've developed dozens of app generators for starting project like you are trying to do.

The best option is to have a generator to create a minimal baseline app, then sub-generators to add testing, front end framework, transpiler, UI framework etc etc. These generators could all be pluggable.

The usual approach is to use inquirer to ask questions on the CLI, then use a templating engine to generate files.

I recently started building an Electron desktop app which can do the same but much more elegant and easy to use.

For testing i would recommend you have a look at Ava (async modern isolated test runner) and Testing double (for mocking). Webpack is a no brainer. Babel 6 or TypeScript for modern JS.

Then for the front end UI I would go with Material design (think Google style) on Vue 2 (modern front end framework of choice - with VDOM like React and huge community behind). These could be the default choices.

Sadly most front end developers are rather "sheep minded" and go for the latest fad and big names/mention, meaning: Angular and React mostly. But these frameworks have a lot of issues and suffer from huge inherent complexity and dated API design and steep learning curve. On the other hand there are loads of books, videos and tutorials to dive through... Vue 2 docs could be better and are mostly still for Vue 1 (since v.2 came out ~2 months ago)

Anyways, glad to find this project. I'd be happy to help out ;)

Perhaps you can start with a slush generator they are quick to design and easy to use. Yeoman feels like overkill and is difficult to use (bad, outdated docs).

Another option I recently found which is really promising is plop

Here is my Electron App generator WIP

Here are some of my slush generators you could use as a template

[kristianmandrup]

Found you through this article

I definitely recommend using async/await for async prog. Say goodbye to ES5 :)