Hacker News Reader

No, but that's a great idea. Do you have any recommendations for a host that can serve up files of this size?

Ember.js is released under an MIT license: https://github.com/emberjs/ember.js/blob/master/LICENSE

Use it however you'd like; contribute back if you want to.

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 we mention in the blog post, Ember.js went through a reboot midway through its life when we realized the thing we were building was not the thing that needed to be built. If you tried Ember.js previously and had a bad experience, I'd really encourage you to give it a whirl again. We've smoothed over the rough surfaces, and now have the documentation and community to help you get started.

If you'd just like to take a peek at what building an Ember.js app is like, I recorded a ~25 minute screencast that takes you soup to nuts:

https://www.youtube.com/watch?v=1QHrlFlaXdI

Lastly, I'd like to express my personal gratitude to everyone that pitched in at the 11th hour to get this release out the door. I couldn't be more proud to call this awesome group of developers my friends.

tomdaleon Angular or Backbone: what are startups using?

I should also call out that many of the above (Travis, Discourse, and Balanced) are all completely open source. They serve as a great learning resource for other companies building seriously ambitious apps.

I'm still on the hunt for a large, open source Angular app to see how their primitives scale up to solve more complicated problems. If anyone knows if such a thing exists, I would appreciate you pointing me in the right direction.

tomdaleon Angular or Backbone: what are startups using?

If you want to meet these folks in person, come by our meetups. Both the SF and NYC meetups routinely have attendance of 120+ people; it's like a mini-conference every month.

tomdaleon Angular or Backbone: what are startups using?

Not sure about the methodology here. In addition to having my own startup using Ember.js, I'm constantly meeting with other startups building their business on it:

* Discourse

* Travis CI

* Practice Fusion

* Nitrous.io

* Embedly

* Balanced

* Customer.io

* Addepar

Not sure if you count other places like Square or Zendesk as startups, but they're using it too. We've also seen big companies like McGraw-Hill Education start building out their next generation technology using it.

You can find a longer list of users here:

http://emberjs.com/ember-users/

tomdaleon Show HN: Yoleo – A Beautiful RSS Reader

Looks like it's written in Ember.js—nice!

tomdaleon Ember.js 1.0 RC4 released

Thank you for your well-reasoned comment. However, it sounds like you're basing your opinion on some misinformation. That's okay, it happens to everybody. :)

Ember.js is extremely future-proof. Yehuda Katz, who I work with on Ember.js, is on both the W3C and TC39, the committee designing the next version of JavaScript. Needless to say, we have a pretty good idea of what's planned for the future of the web platform; we're also very involved with the standards bodies to make sure it is as powerful as possible for building web applications.

Setters and getters are a trade-off. While we'd prefer not to require them, the alternative is that you have to diff objects every time a change happened. And not just a change, but a possible change—which means in response to almost any event. By using getters and setters, we avoid this particular performance footgun.

Actually, Ember views have much more in semantically common with Web Components than Angular directives, despite the fact that many people like to repeat this misinformation. For more, see this thread on Google Groups: https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...

tomdaleon Ember 101: Learn Ember One Video at a Time

You can always find the latest build of Ember Data here: http://builds.emberjs.com.s3.amazonaws.com/ember-data-latest...

tomdaleon Why I love Ember.js

I'm glad that, unlike the previous comment thread, you decided not to refer to Ember as "the North Korea of the JavaScript world."

However, what you're doing here might best be described as presenting a series of "loaded questions." You can find out more about this logical fallacy here: https://yourlogicalfallacyis.com/loaded-question

I'm sorry that you feel the need to attack Ember. If you have any specific complaints, maybe we could discuss them over a beer?

tomdaleon Why I love Ember.js

Thank you for the detailed feedback. Working on Ember Data has been one of the most challenging efforts of my career, but I think that it has the opportunity to dramatically change how people write web applications. Once we've stabilized it, of course. :)

Here are the specific steps we're taking to address your concerns:

1. Thanks to a pull request from Stanley Stuart[1], we now automatically publish builds of Ember Data[2] every time a new commit is pushed that passes our suite of tests.

2. We have begun documenting Ember Data[3] and, while not exhaustive, what we have now is significantly better than just a little while ago. As with what happened with Ember.js, we take documentation very seriously and you should see the Ember Data documentation improve dramatically over time.

