Is there anybody using Yoeman. Any better alternatives??
Ember App Kit: GitHub - stefanpenner/ember-app-kit: deprecated: see https://github.com/stefanpenner/ember-cli
Once you wrap your head around ES6 Modules and how they are resolved, EAK is pretty awesome. Very much in a state of flux though, so be ready to get your hands dirty.
So how did you wrap your head around ES6 Modules?? Was there detailed documentation other then this
http://iamstef.net/ember-app-kit/guides/using-modules.html
Because what I am looking to do is start a new project but it will use Node.JS and Ember.JS
If you’re already familiar with AMD or CommonJS, ES6 modules aren’t that difficult to grasp. The major difference is this new concept of having default exports and named exports from a module. The README from both the es6-module-transpiler and es6-module-loader have been extremely helpful to me.
There is currently an interoperability issue between transpiled ES6 modules and AMD/CJS that’s being worked on, so that’s something to keep in mind.
Ember App Kit is decent, but when I last checked a few weeks back, it forces you to have all files concatenated into one even for development, and you have to self-manage vendor libs (at least until the interop issue I mentioned earlier is addressed and you can use AMD-wrapped vendor libs and such).
If you prefer to have more versatility, and also a lot less configuration to deal with, Mimosa is a great tool, whether you want to build your Ember app with ES6 modules, AMD via RequireJS, or CommonJS via Browserify. It’s going through some important refactoring at the moment for its next major release, which would make it super lightweight, but I’ve used it even in its current state for both Ember and non-Ember projects and it’s been pretty fantastic.
If it helps, you can check out this repo I had put together for playing around with Ember stuff. The ES6 module transpiler used there is stuck at a slightly older version so only default exports are supported right now, but otherwise, once transpiled to AMD, it works nicely with other AMD modules. There’s also a 100% AMD version here before I started experimenting with ES6.
But the gist of it is, I really like the way that Mimosa smartly recompiles/rebuilds only the necessary stuff as you go, so it’s super fast, and there’s not much in terms of configuration needed to get you started if you’re happy with the defaults. And you get to keep your files separate during development.
I think I am going to use Mimosa from your recommendation. It seems easier to implement
@stargatesg1 grain of salt, but my team is also building a fairly large Node/Ember app. We first tried yoeman, then ember-tools. Both were painful mostly due to the app being compiled into a single asset - debugging was difficult. With ember-tools, using their require implementation also limited access to objects in the devtools console, which I found to be painful as we’re also going thru a learning curve with Ember.
We’re keeping all files in a Rails-like structure for now as a compromise between really long files or lots of them, and we’re at least able to debug and make steady progress. The tools aren’t getting in the way as before. The next tool to research is Brunch but we’re still looking.
Interested to hear your thoughts.
I used brunch.io It was very easy. Now there is all these other tools. In today’s web development its like we are a kid in a Candy store LOL. So much alternatives to choose from. At the end of the day we can use any of these technologies but has your product made any money?? These tools should make the developers life easier not a nightmare. It seems like everybody is competing to be the best. But really we should be collaborating more.
If you look at the GitHub for brunch ember https://github.com/gcollazo/brunch-with-ember-reloaded
It hasn’t been updated in a while
Same with Mimosa.io look at the last update
August 26 https://github.com/emirotin/mimosa-ember
Yoeman Ember https://github.com/yeoman/generator-ember
Then there is Ember App kit highly active. https://github.com/stefanpenner/ember-app-kit But what scares me is refractoring or wrapping my head around ES6 Modules Which we need more real world examples on this.
It looks like RequireJS and Grunt are out GulpJS and browserify are a better alternative. Read the article here
http://www.100percentjs.com/just-like-grunt-gulp-browserify-now/
The repo that @edeblois mentioned is a good place to start with Mimosa and Ember. It’s much more recent.
Gulp is the hotness because of streams. Mimosa has sort of been doing a variation of that stream thing for a year and a half now. Just without using the word “pipe” everywhere in the config. =)
If you have questions about Mimosa, let me know. I hope to be adding a good deal of Ember sugar once 2.0 is released.
@stargatesg1 At the end of the day, the repos you’re mentioning (brunch-with-ember-reloaded, mimosa-ember, generator-ember) are just generators or community-contributed skeletons/example apps. You’d have a better idea of how well maintained and active a tool is by looking at its commit and release history, not example apps built on top of them (though they’re nice as a reference for how you might want to setup a similar app). It’s what the tool enables you to do that really matters.
I would never base my decision to use something just on how new and trendy it currently is. Grunt was wildly popular, but I think people have come to a point, especially when developing something of a larger scale, where they started recognizing some of its drawbacks:
- The configuration file starts getting even more bloated and complex than it was to begin with, and often times, you have to start splitting them up into individual task files just to make maintaining them a bit more sane.
- Performance due to the write-to-disk vs. stream approach
- Performance due to the nature of grunt being a simplistic task runner in that when a file changes, you can only tell it to re-run a task, so a single JS file change can result in re-firing the entire “recompile all JS files” task, unless you set up more complex and tedious watchers. And even then, say you’re modifying a LESS partial, technically you’d have to recompile the file that includes that partial too, not just whatever changed. That’s not feasible with tools like Grunt.
Gulp may be the new kid on the block and is getting a lot of attention because of how it solves #2, but I fail so far to see how it would help address #1 (as a developer, you still have to wire up everything yourself with the code-over-configuration approach, spending time working on tooling rather than using the tool to ease your app development), and I fail to see how it helps with #3 as well with its grunt-like watcher setup (https://github.com/gulpjs/gulp#sample-gulpfile).
edeblois I agree with you also thanks for clarifying on using something on how new and trendy it is. Today its gulpjs tomorrow its sipjs 
Tagging it as “trendy” is not a solid argument. Do you have to wait a year before using anything because it’s just “trendy”?
As for your grunt problems:
- It’s not that complex
- Fixed in core like you said
- gulp-watch which will possibly be brought into core in the next release
Only people who are braindead think that “pipe” and “stream” is some kind of a buzzword.
BTW @dbashford every single post you’ve made is about mimosa so obviously you would want to jump in to plug it here. I’d just like to state for the record that gulp is nothing like mimosa so nobody gets confused.
In fact, with NodeJS streams you write once, run everywhere, run fast, as fast as possible. It allows to send data on the fly as it computes, it’s just how it work on Unix system since many years and i think noone currently doubt that it is one of its major features.
As an example, i wrote svgicons2svgfont and it’s underlying libraries with streams and i could easily port it:
- to Grunt
- to Gulp: https://github.com/nfroidure/gulp-svgiconstosvgfont
- and to the browser: SVG Icon Font: Build SVG fonts right in your browser!
Doing a CLI tool would also be a peace of cake. And always by embracing the system in witch it runs to compute as fast as possible. Streams FTW!
Just a note on this kind of mentality. If you try to keep up with everything in the front-end development world, you will end up in psychiatric care.
As far as ES6 is concerned though, they really are just vanilla “imports” like every programming language ever has always had. The only thing that you have to be wary of is the ember resolver. Besides the guide you mention from Stefan, the autoresolution of imports can be fairly opaque. That said, it’s surprisingly POLA.
Need a new serializer? Hmmm, how do I do that… Maybe app/serializers/application.js. Hey, look at that. It worked. I’m not 100% sold, but I do like where things are heading. Spend some time reading through EAK’s issues and you’ll find a lot of really great info.
I did a presentation in November on the different build tools available.
You can see the video here: Ember Meetup SLC Nov - YouTube
Slides are here: https://speakerdeck.com/cavneb/ember-build-tools-showdown
The general gist of the presentation is that Yeoman has some hurdles to overcome and Ember App Kit is your best starting point for new apps.