I was thinking the same thing. Lol 😂😂

Perhaps unsurprisingly, ChatGPT's explanation is completely wrong, and seems made up rather than referencing anything remotely real. Primitives in objects are always stored on the heap, as are the objects themselves. The variable that reference the object might be on the stack, or it might be in a register. The stack isn't used as much in JavaScript bytecode as for instance in C, where all local variables are on the stack. JavaScript uses the stack for storing arguments, as well as local variables as part of the stack frame, but most of the time that variable is only a reference to somewhere on the heap. Meaning that every instance of say a floating point number like 3.14, will reference the same value on the heap, and not stored individually in each stack. Small integers (that can be stored as 32 bit signed int) are the exception, but most of the time they are stored and used in registers, even when passed along to other functions. Strings are NEVER stored on the stack, as they are - contrary to what ChatGPT says - NEVER fixed in size. Different engines might differ on how much or how little they use the stack, but most of the time, it only stores references to the heap.

i find the endless sarcasm so annoying, different strokes. 😊

A classic example of a genius who doesn't have a clue about the subject, but speaks up. I suspect you write even worse OOP than you comment on the FP topic....

In oop you don't have lazy evaluation, out-of-the-box parallelism and compiler that can prove that it's code that looks completely different is doing the same stuff you wrote but faster. You'll never get it in OOP language.

The term/phrase has come to mean declaring/generating markup dynamically on the web server vs the client.

You can think of it like "rendering" a template. You're right that none of the layouting-related decisions are done on the server's side.

To add to that: With the “server rendered” declarative shadow DOM, the component will take on the appearance defined in that HTML/CSS even if JavaScript isn’t even enabled. This is in contrast with the traditionally “client rendered” version where JS would still be required to execute and set the contents of the shadow DOM.

It's rendering the *html code* in the server, instead of using javascript locally. It's not about the visual rendering that the browser does.

I agree. Kids use wrong terminology to describe things. It's like software development wokeness.

With you on this. I run mostly PHP on the server side, but implement web components + Svelte on the client side. What’s more is that there are other JS runtimes and environment types (e.g. Cloudflare workers or WinterJS/WinterCG). Interestingly, runtimes _like_ those which are WinterCG compatible offer opportunities for SSR of JS-bound things (like web components) without necessarily having to have JS as your “back-end”. In this case, there are 3 total layers now (a traditional back-end, traditional front-end and a middleware layer of some sort to perform component SSR). It’s something I’m working on myself in my free time (sorta rare, but still an ongoing thing). 😅

Web components, while not quite as elegant in some ways as modern frameworks, they have one *huge* thing going for them: They’re a standard. That means that they’re here to stay. They work great to sorta bridge the gap as well, in many different ways, including between heterogeneous back-ends (like Ruby, PHP, Python, etc) and even between JS frameworks which support rendering custom elements.

In a Dave Farley interview it was said, OOP look like FP if done right.

Did you find them?

Do you have a link?

Thank you so much!! That's a very nice comment to read and I'm sorry for missing it! I used keynote animations on my mac all the way! Special shout-out to the Line Draw animation and Magic Move - you can do so many interesting this with them!

Hi there, though I am not very experienced with functional programming I have however dabbled a little in Haskell and Scala. I would reccomend you at least try to learn the basics of Functional Programming "because" it is different from object-oriented programming. It will be non-intuitive at first and it will force you to think in a very different mind frame than what you use for OOP. Thinking of a problem from a functional perspective can often help you write better OOP in turn.

@@parth46767 Hi Parth, many thanks for your advice, I will do that for sure 👍

@@giogio_7777 Did you :D Just curious about the experience because I'm in your foot now. (trying to learn it from the ground up)

YES YES YES YES!!!!!! JS is so much simpler and makes so much more sense if you ignore as much of the OOP as you can.