3 ms·

I don't get why a comment like this is downvoted. The commenter is simply saying that he doesn't understand the hype. This site is getting nearly unbearable wit

I don't get why a comment like this is downvoted. The commenter is simply saying that he doesn't understand the hype. This site is getting nearly unbearable with the groupthink, particularly around specific tech or frameworks. /meta On this particular issue, I will go further than my parent and say this does not represent a significant step forward in the scheme of things. The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS. It is positively nuts that we are celebrating a "fix" for it all of these years later, and that we are investing so much time on what should be routine by now. Anyone who is genuinely excited about this should sincerely be asking themselves if it's a good thing that a lengthy post/fairly involved component for sanely displaying images in a browser is the state-of-the-art for Webdev in 2018. Yes, I get it: browsers don't do x or y. So, yeah, let's add more libs, more frameworks, more shims, more specs...more, more, more. It's almost self-parody by now. Look at the average Webapp of any semi-significant complexity. It is such a hodge-podge of code, languages, technologies, build steps, etc. that it's a wonder any of it works. 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?"

shawn 8y ago
As someone who's been here from nearly day one, there has been groupthink around specific tech and frameworks from nearly day one. :) It's not a big deal. Just correct the downvotes and ignore the vocal comments. I identify with your point of view on this topic. But the way to correct the situation isn't to write a rebuttal here. The world only notices better solutions when they exist, so creating them is step one.
- unclebucknasty 8y ago
  >But the way to correct the situation isn't to write a rebuttal here. The world only notices better solutions when they exist, so creating them is step one. Thanks, but I've clearly not made my point! I am saying that we don't need to each run off and create more solutions as that's how we got here in the first place. That is, we can't solve the problem of too many "solutions" by creating more solutions. So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top.
  - mephitix 8y ago
    >> So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top. Lol... this is way easier said than done. The ironic thing is, this has been attempted several times. In fact I would argue this thinking led to the React ecosystem.
enobrev 8y ago
( 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.

shawn 8y ago

As someone who's been here from nearly day one, there has been groupthink around specific tech and frameworks from nearly day one. :) It's not a big deal. Just correct the downvotes and ignore the vocal comments. I identify with your point of view on this topic. But the way to correct the situation isn't to write a rebuttal here. The world only notices better solutions when they exist, so creating them is step one.

unclebucknasty 8y ago
>But the way to correct the situation isn't to write a rebuttal here. The world only notices better solutions when they exist, so creating them is step one. Thanks, but I've clearly not made my point! I am saying that we don't need to each run off and create more solutions as that's how we got here in the first place. That is, we can't solve the problem of too many "solutions" by creating more solutions. So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top.
- mephitix 8y ago
  >> So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top. Lol... this is way easier said than done. The ironic thing is, this has been attempted several times. In fact I would argue this thinking led to the React ecosystem.

enobrev 8y ago

( 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.