21 ms·

I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the ko

I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte. 6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much. I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable: - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off. - Special syntax for reactivity is not javascript - I find the javascript-native flexibility of JSX far more expressive than any custom templating - There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte - Two-way data binding is a constant source of bugs - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop) - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above). - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.

bGl2YW5j 5y ago
Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc). As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
- Aeolun 5y ago
  Redux is not React specific. I assume you could use it with Svelte somehow. That said, most React components are lightyears ahead of native Javascript components, simply because everyone uses React.
  - acemarke 5y ago
    Yes, and in fact we even have a demo of our new RTK Query data fetching API (part of our official Redux Toolkit package) being used with Svelte: https://redux-toolkit.js.org/rtk-query/usage/examples#svelte https://redux-toolkit.js.org/rtk-query/usage/examples#svelte
- tshaddox 5y ago
  How about unstyled components like a dropdown menu or a multi-select with autocomplete?
- joeyjojo 5y ago
  I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.
arxpoetica 5y ago
> Special syntax for reactivity is not javascript That's because there is no syntax for reactivity in JavaScript, period.
Sammi 5y ago
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.
JimDabell 5y ago
> - Special syntax for reactivity is not javascript > - I find the javascript-native flexibility of JSX far more expressive than any custom templating These are odd points to combine – JSX is special syntax not JavaScript as well.
- veidelis 5y ago
  Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From <div attr1="str">{children}</div> To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.
  - toastercat 5y ago
    Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain https://github.com/caderek/react-plain
    - jeswin 5y ago
      Yeah, but that's harder in practice. You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names.
      - toastercat 5y ago
        > You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names. I literally never do this, but I suppose there are people who use React/JSX as a glorified templating library. Even then I probably wouldn't do this and rather use a proper templating library where HTML is valid.
        Kiro 5y ago
malcolmstill 5y ago
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte Do you have some specific examples?
bdougherty 5y ago
I am really curious to hear about specific examples of some of these points. Specifically: > The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that. > Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example? > Two-way data binding is a constant source of bugs Again, very curious to see an example of this. > It's not possible to write a one-line function component or similar What was your use case here? I haven't found myself wanting to do that anywhere.
- jakelazaroff 5y ago
  Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
  - toastercat 5y ago
    2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).
    - eins1234 5y ago
      Any error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.
      - toastercat 5y ago
        Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).
toastercat 5y ago
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.
jeswin 5y ago
> I find the javascript-native flexibility of JSX far more expressive than any custom templating JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.
- hbbio 5y ago
  JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)
  - dharmatech 5y ago
    Opa was pioneering. Very impressive. Ahead of it's time. What stack do you prefer these days? It seems some folks still have their eye on the "full stack / single language" holy grail.
    - hbbio 5y ago
      Thanks a lot! I'm still appalled by the state of many things in JS tbh. I have the impression you have to perpetually move your codebase by adapting to your stack underlying changes, may it be the build system, the framework, tools or libraries that deprecate themselves quickly... The reasons that made start Opa are still there: There should be an easy single language to program web apps and a clean coherent single stack to build and run them. Today, I mostly code in Go and I love it (single stack, tests built in) despite the lack of generics. On the front-end, it's another story. If I have time one day, I'll rebuild something in that space.
- conradfr 5y ago
  Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).
lucasyvas 5y ago
I've not used any Svelte significantly yet, so your points may stand. I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed. useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly. I can't imagine anything worse in Svelte. If there is, I'd love to hear it.
- el_dev_hell 5y ago
  Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability. The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.
  - phist_mcgee 5y ago
    Why do you think it's terrible?
    - rajin444 5y ago
      Overloading the meaning of native language features is not the most beginner friendly. It’s a quirk you just have to remember. Compared to an explicit method name it is much less intuitive.
    - francislavoie 5y ago
      Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality. And don't even get me started about the dependencies array, which has different behaviour whether you omit the argument, or pass an empty array, or pass actual `useState` dependencies, or pass other unrelated variables. Again, it's something you just "need to memorize" to use React.
midrus 5y ago
Yes, clearly it is not for purists.
Donckele 5y ago
“ - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.” What? Can you expand on that? Makes no sense.
- korla 5y ago
  I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write. My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.
tuukkah 5y ago
> - Special syntax for reactivity is not javascript Well, JSX syntax isn't JS either. And hooks semantics is not JS. Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.
- brundolf 5y ago
  As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
  - tuukkah 5y ago
    True, although Svelte's syntax is chosen cleverly in a way that is not incompatible with existing tooling. (Starting a statement with $: is syntactically legal JS and a no-op.) Another question is how much of Vercel's resources would it take to contribute Svelte support into all the major tools.
    - brundolf 5y ago
      It's not technically incompatible, but it's mostly parseable nonsense in the plain language. So it really only serves to make sure syntax highlighters still work, which is just one of many aspects of tooling Considering JSX's current level of support involved cooperation from multiple FAAMNGs, I doubt Vercel could match it
      - tuukkah 5y ago
        Can you give an example of tooling that is not compatible with encountering the $: label? I can only think of a linter complaining about an unused label "$" or a redefined label "$". Compare this e.g. with how React linting has to know which functions are actually (custom) hooks, and they cannot have any idea about the semantics of custom hooks.
