optional /perf directory for any example proposal

[samccone]

There is a demand on many fronts to enable "production" versions of todomvc apps.

Any app should be able to add an additional /perf directory

examples/backbone/perf

The folder should contain an index.html file to serve their app in a way that is inline with best practices for said tool/framework.

Requirements for perf

• No files will be linted in /perf
• The root examples folder should have a way to build the source to go to /perf (this is the idea case.. however some examples will need a different codebase... if that is the case.. the new src can be placed into the /perf folder for the example)
• Any changes to the app will require the changer to recompile the perf build (we will need to enforce this)
• CI tests will be run on both /index.html and perf/index.html
• learn.json needs a new perf-enabled field per framework
• If an example if perf optimized by default (this is a outlier case) we will place an index.html file inside of perf/ that redirects to the root example

---

@tastejs/todomvc if everyone is OK with this I know there are several people willing to do a pass on a few implementations

[addyosmani]

👍 from me based on comment from #1490 (comment)

[sindresorhus]

👍

[passy]

SGTM. What about perf-related changes to the logic, as with angular-perf? Do we continue to keep those separate or is that something you want to cover with this proposal as well?

[samccone]

I would like to kill angular-perf and roll it into normal angular

[passy]

@samccone So having perf/ versions of the app that aren't directly created from the non-perf/ are okay then?

[samccone]

hmm good question, i was thinking there would be 1 codebase just compiled differently for perf...

but perhaps we should allow two codebases because i could think of situations where this would be required

[passy]

In theeooory, we could have a perf.patch that's applied as part of the build, but I'm not sure if that's gonna make things actually easier for anyone.

[samccone]

imho... lets just let some people do the perf version and we can see the demands per each request

thoughts?

[passy]

@samccone 👍 Let's figure out the details along the way.

[samccone]

💃

[addyosmani]

but perhaps we should allow two codebases because i could think of situations where this would be required

I can see some framework authors requiring source specific changes for a perf-optimised version of their app. Would like to keep it flexible so \perf can either be same source (ideally, pretty close) with build-time optimisations or completely different source as long as it's still latest versions + follows spec.

[passy]

\perf

You spend too much time on Windows, @addyosmani! 🎪

[sindresorhus]

Lol

[samccone]

[addyosmani]

😭 🍫

[sindresorhus]

[dmitriz]

As mentioned, the current angularjs-perf implementation is different from angularjs. Specifically - it avoids router.

The difference in performance even caused me some frustrations leading to writing this rebellious answer on StackOverflow.

---

Now there are two different performance stages:

initial page load and route change.

Many testers coming from outside and writing articles only test the former. However, it is the latter that the user has to deal with every single time after the app is started. As more people come here with testing mind, it may be helpful to

• include a guide or at least a memo as to how to test the project "correctly".

---

This seems to highlight a major problem here - how differently people see this project with very different purposes:

• Code comparison: I need to decide X vs Y: Which code is shorter/ easier to read?
• Learn best practices: I'm already using X, now I want to learn industry top standards.
• Performance: I'm writing an article and want to compare the library sizes and run performance tests.

The problem with "best practices", they may be the best in some cases but not in others. The Todo App here is relatively small, so some of the best practices look bloated and unnecessary.

So when you code with the idea to show people best practices, you end up with unnecessarily complex and bloated code that can mislead a newcomer into a wrong judgement about the framework.

On the other hand, if you optimise what the framework gives, to get things done fast and short, that may show the framework more appealing to newcomers but may not necessarily be good example to learn best practices from. See New AngularJS HTML Only Implementation for an extreme example :)

---

• So perhaps several implementations with different goals in mind are justified? All in separate sub-folders?
• And perhaps avoiding calling it "official Angular implementation" but rather keep in its own folder with clearly defined goal? That way people from outside are forced to understand the difference before jumping to quick conclusions and influencing others.

[ColinEberhardt]

So perhaps several implementations with different goals in mind are justified? All in separate sub-folders?

I think this highlights a problem with the whole concept of adding 'perf' implementations. Does the lack of a 'perf' implementation for a particular framework mean that the canonical implementation is already performance optimised? How 'deep' should the optimisations be?

Personally I think it is better to have a single implementation for each framework and instead if someone wants to performance optimise, they write it up as a blog post which we link to in the side menu.

[samccone]

if someone wants to performance optimise, they write it up as a blog post which we link to in the side menu

People kinda already do this... however no one doing these perf checks ever looks or finds them to test against.. In my mind standardizing the way you get to the perf implementation via /perf makes it SUPER simple for people doing this kind of testing to blindly jump to the "production ready" version

Does the lack of a 'perf' implementation for a particular framework mean that the canonical implementation is already performance optimized

^ See my last point on the initial issue

How 'deep' should the optimisations be?

This is kinda up to the person doing it, I am fine with pretty much anything so long as

1. it is still the framework :)
2. it still passes the integration tests

[dmitriz]

Totally agree with the importance of SUPER simple.