I was tired adding up time-related estimates to arrive at a due date. Now I ask teams for their time-related estimate (story points, weeks, etc) and a confidence on their estimate.
This tool runs 5k simulations to create a probabilistic roadmap. I hope others find it useful. Let me know if you have any suggestions!
I'm not sure how those would deal with the scenarios focused on in the article. The only one I'm familiar with is per-component redraws which wouldn't apply.
The general gist is that one would use the subtree diff skipping APIs to prevent expensive diffs, and per-component redraws to selectively update things in the problematic subtree. Admittedly, it's not perfect and requires a not-so-trivial amount of app-space code, but at least it's not a black box renderer like, say, Angular 1.
Ultimately, there are a vast number of different scenarios, some of which are likely to remain open problems for the foreseable future (e.g. a 100,000 item reverse), and some of which can be worked around via application space "escape hatches" such as the use of granular update APIs and techniques like occlusion culling.
As I said, it's very interesting to see work that tackles the problem from an algorithmic complexity angle, and it's always healthy to explore different performance characteristics, but I think it's important to also keep in perspective what is the performance profile of solutions currently in the market, because looking at their theoretical algorithmic complexity alone doesn't tell the whole story.
As the lead author of JMVC, CanJS, StealJS, etc, let me try to address some of the criticisms of this article. I didn't write it, but I reviewed it.
Yes, this is a blatant advertisement. We worked hard on these open source project, believe they are great, and were trying to argue for their use from a commonly overlooked perspective. It should surprise no one that an article on our site advocates for one of our open source projects. I don't think arguing for something you benefit from should disqualify the argument. Instead, it should make any claims we make fall under more intense scrutiny.
Now about longevity, there really isn't a fair comparison. JavaScriptMVC is far older then Backbone, Knockout, Angular and React. They, for the most part, haven't even had to evolve. Their technology is, for the most part, still pretty modern. We'll see how they do.
Here's how JavaScriptMVC evolved:
JavaScriptMVC started on PrototypeJS. It did almost everything a Backbone + RequireJS + Karma + DocJS setup does today. Except much worse! It used:
- PrototypeJS (jQuery had only first released)
- RhinoJS (the only viable server-side JS runtime)
- EJS for templates like `<%= foo %>`
- Steal syntax for loading scripts `steal(dependencies)`
- Selenium for test driving
It had the only working "event delegation" system. This was one of its big features. It also had:
- basic modeling
- basic routing
Since that time, we've probably done more then anyone else to adapt and evolve the tools and technology so a reasonable person could upgrade. Some of my favorite highlights:
1. We updated StealJS to support AMD/CJS/ES6 syntaxes while still supporting the old steal syntax. We also migrated its build system from RhinoJS to NodeJS.
2. We swapped out Prototype for a compatibility layer that runs on jQuery / Zepto / Dojo / Mootools / YUI
3. I helped jQuery add event delegation so we could drop it from JMVC in jQuery 1.4.
4. We added live-binding EJS templates.
5. We added live-binding Handlebars-like templates. And then re-wrote that again to be 2x faster.
2. Worker-thread rendering with virtual dom merges.
We started when JavaScript was in its infancy and managed to evolve our tools and technology to keep pace with innovation constantly happening in our space. I really don't think there's another project that's undergone such a transformation.
When Angular was released, people thought putting click handlers back in a template was silly. Same with React's Virtual DOM approach. Those things have turned out to be great. We've added them (or are just about to).
We've tried to keep changes as small as possible between major versions. I think we've walked the line well between change and backwards compatibility.
So in the end, we're very proud of these accomplishments. We believe they are unique and mean something. That's what this article was about.
animate - probably wouldn't make sense until CSS is better supported.
styles - I've suggested adding it, but waiting on the "go ahead".
fastfix - I've suggested adding, but jQuery said it wasn't interested. I don't think they realize that although fix in its current state is fast, it's called all the time, making it important.
Yes, there are several, but not many can be used with delegate / on in the same way these events can. This makes it extremely useful for frameworks that use declarative event bindings.
comparing jQuery's height vs one implemented with reading multiple properties. I can get a benchmark for this soon.
As far as animate, that's tricky. There's nothing to measure but framerate I suppose. It does in fact use CSS animations and if you assume they are faster (which what's the point if not) ... then you can assume animate is faster.
I was tired adding up time-related estimates to arrive at a due date. Now I ask teams for their time-related estimate (story points, weeks, etc) and a confidence on their estimate.
This tool runs 5k simulations to create a probabilistic roadmap. I hope others find it useful. Let me know if you have any suggestions!