My thoughts on EAK as I consider using it for ember-tools about ember-app-kit

[thomasboyt]

Hey, thanks for the comments! :)

Can't be part of a bigger rails or express app (like discourse), might not be a goal of the project and that's fine.

Depends on what you mean by "part." Really, the only thing you can't easily do is use server-side templating. Nothing stopping you from serving the output through your back-end, given proper configuration.

Move app.js, routes.js into config/app.js, etc. Its also a great place for store.js, i18n, etc.

This only makes sense to me from a Rails background. The reason why routes in Rails are "config" is because there's a whole special DSL for them and they're clearly separated from your codebase, whereas in Ember, Routes are much more tightly-integrated. Doesn't make sense to separate them. I feel the same way about the rest, too. Config to me means ".ini" or ".json", not ".js"

Don't inline script tags from vendor, require them like anything else.

We'd need AMD versions of jQuery, Ember, and Handlebars, then.

Use almond to load the modules so we can load everybody's stuff (anybody who supports amd anyway)

I think this is a good idea. loader.js makes sense for isolated modules & libraries, but not so much for applications. Still, I'm not sure if most libraries people use with Ember come in AMD variants.

Make the module resolver a dependency, put on bower

@stefanpenner wants to do this soon.

Precompile only the templates that changed, make them modules

This would be great, but depends on how granular we can get with Grunt.

Don't want to ship with coffeescript, then we have to support it, which is a huge pain when it comes to generators

Valid point. Since we're just doing foo.coffee -> foo.js compilation, though, there's no reason your generators can't just support JS but still have a Coffeescript task just in case. You're not beholden to supporting CS just because the task exists.

Need source maps for concat build, having a giant app.js is no good

Agreed. Waiting to see if grunt-concat-sourcemap will get merged into grunt-contrib-concat. Also want to get source maps in ES6 module transpiler.

Need a production build

Of what? You can build a production version of the app with grunt build:dist.

Get all of ember in es6, so it depends on handlebars rsvp, backburner, etc. straight from bower

This would be cool, but is a very long-term goal.

[stefanpenner]

absolutely agree. We have much work todo!

Maybe we break some of these points up into multiple issues?

[ryanflorence]

@thomasboyt app.js configures your app. Routes.js configures your routes.
Store.js configures your store. I18n.js configures translations. I wouldn't
be upset about littering the app root with config files, but that is what
they are. Has nothing to do with rails :)

On Saturday, July 20, 2013, Stefan Penner wrote:

absolutely agree. We have much work todo!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-21298422
.

[joefiorini]

Can't be part of a bigger rails or express app (like discourse), might not be a goal of the project and that's fine.

I have a project should make this really easy. The project is half-pipe, and it completely replaces the asset pipeline & gem dependencies with grunt & bower. The only problem would be getting EAK as an NPM module that we could easily install, which I've proposed in #24. @rpflorence Would you find either useful?

[stefanpenner]

@rpflorence we have made some progress on your list. Still a good amount of work + simplification to go though.

[stefanpenner]

@rpflorence thanks for your thoughts, they have helped shape EAK and will continue to.