3. As we outlined in a recent blog post[4], we are focused on stabilizing Ember Data and do not have plans for new features at this time. If we made a mistake in the initial API design, it was not providing enough imperative trap doors to use when the declarative APIs were not sufficient. We are working on fixing that.

Thanks to our friends at Addepar, we are able to dedicate several full days per week to Ember Data and you should see the velocity of the project increase significantly. Many observers have noticed the recent flurry of commit activity[5]; this was not an aberration but an indication of what the future holds now that we have daytime hours to dedicate to it.

If you have specific suggestions for how to make Ember Data as approachable as possible, please let me know. Like I said, my focus right now is on eliminating bugs, stabilizing APIs, and making sure new developers don't hit frustrating rough spots.

1: https://github.com/emberjs/data/pull/850

2: https://s3.amazonaws.com/builds.emberjs.com/ember-data-lates...

3: http://emberjs.com/guides/models/

4: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.ht...

5: https://github.com/emberjs/data/commits/master

tomdaleon Ember 1.0 RC2

Ember Data is overkill for many use cases.

It may seem counterintuitive, but because Ember's object model is so powerful, you don't need a lot of the model-specific sugar that other libraries provide you—it's baked into every object.

To see how easy it is to fetch records using the tools in Ember, see Robin Ward's blog post: http://eviltrout.com/2013/03/23/ember-without-data.html

tomdaleon Callbacks are imperative, promises are functional

James does a good job of articulating why promises are such a useful abstraction, especially in JavaScript land. I've been working on a project recently that relies heavily on coordinating many asynchronously-populated values, and I don't even want to think about what the code would look like if we were wrangling callbacks manually.

We actually extracted our promises implementation from the work we've been doing, and released it as RSVP.js[1]. While other JavaScript promises libraries are great, we specifically designed RSVP.js to be a lightweight primitive that can be embedded and used by other libraries. Effectively, it implements only what's needed to pass the Promises/A+ spec[2]. For a comparison of RSVP.js with other promises-based JavaScript asynchrony libraries, see this previous discussion on Hacker News[3].

1: https://github.com/tildeio/rsvp.js

2: https://github.com/promises-aplus/promises-spec

3: https://news.ycombinator.com/item?id=4661620

tomdaleon Stabilizing Ember Data

Thanks for the suggestion! In fact, you've just described exactly what we're building. We are big fans of REST, and if you read the documentation, you'll see that the default behavior of Ember Data is to transmit RESTful JSON[1].

In addition, we've been working with a bunch of really smart Rails people like Steve Klabnik and Santiago Pastorino on projects like ActiveModel::Serializers[2] and rails-api[3].

That being said, we know that there are a lot of different ways to serialize and transmit records, so we've designed the architecture of Ember Data such that those decisions are encapsulated in specific objects which we call adapters. You can think of it like the adapters for different databases for ORMs like ActiveRecord.

The default adapter, though, is RESTful JSON, and is what we use in all of our applications. You can see the implementation on GitHub[4].

1: http://emberjs.com/guides/models/the-rest-adapter/

2: https://github.com/rails-api/active_model_serializers

3: https://github.com/rails-api/rails-api

4: https://github.com/emberjs/data/blob/master/packages/ember-d...

tomdaleon Why we're moving away from Ember.js

Your comment history indicates that this is a troll account, but I'll reply in case a bystander takes your post seriously:

Ember is actually composed of many smaller, independent packages. For example, we built four microlibraries for use in Ember that you can use totally independently: router.js, route-recognizer.js, rsvp.js and metamorph.js.

Additionally, many people use other great projects from the JavaScript ecosystem to do Ember development, like D3, Crossfilter, mocha, Jasmine, etc. Your assertion that it does not work together or integrate with other tools is 100% false.

tomdaleon Making EmberJS Easier

This is a copy-and-paste version of what you said yesterday.

https://news.ycombinator.com/item?id=5411929

For what it's worth, the SproutCore 2.0 project became the Ember project (see http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...). SproutCore 2.0 was a brand-new codebase, which was renamed to Ember.js.

tomdaleon EmberJS Confuses Me

Yes, Edward Faulkner has used Ember heavily and was one of the original contributors back when we started the project.

