morrvs

Completely agree. In hindsight the choice of ES5 is questionable and in the study I actually conclude that another ES6-based experiment is desirable. Also, as others here have noted, you could start with ES6, see if it works for enough of your users, and only if not orthogonally introduce transpilation to ES5 as a production optimization.

Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.

Performant drag & drop + FLIP animations were not trivial to implement (naive approaches like re-render fully on each mousemove fail spectacularly). I needed to see FPS on a couple different devices so I added the counter. Also, since I claim good rendering performance in the case study, I just kept it there as "proof" :)

Totally agree. I should update the study to express praise for the original TeuxDeux, it's conceptually the best to-do app out there in my opinion.

Thank you very much, looking forward to your feedback! And yes, this is exactly what I wanted to achieve :)

It does start from scratch but it (re-)invents a whole lot of general-purpose code, in effect making up a framework/library, which was an explicit non-goal for the case study (because there are good ones already).

Would you mind creating an issue with some details (browser and version, maybe how to reproduce)? Thanks :)!

Sorry, I didn't mean to make a difference between frameworks and libraries in this case; both would violate the method/goal of the case study which was finding vanilla patterns that are not dependant on general-purpose code.

Thank you very much! This is quite exactly what I'm trying to achieve. Very happy that you like it :)

Original author here - thanks! Yes, ES5 is a huge pain. However, I believe 5% of users (see other comment) are not a joke for many apps. There's always the question of minimum critical APIs required: If you build a 3D or webcam app you can forget ES5 altogether, of course.

> It’s a lot like using polyfills when needed.

Never thought of it this way, thanks for that! As is state in the conclusion, the study would likely be more convincing with ES6 and build steps. So yeah, ES5 is questionable :)

:D just to be clear, the rules were made just for the case study. I'd never recommend following these rules in a professional project. They are part of the method of the case study, not its outcome; the outcome is a couple of (hopefully) interesting patterns and insights, without trying to prescribe anything.

Thanks for reading - original author here. For the precise quote you mentioned I came up with somewhat format rules which prevented building a framework (code-wise) for this case study. The "caveat" you mention is just an explanation for the chosen ruleset; I believe I haven't introduced any general-purpose DOM/UI code in the case study and instead only describe patterns (correct me if I'm wrong!). I agree with your view of framework value as I professionally use React on a daily basis and will continue to do so, for similar reasons :)

Original author here. During the study, I explicitly forbid myself from writing general-purpose helpers which would make up a framework. Would you mind elaborating what in your view makes up the "custom framework"? Thanks!