I have seen this post “AMD is Not the Answer” by Tom Dale and it worries me a little bit.
Require.js did turn into the de facto standard and there are various advantages that are really important for a team working on a bigger project. I know you cam make ember work with it, but it’s not pretty.
I would like to ask what the alternatives are?
Will there be a guide on how to structure an ember.js application, as intended by the creators?
Cheers Severin
This is something I’m interested as well.
I’ve been reading the guides for a while now, but felt the need for something more than those. Since the API has been been evolving quite a bit, most of the small-app-sized examples I could find were outdated.
What would be ideal IMHO would be, bigger than concept-guides’-examples and smaller than the real world beasts like Discourse or Travis-CI. And would concentrate more on organizing the modules and the whole development process itself for those really “ambitious” web applications we are gonna build.
I think I can speak for @wycats, @tom, and myself by saying that we’re big fans of es6-module-transpiler. It can target CommonJS, AMD, or globals.
So if you are still using plain old “document.write” and want to move to something more robust (and you don’t write rails apps++) what module system should you get started with?
I’m using django for example and would love to use something like minispade but because I already have a rich django-specific JS build … I’d rather not include another asset pipeline if possible.
What can someone like myself get started with?
Toran and all, I have published “grunt-minispade v 0.1.0” today and the repo is available on github at https://github.com/stevekane/grunt-minispade. Please feel free to use this plugin and also spread word of its existence.
For help in understanding HOW to use grunt as an asset pipeline for web projects, I have also created an example application that uses grunt, grunt-minispade, threejs, and nodemon which may be found at /stevekane/grunt-and-minispade-plugin-example .
If you have any questions/concerns/would like to help maintain/improve the plugin please let me know @stv_kn or by email at kanesteven@gmail.com.
I hope this helps!
Steve
Hi there.
In my case, I prefer to separate the development of the client app using a different stack. In this way, I can plug the final app to any backend (Django, ror or whatever) .
The tools I use to organize the code are rake-pipeline and minispade.js
In fact, I have a tiny template that I use when I need to start a new project (https://github.com/rriveras/ember-starter-template). Maybe somebody find it useful.
Regards.
this is a great resource rriveras! I also have an extremely similar setup using rake-pipeline but my inspiration for writing the grunt-minispade plugin came from a desire to migrate completely away from ruby dependencies. I am running socket.io on express for our current app and I have been able to construct a gruntfile that handles the automatic re-compilation of all assets (sass, coffeescript, minispade, etc) when any observed file is changed. At the moment I am working the kinks out of getting livereload to work as well via grunt-contrib-livereload. If there is interest, I may spin up a starter project similar to yours for people to check out.
Steve
Yes. We’re working on one.
I have a Grunt Ember boilerplate project here: https://github.com/lsdafjklsd/grunt-ember-boilerplate that gives you project structure based on Ryan Florence’s Ember-tools as well as CommonJS. It’s very extensible and can plug in to existing projects by modifying where Grunt.js output’s the build files. I use it in projects that have different back end platforms, Grunt.js is very flexible.
http://github.com/component/component is faster over ruby build tools i have used such as rakepipeline. Here’s an express app boilerplate https://github.com/kelonye/app.
AMD works fine in my experience. Tom’s three main points are:
AMD has plenty of build tools if you want to use them, so this is not really an argument against it. Require.js includes the r.js optimizer to concatenate and optionally minify your js for you, and there are tons of Grunt tasks to help with this as well.
This is only an issue in development. The ability to request all your AMD modules one by one is a convenience for development to make you not have to rebuild on every file change, not a production-ready solution. Again, use the r.js optimizer to concat and minify your project for you.
This is a fine argument against AMD, but it is also a personal style thing. If you hate the syntax, then there are lots of other solutions. I think there is a lot of value in having your dependencies explicitly listed and brought into scope in a file instead of using magical “Ruby-style” requires, where you cannot be sure what objects you are bringing in to scope.
I agree with @jergason completely.
The mobile port of the Travis-CI client I did recently, I could use require.js and r.js optimizer really successfully.
I am a fan of AMD and RequireJS as well. At a ember meetup here in SoCal there was a presentation on using rake pipeline web filters and minispade. I’m not working in a rails shop so ruby and gems fit the bill fine for building an ember app. To learn about the current build tools that seem to be favored I put together a repo here : https://github.com/pixelhandler/peepcode-ordr based on the peepcode video app I added build tools.
Sometimes it seems to me that the Ember project has been influenced by Ruby and Rails conventions. I hope the developers are keeping an eye out for the rest of us! I’ve always wondered, for instance, why does ember-data (or is it the available adapters that support it – I can’t always tell them apart) want underscores in perfectly reasonable camel-cased object names? Is that a Rails thing?
In any case, I can see in github that AMD support is definitely a topic within the team, and I’m thankful for that.
On the other hand, there is definitely a disconnect between piling objects into the App object and using naming conventions to hook them up vs. the RequireJS “way” of doing things, but it seems reasonable to think that (at a high level):
Obviously inter-connections exist as well, as needed.
Are the naming conventions worth it? I’m not sure. One point of AMD (I think) is to help stop pollution of the global namespace… well the naming conventions in Ember.js seem to just push the problem into the App object. If I can nail down the dependencies really clearly, I’d like to quit using the naming conventions altogether. I don’t know if this will even work, but I’m hopeful.