MVU does not use two-way binding. It uses one-way messaging. The View sends messages back to your app when the user changes things. Your app updates the current state of the application (the Model). Then the Model is used to rerender the View. Whereas two-way binding keeps state on the view and the app model, and tries to directly synchronize between two when either of them change. It seems like a time saver, but ends up with a lot of edge cases and Byzantine problems.
I also do not think applications need their own framework. But using a framework leads us to think this way. Some of the apps I built that became hardest to maintain are ones where I built a framework for it.
I think it is okay to use frameworks, though. For me they were a necessary experience to learn from. For others, they might be a strict time saver because they need exactly what the framework provides and no more. But this never seems to be how things go for my projects.
I think an application framework is necessary. It can make your application share the same flow and behavior. Your team can follow the framework in order to reduce time and thus increase productivity. What I am saying is for enterprise application.
But for application which is for public, I think a framework may not be required as they need a lot of specific or funny behavior.
My use case is enterprise applications. That's pretty much all I do.
With no framework, you still make helper functions to simplify execution of common use cases. So, it is still quite easy for the team to reuse code. But the helpers are opt-in, so if the business has a custom requirement that doesn't work with an existing helper, you also have the choice to do something completely custom. Then if you need to do it more than once, you turn it into another reusable helper.
Framework or no, laziness efficiency finds a way. :)
I'm a dev with a strong *NIX sysadmin background. I've been programming for 20+ years, started with IRC scripts, C, Python, PHP, Ruby/Rails, Node/JS, Go and Elxir. Full time on Ruby,Elixir and Rust.
My experience with this kind of stuff in enteprise is that you can use a framework anyway, but mostly as pluggable widgets. Instead of helpers, I’ve also used conponents (React or Vue), for common tasks (ex: search forms, autocomplete, etc...). It worked very well, or at least IMHO, I prefer this approach over jQuery plugins/helpers.
I would prefer frameworks over jQuery too. :) As I mentioned, there are nuances to doing frameworkless well. I definitely did not mean to imply a free-for-all. There should be guiding principles to the design, of which MVU is a good one. For interacting with the DOM for example, nothing wrong with using the React renderer library, rather than trying to manipulate the DOM directly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
MVU does not use two-way binding. It uses one-way messaging. The View sends messages back to your app when the user changes things. Your app updates the current state of the application (the Model). Then the Model is used to rerender the View. Whereas two-way binding keeps state on the view and the app model, and tries to directly synchronize between two when either of them change. It seems like a time saver, but ends up with a lot of edge cases and Byzantine problems.
I also do not think applications need their own framework. But using a framework leads us to think this way. Some of the apps I built that became hardest to maintain are ones where I built a framework for it.
I think it is okay to use frameworks, though. For me they were a necessary experience to learn from. For others, they might be a strict time saver because they need exactly what the framework provides and no more. But this never seems to be how things go for my projects.
I think an application framework is necessary. It can make your application share the same flow and behavior. Your team can follow the framework in order to reduce time and thus increase productivity. What I am saying is for enterprise application.
But for application which is for public, I think a framework may not be required as they need a lot of specific or funny behavior.
My use case is enterprise applications. That's pretty much all I do.
With no framework, you still make helper functions to simplify execution of common use cases. So, it is still quite easy for the team to reuse code. But the helpers are opt-in, so if the business has a custom requirement that doesn't work with an existing helper, you also have the choice to do something completely custom. Then if you need to do it more than once, you turn it into another reusable helper.
Framework or no,
lazinessefficiency finds a way. :)My experience with this kind of stuff in enteprise is that you can use a framework anyway, but mostly as pluggable widgets. Instead of helpers, I’ve also used conponents (React or Vue), for common tasks (ex: search forms, autocomplete, etc...). It worked very well, or at least IMHO, I prefer this approach over jQuery plugins/helpers.
I would prefer frameworks over jQuery too. :) As I mentioned, there are nuances to doing frameworkless well. I definitely did not mean to imply a free-for-all. There should be guiding principles to the design, of which MVU is a good one. For interacting with the DOM for example, nothing wrong with using the React renderer library, rather than trying to manipulate the DOM directly.