4 ms·

I would be wary of mixing two frameworks in one project, since that would require the intersection of relevant skills from future developers or maintainers. One

I would be wary of mixing two frameworks in one project, since that would require the intersection of relevant skills from future developers or maintainers. One must be sufficiently familiar with both ends (and any idiosyncrasies of how they are used in this instance) in order to jump in and push changes that don’t mess everything up. If coming from Django side (which I did), consider whether you really need a separate framework for the front-end. Nowadays, JavaScript isn’t that hairy, and browser runtime comes with tons of batteries and syntax sugar that make it easy to write complex things. Maybe you want to use a small library like React (which is, of course, not a framework) for certain widgets, or even introduce an extra build step and write TypeScript, but sticking to vanilla overall can be key to managing cognitive load for others or your future self. Yes, maybe you’d need to write a tiny bit of boilerplate (much less than in IE6 days!), but on bright side—basic language reference (e.g., MDN) would be enough for anyone to grasp how it is generally put together. If you are considering using a framework and your front-end part is sufficiently complex for that then consider if you should rather architect it as a separate project. Putting strong boundaries in place can help keep it manageable, problems are isolated to one side, and it’d be more easy to find someone who is best at Django or best at (insert your front-end framework of choice) in future.

em-bee 3y ago
i strongly agree with the separation into two projects. that's the real advantage of frontend frameworks. for me backends are now only providing a REST or GraphQL API and no more HTML templating at all. the HTML stuff is done only in the frontend. that also takes care of the problem of overlapping skills. sure, you need to learn a new framework, but really, it is not that big of a deal. if you have been creating complete websites from CSS/HTML to the backend, it really doesn't change that much. your CSS/HTML skills apply unchanged, and the only thing that is new is javascript itself and a new templating system. the problem (as other commenters noted) stems from backend frameworks trying hard to avoid javascript. so they will try to do as much as they can in the backend, and i can imagine that throwing a full frontend framework into that is going to be challenging. i never tried it. as soon as i started using frontend frameworks 10 years ago, i was done with server side HTML generation.
- mcosta 3y ago
  That works great for apps, not so great with content sites.
  - strogonoff 3y ago
    In contrast to sibling comment, I think you have a “content site” then you don't really need a framework. Vanilla can be enough. However, there is no clear line between a content site and a web app. That’s why I suggest that, as a rule, if you see front-end becoming so complex that a full-blown framework is a must, then it might save you in future if you architect it as a separate project. (As sibling comment points out, it doesn’t need to compromise the ability to render static HTML and degrade in UAs without JavaScript.)
    - em-bee 3y ago
      i don't want to get into the argument about what is better for a content site. that's not the point. i am only focusing on the cognitive load argument. to reiterate, for me the cognitive load is no different whether i use a frontend framework or not. i need similar structure and logic for the frontend, regardless whether the frontent is built with a frontend framework in the browser or in a backend framework on the server. ironically, the main reason i would use a frontend framework for a simple content site is that it would allow me to build all my sites using the same specific frontend and backend code, which actually reduces the cognitive load because i can build my new site just like the last one. obviously, if you want your site to work without javascript at least as a fallback then that's not a good idea, which just goes to show that maybe using cognitive load as a metric itself is not a good idea.
      - strogonoff 3y ago
        > for me the cognitive load is no different whether i use a frontend framework or not A framework, as opposed to a library, requires you to understand its way of thinking, so there is a big difference in whether you must understand one framework or two frameworks in order to make any change. If you have a single project that intermingles two frameworks then your cognitive load is necessarily higher than if you are dealing with only one framework and in future you (or your client) have to hire someone who knows both, and knows them well. The cognitive load is lower if you know both frameworks now in their current state, but we all know frameworks evolve and go in/out of fashion. In addition to the above, depending on a framework is a big thing. Due to inversion of control, it’s much more difficult to refactor something that’s written in a framework, rather than just using some library. Going with two frameworks multiplies that problem by two. It’s like constructing a building on shoulders of two giants that can go their own separate ways. If something happens to either one of them (changes license, changes core team & direction, gets abandoned & no longer receives security fixes, etc.) you’d have to redo a lot of things. Going with vanilla means you don’t need to grasp another framework, even if you need to write a bit more code today. Going with cleanly separated projects means your cognitive load is limited to one framework at a time (plus the connecting layer). It’s more easy hire someone who’s great at back-end & Django and someone else who’s great at front-end & Alpine, instead of finding one person who happens to be great at both. > it would allow me to build all my sites using the same specific frontend and backend code, which actually reduces the cognitive load because i can build my new site just like the last one Sure, adopting a framework whenever you want to save on boilerplate code and cognitive load today would work (thanks to the same inversion of control), but I find is likely to cause maintainability issues and more cognitive load tomorrow. > obviously, if you want your site to work without javascript at least as a fallback then that's not a good idea, which just goes to show that maybe using cognitive load as a metric itself is not a good idea. I think making the site work without JavaScript is a different problem, you can do it regardless of whether you use a front-end framework (unless the particular framework you use makes it difficult).

