machty

What kind of "consistency" do bm25 indexes offer? e.g. I think ElasticSearch is eventually consistent and is constantly indexing in the background and classic Postgres GIN indexes have configuration like `gin_pending_list_limit` and `fastupdate` functionality to avoid slowdowns on insertions (and then you get slowdowns when an insert hits the threshold and triggers the catch-up indexing).

Could the "connect" token just be a JWT token?

poop.bike is still up

I haven't been on the core team in months

Flux is that alternative.

The problem with this is that whatever you require() won't close over other variables/imports unless your preprocessor is straight up compiling JSX into JS and inserting into another JS file, which is kinda gross and eval-y.

If the rule is a) designers only touch .html/.hbs files and b) only developers touch the view/controller .js files, then if either of them change a property name from `{{displayName}}` to `{{display_name}}`, the whole thing breaks, which is the coupling React is trying to avoid by keeping these similar concerns within the same technology/file (JavaScript).

Because it's such a thin layer over JavaScript, you don't have to port/reimplment all the stuff that JavaScript has already solved to your templating language / abstraction of choice. I still prefer Handlebars, but JSX elegantly sidesteps lots of issues at the expense of not actually being real HTML and handling flow control stuff somewhat awkwardly, but you really gotta try it out to get a feel for the tradeoffs.

It will be in 1-2 weeks at https://www.youtube.com/user/EmberNYC

There are heuristics to prevent recursing into obviously-removed/added elements (using component type and keys), but aside from that, there's always going to be a tradeoff between frameworks/libs that choose to track this granular information to know exactly where a change originated and what needs to be updated, vs libraries like React that don't set up any sort of observers or have any sort of knowledge about where the change originated from, and React has demonstrated that their approach is pretty fast due to the fact that live mutable DOM manipulation is the bottleneck and not purely JavaScript traversals.

My point is that the React marketing is "top down unidirectional data flow", and that you quickly reach the end of what you can do with that before needing to add a another perpendicular uni-directional data flow (which is Flux or one of its variants), which breaks the vanilla React paradigm and many of the simplifying assumptions implied within such a simplified system. Two flows, both uni-directional, but in different directions, and the top-down flow no longer has anywhere near the same degree of control once you've added Flux to your system.

Tasks are a more general concept; one of the many possible tasks you could program would be to build your project.

I think you mean phobe

Broccoli looks like little trees. I wanted them to be called `Brocfile`s. Who's with me?

Ember's approach to watching for changes is pretty different. Also, the Ember view layer refactor codenamed HTMLbars has yielded some extremely promising (though admittedly early/premature) performance improvements that often outperform the React equivalent. So we're open to the idea and we have much we can learn from each other but we're not going to merge in React if we can do a better job :)

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides.

It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you haven't had to solve major problems with navigation, routing, complex nested async logic, etc., for the particular app you're trying to build, then it sounds like React would get you most of the way there, but even the React team themselves realize that for medium-large scale apps, React's only going to take you so far.

Re. Haml: try emblemjs.com

Most folk would consider that "dropped", no?

It's Linux, written entirely in Angular directives.

It is possible, and just as easy with Ember.

Keep in mind that Computed Properties are also part of the solution to intelligent, efficient data-binding. CPs in Ember are cached and quite efficient and because they are aware of their dependencies, much of the computation that would otherwise need to go into a dirty-checking approach to data-binding can be avoided. So, Uniform Access is part of it, but I would advise against scrapping an initial implementation of your app using CPs on performance grounds considering that data-binding is the main performance bottleneck in Ember (and Angular).

getters + defining `first` and `last` as Computed Properties would solve this problem

"allowing you to have some pages that use it and others that don't"

Your response seems to dig into a different (though related) issue. If the question is whether, given a whole website, whether angular/ember can exist only on certain pages, but not all pages, then the answer is Yes.

Ember yes.

Yes. Both Angular and Ember support this pattern pretty effortlessly.

I just linkified everything, should be good now

I just added this to the slides (ran out of time to prepare/say all the things I wanted to), related to Google popularity:

- A toolset’s mindshare is predictably going to be greater than that of a framework

- Angular interest (per Google) dwarfs Ember; jQuery interest dwarfs Angular, etc

- Angular encourages you to build the framework; Ember is the framework

Angular folk are often quick to point out that "Angular isn't a framework; it's an HTML compiler", or, as their homepage states, "AngularJS is a toolset for building the framework most suited to your application development." Angular doesn't necessarily set out to solve all of the problems and use cases that developers might run into, but rather Angular intends to give you all of the proper data-binding, dependency injection, and testability primitives as a foundation to build your app upon.

Because it doesn't intend to solve all the problems that a framework might, Angular is far fewer conventions about how to organize large-scale applications than a much heavier and opinionated framework like Ember. This doesn't mean Angular doesn't scale, or that it can't be used to build large apps, but it does explain why it's common for different teams to build large Angular apps in totally different ways, using different patterns, etc.

Ember on the other hand sets out to establish way more conventions, built right into the framework, for solving problems common to most web apps. These patterns are rigorously battle-tested since everyone is using them, and as such, it's easy (once you're past the learning curve), to drop into someone else's Ember app and know exactly where to go to diagnose a problem. That being said, when these patterns aren't helpful for an app's specific needs, most of Ember's patterns/abstractions are, like Angular, built upon composable primitives that you can use to assemble your own data structures, custom classes, etc., to tailor to your app's needs.

It is a little comical that this post comes out a day after one of the greatest community-driven races to the 1.0 finish line from Angular's chief competitor.

Congrats to the badasses at GroupTalent. This looks great!