4 ms·

I wasn't so excited about runes when they first came out. But, when I could create a reactive external component that I can import into a .svelte template, AND

by xrd 2y ago

I wasn't so excited about runes when they first came out. But, when I could create a reactive external component that I can import into a .svelte template, AND that internally encapsulates reactivity, my opinions changed. That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. But, most frontend people don't do testing at all. Typescript is the tool people use to guarantee correctness, and for good reason. But, svelte people have always cast a narrow eye towards typescript and for good reasons as well. So, here we are. I personally prefer writing testable frontend code, and Svelte 5 is revolutionary in that way. It is as good as unit testing, but reactive in the browser. Having said all this, the blog post rings true. Adding proxies feels very uncomfortable. React and Vue lost me when they started adding abstractions on top of abstractions and proxies were the gateway drugs.

CharlieDigital 2y ago
> ...when I could create a reactive external component that I can import into a .svelte template...That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. Isn't this the same as Vue composables? Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts https://github.com/CharlieDigital/vue3-state-definemodel/blo... Vue Component: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/Details.vue#L39 https://github.com/CharlieDigital/vue3-state-definemodel/blo... BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.
- xrd 2y ago
  Can you share an example of a testable vue component? I would like to see that. I got disillusioned around Vue 2. When they had proxies in front of class attributes that looked like functions, it really made it hard to instrument inside of tests. Maybe this is fixed now. But, it left a bad taste in my mouth.
  - CharlieDigital 2y ago
    The VueUse library is a really good place for these since it's all composables like `useClipboard`. Here's an example of a Vue composable for the clipboard: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Here is an example of how it's used: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.md https://github.com/vueuse/vueuse/blob/main/packages/core/use... And the unit tests: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.browser.test.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Another one from the same lib: https://github.com/vueuse/vueuse/blob/main/packages/core/useColorMode/index.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Unit test: https://github.com/vueuse/vueuse/blob/main/packages/core/useColorMode/index.test.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... I'm pretty certain that Svelte took inspiration from Vue composables and I'd also guess that the community will have a bit of friction before people start to get its use cases (same as it was with Vue when it was introduced).
  - MrJohz 2y ago
    With Vue 3 and the composition API, you can do basically the same things you're doing in Svelte. You can also add SolidJS and Preact to this list as well - the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events. A good example in Vue is the top example in this page: https://test-utils.vuejs.org/guide/advanced/reusability-composition https://test-utils.vuejs.org/guide/advanced/reusability-comp... The other examples show some other things you can do if you want, although I'd typically recommend against it - keep your signal-related code free of component/lifecycle-related logic, and it will almost always be much easier to test. (As an aside, I'd add Angular to the list of frameworks that are easy to test, although the framework feels like it goes out of its way to convince you of the opposite. Services are just classes that maintain reactive data - originally via RxJS/Observables, although now signals are also supported - and if you keep them like that, they're fairly easy to test. Unfortunately, Angular's decorators/DI/module system is very pervasive, and at least when I was last using it, meant that even theoretically simple tests still needed lots of boilerplate. But theoretically, it belongs in the same category as the frameworks above.)
- nsonha 2y ago
  That's just reactive programming, nothing new. It's sad that some people think it can only be achieved with wacky non-standard syntax.
wk_end 2y ago
I feel like I must be misunderstanding you. React is certainly unit testable and developers do test it - just ask react-testing-library (10M weekly downloads). I'm not a Svelte dev, so I don't really follow the distinction you're drawing. What is it that supposedly makes Svelte more testable?
- xrd 2y ago
  I haven't used React in a while so I'm happy to learn more. When I look at this example it does not look like the code I would be using inside my webapp. I have a rule of thumb: my test code should look the same as the code when it is inside my app. https://testing-library.com/docs/react-testing-library/example-intro#quickstart-annotated https://testing-library.com/docs/react-testing-library/examp... My Svelte 5 runes test code uses the code in exactly the same way that I use it inside my .svelte templates. That's very different in my opinion.
  - zdragnar 2y ago
    testing-library (and react-testing-library by extension) has a very dogmatic "black box" approach to testing FE code. In many ways it more closely resembles e2e testing than more traditional unit testing does. Personally, I think it's a PITA since it's pretty rare that copy (such as text labels) ever remains stable for very long, or are sufficiently unique on the page, so I do the "strongly discouraged" route of using data-testid attributes for everything (which also has the side effect of making people who write e2e tests happy, but I digress). With all of that said, I find myself rather appreciating the approach. I don't need tests to mirror the implementation, only the interface.
  - wk_end 2y ago
    Can you link to/post an example of how Svelte is tested that's different? In the Full Example linked, the only code that it makes sense to talk about being in the app itself is the code to render the component, and that does look precisely the same. The rest is the testing logic - inspecting the state of the DOM post-render, interacting with components by simulating events, and so on. I don't see how this could correspond to anything in the app proper.
jonstaab 2y ago
This is something I didn't cover in my post, but I feel that's a bug, not a feature. Using runes instead of stores (which did the same thing in svelte 4) implicates the svelte compiler in every source file. This is ok if you're married to svelte, but it makes vendor lock-in even more rigid, since you would have to refactor all your regular utilities too when moving to a new framework.
- throwingrocks 2y ago
  These days, vendor lock-in hardly feels like a worthwhile consideration when evaluating frameworks. A near complete rewrite feels inevitable when transitioning from, say, React to Svelte.
- CharlieDigital 2y ago
  If it's a similar transition to the one from Vue 2 Options API to Vue 3 Composition, then I expect there will be a bit of a bump, but it'll make a lot more sense afterwards. The VueUse library is probably the poster child for why this pattern is super useful.
- 0dayz 2y ago
  One of my biggest gripe with svelte. In the js world you're shooting yourself in the foot by choosing a framework that is as locked in as svelte (no vdom,domain-specific-language and their design philosophy), had to find this out the hard way. I still respect svelte for it's engineering capability, but it's a 100% commitment with no off-road options ever, but if you need a framework for js and don't like react or angular then vue would be my choice.
  - pocketarc 2y ago
    I'm a bit confused about this - if I build something in React/Vue... I'm never going to be using Vue/React alongside it, or anything else. Am I missing something? Who's out there changing frameworks in existing projects? Or is this about something else?
    - 2y ago
tmnvix 2y ago
> svelte people have always cast a narrow eye towards typescript and for good reasons as well. Out of curiosity, could you elaborate on this a little?
- crummy 2y ago
  Svelte supports TypeScript, but the project itself dropped it for JSDocs a year or so back. Here's a discussion on it, with the first post from Rich Harris himself with some reasoning: https://news.ycombinator.com/item?id=35891259 https://news.ycombinator.com/item?id=35891259
- xrd 2y ago
  But, briefly, TS is tricky if the entirety of the ecosystem isn't TS. It's becoming less of a problem, and things like deno and bun that have native support for TS are solving the problem, but Rich Harris made compelling arguments for why they went with JSDoc. And, I don't think that is a perfect solution either, but I can write code that runs even if the JSDoc isn't correct, and I can't do that when the TS compiler refuses to compile for some reason like an external library isn't right.
  - afiori 2y ago
    This is why the types-as-comments proposal for ecmascript could be a game changer, most ts files would magically become valid js files; no compilation needed
gavmor 2y ago
> It is as good as unit testing, but reactive in the browser. I am confused about this because on the one hand, you seem to be hinting at my favorite, under-hyped aspect of testing, which is its use (via TDD) as a controlled-state print/debugger, but on the other you seem to be eliding the most popular--albeit, in my view, less important aspect (insofar as one aims for "working software over comprehensive documentation"[0])--the preservation of behavior across commits and into the future. What am I missing? Edit: re "reactive in the browser," that's how I run @benchristel/taste[1] 0. https://agilemanifesto.org/ https://agilemanifesto.org/ 1. https://github.com/benchristel/taste https://github.com/benchristel/taste
DanielHB 2y ago
Fact is testing frontend code is really hard _because_ people don't build frontend code in isolation. I found that testing is much easier when using tools like storybook and browser-based testing tool (so no snapshot testing, no fake-dom). Right now I am working on a legacy project with ~10 years of work into it, about 15% of the code in there I don't even know how to trigger in the application (lots of weird specific circumstances that require special types of accounts to trigger). I just had to make a small change to hundreds of files and it was hell to manually test it everywhere. IMO almost all components should be able to be renderable in isolation and mocked data. Type systems help with this problem because they remove a whole layer of tests required, but it is not enough.

by xrd 2y ago

CharlieDigital 2y ago

> ...when I could create a reactive external component that I can import into a .svelte template...That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. Isn't this the same as Vue composables? Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts https://github.com/CharlieDigital/vue3-state-definemodel/blo... Vue Component: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/Details.vue#L39 https://github.com/CharlieDigital/vue3-state-definemodel/blo... BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.

xrd 2y ago
Can you share an example of a testable vue component? I would like to see that. I got disillusioned around Vue 2. When they had proxies in front of class attributes that looked like functions, it really made it hard to instrument inside of tests. Maybe this is fixed now. But, it left a bad taste in my mouth.
- CharlieDigital 2y ago
  The VueUse library is a really good place for these since it's all composables like `useClipboard`. Here's an example of a Vue composable for the clipboard: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Here is an example of how it's used: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.md https://github.com/vueuse/vueuse/blob/main/packages/core/use... And the unit tests: https://github.com/vueuse/vueuse/blob/main/packages/core/useClipboard/index.browser.test.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Another one from the same lib: https://github.com/vueuse/vueuse/blob/main/packages/core/useColorMode/index.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... Unit test: https://github.com/vueuse/vueuse/blob/main/packages/core/useColorMode/index.test.ts https://github.com/vueuse/vueuse/blob/main/packages/core/use... I'm pretty certain that Svelte took inspiration from Vue composables and I'd also guess that the community will have a bit of friction before people start to get its use cases (same as it was with Vue when it was introduced).
- MrJohz 2y ago
  With Vue 3 and the composition API, you can do basically the same things you're doing in Svelte. You can also add SolidJS and Preact to this list as well - the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events. A good example in Vue is the top example in this page: https://test-utils.vuejs.org/guide/advanced/reusability-composition https://test-utils.vuejs.org/guide/advanced/reusability-comp... The other examples show some other things you can do if you want, although I'd typically recommend against it - keep your signal-related code free of component/lifecycle-related logic, and it will almost always be much easier to test. (As an aside, I'd add Angular to the list of frameworks that are easy to test, although the framework feels like it goes out of its way to convince you of the opposite. Services are just classes that maintain reactive data - originally via RxJS/Observables, although now signals are also supported - and if you keep them like that, they're fairly easy to test. Unfortunately, Angular's decorators/DI/module system is very pervasive, and at least when I was last using it, meant that even theoretically simple tests still needed lots of boilerplate. But theoretically, it belongs in the same category as the frameworks above.)
nsonha 2y ago
That's just reactive programming, nothing new. It's sad that some people think it can only be achieved with wacky non-standard syntax.

wk_end 2y ago

I feel like I must be misunderstanding you. React is certainly unit testable and developers do test it - just ask react-testing-library (10M weekly downloads). I'm not a Svelte dev, so I don't really follow the distinction you're drawing. What is it that supposedly makes Svelte more testable?

xrd 2y ago
I haven't used React in a while so I'm happy to learn more. When I look at this example it does not look like the code I would be using inside my webapp. I have a rule of thumb: my test code should look the same as the code when it is inside my app. https://testing-library.com/docs/react-testing-library/example-intro#quickstart-annotated https://testing-library.com/docs/react-testing-library/examp... My Svelte 5 runes test code uses the code in exactly the same way that I use it inside my .svelte templates. That's very different in my opinion.
- zdragnar 2y ago
  testing-library (and react-testing-library by extension) has a very dogmatic "black box" approach to testing FE code. In many ways it more closely resembles e2e testing than more traditional unit testing does. Personally, I think it's a PITA since it's pretty rare that copy (such as text labels) ever remains stable for very long, or are sufficiently unique on the page, so I do the "strongly discouraged" route of using data-testid attributes for everything (which also has the side effect of making people who write e2e tests happy, but I digress). With all of that said, I find myself rather appreciating the approach. I don't need tests to mirror the implementation, only the interface.
- wk_end 2y ago
  Can you link to/post an example of how Svelte is tested that's different? In the Full Example linked, the only code that it makes sense to talk about being in the app itself is the code to render the component, and that does look precisely the same. The rest is the testing logic - inspecting the state of the DOM post-render, interacting with components by simulating events, and so on. I don't see how this could correspond to anything in the app proper.

jonstaab 2y ago

This is something I didn't cover in my post, but I feel that's a bug, not a feature. Using runes instead of stores (which did the same thing in svelte 4) implicates the svelte compiler in every source file. This is ok if you're married to svelte, but it makes vendor lock-in even more rigid, since you would have to refactor all your regular utilities too when moving to a new framework.

throwingrocks 2y ago
These days, vendor lock-in hardly feels like a worthwhile consideration when evaluating frameworks. A near complete rewrite feels inevitable when transitioning from, say, React to Svelte.
CharlieDigital 2y ago
If it's a similar transition to the one from Vue 2 Options API to Vue 3 Composition, then I expect there will be a bit of a bump, but it'll make a lot more sense afterwards. The VueUse library is probably the poster child for why this pattern is super useful.
0dayz 2y ago
One of my biggest gripe with svelte. In the js world you're shooting yourself in the foot by choosing a framework that is as locked in as svelte (no vdom,domain-specific-language and their design philosophy), had to find this out the hard way. I still respect svelte for it's engineering capability, but it's a 100% commitment with no off-road options ever, but if you need a framework for js and don't like react or angular then vue would be my choice.
- pocketarc 2y ago
  I'm a bit confused about this - if I build something in React/Vue... I'm never going to be using Vue/React alongside it, or anything else. Am I missing something? Who's out there changing frameworks in existing projects? Or is this about something else?
  - 2y ago

tmnvix 2y ago

> svelte people have always cast a narrow eye towards typescript and for good reasons as well. Out of curiosity, could you elaborate on this a little?

crummy 2y ago
Svelte supports TypeScript, but the project itself dropped it for JSDocs a year or so back. Here's a discussion on it, with the first post from Rich Harris himself with some reasoning: https://news.ycombinator.com/item?id=35891259 https://news.ycombinator.com/item?id=35891259
xrd 2y ago
But, briefly, TS is tricky if the entirety of the ecosystem isn't TS. It's becoming less of a problem, and things like deno and bun that have native support for TS are solving the problem, but Rich Harris made compelling arguments for why they went with JSDoc. And, I don't think that is a perfect solution either, but I can write code that runs even if the JSDoc isn't correct, and I can't do that when the TS compiler refuses to compile for some reason like an external library isn't right.
- afiori 2y ago
  This is why the types-as-comments proposal for ecmascript could be a game changer, most ts files would magically become valid js files; no compilation needed

gavmor 2y ago

> It is as good as unit testing, but reactive in the browser. I am confused about this because on the one hand, you seem to be hinting at my favorite, under-hyped aspect of testing, which is its use (via TDD) as a controlled-state print/debugger, but on the other you seem to be eliding the most popular--albeit, in my view, less important aspect (insofar as one aims for "working software over comprehensive documentation"[0])--the preservation of behavior across commits and into the future. What am I missing? Edit: re "reactive in the browser," that's how I run @benchristel/taste[1] 0. https://agilemanifesto.org/ https://agilemanifesto.org/ 1. https://github.com/benchristel/taste https://github.com/benchristel/taste

DanielHB 2y ago

Fact is testing frontend code is really hard _because_ people don't build frontend code in isolation. I found that testing is much easier when using tools like storybook and browser-based testing tool (so no snapshot testing, no fake-dom). Right now I am working on a legacy project with ~10 years of work into it, about 15% of the code in there I don't even know how to trigger in the application (lots of weird specific circumstances that require special types of accounts to trigger). I just had to make a small change to hundreds of files and it was hell to manually test it everywhere. IMO almost all components should be able to be renderable in isolation and mocked data. Type systems help with this problem because they remove a whole layer of tests required, but it is not enough.