brundolf 5y ago
Much of this I would have expected, but this was less obvious: > There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte What are some examples of this?
FractalHQ 5y ago
I've been developing websites and apps with Svelte for almost 2 years now, and my experience couldn't be more different from yours. > - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off. Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered. > - I find the javascript-native flexibility of JSX far more expressive than any custom templating Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice? > - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte. I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime. > - Two-way data binding is a constant source of bugs It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility. > - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely. > - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching. > - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop) Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated. > - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects). > - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above). Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend. > - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code. The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time. Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!
_ta_2231234 5y ago
This is unfortunate for your team, but most of your conclusions are not adequate. 1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks. 2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there. Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.
- merrywhether 5y ago
  > Two way data binding is not a constant source of bugs Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding. As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.
StaticChamp 5y ago
React has special syntax for reactivity. What is useEffect? Is it a native JS function? I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags? Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte. ============== Svelte > React ==============
- merrywhether 5y ago
  > And why doesn't it allow style tags? You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually. As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.
DonHopkins 5y ago
>- Special syntax for reactivity is not javascript Are you referring to Svelte using the $: dollar label prefix syntax for reactivity? Yes, that is most certainly is standard JavaScript syntax. Read the docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... >label: The labeled statement can be used with break or continue statements. It is prefixing a statement with an identifier which you can refer to. https://svelte.dev/docs https://svelte.dev/docs >3. $: marks a statement as reactive >Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed. https://dev.to/itsjzt/understanding-svelte-s-dollar-label-syntax-3h2b https://dev.to/itsjzt/understanding-svelte-s-dollar-label-sy... >Understanding Svelte's $: (dollar label) syntax >In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties. The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all. Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above. Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design. However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.
taurath 5y ago
Every reason you’ve stated are reasons I’ve switched from one proprietary or open source framework before react to react. 2 way data binding is a mental prison in big apps, I’m sure there’s a good implementation somewhere but I’ve yet to see it.
jseban 5y ago
I don't like templating, it's too restrictive, feels like back to the 90s. This is typically aimed at coders who secretly don't want to code, and fall for tools that seems like they can avoid it. What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend

bGl2YW5j 5y ago

Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc). As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.

Aeolun 5y ago
Redux is not React specific. I assume you could use it with Svelte somehow. That said, most React components are lightyears ahead of native Javascript components, simply because everyone uses React.
- acemarke 5y ago
  Yes, and in fact we even have a demo of our new RTK Query data fetching API (part of our official Redux Toolkit package) being used with Svelte: https://redux-toolkit.js.org/rtk-query/usage/examples#svelte https://redux-toolkit.js.org/rtk-query/usage/examples#svelte
tshaddox 5y ago
How about unstyled components like a dropdown menu or a multi-select with autocomplete?
joeyjojo 5y ago
I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.

arxpoetica 5y ago

> Special syntax for reactivity is not javascript That's because there is no syntax for reactivity in JavaScript, period.

Sammi 5y ago

> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.

JimDabell 5y ago

> - Special syntax for reactivity is not javascript > - I find the javascript-native flexibility of JSX far more expressive than any custom templating These are odd points to combine – JSX is special syntax not JavaScript as well.

veidelis 5y ago
Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From <div attr1="str">{children}</div> To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.
- toastercat 5y ago
  Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain https://github.com/caderek/react-plain
  - jeswin 5y ago
    Yeah, but that's harder in practice. You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names.
    - toastercat 5y ago
      > You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names. I literally never do this, but I suppose there are people who use React/JSX as a glorified templating library. Even then I probably wouldn't do this and rather use a proper templating library where HTML is valid.
      - Kiro 5y ago

malcolmstill 5y ago

> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte Do you have some specific examples?

bdougherty 5y ago

I am really curious to hear about specific examples of some of these points. Specifically: > The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that. > Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example? > Two-way data binding is a constant source of bugs Again, very curious to see an example of this. > It's not possible to write a one-line function component or similar What was your use case here? I haven't found myself wanting to do that anywhere.

jakelazaroff 5y ago
Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
- toastercat 5y ago
  2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).
  - eins1234 5y ago
    Any error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.
    - toastercat 5y ago
      Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).

toastercat 5y ago

> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.

jeswin 5y ago

> I find the javascript-native flexibility of JSX far more expressive than any custom templating JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.

