iamstef

I immediately checked for EV and was stoked to see it!! I haven’t played that game in decades…so many good memories. SOL?

Time to find a new gig.

Starting fresh somewhere else with no reputation, no karma, and the potential for being the small fish again will pay dividends.

At the very least, different social and organizational challenges may exist there and allow you to grow in a different light.

(also, be sure your enjoying non work-related hobbies and adventures as much as you can. Life isn't just work)

Nice, this was super timely as I was literally building the same thing. And I had just reached the part where I was annoyed that all the submitted videos had different shapes and sizes which as you know would be tedious to correct manually.

You for sure saved me some time!

I would be interested in seeing your script if you don’t mind sharing

Literally the worst

history doesn't repeat itself but it does rhyme...

I know atleast one of these companies (I can't speak for the rest) had a pre-existing bi-lateral patent agreement with Facebook which rendered the react patent clause irrelevant, allowing them to use react without concern. Without that existing agreement this would not have been the case.

don't forget travis-ci's web frontend:

repo: https://github.com/travis-ci/travis-web site: https://ember-canary.travis-ci.org/emberjs/ember.js/builds/1...

It even has a version that tracks commit by commit right off ember#master https://ember-canary.travis-ci.org/emberjs/ember.js/builds/1...

At the same time though, when I used Chrome's built-in memory profiling I see a bunch of deopt-related strings, so maybe I'm way off base

In my experience, these add up real quick and are often indicators of a larger "instability" issue that remains well after the "deopt churn" appears to settle, but continues manifests in the form of some heavy GC.

Note: many internal structures related to the JIT (IC/hidden classes/code gen etc) can themselves cause sufficient GC pressure, as can the code you described as "de-opted permanently".

Interestingly it is also possible for the above mentioned GC pressure to itself cause some fun (even more GC pressure): https://bugs.chromium.org/p/v8/issues/detail?id=5456

This may not be the root of your issue, but I would be careful to rule it out entirely to quickly.

Anyways, best of luck!

You may want to give the follow script a try:

* https://gist.github.com/krisselden/d3ce3cbb37cc6035b0927fdbf...

It flips some handy flags providing useful output, this output can quickly illuminate issues the regular tools do not (yet).

Running this on the example you linked to bellow, shows that a series of functions are deopting and optimizing repeatedly. most likely causing at-least some of the sawtooth pattern you see.

example output (likely related to the problem):

  ```
  removing optimized code for: r.getViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r.getViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r.getViewMatrix]
  ```

note: Credit for this should go to @krisselden the author of the above gist not me.

and its easily swappable: https://github.com/switchfly/ember-cli-mocha (and fully integrates with the existing test harness, regardless of the test framework you choose.)

Abstractions aim to hide complexity until one requires them.

As a developer, one becomes productive when one realize when to put the blinders on, and when to take them off. As such I for one, love that I don't need knowledge of x86 assembler, chip design, or signal processing until the problem at hand actually requires them.

Ember-cli aspires to keep developers focused on features, not orthogonal tech. That is unless they need to peel back that layer of the onion, and dive in. Even then, the goal is for only a few community members to dive in, explore the problem space, and ultimately contribute the solution. Next release, all community members benefit, without also having to invest (until the point where they have a specific itch to scratch).

Abstractions hurt when they leak, as such we must aspire to provide the best abstractions we can (at each layer), and this is only possible in collaboration with an eager and enthusiastic community.

An symptom of a curated solution, is all aspects of the stack evolve to work together. Mitigate abstraction leaks at the various boundaries.

As someone who is:

* OSS user (and signee of the Dear Github letter)

* paid user

* user of an enterprise installation of Github

I can honestly say the problems I see in OSS land, are the same shape as those in paid, and the enterprise installation. The difference is, due to the volume of usage the enterprise installation suffers from these same issues even more.

Now, we may not see +1 DOS often (on the enterprise side of this), largely because its seen as bad manners and/or the goals are already shared via some other disjoint medium. But this doesn't mean the issue isn't present.

Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win

Handlebars (Ember's templating engine)

Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.

First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience.

https://fnd.io/

Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)

I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.

Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.

PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.

As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.

The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.

This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.

The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.

Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.

Yes, by introducing (extremely handy) syntactic sugar ;)

I agree, async/await is very nice. Though it is worth pointing out async/await is quite literally syntactic sugar on top of promises. Essentially adding language syntax for common promise idioms.

Very nice, good work!

The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions.

As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;))

I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.

Our friends at http://www.bustle.com/, http://vine.co/, and twitch.tv (http://www.twitch.tv/directory/) ... (lots more) have demonstrated this to be acceptable for there needs.

Traditionally those sites may have also consider I am sure they will continue to be happier as the byte size shrinks, but in the interim they are able to deliver what appears to be a great user experience, in-light of your concerns.

and shrinking :) We have some fun related work planned to continue the shrink.

One thing to note, often we must trade-off bytes for supporting older features. As those go away, we shrink. But moving forward the plan it to have more of a pay-as-you-go model. Utilizing ember-cli to do the r.js optimize esq step, to strip unused portions etc.

