we currently bundle
we currently bundle
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…
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 -> https://github.com/jakehow/ember-cli-todos/tree/docker-development-support
Here is the related issue in ember-cli -> https://github.com/ember-cli/ember-cli/issues/3679
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?
@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.
I don’t see why using Windows or integrating with IDEs should be considered a fringe case. It strikes me as common and reasonable. Lots of people are more productive when working with GUIs. The command line is not a friendly interface. You come off as arrogant by calling this a fringe case.
I disagree. We should absolutely make our tools easy enough for children or anyone else. That’s how we expand our community and make newcomers feel welcome. Being powerful should be of secondary importance. Besides, the whole point of a tool like Ember CLI, its power, is its ability to save time. Time wasted figuring stuff out is contradictory to the goal.
Because it is. 83% of Ember devs use CLI, and only 10% of them are .NET developers. And, as I’ve said, you can keep using Windows, Visual Studio or whatever you want- as soon as you save the files, CLI will notice the update and reload the browser for you. If a tighter integration than that is desired, it would be preferable for ramcat to try to assemble some people interested in building that with him rather than railing about what rubes we all are for using ancient tools on our “incomplete prototype” framework.
To being easy for beginners? I just disagree.
That’s true, 80% is a high figure now that I finished migrating my app. But even migrating my second big app took several weeks, and I think 80% of that time was devoted to app-specific build problems, misunderstanding npm or bower, or tracking down things in ember-cli or ember-cli-rails that were either open or closed issues.
Once ‘ember s’ finally worked, it kept working, but getting there was rough for me, and I’m one of the 83% of devs who said they use ember-cli. If there was a checkbox for “I use ember-cli but it hasn’t saved me time yet”, I’d check that one too.
@Gaurav0’s right that “Time wasted figuring stuff out is contradictory to the goal”. And that’s @Ramcat’s curse, is that Ember CLI, the thing that saves time for most folks (with *nix OSes and npm/bower/ember-cli experience) is the thing standing between them and getting their Ember code running. And that makes @ramcat and I fringe cases because we don’t have experience in these things and were spoiled by the workflows we perceive as “easier” (like the rails asset pipeline or the perfect black box executables in Windows).
Coding is for anyone. Building Ember apps is not for anyone, just like building ambitious apps in any generation or language is not for anyone. But the discussion should be who exactly is it for. Just professionals, or amateurs too? Just OSX, or Linux or Windows? Just Ember-CLI, or Rails or cut-and-paste script tags?
Ember-CLI is clearly the easiest way to start a new application on a Mac that’s fully separated by an API and deployable on a nodejs-friendly infrastructure, and easiest for an existing app that’s rewritten to fit Ember’s 1.10+ expectations. If you want to expand the boundaries of who else gets to join the club, then let’s at least make the boundaries real clear in the guides.
- Windows - caution
- Inexperienced in terminal / cli - caution
- Old View/Controller Ember app, hard to make components - caution
- App can’t be separated from backend - caution
If the community wants to make things easier for any of those groups and expand the boundaries of who can be productive in Ember, then great! But we have to warn people in the meantime that they’re on the fringe.
I think this is a great idea, especially if built into a “who is this for?” section. I think we’re scared of turning people off, but a little bit of clarity up front on what challenges you might face as an adopter would be great, especially if it’s coupled with links to resources for dealing with those challenges.
I don’t think Ember should be “experts-only”, or be cryptic about what skills you need to have as an Ember dev. At the same time, if you’re new to node, npm, bower, CLI tools, QUnit, testem, phantomjs, git, and MVC concepts, you should be prepared to start learning those things. In 2015, you need them (or similar) for just about any approach you take to web development. As for OSes, it’s not just this ecosystem that’s not optimized for Windows- it’s pretty much all of modern JS development. Angular/Yeoman has the same problems.
I’ve seen this come up a number of times recently. Ember-cli is completely agnostic to your deployment infrastructure, in fact I would imagine the most common deployment is to a static host. I’d be interested to know where that misconception comes from as it seems that the communication there can be improved.