I think it is really hard to make an informed decision without a lot of experience. Even when you lean on advice from trusted voices, unless you have someone to guide you through the experience, you might navigate it in a way that turns unpleasant. A lot of internet guides are made for demo purposes, and will lead you astray for long term maintenance.
In the end these are all valid paths to create an app, but each has its own nuances and traps. Might as well pick one that seems interesting (if learning) or is well known (if building a product).
For me, the right way is MVU-style and no framework. Libraries for integration (DOM rendering, HTTP, etc). Frameworks bring a lot of abstractions that you have to learn. These usually save time at first, but tie your hands in other ways down the road. Including knowledge dependencies. How many job listings say things like "[some framework] experience required"? Because if you are not intimately familiar with how that framework's abstractions work, you probably will take a long time to get up to speed on the code base. But like above, this no-framework advice has nuances too. (Although I find mistakes easier to fix than in framework-based.)
Yes. For learning, you should know the key concept of the framework such as two-way binding or MVU (Model-View-Update, I think). (I guess MVU and two-way binding are the same. Please correct me if I am wrong.)
Just for a project. I think I need to select a framework. In addition, I need to build my application framework on top of it as I want the application flow the same behavior or style.
I admit even a very experienced developer would find it very difficult.
I guess developers should select one they just think safe for their project. Do not waste too much time on selection. I think "do something wrong" may be better than nothing (I think).
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.
I think it is really hard to make an informed decision without a lot of experience. Even when you lean on advice from trusted voices, unless you have someone to guide you through the experience, you might navigate it in a way that turns unpleasant. A lot of internet guides are made for demo purposes, and will lead you astray for long term maintenance.
In the end these are all valid paths to create an app, but each has its own nuances and traps. Might as well pick one that seems interesting (if learning) or is well known (if building a product).
For me, the right way is MVU-style and no framework. Libraries for integration (DOM rendering, HTTP, etc). Frameworks bring a lot of abstractions that you have to learn. These usually save time at first, but tie your hands in other ways down the road. Including knowledge dependencies. How many job listings say things like "[some framework] experience required"? Because if you are not intimately familiar with how that framework's abstractions work, you probably will take a long time to get up to speed on the code base. But like above, this no-framework advice has nuances too. (Although I find mistakes easier to fix than in framework-based.)
Yes. For learning, you should know the key concept of the framework such as two-way binding or MVU (Model-View-Update, I think). (I guess MVU and two-way binding are the same. Please correct me if I am wrong.)
Just for a project. I think I need to select a framework. In addition, I need to build my application framework on top of it as I want the application flow the same behavior or style.
I admit even a very experienced developer would find it very difficult.
I guess developers should select one they just think safe for their project. Do not waste too much time on selection. I think "do something wrong" may be better than nothing (I think).
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.