Live data from Hacker News

Ember.js 1.0 Released

emberjs.com

81–90 of 104 posts

Re: Ember.js 1.0 Released

#81
post #34
post #6

I said this already on Twitter, but: It’s been 2½ years since I started working on Ember.js. While I’m proud of the code we wrote, I’m even more proud of the community we built. We have been lucky enough to attract the companies and individuals that are tackling the hardest problems in developing 100% JavaScript web applications; people for whom the only acceptable answer is solid engineering, not piles of hacks. As…

Thank you for this video! It nearly convinced me to build my first EmberJS app (I'm coming from a BackboneJS background and I haven't decided yet between Angular and Ember). Will you continue this kind of videos? Building a series by continuing the current "story" could be really really nice.

There are plans to have a "cookbook" section on the EmberJS site that will be one of the go to places to answer the question of "How do I do X in Ember?". It's currently on the master branch for the site, so expect that soon. In the mean time here are some other video resources http://www.embercasts.com/ and http://ember101.com/. They may be slightly out of date but they are still relevant. Make sure to look in the console for warnings about deprecations.

Re: Ember.js 1.0 Released

#82

Disclaimer: I am a backend developer sporadically doing front end to speed things up (as in: back end is done, time to help the other guys with the front end). Why is this better than jQuery? I haven't looked at the full code base and documentation but did watch the 25 min demo video posted in this thread and thought: "Well, I can do all of this with jQuery too probably just-as fast.". What makes this different? Am I…

JQuery is great, but it doesn't scale up well. Frameworks like Ember allow you to build bigger applications in an easy, clean way. JQuery tends toward spaghetti.

Re: Ember.js 1.0 Released

#83

After building some single page JS web apps small and large, I am not sure that building large JS web apps is actually a good idea. In fact, a lot of the time they probably aren't a good idea. It is often better to just build out separate pages and on a page that requires more interactivity, use knockout or something similar.

It really depends on the type of app you're building. If you're Twitter, a single-page app probably doesn't make a whole lot of sense, which I'm sure is why they backpedaled from that strategy. If you're Asana, then a single-page app makes a lot of sense. It has to do with just how many dynamic things you want happening on the page.

Re: Ember.js 1.0 Released

#84

Disclaimer: I am a backend developer sporadically doing front end to speed things up (as in: back end is done, time to help the other guys with the front end). Why is this better than jQuery? I haven't looked at the full code base and documentation but did watch the 25 min demo video posted in this thread and thought: "Well, I can do all of this with jQuery too probably just-as fast.". What makes this different? Am I…

Usually most of the people realise the need for this kind of tools when they are facing a need/requirement to develop a single page web application (SPA). If you don't need to make one then it's ok to use jquery or even add some PJAX to make your web site look more snappy. But if you have to develop a SPA, then you can't go far with jQuery because it just wasn't created for this type of things, you have to think about models, templates, about application state management and all other stuff, this is where frameworks like Ember and Angular shine.

Re: Ember.js 1.0 Released

#85

After building some single page JS web apps small and large, I am not sure that building large JS web apps is actually a good idea. In fact, a lot of the time they probably aren't a good idea. It is often better to just build out separate pages and on a page that requires more interactivity, use knockout or something similar.

I think the exact opposite actually. JS Web Apps are great. What problems did you run into that made you think otherwise?

I personally run into a host of issues, mostly relating to browser behavior that no longer works.

For example, 'text areas' that no longer trigger the browser's built-in spell checking. Or scrolling that works differently. Or keyboard shortcuts that are overridden. Or, a simple 'submit' button that no longer works because of a browser JS bug, whereas if it were just HTML it'd work.

I do like a lot of browser based apps too, but many of them have tons of annoying issues.

(Note: I mean JS SPAs in general, not Ember ones. Most Ember apps I know are pretty well behaved.)

Re: Ember.js 1.0 Released

#86

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-gen…

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 bri…

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.

Re: Ember.js 1.0 Released

#87
For the uninitiated, could someone please explain what we use Ember (and related frameworks like Angular.js) for?

For example, I build a Rails app to handle models, views, and controllers on the backend. Then I can use HTML/CSS/JS to write a frontend to interface with the Rails app. Why do we need another MVC framework on top of Rails?

Re: Ember.js 1.0 Released

#88

For the uninitiated, could someone please explain what we use Ember (and related frameworks like Angular.js) for? For example, I build a Rails app to handle models, views, and controllers on the backend. Then I can use HTML/CSS/JS to write a frontend to interface with the Rails app. Why do we need another MVC framework on top of Rails?

When writing a single-page app you only need a RESTful API on the backend, much like developing for mobile, to sync your models from the client.

Ideally, the models would be shared between client and server without the need for duplicating code. There has been a few steps in that direction in node.js, but it's an ongoing problem that hopefully we'll figure out in the next couple years.

Re: Ember.js 1.0 Released

#89
post #34
post #6

I said this already on Twitter, but: It’s been 2½ years since I started working on Ember.js. While I’m proud of the code we wrote, I’m even more proud of the community we built. We have been lucky enough to attract the companies and individuals that are tackling the hardest problems in developing 100% JavaScript web applications; people for whom the only acceptable answer is solid engineering, not piles of hacks. As…

Thank you for this video! It nearly convinced me to build my first EmberJS app (I'm coming from a BackboneJS background and I haven't decided yet between Angular and Ember). Will you continue this kind of videos? Building a series by continuing the current "story" could be really really nice.

If you're deciding between Angular and Ember, this video is a entertaining comparison with good examples - http://vimeo.com/68215606

Re: Ember.js 1.0 Released

#90
post #27

Earlier quoted context omitted.

There is nothing built-in but it would be straightforward to update your model data over web sockets. The magic of Ember bindings and observers will take care of the rest.

Saying it would be straight-forward is a little bit of an exaggeration. While, true, Ember will happily update any model pushed to it the difficult bit i.e. pushing the right data to the right model (on the right client) and only the right model to only the right client is an exercise left to the reader. The cleverness of Meteor is not in the push, it's in the logic just before the push.

I started down this path a month or two ago and you're right - it's actually quite a big job. I've been working on a real time system for rails / ember that moves all data over a websocket and allows subscribing to updates, however it has been very hard to get working with ember-data. I've currently have it running with my own (terrible) data layer but I would really like to get it running with ember-data again before I get it up on github.
Post reply on HN