iamstef's comments

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.