How do we beat AngularJS in the developers mindset?

246

This is documented in the guides. From Customizing Serializers - Models - Ember Guides

By default, Ember Data serializes data using the JSON API format. If your backend uses a different format, Ember Data allows you to customize the serializer or use a different serializer entirely.

Then there’s a section explicitly covering attribute names: Customizing Serializers - Models - Ember Guides

Do you think this could be communicated more clearly somehow? Due to the scope of Ember Data it’s not possible to account for every possible API format out of the box (I’m not sure there any solutions that do?) but it does offer some very powerful hooks for you to bend it to your needs.

247

I think the bigger point I was trying to make is that a highly opinionated framework can be problematic when applied to the top of an already existing set of code. And that situation accounts for a large amount of corporate uses that would be a big benefit to Ember.

But maybe that’s the bigger answer. If you want to be Angular, talk more about how businesses can convert to Ember, and not have to be all greenfield development.

1 Like
248

I agree about Ember Data. Atm it’s just not flexible enough for many legitimate scenarios - especially with legacy code etc. Not everything is 100% RESTful and I find it odd to suggest that it is. This way, Ember is marketing itself “for greenfield projects only”.

249

DS.Adapter is extremely flexible in adapting API. Any inflexibility is all mental blocks self imposed by the programmer.

  • You do not have to use DS.RESTAdapter.
  • You do not have to use DS.JSONAPIAdapter.
  • You are allowed to extend DS.Adapter directly.
  • You are allowed to implement each operations (createRecord, updateRecord, etc) in DS.Adapter dramatically different from each other. I have adapted API calls that even goes to different domain.
  • You actually do not have to use any of the DS.Serializer until you’re ready to refactor your DS.Adapter
250

That’s quite a statement, thank you. As someone who has spent hours wading through the Ember Data source code only to have all their solutions pulled out from under their feet as the whole API changed, I find this to be mildly offensive.

In any case, it’s not true. Many of the hooks aren’t there (or at least, weren’t - there has been some improvement since 1.0). Issueing a simple query like /vendors/1?with_image=true proves to be quite a challenge with ED. Another thing that is hard to do is when you have multiple POST endpoints on a single resource (yes, not every API is RESTful). Yes, you can probably rewrite a whole adapter yourself without extending from DS.Adapter, but at that point why even care about Ember Data?

I find such blanket statements to be harmful to the cause of Ember. Being honest about what works well and what doesn’t goes a long way towards establishing trust between a framework and its users. “No, it works, you just have ‘mental blocks’” - not so much. Heck, I’m not even saying that there isn’t possibly an easier way around my issues, but at least it’s all far from obvious as the other members on my team can testify.

edit: Also, I just noticed I was saying good stuff about Ember Data above. :smiley: That was in June - some things have changed and some new challenges have opened up… nevertheless, the point is not that ED sucks in general. When it works, it works fabulously; the issue are the 20% of the cases when it doesn’t work, and by the pareto principle we all know these take the largest amount of work to get right…

3 Likes
251

I would love to help you with your Ember Data issue, but this is not the place. Please start a new thread so we can discuss this further.

252

Your point was “any problems with ED are self-imposed mental blocks”. Unless you meant to imply the truism that every solution to a problem that hasn’t been discovered is a “self-imposed mental block” in some way, this amounts to claiming that ED can adapt to any API in a straightforward, easy way. My point was that this is not true, which is why I provided two very specific examples (I could provide more, but just look at the GH issues). For both of these, btw, I (or rather, my coworkers and me) found highly non-obvious solutions by wading through the source code.

Also, this is on topic. Please do not insist that it isn’t. This was not a request for help, it was a personal assessment of Ember Data. And that’s neither saying that ED has no reason to exist or does everything badly, nor is this any kind of negative judgement about the maintainers of ED whom I do respect for creating such an ambitious library. That said, I still think it should come with a huge disclaimer of its scope and limitations.

253

As a guy who’s used Symfony (PHP Framework) and has been using Angular for just as long, I’ve always been intrigued by Ember.

The barrier for entry is a few specific areas:

What I want: To build some interactive components using the strengths found in a few areas of Ember. Namely the Observables (rather than Angular’s dirty-checking) and the Handlebars integration, and in my head this all made for a nice little component structure. What I saw: “Download this run these commands this thing will scaffold all kinds of stuff and generate a ton of folders and files and use node and npm and bower to grab these dependencies over here oh and about these routes”

in my head I was like “STAHP!”

A self-serving explicit cli tool right up front that is only designed to do stuff for your thing is a steep asking price, historically, for any tool. But when im not a node developer, I may not have node specifically installed, never mind npm and bower. As a PHP developer, that’s a whole different ecosystem for me. (I was just in a fortuitous position where I had dabbled in node in the past, and use bower pretty frequently for all my projects)

