4 ms·

Not sure how you avoid reinventing any of the component frameworks. Writing custom JS component backbone style seems tedious and error prone. Manually modifying

by dsego 1y ago

Not sure how you avoid reinventing any of the component frameworks. Writing custom JS component backbone style seems tedious and error prone. Manually modifying the DOM on changes means writing the same logic several times, once for the initial render and then repeated in every event handler that has change the state of the UI. Alternatively, you might just be nuking your DOM with inner html and then running everything again through the initial rendering logic. But this isn't ideal, components loose focus, there can be glitches, and it can get slow. Not sure how you could make the type of complex UI heavy apps and have any greater flexibility or faster maintenance.

thomasikzelf 1y ago
If you are writing the same DOM update code in each event handler you can abstract it into a function.
- dsego 1y ago
  What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.
  - austin-cheney 1y ago
    You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity. All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node. All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework. This is a person problem, not a technology problem.
    - rrgok 1y ago
      I did not understand the event handler part. Could you make an example?
      - austin-cheney 1y ago
        const myHandler = function (event) { console.log(event.target); }; // this is simple and easier to troubleshoot, // but you can only directly assign one value to an object property myNode.onclick = myHandler; // for pages with JavaScript code from third party domains // use event listeners instead myNode.addEventListener("click", myHandler); When leaving frameworks you have to stop thinking in terms of components, isolated code islands that exist only in their own isolated world. Instead think of areas of the page as parts of a larger whole. You can manage each part independently or not. You wouldn't program outside the browser using something like React, so your programming inside the browser should reflect how you would build an application if the browser weren't there.
  - thomasikzelf 1y ago
    <select id=dropdown> <option value=a>a</option> <option value=b>b</option> </select> <select id=a style="display: none">...</select> <select id=b style="display: none">...</select> <script> const $ = name => document.querySelector(name) $('#dropdown').addEventListener('change', ev => { $('#a').style.display = ev.target.value == "a"? "block" : "none" $('#b').style.display = ev.target.value == "b"? "block" : "none" } </script> vs const [showing, setShowing] = useState(null) const handleChange = ev => setShowing(ev.target.value) let other if(showing == "a") other = <select>...</select> if(showing == "b") other = <select>...</select> return <> <select onChange={handleChange}> <option value=a>a</option> <option value=b>b</option> </select> {other} </> some notes: - The complexities of both of these tiny pieces of code is similiar (I would say) - React needs to load a big bundle - React spits out a large stacktrace with react internals if something goes wrong - React is slower - React code cannot be easily stepped through with the debugger - React needs a build step - React performance is very unpredictable (this is more of a problem with many elements and dynamic code) Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.
    - dsego 1y ago
      Yes and then add few other pieces of state and interdependent components, the reactive code will extend, the manual patch job of connecting listeners and mutating DOM will start falling apart. The first example is okay for a one off but can't be reused as a component. It's also easy to get in a place where you have to update 3-4 different handlers to include a logic change. In a component based library/framework, you ideally update the state logic in one place and the UI just reflects that. For example, making the UI dynamic with a button that adds/removes multiple items that need this show/hide logic, you would need to attach new listeners, clean up listeners, clean up DOM items, and so on... my first example was only illustrative, but not to be taken literally. There a complex UI state in many apps, and reactivity with component based reuse is easier to manage and make sure all states are covered. Many times in my jquery years 10-15 years ago I had failed to update one piece of the DOM and there would be bugs that just aren't happening with component UIs.
austin-cheney 1y ago
> Not sure how you avoid reinventing any of the component frameworks. You don't do framework nonsense. That is all there is to it. For most people writing JavaScript for employment it is absolutely impossible to imagine any universe where a couple of lines of code could be written without something that looks like a framework. That is not a limitation of the language, but rather a limitation of the given developer's imagination. The problem is thus a person problem and not a technology problem. I do not use innerHTML because that is string parsing, and one of my critical performance steps is to avoid parsing from strings, except JSON.parse when needed.
- rudi-c 1y ago
  When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small. If the app being built is "large" (which I understand to mean, has high essential complexity), then those tradeoffs matter a lot. If the app is built by a team instead of an individual, the people problems become significant. Those can very well be turned into a technology problem. The technology (framework in this discussion) can be used, among many other things, to establish a consistent way of solving the problems in the application, which alleviates many people problems.
  - austin-cheney 1y ago
    > When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small. The JavaScript logic in the browser is comparatively small compared to the total application. This is absolutely more true when you remove the bloat imposed by a large framework. Frameworks do not exist to alleviate problems for the developer. They exist to help the employer with candidate selection and training elimination to expedite hiring and firing. I can understand why a developer who is utterly reliant on the framework to do their job might think otherwise, which is a capability/dependence concern.
    - 1y ago

by dsego 1y ago

thomasikzelf 1y ago

If you are writing the same DOM update code in each event handler you can abstract it into a function.

dsego 1y ago
What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.
- austin-cheney 1y ago
  You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity. All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node. All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework. This is a person problem, not a technology problem.
  - rrgok 1y ago
    I did not understand the event handler part. Could you make an example?
    - austin-cheney 1y ago
      const myHandler = function (event) { console.log(event.target); }; // this is simple and easier to troubleshoot, // but you can only directly assign one value to an object property myNode.onclick = myHandler; // for pages with JavaScript code from third party domains // use event listeners instead myNode.addEventListener("click", myHandler); When leaving frameworks you have to stop thinking in terms of components, isolated code islands that exist only in their own isolated world. Instead think of areas of the page as parts of a larger whole. You can manage each part independently or not. You wouldn't program outside the browser using something like React, so your programming inside the browser should reflect how you would build an application if the browser weren't there.
- thomasikzelf 1y ago
  <select id=dropdown> <option value=a>a</option> <option value=b>b</option> </select> <select id=a style="display: none">...</select> <select id=b style="display: none">...</select> <script> const $ = name => document.querySelector(name) $('#dropdown').addEventListener('change', ev => { $('#a').style.display = ev.target.value == "a"? "block" : "none" $('#b').style.display = ev.target.value == "b"? "block" : "none" } </script> vs const [showing, setShowing] = useState(null) const handleChange = ev => setShowing(ev.target.value) let other if(showing == "a") other = <select>...</select> if(showing == "b") other = <select>...</select> return <> <select onChange={handleChange}> <option value=a>a</option> <option value=b>b</option> </select> {other} </> some notes: - The complexities of both of these tiny pieces of code is similiar (I would say) - React needs to load a big bundle - React spits out a large stacktrace with react internals if something goes wrong - React is slower - React code cannot be easily stepped through with the debugger - React needs a build step - React performance is very unpredictable (this is more of a problem with many elements and dynamic code) Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.
  - dsego 1y ago
    Yes and then add few other pieces of state and interdependent components, the reactive code will extend, the manual patch job of connecting listeners and mutating DOM will start falling apart. The first example is okay for a one off but can't be reused as a component. It's also easy to get in a place where you have to update 3-4 different handlers to include a logic change. In a component based library/framework, you ideally update the state logic in one place and the UI just reflects that. For example, making the UI dynamic with a button that adds/removes multiple items that need this show/hide logic, you would need to attach new listeners, clean up listeners, clean up DOM items, and so on... my first example was only illustrative, but not to be taken literally. There a complex UI state in many apps, and reactivity with component based reuse is easier to manage and make sure all states are covered. Many times in my jquery years 10-15 years ago I had failed to update one piece of the DOM and there would be bugs that just aren't happening with component UIs.

austin-cheney 1y ago

> Not sure how you avoid reinventing any of the component frameworks. You don't do framework nonsense. That is all there is to it. For most people writing JavaScript for employment it is absolutely impossible to imagine any universe where a couple of lines of code could be written without something that looks like a framework. That is not a limitation of the language, but rather a limitation of the given developer's imagination. The problem is thus a person problem and not a technology problem. I do not use innerHTML because that is string parsing, and one of my critical performance steps is to avoid parsing from strings, except JSON.parse when needed.

rudi-c 1y ago
When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small. If the app being built is "large" (which I understand to mean, has high essential complexity), then those tradeoffs matter a lot. If the app is built by a team instead of an individual, the people problems become significant. Those can very well be turned into a technology problem. The technology (framework in this discussion) can be used, among many other things, to establish a consistent way of solving the problems in the application, which alleviates many people problems.
- austin-cheney 1y ago
  > When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small. The JavaScript logic in the browser is comparatively small compared to the total application. This is absolutely more true when you remove the bloat imposed by a large framework. Frameworks do not exist to alleviate problems for the developer. They exist to help the employer with candidate selection and training elimination to expedite hiring and firing. I can understand why a developer who is utterly reliant on the framework to do their job might think otherwise, which is a capability/dependence concern.
  - 1y ago