tomdaleon Client-side MVC is not a silver bullet

You're quoting from the Ember website but your bad experience was with Backbone.js. In fact, Ember is designed to avoid the kind of deficiencies you hit in Backbone. Sounds like you should give Ember a try in your next app. ;)

tomdaleon Why Discourse uses Ember.js

Great post.

Client-side web applications have come a long way in the past year. In the comments I read when Discourse was released, many people dismissed out-of-hand rich JavaScript apps based on stale information.

For example, they assumed that infinite scrolling would mean you would lose your place when hitting the back button. They also assumed you would not be able to command-click a link to open it in a new tab.

Surprisingly to many, both work just great in Discourse; try it out if you don't believe me.

Many people also held on to the belief that JavaScript apps are fundamentally incompatible with assistive software; that one is also a common misconception that's just not true anymore. Steve Klabnik wrote up a great overview of it[1].

[1] http://words.steveklabnik.com/emberjs-and-accessibility/

A lot of people pan client-side apps as being slow and bloated and overloaded with JavaScript. Surprisingly, they don't have more than your average full-featured, server-side web application[2][3]. And I think Discourse proves that you can build large apps that feel lightning-fast.

[2] https://twitter.com/tomdale/status/300653212472598528

[3] https://twitter.com/tomdale/status/300653225785311232

If you investigated building apps like this in the past and didn't think it was ready, now is a great time to give it another shot. The tools are maturing rapidly, and while still not perfect for every use case, we're knocking down limitations every day. I'm excited for all the cool stuff people will build in 2013.

tomdaleon StackExchange Founder Vows to Reinvent Online Discourse

Threaded comments—like here, on HN, and on Reddit—easily spiral out of control. It's especially hard to come back later and see what's new.

Many people seem to have missed this, but Discourse solves the problem in a particularly elegant way. Each topic is about, well, a single topic. The conversation flows as a series of replies, ordered chronologically.

If, however, you'd like to change the topic, there's a "Reply as New Topic" button to the right of every post. This allows you to create a new thread, with a new topic. Metadata about this forked topic is saved, so that future readers can easily bounce between related threads, while still having every message in sequence about the same "topic."

In my experience, this approach maintains the simplicity of flat discussion with the ability to fork topics of nested threads, without the complexity.

tomdaleon Civilized Discourse Construction Kit

I've been beta testing Discourse for a few months now, and can tell you that this is going to have a huge impact on how we have discussions online.

Jeff Atwood has more insights into how humans communicate in an hour than I do in a year. Those insights are built right into the software, and I think that will help many communities take off that would otherwise collapse under the weight of trolls and apathy.

On a more selfish note, I'm excited to have an open source Ember.js app available from two of the best JavaScript developers in the world—Robin Ward and Sam Saffron. It's a great resource for the Ember community. If you haven't yet, make sure you head over to GitHub and check out what a modern Ember app looks like.

tomdaleon Migrating from Ember.js to AngularJS

The Angular guys are incredibly smart (and good looking) and I am not above stealing their good ideas for Ember. It's great having skilled competitors, because it drives us both to build a better product.

I hope you didn't find any personal attacks in my response. I want to be firm about the fact that the article contained gross inaccuracies.

I welcome criticism of Ember.js; as with any open source project, there's plenty to criticize. I would just like that criticism to be accurate.

tomdaleon Migrating from Ember.js to AngularJS

Not to start a flame war, but I'm not sure this is a plus. Full unit coverage is nice for confidence, but can be balls and chains when it comes time to make changes.

Ask any of our pre-1.0 users; they'll assure you that the pace of change was breakneck and certainly not hindered by our unit tests.

tomdaleon Migrating from Ember.js to AngularJS

The API has been frozen and we're very close to our 1.0 release. The advantage of changing APIs frequently before 1.0 is that you get a much better product. I'd love it if you reconsider Ember.js and take another look now that it's stable.

tomdaleon Migrating from Ember.js to AngularJS

While there's great feedback here, it's interspersed with information that is either outdated or just flat-out inaccurate.

Overall, Angular is a much more extensive framework than Ember.

I don't think this is true. For example, AngularJS, as far as I'm aware, does not offer a persistence story at all.

Injection and testability.

