If Rails + Ember ever get into some kind of official partnership (in terms of mutual support), this will definitely give them an edge over the competition. Tbh, none of the existing js frameworks are stable enough for my liking, I am just going with the one with highest adoption rates for relative ease of troubleshooting.
Just to chime in on the ember cli and commandline tools thing: Iâm a bit confused in the context of AngularJS when it is claimed that Ember is more command line / command-liney-tools intensive. It is true that I havenât really looked for ways to do âless command line workâ with AngularJS although iâve been writing it with IntelliJ IDEA, but I see AngularJS as more âcommand line tool intensiveâ than Ember with CLI.
This is what I can remember dealing with when developing with angular js:
- Package management: use Bower for managing stuff so that I donât have to store everyting to VCS and so that updating stuff is less painful
- JavaScript: automate injection of bower components to index.html, automate injection of angular js-files in correct order to index.html, combine the js files to app.js and vendor.js (to avoid unnecessary HTTP-requests), ngAnnotate, directive templates to JS conversion, minify, run testsâŚ
- Styles: compile SASS to CSS, hook up bower components (such as Bootstrap-SASS) for use, Set up some variables so that Font Awesome path is correct; concat any bower component .css files so that a single file is generated, autoprefixer, minify. If feeling particularly brave, add uncss to the mix.
- Development: npm to install the dev tools such as Gulp etc; Deal with a separate build process that is optimized for BrowserSync that doesnât do unnecessary things so that save â refresh browser is as fast as it can be.
- Manage .gitignore etc so that the bower components donât get stored to VCS.
Iâm not trying to debate anyone here, but to provide another viewpoint from another beginner, ember CLI seems to be a big step forward from what Iâve had to deal with when doing AngularJS development. Not to say everything above âjust worksâ with ember CLI currently, but no major problems and I do like the direction it seems to be going.
2 Likes
Well, you can run ember cli in the background and use any editor (GUI or command-line) for development. It is, however, true that Ember could benefit from better integration with 3rd-party IDEs, for example Webstorm (which has support for React and Angular)
The whole âthis is how web apps are, this is the future, we need to accept and adaptâ is a tough argument for 100% of people to swallow, no matter how bright that future is. The point is, itâs a self-fulfilling prophecy: the solutions a community makes are not the only solution or the right solution, just solutions. And many of the solutions are to problems we made ourselves. We get to take all of the credit AND all of the blame, even if bad Microsoft decisions in the 90âs are pissing off open source devs today, or bad open source decisions in the 2 years ago are pissing off Microsoft devs today.
We donât need ember-cli, bower, grunt, sass, babel, or any of the other tremendous tools that improve our front-end workflow, but they help pave the new cowpaths. For those who skip all that and write vanilla JS/CSS, they miss out on the all the benefits. They also miss out on all the costs of upgrade and dependency problems, debugging those tools, and learning new workflows every 3 months to ideally make things easier.
Itâs like ember-cli is like selling the first car, which gets you places 5 times faster, but it can need a lot of maintenance and the controls often change while we sort things out. For some people who decide (or their company decides) that the maintenance and changing controls are too risky for them, they have to skip the car and take an old vanilla bike instead.
The downside of the car metaphor is when we say that âyou donât need to use a car, but weâre no longer building bike lines or sidewalks, only highways.â For all of the developers who either built a non-ember-cli app (or inherited a tech stack that doesnât allow migrating to ember-cli), it looks like theyâre completely deprecated.
If we canât use Ember-CLI (which many people canât for decent reasons), it appears that weâre left behind just like the folks in Angular 1.0. We totally understand the future is ember-cli and it makes great sense, but itâs still a wall. So despite all of the âstability without stagnationâ talk, ember-cli can create an even more insurmountable barrier than code changes. Because we can slowly rewrite our apps from views to components, controllers to services/etc, two-way bindings to data down actions up, but our company/IT/hardware situation canât always allow us to change the deployment infrastructure.
No oneâs right or wrong here, itâs just that whenever we add a barrier, we lose the people who arenât willing or permitted to cross.
TL:DR â The content of the code and the process of deploying it are two separate things, and only supporting them together in the future will understandably frustrate & lose some of us whose products or companies are too big to do a gut renovation. And ember-cli can make Ember 2.0 almost identical to Angular 2.0 in terms of migration pain.
2 Likes
I must agree with this! I sat down and built an ember app first for about 2 months, then came to realize about ember-cli and how much of a benefit that would be for us, especially since we already hat a continuous integration running where ember-cli would fit in perfectly. But it took me another month to migrate the 2 months old app into ember-cli. It was worth it, totally!!! But it was a bloody pain in the ass!
Itâs just because Iâm curious: why is the community trying to âbeatâ Angular and not React or X or Y? Why you are fighting most against Angular? Where all these resentments come from?
Iâm comming from Angular and after some pain points at the beginning I really enjoy working with Ember right now. I also like the Ember community and I think the framework is awesome. I think it makes not much sense about focusing how to beat Angular or framework X. I think a lot of energy is lost trying to âbeatâ someone. This energy could be better used in promoting awesome things like fast boot, glimmer, ember-cli etc.
Why the ember community canât just do it like Angular and say âEmber <3 Angularâ and see other frameworks like Angular or React as an inspiration and incentive?
2 Likes
I think most of us appreciate all the frameworks.
Personally, my grudge with Angular isnât Angular but the people who choose it blindly then try to force me into their decision too. There are a lot of people who assume Angular is more polished, when honestly Iâm 10x more productive in Ember before taking the benefits of ember-cli into consideration. I think they are both equally mature frameworks and both have well known flaws.
Similarly, I donât have a grudge with React, but I do with the very vocal React crowd that harps on a few design idioms that âmake React betterâ that arenât even true. React is not âa paradigm shiftâ, it does not âjust let you use native javascriptâ any more than any other JS framework, and it most definitely has a huge and invasive DSL. These arenât reasons to avoid React (all the same can be said about Ember), but there ends up being a lot of unnecessary politicking.
And now you may forget about developerâs mindset.
Version 1.11.0 insists on installing Node + ember-cli + phantomjs. It is a show stopper. Nobody will want to install that just to try Ember. Those who have existing project that does not use ember-cli, and any project more than several months old fells into this category, will not be able to upgrade to 1.11.0. So, currently Ember is only for those who just started working with it.
This is it - suicide. Congratulations and good luck.
Things would be much better if the 1.10 guides allowed to download 1.10 and 1.11, even if the URL for the template compiler should be guessed. However, currently the 1.10 guide returns 404 instead.
Version 1.11.0 insists on installing Node + ember-cli + phantomjs.
Thatâs blatantly false. Releases - Ember.js
Things would be much better if the 1.10 guides allowed to download 1.10 and 1.11, even if the URL for the template compiler should be guessed. However, currently the 1.10 guide returns 404 instead.
Neither 404s
http://builds.emberjs.com/tags/v1.11.0-beta.5/ember-template-compiler.js http://builds.emberjs.com/tags/v1.10.0/ember-template-compiler.js
And now you may forget about developerâs mindset.
Au contraire, I know a lot of devs trying or moving to ember because of ember-cli. ember-cli solves pain points that everyone in front-end dev feels regardless of framework. And ember-cli is making the addon story so ridiculously easy that I suspect ember-addons will soon be the new jQuery plugins.
Version 1.11.0 insists on installing Node + ember-cli + phantomjs.
As I said above, this is untrue. But even if it were to be true, if you are a dev who wants to build an app with any of the major frameworks (bootstrap / react / angular / ember), you will be installing node + phantomjs + a host of build tools to create your own equivalent of ember-cli. Most devs have node and phantomjs on their machine, and have had them for years.
Those who have existing project that does not use ember-cli, and any project more than several months old fells into this category, will not be able to upgrade to 1.11.0.
I ported a large project to ember-cli from a custom build system that used grunt and grunt-neuter for assembly. I already used good practices on file and folder layout, but also had multiple declarations per file (e.g. modules/app contained Route/Controller/View. It took me a half day to convert to es6 modules, and another day to get everything wired together appropriately (the pain point was learning initializers).
Since then Iâve ported several smaller apps, and now that I know much more about ember-cli that process takes me a few hours tops.
The motivation to move the large project to ember-cli was to be able to take advantage of the addon ecosystem, easier upgrades, community sourced solutions for a build pipeline (seriously, otherwise as your app grows you will rewrite your custom pipeline constantly to keep up).
This is it - suicide. Congratulations and good luck.
Suicide never felt so good.
2 Likes
Let us go to the guides and get the following link to what should be Beta release.
QUESTIONS???
I do not doubt that is true. I just wonder if there is a better example of a âpreaching to the chorusâ.
So you canât click on the giant âbuildsâ tab in the nav bar? Releases - Ember.js 
@trek thereâs a broken link in the new docs, when you click any of the build links under channels on Getting Ember - Getting Ember - Ember Guides they are missing a /.
We must be using different Internets. When I click on Guides I go here. This is the 1.11.0 version of the guides and Getting Started â installing Ember leads to this page and that page describes exactly one way to use Ember.
BTW, the page you quote says that the latest beta is 1.11.0-beta 5. Taken literally, this means that 1.11.0 has not been released yet. If so, WTH is the 1.11.0 guide doing on the Ember front page?
Please report website issues at GitHub - emberjs/website: Source for emberjs.com or issue a PR (the codebase is pretty easy).
As much as this thread has a topic, and can be polite and focused, let us keep it so. Bomb throwing and tit-for-tat is not helpful. Thanks!
2 Likes
Eh, once you have node installed it takes how much work to install cli with deps? Two or three commands? And then you get setup enviroment: you get app structure, code discovery and auto reload, configured testrunner. This for me is HUGE win for Ember.
But I admit need for cli-fu puts Ember.js in different world to PHP, where you can install WAMP or XAMPP or another GUI for dev and be happy hacking stuff without ever touching console.
Iâm teaching my younger brother to code right now. His machine has never had any tooling / profiles / command line tools installed.
In 30min we had nvm + io.js + ember-cli + node-webkit + ember-paper and a small demo interface for a music management lib. There really is a huge productivity win here.
So reading all the replies here, I think itâs easy to forget what the point is. How do we get more people using Ember? When it comes down to it, in my opinion, you need to make it WAY easier for people to start using it and reduce the learning curve. The simplest place to start is by reducing all the dependencies required to write a realistic app (anything more than a Hello World).
Many people have stated that Ember CLI is the answer. It is not. The answer canât be âEmber is easy, you just need to know how to use and install Node and Bower and Ember CLI and Watchman and PhantomJS, and then you can start using Ember in a practical wayâ.
Surely you can agree that is a steep set of requirements? Someone brought up a good point about Ember being more of a comparison to native Apps than a traditional web plugin/framework, which is true and I hadnât thought of that. But building a native app actually requires fewer frameworks/dependencies!
Now for everyone who says âWelcome to 2015 - this is the way it is nowâ, Iâll remind you that we are trying to figure out a way to get more people to use Ember, so letâs start by questioning the status quo. I really think you have to start with not requiring Node, and thus Ember CLI.
So, what are the alternatives? It occurred to me that the biggest reason for Ember CLI is compiling templates, and minifying and combining code. So why canât this be done on the server, at run time, and cached? I get Ember is frontend only, but youâre tying it to Node via Ember CLI, so youâve effectively tied it to the server anyway.
I propose a PHP class that generates you a single compiled/minified/combined app.js file.
Youâd define your App with a basic settings array, follow a directory structure like Ember CLI recommends, and then PHP would scan your directory, compile everything, set/compare to a timestamp for caching, then create the app.js file for you if needed (or return the cached one). Youâd then place that in your head wherever you need it, like so:
<script src="<?php echo ember_scripts($settings_array); ?>"></script>
The big advantage to something like this, no Node, no Ember CLI, no Bower. The resulting index.html (or maybe just app.js) file could be aggressively cached or CDNâd, or you could even save index.html as a static page and serve it without the need for PHP at all. It would work on any server running PHP (by far the most common setup), would work in the most popular language around, and would be very very easy for anyone to understand. You could release ports for Ruby/Python/Etc. The idea wouldnât be to replace Ember CLI, youâll always have your hardcore VIM dudes, but having something that lowered the entry level bar is the goal.
That âinsaneâ list of learning requirements for Ember would become PHP, jQuery, HTML/CSS, Ember.
Iâm down to help code something like this for sure (it would actually be easy, most of the hard work is done), I just donât know enough about how youâd compile HTMLbars in PHP, or if thatâs even possible?
2 Likes
@jthoburn Funny, same situation here my brother is working on a college project, his development skills are beginner-intermediate level. I pointed him to ember-cli earlier this evening and said give it a try, and an hour later he was asking how to get ember-paper working so he could have some âzingâ and his client was talking to his flask API on the back end.
1 Like
Yes,it does not take long to setup if you have committed the computer to all kinds of junk. Everybody who responds to any installation request with actual installation is doomed to learn the hard way. Thus any âyou have to install thatâ is a barrier.
OK, assume Ember is an exception due to irrational love to it from second one. So, I do install and get
npm WARN engine makeerror@1.0.10: wanted: {ânodeâ:â0.6.xâ} (current: {ânodeâ:â0.12.1â,ânpmâ:â2.7.4â}) npm WARN engine tmpl@1.0.3: wanted: {ânodeâ:â0.6.xâ} (current: {ânodeâ:â0.12.1â,ânpmâ:â2.7.4â})
If you emphasize the low number of commands you must assume little knowledge and assuming little knowledge you must provide absolutely clean install.
Now comes npm -g list. I you think people are âlots of wonderful stuffâ think again. People understand that each and every piece will malfunction at some time. People also want to see what they have got and the testing environment is a huge liability at this stage.
OK, now ember new cli01. On Windows it results in an Ember 1.10, despite installed according to 1.11 guides, empty app that does not work without not that easy to find performance tweaks. If you want 1.11, and after looking into the change log you definitely want 1.11, something has malfunctioned already exactly as I wrote above.
On Mac it results in âCould not find watchman, falling back to NodeWatcher for file system events.â (was it a correct install???) and âENOENT, open â/Users/andrey/web/EmberTests/package.jsonâ Error: ENOENT, open â/Users/andrey/web/EmberTests/package.jsonâ at Error (native)â
That is, cli01 does not appear in the path, the show stopper has stopped the show, as predicted.
Sidenote: never offer an installer first to Mac crowd when Homebrew can do the same.
There are 3 options. First, forget about the mindset. Second, ensure this shit happens less than once in a decade and is fixed under an hour. Third, put something else on the front page.
Now about the new app ember-cli creates. It is too empty. For example, {{outlet}} is easily visible and evidently unused. Want to fill it - go deeper into Ember docs. The app also does not work - I copy the distilled part to a server, point my browser to it, and see nothing. It is not âwelcome, docsâ, it is âgame overâ.
Just in case you wonder what I guess is the right way.
-
Brainwash everybody Ember so that no quick âhello worldâ comes to mind, ever. Everybody has that and the chances it does not scale are 99%. Same thing with ToDo lists that are Hello Worlds for business line applications - business line applications are being created with established procedures and are reluctant to change.
-
Find the differentiator. I do not know Ember well enough to propose more than 2: Rout that makes a one page app to look normal to the browser with all the shareable links into it and the dependency system. I guess the second one is more unique and to sell it something like Conveyâs game of like or a Snake game would be good.
-
Eat your own dog food. If I go to Console on ember.js I should have Ember or Em to play with. âYou can go to Console right now and tryâŚâ will be fantastic and extremely convincing early in the guides.
-
Find something interesting beyond the boring Web. I have not tried it yet, but it looks like an Ember app with compiled templates satisfies the security requirements for a Chrome app. That also makes ember-cli really necessary.
I donât think homebrew is mentioned anywhere in the guides. If itâs like synaptic, it installs node with sudo, which is a no-no. On Mac/Windows, just use the installer, as specified in the guides.