If you’re starting or are early in a new project GitHub - ember-cli/ember-cli: The Ember.js command line utility., which is exactly what you’re describing.
2 Likes
Even before Ember CLI, using something like Grunt to do automated builds is not a huge barrier to entry. It takes literally minutes (one time) to get started. This process isn’t particular to Ember, either.
Imagine you’re doing some arts and crafts. You’ve got the paper plates, pipe cleaners, colored construction paper- but you refuse to do any project that requires scissors or glue. There’s still a lot of projects you can do without scissors or glue, but those projects aren’t necessarily better or easier to wrap your head around, and scissors and glue aren’t that complicated.
If someone is choosing their development frameworks based on whether or not they will be expected you to use some standard and simple tools, I would be very skeptical of the products they’re making.
That’s fair point. As I said though, it’s better to have a standard way to do these things, documented and recommended along with everything else in guides. There’s also a difference between Ember and others - others don’t claim to be a framework for building ambitious web apps.
As a developer who’s currently looking around for an alternative to Angular, I found Ember to be the perfect choice… then I got curious about how it handles the separation of templates. After reading this thread, I can conclude that Ember isn’t right for me. I find that having to use third party tools to compile templates is just piss poor - it’s a feature that really should have been added to the core framework, if even in the most minimal sense.
I find I should be able to use something similar to Angular’s “templateUrl” attribute for referencing external templates.
You’re referencing a /very/ old thread. You should begin your research on www.ember-cli.com
Saw this as well, even looked at a few vids on YouTube (guess I should have mentioned that) Still too much work for such a basic functionality that should have been included in the first place.
Either use in line templates or resort to an entire build system? Too much…
If you’re building anything beyond a really tiny app or island of functionality then you will need an entire build system. Even static websites these days will use a build system to automate the css/js pre-processing, concatenation, un-used rule stripping, minification, image compression etc.
Pre-compiling templates brings a lot of performance, modularity and maintenance benefits. With ember-cli that is handled for you alongside the building of your Ember.js application.
If you are building something small enough that you can easily manage and maintain it with one template and one JS file then perhaps there are more suitable alternatives available.
I guess I can see your point, but after utilizing Angular’s $templateCache with its ability to fetch templates via Ajax and store them for later use WITHOUT the need for a build system, I find Ember’s approach to be a bit of a heavy requirement. I just want to say { template: “/assets/template/home.html” } for my controllers and have it simply work. No Grunt, NodeJS and other plugins required.
Even in AngularJS at first glance it seems best practice is to use an external build tool (grunt/gulp) to minify, combine and pre-fill the $templateCache.
Ember.js has chosen an efficient method for both developers and their end users.
I guess I’m failing to see how creating an app/templates/home.hbs file and having it automatically built for you and available where needed in Ember is any different to specifying { template: "/assets/template/home.html" } in Angular. The tooling is there to make it a non-issue.
If it’s the fact that all of the (pre-compiled, so much faster for the browser to parse) templates are sent along with the initial JS load that is bothering you then there is an open issue to allow for lazy loading of templates: https://github.com/ember-cli/ember-cli/issues/402.
I quite like the tooling, and I absolutely love how my app is (almost instantly) automatically reloaded after I’ve saved my changes and ember-cli quickly rebuilt the application. I think it’s a real benefit rather than a problem that there’s such a good toolchain in place.
I had the same need prior to ember-cli, have an option to specify a handlbars file for each template to help with separation. But, ember-cli has satisfied that need. I think ember-cli also enforces a better end-product, with the compiled templates and such. However, I think there is still a need to load things as needed for larger apps. Loading everything initially could cause too much overhead. Sounds like this is being worked on though, so even greener pastures are ahead.
What the real issue is, for me, is the need to learn a build tool in order to use Ember effectively. It adds a certain measure of complexity to my workflow. Then again, my aversion to learning build tools may come from the fact that I mostly develop on the server side where all of my templates and partials are fetched and compiled for me without me having to learn anything extra or manually set up or invoke any other tools - just hit refresh. I was looking for something similar in nature on the client side, but it seems Ember is not it.
I may give Ember a look after my next project. Grunt seems interesting…
Grunt is passé, Ember CLI is the new hotness.
You still had to set up the server though. In ember-cli’s case this is as simple as running ember serve, now you have a local server running where all of your templates and partials are fetched and compiled for you. You don’t even need to hit refresh, it includes live reload so the browser refreshes automatically for you whenever you make files changes.
If you are looking into Grunt for use with Ember.js then I urge you to consider ember-cli instead, it’s a much happier path with a lot less learning and setup needed which is why it has replaced the myriad of yeoman/grunt/gulp/sprockets based build environments that were used previously. For other environments where you want to introduce automated builds Grunt can be a real boon, if you look into it be sure to check out http://yeoman.io which offers Grunt scaffolds for common webapp setups.
1 Like
There’s not much to learn - you can get started with CLI in a couple of minutes. It has some awesome power-user features, but you can learn them all ad-hoc. I also second the perspective that it’s not reasonable to build a modern web app without build tools. It would be like not using version control.
1 Like
A year ago when I started learning Ember, I wasn’t familiar with node, npm, or even bower. It was very overwhelming to feel that I needed to learn all these other things just to use Ember in a proper, best-case way. Now days ember-cli has helped but it still is something else to wrap your head around.