You know what Angular doesn’t need? Node, a package manager, a cli, a scaffolding system. It just needs you to provide a script tag to the core angular library, and put “ng-app” somewhere in your html. That’s it, and your good to go. Two lines in my existing page and I was up and running, and the first 10 words on the front page of the website gets you up and running with something useful.

You know what Ember really REALLY needs right now? A bare minimum full example of getting something going, that is actually light on requirements, just like Angular has. I don’t want to download an ecosystem of tools to generate four billion files and folders and setup a build system just to put “Hi my name is ____” on my page.

Now in my application, while I’ve figured out my build workflow (imposing, because I didn’t need one before) now I have yet to figure out how to get ember to do anything useful in my page, because I still havent seen a full page end-to-end example in all my googling that’s coupled with an explanation of what’s going on. I’ve seen js snippets and hbs examples, sure, but that’s it.

The rails thing doesn’t bother me much, honestly, because any server side programmer worth their salt should be able to translate the concepts from rails to their favourite language of and frameworks of choice pretty quickly.

So while im still learning this thing and have yet to build anything that even has it on a page, my two cents are as follows:

  1. End to End full page examples.
  2. Show me some practical use running examples in the documentation as I’m reading it. Angular docs as terrible as they are, at least feature fully working examples that demonstrate the concept the page is trying to convey. I realize some exist on the front end of the ember site, but they feature only snippets and its more difficult than necessary to visualize how it all works from top to bottom.
  3. In the end, all I wanted to do was create a real-time dashboard component that has in-line editable content. I’ve already got this in angular, but I’ve had to do some cheap shameful tricks to get the results across that I’m looking for, that things like Ember and Knockouts observables solve. Or at least, I think Ember’s would. I have yet to get a freakin example going.

Take what I got to say with a grain of salt, I think it’s mostly just the overburdening frustration talking here. I want to like you Ember, I really really do! But you need too much of me right up front!

1 Like
254
255

Yes. But then that’s what Ember assumes you are willing to do, as a developer: If you want to treat JavaScript as a serious and integral part of your application that you are willing to spend time setting up your toolchain.

There’s an argument to be made that you may not want to do so. Countless web app developers have been quite happy with throwing script tags into their app and that’s it; sprockets has made this very easy for Rails and there’s probably similar solutions for PHP frameworks too. But there are downsides to this approach: Modularity, precompilation, asset digests, minification, transpiling (if you use ES6), etc. pp. all have to be supported by your backend framework specific toolchain; and think about what happens when you swap out your API completely. And as for package management, well, you can develop JS without but I wouldn’t say it’s exactly fun.

It is fair to say that Ember requires an upfront investment in setting up your environment (although ember-cli makes this as easy as possible). If you don’t want to do that, Ember will not be the right choice for you, and frameworks like angular allow you to introduce JS more “gradually”.

But then think about what you’re trying to do: You’re trying to write a SPA (otherwise you wouldn’t use Ember) and that means a website that is, for all intents and purposes, governed by JavaScript. Why is it such a bad thing to invest in a proper JavaScript toolchain then? I don’t know how you develop PHP, but wouldn’t you say that using composer, properly modularized code and deployment scripts is a massive improvement over just manually editing your HTML and throwing PHP in and then SFTP-ing everything to the server like in the days of yore? So why not approach JavaScript with the same attitude?

I do agree about documentation and proper full page examples, however.

256

You should really tell the Angular 2 guys this. They are busy building exactly all that, called ng-cli. Guess who was the inspiration?

1 Like
257

In all fairness, there’s a time and place for small-footprint frameworks that you just sprinkle in for the 2-3 things that you need. That said, Ember doesn’t want to be that kind of framework.

1 Like
258

I couldn’t agree more The moment I saw typescript I had almost wrote it off from there

259

Ya I hear what your saying, this might just be how it has been presented to me thus far and how it’s not even in the same ballpark of thought

You see everywhere “angular or ember” and angular this ember that etc etc

And when I saw things like that JSConf demonstration between Angular, Ember, and Knockout the presenter went out of his way to extract the snippets in use in his slide and never once showed the file system

What I’m getting at is that from where I sat, it looked like Ember was supposed to be Angular’s direct competitor attempting to accomplish the same tasks with a different under the hood approach.

And yeah in the PHP landscape the usage of composer and full stack framework adoption has been instrumental in improving the scene and proving there was a better way than what we traditionally were doing. Stacks like Symfony also incorporates things like Assetic which I think is similar to the rails component you mentioned earlier (I’m on my phone) it’s a cli and template asset manager.

Where Ember cli and composer (and npm and pip and gems and blah blah) differ, is that these package managers are general purpose. Though one COULD say if they knew Symfony “Its got a Console cli component to it relies on pretty heavily” where that one especially differs is that it’s also general purpose, other vendor packages in the framework can “tap into it” and extend it infinitely.

