3 ms·

It depends. You can do quite a fair bit with vanilla JS, HTML, and CSS. Things get a little tricky when you start having to maintain a lot of state that multi

It depends. You can do quite a fair bit with vanilla JS, HTML, and CSS. Things get a little tricky when you start having to maintain a lot of state that multiple elements need to be aware of. It's not impossible to do this with vanilla JS, but the mental model can be a bit difficult and this gets amplified across teams. What crap.js frameworks do well is provide a contract for how state can be organized and how components should react/interact with the change in state. This scales well across teams as following a set of mutually agreed upon conventions produces more legible code instead of an entire team rolling their own code for everything.

duderific 7y ago
Thanks for stating this so succinctly. This is a vanilla JS thread, but the "frameworks are crap" groupthink is also getting a bit out of hand. If you are building complex dashboards where multiple components are sharing and updating state, using a declarative framework like React or Vue and state management like Redux keeps things manageable as requirements change.
- abraxas 7y ago
  Isn't the DOM your true state anyway? Why does it have to be kept someplace else? I'm genuinely curious because I don't do any front end work.
  - rajangdavis 7y ago
    When you start tracking state in the DOM, you start having to be very imperative on what gets updated as state changes. For example, if you have a search application and you want to paginate results, you can get pretty far with vanilla js, but you have to evoke changes based on events which is hard to scale beyond one person rolling their own code. This is a lot nicer with frameworks because you can be less explicit on which elements get updated and rather describe changes in state with elements "subscribing" to these state changes. Furthermore, these frameworks have conventions to follow that makes things consistent which is nice for teams. I tend to use jQuery for things that require basic JS interactions, but when there are things that require very scoped JS state with a complex set of interactions, I will defer to Vue.js.

duderific 7y ago

Thanks for stating this so succinctly. This is a vanilla JS thread, but the "frameworks are crap" groupthink is also getting a bit out of hand. If you are building complex dashboards where multiple components are sharing and updating state, using a declarative framework like React or Vue and state management like Redux keeps things manageable as requirements change.

abraxas 7y ago
Isn't the DOM your true state anyway? Why does it have to be kept someplace else? I'm genuinely curious because I don't do any front end work.
- rajangdavis 7y ago
  When you start tracking state in the DOM, you start having to be very imperative on what gets updated as state changes. For example, if you have a search application and you want to paginate results, you can get pretty far with vanilla js, but you have to evoke changes based on events which is hard to scale beyond one person rolling their own code. This is a lot nicer with frameworks because you can be less explicit on which elements get updated and rather describe changes in state with elements "subscribing" to these state changes. Furthermore, these frameworks have conventions to follow that makes things consistent which is nice for teams. I tend to use jQuery for things that require basic JS interactions, but when there are things that require very scoped JS state with a complex set of interactions, I will defer to Vue.js.