Nothing ground breaking, its tried tested and true in many other ecosystems. But when it lands it will provide nice value for our ember apps.

TL;DR We will be following with a new CLI shortly shortly

more details commented here: https://news.ycombinator.com/item?id=10054332

one of the ember-cli maintainers here.

CLI will be following closely with a relevant release. To ensure trying ember 2.0 is as smooth as possible.

my apologies for any lag between the two project releases.

For those interested (or concerned) the CLI is not coupled to the ember versions, it actually enables interested users to switch between versions. Obviously we believe in more curated experience (hence the in-bound CLI release)

We take advantage of this version switching via https://github.com/kategengler/ember-try which enables ember-addons to automatically test against multiple relevant versions of ember.

see ember-meterial-lite travis run as an example https://travis-ci.org/mike-north/ember-material-lite

its not creating a promise that is the problem, its consuming.

Async/await really is a nice sugar, check it out when you have a chance.

The problem usually arises when the GC pressure introduced from the promises (often the intermediate promises) created by many active/concurrent tasks starts burning copious amounts of cycles.

As your concurrency increases, a poor promise implementation starts burning copious amount of valuable cycles, often largely due to GC pressure.

In the abstract this doesn't sound that bad, but when comparing well behaved implementations such as BlueBird, RSVP, When, ES6-Promise etc. with the current state, (July 3, 2015) native Promises, the difference is still staggering.

As for the browser, a promise is a great way to handle async and often a great abstraction around a single potentially remote entity. As more ambitious applications are created, it isn't uncommon to have thousands or tens of thousands of these remote entities. Wouldn't it be nice, if the overhead of using the promise was negligible?

Although everything you say is true, your comment doesn't really add much value.

As you mentioned, micro-benchmarks are riddled with bias, and confusing results.

So putting micro-benchmarks aside and looking at ES5 / ES6 induced performance bottlenecks in actual apps, they are clearly present. (note, this is of-course limited to features actually implemented)

Unfortunately, a macro focused endeavor (only gauging full app performance) isn't as nicely actionable as the micro.

So in practice, in an attempt to produce high value but actionable feedback a hybrid approach, utilizing both micro/macro investigation yields the best results.

In addition the micro-benchmark vs optimizing compiler trap can be mitigated by investigating the intermediate and final outputs of the optimizing compiler.

Anyways, /rant.

There exist an unfortunate amount of JS performance traps, I wish where taken more seriously. Although more work, it would be quite valuable for someone to perform a root cause analysis to investigate potential bottlenecks brought to light by this post.

This isn't entirely accurate as ember essentially diffs the dynamic values, but not DOM (or vDOM). In Ember the DOM is typically produced from pre-compiled templates and values are used to hydrate those templates or choose which templates are rendered.

Obviously exceptions exist, but this is by far the most common scenario.

When ember goes to "Detect" what changed, is basically ignores the DOM, and looks at the dynamic joint values such as {{#if firstName}} or {{lastName}}. Using this information, in then decides what DOM mutations are needed to bring the DOM back into sync.

As a side note: Babel.js has some related optimizations for JSX/react uses.

This all means, for DOM creation and updates the actual DOM is used.

Now this may sound scary, as we all hear the DOM can be slow. But as it turns out, some aspects of the DOM are actually quite fast, and often faster then the alternatives.

For example:

* fragment.cloneNodes to produce new content * node.textContent to update content – nicely leaves content inert, without needing costly JS based XSS escaping.

There are obviously downsides to either approach and as such likely some hybrid is ideal.

just wait till you try generators + async/await, it can be a lovely experience. No callbacks, and working try/catch.

although it would be awesome if this enabled time travel...

ember.js core-team person here: This article nicely summarizes not only why I recommend ember to others, but also why I have chosen to invest my time an energy into the framework and evolving ecosystem. It makes me productive, it makes my team-mates productive, it makes new-hires or members from other teams productive in my app and awesomely, it makes entirely random community members productive when they help other entirely random community members.

Software is complicated, copious amounts flexibility comes at a pretty hefty cost.

Although ember is considered an opinionated framework, the opinion really is only an optimized veneer + glue, peel it away and you have a maximally flexible experience, with typically clear adapter concerns between components.

As we discover and derive new best practices, we don't just aim to share it via literature, or a big bang release and let users discover it as they go. We actively evolve the framework to encourage these best-practices.

Although we are evolving rapidly, we spend copious amounts of effort ensuring the upgrade paths are incremental and digestible.

As a example of this, we have many users with massive applications that began their lives in the days of Sproutcore (5 years ago) but exist today as idiomatic ember 1.1x+ (and soon 2.0) apps. Although the earlier years compatibility and upgrades were shaky at best, we have been spiraling in on a good cadence.

I am working at Yahoo now, we have several large production apps, that are surfing near master of ember, we follow the deprecations to align ourselves with best practices and typically this means deleting a lot of code (liability) and letting the framework do more and more of the heavy lifting. As a bonus, each time we hit issues, we close the feedback loop, report the issue, fix the bug and move on.

I believe all the frameworks are spiraling in on this value proposition, and that is wonderful. Ultimately good evolving best practices tech and idioms benefits the end users, and this is the only thing that actually matters.