4 ms·

( I didn't downvote the parent ) > The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS. Of course these pr

( I didn't downvote the parent ) > The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS. Of course these problems (multiple!) can be fixed with vanilla js. They all have been, separately, each in their own libraries and stackoverflow posts and custom vanilla code on every project in the past couple decades. The linked page does an excellent job of pointing out the libraries and SO posts it's utilizing to resolve these issues. The purpose of the linked component is to pull in all these vanilla js fixes and tweaks at once, in a way they'll all work together. A drop-in component to utilize years worth of tweaks and fixes, so you don't have to worry about this crap anymore. Doesn't that kind of cover your complaint? We shouldn't have to deal with it anymore. Drop this in, and worry about something more interesting. > I think it's time we all took a step back and ask, "what are we doing? Is this the right model? Is there a better way?" I picked React long before most of my colleagues did, and I continue to feel it's one of the most useful libraries in quite some time for browser-based javascript development. Mostly because it allows for something like this very library - drop-in and move on to something better. I was also a huge fan of jquery - not because I couldn't do what jquery was doing for me, but because I was tired of doing it repeatedly for different browsers and for each and every project. Same goes with prototype.js when it first came out, though I hated how it modified the underlying objects. If I'm understanding your post correctly, I feel like these are all attempts to resolve the issues you're speaking toward. To allow us to stop dealing with cross-browser, cross-device, 2-cans and a string connection issues that, ideally, our browsers should be handling for us. At least we don't have to rely on flash to replace missing browser functionality anymore (I say that as someone who absolutely loved ActionScript3).

unclebucknasty 8y ago
>The purpose of the linked component is to pull in all these vanilla js fixes and tweaks at once, in a way they'll all work together. Is it acceptable that this is the state of the art? That, 15-20+ years on, we are fixing the same problem and, further, that we are doing so by rolling a bunch of cruft into yet another framework? Is this really what we are shooting for? >A drop-in component to... >Drop this in, and worry about something more interesting Drop it in after learning and adopting a fairly heavyweight framework that forces you to code to a completely different paradigm. Do we really think this is an acceptable solution for simply displaying images on a Web page? I think that's really telling WRT how far off the map we've wandered. >Doesn't that kind of cover your complaint? >I feel like these are all attempts to resolve the issues you're speaking toward. I think React and others are really symptoms of the problem, which is an impedance mismatch between the static document model that underpins the platform on which we are now trying to build fully dynamic applications. Rather than continuing to paper over browser deficiencies, there needs to be some collaboration between the webdev and browser communities to define more consistent behavior for common scenarios and a standard component/event based model of the type that has proven suitable for GUI-based applications. The Web standards of HTML, DOM, CSS, etc. should not be first-order constructs in this new model. That is, devs should not work in them directly and, to the extent that these standards are useful due to their currently-broad browser support, they should be generated by tooling. We should be laying out our UIs on canvases in our IDEs with flexible grid layouts, and hanging event handlers off of various events a la Swing. We need to break the current DOM/old Web model that tells us React and others are good simply because they make the impedance mismatch slightly less painful and paper over some browser deficiencies.
- enobrev 8y ago
  (I didn't downvote your posts either) I went on a weird tangent with my reply to this comment and just I'm just going to replace it with this. I generally agree with what you're saying as a means forward, but I also think React is a fantastic tool in the meantime. What we have is, in fact, the state of the art for better or worse. We will get beyond this, but it clearly takes time.

unclebucknasty 8y ago

>The purpose of the linked component is to pull in all these vanilla js fixes and tweaks at once, in a way they'll all work together. Is it acceptable that this is the state of the art? That, 15-20+ years on, we are fixing the same problem and, further, that we are doing so by rolling a bunch of cruft into yet another framework? Is this really what we are shooting for? >A drop-in component to... >Drop this in, and worry about something more interesting Drop it in after learning and adopting a fairly heavyweight framework that forces you to code to a completely different paradigm. Do we really think this is an acceptable solution for simply displaying images on a Web page? I think that's really telling WRT how far off the map we've wandered. >Doesn't that kind of cover your complaint? >I feel like these are all attempts to resolve the issues you're speaking toward. I think React and others are really symptoms of the problem, which is an impedance mismatch between the static document model that underpins the platform on which we are now trying to build fully dynamic applications. Rather than continuing to paper over browser deficiencies, there needs to be some collaboration between the webdev and browser communities to define more consistent behavior for common scenarios and a standard component/event based model of the type that has proven suitable for GUI-based applications. The Web standards of HTML, DOM, CSS, etc. should not be first-order constructs in this new model. That is, devs should not work in them directly and, to the extent that these standards are useful due to their currently-broad browser support, they should be generated by tooling. We should be laying out our UIs on canvases in our IDEs with flexible grid layouts, and hanging event handlers off of various events a la Swing. We need to break the current DOM/old Web model that tells us React and others are good simply because they make the impedance mismatch slightly less painful and paper over some browser deficiencies.

enobrev 8y ago
(I didn't downvote your posts either) I went on a weird tangent with my reply to this comment and just I'm just going to replace it with this. I generally agree with what you're saying as a means forward, but I also think React is a fantastic tool in the meantime. What we have is, in fact, the state of the art for better or worse. We will get beyond this, but it clearly takes time.