iamstef

Additionally, rather then having a "virtualDOM" we build a tree of the dynamic data. This is more or less diff'ed similarly to how the virtualDOM is diff'ed.

But where it get interesting is when it comes to actual DOM interaction. To create DOM, we use document fragments + cloneNodes, but for granular updates we utilize property/attribute/textContent updates. When used correctly, this combination turns out to be very fast.

As a bonus, we are typically able to utilize the browsers built-in XSS and sanitization (or just lack of parsing) rather then having to implement this slowly in JavaScript ourselves.

Ultimately, I am extremely happy with how the various front-end frameworks keep pushing the envelope. Getting faster, easier to use, and more secure. Ultimately regardless of the framework the ecosystem moving forward benefits the end users the most.

My experiences may be biased, but most startups I work with have target audiences that do not include tin-foil hatted JavaScript disabling individuals.

To the contrary, for them investing any energy in servicing this minority would be a mistake.

I suspect their exists some subset of startups were this may be reversed. But they are absolutely in the minority.

One hard part becomes synchronizing ephemeral UI state between client and server. Such as data not-yet saved, or various UI components that are toggled into some sensible state.

As the complexity increases, this problem explodes.

One can use local storage (when available), but unfortunately this isn't always available, or needed.

Another thing you can do is bounce state back & forth with requests. Unfortunately this becomes a synchronization nightmare.

It is extremely nice to allow ephemeral UI state to remain in the UI. Merely syncing non-ephermal state, and populating a client side pool of data that is quickly addressable, and thus "instant" from the perspective of the UI.

Mitigating the latency of mobile networks is key here, no latency due to data-locality is the only way. Short of Quantum entanglement Physics isn't on the side of server-side rendered experiences.

> Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript.

I think we can all agree, maintaining two discrete code-bases is a sub-optimal experience. Especially for companies without the resource of the "big names" you point out.

> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast?

Several reason why this experience results in a faster mobile experience.

- cached data serves extremely quickly ;) - pre-emptively loading data to prime the cache. - data is smaller then data + html. - the app remains usable during loading phases.

Additionally, separating the concerns of rendering and data loading, does afford more creative optimizations as the need arises.

pulse typically gives a good indication. https://github.com/stefanpenner/ember-cli/pulse

I believe you are reading into this incorrectly. The title of this post is "How to discourage open source contributions" not "The responsibility of open source project owners".

If you are not interested in contributions to you project, then you are not the intended audience.

Some thoughts supporting the post:

As a contributor I view my contributions as an investment, if my contribution is likely to help others I will be more motivated to contribute. If unfortunately it looks like my contribution will merely idle, I will consider alternatives. Quick-patch my fork and move on, switch to another project that is well maintained or if the project is critical to my work, I may offer to maintain it.

In addition, I will more likely to go above and beyond in my contribution if the project is well maintained and the likelihood of my work landing in the mainline is high. As a maintainer, a positive correlation exists between active maintenance and community contributions.

Author of ember-cli here (and previously the maintainer of ember-rails), this is essentially how my team uses ember-cli at work. Purely as a development harness and deployed to work nicely alongside a rails app.

One of my co-workers has a great related talk: https://speakerdeck.com/lukemelia/lightning-fast-deployment-...

And another related blog post: http://blog.abuiles.com/blog/2014/07/08/lightning-fast-deplo...

I suspect we will want to migrate the ember-rails story to be officially more aligned with the above approaches.

it has!

unfortunately TS currently has many mis-alignments with ES6, hopefully this improves someday.

these are happy-path guidelines and as such, quite easy to diverge from when needed.

i would like to see two jQuery plugins work harmoniously with each other :P

I believe your concern is a valid one, end-points of single page apps should respect authorization requirements, and assume the client is always compromised.

Unfortunately, I believe you may have missed the point of this library and blog post. It merely simplifies the developers life when implementing the client side flows and interactions associated with authorization with one or more auth providers.

This does not preclude proper API authorization or loading sensitive modules post authorization from an authorized end-point.

As someone who has implement many very related flows, I am glad to see an effort to unify, share and simplify this experience.

not yet, but keep a close watch -> http://confreaks.com/events/emberconf2014

I think discourse handles this fantastically well!

It may not be complicated, but it really comes out of left field. It really lacks context

o_0) .... walks away slowly....

ya, grunt tends to suffer from an massive explosion of complexity

I would be an advocate of this.

But.. competition is healthy, I am glad we are getting some great solutions in the space.

fast builds isn't the entire broccoli offering, I would trade slow builds for accurate consistent and durable builds, amazingly with broccoli I get both.

I actually do not believe grunt/gulp vs broccoli makes terribly much sense to compare as broccoli aims to be a accurate/stable/fast build pipeline, it does not aim to replace your task runner. It's primary goal is to be the best possible build pipeline, and should be programmatically accessible to your existing task runner.

Anyways, since I didn't really compare grunt/gulp with broccoli, let me explain what you get:

* primitives make sense, was able to get a fairly non-trivial or ordinary pipeline setup really quickly

* builds so fast, you don't notice them.

* accurately handles changes (deletions and git branch changes tend to often cause similar tools issues)

* doesn't lose changes that occur while building

* true pipeline. eg. describe the transforms, and the system handles the rest. No needing to construct make-shift pipelines yourself

* immediately usable as server (error reporting, locking)

* development builds.

* minified source mapped production builds.

* the Broccolifile API is well suited for constructing custom piplines

And finally:

the above you essentially get for free, if you need customizations the Broccoli file provides are an API well suited for the task.

Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it.

It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.

First JS build tool I've used, that I have been actually immensely impressed with. Manages complexity really nicely, and does so that delivers immense value.

Porting all my projects to it as time permits.

seems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"

its still WIP, once they provide framework authors with what we need, rest assured ember will land it.

We are actually working close with the firefox and chrome teams, to drastically improved general JavaScript developer ergonomics when debugging.

Ya, I use ember-data when its appropriate, and not when its not.

Your concern is noted, and is also a concern of ours. Rest assured the ember-cli will only be a small veneer providing a curated experience of community tools.

The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.

I am glad angular (which has no data-layer) satisfies your needs :)

Many of us are currently using a grunt-based system, see: https://github.com/stefanpenner/ember-app-kit

The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.

Fun obfuscated version in ruby.

https://github.com/stefanpenner/obfcuscatedLife.rb/blob/mast...

and for those crazy people who ever far to trusting:

  curl https://raw.github.com/stefanpenner/obfcuscatedLife.rb/master/game_of_life.rb | ruby

imagine a bouncer that correctly keeps all your clients in sync. e.g. read vs unread.

In addition to this they have a fantastic iOS client.

firefox os competitor?