3 ms·

I imagine it's not so much about learning curve, but about the number of concepts to keep in mind while working on your code. If an application has lots of cli

by Vinnl 3y ago

I imagine it's not so much about learning curve, but about the number of concepts to keep in mind while working on your code. If an application has lots of client-side state (and the framework to support that), for example, that means you have a whole additional lifecycle of your code to reason about. Whereas if it at most sets a disabled attribute on a button, that's conceptually a whole lot lighter.

agumonkey 3y ago
> the number of concepts to keep in mind while working on your code. And most importantly, the amount of fragile ad-hoc, potentially abandonned "concepts". I have a very different feeling when I grind hard to learn about physics or maths compared to IT solutions. The latter almost always feel empty and very temporary, which causes fatigue to rise way faster.
em-bee 3y ago
If an application has lots of client-side state, for example, that means you have a whole additional lifecycle of your code to reason about. not really, because you no longer need to track that state in the backend. the backend can be reduced to data storage and business logic calculations. the cases where you need track some state in both frontend and backend should be rare. from my experience all the UI code is moved from the backend to the frontend. it's not being duplicated. duplication of code can happen during a transition, but it should be temporary
- Vinnl 3y ago
  It's not so much that a single case affects state in both the frontend and the backend; it's that in some cases, you're going to have to reason about the lifecycle of your backend, whereas in others, it's the frontend lifecycle that's relevant. Both come with their own set of concerns, and it's more context switching and lifecycles to keep in mind.
  - em-bee 3y ago
    well, yes, sure, but that's not much different than any two projects. sure, if all your projects are using the same framework then maybe that's easier, but if you are working on multiple projects, chances are you also work with multiple frameworks. at least i do. and if i specialize, i'd do it with one frontend framework and one backend framework. ok, so that's two instead of one. anyone beyond a junior developer should have no problem with this.
    - Vinnl 3y ago
      Exactly - "heavy" frontend frameworks are like adding another project. It's not that there aren't plenty of situations where that is perfectly fine, but if all you need to do is adding a few client-side effects, I'd suggest using something more light-weight.
      - em-bee 3y ago
        that's part of what i am disputing. the frontend logic is moved to the frontend framework, and the backend is dramatically simplified. the overall complexity is not much greater than having everything in the backend framework. so i am only adding another project in terms of dealing with two frameworks instead of one, but at least on the backend i am only using 50% of that framework now. what's more, this simplifies the backend so much that in most cases it is reduced to CRUD in such a way that i can reuse it more easily. since using frontend frameworks i haven't in face needed to do any backend coding anymore because i could just reuse the backend i already had unchanged. so in my case, i only ever had to deal with one project, except for the first time where i wrote the REST API into the backend. every other website after that was a frontend project only. for dozens of projects i can now maintain a single backend implementation (with multiple instances as needed, that all share 100% of the code). that alone makes using a frontend framework worth it even just for a few simple client-side effects.
        Vinnl 3y ago
        I think this is just a case of you arguing from a different set of assumptions. The thread starter started out with a Django app and wanted to distinguish between frontend libraries' conceptual "heaviness" for adding bits of interactivity to their website. Obviously in that case (i.e. being comfortable in Django and wanting to keep that) a framework that assumes that you'll move all logic into it is then conceptually pretty heavy, given that they're not going to do that. If you are, then sure, those frameworks are conceptually lighter.

by Vinnl 3y ago

agumonkey 3y ago

> the number of concepts to keep in mind while working on your code. And most importantly, the amount of fragile ad-hoc, potentially abandonned "concepts". I have a very different feeling when I grind hard to learn about physics or maths compared to IT solutions. The latter almost always feel empty and very temporary, which causes fatigue to rise way faster.

em-bee 3y ago

If an application has lots of client-side state, for example, that means you have a whole additional lifecycle of your code to reason about. not really, because you no longer need to track that state in the backend. the backend can be reduced to data storage and business logic calculations. the cases where you need track some state in both frontend and backend should be rare. from my experience all the UI code is moved from the backend to the frontend. it's not being duplicated. duplication of code can happen during a transition, but it should be temporary

Vinnl 3y ago
It's not so much that a single case affects state in both the frontend and the backend; it's that in some cases, you're going to have to reason about the lifecycle of your backend, whereas in others, it's the frontend lifecycle that's relevant. Both come with their own set of concerns, and it's more context switching and lifecycles to keep in mind.
- em-bee 3y ago
  well, yes, sure, but that's not much different than any two projects. sure, if all your projects are using the same framework then maybe that's easier, but if you are working on multiple projects, chances are you also work with multiple frameworks. at least i do. and if i specialize, i'd do it with one frontend framework and one backend framework. ok, so that's two instead of one. anyone beyond a junior developer should have no problem with this.
  - Vinnl 3y ago
    Exactly - "heavy" frontend frameworks are like adding another project. It's not that there aren't plenty of situations where that is perfectly fine, but if all you need to do is adding a few client-side effects, I'd suggest using something more light-weight.
    - em-bee 3y ago
      that's part of what i am disputing. the frontend logic is moved to the frontend framework, and the backend is dramatically simplified. the overall complexity is not much greater than having everything in the backend framework. so i am only adding another project in terms of dealing with two frameworks instead of one, but at least on the backend i am only using 50% of that framework now. what's more, this simplifies the backend so much that in most cases it is reduced to CRUD in such a way that i can reuse it more easily. since using frontend frameworks i haven't in face needed to do any backend coding anymore because i could just reuse the backend i already had unchanged. so in my case, i only ever had to deal with one project, except for the first time where i wrote the REST API into the backend. every other website after that was a frontend project only. for dozens of projects i can now maintain a single backend implementation (with multiple instances as needed, that all share 100% of the code). that alone makes using a frontend framework worth it even just for a few simple client-side effects.
      - Vinnl 3y ago
        I think this is just a case of you arguing from a different set of assumptions. The thread starter started out with a Django app and wanted to distinguish between frontend libraries' conceptual "heaviness" for adding bits of interactivity to their website. Obviously in that case (i.e. being comfortable in Django and wanting to keep that) a framework that assumes that you'll move all logic into it is then conceptually pretty heavy, given that they're not going to do that. If you are, then sure, those frameworks are conceptually lighter.