4 ms·

That works great for apps, not so great with content sites.

by mcosta 3y ago

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
why is that? if you are thinking that content sites should work without javascript, then that's an entirely different issue. but aside from that, frontend frameworks work just fine for content sites, and there is absolutely no duplication of any logic in frontend and backend. i have built sites like that myself.

That works great for apps, not so great with content sites.

by mcosta 3y ago

That works great for apps, not so great with content sites.

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

why is that? if you are thinking that content sites should work without javascript, then that's an entirely different issue. but aside from that, frontend frameworks work just fine for content sites, and there is absolutely no duplication of any logic in frontend and backend. i have built sites like that myself.