My problem with Ember cli was exactly the same I had with meteor cli and cakephp cli, these are client components that solve a very explicit problems (I’ll call them DX issues (Developer experience)) and purpose for one thing and one thing only ever. So now I got this little program installed. For brevity I also dislike Symfony’s little tool to create new projects for this exact same reason. It’s one function is to clone a new Symfony project into a new directory.

I am also familiar with the use of Gulp and Grunt for running tasks and watchers continuously doing their thing. At one time for a node project I had I think four or five running cli tools doing various things and solving explicit things. I’m not unfamiliar with this landscape. Nevertheless I still think Embers up front asking situation is a bit cray still, and in the situation where I don’t necessarily want a SPA explicitly, I still think Ember would do well to easily enable someone to do that fairly easily. Even if it isn’t the best part or reason or even target audience. But that may be just me lol

260

I agree, although while having ember-cli and friend is indeed a good thing, I also believe they should not be mandatory.

Talking about inspiration, JS frameworks have decades of toolsuite experience from other languages to build on, and monolithic toolsuites have clearly shown their limitations. Too cumbersome for small projects, yet not flexible enough to be used in an application ecosystem, they mostly shine for standalone, mid-size projects only.

Maybe it’s just me, but I have this nagging feeling that the JS world is re-inventing the wheel, while it could have used proven and tested tools. And it’s doing so in a completely isolated, non-interoperable fashion.

261

I hear you. I think the issue is just that the JS landscape is very fragmented and not incredibly mature in a lot of ways. In Ruby, e.g. there is one dep/package manager (RubyGems+Bundler) and one task runner (Rake) and that’s it. JavaScript still hasn’t figured out the way to do things and IMHO, in a lot of ways, it has really fundamental issues (e.g. reproducible builds with NPM are really, really difficult). I think that’s why Ember “reinvents” a lot of the things you wouldn’t deem necessary otherwise.

@spectras - ember-cli is not strictly speaking mandatory. You can still develop without. That said, I think for a small community it makes much more sense to converge on a standard set of tools. Documentation, addons etc. are geared towards ember-cli, but you can always just drop a script tag to Ember into your application.

262

Hello Ember group,

I made a database to collect the differences between technologies and would appreciate input from an Ember expert about this one.

Go here to see a trade-off report between Ember and Angular. If you see anything that’s not right, you can just click on it and enter a correction.

Thanks, Dan

264

Hello,
It’s a bit messy, it seems to mix completely unrelated things, such as ECMAscript 6 features, with the frameworks.

  • Basically, the whole “syntax and language” is mostly irrelevant to a framework comparison.
  • Or “errors are displayed immediately in the editor”, isn’t that a feature of the editor, rather than of the framework?
  • Or “safe from stored cross-site scripting (xss) attacks”, that does not depend on the framework, that depends on the application code.
  • Also, criteria are fuzzy and seem to stem more from pre-existing opinions than measurable things. Eg: “easy to test”, what does that cover? “fast to load”, how much is that, 10ms? 100ms? 1s? 10s? using what device and what network?

I believe the approach will not yield the results you expect. If you are planning to do a generic comparison (eg: press article), you should define generic enough aspects you want to compare, before even looking at the frameworks. If you are planning to choose a technology, you should define which criteria are relevant to your project and your company.

Anyway, if you want to discuss this further, I suggest you open another topic :slight_smile:

265

Thanks for taking the time to consider this approach.

If this isn’t the right thread, I’ll start another one. I thought it fit because it is meant to clarify the cases for each of Angular and Ember which influence decisions and developer mindsets.

You raised a few objections, so in fairness to myself, I’d first like to answer them.

I hold that when making technology decisions, it is not the best approach to consider the technologies in isolation from their dependencies. What you see in the syntax section mostly reflects my understanding that Angular 2 uses Typescript and Ember doesn’t. I might be wrong about that. Typescript provides some benefits. If Ember also uses Typescript, then all of those things will go into the third, ‘common’, column of things that don’t factor into the decision.

People make decisions for many reasons. Some of the reasons are facts but unfortunately many of them are opinions. As you know, opinion reasons are debatable, but nonetheless very important to many people and unfortunately hard to replace with quantifiable fact reasons. Because they’re debatable, I put radio buttons at the top to show or hide the opinion reasons which I record in the database in a very unscientific process of reading all sorts of different commentaries.

If you’re still interested, here’s the whole project. It might help give this Ember/Angular comparison some context.

266

I don’t understand people who criticize Ember or Ember-Data “opinionated” approach.
Let’s talk about consume an API or interacting with a back-end more than 10 years old. Ember Adapter is highly configurable out-of-the-box. AngularJS? Has ngResource and ? Try to use it with different resources to fetch and you risk proliferation of chaos. Define models, define a way to interact and serialize an API, this is “non-opinionated” approach to me (it’s just an hyperbole :slight_smile: ).
Besides that, have you ever tried to embed an angularJs application inside a legacy PHP monolith? Well, with Ember is actually possible without messing with the URL rewriting. This, however, is my little experience on this topic.