EDIT: I just realised that message wasn't meant in response to me; I answered right from my notifications and had just assumed this was on another comment thread.
In other words, continue reading with the fact in mind that I'm a dumbass; but the points are still valid if applied to that other conversation (and, to some extent, probably to this one too)
I think you're still completely missing my point. I cannot give you a simple example of when complexity becomes too big for svelte to handle nicely. That's the whole point; svelte looks good in almost all simple examples, because there isn't much state to keep around, nor things to do with it. The problem is that the approach svelte takes just doesn't scale well because it is too fine-tuned to hide the complexities of a hello-world example.
And once again, you are totally misunderstanding the querySelector point. It's not about calling querySelector; it's about having a shared API. You can call any method of a normal DOM element on your custom elements, because they are just normal DOM elements. The same doesn't work svelte components, which are a separate object with a horrible API that manages the real DOM nodes.
You also cannot define methods on svelte components, which severely limits the ways you can interact with them. So from the outside, svelte components are ridiculously unwieldy compared to custom elements.
And from the inside, their paradigm for state management just doesn't scale nearly as well as plain javascript. The syntax is awkward and just similar enough to plain JS/HTML that you might get confused (just today a coworker tried doing ${} in the HTML section of a svelte component right after making a similar change in the actual JS part).
But the worst part, by far, is that there is zero re-usability without creating a new component. It's all or nothing. This might work for generic things, say, a component to turn an array into an ordered list; but sometimes these sub-components are simply too tightly linked to their surrounding component to be usable anywhere else, and at that point you're stuck with the boilerplate and performance overhead of a new full component.
And it's not even less boilerplate that you're writing; I've started switching to vanilla JS for prototyping because, aside from having the flexibility to write uglier code as I go, I also just have to write less of it, and on top of that it doesn't even need to be compiled.
I hope that was enough of an explanation. Looking forward to more nagging about how querySelector is bad.
Yes, and you can even do stuff like bind:self={array[index]} to at least save on variables a bit but that doesn't really get you all that far either. In the end it still feels like writing lots of globals, except they're at least scoped to one component.
In the end it still feels like writing lots of globals.
At this point I don't know whether you are talking about the DOM or the JS itself. Svelte gets as close to JS and I doubt that you are trying to build a frontend or custom elements to be used in another framework.
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.
EDIT: I just realised that message wasn't meant in response to me; I answered right from my notifications and had just assumed this was on another comment thread.
In other words, continue reading with the fact in mind that I'm a dumbass; but the points are still valid if applied to that other conversation (and, to some extent, probably to this one too)
I think you're still completely missing my point. I cannot give you a simple example of when complexity becomes too big for svelte to handle nicely. That's the whole point; svelte looks good in almost all simple examples, because there isn't much state to keep around, nor things to do with it. The problem is that the approach svelte takes just doesn't scale well because it is too fine-tuned to hide the complexities of a hello-world example.
And once again, you are totally misunderstanding the
querySelectorpoint. It's not about callingquerySelector; it's about having a shared API. You can call any method of a normal DOM element on your custom elements, because they are just normal DOM elements. The same doesn't work svelte components, which are a separate object with a horrible API that manages the real DOM nodes.You also cannot define methods on svelte components, which severely limits the ways you can interact with them. So from the outside, svelte components are ridiculously unwieldy compared to custom elements.
And from the inside, their paradigm for state management just doesn't scale nearly as well as plain javascript. The syntax is awkward and just similar enough to plain JS/HTML that you might get confused (just today a coworker tried doing
${}in the HTML section of a svelte component right after making a similar change in the actual JS part).But the worst part, by far, is that there is zero re-usability without creating a new component. It's all or nothing. This might work for generic things, say, a component to turn an array into an ordered list; but sometimes these sub-components are simply too tightly linked to their surrounding component to be usable anywhere else, and at that point you're stuck with the boilerplate and performance overhead of a new full component.
And it's not even less boilerplate that you're writing; I've started switching to vanilla JS for prototyping because, aside from having the flexibility to write uglier code as I go, I also just have to write less of it, and on top of that it doesn't even need to be compiled.
I hope that was enough of an explanation. Looking forward to more nagging about how
querySelectoris bad.You know you could use the
binddirective in svelte to get the element itself right?Yes, and you can even do stuff like
bind:self={array[index]}to at least save on variables a bit but that doesn't really get you all that far either. In the end it still feels like writing lots of globals, except they're at least scoped to one component.At this point I don't know whether you are talking about the DOM or the JS itself. Svelte gets as close to JS and I doubt that you are trying to build a frontend or custom elements to be used in another framework.