4 ms·

>Manually handling the DOM is probably the biggest cause of spaghetti code. This isn't true. The biggest cause of spaghetti code in "traditional" JS is due to

>Manually handling the DOM is probably the biggest cause of spaghetti code. This isn't true. The biggest cause of spaghetti code in "traditional" JS is due to having multiple conflicting sources of truth for the same pieces of state information (usually split between JS variables and DOM) and subsequent multi-directional synchronization. Having a model that drives all DOM is one way to solve this. However, having "canonical" representation of your state in DOM works as well.

mambodog 9y ago
I think manual DOM manipulation and lack of canonical state representation are both sources of spaghetti code; which one hurts more depends on the type of app you're building. Having the DOM as your canonical representation of state is only suitable for apps with limited state IMO, because your state effectively has to be turned into text (CSS class names and element attributes) whenever it is mutated, which becomes a liability as the complexity of your app state grows.
dlwdlw 9y ago
Yep. And this problem was "solved" long ago via client side templates, MVC from the server to the front-end. Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it. Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly. The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub. Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used. Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone". What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is. Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex. It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS. Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"
agnivade 9y ago
I will have to disagree with you on this. The answer is not cut and dried though. Code slowly starts to become spaghetti when you start putting in more and more UI logic into it. At one point of time, it just becomes a complete mess of if conditions, $.each loops and when you start putting $("#div").("data-something", "value"), you know its spaghetti time. Personally, I feel the components approach keeps it sane. Just let your v-dom layer do all the work. Use a state management library if needed. Just my 2 cents.

mambodog 9y ago

I think manual DOM manipulation and lack of canonical state representation are both sources of spaghetti code; which one hurts more depends on the type of app you're building. Having the DOM as your canonical representation of state is only suitable for apps with limited state IMO, because your state effectively has to be turned into text (CSS class names and element attributes) whenever it is mutated, which becomes a liability as the complexity of your app state grows.

dlwdlw 9y ago

Yep. And this problem was "solved" long ago via client side templates, MVC from the server to the front-end. Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it. Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly. The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub. Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used. Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone". What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is. Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex. It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS. Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"

agnivade 9y ago

I will have to disagree with you on this. The answer is not cut and dried though. Code slowly starts to become spaghetti when you start putting in more and more UI logic into it. At one point of time, it just becomes a complete mess of if conditions, $.each loops and when you start putting $("#div").("data-something", "value"), you know its spaghetti time. Personally, I feel the components approach keeps it sane. Just let your v-dom layer do all the work. Use a state management library if needed. Just my 2 cents.