em-bee 3y ago

i strongly agree with the separation into two projects. that's the real advantage of frontend frameworks. for me backends are now only providing a REST or GraphQL API and no more HTML templating at all. the HTML stuff is done only in the frontend. that also takes care of the problem of overlapping skills. sure, you need to learn a new framework, but really, it is not that big of a deal. if you have been creating complete websites from CSS/HTML to the backend, it really doesn't change that much. your CSS/HTML skills apply unchanged, and the only thing that is new is javascript itself and a new templating system. the problem (as other commenters noted) stems from backend frameworks trying hard to avoid javascript. so they will try to do as much as they can in the backend, and i can imagine that throwing a full frontend framework into that is going to be challenging. i never tried it. as soon as i started using frontend frameworks 10 years ago, i was done with server side HTML generation.

mcosta 3y ago
That works great for apps, not so great with content sites.
- strogonoff 3y ago
  In contrast to sibling comment, I think you have a “content site” then you don't really need a framework. Vanilla can be enough. However, there is no clear line between a content site and a web app. That’s why I suggest that, as a rule, if you see front-end becoming so complex that a full-blown framework is a must, then it might save you in future if you architect it as a separate project. (As sibling comment points out, it doesn’t need to compromise the ability to render static HTML and degrade in UAs without JavaScript.)
  - em-bee 3y ago
    i don't want to get into the argument about what is better for a content site. that's not the point. i am only focusing on the cognitive load argument. to reiterate, for me the cognitive load is no different whether i use a frontend framework or not. i need similar structure and logic for the frontend, regardless whether the frontent is built with a frontend framework in the browser or in a backend framework on the server. ironically, the main reason i would use a frontend framework for a simple content site is that it would allow me to build all my sites using the same specific frontend and backend code, which actually reduces the cognitive load because i can build my new site just like the last one. obviously, if you want your site to work without javascript at least as a fallback then that's not a good idea, which just goes to show that maybe using cognitive load as a metric itself is not a good idea.
    - strogonoff 3y ago
      > for me the cognitive load is no different whether i use a frontend framework or not A framework, as opposed to a library, requires you to understand its way of thinking, so there is a big difference in whether you must understand one framework or two frameworks in order to make any change. If you have a single project that intermingles two frameworks then your cognitive load is necessarily higher than if you are dealing with only one framework and in future you (or your client) have to hire someone who knows both, and knows them well. The cognitive load is lower if you know both frameworks now in their current state, but we all know frameworks evolve and go in/out of fashion. In addition to the above, depending on a framework is a big thing. Due to inversion of control, it’s much more difficult to refactor something that’s written in a framework, rather than just using some library. Going with two frameworks multiplies that problem by two. It’s like constructing a building on shoulders of two giants that can go their own separate ways. If something happens to either one of them (changes license, changes core team & direction, gets abandoned & no longer receives security fixes, etc.) you’d have to redo a lot of things. Going with vanilla means you don’t need to grasp another framework, even if you need to write a bit more code today. Going with cleanly separated projects means your cognitive load is limited to one framework at a time (plus the connecting layer). It’s more easy hire someone who’s great at back-end & Django and someone else who’s great at front-end & Alpine, instead of finding one person who happens to be great at both. > it would allow me to build all my sites using the same specific frontend and backend code, which actually reduces the cognitive load because i can build my new site just like the last one Sure, adopting a framework whenever you want to save on boilerplate code and cognitive load today would work (thanks to the same inversion of control), but I find is likely to cause maintainability issues and more cognitive load tomorrow. > obviously, if you want your site to work without javascript at least as a fallback then that's not a good idea, which just goes to show that maybe using cognitive load as a metric itself is not a good idea. I think making the site work without JavaScript is a different problem, you can do it regardless of whether you use a front-end framework (unless the particular framework you use makes it difficult).