Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New build system #87

Closed
3 tasks
giodamelio opened this issue Oct 6, 2015 · 21 comments · Fixed by #130
Closed
3 tasks

New build system #87

giodamelio opened this issue Oct 6, 2015 · 21 comments · Fixed by #130
Labels
exp/intermediate Prior experience is likely helpful kind/discussion Topical discussion; usually not changes to codebase

Comments

@giodamelio
Copy link

The webui is about to get an overhaul, and the build system needs to be figured out before too much work is done.

Here are some goals

The two main options are Webpack and Browserify.

Browserify:

Pros:

  • Simple, follows Unix philosophy
  • Mature and fast

Cons:

  • Integrating non-JS assets requires writing non portable shell scripts

Webpack:

Pros:

  • Fully featured. Plugins allow for awesome things like react hot-reloading
  • Loads most any type of file. All assets can be processed with one tool

Cons:

  • A bit of magic. Complicated config(well documented though)
@dignifiedquire
Copy link
Member

Another pro for webpack: Excellent hot-reloading support

@dignifiedquire
Copy link
Member

Also a point to think about: finding a common setup for different UI parts so that we don't have to rediscuss this on every project. Electron-app is currently getting a webpack setup with hot reloading and assets bundeling in ipfs/ipfs-desktop#43 which I feel would very well work for this project as well.

@giodamelio
Copy link
Author

I am thinking along the same lines. We could create a repo of IPFS related react components, that could be shared between the electron app, webui and any other future JS projects.

Another option is web components. Browser support is decent, and I believe there are polyfills. I don't know if the tooling is there yet though.

@jbenet
Copy link
Member

jbenet commented Oct 6, 2015

Take a look at the webcomponents work by @krl -- ideally many of these could be webcomponents living on ipfs itself.


Sent from Mailbox

On Tue, Oct 6, 2015 at 12:56 PM, Friedel Ziegelmayer
notifications@github.com wrote:

Also a point to think about: finding a common setup for different UI parts so that we don't have to rediscuss this on every project. Electron-app is currently getting a webpack setup with hot reloading and assets bundeling in ipfs/ipfs-desktop#43 which I feel would very well work for this project as well.

Reply to this email directly or view it on GitHub:
#87 (comment)

@giodamelio
Copy link
Author

Hmm, that's interesting(Link). I like the idea of having separate web components hosted on IPFS. The tooling needs some work though. I will have to read up on web components.

@dignifiedquire
Copy link
Member

To be honest I'm not a big fan of web components after reading up on them a bit more, also it looks like react + web components is not a really good fit facebook/react#5052

The stuff from @krl looks interesting but I can't help but wonder, what actual benefit do we get from using web components instead of just creating dist bundles that live on ipfs.

Update I might be missing something here entirely in the connection between web components and ipfs, so sorry for my ignorance if that's the case.

@giodamelio
Copy link
Author

Web components don't have anything todo with IPFS per-say, it's more the fact they are a standard instead of a library. They are supported natively.

@dignifiedquire
Copy link
Member

Not sure I would say this is real native support: http://caniuse.com/#search=web%20components

@giodamelio
Copy link
Author

Ya, support is not too good yet. I think there are some polyfills, but it doesn't seem ready yet.

@jbenet
Copy link
Member

jbenet commented Oct 8, 2015

WebComponents is a very important internet standard, and we've been talking to a lot of people about them. One exiting thing is making a big push to make WebComponents that live on IPFS and need no origin server at all, that anybody can use, like true "npm modules for frontend". These can often be small enough that we can offer to pin them for people.

WebComponents is the result of pushes towards creating true modular, reusable pieces for UIs. they have significant traction already, and we stand a chance to improve the ecosystem dramatically by coming up with good ways to {find, serve, archive} these.

Another thing i'm very excited about is being able to make an app from scratch and use WebComponents for the hard stuff, directly from the web. never touch a locla server. only browser, a known ipfs gateway (with write access), and some WebComponents in the network.

@giodamelio
Copy link
Author

I am going to try to build a simple web component (unrelated to webui), and maybe come up with something that could be used as a template for making IPFS hosted web components.

@dignifiedquire
Copy link
Member

@giodamelio going to start work on a build system that integrates webpack with ipfs as best as possible soon. Let me know if you are still interested in helping out

@dignifiedquire dignifiedquire added help wanted Seeking public contribution on this issue exp/intermediate Prior experience is likely helpful kind/discussion Topical discussion; usually not changes to codebase labels Nov 19, 2015
@giodamelio
Copy link
Author

@dignifiedquire Yes, I do want to help out. Is there going to be a new branch that I can track?

@dignifiedquire
Copy link
Member

@giodamelio there will be, I'm still researching some things but will add a reference here as soon as I have some code

@giodamelio
Copy link
Author

Thanks

On Thu, Nov 19, 2015 at 12:41 PM Friedel Ziegelmayer <
notifications@github.com> wrote:

@giodamelio https://github.com/giodamelio there will be, I'm still
researching some things but will add a reference here as soon as I have
some code


Reply to this email directly or view it on GitHub
#87 (comment).

@dignifiedquire dignifiedquire removed the help wanted Seeking public contribution on this issue label Dec 21, 2015
@dignifiedquire dignifiedquire self-assigned this Dec 21, 2015
@RichardLitt
Copy link
Member

@dignifiedquire Where are we at the moment?

@dignifiedquire
Copy link
Member

@RichardLitt somewhere in the middle ;) My pr does webpack + es2015 + base test setup, so we are only missing modularization which I want to delay until we have the code in a better state

@RichardLitt
Copy link
Member

Ok, cool. So, the next step for people wishing to close this issue are: check out other issues, and see if there is anything you can do for them?

@dignifiedquire
Copy link
Member

@RichardLitt I think I will close this issue as soon as #130 is merged and create more modular issues around all the things needed to be done.

@RichardLitt
Copy link
Member

Sounds good.

@RichardLitt
Copy link
Member

Whoop!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/intermediate Prior experience is likely helpful kind/discussion Topical discussion; usually not changes to codebase
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants