3 ms·

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 betwe

by 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

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.