I am about to develop a web application, and I need an MVC framework for the same, I started working with the SproutCore, but doing a few more research, I came to know about Ember.js also. I have seen a lot of post, where they are claiming that ember.js is much better than Sproutcore, but looking at the differences, I have seen that the widget support is not there in Ember.js.
I have seen some other post for differnces also between the two like Here, but I am still not getting it, when to prefer Sproutcore and when Ember.
It predominantly comes down to the design style of application you are after as technically there are many similarities because of their shared ancestry.
If you want a web application that 'feels' like a Desktop app I'd go for Sproutcore.
If you want your web application to be something more like Twitter, github or stackoverflow I'd go for Ember.
According to my history knowledge, sproutcore is the predecessor of emberjs.
Related
I'm planning on building a web application with an EmberJS front-end that talks to a Flask-based RESTful API. I was originally excited to get going with lineman to help tackle the front-end, but recently I've been introduced to ember-cli. Ember-cli seems to be much more tightly integrated with EmberJS, though it appears to be less fleshed out than lineman.
Does anyone have experience with both lineman and ember-cli? If so, do you see a benefit of using one over another?
I have recently inherited a non-finished web app written in Clojure, based on compojure and hiccup basically. It's a bad attempt to model some sort of MVC with OO style not in the FP style as seen here . So I bet to re-start the project almost from the scratch reusing the useful parts. I consider these alternatives:
The least breaking alternative would be Compojure+Enlive+jquery-pjax
Using a clojure web framework like Pedestal Any experiences about this?
The initial idea was to implement a RESTful API serving JSON so for the more elaborated solution I have Backbone+react.js in my mind for the front-end and Liberator for the back-end but it's likely to take longer to develop than a traditional server app.
Thoughts and alternatives taking into account that an Ajax experience is required please, thanks a lot!
I'm not sure what is the relation between RESTful API and responsive in your post. However ...
You have multiple options here: Pedestal, Liberator and Caribou.
If all what you need is a RESTful API, then I think Liberator is your best bet and it is not going to take longer time as you mentioned. I don't know how you got that impression.
Pedestal shines if you want to develop Single-Page applications but the framework in general requires a good time to grasp and understand how it is works.
Have a look at Caribou also. It is easy to use and feel familiar.
But again, it is your choice.
In the project I am working on, we are using ember.js (1.0rc1) without ember-data which is working out quite fine so far. The reason why we decided to go without ember-data is that we already have some utility methods to handle the integration with the REST interface, and over all because ember-data is not part of the ember.js.
From emberjs.com:
Currently, Ember Data ships as a separate library from Ember.js, while
we expand the adapter API to support more features. The API described
in this section tends to be stable, however. Until Ember Data is
included as part of the standard distribution, you can get your copy
from the GitHub page.
So, to my questions and the input I am looking for:
how much do we lose/gain with this approach? (besides the REST integration)
experiences of somebody that actually might have started also without ember-data, and now migrated to ember-data
maturity of ember-data and its integration into ember.js
And there is another question, which might rather be for the ember.js/ember-data devs:
what's the roadmap to integrate ember-data into ember.js and how strong will be the impact on the APIs?
Thanks for sharing your experiences and giving some hints and advices. // ph
I use ember-data in my project and I'm very pleased with it. I saves you a lot of time developing your own stuff for communicating with the server.
At this time ember-data is not officially production-ready but I use it already.
Read this on the emberjs website about ember-data. It says:
Without any configuration, Ember Data can load and save records and relationships served via a RESTful JSON API, provided it follows certain conventions.
We also understand that there exist many web service APIs in the world, many of them crazy, inconsistent, and out of your control. Ember Data is designed to be configurable to work with whatever persistence layer you want, from the ordinary to the exotic.
There is more information on the github page. There is even kind of a roadmap in it...
Another advantage is that you can define your Models with their relationships. It's also possible to use transactions which are giving you the ability to rollback changes if something went wrong at the server.
I really like the vision behind ember-data that it's not dependent on the kind of backend you use. Or where you define your relationships. If you use Mongo-db where you define the relationships on the parent object, where others do that the childs.
I'm evaluating ember.js with ember-data and meteor for a single-page web app.
So far my conclusion is that meteor can best be compared with a combination of ember.s and ember data while ember data takes the role of minimongo.
I really like the real-time sync of data with minimongo in meteor and would like to see this feature in ember.js. My question is whether we will see this or whether this is totally out of scope? Maybe there is a secondary lib or project which could be plugged in to have such functionality?
The question is pretty specific but I think for this topic any broader scoped contribution can be valuable.
Thanks
An ember-data store can be fed by many sources via adapters, one of which could certainly connect with web sockets. I prefer ember's clean separation of store from adapter to meteor's approach, which seems to require tighter coupling between client / server (I may be wrong here - I admittedly don't have experience with meteor).
You might want to check out Paul Chavard's (#tchak) colors-demo, a rails / ember / web sockets app that replicates the original Meteor demo. It's a quick proof-of-concept app and may be a bit outdated at this point, but it certainly shows that real-time ember apps are possible.
I have a pure REST rails backend and I'm working on the client side using Ember.JS I understand that ember-data is used for REST communications but I see it's not even in production does anyone know when it will be ready?
Or if there is a better solution that can be used?
To be fair, Ember.js itself hasn't actually reached a stable 1.0 version yet. From personal experience, I've only ever used the ember-latest.js because their tagged versions are usually so far behind the latest version, and there are too many things missing for me in their 1.0 pre tag. Even the API documentation on emberjs.com is for ember-latest.js, and the 1.0 pre API docs have been archived.
With that being said, as long as you are willing to dig through the new API documentation which is now quite nice, writing in Ember has been a fairly stable and consistent experience for me all summer. Ember Data has also been pretty good, but you have to look into the source code for most of the documentation.
Ember Data has by far the best REST adapter for Ember that I know of, especially because it is built specifically for rails. Look into Active Model Serializers. It almost makes building your API in rails a trivial task. It works perfectly fine for hasOne, hasMany and belongsTo once you understand the conventions explained in the readme for Ember Data. Many-to-many relationships should probably be decomposed into two hasMany relationships with a model in between.
In terms of when it will be ready, they intend to merge ember-data into Ember.js before the final 1.0 release. (source) They have both been stable enough for me though, and quite a number of companies who have already deployed ember apps. Backbone.js is at 0.9.2 and tons of people have put their trust in that, even though backbone doesn't really have something like ember-data.