Hacker News new | ask | show | jobs
by impressive 4672 days ago
At work we have been using Angular for about a year and we had evaluated Ember and decided not to use it because it wasn't really as good at the time. It may be better now, but I'm not as excited. Here's why:

1. For most applications, the JS MVC framework needs server-side backing, so don't fool yourself: You are no longer using MVC- you are using MVC X 2. There is no magic server-side out there that runs on self-generated jellybeans and weed that will power these frameworks. They are beautiful but unnecessary cruft in such pretty packaging that you think they are doing you a favor and washing your clothes for you. But they are only washing part of your clothes. The rest are still dirty and on the floor.

2. Despite the old saying, "Everything at some point will be written in JavaScript," it is not JavaScript, but rather mobile application development that is leading the charge in the development world currently. It is the platform and the accessibility (intuitive, easily held and portable), and not the "how" (whether it is webkit running Ember or Angular).

So, even though it is awesome that Ember and Angular are great, and I'm happy for you Yahuda, just like I'm happy for Misko/Igor/Vojta, I think this is a lot about only part of a solution, and it might not even be the right one. The whole package and the platform must be considered, not just the web client UI.

So, I ask, now that v1.0 is out, what is being done about considering the ease of developing the entire shebang?

1 comments

Ember Data and server-side components like active_model_serializers for Rails are working towards the entire shebang.

I agree that mobile development is driving a lot of this. If you've built mobile-first, then you already have an API that services multiple clients. And the web app is just another client, no?

So it makes me wonder, maybe what we need is the equivalent of Ember Data that runs on iOS and Android to bridge the gap between the API and the native framework.

This is the whole reason for formalizing the media type that ember-data expects into JSON API. That way, you can implement whichever side in whichever language and know it all works well together.