I think rafalp is onto something. There’s room for both approaches: A lot of the “how to think in Ember” stuff is really important for allowing you to be creative in the framework, but some “Ember Legos” to build apps with would be a much friendlier place to start. I think that’s what the cookbook was supposed to be, but I don’t think it’s seen much action in a while. Maybe we should do a “call for recipes?”
I’m a technology agnostic who wants nothing other than to relieve the suffering of developers faced with choosing technologies.
So I made this: http://www.dancancro.com/comparison-of-angularjs-application-starters
I’m looking for ember and ember-cli experts who can help fill in a few unknowns about these things so that people can clearly see what the trade-offs are between ember and angular and everything else.
If you are able to help out to any extent (you don’t have to be an expert), please send me a private message and I will make you an editor of the document. Every little bit helps and all good reasons to use ember (worded in yes/no form) will be added to the list.
So some thoughts from an Ember beginner (as in: no “real” code written yet). Also, first post, so hi all.
We at my company need to select a SPA framework (or toolset, if we’re being strict about what is and is not a framework). I really want us to choose Ember. Or more accurately: I’m really hoping Ember is a good fit for our purpose so that we can choose it. The thing is, it is rather hard to understand how painful things would be with Ember.
For example, one of our primary needs is to have Ember run nicely on Android (and iOS and whatever the mobile Windows is called), probably both as a website and as a phonegap app. So then you start googling around to see if you can find blog posts or forum discussions about whether I’m going to have a bad or good time with Ember, given those and other requirements. Then you quickly stumble across some old discussions like these:
(and even recent rants like this: Reddit - Dive into anything)
You realise they’re old threads and stuff has probably improved (and might improve before your app is going into production). But the seeds of FUD have been planted. “Maybe we should choose angular since surely the massive user base will help / has already figured all the solutions to any problems we might have?”
Of course, you then would start to look for newer information: whether the pain points you’ve found are still relevant. The point is: this takes way much more effort than it needs to. I have been doing substantial digging to understand where things are going and what pain points are currently relevant, so I know that there’s a list of things for Ember 2.0 on Github somewhere, I know there’s a conference talk on youtube announcing the date for 2.0, there’s a website (and a thing on Github) tracking the progress of the Glimmer engine (also announced on the same conference talk)… none of which has been linked or announced on the emberjs.com site (excluding this discussion board).
This would be extremely easy to fix. Just make more blog posts. I’d think things like Glimmer, date for 2.0, Ember conf videos, all the nice stuff that is happening around things like the CLI and Ember inspector should be announced and talked about in the blog.
1 Like
+1. Even if they were just links to the external resources, I think having a much more active blog would help. You could have links to the conference videos, particularly good meetup presentations, hot forum threads, RFCs, and maybe a “this week in Ember Twitter” best-of. The width and depth of stuff out there is great, but it would be nice to some curation on the main site.
1 Like
I actually posted over here about how to improve the Docs, before I’d read this thread. So let me address my thoughts on this topic.
I’m exactly the target audience that would have used Angular instead of Ember. In fact, I’m about 4 weeks into Ember and very close to calling it quits and moving to Angular. I’ll start from the beginning.
I’d say I’m an expert in PHP, jQuery and WordPress. I work at a digital agency, and work on WordPress powered sites almost 6 days a week. I’m in charge of a team of 3, with a network of freelancers. I hate VIM, we use Coda, the GitHub App, and generally stay out of Terminal.
WordPress just rolled out a JSON API, so we are starting to move to using WordPress as an API to power an MVC frontend. I spent a few months going into Ember v. Angular v. Backbone v. Flatiron. I would have gone with Angualr, except they blew up v1 and I’d have to start again with v2 at the end of the year, so I figured I may as well learn Ember now, and then switch to Angualr 2 if need be later.
The Google thing was a non-factor, seems like Ember gets hung up on that.
So far, the major pain points for me trying to get into Ember have been Pre-compling templates, Authentication, Routes v. Controllers (they seem to do all the same things!), Views v. Components (all examples use Views, Ember teams says to use Components), and Animations (not mentioned in documentation at all). I’m also struggling to find a list of all the action hooks (I’m not even sure that’s the right name for them - beforeModel etc) and what sequence they get called in (would it be too much to see something like this).
The steep learning curve. No one above has touched on why this is so steep, but for me its easy to see why. Here is a list of technology you need to be very familiar with in order to build a simple signup/login/save-something app.
- Node.js
- Rails (so many examples say “Ruby gem” and it makes it seem like you need to know Ruby just to install something).
- Grunt
- Ember CLI or Ember Templates
- Ember Data (the docs make it seem like ED is the best way to go, it’s not even at v1!)
- Ember
- jQuery RSVP promises
- Setup a .htaccess (or equivalent) file to route everything to index.html
- How to config CORS on your API server
- jQuery
- JavaScript
- HTML/CSS
The above list is insane, you are not making it easy on people to get into Ember. Could you imagine a job posting asking for the above skill set? What would the salary be? Compare that to WordPress: PHP, HTML/CSS and maybe jQuery.
Now, it seems to me the best thing Ember could do is start figuring out ways to cross things off that list. Here are my suggestions:
Improve/Remove Pre-Compiling
Give up on the “everything in index.html” examples. They are disingenuous and not helping your cause. Having templates in separate .hbs files are the proper way to do things, so start owning up to that. I know the Ember core team are very adamant on how build tools are such common place these days, but the simple fact is they aren’t. If you’ve come out of PHP, then you’ve never used them. If you improved the build process, you’d cross 3 things off that list right away. My wish: Build a simple plugin to Coda that compiles templates on save. Now I don’t need Ember-CLI, Node or Grunt, and I can host everything on any Apache server.
Better “Ember Way” documentation/examples
The example app is way too simple for real life. No one is building a blogging app with no authentication. Authentication is a major pain point that you need to get over very early on in a build, and there is no clear indication from Ember about how best to do it.
@rafalp hit the nail on the head (see what I did there?). The docs don’t come at it from the right angle, help us build something useful, don’t show us all the fancy stuff Ember can do on Day 1. My wish: 2 or 3 simple apps well documented showing signup/login/save-something, each more feature complete than the next. They should show the current best practice on how to do things.
Then something like the WordPress CODEX. Start the docs from the point of view: "So you are looking to build something. When a user requests a Ember page, first this happens, then this, then this etc etc.).
Don’t talk about Ember Data yet
It’s not ready for prime time, and it adds a whole other level of learning at an early stage of a persons Ember onboarding. You’d be way better off talking about simple ways to connect server side APIs manually. The concepts are easier to learn (it’s just AJAX returning a JSON object), and those lessons only make it easier for you to understand ED later when you are ready.
From what I understand so far, the same could be said for models. I got real hung up on defining models in Ember, when really if the server returns JSON objects formatted correctly, you don’t even need to define anything.
Animations
Angular makes a big deal out of this, because it’s what people in the real world want. The first thing anyone will want to do (even before authentication), is have a drop down menu or animation between routes. Ember makes a big deal out of being a “real world framework”, you need to give some official direction on how to do basic animations. My wish: Something way simpler than Liquid Fire, that allows me to slide in a menu, and animate between routes.
Stop talking about Rails/Ruby/Node
The PHP audience is massive, and the way WordPress is going will only encourage people to go the MVC way. But the more I see Ruby gem this, or Rails this or Node that, I just start thinking “wow, I have to learn so much just to use Ember!”. You should be server agnostic, and not require Node/NPM/Grunt to use something that is essentially a giant plugin to jQuery.
Get way into StackOverflow
Forget about IRC, your only helping nerds 
. StackOverflow posts last forever, and serve as a stop gap for incomplete documentation. The voting nature of it also makes me feel confident that something is best practice, more so than a blog from a year ago.
And having read the above thread, I’d urge you not to get hung up producing video tutorials. That’s such a frontend developer mentality (the days of Flash are over!). Clear direction on best practice from the core team, solid StackOverflow presence, solid example apps, and great supporting documentation is more than enough. WordPress got massive doing just that, can’t remember ever seeing a WordPress tutorial video.
10 Likes
Although I do not share your feelings here, I am actually absolutely on-board with fleshing out ember-cli / (editor|IDE) integrations. I believe this would really be nice. At some-point this is totally something worth pursuing.
This is actually one of the motivations of ember-cli, it aims to handle all these details for you. No need to learn how to compile templates, grunt, how to get tests running. Additionally, it aids community wide conventions, that make it easy to share add-ons (like wordpress) and also makes it easy for one ember developer to easily migrate to another ember project.
I am uncertain about the “its not ready for primetime” statement. I have seen and continue to see it used with success. Although it may not handle all use-cases, the ever growing set it does, work quite well.
Some pretty fun public examples that really show-case the flexibility of ember-data.
- http://find.io/ : uses ember-data to entirely abstract the itunes API
- Hacker News (source: GitHub - chancancode/hn-reader: An embitious Hacker News reader, built with Ember.js) uses ember-data adapters to abstract hacker news.
In reality, you do not need to use ember-data in ember, you can simply return ajax requests and ignore the ember-data even exists. It many of my apps, i really do use both.
When building an app with raw ajax requests everywhere, I quickly run into duplication of data serialization and API level concerns. Once i hit that pain, I start utilizing ember-data’s conventions to manage this complexity.
- adapters → API / Ajax level concerns (and honestly, just normal $.ajax in the adapters)
- serializers → data transform needs
What this means is, you can choose to use as little or as much of ember-data as your comfort level allows. As one gets more comfortable with it, you realize how it helps manage complexity.
if we look at ad the hn-reader, we can see that @chancancode uses the adapter to encapsulate the raw XMLHTTPRequest (this could easily just be $.ajax as well) https://github.com/chancancode/hn-reader/blob/7c9caa0e83b3eae91b6651633981658b070c9db1/app/adapters/article.js#L11-L34
Now that enables him, to use this.store.find('article', <article-id>) throughout his code-base, without leaking the details as to how.
This I also have to agree with. I in-frequently venture to StackOverflow to answer questions, this is largely do to personal time constraints, but I suspect making this a habit would actually go a long way.
1 Like
The above list is insane
Yes. Welcome to 2015. I realize that lots of web developers pine for the good old days when they were writing simple web pages. Those days are ending. Knowing just PHP, HTML, CSS, and jQuery is not nearly good enough to write the kind of ambitious applications that lead their industries today.
This isn’t an Ember-specific issue, this is the difference between web pages and complete in-browser applications. Asking how Ember compares to jQuery is not the relevant comparison. It’s more appropriate to ask how Ember compares to writing a native iOS or Android app (and I for one will take ember-cli over XCode any day).
The key tool that solves your pain points is ember-cli, and ember-cli hasn’t had a stable 1.0 release yet (coming in June). That means we’re still in early-adopter territory. Being an early adopter isn’t for everyone. It means you won’t always have clear instructions, and it means you will hit bugs. If you aren’t OK with that, then don’t be an early adopter.
We care strongly about creating a welcoming and accessible community. We want to help everybody who wants to learn Ember to learn it with the minimal necessary effort. But we are not miracle workers. Being an early adopter always comes with a certain amount of struggle. The early adopters do a lot of work that paves an easy path for everybody else to follow behind later. We are getting there.
3 Likes
As someone who just started a project for the first time this crystallizes my exact sentiments. Explaining how things work is an important first step. Explaining how things work in the context of getting **** done is the next.
[quote=“ef4, post:172, topic:3948, full:true”] Yes. Welcome to 2015.
The key tool that solves your pain points is ember-cli…[/quote]
I wanted to say “you’ve got to be joking”, so maybe I’d say it this way. If you knew PHP, HTML, CSS, and jQuery you’d know enough to learn any framework or coding paradigm. Then again I am a dinosaur and started coding in the early '80s, learning and adapting for 30 years can train you to always be adapting.
On your second point, if the future of Ember is cli, count me out. Coding from the command line is not mainstream and cannot have the reach needed to compete with frameworks that have more adoption and backing. I started on main frames, coding from the command line - it is not the future, it is very much the past.
Let me give you a little of my Ember experience. I started coding in Unity at about the same time as I started coding Ember for myself. By day and night I was a Unity game coder and at night I was teaching myself Ember writing my own animal husbandry site. In six weeks of being lead developer teaching the company how to write games in Unity (my first time) my boss said what I was doing he thought we wouldn’t be doing for six more months. In seven weeks of coding Ember I was ready to give up.
Now a few months later I’m back to try again, I’ve shown my Ember site to my friends and they had a much better idea on how to manage the data than I had. I’m willing to run through the gauntlet again and I have a better idea on how to pass data around within an Ember application which I hope to post in the future.
I am a talented developer and Ember is hard.
Coding from the command line is not mainstream and cannot have the reach needed to compete with frameworks that have more adoption and backing.
Here’s the thing: in web app development in 2015, there is no such framework. Not with the kind of flawlessly integrated IDE experience you want. But we are literally building the first layer that will make it possible. Other Javascript frameworks with much bigger backers (Angular), are starting to use ember-cli too because it solves this common need.
If you look under the hood in any IDE, there are lower level programmable primitives. More often than not they can be used directly from the shell. ember-cli is that primitive for this ecosystem. It’s a necessary step before you can do IDE integration.
Your comparison with Unity just reinforces my point. Unity is a much more mature product in a much more mature part of the wider programming universe. Browser apps are the wild west. If you want a curated experience like Unity, stay out of browser apps until the dust settles.
1 Like
Yes, I’ have had a really really hard time to learn ember, and I’m still confused. If someone rewrite the guides part, I’ll appreciate it really.
I agree with this one. It’s not that Ember Data isn’t ready, it’s that ember performs well with with POJOs and jQuery and that is simpler. For simplicity of learning I wish the Getting Started Guide didn’t mention Ember data at all. Then a “Take your Data Models to the Next Level with Ember Data” section
This page is a great introduction, and I wish that I had seen this page before I tried Ember Data while going through the Getting Started Guide
As a new user myself, this is the introduction I would have wanted:
Binding a model to your view is as simple as returning an object from your route’s model hook
App.PhotosRoute = Ember.Route.extend({
model: function() {
return [{
title: "Tomster",
url: "http://emberjs.com/images/about/ember-productivity-sm.png"
}, {
title: "Eiffel Tower",
url: "http://emberjs.com/images/about/ember-structure-sm.png"
}];
}
});
Views will update automatically after async data arrives via simple ajax requests
App.PullRequestsRoute = Ember.Route.extend({
model: function() {
return Ember.$.getJSON('https://api.github.com/repos/emberjs/ember.js/pulls');
}
});
You can easily format and parse the data to meet your needs
App.PullRequestsRoute = Ember.Route.extend({
model: function() {
var url = 'https://api.github.com/repos/emberjs/ember.js/pulls';
return Ember.$.getJSON(url).then(function(data) {
return data.splice(0, 3);
});
}
});
If you want to aggregate multiple async data sources, Ember’s got that built right in
App.IndexRoute = Ember.Route.extend({
model: function() {
return Ember.RSVP.hash({
people: $.getJSON('https://some/api/people/'),
companies: $.getJSON('https://some/api/companies/')
})
}
});
Ember Data has advanced features for maintaining relationships between models. Learn about Ember Data and the Data Store in Part 2 here
4 Likes
Then that is the most important piece of documentation that should be on the Ember site - THIS IS AN INCOMPLETE, PROTOTYPE FRAMEWORK.
You’re leading people on to believe this is ready for primetime.
This is just incorrect. I started on Visual Studio, then GUI text editors, and now vim- you’ll hear similar stories all over the place. Between that, npm, git, grunt/gulp/brunch/broccoli… the command line is very much the future. IDEs are terrific training wheels, but they’re terribly imprecise tools for serious work. It’s why Angular is doubling down on Yeoman (a CLI tool), and I’ve heard similar rumblings out of React. These are the tools for the job.
Calm down, this is a little much.
You are missing out here! Coding from command line is very efficient and deterministic, it takes no time to test your code and without all the overhead of your desktop environment you can eliminate all side effects. Ember cli generates everything you need with a simple command, you can’t forget about anything. Getting something working is much faster on the command line. Making it shiny comes later, get something started first!
This is almost the most idiotic thing i’ve ever heard. Its like the hipster-luddite of the coding world. Visual studio exists and people pay money for it because its worth it to them. Microsoft makes billions of dollars a year on this stuff. Apple makes billions of dollars a year on this stuff. You cannot say that the last 30+ years of programming advancement will be thrown away so that we can all go back to using vi.
I’m all for command line tools following the linux/unix paradigm of do one specific task and do it well but it shouldn’t absolutely force people into using it. At the very least there should be a UI available along side it, just like there is for git and so many other tools.
Wow, that’s the new tagline of my resume!
This is really the core of the issue. No one is forcing you to use anything. The #1 complaint levied against the JS community right now is that there are too many options. If Apple and Microsoft have nailed it, and us “hipster luddites” have it so wrong, why are you here?
On the other hand, if you wanted to be constructive and be a part of the community (you realize that this is open source, right?), here are some helpful ways you could have phrased this:
- “I see a lot of people talking about command line stuff- isn’t that from olden times? We don’t use that where I work, can anyone enlighten me?”
- “I’m just not a command-line guy, and I don’t think I ever will be. Who wants to help me come up with a GUI companion to CLI?”
- “I work in a Java shop, and we use Eclipse for everything. It’s kind of awkward to jump back and forth for some of the CLI tasks- anyone interested in helping me with an extension?”
You can keep giving Microsoft and Apple billions for their solutions, or you can use another solution that works better for you, or you can be a part of creating the Ember that you want, or you can just use everything as-is. You have a stunning number of choices, and the one you ran with was complaining that a ridiculously small number of people haven’t hand-crafted the thing you wanted for free, and that the many people who are thrilled with the existing approach are idiots.
This might just not be a good fit for you. It doesn’t have to be. Why does that enrage you so much?
2 Likes
I think you misread what I was getting at. The emphatic stance that command line “is the future” is narrow minded and promotes regression. I never said I hated commander line tools. Command line tools are already present as the base for every compelling interfaces.
You want to know how to beat angular Js in the developers mindset? Make compromises to draw more people in. Be open to opinions and willing to try the tried and true methods even though they are not hip or cool. JavaScript developers are a damn opinionated bunch of people. I would argue this is the reason we have 18 different tools that all generally do the same thing and there is a new damn framework every other day.
I realize this is the way of things sometimes as was the case with jquery but it doesn’t have to be. This xkcd basically summarizes the problem. xkcd: Standards
Consider the context in which I wrote that “the command line is the future.” Ember-CLI isn’t an aberration- it was a trendsetter. Angular and React aren’t running away from this, they’re incorporating it. It hasn’t been a failure in this community- it’s actually helped with adoption and growth substantially. It’s not regressive- IDEs are absolutely not an “improvement” on CLI tools. Different choice? Sure. Not right for everyone? Agreed. I’ll even say that it puts up a wall against being beginner-friendly (never a stated goal of the project, btw), which last week I argued should be accounted for in the docs.
This thread is a year & change old, and over that period has become a catch-all for “I liked this from other frameworks,” which is still worthwhile. The closing keynote of EmberConf a couple weeks ago was obliquely about how we should stop caring about “beating” Angular, which is super relevant right now. It’s not about beating Angular (or React, or the next one…), at all anymore. It’s about making the tools that this community wants to use. If the fuzzy thing that this community is about roughly aligns with what you’re looking for, it’s a party with an infinite number of seats and you can start being a host whenever you want. We don’t need to “beat” anyone anymore.
We also don’t need to compromise to draw in more people. We can be this size, or double, or quintuple- doesn’t matter. Ember doesn’t need to be the new Spring or whatever, and you’ll find few people around here that want it to be. The only question you need to answer is whether this community is a good fit for you (it really is just goddamned incredible). You have other (very good) choices though. Are you going to be the champion for Ember GUI tools, or are you going to be that for Angular, or are you just going to wait to see who else does it…? All valid choices.
1 Like