Closed yankeeinlondon closed 8 years ago
I'm not sure what you mean by this. Beyond any default ember-addon stuff that uses browserify, the only use I have of it here is to load in the actual Horizon client lib, and it's only out of necessity as I saw it as @horizon/client is published as a CommonJS module.
SystemJS is doing the same thing as Browserify but seems to be getting better press. Seemed like you were having an issue with Browserify anyway so I thought maybe loading the Horizon library with SystemJS might make sense.
Here's a few links if you're interested:
I think the React community is moving away from Webpack (due to its large amount of config) and toward this. Not that this is a reason to do it.
This is a great video on jspm, SystemJS, and Ember: http://discuss.emberjs.com/t/new-ember-workflow-using-systemjs-and-jspm/6056/3
Having watched it though I think it's worth avoiding for now but I'd love to see Stephan take this into Ember-CLI
Here's my "stupid question of the day" ... it because the Horizon client is not available in ES6 that we need browserify, right?
The more I think about it the more I'm convinced we should just point the Ember App to the client library that is hosted by the Horizon server. This is what Horizon recommends, it ensures the client and server versions are in sync, and there needs to be a CORS route anyway for the database connection. On top of all that we get rid of all the browersify ugliness.
I was actually thinking about trying to just use the horizon client lib served by the server today. I think it's the way to go.
Just meant for discussion.
It's not an area I'm terribly deep in but from the outside looking in it would appear that SystemJS/JSPM have all the momentum and people really like it. Might be good to use this instead of Browserify?