Why does Ember.js require a server? - ember.js

I've downloaded Ember.js ver 1.13.13 for a test drive.
With other js frameworks, I am able to run from a file system. Does Ember require a server? I could not run directly from a file system. I did find some old tutorials that allows this. Is this a new thing?

You are using Ember-CLI which requires running ember serve in order to view your ember app. Ember-CLI uses conventions so that it knows where to locate the files that compose your ember app. As Ember-CLI locates your files, it knows how to combine them in a manner that ultimately results in the single JavaScript file that is executed in your browser. In theory you could use the globals style of development-which is the style reflected in the 'old tutorials' that you reference-and run the app directly without using any sort of "server." But, I don't recommend that. Learning Ember-CLI is useful as it is the preferred method of development moving forward. And, in my opinion, gives you a number of features that allow you to more quickly prototype apps. You can read more about that in the link I provided to the Ember-CLI website.

Related

Ember-cli: How do I watch+reload a file in bower_components?

I'm developing an Ember.js app (using ember-cli) alongside a regular ol' front-end Javascript library, which is included in the Ember project on my local machine via bower link + an import in ember-cli-build.js. Trouble is, I have to restart the local Ember server each time I make a change to the library, which severely slows down development.
The big question: Is there some way to tell ember-cli to watch and reload a bower_components import without restarting the server?
For the record, the JS library is not the sort of thing that would make sense as an Ember addon, and creating a thin-wrapper addon just for the sake of reloading (if that's even possible) seems like overkill.

What are the respective purposes of the emberjs.com and ember-cli websites?

I am a bit confused regarding the ember websites "emberjs.com" and "ember-cli.com". Isn't ember-cli now a part of emberjs and documented at "emberjs.com"? If so, why have a different website for ember-cli? Also, why do the sites differ regarding the versions of the prerequisite JS frameworks? For example, the emberjs.com getting starting page says to use Node.js 0.12 or higher while the ember-cli.com site says to use the latest stable version of Node (version 4.0.x).
the emberjs.com getting starting page says to use Node.js 0.12 or
higher while the ember-cli.com site says to use the latest stable
version of Node (version 4.0.x).
Seems like emberjs.com is out of sync, you can create issue on emberjs.com website repository on GitHub or hope that it's already created and it will be resolved shortly. Also, there was as issue with bufferutil in Ember CLI + node.js 4.0, so they might wait until it's resolved, but for some reason it's recommended on ember-cli.com.
Isn't ember-cli now a part of emberjs and documented at "emberjs.com"?
It isn't part of Ember.js. It's part of Ember.js ecosystem. It's recommended tool to work with library and that's why examples in guides assume that you're using Ember CLI. But, you could also use Ember.js without Ember CLI by loading jQuery, Ember.js, Ember.js template compiler and working on globals.
Ember.js documents everything about library itself, how logic behind library works, core concepts. You have components, routing, controllers, models explained there, but you won't find information there how to add CoffeeScript to your project.
Ember CLI website documents everything about Ember CLI, which is tool that provides:
asset pipeline
a strong conventional project structure
powerful addon system for extension.
You can see in user-guide that it documents possible build configurations, how to make SASS or CoffeeScript working in your environment etc.

EmberJS (without ember-cli) development behind firewall using systemjs or any other loader

I am planning to use EmberJS for a small application in my day job. I have used a little ember on my laptop using ember-cli. However at work I don't have access to Github.
I am planning to download the libraries and start using without any tools like npm, bower. I have tried to setup a static web app at https://github.com/mmrath/ember-standalone
There is not much code in there. I have tried to keep the structure as close to ember-cli as possible, os that it will be easier for me to upgrade to ember-cli when access is available. I would like to use ES6 modules like in ember-cli. However the fist step of loading the Ember is not working.
Error I see in chrome console is
Error: http://localhost:4200/vendor/ember/ember.debug.js detected as System.register but didn't execute.

Cons/pros and feasibility of running Yeoman and Rails with an Ember project?

I am working on an Ember-Rails app. I have used Yeoman previously for building non-ember-rails apps and js plugins and I would love to be able to realize the benefits of Yeoman (especially Grunt's livereload) when working on my Ember-Rails projects. However, I am unsure as to whether Ember, Rails, and Yeoman are fully compatible and whether they overlap in their roles and responsibilities. For example:
Dependency Management
- I understand Bower is used for dependency management. Does Bower affect how assets are loaded through the rails asset pipeline? What are the advantages/disadvantages of loading dependencies through Bower instead of using Rails gems?
Livereload
- Does livereload function with a single-page app (like one built in Ember) in the same way it does with a multi-page app (for example, an html site that doesn't use a js framework)? Are individual models/views/controllers reloaded or does the whole app reload and/or recompile through the Rails asset pipeline?
Existing Project
- Are there pitfalls when integrating Yeoman into an existing Ember-Rails app? We're running Ember 1.3.0-beta and Ember Data 1.0.0-beta on our production. If you have experience with up-to-date Ember builds, are Ember-auth and Ember-data compatible with Yeoman?
If anyone has experience combining Ember, Rails, and Yeoman, or if you understand how the frontend and backend would compare with such a stack please share your thoughts! Would you recommend just integrating part of the Yeoman setup (e.g. Grunt) with an Ember-Rails app instead of the whole of Yeoman?
Thanks.
I'm not Rails&Ember guy, but here are my general thoughts about feasibility of using Yeoman:
Not using Yeoman: Feasibility
From my experience in combining Yeoman & Django, I must say that it starts to pay off only in medium-sized or bigger projects.
In smaller ones, particularly with tight deadlines and not much attention paid to the code quality & tech. solutions used (like Univ. projects), you'll be probably better off sticking with bare Rails (downloading JS libraries manually and committing them accordingly to the Rails project structure).
The reason is simple: It might be really time-consuming to fine tune both full-stack framework (Rails) with frontend-framework (Yeoman).
Particularly if Rails is driven by CoC principle.
It might seem to work after some setup, but as the project evolves, you will spot further obstacles and you'll have to tamper waaaaaaay more.
Cons & things I consider not worth this time investment:
Livereload
I like it very much, I was amazed with it at first, but after some time I see that I don't spend that much time editing HTML&CSS in IDE and watching static page on another screen automatically refresh. In majority of cases I still need to do Alt + tab and trigger some action, perform some click, so whether I add one Ctrl+R hit in-between doesn't do any difference.
In some cases you'll be better off playing around with Local Folders Mappings (Chrome Dev Tools) or web proxy (e.g.: Fiddler).
There are cases where Livereload does a brilliant job though, such as for instance not needing to perform full reload if you edited only CSS.
As for your questions:
For me if it detects changes in JS it reloads whole page. But maybe it's because I'm using JetBrains IDEs (filesystem cache'ing) and CoffeScript (compilation to JS).
Yeoman is best suited for SPAs. Would it be acceptable for you to make it a SPA, not a round trip app ?
Bower - Attempt to provide dependency management for github projects
What bower does for your app is basically downloading stuff from github. No rocket science here.
If the structure of downloaded thing is non-standard, Bower/RequireJS/Grunt-bower-install has no bloody idea what to do with it next, i.e. how to inject everything so that you won't get errors. For most popular libraries bower just works, for highly customized ones you will end up injecting downloaded stuff manually.
The ones to blame are people who don't package useful github projects properly.
Furthermore I heard of workflows where people commit bower_components due to problems with bower, never experienced personally though, perhaps the issues were fixed. If so possibility of not committing 3rd libraries to source code is definitely an advantage.
Note: As I pointed out above, it's how bower helps you developing your app, but bower has become somewhat a standard in the frontend community, for instance http://ngmodules.org/ is build on top of that, so it's a important tool.
Can Rails assembly pipeline fetch arbitrary github project ? Yes.
Can it inject library references to your html ? Duno, I'm not Rails guy.
Generators
Some could do a beautiful job, such as configuring whole heroku-related stuff for you. Too bad generator-heroku doesn't work as expected (tried it sth like 2 months ago). Same was true for travis generator. In this case fix was easy, but see the next point.
As for Angular generators (I'm Angular guy, not Ember guy, sorry :-) ) - it just adds 2 files and includes them in index.html, furthermore if you are using not so straight-forward syntax for creating JS framework related stuff (sample: Angular-related stuff in coffee) generator will most probably not know about it. Ok, you can submit a patch to generator, but then AngularJS team decides to change the syntax a little bit in the next release - you get the idea ? - again, see the next point.
What is more, if your project uses layout in which code is structured by feature/module (e.g. admin module, profile settings module, ...), not by type (directives, controllers, ...) framework-specific generators won't work.
Stability
Karma is evolving rapidly, so does Angular, Angular-UI and loads of fronted tools, frameworks.
It's really difficult for Yeoman to keep up with most recent changes, although they do a nice job here.
Employing Yeoman: Being cutting-edge
Yeoman provides some really cool stuff such as:
Linting
Compiling coffeescript, SASS/SCSS, etc. on the fly
CDNifying
Really useful when you want to have libraries downloaded locally in case of developing offline and still benefit from pros of CDN.
Without Grunt you would have ended up writing scripts parsing your HTMLs
Automated JS/CSS minification
Grunt does it for you. You only have to configure it properly.
Encouraging separation and low coupling of your frontend and backend
As for your question: I doubt that you'll be able to manage Rails part solely with Yeoman.
A good recipe for a web app in Yeoman & sth is: https://stackoverflow.com/a/19425461/1432478.
That's for Django, adapt it accordingly to Rails.
My opinion
In majority of small projects based purely on Spring MVC, Rails, Django, etc. you simply don't perform any of things done by Grunt (hence there's less time expenditure for setup).
There are cases when producing technologically advanced frontend is a must.
e.g.: Most recently I discovered that my bank account management system doesn't minify JSes. Even funny comments are left as they were. I didn't perform any rushed money withdrawal, but I hope they at least have server-side validation. :-)
Yeoman is a really good combination of solutions facilitating all those chores.
Using only Grunt? IMHO No. Yeoman is Grunt when it comes to app assembly. You get Livereload and other stuff for free.
If:
you're lucky and found sample config that seems to work for the web framework of your choice or managed to configure one on your own
don't have deadlines to hold
then you should probably give it a try.
If you will work on multiple projects, chore of configuring it once might pay off by copy-pasting config to future projects.
But keep in mind that frontend technologies are rapidly evolving, that's why tons of samples from the net simply don't work out of the box.
Further reading :)
http://blog.tfnico.com/2013/07/considerations-for-javascript-in-modern.html
Java world here, but I hope some concepts will be useful:
http://addyosmani.com/blog/making-maven-grunt/
Javascript web app and Java server, build all in Maven or use Grunt for web app?

Define handlebars scripts in a separate directory

I would like to avoid to manage a big index.html file containing all my handlebars template.
I read multiple blogs with different solutions but I'm not sure of the best one.
Is there someone from the official ember.js team able to provide the best practice for this ?
Is grunt the best solution ?
Currently I do not use any special backend like node.js. Only a basic http apache server. The REST API is provided by a Tomcat server
IMO if you are not a rails developer then one of the best option would be indeed grunt or much better yeoman (http://yeoman.io/). Using the generator-ember (https://github.com/yeoman/generator-ember) and yeoman togheter will get you up and running in no time. For example after installing yeoman and the generator-ember you can create a full project structure with a simple yo ember, this will create all the necessary folder for views/controller/routes/templates where you can start coding right away. You should give it a try.
Edit
As stated in the comment of #Toran Billups, the ember core team is working on this project (https://github.com/stefanpenner/ember-app-kit) which will be grunt based and it will work using modules and much more awesome stuff.
Hope it helps.