4 ms·

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 lifecy

by 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.
      - em-bee 3y ago
        you are right. i am arguing based on the assumption that this: being comfortable in Django and wanting to keep that is a bad idea. because whoever is doing that is missing out on a lot of potential. sure, there are many cases where sticking with django for everything is the right choice, but that's not always true, and i am trying to argue that there is a benefit to exploring the alternative. i was a backend developer too, django, laravel, others,, and i shunned javascript as much as i could, but when i discovered angularjs (the first version, before it was popular) it just won me over as the better way to build frontends. in particular, not having to track state in the server, i feel, makes the whole development process so much easier. i could summarize it thusly: i would use a lightweight option only if the site is mostly stateless (which many content sites tend to be) but as soon as it is necessary to track state, i find a frontend framework talking to an API is the better choice, because tracking state in the browser is so much easier.
        Vinnl 3y ago
        Heh I mean, I'm a frontend engineer too and agree with you that there's so much to be had in the frontend :) But I also understand that people have preferences and habits, and that there's a cost to investigating potential other paths one could take without knowing in advance whether they're right for them.
        em-bee 3y ago
        well, you never know in advance, and while i don't fault people for feeling overwhelmed by the many ever changing frontend frameworks, everyone should at least build one true SPA with any frontend framework to learn what the fuss is all about. because you can't make an informed choice about the suitability of building an SPA if you are not familiar with the choices. there is also the aspect of using frontend frameworks for mobile development, where an SPA is more likely to be suitable to enable disconnected operation.

by Vinnl 3y ago

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.
    - em-bee 3y ago
      you are right. i am arguing based on the assumption that this: being comfortable in Django and wanting to keep that is a bad idea. because whoever is doing that is missing out on a lot of potential. sure, there are many cases where sticking with django for everything is the right choice, but that's not always true, and i am trying to argue that there is a benefit to exploring the alternative. i was a backend developer too, django, laravel, others,, and i shunned javascript as much as i could, but when i discovered angularjs (the first version, before it was popular) it just won me over as the better way to build frontends. in particular, not having to track state in the server, i feel, makes the whole development process so much easier. i could summarize it thusly: i would use a lightweight option only if the site is mostly stateless (which many content sites tend to be) but as soon as it is necessary to track state, i find a frontend framework talking to an API is the better choice, because tracking state in the browser is so much easier.
      - Vinnl 3y ago
        Heh I mean, I'm a frontend engineer too and agree with you that there's so much to be had in the frontend :) But I also understand that people have preferences and habits, and that there's a cost to investigating potential other paths one could take without knowing in advance whether they're right for them.
        em-bee 3y ago
        well, you never know in advance, and while i don't fault people for feeling overwhelmed by the many ever changing frontend frameworks, everyone should at least build one true SPA with any frontend framework to learn what the fuss is all about. because you can't make an informed choice about the suitability of building an SPA if you are not familiar with the choices. there is also the aspect of using frontend frameworks for mobile development, where an SPA is more likely to be suitable to enable disconnected operation.