4 ms·

>there will never be direct DOM access from WebAssembly for security reasons You should contribute this knowledge: https://github.com/WebAssembly/proposals/iss

• austincheney 8y ago
  > I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile. Uggghhh, somehow you have somehow never seen DOM fear while simultaneously describing your own DOM fear. To say this behavior is prolific underscores the prolificness of it. --- Some anecdotal stories of DOM fear: I remember trying to hire my replacement when I was the A/B test engineer for Travelocity. This was when jQuery was at its religious height before querySelectors were a standard. jQuery wouldn't work well in this context because it was too slow, required an external library, and developers spent more time debugging their crappy jQuery code than simply solving the business problem. I remember warning applications they could not use jQuery in this position and it would not be available for consideration in the interview. Half the candidates dropped out. Before I became the A/B test engineer for Travelocity I remember a principle engineer telling me they had to use jQuery because the DOM was too hard. Its because of stupid crap like that the company had no trouble promoting me to more senior positions. I remember being temporarily banned from an IRC channel because I described jQuery as slow. They are thousands of times slower on all browsers except Firefox where they are millions to billions times slower. It sounds like there should be more to this, such as a demonstration of bad behavior on my part, but I promise describing jQuery as slow was all it took to elicit an immediate emotional response that touched on multiple people. I remember being continuously flamed on Reddit for describing that WASM is not a DOM replacement. I have since deleted my Reddit account. On Reddit's r/programming the emotions are especially raw on this subject. I remember going into job interviews for JavaScript development and opening the conversation with my thoughts on jQuery or DOM access. Every time the interview would have to recollect themselves from being immediately disoriented and completely lost. Strange as that sounds it never stopped me from winning the job. I could go on and on, but fear of the DOM is real. People justify all manners of strange behaviors to qualify their defensiveness on this matter to the point of exercising extreme effort to avoid the subject at great expense to their business products and even their career decisions. Its really weird because the DOM is the standard and its stupid simple.
  • danShumway 8y ago
    Is this all just about people using ``$`` instead of ``document.querySelector``? I figured you were talking about the virtual DOM in React or something. Now I'm not sure what you mean anymore. What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow. That has nothing to do with being afraid of the DOM, it has to do with grouping your update logic into one place so that you can avoid spaghetti code, state-dependent updates, and XSS attacks. When people talk about direct DOM access, this is often what they're referring to -- developers who think, "I need to change the color of this button. I know, I'll just set it directly in this random method so it only works in this very narrow code path." I haven't used JQuery on a single personal project in at least 3 or 4 years, possibly longer. But even though I'm usually using the JS APIs directly, I'm still pushing all of my logic through a single render function instead of willy-nilly updating input labels in 5 different functions. Forcing rendering to go through an optimized chokepoint is just good architecture -- I'd use the same pattern even if I was working with Windows Forms or OpenGL. My advice would be that if you're surrounded by people who are frightened of working with the DOM without JQuery, then find better developers to hang out with. Because in my experience that's not typical, and I very rarely run into developers with that perspective. Certainly I don't think it's the consensus on HN.
    • austincheney 8y ago
      document.querySelector is still amazingly similar in use and form to the Sizzle engine on which it is based. Either way they have to parse into the standard DOM methods, because strings alone will not navigate or access anything. Here is a summary of the standard DOM for mere mortals: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml > What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow. I have been doing this work long enough to see all manners of excuses and justifications. It is amazing how they change over time, but at any given time they are wonderfully uniform centering on the most popular understanding of the technology at the time. They are all unoriginal clichés that people mindlessly echo. The excuses that stuck with me over the years: * Its too hard. You cant do it without jQuery. * It has to be further abstracted. Without the necessary abstractions you are essentially working in assembly code. (JavaScript is never close to assembly). * You are reinventing the wheel (never mind that frameworks do that frameworks reinvent the wheel) * You have to maintain state and you cannot do that without a framework. (unit test your code) * If you don't use a framework you will end up writing a framework anyways. --- In the end all the stupidity comes down to behavior. Developers don't trust the technology, don't trust their management, and especially don't trust each other or themselves to get it right. This behavior is called invented here syndrome and it isn't limited to the dom, the web, or even software. I frequently speak with lawyers and medical professionals who are frequently forced to mitigate this very same set of stupidity. The cure for this foolishness is: * Don't hire incompetent people, which are people lacking the proper desire and potential. * Train your people. This technology isn't hard. * Have the proper test automation in place. * Have strong leadership in place. It is only a matter of time before people get frustrated or desperate and differ to really bad decisions. Bad decisions aren't limited to stupid people. Strong leaders are capable of withstanding the tired pleadings and big tears. Bad decisions are almost universally motivated by a perception of convenience without regard for risks or future expense, the easy versus simple paradigm. Of course most organizations aren't willing to invest in any of this and would rather push the debt out to be a future failure for somebody else.