Monolithic HTML file refactoring?

[jtibble]

Hi Canton,

I'm a huge fan of the project (have purchased stickers and envelopes from you before!) and would like to contribute by helping refactor the monolithic HTML file down into separate components. Is this sort of contribution welcomed and/or encouraged?

Proposal:

1. Separate global JS modules into separate files in /libs folder, or include them with Bower
2. Separate application-level code into separate modules/files in /src folder
3. Use AlmondJS (with RequireJS) to join these libs and src together into a unified JS file that is then included by the HTML when the site is deployed.

This would dramatically simplify the HTML page, separate the JS source from the static layout, and allow developers to contribute to the individual code-sections. The JS can be all built together into one monolithic JS file which I still recommend), but they start off as individual pieces. I don't know if having all the JS in one HTML file is intentional or a byproduct of the development process, but I'd like to help and contribute if I can.

Thanks,
John Tibble

[cantonbecker]

On Mar 10, 2014, at 9:21 AM, John Tibble notifications@github.com wrote:

I don't know if having all the JS in one HTML file is intentional or a byproduct of the development process

Hi John,

First thanks for the very kind offer. I’d like to consider this. I’ve never used a build system for JS but I can see the advantages, and it’s been recommended before. I suspect you have significant expertise, so it’s a generous offer on your part.

The only reason I like the JS and HTML in a single huge file is so that bitaddress.org can be compared (diff’d) against bitcoinpaperwallet.com with relative ease. This is critical for people who want to audit my code and have a greater implicit trust for bitaddress.org (and rightly so!)

It also makes it easier for me to merge improvements in bitaddress.org back into bitcoinpaperwallet.com, now that they’ve deviated so significantly from one another.

If bitaddress.org separated its HTML from its JS, I would likely follow suit.

Thoughts?

[jtibble]

It is good that you have tried to stay aligned to bitaddresss, and I understand how that adds to your credibility and audit-ability, which is valuable. How often do you merge changes from that project, and are they substantial? What exactly are your dependencies on that project? How much code do you share, as a percent?

I ask because I'm imagining a future where bitaddress provides a library with core functionality, which you include in your build-process for BPC.com. It becomes a core piece of your functionality, but you break away from it as a fork and move towards using it as a dependency only.

This would help you separate the inherited-from-bitaddress functionality from your BPW.com functionality, like the background image picker, etc, and let both you and bitaddress iterate on functionality without worrying about porting changes forwards or backwards. If they publish an update, this project can include it immediately if all tests pass, and there would be no more porting changes from them to this site. If you proposed a change to their core functionality, it could go through the normal pull-requeat channels, and after approval, be integrated automatically into your deployed site as soon as they update.

If this project was successful in splitting the JS and HTML in a clean and simple way, do you think the maintainers of the bitaddress project would begin to do the same? All of this proposal assumed that their project was already included as a dependency, but because it's not, the change might have to start with them.

[Stemby]

What do you think about opening an issue here?