hbbio 5y ago
JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)
- dharmatech 5y ago
  Opa was pioneering. Very impressive. Ahead of it's time. What stack do you prefer these days? It seems some folks still have their eye on the "full stack / single language" holy grail.
  - hbbio 5y ago
    Thanks a lot! I'm still appalled by the state of many things in JS tbh. I have the impression you have to perpetually move your codebase by adapting to your stack underlying changes, may it be the build system, the framework, tools or libraries that deprecate themselves quickly... The reasons that made start Opa are still there: There should be an easy single language to program web apps and a clean coherent single stack to build and run them. Today, I mostly code in Go and I love it (single stack, tests built in) despite the lack of generics. On the front-end, it's another story. If I have time one day, I'll rebuild something in that space.
conradfr 5y ago
Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).

lucasyvas 5y ago

I've not used any Svelte significantly yet, so your points may stand. I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed. useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly. I can't imagine anything worse in Svelte. If there is, I'd love to hear it.

el_dev_hell 5y ago
Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability. The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.
- phist_mcgee 5y ago
  Why do you think it's terrible?
  - rajin444 5y ago
    Overloading the meaning of native language features is not the most beginner friendly. It’s a quirk you just have to remember. Compared to an explicit method name it is much less intuitive.
  - francislavoie 5y ago
    Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality. And don't even get me started about the dependencies array, which has different behaviour whether you omit the argument, or pass an empty array, or pass actual `useState` dependencies, or pass other unrelated variables. Again, it's something you just "need to memorize" to use React.

midrus 5y ago

Yes, clearly it is not for purists.

Donckele 5y ago

“ - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.” What? Can you expand on that? Makes no sense.

korla 5y ago
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write. My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.

tuukkah 5y ago

> - Special syntax for reactivity is not javascript Well, JSX syntax isn't JS either. And hooks semantics is not JS. Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.

brundolf 5y ago
As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
- tuukkah 5y ago
  True, although Svelte's syntax is chosen cleverly in a way that is not incompatible with existing tooling. (Starting a statement with $: is syntactically legal JS and a no-op.) Another question is how much of Vercel's resources would it take to contribute Svelte support into all the major tools.
  - brundolf 5y ago
    It's not technically incompatible, but it's mostly parseable nonsense in the plain language. So it really only serves to make sure syntax highlighters still work, which is just one of many aspects of tooling Considering JSX's current level of support involved cooperation from multiple FAAMNGs, I doubt Vercel could match it
    - tuukkah 5y ago
      Can you give an example of tooling that is not compatible with encountering the $: label? I can only think of a linter complaining about an unused label "$" or a redefined label "$". Compare this e.g. with how React linting has to know which functions are actually (custom) hooks, and they cannot have any idea about the semantics of custom hooks.

brundolf 5y ago

Much of this I would have expected, but this was less obvious: > There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte What are some examples of this?

FractalHQ 5y ago

I've been developing websites and apps with Svelte for almost 2 years now, and my experience couldn't be more different from yours. > - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off. Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered. > - I find the javascript-native flexibility of JSX far more expressive than any custom templating Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice? > - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte. I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime. > - Two-way data binding is a constant source of bugs It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility. > - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely. > - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching. > - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop) Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated. > - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects). > - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above). Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend. > - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code. The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time. Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!

_ta_2231234 5y ago

This is unfortunate for your team, but most of your conclusions are not adequate. 1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks. 2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there. Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.

merrywhether 5y ago
> Two way data binding is not a constant source of bugs Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding. As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.

StaticChamp 5y ago

React has special syntax for reactivity. What is useEffect? Is it a native JS function? I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags? Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte. ============== Svelte > React ==============

merrywhether 5y ago
> And why doesn't it allow style tags? You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually. As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.

DonHopkins 5y ago

>- Special syntax for reactivity is not javascript Are you referring to Svelte using the $: dollar label prefix syntax for reactivity? Yes, that is most certainly is standard JavaScript syntax. Read the docs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... >label: The labeled statement can be used with break or continue statements. It is prefixing a statement with an identifier which you can refer to. https://svelte.dev/docs https://svelte.dev/docs >3. $: marks a statement as reactive >Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed. https://dev.to/itsjzt/understanding-svelte-s-dollar-label-syntax-3h2b https://dev.to/itsjzt/understanding-svelte-s-dollar-label-sy... >Understanding Svelte's $: (dollar label) syntax >In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties. The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all. Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above. Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design. However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.

taurath 5y ago

Every reason you’ve stated are reasons I’ve switched from one proprietary or open source framework before react to react. 2 way data binding is a mental prison in big apps, I’m sure there’s a good implementation somewhere but I’ve yet to see it.

jseban 5y ago

I don't like templating, it's too restrictive, feels like back to the 90s. This is typically aimed at coders who secretly don't want to code, and fall for tools that seems like they can avoid it. What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend