If you create 50 000 variables instead of using a loop...
If I was writing an optimizing compiler. Maybe.
I'm not quite following the CRA example. I'm gathering you mean something different than tree-shaking. Frameworks like Svelte are playing at only including the code you need by abstracting the underlying JS with nice DSLs. In so they narrow the band and capture intent better. Even things like JSX do this to some degree.
I was saying that the language of reactivity or hooks makes for a powerful DSL to describe application updates without relying on the components for that. Svelte already is going along this path. I find it takes a runtime solution to motivate a compile-time one. We do things manually before we automate them. If this unlocks this sort of capability at runtime. Compilers will follow (as the tooling becomes sophisticated enough to follow)
TL;DR The problem of framework abstraction are not abstractions themselves, but rather inability to change them.
I was saying that I'd like to have control over the tech I'm using, control over its code. You would agree that forking React or Svelte to incorporate it in your codebase is a nightmare. But JavaScript frameworks can and should be distributed as code, as a template project with small editable library functions.
I agree with you, optimization will always be needed. Not ephemeral one-size-fit-all optimization, but a custom, particular project oriented fine-tuning. And the most efficient way to do that is to simply edit the code.
Ok gotcha. Hmm.. first I've heard this particular argument. React is on one side with heavy VDOM abstraction at runtime, and Svelte on the other side where compiler takes care of everything.
I'm going to take note of this because Solid's everything is just a reactive primitive lends to this. Not sure what to do with that though. Templating is the one place where there is always a lot of code. Even things like Lit. Diffing solutions aren't really end-user tweakable and less diffing solutions like Solid are bulkier without leveraging tools like compilers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If I was writing an optimizing compiler. Maybe.
I'm not quite following the CRA example. I'm gathering you mean something different than tree-shaking. Frameworks like Svelte are playing at only including the code you need by abstracting the underlying JS with nice DSLs. In so they narrow the band and capture intent better. Even things like JSX do this to some degree.
I was saying that the language of reactivity or hooks makes for a powerful DSL to describe application updates without relying on the components for that. Svelte already is going along this path. I find it takes a runtime solution to motivate a compile-time one. We do things manually before we automate them. If this unlocks this sort of capability at runtime. Compilers will follow (as the tooling becomes sophisticated enough to follow)
TL;DR The problem of framework abstraction are not abstractions themselves, but rather inability to change them.
I was saying that I'd like to have control over the tech I'm using, control over its code. You would agree that forking React or Svelte to incorporate it in your codebase is a nightmare. But JavaScript frameworks can and should be distributed as code, as a template project with small editable library functions.
I agree with you, optimization will always be needed. Not ephemeral one-size-fit-all optimization, but a custom, particular project oriented fine-tuning. And the most efficient way to do that is to simply edit the code.
Ok gotcha. Hmm.. first I've heard this particular argument. React is on one side with heavy VDOM abstraction at runtime, and Svelte on the other side where compiler takes care of everything.
I'm going to take note of this because Solid's everything is just a reactive primitive lends to this. Not sure what to do with that though. Templating is the one place where there is always a lot of code. Even things like Lit. Diffing solutions aren't really end-user tweakable and less diffing solutions like Solid are bulkier without leveraging tools like compilers.