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.