Ahh now it makes sense why the guides of ember-cli do read like they are expecting every developer to have OSX running!
Since I actually think the only reliable way of development is on a linux VM, I had a lot of trouble getting node, phantom and ember-cli to work in my debian as well. The best would be an official docker image! Everyone would work on the same platform and new people would not need to worry about what to install where with what right in which order for what version (WTF?)
Seriously, this is an open source project. If you find things that donât work, then fix them, donât just bitch about it on the internet.
Ranting about how terrible some decision is just doesnât help. Come up with a better solution, propose it to the team and see where it goes. None of the core team are unreasonable or just out to make your life difficult. Even better, discuss it with the core team, fix it and submit a pull request.
Insulting people and taking some kind of moral high ground is not helpful.
There has been thousands of hours put into developing Ember and the associated tools by hundreds of people, many doing so for free. They put this software and tooling out there for free. Find yourself a problem with closed source, tough shit, find a problem with OSS, crack out the source code and fix it or point the makers to the problem.
Not all professional developers are men, many are women too. Some use Windows, some use Mac, some use *nix systems. Again, such negative tone isnât the way to get help.
Jumping on people who have made a genuinely useful remark is also not helpful. Ramcat is right, no-one should run commands blindly without knowing what they will do. For someone completely new to the ecosystem thatâs what these commands equate to. A âgetting startedâ guide should have a brief explanation and a link to the relevant npm docs, calling someone out for not immediately jumping in to the previously unknown git/github environment to fix things whilst they are just getting started understanding the project is definitely not helpful.
There was no negative tone here, especially when taken in the context of all the other useful comments that Ramcat has made from someone who is clearly coming from outside of the command-line driven web & javascript ecosystem bubble that many ember.js adopters have come from. Ramcat did not suggest that all developers are male and work on windows, only that his development experiences so far have been almost entirely windows-centric - we should listen in that case, there will likely be many more people arriving with similar backgrounds as Ember.js grows and is used more and more in non-rails/node/linux/osx shops.
It seems that there has been a noticeable trend lately of attacking newcomers who are venting their frustrations whilst stumbling at the huge web of dependencies that many of us have taken for granted for many years now. This is sad, we should listen to them and re-learn what itâs like to be faced with such obstacles. The Ember.js community is one of itâs greatest assets, letâs not destroy that by turning into a members club where one must have all the requisite knowledge in order to be treated with respect and have their voices heard.
Lowering barriers of entry can only help in the long term. Sharing knowledge rather than chastising those who donât match your own knowledge/ability-set will help developers grow and be more likely to contribute once they have the requisite skills and confidence.
@ramcat, please continue, your experiences are useful and will surely go towards making Ember.js easier for a more diverse developer audience.
I donât think what you are saying is wrong, itâs a good idea to do these things. As all of the people working on Ember are OSS contributors, there are things that may not get done because of differing priorities. As I said previously, if you see an issues, make a suggestion and try to fix. Starting out with just plain negative comments doesnât help anyone.
If we start with gentle language, like, âHey, Iâm really struggling with x, what am I doing wrong?â then it starts a conversation that leads to positive assistance. Thatâs what Iâm jumping on, along with the use of gender exclusive language and sweeping generalizations. When we use those words, no matter how well intended, it creates the sense that some people (such as women) are not welcome. A diverse community is wonderful. There are lots of things happening that should hopefully help developers from a more Windows centric background get started with Ember CLI (Releases ¡ ember-cli/ember-cli ¡ GitHub). Sure itâs not perfect, but things are going the right way.
Building things that work in all environments is a super complex task. I personally develop on a Mac with Ember and on many occasions have run into issues, thatâs the nature of the work. Just last week I discovered that Ember CLI had stopped working without a network connection (super useful when you discover this on a 4 hour flight). No one had set out to exclude me or make things difficult. I let people know using the issue tracker and it was fixed very quickly.
Anyhoo, my message is really simple. Be nicer to each other and we all do better.
this looks like a bug on our end, git should not be required. I have opened a ticket: should work gracefully without git installed ¡ Issue #3702 ¡ ember-cli/ember-cli ¡ GitHub
and will look into it right-now.
edit: ah, this is because bower is silly and requires git. We have plans to drop bower, but it will be some more work. ( have opened an issue on the guides: GIT is a dependency for ember-cli (because of bower) ¡ Issue #146 ¡ emberjs/guides ¡ GitHub)
we currently bundle bower as ember install:bower
Ya this is likely a good idea, would love it if someone could champion this.
Yes, it would be great if somebody wants to champion a Docker image. It would be a nice option for people to get started easily.
But I will caution that I donât expect Docker to become the de-facto standard way people run ember-cli unless the filesystem synchronization performance gets significantly better than it is right now. I have run ember-cli in various VMs and tried many permutations of filesystem, and never managed to get builds nearly as fast as running natively.
If youâre using a Linux host, that may not apply, because in that case the Docker container is extremely lightweight. But on any other OS, you end up with a heavyweight VM underneath Docker.
The other major challenge would be that really using Docker properly requires a very different workflow than what we do now. So unless we get everybody to agree on Docker as the standard, people will end up with two very different workflows, complicating the problem of teaching newbies even further. As an example: the proper Docker-ish way to install a new Ember addon would be to edit your Dockerfile & rebuild your whole image, instead of running npm install inside the image.
I actually might have misunderstood the docker-ish way. I thought itâs just to setup a development environment. So installing a new ember addon is not part of the image anymore.
I use IDEâs on windows all the time, sometimes on OSX(at home). My project and development environment is a debian always though. I use Samba to access the projects on the dev env. Installing all those frameworks and tools and building on my normal desktop environment feels just wrong. A VM (docker images are basically just preset VMâs) you can always mess around with and even totally mess it up! I donât want to mess up my normal env. After a few years and a few jobs I would have one thousand and one tools and servers starting up everytime I want to start the computer to check mailsâŚ
no thanksâŚ
each project a new VM, which can be archived or thrown away. Saying that I will now uninstall that bloody Zend and SQL Server that have been running for so many years now and never been used haha. And then I go and setup a dockerâŚ
seems like there are a few ones already⌠any experience anyone?
I put together a docker support branch of ember-cli-todos here â GitHub - jakehow/ember-cli-todos at docker-development-support
Here is the related issue in ember-cli â Docker + ember-cli applications in Development ¡ Issue #3679 ¡ ember-cli/ember-cli ¡ GitHub
If you try it out and have any issues let me know and I will try to help (however I do not have a Windows machine to test).
Thank you for the update. So for the sake of documentation the order now is:
1. Git (from this link: https://github.com/bower/bower#windows-users) 2. NodeJS (includes NPM). 3. Ember-CLI (npm install -g ember-cli). 4. Phantom JS (npm install -g phantomjs).
I knocked up an ember-cli install guide component. http://jsbin.com/wiwufe/
@Ramcat would this have covered your questions coming from a windows/non-cli background?
I havent added a git option, and I havent used nvm-windows myself so I dont know how stable/usable it is
Ok, that jsbin is cool. A great example to people who want to make things react to selected checkboxes.
But to answer your question honestly, Iâd have to say no. It introduces NVM which was not in the Ember documentation and does not explain what a package manager is, nor what itâs going to do to my machine. It also does bower which from the explanations in this thread above is not required (globally).
The only reason I some idea what a package manager is, is because I did a ROR project 5+ years ago, perhaps I had forgotten a few details - the main one is how distasteful their file placement is. With an installer I get to pick where the files go (true there are bad installers out there) but a package manager that puts files in the user directory for Windows to mess up is just unfathomable to me and my experience selling shrink-wrapped software since '97.
Also I altered NPMâs config file per their instructions and it made no difference to the bulk of the files - the cache files moved but everything else went to the user directory.
And just for the record, I started coding on main frames, so for me the command line is just âso thirty years agoâ, its not that I donât know how to use it, its that in this era of modern computing I find it distasteful and more importantly I believe less people will or can code that way, than an IDE or visual programming environment. For me, its âcan children learn this readily?â.
Do you say that about medicine or law? Software engineering is a profession, it doesnât have to be easy enough for children.
Software Engineering is still a profession that does not require a degree, I started learning at 14. Unfortunately I see that trend in age going up - kids start learning coding later. There are the exceptions but I donât see as many kids at 14 who know what me and my friends that age knew (and my fellow developers when they were 14). No the law and medicine are for adults coding is for anyone.
Over the last 15 or so years I have seen a huge swing towards cli-based tools in backend web development. As the minimum requirements for web apps have grown so have the tools necessary to architect these ever-growing projects successfully. Now that front-end apps are reaching similar complexity itâs been a natural progression for everyone already in the industry. The command line has been a proven, efficient method of working both locally and on remote servers which have been overwhelmingly linux based.
The industry is still in its infancy in many respects and that is shown in the fast moving and often tumultuous landscape of web-focused languages, frameworks and dev tools. Building a deeply integrated IDE or visual programming environment is a huge and slow undertaking that is often interminably linked with a particular language/framework/OS and so weâve seen the move towards cli tools that can adapt quickly.
Weâve also seen the rise of hugely configurable and customisable text editors that play nicely with the command line tools that most modern languages and frameworks provide. If you want to itâs usually possible to configure these to give you all or most of the benefits of a full IDE for your particular language/framework of choice.
The key point has always been about choice and being able to move fast enough that we arenât stuck with outdated technologies because the IDEs havenât been able to keep up. Thereâs a clear progression where new technologies arise with little or no tooling, then the cli tools get better and editors start improving their support, and finally if the technology is around long enough and becomes ubiquitous then the IDEs arrive. Ember is in the early stages of this progression (as are all other front-end frameworks) so youâve joined at an exciting time!
Simply flat-out saying that itâs wrong to use cli tools is as short sighted as saying that IDEs have no place. Both are useful and serve different segments of the industry.
What is useful is pointing out areas where docs make too many assumptions and leave knowledge gaps for new users, or starting some discussion about specific issues that you believe an IDE would solve.
Coding is for everyone. Professional, well-architectured development within complex and rapidly changing software environments is a different matter. Ember is definitely in the latter camp and you wouldnât expect a just-started 14 year old to have the requisite knowledge just as you wouldnât expect them to have the requisite knowledge of law or medicine.
Making generalising and potentially caustic comments is distracting from the real issues youâve raised and the people trying to help with and understand those frustrations.
[quote=âlookingsideways, post:37, topic:7666â] rapidly changing software environments ⌠Ember is definitely in the latter camp [/quote]
My comment that started all this is that Ember is incomplete and a prototype framework. I donât mean that as an insult (being told âbrowser appsâ are the âwild westâ seemed insulting to someone who has been coding dynamic web sites, the first browser apps, since '98) - I mean that as Ember should document that to new users. Use this at your own risk because Ember will change as you learn it (it has in the time Iâve been here). Being upfront about where the framework is, is honest to your new people. It is a framework for ambitious web sites but it is changing so fast as to be unsuitable for, I would say, most professionals and most professional development shops where estimating and delivering software at known rates and costs matters. Iâm good but I could not estimate the time it would take me to build an ambitious web site in Ember. That point alone might make most employers pass.
I would think its obvious I have softened my comments over the last few days, I was not trying to be caustic, though the CLI fans have told me to grow up and do software like the âbigâ boys, that perhaps a 14 year old could do my job, that this is the state of development today, and other comments you might consider just as caustic if delivered at you.
This is really unfortunate. The Ember.js community tries to hold itself to a higher standard so that we do not alienate new users, but it is clear we continue to fall short. This is especially true when those new users come with a different perspective.
I began programming when I was 10, so I understand where you are coming from. I do think we need to make it easier for new people to join the Ember community and learn these great tools.
Kyle, first, no one is saying that what you do at work on a daily basis is easy enough for anyone. Second, there is no call for you to claim this might be true for anyone else.
However, children can learn to program, and some of them can do so very well after just a few years of learning and practice. Thatâs not a judgement on âprofessional software engineeringâ, but on whether the concepts required to code are beyond the ability of children to grasp. Why should you feel so threatened by this?
Children, and anyone else, could learn to write a web page with extensive JavaScript today, finding solutions to most of the basic setup problems with quick Google searches. Right now, this is not true of the Ember platform. That is a valid criticism. Responding to it with such defensiveness is not helpful.
@Ramcat I agree with you that IDEs can be way more productive than the command line for a ton of us, but only when the language/framework moves gradually enough to let the IDE adapt and build up its magic. Itâs a vicious circle because Ember moves too fast for an IDE to catch up, so Ember folks canât rely on IDEs, so they donât focus attention on them. The fact that the official docs are just catching up shows that a full IDE integration isnât gonna squeak into the core teamâs free time right now.
If you can get something like SublimeText (or Atom?) running on your Windows box, @lookingsideways is right that you can get it halfway to an IDE. There are enough Ember-relevant plugins that I think itâs a good semi-IDE for now. And if/when you get ember-cli to cooperate, its HTMLbars and ES6 linters also do a lot of the code sniffing I used to love from Eclipse/etc.
I love my mouse (there, I said it). I love clicking, and buttons, and Finder, and typography and interaction design, but as a front end dev it can be depressing that I have to spend 80% of my day typing in a terminal when my goal is making something visually beautiful. It feels like trying to draw a landscape in Photoshop with voice commands, and the disconnect between the tools and the goal can distract me from the goal, until we obsess more and more on process and less on usability or visual language.
For the people who prefer the terminal, JS tools and ember-cli are great!
For the people who prefer IDEs or clicking, Iâm sorry and I feel your pain! But you should try tricking out Sublime or Atom or something else until Ember slows down enough for the IDE makers to support us.
@ramcat didnât come in with a different perspective- he came saying heâd making software for a thousand years and that weâre all doing it wrong. Weâre exceedingly nice to new folks, but he hasnât been asking for help, heâs spent weeks talking about how insane it is that the community hasnât been redesigned around his fringe case. I think folks have been pretty well-tempered about it, considering.
Except thatâs pretty much what @ramcat said when I said that our tools donât need to be easy enough for children, they need to be powerful enough for professionals.
As for this:
The amount of actual typing required by Ember CLI on a daily basis really stops at âember sâ, and maybe âbower update.â Everything else you can do using whatever method or tools you want to, including an IDE, a WYSIWYG, vim, whatever. Itâs part of what makes this amount of pushback so baffling- CLI is pretty automagical and minimal if you want it to be.