Rafael Weinstein (2014-02-21T16:25:08.000Z)
domenic at domenicdenicola.com (2014-03-02T22:27:11.729Z)
On Thu, Feb 20, 2014 at 4:38 PM, Woodlock, Don (GE Healthcare) <Don.Woodlock at med.ge.com> wrote: > As you recommended, I did have some fun with this. And I > now have some updated feedback: > > - I now understand that there is not indeed an ‘information hole’ in the changeRecords for the Array.observe callback. As you said you just need a more sophisticated processing algorithm to read them properly. I wrote a few different versions of this as well as stepped through your projectArraySplices () code in observe.js/Polymer. This logic is not for the faint of heart. > > - My feedback therefore is about the same. I believe that you should have an easier to use record of changes that is sent to the callback so that a novice or intermediate Javascript engineer can easily understand and use it. In fact you may be agreeing with this point. At the same time you are championing this standard, you are also writing a library (e.g. ArrayObserver in Polymer) that provides a more user-friendly face for the callback (your splices array). Why save the user-friendliness for the library, why not take the opportunity right now to make the changeRecords easier to use natively? > > - Here is the perspective that I am taking. At the moment I’m teaching my teenagers Javascript for an app they are building and in the interest of not confusing them, I’m trying to stick to VanillaJS so they don’t get confused about what is JS and what is part of a library. And I’m also interested in teaching them the MVC pattern which is difficult to do in pure JS. With Array.observe and Object.observe, I was hoping that eventually they, and users like them, could also take advantage of these new native features to write their code in MVC form. > > - But it is quite difficult to read the changeRecords as I mentioned above. So I took the perspective of an author writing an explanation of how to process them. You can see that in the attached document. This includes five different potential approaches that one can use to do a very simple MVC. Please read through it and you can see how difficult it is to explain it – at least for me. > > So here would be my questions/feedback for you: > > - Why not offer a more user-friendly array of changeRecords that an intermediate engineer can properly process. For example your *splices*(or my supplemented changeRecords) are much much easier to deal with. Again why save that for a library, when we could just make ECMA 6 easy to use. You might say your splices can’t be used as a replacement because it leaves off mutations that don’t net to anything. But it does work for the three use cases in your youtube walk through – MVC, persistence, and constraint management. If Object.observe is just a performance gift for library authors, fine. But if it’s something for the masses, I think you could make it easier. I realize I’m disregarding other considerations – consistency with other parts of Javascript, performance considerations, etc. But you are soooo close to offering an easy to use native feature here. > > - Given the five solutions in my document, as the champion of Object.observe, what solution would you recommend someone use to process the records? Use a library? Keep a copy and just compare yourself? Your insight into how you expect this spec to be used would be appreciated. > > Thanks Rafael – again I love the standard. I may still be > misunderstanding how this works. But you asked for feedback. Let me know > your thoughts. > > P.S. – happy to add any of this to jsbin if you’d like to see it more > closely with my testing scripts. You don't misunderstand at all! You've totally got it now. It's awesome that you are using modern application architecture as teaching material. As to your question about why not make the API easier to use, my answer is: one person's easy-to-use is another person's performance problem. As language designers, it's our responsibility to add features to the language that are simple, flexible & powerful primitives which can enable diverse patterns of use that are highly performant. While adding an extra array to each change record may make it possible to process a set of use cases by simply "applying" each change record in order to a target, allocating those arrays has a cost that most "production" applications wish to avoid. Also, most of the time it's a good trade-off to do a bunch of reads to avoid doing some writes (figuring out the minimal set of changes needed to synchronize). Also, it's generally a good idea to do some lost-cost work (computing the 'net-effect of what happened) to avoid some high-cost work (mutating the DOM). As to my recommendation of which approach to use, my personal opinion is that good system design is frequently about proper separation of concerns and layering. Much like MVC patterns create conceptual leverage by separating "business logic" from "presentation logic" concerns, complex systems are possible when we create progressively complex layers of abstractions. In other words, I think your use case requires layering the "diff in time" abstraction on top of the "raw stream of things that happened" abstraction. Whether you create this abstraction yourself or you use someone else's code (a js library) is up to you. I happen to be a fan of not reinventing the wheel when possible, but sometimes the most powerful teaching tool is to ask your student to do just that.
domenic at domenicdenicola.com (2014-03-02T22:26:52.535Z)
On Thu, Feb 20, 2014 at 4:38 PM, Woodlock, Don (GE Healthcare) <Don.Woodlock at med.ge.com> wrote: > As you recommended, I did have some fun with this. And I > now have some updated feedback: > > - I now understand that there is not indeed an ‘information hole’ in the changeRecords for the Array.observe callback. As you said you just need a more sophisticated processing algorithm to read them properly. I wrote a few different versions of this as well as stepped through your projectArraySplices () code in observe.js/Polymer. This logic is not for the faint of heart. > > - My feedback therefore is about the same. I believe that you should have an easier to use record of changes that is sent to the callback so that a novice or intermediate Javascript engineer can easily understand and use it. In fact you may be agreeing with this point. At the same time you are championing this standard, you are also writing a library (e.g. ArrayObserver in Polymer) that provides a more user-friendly face for the callback (your splices array). Why save the user-friendliness for the library, why not take the opportunity right now to make the changeRecords easier to use natively? > > - Here is the perspective that I am taking. At the moment I’m teaching my teenagers Javascript for an app they are building and in the interest of not confusing them, I’m trying to stick to VanillaJS so they don’t get confused about what is JS and what is part of a library. And I’m also interested in teaching them the MVC pattern which is difficult to do in pure JS. With Array.observe and Object.observe, I was hoping that eventually they, and users like them, could also take advantage of these new native features to write their code in MVC form. > > - But it is quite difficult to read the changeRecords as I mentioned above. So I took the perspective of an author writing an explanation of how to process them. You can see that in the attached document. This includes five different potential approaches that one can use to do a very simple MVC. Please read through it and you can see how difficult it is to explain it – at least for me. > > So here would be my questions/feedback for you: > > - Why not offer a more user-friendly array of changeRecords that an intermediate engineer can properly process. For example your *splices*(or my supplemented changeRecords) are much much easier to deal with. Again why save that for a library, when we could just make ECMA 6 easy to use. You might say your splices can’t be used as a replacement because it leaves off mutations that don’t net to anything. But it does work for the three use cases in your youtube walk through – MVC, persistence, and constraint management. If Object.observe is just a performance gift for library authors, fine. But if it’s something for the masses, I think you could make it easier. I realize I’m disregarding other considerations – consistency with other parts of Javascript, performance considerations, etc. But you are soooo close to offering an easy to use native feature here. > > - Given the five solutions in my document, as the champion of Object.observe, what solution would you recommend someone use to process the records? Use a library? Keep a copy and just compare yourself? Your insight into how you expect this spec to be used would be appreciated. > > Thanks Rafael – again I love the standard. I may still be > misunderstanding how this works. But you asked for feedback. Let me know > your thoughts. > > P.S. – happy to add any of this to jsbin if you’d like to see it more > closely with my testing scripts. Don, You don't misunderstand at all! You've totally got it now. It's awesome that you are using modern application architecture as teaching material. As to your question about why not make the API easier to use, my answer is: one person's easy-to-use is another person's performance problem. As language designers, it's our responsibility to add features to the language that are simple, flexible & powerful primitives which can enable diverse patterns of use that are highly performant. While adding an extra array to each change record may make it possible to process a set of use cases by simply "applying" each change record in order to a target, allocating those arrays has a cost that most "production" applications wish to avoid. Also, most of the time it's a good trade-off to do a bunch of reads to avoid doing some writes (figuring out the minimal set of changes needed to synchronize). Also, it's generally a good idea to do some lost-cost work (computing the 'net-effect of what happened) to avoid some high-cost work (mutating the DOM). As to my recommendation of which approach to use, my personal opinion is that good system design is frequently about proper separation of concerns and layering. Much like MVC patterns create conceptual leverage by separating "business logic" from "presentation logic" concerns, complex systems are possible when we create progressively complex layers of abstractions. In other words, I think your use case requires layering the "diff in time" abstraction on top of the "raw stream of things that happened" abstraction. Whether you create this abstraction yourself or you use someone else's code (a js library) is up to you. I happen to be a fan of not reinventing the wheel when possible, but sometimes the most powerful teaching tool is to ask your student to do just that.