3 ms·

> simple demo app I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.

tgflynn 4y ago
All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?
- arbitrage 4y ago
  so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
- guilherme-puida 4y ago
  If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?
  - tgflynn 4y ago
    Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.
    - wonnage 4y ago
      sounds like someone has a bad case of not-invented-here
      - spoils19 4y ago
        Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.
        phist_mcgee 4y ago
        I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked. Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.
        wonnage 4y ago
        This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.
        guilherme-puida 4y ago
        Do you work alone though? Do all people in your team agree with your technical decisions? If you left the team, would someone be able to maintain and improve your hand-rolled framework?

tgflynn 4y ago

All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?

arbitrage 4y ago
so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
guilherme-puida 4y ago
If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?
- tgflynn 4y ago
  Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.
  - wonnage 4y ago
    sounds like someone has a bad case of not-invented-here
    - spoils19 4y ago
      Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.
      - phist_mcgee 4y ago
        I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked. Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.
      - wonnage 4y ago
        This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.
      - guilherme-puida 4y ago
        Do you work alone though? Do all people in your team agree with your technical decisions? If you left the team, would someone be able to maintain and improve your hand-rolled framework?