4 ms·

I wanna know more about what's "heavy" and what's not, and why choose lighter solutions over heavier. Are we talking purely bytes? Popularity? Typical codebase

I wanna know more about what's "heavy" and what's not, and why choose lighter solutions over heavier. Are we talking purely bytes? Popularity? Typical codebase size? Browser performance? And whichever it is, why are we prioritising it?

paulddraper 3y ago
Heavy as in "conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms. I.e. looking for solutions that "render HTML in Django, and use Javascript to enhance the server-rendred [sic] HTML." HTMX is the most popular solution.
- em-bee 3y ago
  "conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms which i think is, for the most part an exaggeration. if someone feels that learning a new framework is heavy and has a steep learning curve, then either they are juniors that need more practice and experience, or they have never tried learning a second framework, or they have become lazy. (but here i'd also like to blame employers that don't give their developers time to learn new stuff)
  - aragilar 3y ago
    Or simply what integrates well with an existing framework. The "lightweight" examples given allow for non-JS templating on the backend (in this case Python, but the article looks at other non-JS languages), whereas other frameworks require build steps/"SSR" and effectively require a REST or other API framework.
    - em-bee 3y ago
      see my comment here for a response: https://news.ycombinator.com/item?id=39157910 https://news.ycombinator.com/item?id=39157910 btw, i use frontend frameworks without bundlers/build steps, but load then statically straight into the browser. that may seem a bit wasteful, but it dramatically simplifies the maintenance needs for a site, guaranteeing that the site will keep running and be maintainable for the forseeable future.
  - deleted 3y ago
    [deleted]
  - 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.
pier25 3y ago
I assumed size which is probably what most people would associate with "heavy".
PrimeMcFly 3y ago
> I wanna know more I want to know more. Let's try to maintain a high level of writing and communication here.
- AlexeyBelov 3y ago
  > Let's Let us.
  - PrimeMcFly 3y ago
    Contractions are proper English. Your "correction" is not one. Nice try though.

paulddraper 3y ago

Heavy as in "conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms. I.e. looking for solutions that "render HTML in Django, and use Javascript to enhance the server-rendred [sic] HTML." HTMX is the most popular solution.

em-bee 3y ago
"conceptually heavy" -- complex, steep learning curve, extra build steps, bringing in non-Django paradigms which i think is, for the most part an exaggeration. if someone feels that learning a new framework is heavy and has a steep learning curve, then either they are juniors that need more practice and experience, or they have never tried learning a second framework, or they have become lazy. (but here i'd also like to blame employers that don't give their developers time to learn new stuff)
- aragilar 3y ago
  Or simply what integrates well with an existing framework. The "lightweight" examples given allow for non-JS templating on the backend (in this case Python, but the article looks at other non-JS languages), whereas other frameworks require build steps/"SSR" and effectively require a REST or other API framework.
  - em-bee 3y ago
    see my comment here for a response: https://news.ycombinator.com/item?id=39157910 https://news.ycombinator.com/item?id=39157910 btw, i use frontend frameworks without bundlers/build steps, but load then statically straight into the browser. that may seem a bit wasteful, but it dramatically simplifies the maintenance needs for a site, guaranteeing that the site will keep running and be maintainable for the forseeable future.
- deleted 3y ago
  [deleted]
- 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.

pier25 3y ago

I assumed size which is probably what most people would associate with "heavy".

PrimeMcFly 3y ago

> I wanna know more I want to know more. Let's try to maintain a high level of writing and communication here.

AlexeyBelov 3y ago
> Let's Let us.
- PrimeMcFly 3y ago
  Contractions are proper English. Your "correction" is not one. Nice try though.