Ember.js does dependency injection too; we just roll it into our conventions so that new developers don't need to learn what dependency injection is. If you have to learn a ton of comp sci terminology to start learning a framework, they blew it.

Additionally, Ember is fully unit tested (over 6000 unit tests at the moment) and, because of dependency injection, loading up your app in a clean state and testing individual components (models, views and controllers) is easy.

Support for partials and inclusion of templates. This is another thing I really missed with Ember.js, which offers no easy way to break down your HTML templates into smaller, more manageable files.

This is just flat-out inaccurate, and has never been true. Ember has supported breaking up templates since day one.

Documentation. While the Ember.js documentation is fairly large, I found it very unorganized and I often resorted to searching the page to find what I need.

This has been fixed and the response has been overwhelmingly positive. We still have a ton of stuff planned to make it even more friendly for beginners.

Cascading updates are being executed right away.

This is simply not true. In fact, Ember's run loop is what powers many of the nicest features, like deferred DOM updating and binding synchronization. I'm a little bit surprised that other JS frameworks haven't copied the idea, to be honest.

You need to remember to call the setter: object.set('foo', newValue)

I agree that this is not ideal, but the flip side is that frameworks like Angular have to iterate over every bound object when something in a scope has changed, and check it against previously known values to determine if a change has happened. This "dirty checking" can quickly lead to pathological performance issues. We're all about ease-of-use, but not when it turns into a footgun.

As you might be aware, Yehuda Katz is on TC39 (the committee developing the next version of ECMAScript). ES6 supports object proxies, which provide sufficiently rich semantics that we will be able to drop the get/set requirement if you are targeting ES6 browsers. We are ready to add this to Ember as soon as proxies land in popular browsers.

It's actually disappointing how much FUD is in this article. Competition is great, but let's deal with facts.

tomdaleon Turbolinks and the Prague Café Effect

There's another use case that is just as important in my opinion: offline mode. The Turbolinks folks would argue "you are not on a fucking plane"[1], but I have been on a plane and wanted to access things like GitHub issues.

The architecture that allows JavaScript apps to win the "Prague café effect" also makes it possible to write web apps that are still useful without an internet connection, so long as the user has downloaded some information in the past.

DHH has said that things like Turbolinks are "a stop-gap on the road to having persistent JS runtime across page changes"[2], and I think he's right. The tooling is still very immature right now, which is why people like Turbolinks: it fits into an extremely well-polished workflow. But I'm excited about the next few years, as frameworks like Ember and Backbone reach the maturity of server-side frameworks.

[1]: http://37signals.com/svn/posts/347-youre-not-on-a-fucking-pl... [2]: https://twitter.com/dhh/status/281432076199280640

tomdaleon Rant: Backbone, Angular, Meteor, Derby

As someone who has sacrificed his last few weekends and holidays writing documentation for my open source projects, I can assure you that that is not my attitude, and the fact you think so is very disappointing.

tomdaleon Winning is the worst thing that can happen in Vegas

Where is this strong reaction to over-design coming from? Full disclosure: I earned most of my salary in 2012 doing consulting. Fortunately, most of it was from working on open source projects. But a component of it was going in and getting our hands dirty in clients' apps.

Not a single one suffered from over-architecture; indeed, the common thread to all of the problems I saw is that people would intentionally put off the "just in time" architecture improvements that DHH recommends in favor of just one more feature.

By the time we got there, the whole thing was about to collapse under its own weight.

And that's exactly my point: this seems to be a solution in search for a problem. Under-architecture is much, much more widespread of a problem than over-architecture, based on my own anecdotal experience and the horror stories told by my friends over beers.

Software engineering is about striking a balance between choosing an architecture that can grow with your project while being simple enough for you to ship features today. The dogmatic approach from both sides in this ideological war is bizarre. Remember that prescriptivism against prescriptivism is still prescriptivism.

tomdaleon Show HN: Ember Table by Addepar

It seems like the only thing they are using from Underscore that's not already in Ember.js is Function.bind; I'm totally open to adding it to Ember.js proper.

tomdaleon Show HN: Ember Table by Addepar

I'm not trying to beat a dead horse here, but the two really do not share much architecture, especially when it comes to the view layer. The only place where the two started out looking similar is in the object model, and even that has evolved so much in Ember.js they only look the same if you squint.