4 ms·

Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irratio

Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irrationality is not new. I have no idea why, but tree models scare the shit out of college educated developers. That’s supremely weird because computer science education spends so much energy on data structures and tree models. It also makes the conversation about WASM even more bizarre. Most college educated developers are scared of the DOM. Yes, it’s fear the emotion and it’s completely irrational. Trust me on this as I have watched it as a prior full time JS dev for over 15 years. Developers are continuously trying to hide from the thing with layers of unnecessary abstractions and often don’t know why because they have invested so much energy in masking their irrational nonsense. Other developers that have not embraced this nightmare of emotions just simply wish WASM would replace JS so they don’t have touch any of this. This is problematic because you don’t need anything to do with JS or the DOM to deploy WASM, but it’s a sandbox that ignores the containing web page, which is absolutely not a replacement. For WASM to become a replacement it would have to gain full DOM access to the containing page. Browser makers have refused to do that for clear security reasons. So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions and then other developers that want bypass the nonsense by embracing that thing they don’t know they are yet afraid of it. That is super fucking weird, but it makes for fun stories to nondevelopers that wonder why software is the way it is.

worthless-trash 1y ago
> Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.
- afiori 1y ago
  some of the worst dom api were designed with java compatibilty in mind
  - worthless-trash 1y ago
    So its the java prefix that matters ;)
continuational 1y ago
The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another. The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you. It's not irrational; quite the contrary.
- alpha_squared 1y ago
  Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.
- austin-cheney 1y ago
  Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.
  - mr_toad 1y ago
    React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM. Storing the diffs to local storage is an interesting idea though.
  - skydhash 1y ago
    State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.
    - austin-cheney 1y ago
      What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.
assimpleaspossi 1y ago
I closed my web dev business just three years ago. I found that many people who work with the web don't want to do the work to understand how it all works. They think there must be a library somewhere to do "that" while doing "that" is simple enough using standard components and features. Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.
- joquarky 1y ago
  I found the same at my last two tech jobs (S&P 100 and 500). People hate getting their hands dirty with fundamental web dev. My favorite part of web dev is working directly with the DOM, vanilla JS, and using minimal dependencies (if any). I feel like the web equivalent of an assembly programmer these days, but apparently nobody is interested in hiring for this sort of thing anymore.
afiori 1y ago
The reason WASM does not have dom access is that many recent DOM APIs return and expect javascript objects and classes like iterators, so you would still need some thin js glue wrapper between the dom and wasm. Security has nothing to do with it as (performace aside) wasm+minimal js glue can already do anything js can do
chrismorgan 1y ago
> For WASM to become a replacement it would have to gain full DOM access to the containing page. To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around. Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. > Browser makers have refused to do that for clear security reasons. Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.
- hinkley 1y ago
  > Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
  - austin-cheney 1y ago
    The point of WASM is a universal compile target that executes a sandbox. That is all. The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.
    - skydhash 1y ago
      I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++. Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.
troupo 1y ago
> I have no idea why, but tree models scare the shit out of college educated developers. Very few people are "scared" of tree models. The problem of working with the DOM is that it's: - 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things - Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks - An API that is completely non-composable - A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page) - A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height https://www.granola.ai/blog/dont-animate-height > So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.
- austin-cheney 1y ago
  This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors. DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow. Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster. The only real performance problem is the JS developer doing stupid shit.
  - troupo 1y ago
    > All these excuses, especially about vanity, are masking behaviors. 1. These are not excuses, these are facts of life 2. No idea where you got vanity from > DOM access is not quite as fast now as it was 10 years ago. I was getting just under a billion operations per second Who said anything about DOM access? > The only real performance problem is the JS developer doing stupid shit. Ah yes. I didn't know that "animating a simple rectangle requires 60% CPU" is "developers doing stupid shit" and not DOM being slow because you could do meaningless "DOM access" billions time a second. Please re-read what I wrote and make a good faith attempt to understand it. Overcome your bias and foregone conclusions.

worthless-trash 1y ago

> Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.

afiori 1y ago
some of the worst dom api were designed with java compatibilty in mind
- worthless-trash 1y ago
  So its the java prefix that matters ;)

continuational 1y ago

The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another. The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you. It's not irrational; quite the contrary.

alpha_squared 1y ago
Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.
austin-cheney 1y ago
Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.
- mr_toad 1y ago
  React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM. Storing the diffs to local storage is an interesting idea though.
- skydhash 1y ago
  State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.
  - austin-cheney 1y ago
    What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.

assimpleaspossi 1y ago

I closed my web dev business just three years ago. I found that many people who work with the web don't want to do the work to understand how it all works. They think there must be a library somewhere to do "that" while doing "that" is simple enough using standard components and features. Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.

joquarky 1y ago
I found the same at my last two tech jobs (S&P 100 and 500). People hate getting their hands dirty with fundamental web dev. My favorite part of web dev is working directly with the DOM, vanilla JS, and using minimal dependencies (if any). I feel like the web equivalent of an assembly programmer these days, but apparently nobody is interested in hiring for this sort of thing anymore.

afiori 1y ago

The reason WASM does not have dom access is that many recent DOM APIs return and expect javascript objects and classes like iterators, so you would still need some thin js glue wrapper between the dom and wasm. Security has nothing to do with it as (performace aside) wasm+minimal js glue can already do anything js can do

chrismorgan 1y ago

> For WASM to become a replacement it would have to gain full DOM access to the containing page. To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around. Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. > Browser makers have refused to do that for clear security reasons. Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.

hinkley 1y ago
> Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
- austin-cheney 1y ago
  The point of WASM is a universal compile target that executes a sandbox. That is all. The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.
  - skydhash 1y ago
    I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++. Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.

troupo 1y ago

> I have no idea why, but tree models scare the shit out of college educated developers. Very few people are "scared" of tree models. The problem of working with the DOM is that it's: - 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things - Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks - An API that is completely non-composable - A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page) - A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height https://www.granola.ai/blog/dont-animate-height > So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.

austin-cheney 1y ago
This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors. DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow. Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster. The only real performance problem is the JS developer doing stupid shit.
- troupo 1y ago
  > All these excuses, especially about vanity, are masking behaviors. 1. These are not excuses, these are facts of life 2. No idea where you got vanity from > DOM access is not quite as fast now as it was 10 years ago. I was getting just under a billion operations per second Who said anything about DOM access? > The only real performance problem is the JS developer doing stupid shit. Ah yes. I didn't know that "animating a simple rectangle requires 60% CPU" is "developers doing stupid shit" and not DOM being slow because you could do meaningless "DOM access" billions time a second. Please re-read what I wrote and make a good faith attempt to understand it. Overcome your bias and foregone conclusions.