3 ms·

Babel/vdom is not necessary for web dev. Can't blame chrome for electron.

alganet 2y ago
If something uses DOM and JavaScript, to me it's web enough to be called web, even if it is rendering outside of regular browser expectations (some React Native stuff or similar). The whole premise of this tech is to approximate app development to web development. Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.
- bawolff 2y ago
  Sheesh, the existence of libraries does not mean standards have failed.
  - alganet 2y ago
    Sometimes it does. Would normalize.css exist if the standards were more specific around default styles? Would jQuery/sizzle exist if CSS selectors were available as a DOM API in the first place? Would vdom exist if DOM was faster?
    - kccqzy 2y ago
      VDOM would still exist if the DOM was faster. It's a different abstraction that reconciles the differences between the simple data->elements flow and the inherently stateful DOM. If you don't understand why VDOM exists, here's a nice experiment: in your next web app stop using VDOM and always set innerHTML. You'll find that (1) it's actually fast enough so you can conclude that VDOM doesn't exist just to patch over DOM slowness; (2) you are missing some features you get in VDOM. The answer is that the DOM inherently has state. It could be a textbox's text input and its cursor state, or the focus state, or whatever. But developers don't want to think about this DOM-managed state to simplify their mental model.
      - alganet 2y ago
        Let's ask the next why. Why make the interaction with the DOM stateless? Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used. So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state). Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls). It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?
        Thiez 2y ago
        > Remember when we parsed JSON with libs written in JS? No, when was that? Because it was always possible to `eval(jsonString)` and get the parsed result. Indeed, that was the whole point.
        alganet 2y ago
        It was always possible but never safe. We're oldschool, not savages!
        deleted 2y ago
        [deleted]

If something uses DOM and JavaScript, to me it's web enough to be called web, even if it is rendering outside of regular browser expectations (some React Native stuff or similar). The whole premise of this tech is to approximate app development to web development. Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.

bawolff 2y ago
Sheesh, the existence of libraries does not mean standards have failed.
- alganet 2y ago
  Sometimes it does. Would normalize.css exist if the standards were more specific around default styles? Would jQuery/sizzle exist if CSS selectors were available as a DOM API in the first place? Would vdom exist if DOM was faster?
  - kccqzy 2y ago
    VDOM would still exist if the DOM was faster. It's a different abstraction that reconciles the differences between the simple data->elements flow and the inherently stateful DOM. If you don't understand why VDOM exists, here's a nice experiment: in your next web app stop using VDOM and always set innerHTML. You'll find that (1) it's actually fast enough so you can conclude that VDOM doesn't exist just to patch over DOM slowness; (2) you are missing some features you get in VDOM. The answer is that the DOM inherently has state. It could be a textbox's text input and its cursor state, or the focus state, or whatever. But developers don't want to think about this DOM-managed state to simplify their mental model.
    - alganet 2y ago
      Let's ask the next why. Why make the interaction with the DOM stateless? Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used. So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state). Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls). It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?
      - Thiez 2y ago
        > Remember when we parsed JSON with libs written in JS? No, when was that? Because it was always possible to `eval(jsonString)` and get the parsed result. Indeed, that was the whole point.
        alganet 2y ago
        It was always possible but never safe. We're oldschool, not savages!
      - deleted 2y ago
        [deleted]